Стык маршрутизируемой сети и Интернет

Продолжаем говорить про курс route, про маршрутизацию в сетях предприятия. Мы с вами обсудили вопросы запуска маршрутизируемой сети внутри предприятия. Если у нас есть какие-то железки, они между собой связываются. Где-то у нас может быть L2-связь, но в основном мы предпочитаем L3-связь. И между нашими маршрутизаторами будет работать какой-то протокол динамической маршрутизации. Будь то OSPF, EIGRP или никто не будет помянут RIP. Или если маленькая у вас сеть, даже может быть статическая маршрутизация. Но рано или поздно вы всё равно столкнётесь с вопросом: а что дальше? Окей, сеть мы построили. Надо в интернет как-то выпустить трафик. Здесь возникают нюансы. Первый нюанс — если у нас есть один провайдер, то мы должны к нему как-то подключиться. И мы должны, наверное, использовать NAT. Потому что провайдер нам даст один IP-шник, и с этим IP-шником мы должны будем что-то делать. Ещё вопрос может быть, если у нас провайдеров два.

Соответственно, нам надо два NAT сделать. Один NAT в адрес одного провайдера, другой NAT в адрес другого провайдера. И нам нужно будет как-то сделать правило, чтобы переключаться между этими провайдерами. А ещё может быть такое, что у нас переключение между двумя провайдерами происходит, и все сессии теряются. Потому что мы раньше NAT-или в адрес одного провайдера, в IP-шник одного провайдера. А после переключения мы NAT-им в адрес другого провайдера. И у нас возникает вопрос: раньше пакеты NAT-ились в одно, теперь NAT-ятся в другое. Это, естественно, у получателя вызывает серьёзные проблемы. И сессия рвётся. Если у нас TCP-шная сессия была, она сначала из-под одного IP-шника устанавливалась, а теперь из-под другого приходит. Естественно, что старая сессия со старого IP-шника должна будет порваться, а новая должна будет переустановиться. Поэтому вопросов, как подключить предприятие к интернету, на самом деле довольно много. Здесь сразу возникают вопросы по безопасности. Насколько это всё может быть безопасно? Насколько хорошая идея выпускать трафик в интернет неконтролируемо?

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

Сейчас действительно считается нормой, что компания, которая нанимает работников, будет предоставлять доступ в интернет, причём практически неограниченный. Понятное дело, что какие-то вещи нужно запрещать: нельзя на порносайты на рабочем месте ходить или на вирусные какие-то сайты. Но условный ВКонтактик чаще всего разрешён. Если он не разрешён, то есть какой-то документ, в котором написано, что ВКонтактик нельзя или вообще ничего нельзя. Там уже начинаются отдельные разговоры, но тем не менее. Один из вариантов, как можно использовать интернет — просто создавать хорошую атмосферу в коллективе. Мы предоставляем для сотрудников доступ к каким-то публичным ресурсам. Например, уже упомянутый ВКонтакте. Может быть такое, что в интернете будут предложены какие-то ресурсы, которые нужны для нормальной работы предприятия. Например, у вас есть какой-то отдел закупок.

Для того, чтобы этот отдел закупок мог работать, ему нужен доступ к условным Price.ru, к Яндекс.Маркету, к сайту каких-то дистрибьюторов, на котором они могут посмотреть, есть ли нужный товар в наличии. И это будет уже не развлекательное дело, это уже будет рабочая необходимость. Но всё равно, что вы предоставляете доступ к ВКонтакте, что вы предоставляете доступ к сайту дистрибьютора, это примерно одна и та же нагрузка. По смыслу одна и та же. Выглядит одинаково. Может быть такое, что у вас есть посетители, которые приходят на ваш сайт, и вы хотите опубликовать какие-то ресурсы предприятия наружу для внешних посетителей. Вы сами хостите ресурсы, сервис какой-то у вас есть, в кавычках «сайт», назовём его, и вы хотите, чтобы снаружи можно было подключаться к вам. Например, потому что вы тот самый дистрибьютор, к которому будут подключаться внешние сотрудники отделов продаж. И вы должны будете показать, какие товары есть у вас на складе. Поэтому, если у вас есть интернет, то вы его используете уже не для развлечений,

не для того, чтобы на какие-то чужие сайты ходить, а для того, чтобы на ваши ресурсы могли подключиться люди снаружи. Может быть такое, что вы хотите, чтобы к вашим ресурсам могли подключаться не какие-то произвольные клиенты, а, например, ваши собственные сотрудники. У вас есть люди, которые в каких-то удалённых офисах сидят, в командировки ездят, из отеля хотят подключаться и получать доступ к ресурсам предприятия. В этом случае вы должны будете такой удалённый доступ предоставить. Опять же, это предполагает, что у вас есть доступ в интернет, и у сотрудника, который, например, может быть в гостинице. Ему придётся заплатить за отель, в котором есть интернет. И вы должны будете подключить вашу сеть предприятия к интернету, чтобы сотрудник мог к ней подключиться. Или вариант такой, что у вас есть несколько офисов, и в этих офисах у вас есть доступ в интернет в каждом из них. И вы хотите, не получая от провайдера огромные счета за услугу выделенного VPN между этими офисами,

поверх публичного интернета организовать связь между различными частями вашей сети. Или, например, если у вас в принципе физически невозможна организация провайдерского VPN, потому что офисы находятся в разных странах. В этой ситуации не всегда можно будет такую штуку реализовать, чтобы вы пришли к провайдеру и сказали: мне нужно офисы связать между собой. Один офис в Аргентине, второй офис на Чукотке. Всё, вы попали, если вам такое надо сделать. Дальше. В определённых ситуациях у вас доступ в интернет может отвалиться, и ничего страшного не произойдёт. Если вы используете доступ в интернет только для ВКонтакте — ничего страшного. Если он отвалится, кто-то не посидит во ВКонтакте. А иногда бывает такое, что доступ в интернет нужен, и он зарабатывает деньги. Если он прекращает работать даже на секунду, вы деньги напрямую теряете. Представьте себе, что будет, если у условного Амазона или Майкрософта интернет отвалится прямо совсем.

