IPv6: Сколько адресов нужно для счастья?

    Картинка, которая некоторых привыкших к IPv4 сетевиков может ввести в ступор:

        R6#sh ipv6 interface brief
        FastEthernet0/0            [up/up]
            FE80::218:18FF:FE45:F0E2
            1::1
            1::2
            1::3
            1::10
            1::100:500
            2::1
            2::2
    

    Причём каждый из этих адресов может быть использован наравне с другими. Как так?

    Важные изменения в IPv6


    1. Адресов на интерфейсе может быть много.
    2. У адресов есть scope — область видимости или область действия.
    3. Активно используются адреса с областью действия в пределах сегмента — так называемые link-local.
    4. Адреса могут быть сгенерированы самостоятельно.


    Теперь подробнее.

    1. Много адресов на интерфейсе


    Конечно можно возразить, что в IPv4 тоже были различные методы, как назначить на интерфейс несколько адресов (secondary, alias и так далее). Но в IPv6 адреса сделали равными, и это открывает широкие возможности.

    К примеру, узел может использовать один адрес для связи в своей локальной сети, другой адрес для связи в пределах организации и третий — для доступа в Интернет. Или сразу 10 для доступа в Интернет — на каждый сайт отправлять запросы с нового адреса.

    Введён механизм предпочтения и старения адресов, с помощью которого можно делать плавную смену адресов в сети. На первом этапе все запросы начинают отправляться с новых адресов, но узлы продолжают откликаются и на старые тоже. Затем ещё через некоторое время старые адреса полностью списываются в утиль.

    На первый взгляд может показаться «Ну и ладно», однако такие маленькие детали приведут к совсем другой логике назначения адресов.

    2. Scope


    Опять же, формально область действия была и у адресов в IPv4.

    Есть link-local адреса. Они обычно известны под кодовым именем "$@#*!!! Опять DHCP не работает!" и выбираются из диапазона 169.254.0.0/16. Но вообще-то у них есть функции помимо «Дать админу понять, что его DHCP-сервер не выдаёт адреса».

    Во-первых, такой адрес может быть автоматически сгенерирован самим устройством. Во-вторых, он вполне подходит для связи внутри сети. Ограничение: он вообще-то не должен маршрутизироваться, ибо link-local.

    Кроме них, RFC 1918 задаёт три диапазона приватных адресов: всеми любимый 192.168.0.0/16, большой 10.0.0.0/8 и незаслуженно забываемый 172.16.0.0/12 (т.е. от 172.16.0.0 до 172.31.255.255). Они маршрутизируются, но только в пределах вашей внутренней сети. Для связи в Интернете их использовать нельзя.

    Наконец, есть (недостаточно) много уникальных («публичных», «белых») адресов, которые выдаются в пользование организациям и провайдерам и подходят для связи в глобальном масштабе.

    Существенное ограничение IPv4: нельзя использовать эти адреса одновременно. Либо link-local, и сиди без связи с другими сетями, либо приватные, но без NAT в Интернет не попасть, или публичные, которые подходят для всего, но нынче в страшном дефиците.

    В IPv6 одновременно можно использовать адреса с разной областью действия. Надо постучаться к соседу по сети — используем link-local. Пошли в Интернет — берём глобально-уникальный.

    Для узлов предусмотрены три варианта адресов:

    • Link-local. Диапазон FE80::/10. Обязан быть на всех узлах с IPv6. Создаётся узлом самостоятельно (например, по EUI-64), либо можем задать его ручками. Как следует из названия, действует в пределах сегмента, поэтому уникальность требуется только в пределах этого сегмента (как у MAC-адресов, например). Отсюда на разных интерфейсах может быть одинаковым.
    • Unique-local address (ULA). Это аналог «приватных» адресов. Scope — вообще говоря, глобальный (RFC 4193), но в Интернете их маршрутизировать никто не обязан, поэтому в большинстве случаев будут срезаться провайдером, например. Назначать можно по аналогии с адресами 192.168..., только теперь их много больше, поэтому вероятность выбрать одинаковые гораздо ниже.

    Примечание
    В IPv4 есть одна неприятная ситуация с приватными адресами, когда фирма А покупает фирму Б, и в этих фирмах используется одинаковая сеть (в худшем случае 10.0.0.0/8). Сращивать их — головная боль. Хотя адреса ULA можно брать любые, рекомендуется их генерировать случайным образом и заносить в один из общественных каталогов (например сюда). Это гарантирует очень маленькую вероятность пересечения. Если же вы возьмёте «красивые» адреса ULA, и потом вам придётся сращивать одинаковые сети на пару с другим таким же неудачником админом — сами виноваты.

    • Глобально уникальные адреса. Таких больше всего. Маршрутизируются, уникальны на всей планете, прямой аналог публичных IPv4 адресов.


    Примечание
    Ранее существовали т.н. site-local адреса со своей областью действия — одной площадкой (site). Но разработчики IPv6 пришли к выводу, что понятие площадки слишком мутное, и от site-local отказались в пользу ULA.


    Кроме общего понятия «область действия», у каждого конкретного адреса на конкретном интерфейсе возникает зона действия. Это часть топологии, на которую распространяется область действия данного адреса с данного интерфейса. Для программистов обычно предлагается такое объяснение: область действия — это абстрактный класс, а зона действия — экземпляр класса. Например, у link-local-адреса на интерфейсе Fa0/0 зоной действия будет сегмент сети, подключенный к интерфейсу Fa0/0.

    Границы зон проходят по узлам. Отсюда link-local адреса на разных интерфейсах маршрутизатора будут лежать в разных зонах.

    Визуализировать области действия и зоны действия поможет картинка:
    image

    Побочный эффект: возникает двусмысленность. Если мы говорим «Отправь пакет на FE80::101», то встречный вопрос будет «На который из интерфейсов?», потому что данный адрес может быть на любом из интерфейсов. Поэтому для link-local адресов обязательно уточняется интерфейс, который будет использоваться. В Windows используется записи вида FE80::1%5, где после символа "%" идёт ID интерфейса. В Linux применяется название (FE80::1%eth0).

    3. Польза от link-local адресов


    Возможность одновременно использовать адреса разных типов открывает очень интересные возможности.

    Возьмём вот такую топологию:

    image

    Сколько подсетей нужно, чтобы у нас была связь по IP между компьютером и сервером?

    В IPv4 понадобится 4 подсети, и даже если мы будем брать сети /31, это 8 адресов.

    Сколько подсетей достаточно будет настроить в IPv6?

    Правильный ответ
    Две, одна между компьютером и Router0, а другая между сервером и Router2. Остальные адреса могут быть link-local, их можно сгенерировать автоматически.


    Как это возможно?

    А очень просто. Маршрутизация работает хоп за хопом. На каждом этапе нам нужно знать только исходящий интерфейс и адрес следующего перехода, причём физический, а IP нам нужен постольку-поскольку.

    Компьютер знает link-local адрес ближайшего роутера (Router0). Router0 знает link-local следующего в цепочке (Router1). Router1 знает адрес Router2. Router2 может доставить сообщение серверу. Обратно так же.

    Уточнение: Как справедливо заметил в комментариях Alukardd, такая возможность есть и в IPv4. Поэтому в Интернете вы вполне можете увидеть приватные адреса в результатах трассировки.

    Проверим.

    Включим маршрутизацию IPv6:

    Router#conf t
    Router(config)#ipv6 unicast-routing
    

    Включим IPv6 на интерфейсах, адреса link-local создадутся автоматически:

    Router(config)#interface fa0/0
    Router(config-if)#ipv6 enable
    Router(config-if)#interface fa0/1
    Router(config-if)#ipv6 enable
    Router(config-if)#end
    Router#
    

    Проверяем:

    Router#show ipv6 interface brief
    FastEthernet0/0 [up/up]
    FE80::201:C7FF:FE8D:B001
    FastEthernet0/1 [up/up]
    FE80::201:C7FF:FE8D:B002
    

    Настраиваем глобальные адреса:

    Router0#conf t
    Router0(config)#interface fa0/0
    Router0(config-if)#ipv6 address 1::1/64
    

    Router2#conf t
    Router2(config)#interface fa0/1
    Router2(config-if)#ipv6 address 2::1/64
    

    Обратите внимание, что на компьютерах в общем случае ничего настраивать не нужно, адреса будут автоматически получены. Каким образом — тема отдельной статьи.

    Наконец, понадобится маршрутизация. Настроим OSPFv3.

    Router0#conf t
    Router0(config)#ipv6 router ospf 1
    %OSPFv3-4-NORTRID: OSPFv3 process 1 could not pick a router-id,please configure manually
    
    !Обратите внимание, нужно настроить router-id, для каждого из роутеров свой уникальный
    Router0(config-rtr)#router-id 1.0.0.0
    Router0(config-rtr)#exit
    Router0(config)#interface fa0/0
    Router0(config-if)#ipv6 ospf 1 area 0
    Router0(config-if)#interface fa0/1
    Router0(config-if)#ipv6 ospf 1 area 0
    

    Повторяем процедуру на остальных роутерах (меняя router-id, само собой). После этого у нас установится соседство (по link-local адресам!), и в таблицу маршрутизации попадут нужные маршруты.

    Router0#sh ipv6 route
    IPv6 Routing Table - 4 entries
    Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
    U - Per-user Static route, M - MIPv6
    I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
    O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
    ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
    D - EIGRP, EX - EIGRP external
    
    C 1::/64 [0/0]
    via ::, FastEthernet0/0
    L 1::1/128 [0/0]
    via ::, FastEthernet0/0
    O 2::/64 [110/3]
    via FE80::201:63FF:FE59:4501, FastEthernet0/1
    

    После чего можно убедиться, что всё работает.

    На грани экстрима
    Можно обойтись всего двумя глобальными адресами (на компьютер и на сервер). Однако в этом случае на Router0 и Router2 придётся создавать статические маршруты до компьютера и сервера, соответственно, поскольку самостоятельно роутеры об этих адресах не узнают. Затем можно сделать редистрибуцию в OSPF и проверить, что связь даже в таком странноватом случае будет.


    Вывод: для транзита трафика достаточно использовать link-local адреса. Глобально-уникальные адреса и ULA нужны будут только в том случае, если вы хотите обратиться к самому устройству (к примеру, зайти на роутер по SSH).

    Несомненный плюс маршрутизации по link-local адресам в том, что убирается привязка к конкретной адресации. Можно привести такую аналогию: в IPv4 маршрут записывался через названия улиц и домов — «По улице Ленина до дома 51 и направо». В IPv6 маршрут можно записать как «два светофора прямо, на третьем направо». В случае смены адресации («переименования улиц») маршруты IPv4 нужно перестраивать заново, а в IPv6 всё продолжит работать как обычно.

    4. Автоматическое назначение адресов


    Про EUI-64 разъяснение было ранее, но сама тема в целом достойна отдельной статьи.

    IPv6-адреса через EUI-64: Точки над i

    Надеюсь, статья была полезна. Следующая на очереди тема — раздача слонов адресов.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 54

      0
      Спасибо. Никак не могу собраться с силами прочитать правила и спецификации всей этот IPv6 кухни.
      А тут доступно и с примерами.
      Жду продолжений.
        +1
        На здоровье! Продолжение уже скоро, плюс есть более далёкая цель — несколько заметок по безопасности для IPv6 — ради которой на самом деле всё это и затевалось.
      0
      У меня на свежеустановленной 7 винде при пинге любого сайта выдавался ipv6 адрес.
      При этом блокировки работали исправно. Отключил Ipv6 в настройках сетевого подключения, пинг стал выдавать обычный ipv4 адрес.

      Пара вопросов:
      1. Лучше отключить ipv6 или оставить?
      2. Можно ли использовать ipv6 для обхода блокировок сайтов?

      Провайдер банит по ip + самописный тормозной dpi.
        +3
        Вопрос с предпочтением между IPv4 и IPv6 тонкий. В DNS у сайтов с IPv6 будут две записи — А и АААА, соответственно дальше уже ПО на компьютере решает, что использовать. Сейчас общая тенденция такая: либо IPv6 предпочитается, либо соединения отправляются одновременно, а там смотрим, кто ответил и кто быстрее.

        По глобальным настройкам в Windows 7 есть вот такой KB. В частности там два «фиксика» — на приоритет IPv6 и наоборот IPv4.

        По вопросам:
        1. Общая рекомендация — если не используем, то отключаем, но это по соображениям безопасности. А так можете в те же торренты зайти и посмотреть, что там IPv6-пиры есть.
        2. Для представителей Рос-трам-парам-надзоров — нельзя, и точка, и дальше читать не нужно. Для остальных — в IPv6 можно много чего, и в том числе многие ограничения не работают.

        Могу посоветовать подключить себе домой IPv6-туннель, через того же Hurricane Electric — бесплатно и познавательно. Статьи где-то в округе были, но ссылки под рукой нет. Если будет нужно, могу и об этом написать.
        0
        Побочный эффект: возникает двусмысленность. Если мы говорим «Отправь пакет на FE80::101», то встречный вопрос будет «На который из интерфейсов?», потому что данный адрес может быть на любом из интерфейсов. Поэтому для link-local адресов обязательно уточняется интерфейс, который будет использоваться. В Windows используется записи вида FE80::1%5, где после символа "%" идёт ID интерфейса. В Linux применяется название (FE80::1%eth0).

        Вот этот момент остаётся для меня не совсем понятным. Почему link-local адрес может быть на любом из интерфейсов? Он же генерируется на основе MAC адреса, а MAC у интерфейса, ведь, уникальный. И сразу понятно от какого интерфеса MAC и, соответственно, link-local адрес.
        Я, похоже, упускаю что-то очевидное, но что? Можете пояснить этот момент?
          +1
          MAC-адрес у интерфейса уникальный в пределах сегмента сети. В других сегментах такой же MAC может быть на любом устройстве.

          Простой пример: ваш провайдер привязывается к MAC-адресам, а вы хотите поставить беспроводной роутер для раздачи трафика.
          Способ 1: звоним в техподдержку, просим перепривязать.
          Способ 2: заходим с компьютера на веб-интерфейс роутера, находим функцию «Clone MAC», делаем «тынц», и всё работает. На внешнем интерфейсе роутера будет такой же MAC, как у вашего компьютера.
            0
            А правильно ли я понимаю, что можно и руками поставить адрес? Приснопамятный FE80::1, к примеру? В этом случае у нас будет несколько LL-адресов на интерфейсе — автоматически созданные на основе MAC, и назначенные нами.
              0
              Сам себе отвечу — правильно, и это просто кайф:
              user@grand:~$ ip -6 addr show dev wlan0
              3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
              inet6 fe80::1/64 scope link
              valid_lft forever preferred_lft forever
              inet6 fe80::211:76ff:fe21:325/64 scope link
              valid_lft forever preferred_lft forever

                0
                Можно хоть сколько адресов, и в этом как раз вся соль.
                Опять же, никто не запрещает вам поставить а) красивые адреса link-local или б) красивые MAC-адреса вида 02:00:00:00:00:01, как в предыдущей статье, чтобы не только link-local, но и все остальные адреса были такими.
              0
              Так. Допустим у меня в компьютере два сетевых интерфейса. Каждый из них подключен к своему L2 сегменту. В каждом отдельном L2 сегменте вполне могут существовать одинаковые link-local адреса. Следовательно, если я хочу попинговать узел, который находится в первом L2 сегменте я должен указать сетевой интерфейс к которому подключен этот L2 сегмент иначе возникает неопределённость.
              Так, да?
                +1
                Именно так. И если пишете, например, статический маршрут, то тоже обязательно указываете помимо link-local адреса ещё и интерфейс.
                  0
                  Спасибо. Картина прояснилась :-)
                    0
                    Никак не могу понять, почему наличии маршрута например
                    fe80::20c:39ff:fe4f:87fa%en0 0:c:39:4f:87:fa UHLWIir en0

                    ping6 всё равно нужно вызывать с %en0, иначе ping6: sendmsg: No route to host
                      0
                      Так работает Link-Local в IPv6. Интерфейс нужно указывать всегда.
                    +1
                    Вопрос даже не в возможных коллизиях адресов в разных сегментах. Неопределённость есть и без коллизий.

                    В таблице маршрутизации для всех интерфейсов с поднятым v6 есть запись про fe80::/64. Одинаковый префикс — выбрать исходящий интерфейс без подсказки невозможно.
                0
                Тут на ipv4 с мультихомом проблемы зачастую (всё непрозрачно и через энное место).
                Что ж на ipv6 будет O_O
                  +1
                  Ну на IPv4 это выглядит, как чужеродная технология, а на IPv6 оно изначально так задумывалось. Думаю, все хорошо будет.
                    0
                    Не обязательно, но будем надеяться. Вообще в IPv6 на бумаге город-сад, развитой социализм и так далее. К сожалению, некоторые вещи на практике работают, а некоторые нет от слова «совсем».

                    В плане мультихоума как раз не всё гладко, потому что проблемы с ним фундаментальные. И в IPv6, если правильно помню, где-то до середины 2000-х была одна логика, а потом всё переосмыслили. Провайдеронезависимые (PI) адреса те же впихнули, хотя изначально планы были не допустить фрагментации адресного пространства как в IPv4.
                    +1
                    Во-первых, с IPv4 можно прекрасно использовать кучу различных адресов на одном интерфейсе и PBR ни кто не отменял.
                    Во-вторых, IPv4 так же можно маршрутить через серые сетки (совсем не обязательно выделять 4 белые сетки под это дело), и более того, так оно и бывает в реальной жизни у некоторых провайдеров.
                      0
                      Абсолютно согласен, ну так ведь IPv6 к нам не из космоса прилетел. Просто в нём это «искаропки» и настраивается в полторы команды.
                        0
                        Перечитал и понял, что не понял глобально-уникального ;) смысла комментария.

                        Варианты трактования:
                        1) IPv6 не нужен. Безблагодатный холивор, и если так, то уточню — маркетингом IPv6 не занимаюсь. Цель статьи — рассказать про особенности и «странности» IPv6, а не давать ему оценки.
                        2) Тёртых спецов ничего не удивляет и не пугает. Ну да, на то они и специалисты. Чтобы не было обид со стороны специалистов, немного переписал вступление. С другой стороны, статья не совсем для них, потому что объясняются основы основ IPv6.
                        3) ???
                          +1
                          )))
                          Смысл моего комментария в том, что не надо подавать материал в формате «IPv4 ни чего не умеет». Да, у IPv6 есть разные вкусности, но и IPv4 не пальцем деланный и прекрасно решает почти все возможные задачи.

                          Я сам за IPv6. На работе вот провайдер выдал нам блок /48, а мой домашний всё ещё не поддерживает, пришлось самому поднимать 6to4, благо белый IPv4 у меня есть. Так что в не любви к IPv6 меня обвинить нельзя.
                            0
                            Соглашусь, что это может так восприниматься. Просто вы в курсе, как это можно сделать в IPv4, а другие нет. И в IPv4 подобные штуки были сугубо опциональны, а в IPv6 это нормально, рекомендуется или даже требуется.

                            В любом случае, во имя Великой Справедливости добавил эту информацию в статью.
                            –1
                            И заодно вопрос — как Вы собрались брать в IPv4 «сети» /31, это недорешение для экономии в PtP соединениях??? В таких ситуациях, обычно нарезают на сети /30.
                              0
                              Это если максимально ужаться, сделать Point-to-point и воспользоваться такой возможностью. В тексте скорее для иллюстрации, что обычным методом хоть заужимайся, но адреса расходуются.
                        0
                        Спасибо снова за цикл статей! Очень кстати, потому что разбираться самому времени нет, а инфы пока намного меньше, чем по в4…
                          0
                          Кстати, asch, что-нибудь слышно про Mobile IPv6 с Home agent? Это вообще где-нибудь работает, или хотя бы будет, или все так и останется на бумаге?
                            +1
                            Скажу честно, что я это чудо тоже вживую не видел, пока только по диагонали просмотрел configuration guide. И кого спрашивал — тоже не видели. Но вопрос хороший, надо будет на досуге поразбираться.
                              0
                              Да-да, тоже очень хочется увидеть это вживую!
                              Читал описание вот здесь, но в рабочем состоянии так и не увидел.
                            +1
                            Что прикольно, для IPv4 тоже можно использовать link-local адреса в схеме как на картинке в п. 3. Настраивается и работает абсолютно так же, как для IPv6. Ведь маршрутизируемые пакеты не используют эти адреса (у них-то нормальные маршрутизируемые адреса), а на маршрутизаторах указание next hop используется только для определения интерфейса, через который выйдет пакет, и физического адреса следущего маршрутизатора — тут без разницы, link-local, глобально уникальные или приватные там будут адреса.

                            То есть, для IPv4 потребуется две сети — между компом и маршрутизатором, и между маршрутизатором и сервером. Остальные адреса будут локальными.

                            Только это не принято, считается, что нужно обязательно использовать там подсеть /30 и белые адреса (если речь об интернете).
                              0
                              Раз пошла такая пьянка…

                              Ну во-первых, можно, да. Но в RFC по Link-local для IPv4 написано, если правильно помню, что не следует использовать эти адреса при наличии нормальных и допускается их использовать, если приспичило.

                              Во-вторых, берём две циски и делаем следующий трюк:
                              R1#ping 10.0.0.2 source 169.254.0.1
                              Type escape sequence to abort.
                              Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
                              Packet sent with a source address of 169.254.0.1
                              !!!!!
                              Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
                              

                              R2#ping 169.254.0.1 source 10.0.0.2
                              Type escape sequence to abort.
                              Sending 5, 100-byte ICMP Echos to 169.254.0.1, timeout is 2 seconds:
                              Packet sent with a source address of 10.0.0.2
                              !!!!!
                              Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
                              

                              А ещё Деда Мороза не существует

                              Что касается приватных адресов, то да, можно, см. выше.

                                +2
                                Хорошо, что вы про циску вспомнили. Циска вообще не знает, что такое 169.254, она их маршрутизирует (проверял специально). У неё нет понятия ipv4 link-local. Это как бы намекает нам на то, что разработчики там клали на RFCшки.

                                Ну не шмогла отдельно взятая контора его осилить. Что вовсе не отменяет факта наличия стандарта и того, что никто не запрещал его применять другим вендорам, кто способен реализовать.
                              +1
                              Также узел может быть доступен одновременно сразу через двух провайдеров безо всяких BGP: по одному адресу через одного, по другому адресу — через второго.

                              Не совсем понял этот момент. Разве есть какие-то отличия от IPv4? Как в случае IPv4, так и в случае IPv6 нам нужно добавить правила маршрутизации (ip rule в Linux) и сделать несколько таблиц маршрутизации. Если этого не сделать, то пакет, пришедший с любого интерфейса, будет уходить через default gateway какого-то одного провайдера. Или я ошибаюсь?
                                0
                                Эффект примерно такой же, как и в случае двух провайдеров и сервера, который спрятан за NAT. Со стороны провайдера А он виден со своим префиксом, а со стороны провайдера Б — со своим. В зависимости от того, какой адрес выдаёт DNS — через такой линк клиент к вам и будет отправлять запрос.

                                Маршрутизация обратного трафика настраивается чуть проще, потому что в IPv6 для ответного трафика уже по адресу источника понятно, через какого из провайдеров отправлять. В случае с NAT тоже обходится: транслируем в разные приватные адреса или в разные порты.
                                  +1
                                  Не понимаю вас.
                                  Есть у нас сервер и два провайдера. Оба выдают по одной /64-подсети. Ставим какой-то default gateway (например, через первого провайдера). При запросе по IP второго провайдера, ответ пойдет через первого, т.к. он указан как default gateway.
                                  Поведение не отличается от IPv4.
                                  Я где-то заблуждаюсь?
                                    0
                                    Не совсем так. В теории было обновление RFC 3484, в котором, среди прочего, добавляется правило «Ходи через того, кто тебе дал этот префикс». Однако судя по дате (2011), ждать, что это работает здесь и сейчас, не приходится. Поэтому используем запасной вариант — PBR по адресу источника.

                                    Есть ещё одна тонкость, что выдаваемый провайдером префикс в случае сбоя нужно старить (рекламировать с нулевым lifetime), и с этим тоже могут быть проблемы.
                                      0
                                      PBR по адресу источника

                                      то есть, точно так же, как IPv4, как писал ValdikSS — в линуксе это ip rule from адрес-источника lookup таблица-с-соответствующим-nexthop
                                        +1
                                        Нашёл более свежие RFC на данную тему, и… в общем, ваша правда, ValdikSS описал единственный работающий способ, который как в IPv4.

                                        Пункт в RFC 3484 bis про выбор адреса на основании некст-хопа так никуда и не ушёл.

                                        Судя по RFC 7157, время прошло, а проблема так и не решена. Один из подходов — ввести таблицы маршрутизации с source-destination. Т.е. то, что сейчас делает PBR. Но опять, статус сугубо экспериментальный, и даже если это будет, то не скоро.

                                        Есть другие подходы — LISP, например, но идеальных нет. У некоторых есть большое желание сделать NPT (NAT66), но это всё обычно отметается по религиозным соображениям.

                                        В общем, прошу прощения за дезинформацию, обещанный простой multihoming так и не запилили. Жаль.
                                      0
                                      del
                                  +1
                                  Растаращить )
                                    +2
                                    Вы промахнулись.
                                    0
                                    Давно использую. Туннель 6in4 из домашнего роутера в Huricane Electric. Отладочный сервер с несколькими ipv6 адресами с разными JavaEE серверами на разных ip адресах. Miredoo, в офисе и других местах. DynDNS, чтобы не запоминать адреса.
                                    Это не так хорошо, как если бы провайдер выдал мне /64 ipv6 адрес, но очень близко к этому.
                                      +3
                                      Вы погрязли в легаси ifconfig'а. Линукс уж лет 10 умеет несколько ipv4 равноправных адреса на интерфейсе.

                                      ip addr add — и делайте сколько понадобится.
                                        0
                                        а теперь попробуй заставить локальное приложение прибинденное на 0.0.0.0:949 отправить с него UDP пакет через второй дефолтгейтвей, а не через первый.
                                        а я попкорн рядом пожую.
                                          0
                                          iptables -t mangle -A OUTPUT -p udp --sport 949 -j MARK --set-mark 0x1

                                          ip route add default via второй-гейт table special

                                          ip rule add fwmark 0x1 lookup special

                                            0
                                            Ага. Уходит при этом через правильный интерфейс, но с неправильным source address.

                                            … и SNAT не отрабатывает.

                                            … хотя да, забыл сказать, что это при разных интерфейсах. разные адреса на одном интерфейсе работают при этом корректно, да.
                                              0
                                              Неправда ваша. Всё правильно будет. В таблицу маршрутизации вместе с командой add default добавится и dev интерфейс (само, хотя можно и руками указать). А если интерфейс point-to-point, то via nexhop можно не указывать, только интерфейс — типа ip route add default dev ppp1 table N — и это работает. И всё пойдёт через правильный интерфейc.

                                              А чтобы NAT работал — это вопрос отдельный, но тоже реализуемо.

                                              Собственно, подобная цепочка правил — это миллион раз пройденный путь — habrahabr.ru/post/117620/
                                              Работает безотказно.
                                                0
                                                Я не идиот, и подобную систему тоже составлял уже десяток раз. Вот только фактически уходит через правильный интерфейс но с неправильным source addr.
                                                Впрочем, я ниосилятор, и возможно это выкрутасы астериска; хотя он НЕ ставит saddr при отправке если забинден на вилдкард.

                                                То есть схема именно такая: mangle/output => ip rule fwmark =>default via xxx dev yyy src zzz
                                                ходит через правильный интерфейс, но с неправильным source address.
                                                  0
                                                  вероятно, в таблице маршрутизации тогда нужно было ещё src добавить как подсказку «какой адрес подставлять пакету»

                                                  маршрутизация в линуксе действует по порядку: netfilter OUTPUT (здесь мы ставим метку) -> routing (выбирается интерфейс по метке с помощью ip rule и тут же подставится адрес из src) -> POSTROUTING (а тут всевозможные NATы)
                                                    0
                                                    см. выше про «dev yyy src zzz»

                                      Only users with full accounts can post comments. Log in, please.