Сервисы в провайдерской сети

Последний наш модуль. Довольно быстро мы его должны закончить. Сугубо теоретически, здесь никаких лаб не будет. Просто про какие-то вещи, которые у любого провайдера должны присутствовать, здесь я расскажу. Первое, что нужно будет заметить, это то, что провайдеры ISP, которые, они предоставляют услугу доступа в интернет. Поэтому это то, чего мы, собственно говоря, от них ожидаем. Но вообще говоря, ISP иногда предполагает и оказание других услуг, в том числе, как уже говорили мы в начале курса, там есть трипл-плей с телефонией, с телевизором, там есть всякие другие вещи. Ну, они обычно предоставляются просто как то, что вы говорите, что у вас есть там определенный Вилан или определенные адреса, и с этих адресов там валится, например, поток телевизора. Что касается основной задачи интернет-сервис-провайдера, это все-таки предоставлять интернет. Интернета у нас на сегодня по факту два, это независимые интернеты. Интернет для IPv4, интернет для IPv6.

Если говорить про ситуацию в российской юрисдекции, в российском законодательстве, то нигде не написано, что такое интернет. То есть есть куча всяких законов о том, как надо оказывать услуги связи, с каким качеством эти услуги связи должны оказываться, какие лицензии нужно иметь. Но нигде не написано, что такое интернет. Поэтому по факту, если вы предполагаете, что вы являетесь провайдером, но оказываете доступ только к половине интернета, засудить вас за это невозможно. То есть нигде нет определения того, что такое интернет. Есть просто понимание того, что вот есть некая всемирная информационная, коммуникационная сеть, одна штука, и вот вроде бы все называют интернетом именно доступ к чему-то там на нее похожему. Но по большому счету нигде нет указания, что вот если мы берем интернет и от него отделяем какой-то один узел, вот что она интернетом быть перестает. Или даже два узла, или три узла, или миллион узлов. То есть в какой момент интернет перестает быть интернетом и становится просто какой-то обычной коммуникационной сетью, нигде в законе этого не указано. Более того, нельзя доказать, что вы предоставляете доступ к интернету,

нельзя доказать, что вы его не предоставляете. Поэтому вот есть такая вот любопытная особенность. Ну да, интернет на самом деле две штуки. Это как бы два независимых объединения узлов. Есть интернет, который доступен через IPv4, есть интернет, который доступен через IPv6. По факту на сегодня интернет IPv4 примерно в 10 раз больше, чем IPv6. Для того, чтобы в IPv4 у нас доступ для пользователей осуществлялся, нам нужно будет где-то раздобыть адреса, с которыми эти пользователи будут выходить в мир. С очень большой вероятностью нам потребуется включить NAT, потому что адресов у нас, скорее всего, не будет столько же, сколько пользователей. Адреса сейчас будут дорогие, и по этой причине чаще всего провайдеры все-таки NAT используют. За рядкими исключениями, в которых провайдеры достаточно богатые, буратинки когда-то в свое время купили большой пул белых адресов и могут себе позволить каждому клиенту выдавать отдельный белый IPv6.

NAT, соответственно, у провайдеров не совсем обычный с точки зрения технологии он точно такой же, он точно так же перебивает IP-адреса, но за счет большого количества сессий, одновременно которые надо поддерживать, трекить, есть специальный маркетинговый термин. Это carrier-grade NAT или large-scale NAT. То есть это такой специальный тип NAT для провайдеров, который ничем не отличается от обычного домашнего NAT, просто он очень большой и толстый. Как правило, железки, которые выполняют NAT, они очень сильно нагружены, потому что NAT — это операция довольно сложная технологически. И если вы выполняете NAT на просто обычном роутере, делаете это целиком на процессоре, то обычная производительность такого NAT, она где-то там в районе 40-50 мегабит на слабеньких процессорах, там 100-200-300 мегабит на нормальных процессорах. Если вы делаете это на обычных серверных процессорах, то вы можете допустить, что у вас там NAT будет транслироваться,

ну, порядка, например, да, там гигабит, десятка гигабит, но все равно вы рано или поздно упираетесь в какую-то цифру, дальше которой процессор просто не может уже работать. Плюс к тому, каждая сессия, она даже если вдруг не пропускает через себя трафик, она потребляет определенные ресурсы. Если вы хотите пропускать через себя сотни тысяч сессий и оперировать там десятками гигабит в секунду, то для этого потребуется, скорее всего, специально отдельные устройства, которые будут специально заточены под провайдерские NAT. Кроме того, для работы нужен будет DNS. Что в IPv4 мире, что в IPv6 мире, DNS нужен. Ну, даже тогда, когда мы назначаем настройки на узел, мы всегда прописываем IP-шник, шлюз и DNS. Ну, то есть все эти настройки надо будет где-то взять, и DNS, скорее всего, вы хотите использовать свой. Вы, конечно, можете взять и направить ваших пользователей на Google DNS восьмерке, и даже оно, наверное, будет работать, но как-то традиционно это не принято делать.

Традиционно принято пользователям давать доступ к своему серверу DNS, который дальше уже будет разрешать их запросы. Если говорить про IPv6, та же самая история, только NAT уже не нужен, классический NAT, когда перебиваются адреса, но дополнительно к интернету IPv6 обычно идет бонусом необходимость обеспечения переходных технологий. То есть либо вы предполагаете, что у вас будет именно доступ к двум интернетам одновременно, вы даете там и IPv4 адреса пользователю, и IPv6, либо вы можете пойти по более модному новому пути и дать пользователю доступ только к сети IPv6, и в этот момент пользователь у вас скажет, ну как же так, я же хочу ходить в ресурсы, которые только IPv4, всякие там твиттеры, фигиттеры, но вы говорите, окей, я тебе даю доступ только к IPv6 сети, но я тебе даю возможность через эту IPv6 сеть ходить в IPv4. Или наоборот, я тебе даю доступ только к IPv4 сети, но я тебе позволяю через нее ходить в IPv6.

Все это будет называться переходными технологиями, Transition Technologies, и мы сейчас про них пробежимся быстренько. Ну и еще одна услуга, которую традиционно провайдеры ISP предоставляют, хотя вообще-то говоря, она к интернету прямого отношения не имеет, это MPLS VPN. Про них мы уже говорили, что если вы берете пользовательский кусочек данных, оборачиваете в MPLS меткой и профорвардите такой кусочек данных до точки выхода в своей сети, и дальше выплюните без особых изменений, то вот это вот и будет как раз MPLS VPN. Штука довольно дорогая для пользователей, но тем не менее она пользователям будет очень интересна, потому что она, а, дает подконтрольное качество обслуживания, б, провайдер может подписаться кровью под тем, что качество обслуживания будет соблюдаться при выполнении определенных условий. Поэтому, если, допустим, у вас клиенты, которым требуется высокое качество соединения, требуется минимальные задержки, требуется минимальный джеттер,

то они зачастую готовы платить за MPLS VPN. Так, давайте про все это дело детально поговорим. То, что в интернете сейчас большое количество маршрутов IPv4, я вам только что показывал, сейчас прямо вот на лету, буквально там сколько, полчаса назад, я заходил на роутер BGP-шный Looking Glass сервер швейцарского провайдера, и он мне показал там 760 тысяч маршрутов. Довольно много. И эти маршруты постоянно меняются, то есть появляются новые сети, которые рассказывают, что вот они доступны теперь так, теперь доступны эдак. Нам постоянно нужно их пересчитывать и понимать, с какой стороны до этих сетей лучше всего добраться. Провайдер не может воспользоваться маршрутом по умолчанию, потому что это привилегия конечных абонентов. Они говорят, что все сети в мире доступны через моего провайдера или там через двух провайдеров. Я буду ходить через какой попало. Но провайдер не может направить трафик, куда попало. Ему точно необходимо знать, где находится каждый из участников

взаимодействия интернета. Поэтому ему придется знать каждый из этих узлов, каждый из этих маршрутов, 800 тысяч маршрутов, которые есть в таблице, с какой стороны будут находиться. 800 тысяч маршрутов можно запихать только в один протокол BGP. То есть ни в один другой протокол динамической маршрутизации столько просто не влезет. Плюс еще, если туда запихать 70 тысяч IPv6 маршрутов, ну, то есть получается под миллион. Если вдруг вы будете оказывать услугу L3 в MPLS VPN, то вы будете получать еще пользовательские маршруты дополнительно к маршрутам из интернета. И их тоже может быть довольно много. Поэтому обычно для маршрутизаторов, которые используются в провайдерах, выбирают те модели, которые способны в своей голове держать, ну, как минимум, 2 миллиона маршрутов. Лучше больше. Плюс к тому специфическая особенность в России, что у нас есть замечательный Роскомнадзор, который периодически рассказывает про то, куда ходить не надо. И одна из техник, как запретить некоторым пользователям ходить на некоторые ресурсы, на которые государство считает,

их не нужно пускать, это вбросить нуль роуты с 32-й маской. То есть у вас в таблице, в реестре запрещенных ресурсов есть какие-то IP-шники, вы их парсите на отдельный слэш 32 и вбрасываете в таблицу маршрутизации, в таблицу BGP. Дальше по BGP раздаете эти маршруты на конечные роутеры. Эта штука подвержена атакам со стороны Роскомнадзора, которые периодически пытаются туда вбросить слэш 10-е сетки, в которых реально много узлов. То есть когда вбросили 16 миллионов сетей, все роутеры, которые использовали такую технику блокировки, они немножко погрустнели. Ну, тем не менее, да. Жизнь боль. Как бы там ни было, современные роутеры, которые провайдеры используют, они, как правило, такие штуки пережевывают без особых проблем. Если говорить про провайдеров, которые в свое время купили какое-то бэушное железо,

там, не знаю, шеститонники, каталисты, и пытаются использовать их в своей провайдерской сети, ну, потому что о чем? В принципе, неплохая железка. Ну, вот, да, старые шеститонники со старыми супервизорами вполне возможно уже такое количество маршрутов пережевывать не смогут. То есть для них там 2 миллиона маршрутов, это уже как бы много. Если вы включаете BGP, то вам нужно будет получить уникальный номер автономной системы. Получается он в региональном регистраторе. Вы приходите, говорите, я хочу купить номер автономки. Ну, и при соблюдении определенных бюрократических требований вам его дают. Дальше вам нужно будет взять адреса, и эти адреса тоже получить у своего регистратора и раздать их абонентам. Варианты адресации, которые можно будет придумать, будут следующие. Если вы используете IPv4, то вы можете сказать, что либо вы используете на каждого абонента отдельную слэш-31 или там слэш-30 сетку. Это будет предполагать, что у вас либо какой-то point-to-point канал,

не знаю, например, PPP поднимается с абонентом, или вы поднимаете, допустим, отдельный Вилан, и в этом Вилане вы говорите, вот у нас есть IP-шник, у соседа есть IP-шник. Штука эта крайне неэкономная, потому что вы много IP-шников при этом разбрасываете. Раньше так делали, сейчас очень мало кто так сделает, поэтому штука, вот именно самая первая, когда вы выдаёте на каждого абонента отдельную слэш-31 или слэш-30 сетку, она вот сегодня всё менее-менее популярна за счёт неэффективного расходования IP-адресов. Штука более популярная, это слэш-24 сетка на несколько абонентов, то есть у вас есть, там, не знаю, частная сеть или публичная сеть, и вы говорите, вот давайте мы слэш-24 разделяем по отдельным IP-шникам на наших абонентов, и у нас есть, там, не знаю, свечи, вот в этом свече у нас юзеры сидят, одному там точка один IP-шник, другому точка два, третьему точка три, ну и всех их можно либо запихать в один большой вилан, и тут как-то у некоторых