Естественно, кто-то будет очень недоволен. Амазон потеряет очень много денег, если у него даже хотя бы на секунду интернет отвалится. Потери будут исчисляться не тысячами, а десятками, сотнями тысяч долларов. Поэтому подключение, если вы зависите от этого интернета, должно быть стабильным, надёжным, бесперебойным. И вы должны будете заложиться под то, что невозможно построить абсолютно на 100% рабочую конфигурацию. Всегда будет шанс того, что что-то сломается. И вы можете предположить, что может сломаться, если вы выпускаете трафик в интернет. Как минимум, может сломаться провод, которым вы соединены с провайдером. Канал связи между вами и провайдером не на 100% надёжный. Чаще всего там какая-нибудь оптика будет, приехал экскаватор, покопал траншею — всё, вы сидите без связи. Может быть такое, что у вас железка возьмёт и сгорит. Или у провайдера та железка, к которой вы подключаетесь, возьмёт и сгорит. Тоже в этом случае вы должны будете защититься от отказа отдельного устройства. Или может быть такое, что у вас есть провайдер, всё с ним хорошо, канал связи с ним работает, всё замечательно.

Но он не проплатил деньги за аплинк, и у него связи нет. У вас всё хорошо: ваша железка нормально работает. Железка провайдера, к которой вы подключаетесь, нормально работает. Линк между вашими железками нормально работает. А интернет там не течёт. В этой ситуации вы можете предположить, что надо будет защищаться не просто на уровне канала, не просто на уровне железки, а на уровне прямо поставщика услуги. Что у нас есть два провайдера в интернет, которые используют разные аплинки, которые используют разные технологии доступа. И мы можем предположить, что если один сломается, второй вряд ли при этом одновременно сломается. Хотя здесь надо быть очень аккуратным, потому что очень часто, если вы в каком-то регионе работаете, особенно если это какая-то глубинка, вы не можете найти двух розничных провайдеров, которые не использовали бы одни и те же аплинки. И вполне может быть такое, что вы приходите к провайдеру X, говорите: мне нужен доступ в интернет. Они говорят: не проблема, 100 рублей в месяц, или 1000, или 10 тысяч рублей в месяц, неважно. Приходите к другому, он говорит: тоже 20 тысяч рублей в месяц.

Вы говорите: окей, я беру вас обоих. Дальше вы начинаете настраивать связь между ними. Вы говорите: мы со своей стороны всё настроили хорошо. Если связь с одним падает, мы переключаемся на второй. Если связь со вторым падает, мы переключаемся на первый. Но дальше возникает ситуация, когда выясняется, что упал аплинк, условный Ростелеком. И вы сидите без связи, потому что оба этих маленьких розничных провайдера использовали один-единственный аплинк Ростелекома. Поэтому вы должны будете на этом уровне взять, прикинуть, кто у этих провайдеров аплинки, как они связаны, не случится ли такое, что какой-то отдельный отказ у вышестоящего аплинка вызовет пропадание связи у вас. Иногда это сделать нереально, к сожалению. Но тем не менее постараться, по крайней мере, стоит. Так. Как можно подключаться к интернету? Если вы предприятие, то возможны варианты. Есть провайдер, есть вы как предприятие, вас соединяет один шнурок. Это может быть не шнурок, это может быть какое-то беспроводное соединение.

Но это один канал связи: он втыкается с вашей стороны в одну железку, с провайдерской стороны он втыкается в одну железку, и здесь сломаться может всё. Может сломаться ваша железка, может сломаться канал между вами и провайдером, может сломаться железка провайдера, может сломаться провайдер целиком. Это самый ненадёжный вариант, когда у вас есть просто один шнурок, которым вы соединены с провайдером. И особенно если это не шнурок, а даже беспроводное какое-то соединение — что угодно может пойти не так, и на связь это повлияет, скорее всего, негативно. Это самый ненадёжный вариант, но он самый простой. Если вы получаете такой вариант — связь со внешним миром через один единственный канал, то с вашей стороны здесь всё просто. Вы говорите: вот здесь у нас железка, здесь нам выдаёт провайдер IP-шник по DHCP или как-то ещё. Мы его назначаем, здесь включаем NAT и бурно радуемся тому, что у нас весь трафик ходит через один единственный шнурок. Наружу у нас смотрит маршрут 0.0.0.0/0.

Это примитивно простой сценарий, при котором у нас всё работает в кавычках «из коробки». Но в какой-то момент вы начинаете задумываться: а что если оно сломается? Как минимум может сломаться провод или канал связи между вами и провайдером. И вы говорите: давайте мы сделаем два канала, два провода. На самом деле начинается оно немножко с другого. Сначала начинается с того, что давайте мы поставим две железки у нас, чтобы если один роутер сдох, второй бы начал работать по тому же проводу. Но сразу возникает вопрос: а куда провод втыкать? В одну из этих железок, правда? А если одна из железок сдохнет, то всё сдохло. И здесь есть варианты, когда на физическом уровне некоторые устройства позволяют так называемый порт в bypass переключить. И у вас будет провод приходить в одну железку. Рядом стоит вторая такая же. И они между собой соединены. И эти порты связаны в режиме bypass. Bypass.

Если железка целиком дохнет, то тут просто релюшка закорачивает эти контакты. И у вас получается, что провод такой странной формы приходит. Трафик начинает ходить через вторую железку. Но это надо, чтобы сложились все условия: чтобы железка именно по питанию сдохла, чтобы она не зависла. Чтобы этот самый bypass включился. Cisco такое не поддерживает, но тем не менее некоторые другие вендоры такое предоставляют. Но рано или поздно, если вы говорите, что тут у нас задолбало всё падать, мы хотим поставить вторую железку, вы неизбежно приходите к тому, что вам нужен второй провод, второй канал до провайдера. До одного и того же, подчёркиваю. Это сценарий dual-homed подключения. Single-homed — у нас один провод, dual-homed — у нас два провода до одного и того же провайдера. И трафик между этими проводами может ходить, как вам заблагорассудится. Можете сказать, что трафик должен ходить через один, а если он сдох, то тогда через второй. Можно как-то ещё придумать. Здесь возможны варианты.

Есть что обсудить, как организовать загрузку этих каналов одновременно. И провайдер сам со своей стороны трафик до вас может что по одному шнурку пригонять, что по другому. Это в принципе ни на что особенно сильно не повлияет. Ни на resequencing, ни на какие-то ещё вещи. Здесь сравнительно всё просто. Естественно, намного сложнее по сравнению с первым вариантом, где у нас всего один шнурок. Потому что мы должны будем настроить балансировку, мы должны будем каким-то образом выбрать канал, в который отправляем трафик. Мы должны будем решать проблемы с resequencing, если мы будем оба канала одновременно загружать. А если мы не будем оба канала одновременно загружать, мы должны будем придумать, что говорить руководству. Что платим деньги за два канала, а по факту эксплуатируем только один, а второй просто в холодном резерве лежит. Такие вещи должны быть продуманы. Но тем не менее dual-homed подключение — это наименьшее из зол по сравнению со всеми остальными вариантами, которые будут усложнять конфигурацию очень сильно.

Ещё один вариант — сказать, что мы всё равно будем использовать два разных шнурка. Мы можем сказать: давайте используем два провайдера в этом случае. У нас будет сеть предприятия, там стоит одна или две железки, и они смотрят разными каналами на двух разных провайдеров. Если один провайдер дохнет, то мы переключаемся на второй. Всё бы ничего, но в этом случае проблема возникает с NAT. Как же быть, когда у нас при переключении с одного провайдера на другой меняются IP-шники? И здесь вам придётся использовать динамическую маршрутизацию между вашей автономной системой и автономной системой ваших провайдеров. Вы должны будете сказать, что у вас есть какие-то собственные IP-адреса, так называемые PI-адреса, Provider Independent. PI-IP-адреса. И вы эти адреса должны будете анонсировать по протоколу BGP или каким-то иным образом обоим вашим провайдерам. А они будут анонсировать их снаружи в интернет.

И в этом случае трафик из интернета до ваших IP-шников будет ходить через какого-то одного из этих провайдеров, или через обоих одновременно. Часть трафика может приходить так, часть трафика может приходить так. И здесь сразу много вопросов возникает. Как настраивать BGP, как настраивать балансировку трафика. Эта штука довольно сложная. И самый злобный, самый сложный вариант — это когда у нас два провайдера, до каждого два шнурка. На экзамене весьма вероятно вас будут спрашивать про название этих топологий подключения. Single-homed — это один шнурок до одного провайдера. Dual-homed — два шнурка до одного провайдера. Multi-homed — два шнурка до двух разных провайдеров. И Dual multi-homed — это несколько провайдеров, до каждого несколько шнурков. С провайдерскими адресами, с PI-адресами ситуация следующая.

В IPv4 вы их просто не найдёте. Когда-то давным-давно, в очень-очень далёкой галактике, пока адреса IPv4 ещё оставались, вы могли просто прийти в свой региональный регистратор и сказать: мы компания, у нас есть необходимость использовать два провайдера одновременно, дайте нам, пожалуйста, эти самые PI-адреса. И дальше вы просто платили деньги и получали провайдер-независимую сетку. И плюс вам ещё был нужен так называемый номер автономной системы. Тоже вопрос был на самом деле чисто финансовый. Просто платили деньги, получали IP-шники и получали номер автономки. После того, как в IPv4 адреса тупо кончились — они сейчас уже тупо кончились — естественно, вы их просто получить уже не можете. Сейчас можно получить только провайдер-зависимые, Provider Aggregatable адреса, которые выдаются блоками. И они выдаются только провайдерам. Но вы, конечно, можете сказать, что вы прямо провайдер-провайдер, просто маленький. У вас там 10 абонентов есть, и вы хотите получить провайдер-зависимые адреса.

Дальше вести себя вы будете так, как будто вы на самом деле не провайдер, вы просто получаете IP-шники. На них не написано, что это IP-шники какие-то специальные, просто IP-шники. И вы начинаете их использовать как будто они Provider Independent. В индустрии такой лёгкий обман встречается достаточно часто. Про выдачу этих провайдер-зависимых адресов есть следующая схема. Есть организация, которая распределяет все ресурсы, необходимые для работы интернета. Она называется IANA. Internet Assigned Numbers Authority. Она будет раздавать номера автономных систем и следить за тем, чтобы один и тот же номер автономной системы не достался двум разным участникам. Если один участник перестаёт платить деньги, у него номер автономки отбирают и выдают кому-то другому. И равным образом она же будет раздавать и блоки IP-адресов.

Напрямую отдельные IP-шники она не выдаёт, она работает именно на уровне блоков. И плюс она же на самом деле будет управлять и DNS. Эта самая IANA раздаёт большие блоки адресов, например, по /8 маске. Сами понимаете, таких блоков мало. И она эти блоки раздаёт так называемым региональным регистраторам. Их целых пять штук по миру. Европейский — RIPE NCC. Не путайте, пожалуйста, просто RIPE. И RIPE NCC — это разные сущности. RIPE — это сообщество инженеров, которые просто встречаются и любят побухтеть ни о чём. Сходки инженеров. А RIPE NCC — это организация, традиционный центр европейских IP-сетей. Вот французское название. Я не настолько знаю французский, чтобы это произнести вслух, но тем не менее. Network Coordination Center. В Северной Америке используется региональный регистратор ARIN, American Registry for Internet Numbers.

Asia Pacific — соответственно, Азия, Австралия, APNIC, Asia Pacific NIC. Южная и Центральная Америка, LACNIC, Латинская Америка, Карибский бассейн. И соответственно Африка, AfriNIC. Вот пять штук, которые заведуют раздачей слонов во всём мире. И она выдаёт блоки этим самым региональным регистраторам. Дальше региональные регистраторы раздают блоки адресов из своих полученных больших блоков мелким регистраторам, которые называются LIR, локальные интернет-регистраторы. Это могут быть провайдеры, это могут быть какие-то крупные предприятия, у которых много абонентов, это могут быть университеты. И соответственно дальше LIR-ы выдают IP-шники уже конечным пользователям. Если говорить про сегодняшний день, то сегодня вы можете получить PA-IP-адреса по очень большому блату, либо вы можете получить...

Да, в IPv4. Либо вы можете получить IP-шники, если вдруг вам очень надо будет, на чёрном рынке. Вы просто приходите к обладателю этих самых IP-адресов, у которого они есть сейчас и который их не использует, и говорите: переоформите, пожалуйста, свои IP-шники на нас. Соответственно, они в RIR свой, например в RIPE, если вы в Европе, отдают команду, что с их учётки эти IP-шники надо переоформить на вашу учётку. Адреса в любом случае стоят каких-то денежек. Если мне память не изменяет, там не очень большие суммы, за /24 сетку что-то порядка 200 евро надо платить. Это не так много. Масштаб примерно такой. И плюс ещё надо платить деньги за автономку. Если вы используете связь по BGP, то вам нужен будет номер автономной системы, который тоже стоит денег. Он стоит что-то типа 400 евро, 400 долларов в год. Это в принципе для предприятия вполне подъёмные деньги.