возникают вопросы, что такое взять, запихать в один вилан, значит, они могут между собой взаимодействовать, получается, да, что получается, трафик между ними ходит. Часто бывает так, что, да, трафик между ними натурально ходит, часто бывает так, что у нас свеч будет с правильными буковками Metro Ethernet, и, соответственно, мы объявляем, что это порты у нас uni, uni здесь, uni здесь, и трафик между абонентами здесь перестает ходить. С точки зрения настроек, вот эта вот штука самая простая, но есть нюансы, что трафик между разными абонентами здесь у нас взаимодействовать никаким образом не может. То есть, если мы хотим разрешить нашим пользователям ходить из одной сети в другую, эта схема красивая наша разваливается. Сюда же можно будет отнести всякие штуки типа Private VLAN или Protected Port, которые, по сути, свои делают то же самое, когда у нас обычные абоненты между собой обмениваться трафиком не могут. Они могут обмениваться только со внешним миром. Тоже, соответственно, это как бы подозрительная схема по причине вот именно

как бы адреса расходуются экономно, но вопросы безопасности, вопросы доступа, доступности ресурсов, они, соответственно, не всегда решаются при такой схеме. Что можно в такой схеме будет предложить? Можно будет сказать, давайте мы здесь вообще адреса не используем, у нас не используется IP в такой сети, но у нас здесь поднимается PPP-OE сервер, PPP-OE, и дальше у нас, соответственно, получаются у каждого пользователя отдельные PPP-шные трубы на Brass. А вот в Brass здесь мы уже можем использовать PPP-32 сетку на абонента. Эта штука очень любима провайдерами, то есть мы говорим, что у нас используют слэш-32 сетки на каждого абонента, мы говорим, у тебя IP-шник 10.1.1.1, у тебя IP-шник 10.1.1.2, но по 32 маскам. На сервер, при этом, мы выделяем какой-нибудь IP-шник чисто декоративный, можем из этой же сети, можем не из этой же, то есть говорим 10.1.1.0

Flash-32. Это вот IP-шник самого этого самого Brass. И дальше у нас это все нормально работает, если мы используем PPP. Поэтому PPP в провайдерах очень нежно любим. PPP просто, PPP-ое и его разновидности. Если вы не хотите поднимать PPP-ое, хотите нативный PPP иметь, нативный IP, простите, поверх изернета, можно сделать схему с VLAN-пер-юзер, то есть вы говорите, у вас есть свитч, у вас есть юзеры, которые на нем сидят, вот, и вы говорите, вот здесь вот у нас один VLAN, здесь у нас другой VLAN, здесь у нас третий VLAN, здесь мы выделяем IP-шники 10.1.1.0.1.1. Может быть, даже Slash-32. Здесь мы говорим 10.1.1.0. Slash-32 в обычном эзернете. И дальше статикой прописываем эти маршруты на соседях. То есть мы вот здесь вот на клиенте должны будем сказать, что у нас есть статический маршрут до сети 10.1.1.0.

Slash-32 доступны через этот интерфейс. Там эзернет ноль. На соседе, на роутере. На нашем свитче, ну, или на нашем брасе абсолютно аналогичные настройки прописываются. То есть мы создаем connected маршрут, присоединенный маршрут, и на каждой железке мы должны будем это сделать. тоже такая техника иногда используется. Она неудобная, потому что требует большого количества настроек, в том числе и на абонентах. Но если вдруг вы знаете, что абонентские железки вам подконтрольны, то есть эти CPE-шки, например, вы выдаете своим клиентам, продон, и они принадлежат фактически вам, они подконтрольны вам, то вот такая вот схема, она позволяет экономить адреса, при этом трафик между абонентами может ходить, но он ходит через ваш центральный вот этот вот роутер. Если вы используете IPv6, вы должны будете каждому абоненту выдать отдельную сетку slash64, при этом на транзитных интерфейсах,

которые у вас будут между вами и абонентской железкой, в принципе, там можно вообще маршрутизируемые адреса не иметь, если очень хочется, можно их генерировать по слааку, и дальше внутри абонентской сети CPE-шка будет раздавать уже конечным терминальным устройствам адреса из той сетки, которую вы им дадите. Как минимум, вы должны будете выдавать каждому абоненту slash64, просто потому, что меньше, мельче сетки выдавать запрещено, иначе сломаются все механизмы тип слаака. В правилах, в RFC и в рекомендациях региональных регистраторов прописано, что следует выдавать, ну, лучше 56, а вообще-то, конечно, 48. так, далее. Если мы используем IPv6, это происходит следующим образом. Мы, как провайдер,

должны будем отдать конечному, не конечному, а устройству, клиентскому префикс. мы его отдаем, как правило, по протоколу DHCP. В IPv6 это такая штука, как DHCP Prefix Delegation, и мы отдаем тот префикс, который клиент должен будет побить на части и кусочки по 64 маске раздать своим абонентам. При этом, если вот здесь вам нужен какой-то IP-шник, вы его генерите после лаку. То есть, у вас провайдерское устройство говорит окей, мы отдаем с помощью роутер-аннонсмент указание, какая у нас онлинк-сеть используется, клиентское устройство, не клиентское устройство, клиентская CPI-шка генерит после лаку адрес, дальше она по DHCP, получив указание, что там еще какие-то настройки есть по DHCP, надо будет их получить менеджмент флаг видит, забирает префикс, который подает ей наш роутер, и дальше клиентская CPI-шка

раздает эти самые префиксы на своих интерфейсах, которых у нее может быть один, может быть много, но чаще всего все-таки один. При этом автоматически здесь же срабатывают и все маршруты, которые у вас должны устанавливаться, потому что если у вас здесь есть несколько маршрутизаторов топологии, и у клиента начинают вот здесь порождаются какие-то сетки, значит, здесь одна 64-я сетка, здесь другая 64-я сетка, здесь третья 64-я сетка, но они все складываются в единый тот префикс, который клиентская CPI-шка получила от провайдерского роутера. провайдерский роутер, когда под HCP префикс delegation отдает этот самый префикс, он автоматически порождает в таблице у себя маршрут, который смотрит на абонента. Этот маршрут можно будет взять и, например, редистрибутнуть в BGP. таким образом у вас автоматически все эти маршруты будут анонсироваться с того роутера, который их раздает. Вы можете сделать каскадный префикс delegation, сказать,

например, у нас есть некий пул, и мы из этого пула выбираем какой-то один по 48-й маске, а всего у нас пул, не знаю, слэш 32-й. И мы вот этот 32-й пул дербаним на 48-й, одному клиенту отдали одну 48-ю сетку, другому другую, третьему, третью, и вот те сетки, которые у нас есть, мы вбрасываем BGP по 48-й маске, а дальше у нас где-то на границе сети большой роутер стоит, пограничник, который наружу вообще в интернет отдает уже агрегированный слэш 32. Это то, как выглядит работа с IPv6-ыми адресами. Почему я про это рассказываю? Потому что очень часто люди, которые сидят в провайдерах, они почему-то не знают, что в IPv6 нужно использовать механизм prefix delegation, что достаточно на интерфейсе, который смотрит на клиента со стороны провайдерского роутера, то есть вот здесь прописать IP-шник из некоторой сети, которую они хотят выделить клиенту, они говорят, вот у нас есть вот такая слэш 32-я сетка,

мы говорим, вот здесь мы вешаем IP-шник 2001 DB8 B1 6B 2. не знаю, B5 2.1 и говорим, вот типа ты ставь маршрут на IP-шник, мы его по 64-й маске повесили, и нам все типа круто. В IPv4 такая штука бы сработала, то есть вы говорите, окей, у нас есть там сетка слэш 30-я, и вот типа вот у тебя твоя железка, пусть она на меня, на этот IP-шник смотрит. По IPv6 эта штука не сработает, то есть вот здесь вот не должно быть этой сети, эта сеть должна быть вот здесь, вот в этом вот широковещательном домене, вот здесь вот ее быть не должно, вот этого IP-шника здесь быть не должно, этот IP-шник должен висеть вот тут вот, на клиентской железке. Для того, чтобы клиентский маршрутизатор поставил правильный маршрут, ему нужно поставить либо статик, вручную прописанный, на некоторый IP-шник провайдерского роутера, ну и это иногда можно сделать, допустим,

вы каким-нибудь образом изощряетесь, узнаете link-local адрес этого роутера, на него ставите маршрут. И второй момент, вот этот вот роутер должен поставить со своей стороны маршрут на адрес CPE-шки. Вот если вы пытаетесь ручками повесить какие-то IP-шники, то вы не должны забыть ручками создать такой статический маршрут. Если вы не хотите заморачиваться статическими маршрутами, а никто на самом деле не хочет с ними заморачиваться, вам следует использовать DHCP PrefixDelegation, который все это сделает за вас. Вы настраиваете PrefixDelegation вот здесь, вот вы говорите, вы по DHCP раздаете куски какого-то пула слэш-32 по 48 маскам. То есть вы на интерфейсе не настраиваете IP-шник, вы на интерфейсе настраиваете DHCP PrefixDelegation. У вас PE-шка начинает на CPE-шке раздавать кусочки большого пула, CPE-шка такие кусочки хватает, делит их на части и по кусочкам назначает на абонентов. PE-шка при выдаче по DHCP этого префикса автоматически на того, кто его запросил,

ставит маршрут, автоматически заносит его в свою таблицу маршрутизации и автоматически его можно редистрибутить в BGP. То есть только так и никак иначе. Альтернатива на самом деле только одна. Статикой создавать все маршруты вручную. Это нереально по количеству административных задач. DHCP PrefixDelegation работает нормально, ни одной причины его не использовать. Адреса, что IPv4, что IPv6, нужно заранее где-то получить. То есть я сказал, что у нас есть слэш-32 сетка в IPv6 или слэш-24 сетка в IPv4. Эти все сетки надо где-то получать. Получаются они в региональных регистраторах. Если вы провайдер, вы получаете статус локального регистратора LIR. В принципе, не только провайдеры бывают LIR-ами, бывают еще и предприятия LIR-ами. И они могут самостоятельно получать в каких-то случаях адреса для своих нужд. Ну вот, как бы предполагается, что провайдеры получают статус этого LIR-а, получают блоки адресов

у регионального регистратора, дальше начинают раздавать эти адреса во временное пользование своим клиентам. Адреса бывают провайдеры независимые, провайдеры independent или сокращение PI, IP-адреса, или провайдеры aggregatable, то есть провайдеры зависимые адреса или PA, IP-адреса. IPv4, PI-адреса, вот эти вот, купить уже нельзя. По факту они давным-давно закончились. IPv6 все еще можно, но вы должны будете предоставить письмо, что вам это действительно нужно. Вот. Если вы хотите прикинуться провайдером и получить статус LIR-а, никаких проблем, даже сейчас в условиях недостатка IPv4-х адресов вам 22-ю сетку в принципе вполне дадут. 22-я сетка это 1000 адресов, 1024 адреса. В принципе, для каких-то простых задач этого хватит. Ну и опять же, да, для любых задач, предполагающих взаимодействие через НАТО, этого тоже хватит. На всякий случай, повторю кратенько, что региональных регистраторов