Если говорить про IPv6, то вы в IPv6 вполне можете получить PI-адреса. Но не так много пока что желающих, к сожалению, получить провайдеронезависимые адреса. Дальше. После того как вы получили эти самые адреса, вы можете с ними ходить в интернет. Дальше адреса могут быть либо провайдерозависимые, либо провайдеронезависимые. В IPv4 по внешнему виду IP-шника невозможно сказать, какие адреса у вас какие. Вот есть адрес, например, 8.8.8.8. Мы все знаем, что это Google DNS. Какой он — провайдерозависимый или провайдеронезависимый — это можно посмотреть только в базе IANA, например в базе Whois, на самом деле в базе региональных регистраторов. Нужно обратиться к какому-то реестру адресов и там смотреть, кому выдали этот адрес. И по внешнему виду непонятно, что это за адрес. В IPv6 провайдерозависимые адреса имеют очень определённую структуру.

Эта структура будет иерархической, что региональные регистраторы от IANA получают большие блоки. По стандарту, по договорённостям изначальным, они должны были получать блоки по /23 маске. Но это достаточно маленькая сеть в IPv6. Несмотря на то, что там много битиков в IPv6-адресе, /23 сетка для регионального регистратора, для организации уровня того же RIPE европейского, это действительно маленький блок. Поэтому многие регистраторы будут получать одновременно сразу пачки этих /23 блоков. На самом деле вы вполне можете сказать, что если мы берём два блока по /23 маске, это фактически всё равно что /22 сетка, правда? И по факту на сегодняшний день история знает случаи, когда региональные регистраторы получали /12 сетки. Это ARIN. Дальше. Этот самый региональный регистратор начинает раздавать свои адреса LIR-ам,

локальным регистраторам, и они должны получать блоки по /32 маске. Но опять же, если вы крупный, какой-то суперкрупный провайдер уровня какого-нибудь AT&T или Sprint или крупные американские провайдеры, то блоки они могут получать крупные. Они могут получать блоки крупнее даже, чем /23, чем LIR-ы могут по идее запрашивать. Если вы условный Sprint, вы можете прийти и сказать: слушайте, у нас клиентов дофига и больше. Мы должны получать много-много-много адресов. И по факту, опять же, история знает случаи, когда LIR-ы получали /19 маску. Дальше эти LIR-ы, провайдеры, начинают раздавать свои адреса клиентам. И есть правило, по которому они должны это делать. Не то что правило — договорённости, опять же. Договорённость следующая: конечный абонент должен получать сетку не менее чем /48. И здесь возникает нюанс. Нюанс заключается в том, что если выдавать /48 сетки абонентам,

дальше абоненты должны будут использовать сетки на конечных хостах /64. По факту, если мы выдаём клиенту /48 сетку, а он назначает /64, то это получается 65 536 сетей мы ему даём по /64 маске. И тут многие провайдеры сказали: у нас самое сильное животное на земле душит такое делать. Мы в IPv4 за каждый IP-шник деньги берём. А тут мы получается обязаны выдать не просто /64 сетку, в которой 2 в степени 64 — это дофига лиард адресов примерно. Мы не просто должны им отдать много-много адресов в каждой сети. Мы должны им ещё и много-много таких сетей отдать. Нас жаба душит, мы такое делать не будем. И несмотря на то, что по стандарту клиенты-физики даже, любые клиенты должны получать как минимум /48 сетку, провайдеры по факту не дают /48 сетки в нарушение договорённости о том,

как должен быть устроен IPv6-интернет. Если вы клиент-физлицо, по факту реальность такова, что вы будете получать /64 маску. Этого вам хватит на одну внутреннюю сеть. Если вы клиент-физлицо, вот я нарисую человечка, сразу видно, что это мальчик, и вот он настраивает свою внутреннюю сеть, у него есть шнурок от провайдера, который приходит в его роутер, как мог — так нарисовал роутер, и у него этот роутер смотрит на внутренний свитч, и внутренний свитч соответственно говорит, что у нас есть телевизор, какой-нибудь компьютер, что там ещё — приставка, Wi-Fi здесь ещё торчит, который раздаёт ту же самую сетку, аналог условный 192.168.1.1 по /24 маске. Это всё один, назовём это VLAN, и в этом VLAN есть одна и та же сетка /64 в IPv6. И вот провайдеры говорят, что это придётся делать так,

потому что иначе IPv6 просто не будет работать, хотя находятся отдельные уникумы, которые говорят: а мы вам вообще будем выдавать только один IPv6-адрес, и нам всё равно, что это не то, как работает IPv6. У нас деньги берутся по базе за отдельные IP-шники. В IPv4 мы берём деньги — 150 рублей за белый адрес. В IPv6 вы получаете белый адрес — пожалуйста, платите нам 150 рублей за каждый. Мы не будем вам давать /64 сетку, потому что там дохрена этих адресов, и вы нам просто не расплатитесь, если мы вам выдадим все эти адреса. Поэтому вот вам один. Это, конечно, уже крайности. В реальности провайдеры, если вдруг они предоставляют на коммерческих условиях IPv6, в реальности физикам будут давать /64. Иногда можно встретить то, что юрикам дают /64, но это уже немножко наглость, потому что юрик предполагает, что он должен будет сетку разрезать на несколько VLAN-ов, скорее всего, и в этой ситуации ему будет очень тускло, если ему не дать хотя бы /56 сетку. Это 256 по /64. Если вы упёртый человек,

если вы достаточно хорошо умеете аргументировать свою позицию, вы можете вооружиться документами, нормативными какими-то отраслевыми актами и сказать: ребята, давайте, пожалуйста, блок нормальный. По стандарту предполагается, что меньше чем /48 вообще никому не будут давать. Тут вы вполне вероятно столкнётесь с непониманием со стороны провайдера, который скажет: вы знаете, идите в баню со своими нормативными документами. Мы будем делать так, как нам нравится. Если взять какой-нибудь красивый IP-шник... Давайте сотру со слайда всё. Если взять какой-нибудь красивый IP-шник, который вы можете как клиент назначить на хост, то соответственно этот IP-шник будет иметь некую структуру. У нас, например, адрес есть. Мы помним, что адрес делится на две части. Соответственно, левая называется network ID.

Network ID. И соответственно правая называется interface ID. В отличие от IPv4, где она называлась host ID. В IPv4 у нас граница между левой и правой частью проходила где угодно. В IPv6 она у нас будет проходить ровно по серединке. Правая часть — interface ID — она 64 бита. И левая часть — network ID — тоже 64 бита. Это необязательное условие, но очень многие механизмы в IPv6 рассчитаны на то, что у вас граница между левой и правой частью будет проходить именно по серединке. Дальше, соответственно, правую часть мы уже не трогаем. Она либо придумывается автоматически, либо назначается ручками. И левая часть у нас будет иметь определённую структуру. Если мы региональный регистратор, то мы можем предположить, что мы получили, например, блок /20. /20 блок — это 5 символов. Каждый символ в шестнадцатеричной нотации — это 4 бита. 20 бит — это 5 раз по 4 символа. Вот эти 5 символов — это соответственно сетка, которую RIR получил.

2001:0200:0000 и так далее. На самом деле она схлопывается естественно до 2001:200::/20. 2001:200::/20. Это получил RIR. Условный какой-нибудь RIPE. Дальше. LIR-ы, провайдеры, получают блоки /32. /32 — это вот здесь граница проходит. LIR получил блок от RIR 2001:0200:0000::/32. Дальше LIR, какой-то провайдер, условный Ростелеком, выдал IP-шник своему клиенту. Мы можем предположить, что этот клиент был, например, юрлицо, которое смогло отстоять свои права и получило сетку /48. В этом случае клиент — условное ЗАО «Ромашка».

И оно получает сетку 2001:0200:0000::/48 и так далее. /48. И дальше этот клиент уже дербанит полученный префикс на /64 сетки. Он получает их достаточно много. И фактически этот октет будет означать своего рода номер VLAN-а. В IPv4 у нас для того, чтобы взять и порезать сетку на части, надо было заниматься всякой фигнёй — типа заимствовать какое-то количество битов host ID. Соответственно host ID у вас становился меньше. Кто на ICND1 ходил, тот помнит процедуру сабнетинга. И там действительно у нас не было никакой границы между левой и правой частью. Здесь у нас есть граница между левой и правой частью, она фиксированная. И есть фиксированное место для того, чтобы мы могли туда вписать условно номер VLAN-а.

И действительно, провайдерозависимые адреса будут иметь вполне чёткую структуру — кто какие адреса будет получать. Это не означает, что вы можете легко, прямо по внешнему виду такого IP-шника, получить сразу понимание, что этот IP-шник условно газпромовский и находится он условно в Москве. Но тем не менее при определённом везении вы можете сказать, что в Whois должна быть прописана запись про эту /48 сетку. И соответственно всё, что здесь будет до границы 64 бита, — это всё будет условно номер VLAN-а. В нашем случае VLAN будет там B5:189. Так. С провайдеронезависимыми адресами всё проще. Вы получаете их самостоятельно у регионального регистратора. Приходите в RIPE, говорите: RIPE, нам нужен провайдеронезависимый адрес. В некоторых случаях RIPE может от вас потребовать какие-то дополнительные условия,

чтобы были соблюдены — например, чтобы у вас был бы договор с провайдером, который согласился бы с вами пириться по PI и выступил бы так называемым вашим спонсором. Безусловно, если вы используете PI-адреса, то вам хотя бы с одним провайдером по BGP надо будет подружиться. И вот вы фактически приходите к провайдеру на поклон, говорите: дорогой провайдер, мы хотим с вами дружить, будьте нашим спонсором. От провайдера при этом ничего не потребуется особо — просто письмо написать, но тем не менее совсем уж кривые левые случаи этот механизм отсеивает. Да, требуется также получение номера автономки, но если вы в BGP будете работать, то каждая автономная система должна быть пронумерована, и номер должен быть уникальный. Не в любой сети PI-адреса будут полезны, не в любой сети они будут нужны. Во-первых, у вас должна быть мультихоум-сеть, то есть у вас должно быть подключение к двум провайдерам. Каждому из этих провайдеров вы должны настолько понравиться, что они должны согласиться с вами дружить по протоколу BGP.

Это уже на самом деле немаловажный пункт, потому что далеко не любой провайдер с вами будет согласен дружить по BGP. Это можно встретить. Это не то что прямо невозможно, но тем не менее это не самый частый сценарий. Если вы к провайдеру приходите и говорите: мне нужно с вами по BGP пириться, провайдер скажет: а ну вас в баню. Вы денег-то готовы платить, но вы же не готовы платить много денег. А за мало денег получится, что мы сейчас полезем в наш BGP, начнём его конфигурировать, и у нас что-нибудь сломается. Нам намного интереснее получать мало денег от многих клиентов, которые ничего не просят. Поэтому эти отдельные случаи, когда вы говорите: а вот надо, чтобы вы своё железо переконфигурировали, чтобы мы к вам могли подключиться, они не приносят деньги и с точки зрения бизнеса просто не интересны провайдеру. Поэтому есть провайдеры, которые согласны подключаться по BGP с клиентами, есть те, которые нет. Если у вас хотя бы одно из этих условий не соблюдено — нет двух провайдеров, которые согласились бы дружить с вами по BGP, —

то вам провайдеронезависимые адреса противопоказаны. Просто смысла нет их использовать. В IPv4 у нас были адреса, которые нельзя было выпускать в интернет, но если очень хотелось, то можно было с использованием NAT. Это на самом деле несколько блоков. Наиболее популярные блоки, которые нельзя выпускать в интернет, — это RFC 1918. Запомните, пожалуйста, этот номер RFC. Это частные IP-шники, которые можно назначать во внутренней сети, но нельзя выпускать в интернет. Это блок 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Я думаю, что вы в принципе помните его. Эти сети нельзя было выпускать в интернет, но в 1992 году появился NAT. И соответственно стало можно взять, отправить пакет из-под частного адреса в сторону интернета, и дальше NAT его перебивал. Частный IP-шник перебивал на публичный.