пять штук. Это европейский RIP, американский ARIN, азиатский Asia Pacific APNIC, латиноамериканский LACNIC и африканский AFRINIC. Схема раздачи адресов выглядит следующим образом. Региональные регистраторы получают у ИАНа блоки адресов, ну, сейчас ИАНа все уже блоки давным-давно раздала. Дальше, региональный регистратор раздает лирам кусочки этих самых блоков. Ну, по состоянию на сейчас у всех регистраторов уже свои блоки закончились, остались только те, которые были в БУ, скажем, во вторичном пользовании. Если мы говорим про PA-адреса, то IPv4 PA-адреса никак не отличаются от нормальных, просто адреса, они просто адреса и все. В IPv6 PA-адреса имеют некую структуру, мы ее на самом деле уже видели. То есть сначала начинаются они либо на двойку, либо на тройку.

Дальше та часть, которая относится к региональному регистратору, это не позже, чем 23 символ заканчивается. Например, вот столько вот, это может относиться к конкретному риру. Например, не знаю, Ripe. Дальше. Лир получает блок обычно по 32 маске. В принципе, если вы крупный лир, вы можете запросить и более крупный блок, чем 32. Ну, если вы как бы штатно предполагаете, что 32 блока вам не хватит, вы можете попросить крупнее. Практика знает, что лиры иногда получают вплоть до вот таких вот штук. Ну, это крупные провайдеры, если мне память не изменяет, и TNT вот такой вот блок получал в свое время. Далее. Конечный клиент, когда хочет получить адрес у конкретного лира, он получает некий адрес, и идентификатор этого клиента, он будет, ну, если мы говорим про схему

с slash56, вот здесь у нас номер клиента. Это клиент. Дальше клиент полученную сетку slash56 делит на части. Вот это вот будет кусочек выданный клиенту, ну, если хотите, номер VLAN. И вот все, что справа, вся правая половина, это у нас будет интерфейс ID. Интерфейс ID. Далее. Если мы говорим про PI-адреса, провайдеры независимые, то они никоим образом не выделяются среди всех остальных. Они будут иметь совершенно произвольный вид. Единственное, что про них можно будет сказать, это то, что у них будет некий, ну, они тоже будут начинаться на двойку или на тройку, они тоже будут принадлежать тому же блоку адресов, что и PI-адреса, но они уже не будут выдаваться некоторому конкретному леру, они уже будут получаться вами напрямую в региональном регистраторе. Если вы предприятие, которое хочет получить провайдер независимые адреса для того, чтобы подключаться

к нескольким разным провайдерам, то предприятие должно будет заручиться спонсорством Лира. Например, он пойдет к провайдеру номер один, скажет, дорогой провайдер номер один, пойдем вместе со мной в РАЙП, ты мне напишешь спонсорское письмо, я куплю себе адреса, и после этого с этими адресами, с этими номером автономной системы конкретное предприятие сможет уже подключаться к остальным провайдерам и использовать провайдеры независимые адреса. Но для этого им нужно будет использовать, скорее всего, BGP, анонсировать свои IP-шники провайдерам, и дальше провайдеры расскажут уже, что через них можно ходить до этих сетей. В каких случаях эти адреса будут нужны? Если вы предприятие, если у вас мультифом-сеть, то есть вы договорились попириться с провайдерами по BGP, и провайдеры вроде бы как не против. В реальности очень мало провайдеров на самом деле согласны дружить по BGP, потому что это предполагает перенастройку роутеров. Во многих мелких сетях роутеры когда-то давным-давно настроили, были пьяным Васей, и этот Васей давным-давно уже уволился, и на эти роутеры

уже все боятся смотреть. Ну, то есть очень мало кто из провайдеров согласен на самом деле в свои конфиги вносить какие-то изменения. Если мы говорим про IPv4, то у нас есть как бы стандартная практика, что клиенты не назначают напрямую на свои терминальные узлы белые IP-шники. Клиенты назначают так называемые серые адреса или частные адреса. Прописаны эти частные адреса стандартом RFC 19-18, их надо знать на зубок, то есть вот они. Я думаю, что вы их знаете. В IPv6 есть аналог этих самых RFC 19-18, это блок FD00 по 8-й маске, то есть вы берете случайным образом из этого диапазона блок, и назначаете его. Такие адреса выпускать в интернет нельзя. По стандарту вот эти вот адреса выпускать в интернет нельзя, нельзя, нельзя, но если очень хочется, то есть типа NAT. И вот вы эти адреса перебиваете в какие-то белые адреса, которые можно уже будет использовать. Ну, да, предполагается,

что у вас, у вашего провайдера эти самые белые адреса есть, и он NAT для вас будет делать. При этом есть нюанс. Если есть интернет, в котором нельзя иметь такие частные адреса, и есть, соответственно, сетка клиентская, которая неконтролируемая, но, соответственно, мы предполагаем, что там RFC 19, 18 IP-шники есть, и есть между ними еще прокладка. Прокладка это наша провайдерская сеть. Какие адреса мы сможем назначить на клиентскую CPE-шную железку для того, чтобы дальше выпустить их в интернет? У нас же есть еще свои какие-то IP-шники, которые в этой сети фигурируют, да? И получается, что если мы возьмем и скажем, дорогой клиент, мы тебе хотим на внешний твой интерфейс, который смотрит нашу провайдерскую сеть, чтобы потом пакеты из-под этого адреса выпустить в интернет, предлагаем адрес, там, не знаю, 10.1.1.1, у нас возникает конфликт. Возможно, клиент со своей стороны в частной сети тоже захотел использовать такие адреса. И, соответственно, у нас в какой-то момент клиентская железка скажет,

а я не могу адрес 10.1.1.1 перебить в этот 10.1.1.1, потому что у меня вообще получается одинаковые адреса для того, чтобы такой проблемы не было, для провайдеров специально есть сетка для двойного НАТО 10.6400 по 10 маске. То есть вы на клиентские интерфейсы, смотрящие в вашу провайдерскую сеть, не назначаете RFC 19.18 адреса, назначаете, например, 100.100.1.1. RFC 19.18 адреса не пересекаются с этой сетью, дальше отобежит все по вашей провайдерской сети, и на выходе из вашей провайдерской сети пограничный роутер выполняет Career Grade NAT. NAT у нас, соответственно, бывает IPv4 или какой-нибудь другой. Ну, я не буду вам рассказывать про то, что там разные названия у этого НАТО есть, я думаю, что вы это все знаете. Если мы говорим про сегодняшние реалии, то мы никогда не используем никакие типы НАТО, кроме НАТО с перегрузкой, при которой у нас заменяются сокеты

на сокеты. То есть у нас идет пакет, этот пакет содержит в себе либо TCP, либо UDP, либо ICMP. У него есть какие-то идентификаторы, и мы эти идентификаторы будем подменять. При этом подменяем мы пару IPшник плюс идентификатор. Заменяем в этом случае некоторый поднабор частных адресов на один и тот же публичный IPшник. Просто различаем в этом случае с какого идентификатора, на какой идентификатор оно идет. Если это TCP-шные порты, мы говорим, мы в этом случае называем это все дело сокет, мы говорим, вот такой вот там TCP-шный или UDP-шный сокет, мы меняем на такой вот TCP-шный или UDP-шный сокет. При этом частные адреса скрываются, а наружу мы показываем только публичные IPшники. Если мы используем классический IPv4, то мы должны будем использовать НАТО для того, чтобы просто вот эти частные сети, которые традиционно все используют в LAN-сетях, использовать в интернете, чтобы пакеты из этих сетей могли выходить наружу. В таком случае мы будем транслировать IPv4 в IPv4.

То есть у нас есть NAT-роутер. Он с одной стороны получает четвертый пакет, с другой стороны выпускает четвертый пакет. Вот NAT-4-4-4-4 это как раз просто обычный NAT, который мы проходим на сессии. Есть также NAT-6-4. Это не конкретная технология, это как бы стиль работы NAT, при которой он с одной стороны получает IPv6 пакет, а дальше он его транслирует в NAT-64, в IPv4 пакет. Есть еще отдельная технология, которая называется NAT-64, мы про нее дальше поговорим. В каких случаях надо вот такую вот штуку будет делать? Когда у вас есть IPv6-only сетка, вам надо предоставить ей доступ к интернету IPv4. Вот в этом случае вам NAT-64 понадобится. Кроме того, есть специальное обозначение, ну, про carrier-grade NAT я уже рассказал. Это обычный NAT, который ничем не отличается технологически от просто NAT, который выполняется на любом D-link, но он заточен под большое количество сессий. То есть, если мы говорим про крупных провайдеров, которым нужно обрабатывать гигабиты,

десятки гигабит трафика, то пропускать их всех через какую-то маленькую железочку, которая делает NAT, иногда невозможно. Поэтому вот железка, которая умеет специально делать много-много NAT, эта железка будет называться carrier-grade NAT, или он же large-scale NAT. Никаких специальных задач у carrier-grade NAT нет, кроме того, чтобы он мог выжить, если вы на него пускаете много гигабит данных, много-много-много сессий. От чего он, кстати, будет умирать быстрее, от количества сессий или от количества трафика, это спорный вопрос. Есть еще один термин, хитрый NAT 4.4.4.4. Это двойная трансляция, когда у вас есть ЦПЕшная железка. Соответственно, здесь у нас RFC 19.18 адреса. Здесь у нас, соответственно, те самые 164.0.0. Слой 64. Слой 10. Какой 64.

Здесь у нас интернет. Вот в этом случае мы говорим, мы должны будем сделать здесь NAT на клиенте, то есть на клиентской коробочке будет выполняться NAT. Это обычный пользовательский NAT, который не требует никаких специальных наусилий с нашей стороны. Пользователь там в настройках включает галочку и выполняет трансляцию своих частных IP-шников в вот эту специальную серую провайдерскую сетку. После чего от множества, множества, множества этих провайдерских клиентских железок трафик доходит до выхода из провайдерской сети. Здесь есть CGNAT, который транслирует все это дело еще раз. Вот эту вот сетку транслирует в адреса белые, которые пригодны для работы в интернете. Это довольно классическая вещь, и многие провайдеры работают именно на такой схеме. Но при этом у нас дважды выполняется NAT. Некоторые штуки, которые плохо себя чувствуют с NAT, в случае NAT 4.4.4 будут себя чувствовать вдвое хуже, чем с обычным NAT. Ну, то есть сразу всякая телефония, сразу всякие UPnP, сразу всякие

peer-to-peer приложения, они начинают от этого страдать. Далее. Для работы в интернете нам нужен будет DNS. Неважно, IPv4, IPv6 интернет, DNS все равно нужен. То есть у нас есть некое имя, которое мы хотим разрешить, и мы пытаемся понять, это вообще кто. Вот мы должны в этом случае задать вопрос DNS серверу, с вопросом там говорим, мы хотим разрешить там www.networkeducation.ru. Вот это типа кто? Мы ему задаем вопрос, он нам говорит, это адрес, там не знаю, 192.0.2.1. Вот это вот 192.0.1 мы должны получить в качестве результата на вопрос это вообще кто. При этом на самом деле у нас есть отдельный вопрос. Ты знаешь, кто это по IPv4 или ты знаешь, кто это по IPv6? Если мы запрашиваем вопрос и нас интересует результат IPv4, то мы запрашиваем

запись типа А. Это так называемая ресурсная запись или ресурс-рекорд. Если мы хотим получить запись типа А, то мы запрашиваем Ашу и получаем результат. Если мы хотим получить 4-х Ашу, то мы говорим, что нас интересует IPv6 результат. Давайте попробуем показать, как это выглядит в реальности. Так. ns.lookat www.networkeducation.ru Я спрашиваю, и он мне выдает вот айпишники. На самом деле, если я сейчас закажу дебаг, минус D2, мы увидим, что там идут запросы вполне определенных типов. И, соответственно, вот я отмотал до самого верха. Я задаю вопрос... Так, это не то, это не отсюда. Здесь рыбу заворачивали. Вот. То есть я задаю вопрос, типа, скажи мне, кто такой www.networkeducation.ru и дай мне запись типа А. И мне выдается результат.