И IPv4 сегодня так работает везде. Никто уже не назначает белых IPшники на конечные хосты. Все сидят за NATом. В IPv6 NAT есть, но того NATа, который выпускает наружу всех клиентов, нет. И в IPv6 вы можете сказать, нам нужны частные IPшники, просто чтобы не публичные IPшники на хосты раздавать, а частные. Но вы должны будете тогда эти адреса использовать только внутри сети. Вы не можете их выпускать в интернет. Если вы используете выход в интернет, то вам нужны глобальные публичные маршрутизируемые адреса, которые имеют определённую структуру, которые вы обязаны запрашивать большими блоками у своего провайдера, как минимум /64, скорее даже большими. Вернусь на предыдущий слайд. Когда вы получаете блок /48 или /56 или даже /64, это много белых адресов и нет никакой проблемы с тем, чтобы эти белые адреса раздать на конечные хосты.

В IPv6 для выпуска в интернет вам нужно на хосты повесить белые IPшники. Для работы внутри сети вы можете дополнительно сказать, у нас есть какие-то хосты, которым нужен выход в интернет. Здесь у нас интернет. У нас здесь какая-то сеть есть, которой нужен выход в интернет. И плюс у нас ещё здесь есть какой-то другой кусок сети, которому выход в интернет не нужен. И нам надо, чтобы здесь у нас связанность всё равно была. Мы говорим «Окей». Для связи нашей части сети с интернетом у нас будут использоваться global адреса, а для связи внутри сети мы сделаем unique local адреса. И это будут локальные адреса, которые частные, которые не пересекаются с интернетом. И в интернете они работать не будут. Классический сценарий предполагает, что вы берёте сетку FD00::/8 и дальше выбираете из неё условно-случайным образом /48 сетку.

Но случайный выбор предписывает использовать не совсем случайную сеть, а всё-таки такую контролируемую случайную. Вы должны будете взять на некотором компьютере серийный номер этого компьютера или MAC-адрес, добавить к этому серийному номеру или MAC-адресу текущее время в Unix формате, от этого всего посчитать хэш и взять от этого хэша 40 бит. И к FD приклеить 40 бит и получить действительно случайную /48 сетку. Это позволит вам в случае, если вы придумали по такой схеме Unique Local адреса и ваш сосед придумал по такой же схеме Unique Local адреса, пириться между собой по Unique Local адресам. Чтобы не было проблемы, которая возникла, например, у Facebook, когда они купили Instagram, что серверы Facebook и серверы Instagram использовали одни и те же частные IPшники. И нельзя было отправить пакет с сервера Facebook на сервер Instagram. Потому что нельзя отправить пакет с адреса 192.168.1.1 на 192.168.1.1.

Поэтому в IPv6 у нас есть специальный механизм генерации случайной сети из блока всех частных сетей. Естественно, есть определённый соблазн сказать, что могло же такое быть, что мы взяли серийный номер железки какой-то, добавили к ней текущее время в Unix формате, посчитали хэш. И этот хэш получился куча нулей. Мы взяли последние 40 бит из этого хэша. Это тоже получились нули. У нас получается сетка FD00::/48. Вот такая красивая. Может такое быть? Может. Кто может сказать, что такого не могло быть? Могло. И часто вы можете встретить именно такую сеть, просто потому что она красивая. Если вы хотите использовать подключение к интернету, то вы, скорее всего, начнёте с того, что у вас есть single-homed подключение, где, скорее всего, вы будете использовать провайдерозависимые адреса.

Вам провайдер будет присылать их по DHCP или статикой вы будете назначать. Там же будет маршрут по умолчанию. Опять же, если DHCP используете, он может прибежать оттуда. Либо, если вы будете использовать статику, вы его статически можете прописать. Для IPv4 вам потребуется NAT. И если вы будете работать с IPv6, то здесь может быть такой сценарий, когда у вас есть роутер. Этот роутер получает префикс от провайдера по механизму, который называется DHCP PD, prefix delegation. Он говорит, что я тебе выдаю сетку, например, 2001:DB8::/48. И дальше роутер, который по prefix delegation, по DHCP PD получил такой префикс, начинает раздавать его своим клиентам. Он говорит, у меня есть сетка 2001:DB8:1::/64.

Потом другому клиенту говорит, у меня есть сетка 2001:DB8:2::/64. Он блок адресов, который получает по prefix delegation, делит на части и раздаёт эти адреса на внутренних интерфейсах. Это штука динамическая, и она очень удобная. Как раз в ситуации, когда вы подключаетесь к IPv6 интернету, чаще всего она используется. Если у нас использовался IPv4 доступ, то там обязательно работал NAT. И с NAT вы должны будете на экзамене продемонстрировать своё умение его настраивать. Мы это делали на ICND1, но тем не менее напомню, как это всё выглядело. Первое. NAT — это процедура смены IP-адресов. NAT не связан с маршрутизацией. Когда у вас пакет проходит из одной сети в другую, он проходит по таблице маршрутизации, но на роутере в какой-то момент ему просто меняется IPшник.

Эта процедура вообще никак не связана между собой. Отдельно выполняется маршрутизация и отдельно выполняется перебивка IPшников. У вас должно быть правило, по которому процесс маршрутизации перекладывает пакет между интерфейсами, и отдельно требуется правило, по которому отдельный процесс NAT будет перебивать IP-адреса. Само название NAT — Network Address Translation — как раз намекает на то, что это именно только перебивка сетевых адресов. Адреса надо перебивать так, чтобы приложение, которое пользуется связью через IP, этого не заметило или, по крайней мере, заметило бы по минимуму. Поэтому вы адреса меняете у пакетов, которые идут из вашей, чаще всего, внутренней сети наружу. И потом, когда приходят ответы, вы обратно подменяете публичный IPшник на тот частный, из-под которого оригинальный пакет отправлялся. В нашем случае у нас есть, например, пакет, который идёт в сторону Google DNS от адреса 192.168.1.1.

Мы пропускаем такой пакет наружу, меняем частный IPшник 192.168.1.1 на публичный 203.0.113.1. Мы должны это сделать, потому что такой адрес нельзя выпускать в интернет. Пакет дошёл до сервера Google, возвращается обратно на тот же самый IPшник, откуда он пришёл, то есть на 203.0.113.1. И дальше роутер обратный пакет транслирует обратно в 192.168.1.1. Если вы поменяете только в одну сторону адреса в пакетах, то пакет придёт на этот роутер. Дальше роутер скажет, окей, пришёл пакет. Замечательно. Что с ним делать дальше? Выкинуть? Мы его не запрашивали. А клиент, который изначальный запрос отправлял, он ответ свой не получит. Поэтому для того, чтобы всё хорошо работало, вы должны будете в обе стороны пакеты транслировать при прохождении через сеть. Некоторые приложения будут страдать от того, что вы вносите какие-то изменения в пакет самовольно, потому что в заголовке IP изменения вносить нельзя, кроме определённых полей, в которых это делать можно.

Можно вносить изменения в поле TTL. И можно вносить изменения в поле Type of Service. Оно же DSCP метки. Чексумма, понятное дело. Во все остальные поля изменения вносить нельзя. Поэтому если у нас есть какой-то пакет, который по сети идёт, в котором мы IPшники перебиваем, некоторые протоколы от этого будут страдать. Из числа наиболее ярких примеров протоколов, которые плохо переживают NAT, это GRE и NTP. Если у вас есть, например, среда с операционной системой Windows, пользовательские компьютеры, и вы наверняка замечали, что там есть фича по умолчанию, которая позволяет синхронизировать время с сервером в интернете. И многие наверняка замечали, что там есть кнопка «Синхронизировать сейчас». Вы нажимаете её, и она пишет, извините, возникла ошибка. И вы видите, что Microsoft Windows, операционная система, придуманная компанией Microsoft, пытается синхронизировать время с сервером time.windows.com, предоставляемым Microsoft,

и генерирует ошибку. Что за ерунда? Казалось бы, Microsoft везде — и там, и там Microsoft. Почему они не могут нормально сделать? На самом деле, это не Microsoft виноват, а виноват как раз NTP, который там используется, протокол синхронизации времени, который не проходит через NAT, или проходит, но плохо. И по этой причине иногда бывает такое, что нажимаете один раз — ошибка, нажимаете ещё раз — ошибка, нажимаете третий раз — проходит. Это не потому, что там сервер как-то сильно загружен, а потому что предыдущая трансляция, которая не могла установиться, в этот раз установилась и прошла. NTP протокол такой специфический, он не очень любит NAT. Прямо скажем, совсем не любит. В некоторых случаях оно может работать криво, как в случае с NTP. В некоторых случаях оно может вообще не работать, как, например, протокол FTP, который передаёт IPшники, из которых он устанавливает сессию, внутри самой FTP-сессии. Вы отправляете IP-пакет, внутри есть FTP-команда, и вы говорите, я отправляю FTP-команду с указанием своего частного IPшника

192.168.1.1. Если вы там только в IP-пакете перебьёте адреса, то до конечного получателя такой пакет, конечно, дойдёт, но внутри там будет частный IPшник всё равно фигурировать. И в этой ситуации вы можете дополнительно, например, расковыривать не просто заголовки IP, не просто вложения, видеть, что внутри лежит TCP-сессия, но смотреть ещё и вглубь и видеть там, например, FTP или какой-нибудь SIP, и внутри FTP-сессии или SIP-сессии тоже IPшники менять. Но в некоторых случаях это прокатит, а в некоторых случаях даже это не поможет, как, например, протокол ESP, который является частью IPsec, который шифрует данные. Дело в том, что он будет при отправке данных подписывать пакеты цифровой подписью. И эта цифровая подпись распространяется на весь пакет, включая IPшники. И если вы IP-пакет изменяете, в нём IP-адреса, то вся цифровая подпись на всём пакете становится недействительной. И транзитный роутер не может ничего с этим сделать. У него нет оригинальных ключей, которыми он мог бы новый пакет с новыми IP-адресами

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

У нас есть IPшник 192.168.1.1. Мы его будем всегда перебивать на 203.0.1.1. Просто первые два байта 192.168 меняем на 203.0. Или 192.168.1 — первые три байта — меняем на 203.0.113. И тогда у нас получается, есть частные адреса, и из них можно легко получить публичные адреса. Но эта штука предполагает, что мы не отслеживаем состояние каждого отдельного IPшника, но потребуется много IP-адресов. В любом случае, каждая трансляция двусторонняя. Когда мы говорим, что во внутренних пакетах, которые идут наружу, мы меняем такие-то адреса на такие-то, то в обратных пакетах мы обязаны поменять адреса обратно. Может быть такое, что у вас внутри этой таблички будут храниться какие-то дополнительные ограничения. Типа, если пакеты приходят из-под TCP-сессии с IPшника 192.168.1.1 из-под порта 12345,

то мы меняем это на IPшник такой-то и проставляем TCP-порт 23456. И когда обратные TCP-сегменты приходят, они приходят на этот порт, мы меняем их на другой TCP-порт и на другой IPшник. Но это уже детали, что конкретная реализация может такие штуки делать. В любом случае у нас есть некая табличка. По этой табличке мы определяем, надо ли менять в конкретном пакете адреса или не надо. Если да, то на что. Если говорить про наиболее популярный сегодня способ транслировать адреса, то он будет называться NAT с перегрузкой, или NAPT — Network Address and Port Translation. Это RFC-шный термин. Network Address and Port Translation. RFC 2663. Это вещь, которая будет преобразовывать IP-адреса и номера портов для TCP, UDP. И какие-то другие протоколы там в принципе будут иметь похожие механизмы.

Работает эта штука следующим образом. Вы будете подменять для тех протоколов, у которых есть такое понятие как socket, пару IPшник плюс порт. То есть socket. У вас приходит пакет из-под socket 192.168.1.1 с порта 54321 на socket 8.8.8.8:53. Вы будете говорить, окей, этот socket частный, мы его выпускаем. Этот пакет наружу, но перебиваем частный socket на публичный. И публичный socket у нас будет 203.0.113.1. Возможно, порт при этом поменяется. Может быть и нет. Как правило, реализации NAT с перегрузкой стремятся сохранить порт, если есть такая возможность. Потому что в большинстве применений source порт будет случайный. Но если мы его поменяем, ничего особо плохого не случится. Потому что он случайный, динамический. Как правило, конечное приложение не требует, чтобы эти порты были какие-то конкретные. Как раз NTP, протокол синхронизации времени, будет от этого страдать.