Я тебе отвечаю, что запись типа А у меня есть. Вот такой вот айпишник или вот такой вот айпишник. У меня, соответственно, два варианта. Ходи на любой из них по своему усмотрению. Дальше. Я на всякий случай спрашиваю, а 4х-ка есть? Он говорит, и 4х-ка есть. Вот, пожалуйста, по своему усмотрению. Вот тебе один, вот тебе второй. Пользуйся, пожалуйста. И весь этот результат складывается в итоге в красивый вывод, что вот это имя резолвится в 4 айпишника. Два айпи в четвертых, два айпи в шестых. Дальше. Если мы хотим запросить у сервера какой-нибудь адрес, мы говорим, скажи мне в www.networkeducation.ru. У нас есть два режима работы. Первый вариант – это итеративный. Второй вариант – это рекурсивный. Обычные клиенты чаще всего заказывают рекурсивный ответ. Это предполагает, что клиент спрашивает, скажи мне в www.networkeducation.ru, и не выдавая мне ничего, кроме конечного ответа.

Дело в том, что это предполагает, что ваш сервер, к которому вы обращаетесь, должен гарантированно сделать всю работу за вас и дальше дать вам уже готовый результат. Он не может от вас отмахнуться и сказать, я сам не знаю, но ты как-нибудь сам разберись. Итеративный запрос – это указание, что вы как клиент готовы, в принципе, сами поработать. Вы спрашиваете у вашего сервера, дорогой сервер, дай мне, пожалуйста, какую-нибудь подсказку, в каком направлении мне надо пойти, чтобы добраться до узла www.networkeducation.ru. И в этом случае ваш сервер сделает максимально, скажем, хорошее действие, которое может привести вас к итоговому результату. Дело в том, что не все сервера знают про все IP-шники, все имена в мире. DNS организован в корневую, в иерархическую топологию, в которой корневые сервера имеют имя «точка», и они имеют хорошо известный список IP-адресов. То есть у вас есть набор адресов, и там вот вы заранее знаете,

что 192.0.2.1, 203.0.1.3.1.2, и какие-то еще IP-шники, это вот будут корневые сервера, они в самой операционной системе, как правило, зашиты. И вы можете обратиться к этим адресам и спросить, а где можно мне найти вот эту вот штуку в VV Network Education.ru. Если вы ничего не знаете о внешнем мире, если вот просто вы абстрактный провайдер, висящий в вакууме, и вы прописали для своих клиентов DNS-сервер, клиент к вам приходит и говорит, скажи мне вот это вот в VV Network Education.ru и дай мне сразу готовый результат. Он от вас требует рекурсивные... он требует рекурсивные действия выполнить и дать ему сразу готовый результат. А вы понятия не имеете, кто такой VV Network Education.ru. Ну, мы пока не настолько известны, чтобы нас прописывали во все операционные системы, во все DNS-сервера статикой. Ну, так вот. Как результат, сервер должен понять, в какую сторону вообще идти. Вот вас поймают за ушко, спросишь, какой IP-шник будет у VV Network Education.ru?

Вы говорите, я понятия не имею. Точно так же и сервер. Он говорит, я понятия не имею, но мне надо куда-то пойти. И вот в этом случае он идет на корневые сервера и задает им вопрос, где мне взять VV Network Education.ru. А корневые сервера, они тоже про всех не знают. Но они знают, что есть вот эти вот самые топ-левел-домены, и есть топ-левел-домен.ru, есть топ-левел-домен.com, есть топ-левел-домен, не знаю, какой-нибудь, не знаю, UA Украина, есть топ-левел-домен Италия.it, есть топ-левел-домен, еду. Ну, то есть все вот эти вот ТЛДшки, они у них прописаны в корневых серверах, и только это и больше ничего. И, соответственно, по каждой зоне есть список ответственных серверов, так называемой записи NS, на им сервер. И когда мы приходим с запросом VV Network Education.ru к корневым серверам, они говорят, мы сами не знаем, но из всех зон, которые у нас прописаны, наиболее похожая на твою, это будет зона.ru, потому что у тебя заканчивается на.ru.

Поэтому ты, пожалуйста, пойди на те сервера, которые указаны там, и посмотри, что там тебе скажут. То есть вот сейчас... Так, это не тот, это не отсюда, здесь рыбу заворачивали. Сейчас я попробую выполнить запрос. И так, как у нас там запрос делается? slookup. Так, минус R, по-моему, VV Network Education.ru, не минус R, минус I. VV Network Education.ru минус D2. Так, не угадал. slookup. Все, пальцы заплетаются. set D2. Но рекурсия. set.ru в курсе.

VVV Network Education.ru. Я задаю вопрос, типа, в какую сторону мне следует пройти, и... и... и... и... так, и что мне возвращается в результате? Мне сразу выдается готовый результат. Мне надо на какой-нибудь сервер пойти, который не знает про это, потому что он закешировал. сервер... не знаю, восьмерки. Так, вот. Мне кажется, вернули как раз какой-то результат, похожий на правду. я запросил VV Network Education.ru без рекурсии, и мне ответили, что сам я не знаю, но ты, пожалуйста, пойди вот куда-нибудь вот сюда вот, вот эта вот страшная штука, и вот эти страшные штуки им соответствуют вот такие вот айпишники.

Я сейчас запросил с Гугла, но вообще по-хорошему мне надо было, конечно, обратиться к корневому серверу и запросить результат с него. Но он бы все равно мне дал NS-сервера в соответствующей зоне.ru для того, чтобы продемонстрировать какие-то сервера. Где у нас nslookup минус q равно ns ru точка. Вот. Это вот корневые сервера. Вернули бы мне вот такой вот результат, если бы я задал им вопрос, типа, где взять VV Network Education.ru. Дальше я бы пошел на вот такой вот сервер и сказал nslookup lookup минус ну рекурсия. Не знаю, сработает, нет. VVV Network Education.ru Он так не хочет. Ну вот он мне сказал, иди куда-нибудь, иди вот на такие вот DNS-сервера и получишь результат.

То есть, опять же, эти сервера, они принимают только итеративные запросы, они не согласны работать по рекурсии, они мне возвращают промежуточные результаты. Network Education.ru А, на ресурсе, да, на рекурсе надо. Но все равно результат получился нерекурсивный. Вот, да. Сейчас ошибки никакую не выдают. Он мне говорит, для того, чтобы обратиться к имени VV Network Education.ru, я сам не знаю, когда этого лучше добраться, но ты вот вот такую вот зону Network Education.ru без VVV можешь получить у вот этих вот двух товарищей. Дальше я уже на эти сервера иду и получаю результат. Вот я обращаюсь к вот этому, например, серверу, говорит, дай мне, пожалуйста, VV Network Education.ru, и он говорит, окей, я сам знаю, как добраться до этого имени, у меня прописаны вот такие вот IP-шники. То есть, с использованием такой иерархической схемы вы можете, даже если не знаете, на какой именно сервер подключиться для того, чтобы получить итоговый результат,

обратиться сначала к корневым серверам, они скажут, я сам не знаю, но иди вон туда, вы идете туда, они говорят, я сам не знаю, но иди вон сюда, и вот так вот рано или поздно вы добираетесь до какого-то сервера, который даст вам авторитативный результат. Это тот результат, который уже не оспаривается. Ну и, соответственно, вот результатом при работе в интернете чаще всего должна быть запись либо А, либо АААА, либо NX-домейн. NX-домейн – значит ошибка, значит, такого домена нет. Если вы работаете с IPv4, то там все просто, если вы работаете с IPv6, то, во-первых, ваш сервер IPv6 должен поддерживать, само собой, то есть вы должны будете слушать 53-й DNS-порт по IPv4 и по IPv6, вы должны будете для клиентов разрешить доступ с рекурсивными запросами, но не очень хорошая идея будет разрешать доступ из интернета, то есть для всех, кроме ваших клиентов, дело в том, что DNS подвержен атаке амплификации, когда коротенький маленький запросик формирует

длительный большой ответ. И DNS работает по UDP, поэтому если вдруг кто-то вам пришлет IP-пакет с поддельным IP-адресом источника, то вы будете на маленькие запросы отвечать большими ответами, и тем самым можно очень легко породить DDoS-атаку на совершенно ни в чем неповинных жертв. Так что DNS публичный, который смотрит на интернет, это в принципе не очень хорошая идея. Вы должны будете использовать такой DNS-сервер, который поддерживает 4х-шки. Более того, вы должны будете убедиться, что все ваши прочие записи могут работать с 4х-шками, то есть, например, вы указываете на им сервер для какой-то зоны, то там должно быть можно указать 4х-шку в качестве результата. Вот. Вы вполне возможно захотите использовать расширение eDNS-0 для того, чтобы получить дополнительные фичи, которые в DNS-е

не были созданы изначально, но потом появились. Одна из главнейших фич, которые eDNS-0 поддерживает, это увеличение размера датограммы до какого-то вменяемого размера, потому что по умолчанию DNS пытается все гарантированно впихнуть в размер IP-пакета, который не будет превышать 576 байт. Тяжелое наследие древних-древних времен. Ну и если вдруг вы выполняете итеративный запрос, то есть не рекурсивный, а как раз итеративный, то, естественно, что вам какой-то из транзитных серверов может вернуться с адресом IPv4. То есть, если вам корневой сервер скажет, что, допустим, зону RU, RU, не RU, не Румынию, Россию, обслуживает IPv4 адрес какой-нибудь, там, не знаю, 192.021, вы в конце хотите получить 4х-ку IPv6, но вы должны будете обратиться к транзитному серверу, который IPv4. Поэтому у вас на DNS-сервере

должен быть доступен интернет и IPv4, и IPv6. если вы будете работать с IPv6 на ваших клиентах, то вы, конечно, должны будете предоставить им доступ к IPv6, это уже сегодня как-то даже не обсуждается, что это должно рано или поздно произойти. Многие провайдеры пока боятся переходить на IPv6, потому что оборудование его у них может не поддерживает, потому что самое главное, администраторы его тоже не умеют поддерживать, типа боятся. На самом деле, ничего страшного в нем нет, это просто новая версия протокола, которая избавлена от некоторых ошибок, которые есть в IPv4. Но в России все-таки пока доля внедрения IPv6 сильно ниже, чем в среднем по миру. Если говорить в среднем по миру, то проникновение IPv6 сейчас порядка 25%, то есть в среднем 25% населения планеты уже пользуется IPv6. Если говорить про количество трафика IPv6, то оно, конечно, пока несколько меньше,

чем четверть всего трафика, то есть, ну, примерно соответствует тем цифрам, которые мы с вами видели на Looking Glass сервере. То есть примерно там в зависимости от конкретного конкретной задачи его может быть порядка 10%, может чуть меньше. Плюс к тому, не во всех провайдерах есть возможность техническое IPv6 обеспечить, потому что не у всех есть стыки с провайдерами, которые готовы подоставлять IPv6. все крупные провайдеры на самом деле уже оплинки IPv6 предоставляют, но вот в некоторых случаях как бы отмазки идут такие, что нам оплинк не дает. Ну, не дает и не дает. если вы предприятие, то вы можете, если вы у себя захотели внедрить IPv6, внедрять его по частям и связывать эти части между собой с помощью каких-то механизмов переходных, туннельных. То есть у вас есть часть, где поддерживается IPv6,