Потому что у него socket источника всегда будет использовать 123 порт. Если вы отправляете пакет с 123 порта, и кто-то другой будет отправлять пакеты с 123 порта, то пакеты будут выпущены наружу, и они, вполне возможно, будут выпущены из-под одного и того же IPшника. И получится, что пакеты, отправленные одним хостом и другим хостом, невозможно будет отличить друг от друга. У них после трансляции адреса будут одинаковые, публичные. И номера портов тоже получатся одинаковые, 123. Поэтому одна из этих трансляций просто не будет выполнена. И пакеты, которые смогли пройти трансляцию, они уйдут в сеть, они вернутся, и с ними всё будет хорошо. Они позволят синхронизировать время. А для второго хоста, для второй сессии, трансляция выполнена не будет. Пакет уйдёт в интернет из-под частного адреса, и там навечно и останется. Вернуть ответ на такой адрес будет нельзя.

Обычно, когда мы говорим про NAT с перегрузкой, у нас в таблице будет храниться как раз сокет. Что меняем — на сокет, на что меняем. Иногда роутер будет способен влиять одновременно на пару сокетов. Если у нас есть IP-пакет, у него есть и source IP-адрес, и destination IP-адрес, и source порт, и destination порт. И в этом случае source socket и destination socket будут меняться на другие source socket и destination socket. И наоборот, когда пакеты проходят в обратную сторону, они будут в обратную сторону меняться. То, что раньше было destination socket, становится source socket. То, что раньше было source socket, становится destination socket. Но смысл всё равно такой, что у нас есть табличка, в которой написано, что и на что меняем. И трансляции эти двусторонние. Если один раз мы поменяли что-то в одну сторону, то в другую сторону меняется всё наоборот. Если вы используете два шнурка, то вы должны будете каким-то образом договориться с провайдером,

что у вас это происходит. Вы дальше можете сказать, давайте мы, например, агрегируем эти два шнурка с помощью L2 механизма. Например, port-channel поднимем. И LACP будем контролировать, что у нас там всё хорошо. То есть у вас фактически всё превращается в один шнурок. Либо если вы хотите сделать так, чтобы у вас два разных устройства было с вашей стороны, два разных устройства со стороны провайдера, здесь уже L2 не обойтись, здесь придётся на L3 всё делать. И в этой ситуации вы можете использовать либо статическую маршрутизацию, либо, если уж прям всё по-взрослому делать, лучше, наверное, здесь будет использовать как раз BGP. Уже здесь не обязательно будет использовать публичные номера автономки, но тем не менее вы по BGP просто будете определять, какой из шнурков с провайдером у вас будет работать. OSPF или EIGRP использовать в этой ситуации нехорошо, потому что это всё-таки чужая сеть, чужая автономка, и просто страшно немножко пускать кого попало в свой OSPF.

А BGP как раз вполне нормально. Вы используете BGP для того, чтобы вам провайдер прислал динамический дефолтный маршрут. Он вам пришлёт по каждому из шнурков 0.0.0.0/0. Вы из двух вариантов, как выйти в интернет, выберете какой-то один или даже оба, и трафик будете выпускать через этого провайдера наружу. Дальше. Внутри вашей внутренней сети у вас, скорее всего, если в IPv4 за NAT все будут сидеть с частными адресами, здесь сразу возникнет вопрос, что будет, если у вас есть два роутера, которые смотрят двумя шнурками наружу, на каждом из них нужно будет иметь NAT, и при переключении с одной железки на другую, У вас был клиент, который ходил в интернет через одну железку, а потом начал по какой-то причине ходить через другую, то трансляции NAT у него, скорее всего, не было. Вам нужно будет каким-то образом заставить эти две железки работать как единое целое и реплицировать таблицы NAT друг для друга. Или забить и сказать, что если у нас происходит переключение на другую железку,

то да, сессия потеряется, и фиг с ней. В IPv6 у нас будет, соответственно, скорее всего, настройка с DHCPPD. И один роутер получает диапазон prefix delegation, другой роутер получает диапазон prefix delegation, и у вас во внутренней сети анонсируются одни и те же префиксы. Так. При подключении к двум разным провайдерам здесь будет сложность. И сложность здесь будет в том, что вам фактически либо надо будет использовать BGP и использовать провайдеронезависимые адреса, и это будет означать, что вам нужно достаточно сложную конфигурацию BGP использовать на вашем абонентском устройстве. CPE – это Customer Premises Equipment, устройство, которое стоит у абонента. Если вы используете провайдеронезависимые адреса, то BGP вы использовать фактически должны. Вам очень сложно будет обойтись без него. Если же вы будете использовать провайдерозависимые адреса PA, то у вас, опять же, будет проблема с тем, что у нас две железки,

сразу возникает вопрос, как мы делаем NAT, что будет, если трафик ходил через одну железку, а потом через другую, сессии у нас порвутся. Если мы хотим, чтобы они не рвались, то это провайдеронезависимые адреса без вариантов. Плюс нам надо будет решить вопрос, куда выпускать трафик, и нам нужно будет написать какие-то политики, как пакеты будут выходить через какой канал в интернет. Опять же, если мы используем BGP, то в этой ситуации нам каждый провайдер будет присылать какие-то маршруты, например, дефолтные, и мы политиками BGP-шными будем рулить. Если мы будем говорить, что у нас нет BGP, у нас используется, например, как раз сценарий в сторону каждого из провайдеров, мы используем, например, Policy Based Routing, для того чтобы выбрать, куда трафик мы посылаем. Да, там надо будет настроить PBR. Опять же, политики. В IPv6, как правило, здесь у нас будет ручная настройка, мы должны будем получить и префиксы IPv6 от провайдера 1, и префиксы от провайдера 2,

и мы просто раздадим каждому клиенту и те, и другие префиксы. И у нас на каждом клиенте будет два публичных адреса, и мы должны будем заставить каким-то образом клиентов выбирать какие-то конкретные адреса. Если говорить про Windows, например, то там есть такая штука, которая называется Prefix Policy. Каким образом из нескольких публичных IPv6, которые есть у нас на каждом абоненте, выбрать правильный source IP для конкретного подключения. Там, опять же, есть табличка, которую можно централизованно, например, с помощью групповых политик раздать, и у вас узлы будут использовать оба канала в интернет. Давайте поговорим про то, как это всё можно сделать на цифре.