другая часть, где поддерживается IPv6, а вот между ними IPv6 нет. Но в этом случае вы можете построить какие-то туннели и поверх этих туннелей работать по IPv6. эти туннели могут идти через интернет. Каким образом вы можете как провайдер сделать так, чтобы у ваших клиентов IPv6 организовался? Самый простой вариант — это на пограничном устройстве, которое на абонента смотрит, на брасе, сделать и IPv4, и IPv6. Самый простой в том смысле, что оно очевидно, как оно работает. То есть там нет никаких сложностей с точки зрения того, что вы просто говорите, у нас здесь есть IP-адрес, здесь у нас есть IPv6-адрес. Ну, как читается, это все легко. Настройка этого всего понятная, но только она большая, потому что вы в два раза больше работы должны будете сделать. Вы должны будете поддерживать вдвое больше всего на каждом узле. У вас вот здесь какие-то узлы есть, вот здесь какие-то узлы есть, и на каждом из них надо будет поднимать Dual Stack. Здесь поднимайте IPv4, IPv6,

здесь поднимайте IPv4, IPv6, здесь поднимайте IPv4, IPv6. Везде на всех интерфейсах, которые смотрят на абонентах, вы должны будете фильтры вешать и IPv4, и IPv6. То есть это двойная работа. DualStack в этом смысле не очень приятен, именно потому что слишком много действий приходится делать для того, чтобы его реализовывать. Поэтому у провайдеров он не очень популярен. Вы вынуждены будете набрать, скорее всего, DualStack поднимать, никуда от этого не деться, за редкими исключениями. Но дальше, что происходит внутри вашей сети, там, как правило, у вас работает только один протокол. С очень большой вероятностью, если вы работаете с сетью, которая уже построена и была задизайнена лет 10 назад, то внутри у вас бегает только IPv4, а IPv6 бегает просто как сервис в своего рода VPN. А в случае, если вы дизайните новую сеть, в принципе, вы можете рассмотреть вариант, при котором у вас будет работать чистый IPv6, и IPv4 будет бегать уже как сервис, ну и IPv6 тоже клиентский, будет тоже бегать как сервис.

IPv6 при этом у вас будет в самой сети ядра использоваться как основной underlay протокол. не все оборудование корректно с этим работает, поэтому сегодня провайдеров, которые использовали бы такой вариант, крайне мало. Ну, то есть это какие-то очень крупные ребята, типа Deutsche Telekom, они могут себе пилотные проекты позволить, которые покажут вообще, насколько отрасль к этому всему готова. Ну, пока что именно в провайдерской отрасли чистые IPv6 в сети ядра пока встречаются не очень часто. Если говорить про технологии, которые можно использовать для вот этого переходного сценария, когда у нас кое-где кое-что есть, но не везде есть и то, и другое, то самый простой вариант, что можно сделать, это построить статический туннель. Обычно эта штука используется предприятиями, когда у нас здесь есть предприятие, там, не знаю, одна, один филиал, здесь у нас другой филиал, два пограничных роутера, которые смотрят в интернет, поверх интернета они строят туннель. Ну, все понятно, как это работает,

но для провайдера здесь ничего интересного нет. Провайдеры такого рода туннели строят крайне редко. Если использовать туннелирование, то используются два основных варианта, чего можно затуннелировать и как можно это затуннелировать. Если мы используем IPv6 и хотим перегнать его по IPv4 сети, то есть либо вариант 6-in4, когда вы берете IPv6 пакет и оборачиваете его сразу IPv4 заголовком, при этом указываете код вложения 4. То есть там, где у нас в поле, что внутри лежит, например, TCP будет 6, ICMP будет 1, UDP будет 17, а вот если четверка будет, значит это... Ой, простите, 41. 41, значит это IPv6. 4, это значит другой IPv4 заголовок. 4 на 4. Второй вариант это ГРЭ. То есть у вас есть IPv6 пакет, вы его оборачиваете ГРЭшным заголовком, IPv6, дальше ГРЭ и дальше IPv4.

В случае с ГРЭ есть дополнительный заголовок, но он в некоторых случаях будет облегчать жизнь, потому что он позволяет внутри себя вложить совершенно произвольные вложения. Если у вас есть как раз сценарий вида 2 роутера, которые на границе с интернетом строят между собой туннель для того, чтобы два филиала связать между собой, чаще всего используется именно ГРЭ, потому что он позволяет и IPv4 внутри себя запихнуть, и IPv6, и все на свете. Если мы говорим про то, что мы провайдер и хотим с помощью туннельных технологий помочь нашим клиентам получить доступ к IPv6, чаще всего провайдеры скажут, что ГРЭ нам не хочется использовать, тем более, что он через НАТО хреново проходит. В этом случае они скажут, давайте использовать тогда IPv4 и потом сразу IPv6 без каких-либо транзитных заголовков. Динамические туннели могут позволить клиенту подключаться к IPv6 даже без помощи провайдера. Может помощь провайдера быть, может ее не быть, но, соответственно, это вот клиент хочет подключиться к интернету,

сидеть на попе ровно не может, и начинает какие-то действия совершать, даже несмотря на то, что провайдер доступ к IPv6 не предоставляет. Самый простой вариант, что можно сделать, это построить статический туннель с известным брокером. Это у нас либо какой-нибудь, не знаю, из российских IPv4 market, либо это может быть Hurricane Electric, туннельbroker.net, ну, то есть вам в этом случае указывают, какой IP-шник использовать в качестве другого конца туннеля, от вас требует белый IP-адрес, откуда вы будете строить туннель, и в этом туннеле у вас начинает работать IPv6 и выпускает вас в интернет. Примитивно простая штука, я даже ее сейчас рассматривать не буду. Второй вариант — это динамические туннели, когда вы будете отправлять трафик в IPv4 интернет, и оно само как-нибудь построит вам туннель с кем-нибудь, заранее неизвестно с кем. Давайте посмотрим на каждый из этих механизмов, которые будут предоставлять нам построение динамических туннелей в разрезе. Самый первый вариант —

это механизм 6-2-4. 6-2-4 — это не 6-in-4, не путайте. 6-in-4 — это мы берем IPv6 пакет и оборачиваем его IPv4 заголовком. Вот это 6-in-4. А 6-2-4 — это технология, которая использует инкапсуляцию 6-in-4 и указывает, каким образом заполняются поля вот в этом вот в 4-м заголовке. Если вы хотите выпускать пакеты в интернет, вот у вас есть какой-то компьютер, у вас есть роутер, вы хотите организовать в вашей частной сети IPv6 взаимодействие, вы используете для вашего частного взаимодействия сеточку, которая начинается на 2002. Дальше. У вас за вот этим роутером сетей IPv6, возможно, будет несколько. Поэтому по стандарту предполагается, что в этом случае на роутер выделяется сетка slash 48. Вот как получить 48-ую сетку для взаимодействия 6-4. Вы должны будете знать свой белый IP-адрес.

Если у вас белый IP-адрес, например, 10-0-0-1, в 16-ти речном виде он записывается как 0-A-0-0-0-0-0-1. Вот вы берете запись вашего белого IP-шника в 16-ти речном виде, приклеиваете его к 2002 и получаете 6-4-сетку, которая закреплена за вами, как за обладателем белого IP-шника. Соответственно, все пакеты, которые вы должны будете выпускать, вы должны будете выпускать из-под IP-шника 10-0-0-1, и они должны будут содержать в себе IPv6-ые пакеты, которые идут из-под 2002, дальше вот 10-0-0-1 инкапсулированные в качестве адреса источника. В этом случае пакеты, которые будут приходить обратно, они будут приходить именно на ваш белый IP-шник. Что здесь можно будет заметить? Если вы используете такую схему инкапсуляции, вы должны будете использовать адрес источника

для вот этих белых IPv4-пакетов, тот, который у вас указывается, то есть вы используете 10-0-1, на самом деле, конечно, не 10-0-1, у вас будет публичный IP-шник 192-0-2-1, вот вы в этом случае говорите, 192-2, это у нас 128-64-C0-0-0-0-0-1. Вот такой вот адрес вы используете в качестве публичного адреса, только 2-0-2-0-1. И, соответственно, у вас, ваши пакеты IPv6-ые должны идти не из-под 0-0-0, а C0-0-0-0-2-0-1. Вот у вас конструируются IPv6-ые адреса, которые соответствуют вашему публичному IP-шнику. Вы будете выпускать такие пакеты из-под хорошо понятных 604-адресов на те адреса, которые вы хотите в итоге, до которых хотите достать. Такие пакеты с клиента

уходят на 604-роутер, 604-роутер оборачивает их заголовком, в качестве адреса источника прописывает свой вот этот белый адрес источника. В качестве адреса получателя прописывает хорошо известный адрес 192-88-99-1. Это единственный зарезервированный Unicast Anycast в IPv4. Anycast 604-ролый адрес. То есть такие узлы, которые выполняют преобразование 604, из IPv4-ых пакетов извлекают от IPv6-ое вложение, направляют дальше в IPv6-ой интернет, их много. И те узлы, которые выполняют такую операцию, они в BGP просто вбрасывают вот этот вот префикс 192-88-99-1. Пакеты IPv4-ой направляются в интернет, они доходят до ближайшей точки, которая выполняет обратное преобразование, то есть просто доходят до ближайшего узла, который анонсирует вот такой вот IP-шник. Дальше этот узел берет как получатель

192-88-99-1 трафика, у него этот IP-шник прописан 192-88-99-1. Он открывает такой пакет, видит внутри IPv6-ое вложение и направляет его в интернет. Дальше обратные пакеты, которые будут идти, они будут идти на 2002, дальше там кракозяблики какие-то, они после того, как дошли до конечного получателя, дальше обратные пакеты идут на 2002, чего-то там, они доходят до какого-то другого, 6-104-узла, который находится ближе к IPv6-ому изначальному отправителю этих пакетов или оригинальному получателю, и они заворачиваются в IPv4. До какого именно IPv4-ого IP-шника надо будет завернуть, они вычленяют это как раз из IP-шника получателя. И дальше пакет по IPv4 опять же бежит на ваш роутер, на тот самый 192-0-2-1 IP-шник белый, ваш публичный, который есть. Пакеты раскрываются

и отправляются дальше в сеть получателя. Эта штука не дублируется с обычными IP-шниками, потому что у IPv6-ых адресов вот этот диапазон 2002 по 16-й маске зарезервирован за 6-104. Его нельзя просто так получить. Вот. Ну и, соответственно, вот так вот оно работает. Оно так вот вас позволяет выпустить в IPv6-ой интернет. Штука интересная, штука почти всегда неплохо работающая, но она, к сожалению, не позволяет контролировать качество доставки трафика, потому что вы не можете узнать, где находится ближайшая к вам входная нода 6-104. Равным образом вы абсолютно не можете проконтролировать, где находится выходная нода 6-104 и входная нода для обратного трафика. Поэтому к сожалению, эта штука, она не очень стабильная, скажем так, но она очень простая в настройке. Вы просто создаете туннель, указываете в качестве

адреса получателя 192.88.99.1 и обладая белым публичным IP-шником можете прекрасно работать. Если говорить про дальнейшее развитие этой идеи, которая избавлена от недостатков с непредсказуемыми задержками, к невозможности контролировать выходную нода, то, соответственно, следующая идея, которая получилась из 6-104 будет называться 6RD. Это 6RD Rapid Development называется. Это RD. Заключается оно в следующем. Точно то же самое, что и в 6-104. Все работает, но 6RD роутер, вот эта вот входная нода для трафика, она будет контролироваться провайдером. То есть провайдер для своих абонентов говорит, я вам поднял ноду 6RD роутер, указывает ее IP-шник публичный и, соответственно, вы на своем, пардон, вот этот вот вот этот вот IP-шник указывает и говорит, пожалуйста,

заворачивайте весь трафик на 192, 168, 10, 10, то есть ставьте туннель до этого самого IP-шника и в этом самом IP-шнике на этот IP-шник посылайте IPv4 трафик, содержащий в себе IPv6 пакеты. Дальше, для того, чтобы внутри сети можно было понять, от кого какой пакет пришел, вы должны будете использовать IPv6 адреса из выданного вашим провайдером префикса, который в себе будут содержать либо целиком IP-шник ваш как клиента, либо только его часть. Ну, то есть вам провайдер указывает, по какой схеме надо будет использовать IP-адресацию. Например, он вам выдает всем клиентам своего 6RD, говорит, берете префикс 2001 DB8 и дальше к вот этому префиксу по 32 маске добавляете вторую половинку вашего IP-шника клиента. Вот. Если у вас IP-шник клиента 192-168-10-10,

то есть вы знаете свой IP-шник внутри сети, вы говорите, окей, вот это вот 192-168-10-10, от него отрезаем вторую половинку, потому что у всех 192-168 одинаковая, и получаем 0A-0A. Поэтому мы берем 2001 2.DB8 2.0A-0A slash slash 48 и получаем свою собственную отдельную IP-шную сеть, которую мы можем использовать. Вы знаете, с какой стороны будет находиться ваш ваша нода 6RD. Вам IP-шник провайдер выдал 192-168-111 для того, чтобы вы на него строили туннель, но при этом сама нода 6RD нигде не указывает, что вот есть отдельно вы со 192-168-10-10, отдельно там Вася со 192-168-20-20, отдельно там кто-то еще. То есть все эти клиенты для нее одинаковые, и она позволяет делать стейтлесс преобразование IPv4 пакетов, содержащих IPv6 вложение, в нативное IPv6 вложение.

Когда пакеты приходят обратно, они приходят обратно на ноду 6RD нативно, то есть это контрольное вашему провайдеру нода, идет обратное преобразование. Вы, как провайдер, заворачиваете IPv6 пакеты в IPv4, вы вычленяете вот эту вот часть из IPv6 адреса, приклеиваете к ней 192-168-10-10 и отправляете дело по IPv4 сети. В какой ситуации эта штука может быть полезна? В случае, если вы провайдер, вы имеете стык с IPv6 интернетом, ваш пограничник поддерживает IPv6, но ваша внутренне провайдерская сеть не поддерживает IPv6 вообще никак. То есть, ну вот вы используете какое-то старое железо, и у вас вообще никак нет доступа к IPv6, вы не можете его предоставлять вообще. А очень хочется. Вот в этом случае вы говорите, окей, дорогие клиенты, нативного IPv6 у вас не будет, но 6RD мы вам даем. Пожалуйста, используйте. Если провайдер не дает доступа никакого,

ни 6.2.4 не работает, потому что за NAT-ом все серые адреса, ни 6RD он не дает, потому что козел сраный, ой, простите, ну бывает такое. В этом случае вы можете все равно воспользоваться доступом к IPv6. Для этого используется хитрая технология, которая называется Tereda. название этой технологии пришло из латинского названия корабельного червя, Tereda Навалис, который жил в дереве и очень сильно напрягал моряков в средние века, потому что корабли тогда строились из дерева, и если вдруг вот этот вот червячок залезал в дерево, он любую совершенно древесину проковыривал насквозь. Это червяк, у которого на голове специальная раковинка, и эта раковинка, он, этот червячок использовал как такой бур. И вот он пробуривал любую совершенно древесину, и, соответственно, у вас внезапно в корабле образовывалась дырка, за что этот червячок традиционно был нелюбим моряками. Так вот, Tereda — это протокол, который точно так же

проковыривает любую провайдерскую сетку, за что традиционно нелюбим провайдерами. Строится он, строить он будет туннель от конечного абонента, от конечного терминального узла абонента, то есть это, если у клиента здесь CPE, и вот здесь дальше конечный компьютер, значит, конечный компьютер будет строить туннель с интернетом. Для того, чтобы эта штука работала, нужно будет иметь где-то в интернете, неважно где, Tereda сервера, они не под контроль на провайдеру, и туннели будут строиться поверх UDP, то есть UDP прекрасно проходит NAT, UDP можно использовать за серыми адресами, и для работы с Tereda используется хорошо известный префикс 2001.0.32, то есть если вы видите адрес, начинающийся на 2001.0, чего-то там, то это вот адрес как раз Tereda. Внутри IPv6 адреса, точно так же, как в случае с 6.4.6.rd, будет использоваться

информация, как из IPv6 IPшника получить IPv4 адреса, ну и эта информация будет там немножко закодирована, она будет известна как раз Tereda серверу, то есть трафик из компьютера абонента доходит до Tereda сервера, дальше Tereda сервер достает IPv6 пакеты и отправляет их в интернет, дальше потом трафик из интернета приходит на, возможно, какой-то другой Tereda сервер и отправляется на абонента. Для того, чтобы это все работало, вы должны будете на клиенте указать, какой именно Tereda сервер вы будете использовать, то есть для того, чтобы это работало, между теми серверами, которые будут входной и выходной, должно быть репликация состояния, должно быть указание, на какой именно IP-шник клиента нужно будет заворачивать IPv4 пакеты. Если использовать, к примеру, операционную систему Microsoft, то там штатно тередовские туннели строятся, то есть даже если вдруг вы просто достаете

компьютер из коробки, на нем только IPv4 поднимается от провайдера, тередовский туннель там все равно строится до сервера Microsoft. Вот, например, вот такое вот имя используется штатно по умолчанию в некоторых операционных системах Windows. Вы, как провайдер, внезапно понимаете, что у вас компьютеры клиентов имеют доступ к IPv6, хотя вы, как провайдер, доступа к IPv6 не предоставляете. То есть вот оно само автоматически все делает. Особенно это прикольно осознавать сотрудникам предприятия, особенно администраторам сетей предприятия, которые понимают, что их компьютеры, за которые они должны нести ответственность, которым доступ к IPv6, в общем-то, не предполагается, внезапно имеют этот самый доступ к IPv6. Ну, то есть там в этом IPv6, может быть, не все можно делать, но всякие фейсбучики, например, начинают открываться. По умолчанию во многих операционных системах приоритет доступа через Тереда ниже, чем приоритет доступа по IPv4, то есть обычный IPv6, нативный, он более приоритетный,

чем IPv4, а вот Тередовский IPv6, он менее приоритетный, чем IPv4. Но, тем не менее, да, если вдруг у вас нигде ничего не открывается, все заблокировано, а внезапно начинают открываться всякие фейсбучики, это вот как раз он. Как можно Тереда регулировать, если вы провайдер? Никак. Ну, то есть, провайдеру обычно не надо с ним ничего делать. Единственное, что, ну, как это, просто какой-то трафик, который ходит. С точки зрения законодательства никто не заставляет вас, вашим клиентам, допустим, вашим кастоверам, пользователям расковыривать Тередовские сессии и, допустим, вычленять из них запрещенную информацию. То есть, пока нету обязательств у провайдеров расковыривать вообще весь трафик, который передается по сети, даже если он там затуннелирован, зашифрован, и выискивать там кусочки чего-то запрещенного. Но если вы сотрудник предприятия, вы администратор предприятия, вы, конечно, должны будете знать, что такая штука существует. И, как правило,

стандартные настройки Тереда, они хорошо известны. Это UDP и, ой, и 3544 порт. То есть, вот сервер работает обычно именно по этому порту. Если вы догадываетесь, что ваши клиенты сами ничего не делали, никакие настройки Тереда не задавали, то вы можете вот такой вот порт закрыть на Firewall, и тогда Тереда у вас работать не будет. Но, опять же, если у вас окажется хитропопый клиент, который захочет все-таки Тереда включить, он может у себя, допустим, где-то на внешнем компьютере, во внешнем мире поднять свой Тереда-сервер, и из сети предприятия подключаться именно к нему. Ну, да, то есть, это уже такой отдельный разговор. Технологии, которые старые, это 6 over 4 и Setup. Они обе используют конкурсуляцию 6 in 4, обе создают виртуальный интерфейс, и они позволяют делать следующие вещи. У вас есть компания, у нее есть один кусочек

IPv6, есть другой кусочек IPv6, оба кусочка IPv6 сети подконтрольны вашей компании. И, соответственно, они связаны между собой через IPv4 сеть. Вот как сделать так, чтобы узлы в одном кусочке IPv6 сети связывались бы с другим кусочком IPv6 сети? Вот. 6 over 4, древняя технология, которая использовала следующую штуку. Она поднимала туннель и говорила, вот мы сейчас построим туннель, этот туннель будет использовать в качестве IP-шника и источника наш белый публичный IP-шник, а в качестве, соответственно, IP-шника назначения мы будем автоматически узнавать, где брать, где брать Next Hop для определенных IPv6 адресов. В этом случае вы орали на всю сеть мультикастом, специальным мультикастом, типа у кого из вас за вашей спиной IP-шники IPv6, вот такие вот, отзовитесь. Внутри сети предприятия эта штука предполагала,

что у вас мультикаст будет передаваться и узлы, которые действительно обладают определенными IPv6 адресами, которые поддерживают 6 over 4, они бы вам ответили бы юникастом, что ты тут только что орал, у кого из вас IP-шники IPv6 за спиной вот такие, пожалуйста, ходи ко мне. 6 over 4 позволял вам использовать link-local адреса FE80 по 96-й маске, то есть это фактически link-local адреса, но и последние 32 бита у вас были IPv4 адреса next-hopов, то есть если вы заранее знали, на какой именно IP-шник вы собираетесь отправить трафик в IPv4, то вы можете этим адресом пользоваться, но если вы не знаете, то вы хотите понять, до кого надо достучаться будет, вот в этом случае вы будете использовать NeighborDiscovering. поверх мультикаста. И Setup примерно так же работает, то есть он тоже будет иметь некий интерфейс, у него тоже будут за спиной

находиться IPv6 кусочки сети, и он будет головой смотреть в IPv4 сеть, но для того, чтобы понимать, какие у него в принципе соседи бывают, и соответственно, какие IPv4 айпишники в принципе способны за своей спиной иметь какие-то IPv6 адреса, чтобы, например, там, не знаю, поверх этого всего дела построить BGP сеть, или OSPF, или что-то еще. Вот в этом случае и Setup не использует мультикаст, он использует запрос по DNS, просит ресурсную запись и Setup example.com ашку, обычную ашку. И в этом случае, если такая запись существует, то есть если мы говорим, у нас вот здесь вот узел а.example.com вот, и здесь у нас узел b.example.com вот они оба понимают, что они используются и company example.com вот, они оба этих узла принадлежат к сети example.com, они идут на свои прописанные

DNS сервера и говорят, скажите, пожалуйста, вот такую вот запись и Setup.example.com система возвращает список IPv4-х адресов всех и Setup нод. То есть она говорит, вот здесь вот у нас есть нода, вот здесь у нас есть нода, вот здесь у нас есть нода, и мы, получив список всех IPv6-х нод и Setup нод через DNS, мы дальше проверяем, отправляем router solicitation unicast на указанные адреса и проверяем, доступны ли там действительно и Setup ноды или нет. Ну и после чего можно уже и USPF построить. Недавно был случай, когда компания Provider не знала о том, что существует вот такая вот штука и Setup. Она разрешала своим пользователям по своему имени домена, ну там был домен, ну тоже, допустим, example.com

или company.com, она разрешила пользователям регистрировать регистрировать в DNS имена в своем домене. И, соответственно, нашелся умник, который зарегистрировал имя и Setup, ну там company.com. Ну, соответственно, на компьютер этого умника начали ломиться все операционные системы, у которых тоже были прописаны соответствующие DNS-суффиксы и спрашивать, не знаешь ли ты, как добраться до и Setup. ну, соответственно, он некоторое время по, как бы это сказать, побакланил, а потом начал отвечать адресами, на которые следует обращаться для того, чтобы постучаться по этому самому Setup. Ну, очень быстро сетка от этого у клиентов, которые пытались такое делать, стала работать очень плохо. Ну, закончилось все это скверно. Ошибка провайдера в этом случае заключалась в том, что вот такие вот имена, как и Setup, как некоторые другие технологии, которые тоже используют обнаружение через DNS, надо просто знать,

какие технологии используются по умолчанию во многих операционных системах и не давать регистрировать подобные имена. И уж, наверное, совсем плохая идея позволяет пользователям регистрировать имена DNS в своем домене. Вот. Если вы работаете с текущей сетью, скорее всего, у вас сеть сейчас IPv4, и IPv6 вы поверх нее предоставляете как сервис. Будущее интернета, скорее всего, будет заключаться в том, что сети будут строиться только поверх IPv6, то есть у вас будет Underlay IPv6, поверх которого будут передаваться всякие разные сервисы, либо в MPLS, либо в чем-то еще. Сегодня оборудование, которое бы позволяло строить MPLS поверх IPv6, есть, но в нем не позволяют строить трафик-инжиниринг-туннели с помощью RSVPTE. Это, в общем, довольно важная фича, поэтому сегодня чистых IPv6 провайдерских сетей, как уже было сказано, не очень много. Но я думаю, что скоро это изменится, скоро появится и RSVPTE

для IPv6 в массах, и, в общем-то, новые провайдерские сети можно уже будет строить чисто по IPv6. В принципе, учитывая недостаток IPv4 адресов, можно будет предполагать, что следующие, скажем, 10 лет пройдут под знаком давайте клиентам не будем давать IPv4 адреса, благо они дорогие, и, в общем-то, клиентам по большому счету не нужны. Можно использовать технологию перехода, давать клиенту только IPv6 адреса, но дальше с использованием черной магии сделать так, чтобы эти клиенты могли обращаться к ресурсам, которые в норме доступны через IPv4. Здесь можно будет упомянуть три механизма. Это два очень похожих друг на друга механизма NAT-PT и NAT-6.4 и 4.6.4 xLAT. Давайте разберем их все детально. NAT-PT это старая технология, которая заключается в том, что у вас есть роутер, который выполняет преобразование IPv6 адресов в IPv4. Для того, чтобы отправлять пакеты с чистого

IPv6 узла на сервер, который IPv4 вы используете некий хорошо известный префикс, допустим, fdf 2.2 и дальше в конце этого самого префикса вы указываете закодированный IPv4 адрес. Кстати, если вы используете такую схему, когда в конце IPv6 адреса у вас будет IPv4 адрес, есть нотация, которая позволяет записывать IPv6 адреса не вот в такой форме, когда мы используем 8 групп по 4 разряда разделенных 2.2. А вот тот же самый адрес можно записать как fdff 2.2 10.0.0.1 Это не процент, это два двоеточия. То есть, если вот вы хотите, вы можете последние два две 16-ричные группы записать в виде просто обычного IPv4 адреса. Такое разрешено. Это штатная разрешенная форма записи IPv6 адреса. Если вы отправляете пакет на такой вот адрес, роутер с NAT будет понимать,

что такие IPv6 пакеты надо переделать в IPv4. То есть, если там внутри лежит TCP или UDP, они, в принципе, плюс-минус километр одинаково работают что поверх IPv4, что поверх IPv6, поэтому голову IPv6 мы отрезаем, вместо нее приклеиваем новую IPv4 голову, IP-адрес источника мы вычленяем из адреса IPv6 назначения, простите, IPv4 адрес назначения мы вычленяем из IPv6 адреса назначения, IPv6 адрес источника теряется при этом, IPv4 адрес мы переделываем в какой-нибудь. Понятное дело, что это будет все stateful, то есть нам нужно будет иметь табличку трансляции, в которой мы скажем, что мы FD002 в точь единицы переделали в 10.002. Ну и потом наоборот надо будет трафик вернуть тоже. Работает это все примерно как в IPv4, то есть мы IPv6 пакет взяли, переделали в IPv4, но фактически что там, что там, у нас есть inside-local, outside-local адреса, и отличие обычного

NAT от NAT-PT будет заключаться только в том, что у нас inside-local и outside-local адреса будут IPv6. Ну и в outside-local адресе, который будет перебиваться в outside-global, у нас будет адрес, содержащий в себе 32 бита outside-global адреса. Чтобы эта штука работала, вам недостаточно просто поднять сам NAT-PT. Вам потребуется также сказать, что у вас на этом роутере будет работать DNS-ILG. как-то криво написал. Короче, это штука, которая будет отслеживать DNS-запросы через себя, и если она будет видеть, что запросы DNS-а идут на какие-то четырех-ашки, она будет их переделывать в ашки. То есть, если вдруг мы видим запрос на www, там, не знаю, условно, google.com, и мы пытаемся резолвить это имя, и мы понимаем, что это имя не резолвится в четырех-ашку, значит, мы должны попробовать ашку зарезолвить самостоятельно, не от имени клиента, а от имени NAT-PT-Router, и вернуть результат клиенту. То есть, мы должны будем

вмешиваться в работу DNS-а, и главное, мы должны будем убедиться, что все запросы от клиентов по DNS-у идут через NAT-PT-Router. То есть, нельзя будет сделать так, чтобы где-то в стране у нас был DNS, на который обращается наш клиент, и он не проходит через NAT-PT. В этом случае NAT-PT работать не будет. Развитие этой идеи заключается в том, что DNS-сервер мы таки выносим наружу, но мы для того, чтобы это все работало, используем специальный механизм работы DNS-а. То есть, мы сделаем специальный DNS-сервер, который будет для клиентов возвращать правильные результаты, и если вдруг клиент обращается за каким-то именем, который он пытается понять, как к нему можно достучаться по IPv6, DNS-64 сервер, это такой специальный DNS-сервер, он сначала пытается резолвить 4-х-шку, а потом, если ему не удается 4-х-шку зарезолвить, он резолвит а-шку и кодирует результат в том виде, чтобы клиент мог обратиться на NAT-6-4 роутер,

не NAT-6-4. Работает это вот как, вот каким образом. У нас есть компьютер, компьютер обращается по имени, говорит DNS, скажи мне, где WV Network Education Rule. DNS-64 сервер, пытается спросить, где у нас такая 4-х-шка. Ему возвращается NX-домейн, говорит, нету такого. Он говорит, окей, а а-шку скажи такую. Ему говорят, вот тебе а-шка, вот тебе IPv6 какой-то там какой-то вернулся. DNS-64 сервер, говорит, окей, я сейчас приделаю к вот этой вот, к IPv6, который мне вернулся к а-шке, хорошо известный суффикс 64, двоеточие, ff9b, два двоеточия по 96-й маске. И, префикс, простите, не суффикс. Префикс берет, дальше приклеивает к ней IPv4-й а-шник и выдает его в качестве 4-х-шки клиенту. То есть он, как полноценный нормальный сервер на рекурсивный запрос отвечает конечным результатом. Клиент говорит, скажи мне имя 4-х-шку

Network Education Rule. DNS-64 сервер говорит, ты просил 4-х-шку, я тебе вернул 4-х-шку. Но внутри этой 4-х-шки закодирован IPv4-й адрес. После чего клиент направляет поток, ну не поток, а запрос, например, там, типа син-пакет на NAT64 роутер. Он может его просто пустить в интернет, типа в IPv6, но такой пакет проходит через NAT роутер. NAT роутер видит, что пакет идет на хорошо известный префикс. Он его открывает, видит внутри какое-то вложение, допустим, TCP, UDP, делает то же самое, что и NAT PT. Но, соответственно, NAT роутер уже при этом не вмешивается в работу DNS. Он открывает заголовок IPv6, видит там IPv4-й адрес вложения, выкидывает IPv6-й заголовок, делает IPv4-й и направляет его в интернет. Схема работы с точки зрения перебивки адресов точно та же самая, что и у NAT PT, но при этом не требуется

вмешательства в DNS на роутере NAT. На роутере NAT64. Эта штука намного более стабильная, и если вы хотите реализовать взаимодействие для ваших клиентов IPv6-only, чтобы они имели доступ к IPv4-му интернету, вы поднимаете DNS64 и вы поднимаете NAT64. так, далее, далее, далее, далее, далее. Вот как эта штука работает. У нас есть клиент, который чистый IPv6-й, он говорит, скажи мне, как добраться по IPv6 до некоторого узла, обращается к DNS-серверу, к своему специальному DNS-серверу. Специальный DNS-сервер говорит, я сейчас попробую, подожди секунду, обращается к своему следующему DNS-серверу в цепочке, может быть итеративно, может быть рекурсивно, говорит, дай мне, пожалуйста, 4х-ку, example.com, мне она очень нужна. В итоге выясняет, что такого домена нету, 4х-ки нету, то есть узел, к которому обращается в 6-ой клиент, не доступен по IPv6, доступен только по IPv4.

Как следствие, он говорит, окей, скажи мне тогда ашку, получает результат, кодирует вот это вот 203.013.1 внутри IPv6-го адреса с хорошо известным префиксом и возвращает результат 4х-ку с указанным IP-шником. Дальше клиент поднимает с указанным IP-шником сессию, но при прохождении через NAT-роутер IPv6-ые пакеты превращаются внезапно в IPv4 и дальше бегут уже из-под IPv4. Эта штука требует отслеживания трансляций, ну и чаще всего, если мы используем именно вариант с отслеживанием трансляций, по нагрузке на роутере эта штука довольно такая серьезная. Нам все время потребуется, опять же, достаточно тяжелое железо. Ну, в таком сценарии вам потребуется достаточно мало IPv6-ых адресов, в смысле, достаточно мало IPv4-ых адресов, вам достаточно будет иметь только некий пул белых адресов на вашем NAT. Почему NAT-PT? NAT-6-4.

Вот. Если мы используем NAT на роутере, преобразование IPv6 в IPv4, NAT-6-4, то это можно сделать в принципе и стейтлесс. То есть, если у вас есть достаточно много белых IP-шников, если вы в свое время где-то раздобыли много белых адресов, вы можете сделать стейтлесс преобразование. Вы указываете, что у вас inside global address, то есть, откуда трафик идет, будет кодировать в себе, простите, inside local address, откуда трафик идет из IPv6, будет кодировать в себе inside global address. То есть, у нас есть клиент, он говорит, я отправляю IPv6 пакет, и в этом пакете у нас адрес назначения, естественно, кодируется, в нем IPv4 адрес назначения, и, соответственно, можно точно так же кодировать и IP-адрес источника. Если вы это делаете, у вас в IPv6 пакете и в адресе источника, и в адресе получателя будут содержаться

IPv4 адреса, которые нужно будет для того, чтобы трафик доставить до конечного абонента, ну и, соответственно, вернуть трафик обратно. Тоже можно будет до именно этого абонента. Но для этого потребуется взаимно однозначное соответствие между публичными IPv4 и внутренними IPv6 адресами. Штука очень быстрая, она алгоритмичная, но, соответственно, она требует большого количества адресов, поэтому в реальности у нее есть как бы сложности с ее использованием. Чаще всего взаимодействие ведется через Stateful NAT64, который работает точно так же, как NAT IPv4, то есть он может брать сокеты IPv6 и преобразовывать их в сокеты IPv4 с одинаковым IPv4 адресом. Для того, чтобы эта штука работала, взаимодействие может инициироваться только узлом IPv6. То есть нельзя будет из IPv4 интернета отправить какой-то пакет на NAT64 роутер,

и чтобы он это преобразовал в сторону клиента, транслировал обратно. То есть инициировать трансляцию должен клиент. Ну и таблицу трансляции в этом случае тоже придется ввести. Эта штука нагружает роутер очень сильно, но, тем не менее, это практически единственный вариант, как можно сегодня организовать взаимодействие, если у вас нету большого количества IPv4 адресов. Что касается вот этого префикса 64ff9b по 96 маски. Почему именно он выбран, почему не какой-то другой? Если используется вот такой вот странный префикс, он, обратите внимание, не global-unicast, то есть его выпускать в интернет нельзя. Он будет нейтральный с точки зрения алгоритма интернет-чексам. То есть если у вас есть TCP, который вложен в IP, вот у вас IP-заголовок, потом TCP-заголовок, потом какие-то данные. Вот, и все это бежит по сети. Вот оно проходит через роутер, IPv6 преобразуется в то же самое, но IPv4. То есть дата,

дальше у нас там TCP, и дальше у нас IPv4. Так вот, внутри заголовка TCP-шного у нас будет храниться чексума от псевдозаголовка. Если вы меняете IPv6-й заголовок на IPv4, у вас чексума, интернет-чексам не портится. Фишка в том, что чексума считается от IP-адресов отправителя-получателя, если вы используете IPv6-е адреса, содержащие в себе IP-шники, неважно, отправители или получатели IPv4, и приклеиваете к ним вот этот вот префикс, то, соответственно, чексума от этого не меняется. Что вы сделаете это один раз, что вы сделаете это два раза, код вложения не поменяется, там указатель на протокол, то есть чексума от того, что вы используете вот этот вот префикс, не меняется, как следствие оборудование ваше нагружается несколько меньше. Вы можете использовать другие префиксы, если захотите, но при этом, естественно, оборудование чуть-чуть будет посложнее.

Каждый раз, когда пакет будет транслироваться, помимо того, что он будет транслироваться, ему нужно будет еще пересчитать чексуму. Дополнительно к тому нужно будет преобразовывать ICMP-шные сообщения, то есть если у вас идет сообщение типа, там, не знаю, ICMP их реплай, там все просто, его преобразовать из ICMP-IP4 в IPv6 можно легко, но в некоторых случаях там будут проблемы, как преобразовывать IPv4-ICMP-шные сообщения в IPv6-ICMP-шные сообщения для выполнения трансляции. То есть, если вдруг вы отправили EDP-шную датограмму, она пришла до получателя, и получатель отправляет ICMP-шные сообщения PortUnrichable, то есть, в этом случае вы должны будете вернуть такое сообщение конечному как бы изначальному отправителю, несмотря на то, что трансляция для ICMP у вас изначально не была. То есть, вот это выглядит как то, что у вас есть роутер с NAT, здесь есть клиент, здесь есть какой-то сервер, вы отправляете UDP-шное сообщение, это сообщение доходит до сервера,

сервер говорит, у меня такого порта нету, в ответ идет ICMP. Трансляцию вы поставили для UDP, а в ответ надо еще и ICMP тоже в эту же трансляцию завернуть. Есть RFC, который указывает, как это надо делать. Соответственно, называется эта штука SEED, Stateless IP ICMP Translation. Понятное дело, что в некоторых случаях вы должны будете расковыривать весь трафик, который внутри идет, если вы увидите там FTP, например, то должны будете расковырять его, видеть там IP 4 адреса и что с ними сделать. Ну и, скорее всего, вам понадобится DNS-64 сервер. Вы можете проверить, действительно ли сервер у вас поддерживает DNS-64, если вы попытаетесь зарезолвить запись, ресурсная запись 4-х, IPv4-only-ARPA. То есть, это IPv4-only-ARPA, это запись, которая по определению гарантирована, только IPv4 результат вам может дать, только одну ашку. Если вы запрашиваете 4-х, и вам возвращается какой-то результат от NX-Domain,

то, значит, у вас работает DNS-64. если... Так, вообще, этот слайд откуда взялся-то? Он здесь не должен быть. Да. А, да, это должен быть. Простите, ошибся. Если вы хотите использовать инкапсуляцию IPv4 в IPv6, ситуация, когда вы очень продвинутый провайдер, у вас нативная IPv6-сеть, и ваши клиенты хотят получать доступ по IPv4, то вы можете использовать либо туннелирование 4-инт-6, когда у вас есть IPv6-й заголовок, дальше вы указываете, что внутри лежит вложение с типом 4, и дальше у вас IPv6, дальше следующее вложение будет IPv4, ну, либо тоже GRE можно использовать. Клиентам IPv4-м в любом случае, в этом случае нужно будет предоставлять доступ к IPv4-интернету, и, скорее всего, это потребует НАТО. Какие здесь возможны сценарии? Первый сценарий это DS-лайт, очень популярная схема,

когда у вас есть в потоке трафика между клиентом и сервером в интернете два элемента, которые называются before и after. Before — это, скорее всего, CPEшка клиентская, а after — это, скорее всего, выходной роутер, на котором у вас будет сразу же одновременно работать и CGNAT. Вот. Соответственно, пакеты, которые клиент отправляет, это просто обычный IPv4-пакет, пакеты. Дальше. На before — элементе у вас все это дело заворачивается с помощью 6-in4, то есть приклеивается к этому всему делу еще дополнительно IPv6-заголовок, и уже IPv6-пакет тащится по провайдерской сети. Все это дело доходит до автора элемента, снимается заголовок IPv6, выпускается все это дело в интернет, возможно, с помощью CGNAT. Эта штука довольно часто используется в проводных сетях. Она создавалась для того, чтобы у вас был, например, какой-то провайдер,

который вы только что построили, свеженький, внутри него вся инфраструктура построена на IPv6, и вы строите фактически такие туннели, где у вас каждый клиент строит туннель с large-scale NAT, для того, чтобы внутри передавать IPv4 трафик. Второй вариант это 464x LAT, страшное название. Смысл заключается точно в том же, у вас есть внутренняя клиентская сеть IPv4, есть IPv4 интернет, но между ними есть чисто IPv6 провайдерская среда. Трафик от IPv4 клиента доходит до элемента CLAT клиентский клиентский терминал. Дальше. Вместо того, чтобы заворачиваться в IPv6 заголовок, используется преобразование NAT 4.6, то есть это вы отрезаете IPv4 голову, вместо нее приклеиваете IPv6 бошку. Трафик доходит до следующего узла, который называется P-LAT, и он делает еще раз

трансляцию, которая будет называться NAT обычная 6.4, он отрезает IPv6 бошку и отправляет пакет в интернет с IPv4 головой. Вот эта вот схема, несмотря на свою какую-то кажущую сустранность, она на самом деле очень популярна в беспроводных сетях, особенно в мобильных сетях, которые регулируются консорциумом 3GPP. Дело в том, что вот это вот CLAT устройство, оно не всегда выглядит как отдельный роутер, который там монтируется в стойку или как отдельная железочка, которая может попробовать руками. Дело в том, что часто вот все вот то, что я сейчас обвел в рамочку, это все один мобильный терминал, который подключается к провайдерской сети по чистому IPv6. И внутри мобильного терминала у вас поднимается сила от элементов и порождается IPv4 сетка, в которой могут быть клиенты, какие-то приложения, какие-то контейнеры. И если вашему мобильному терминалу нужно иметь доступ к IPv4, он его получает.

Если вашему мобильному терминалу нужен доступ к IPv6, он его получает. Все это будет как сервисы работать. Вот здесь какой-то сервис, здесь какой-то сервис. А дальше все это дело бежит по провайдерской беспроводной сети до пилата элемента и вылетает в IPv4 или в IPv6 интернет. Вот эта вот штука, она, как я уже сказал, в беспроводных сетях, в мобильных сетях используется в качестве стандартной. Еще одна штука, которую можно будет встретить в некоторых случаях, это будет называться мап. И смысл его будет заключаться в следующем. Опять же, у вас есть два элемента, мап клиентская железка и мап провайдерская железка, мап бордер релей. Вы будете отправлять, вы будете принимать от клиента IPv4 пакеты. Дальше, вы, используя некоторую схему преобразования в известный префикс, кодируете внутри IPv6 заголовка некие вот эти вот адреса, которые были изначально в IPv4 пакете

и заворачиваете IPv4 пакет в IPv6, то есть приклеиваете к нему бошку и пропускаете трафик дальше по IPv6 сети. Внутри IPv6 заголовка у вас содержится вся фактическая информация, которая нужна для того, чтобы промаршрутизировать трафик дальше в сторону сети назначения. Вот этот вот префикс fd00, чего-то там, он адресуется в сторону бордер релея. Дальше до бордера релея трафик доходит и маршрутизируется в интернет с использованием обычного НАТО. Есть два варианта, как вот это вот можно сделать. Можно использовать двойной НАТО, то есть я вам сейчас фактически показал, как это выглядит. Оба варианта НАТО на самом деле и тот, который здесь будет идти, и тот, который здесь будет идти до CGНАТО, который отдельно здесь стоит, они будут стейтлесс. То есть эта штука алгоритмическая и очень быстрая. Ну или второй вариант это использовать дополнительный заголовок 4 in 6, когда вы 4 пакет оборачиваете дополнительным IPv6 заголовком.

Оба варианта доступны, оба варианта были приняты одновременно. Мап с двойной трансляцией будет называться Мап Т, мап с заворачиванием IPv4 в IPv6 будет называться Мап Е. Оба варианта, да, либо приклеиваем, либо меняем бошку. Оба варианта будут доступны. Так, ну и последнее, что хотелось бы упомянуть, что ваши клиенты, конечно, пусечки, они вам деньги несут, но от них надо защищаться. Они зачастую пытаются сделать всякие разные нехорошие вещи, и эти самые вещи, они губительны для провайдерского бизнеса, поэтому надо будет защищаться от них, как от самых злых хакеров. Они в первую очередь заинтересованы в том, чтобы вас поломать и получить бесплатно доступ к чему-нибудь. Обычные всякие хакеры-крекеры, которые из интернета пытаются вашу сеть просканировать, они не заинтересованы морально или материально во взломе вашей сети, а вот те,

кто находятся за вашими абонентскими портами, это ваши самые главные враги. Да, они приносят вам деньги, но защищаться от них нужно в первую очередь. Поэтому защищаемся от них мы с теми всеми мерами, которые мы проходили на CCNA, это мы включаем порт security, это мы включаем BPDO фильтр на портах от них, мы включаем dynamic arp inspection, включаем порт access-листы, которые отбрасывают ненужный трафик, смотрим на то, чтобы нам не присылали всякие лишние вложения, если у нас нету IPv6, пристреливаем нафиг 80... 80... как он называется-то? Забыл. Не 88, а 8. Господи. 86DD, IPv6 вложения. Если мы видим внутри IPv4 пакета, проверяем IPшники источника про Unicast Reverse Path Forwarding, проверяем это все дело по IP Source Guard, если у нас используется, опять же, DHCP Snooping, если мы выдаем IPшники по DHCP, то есть все возможные

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

Точнее, это будет не один курс, а несколько. Будет один курс посвящен BGP, будет один курс посвящен MPLS, будет один курс посвящен Kiosu, будет что у нас там еще, BGP, Kiosu, IGP, всякие ISIS и USPF. Но это все будет потом. А сейчас я на этом с вами прощаюсь. Вот.