VPN

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

Бывает такое. Или вы можете построить такое соединение самостоятельно, как будто у вас несколько узлов соединены виртуальным проводом, и этот механизм будет называться виртуальной частной сетью, VPN, Virtual Private Network. Почему эта аббревиатура, это словосочетание, имеет глубокий смысл? Почему каждое слово во фразе Virtual Private Network имеет достаточно большое значение? Начнём с того, что нет какой-то единой технологии, которая бы называлась Virtual Private Network. Это всё, по большому счёту, какие-то способы сделать так, чтобы у вас несколько узлов были связаны между собой с помощью некого канала, который бы был не настоящий, не физический провод. Но эти узлы работали бы так, как будто бы они всё-таки связаны между собой практически прямым проводом. Виртуальные означает, что такого провода нет. Но узлы предполагают, что фактически поведение у них будет такое, как будто провод есть.

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

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

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

Если вы будете использовать просто VPN, это уже само по себе повышает безопасность передаваемых данных. Но если вы дополнительно ещё и зашифруете всё это, то безопасность начинает расти весьма значительно. За счёт всего этого VPN становится очень интересным инструментом, который позволяет объединить в единую сеть несколько различных точек присутствия, которые могли бы теоретически быть связаны с помощью отдельных выделенных линий, но не требуют этих самых выделенных линий. VPN — это инструмент, который очень популярен в современном мире. И все решения в этой технологии можно будет разделить на два семейства. Первое семейство будет называться Remote Access, решение по удалённому доступу сотрудников. В таком решении предполагается, что у вас есть пользователи, которые хотят получить доступ к удалённой сети. Например, у нас есть сотрудник, который хочет из гостиницы подключиться к корпоративному серверу и скачать с него файл.

Мы можем сказать: да, дорогой пользователь, ты можешь, конечно, взять, проложить провод отдельно до корпоративной сети, но это будет, прямо скажем, неприятно для него, потому что он физически не может взять и проложить провод от гостиницы до корпоративной сети. Прямо совсем не вариант это делать. Может быть, он, конечно, может, например, взять и позвонить по телефону стационарной связи до какого-то нашего модемного пула и получить выделенную электрическую цепь с помощью PSTN, Public Switch Telephone Network, и дальше по этой выделенной линии получить доступ к нашей внутренней корпоративной сети. Но всё равно это технология сегодня крайне редко используемая, поэтому, скорее всего, у сотрудника в гостинице не будет прямого провода до нашей компании, не будет модемного соединения с нашей компанией. У него вместо этого будет VPN, который он поднимет через интернет, который в гостинице ему предоставят, до удалённого узла, который находится в нашей корпоративной сети, опять же, имеет доступ к интернету, построит виртуальный провод от своего компьютера до удалённого узла и получит доступ к удалённой сети.

Для того чтобы это всё работало, нужно будет, чтобы у вас на том узле, который хочет получить соединение, работал некий механизм построения такого виртуального канала. И с другой стороны, вам нужно будет, чтобы на этом терминальном узле, который терминирует такие VPN-подключения, тоже принимались подобные соединения. К такому семейству будут относиться протоколы PPTP, L2TP, SSTP, OpenVPN. Их довольно много. У Cisco есть своё фирменное решение AnyConnect. Смысл у этого всего одинаковый: мы берём на отдельном компьютере, запускаем VPN-клиент, который строит виртуальный провод до VPN-концентратора. Это не единственный способ организации VPN. Второй класс VPN-ов — это site-to-site VPN, который связывает между собой несколько сетей. У Remote Access VPN-ов есть сеть, и к этой сети подключается одиночный пользователь. Каждый отдельный пользователь получает свой отдельный виртуальный канал.

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

Туннели IP-IP, когда мы берём IP-пакет, который должен будет передаваться в виртуальном проводе, и оборачиваем его новым IP-заголовком. Может к этому же решению относиться GRE, Generic Routing Encapsulation, когда мы берём IP-пакет, оборачиваем его специальным заголовком GRE и оборачиваем уже его новым IP-заголовком. Мы посылаем пакет по сети в сеть назначения. Немножко больше накладных расходов, но за счёт того, что в дополнительный заголовок можно вписать кое-какие интересные штуки, GRE по сравнению с IP-IP чуточку более гибкий протокол. В принципе, между ними разницы особой нет. Но IP-IP позволяет вложить внутрь IP-пакета только другой IP-пакет. А в случае с GRE можно взять и внутрь IP-пакета через транзитный GRE-заголовок вложить что угодно. Например, можно взять и в GRE-туннель отправить трафик IPv4, IPv6, CDP.

Что захотите, то и отправляйте. Это такой универсальный туннель, который несёт в себе трафик чего угодно. Можно взять и поднять IPsec в туннельном режиме. У нас, опять же, эти два роутера будут по публичной сети гонять трафик через публичные каналы. Но при этом они будут его шифровать с помощью IPsec. И трафик обычных пользователей у нас будет ходить по этому виртуальному каналу зашифрованный. Не надо путать эти два семейства между собой. Они разные. Remote Access — решение для одиночного пользователя. Site-to-site — для того, чтобы подключить много пользователей к другой пачке из многих пользователей. Они устроены по-разному. И если у вас задача связать между собой два офиса, решение Remote Access использовать не нужно. Надо использовать site-to-site. Если у вас задача подключить одного пользователя, у которого нет своего роутера, и надо просто ему быстренько организовать по месту доступ к сети, в этом случае как раз имеет смысл использовать решение Remote Access и не использовать решение site-to-site.

Это два разных семейства. У них разные принципы работы, разные идеологии, и надо выбирать то решение, которое соответствует нужным вам потребностям. В некоторых случаях приходится делать немножко странные вещи. Иногда бывает так, что для того, чтобы решить задачу взаимодействия двух офисов, приходится, например, поднимать L2TP-канал. Хотя казалось бы, L2TP — это решение Remote Access, но в некоторых случаях это бывает оправдано. Но вы всегда должны будете понимать, что если вдруг вы берёте для соединения site-to-site технологию, которая относится к Remote Access, то почему вы это делаете? Вам нужно будет каким-то образом доказать самому себе, что корректно именно в вашей ситуации будет выбрать неподходящую технологию для решения вашей конкретной задачи. В некоторых случаях это действительно оправдано. Но только в некоторых. Если говорить про сети предприятий, мы будем с вами учиться строить site-to-site VPN.

Возможные варианты здесь у нас, как уже говорилось, либо IPsec в туннельном режиме, либо туннель GRE, возможно, защищённый IPsec в транспортном режиме. Сам по себе GRE не позволяет шифровать трафик. Но если мы сочетаем GRE с IPsec, то шифрование при этом возможно с помощью отдельного дополнительного механизма. Вот это мы с вами в рамках курса изучать не будем. Вот это мы с вами в рамках курса изучать не будем. Вот это будем. Можно будет представить себе всякие разные хитрые штуки на основе, например, GRE. Есть такая штука Cisco DMVPN. Фирменный цисковский механизм построения site-to-site VPN, когда этих самых сайтов у нас много. Например, если у нас всего два сайта, раз и два, никаких проблем. Берём GRE, между ними поднимаем, и она работает. Если у нас сайтов, например, становится три, то нам надо поднять три туннеля, на каждом роутере по два. Если у нас становится четыре роутера, четыре сайта, нам надо будет на каждом роутере поднять по три туннеля до каждого сайта.

Если у нас таких сайтов становится пять, сами понимаете, что здесь у нас количество линков между роутерами начинает расти и расти очень сильно. Поэтому, если у нас, например, есть компания, в которой есть два центральных дата-центра и, допустим, сто филиалов, строить туннели по схеме каждого на каждого — можно задолбаться. Cisco DMVPN позволяет этого не делать. Он позволит на каждом роутере построить всего один туннель. И у нас будет один туннель, который будет смотреть на всех остальных участников сразу. Вот так это будет выглядеть. Вот это интернет, в интернет смотрит один туннель, и дальше поверх этого туннеля трафик бегает на всех соседей одновременно. Эта штука проприетарная, но в сочетании с EIGRP она даёт очень неплохие результаты. Благо EIGRP тоже фирменный цисковский протокол, проприетарный, его больше ни у кого нет. Когда мы говорим про GRE, протокол действительно универсальный в том смысле, что в него можно запихать много разных данных.

Не обязательно внутри него передавать именно IPv4-вложение, можно IPv4, IPv6 и всё что угодно. Он достаточно неплохо NATится, например, если вы захотите, вы можете заставить GRE проходить через NAT. Поэтому, как правило, если говорить про реальный сценарий site-to-site, именно IPv4-туннели строятся достаточно редко, а вот GRE-туннели строятся несколько чаще. В принципе, вы можете сказать, что нам нет смысла тратить дополнительные накладные расходы на GRE-заголовок, потому что если мы берём IPv4-пакет большой и внутри него сразу кладём IPv4-пакет маленький, без транзитного GRE-заголовка, то мы тем самым экономим немножко места на дополнительных заголовках. За счёт GRE мы тратим дополнительные заголовки, но мы что-то приобретаем. Если вы собираетесь отправлять поверх GRE-туннеля только IPv4-пакеты, если вам не требуется проходить через NAT, если вам не требуется гонять какой-то жесткий мультикаст или что-то еще, вам GRE не нужен. Вы можете сразу IPv4-пакет использовать,

и настраивается он по большому счету в Cisco точно так же, как для IPv4-туннелей. GRE различаются буквально одной командой. Если говорить про оборудование других вендоров, то же самое там. IPv4-туннели и GRE-туннели, как правило, настраиваются идентичным образом. Просто разница между ними в том, что у GRE есть дополнительный заголовок, в который можно чего-то напихать, если вам это нужно. А у IPv4 идет сразу IP-заголовок один, а потом IP-заголовок другой. Поэтому вы должны будете сами для себя решить, нужен ли вам этот дополнительный заголовок GRE или нет. Мы в рамках курса предположим, что он вам нужен и, соответственно, посмотрим на то, как строятся туннели GRE через интернет. Довольно частый сценарий. У нас есть офис один, у нас есть офис другой. В одном офисе сетка 10.0.1.0, в другом офисе сетка 10.0.2.0. Нам нужно между собой эти два офиса связать, чтобы трафик мог идти от 10.0.1.1 до 10.0.2.1.

Между этими двумя узлами должно быть IP-взаимодействие. Если мы такие пакеты просто направим в интернет, они там, естественно, будут расстреляны. Если мы связываем между собой два офиса, то у нас здесь цепочка роутеров интернетовских, провайдерских. Естественно, как только мы промаршрутизируем такой пакет в сторону интернета, здесь нам такие пакеты пристрелят. Но мы можем сделать ход конем. Мы можем взять этот IP-пакет, который у нас есть, и обернуть его новым IP-заголовком, сделав вид, что оригинальный IP-пакет — это просто вложение, какие-то пользовательские данные. Соответственно, у нас получится IP-пакет, который несет в себе другой IP-пакет. И у этого нового заголовка, который мы дорисуем дополнительно, мы пропишем публичные адреса — не эти частные 10.0 чего-то там, а те публичные IP-шники, которые соответствуют концам туннеля. Например, в нашем случае у нас есть два роутера, у них публичные IP-шники 192.0.2.1 и 203.0.1.2. У нас есть этот зеленый пакет, мы его кладем

внутрь большого черно-желтого пакета, и в черно-желтый пакет мы пишем адрес источника — публичный IP-шник отправителя, адрес назначения — публичный IP-шник получателя. Такой пакет по интернету бежит, бежит, бежит, доходит до роутера получателя. Тот говорит: я вижу внутри GRE-шное вложение, это вложение пришло именно персонально мне. GRE-шные пакеты будут отличаться от остальных тем, что у них код вложения в IP — 47, такое хорошо известное вложение GRE. И он говорит: окей, это означает, что пришел какой-то инкапсулированный пакет IP, надо эту шелуху снять, внешний IP-заголовок убрать, GRE-шный заголовок убрать, и внутри останется то, что мне пришло по виртуальному туннелю. Фактически у нас получается такой виртуальный провод, в котором трафик передается от одного узла до другого. IP-пакет отсюда вытаскивается и направляется в таблицу маршрутизации, отправляется по таблице назначения. Таким нехитрым образом

работает GRE. Узел отправителя, когда понимает, что надо трафик отправить в GRE-шный туннель, заворачивает данные, которые отправляются в такой туннель, в новый заголовок. Узел получателя, когда видит, что трафик пришел на него и внутри лежит код вложения 47, он все дополнительные заголовки счищает и получает оригинальное вложение. У GRE очень простой заголовок. Очень простой, но в то же время он может разрастаться и становиться довольно сложным. Базовый заголовок GRE будет содержать в себе только 4 байта. Эта первая строчка есть у абсолютно любого GRE-шного вложения — 4 байта. Первый бит будет указывать, есть ли вторые 4 байта. Если первый бит будет 0, то заголовок будет состоять просто из 4 байт. Если здесь будет стоять единичка, он будет состоять из 8 байт. Здесь этих флагов на самом деле довольно много может быть. Я вам показал самый простой GRE, который только может быть. Но в принципе здесь могут быть еще дополнительные

4-байтовые поля, которые тоже будут относиться к GRE. Там может быть, например, тип туннеля, ключ туннеля. Если вы хотите, чтобы у вас одновременно несколько туннелей строилось между двумя точками, вы можете сказать: эти пакеты будут относиться к одному туннелю, эти пакеты — к другому туннелю. Но это все опционально и не обязано поддерживаться разными роутерами. А то, что на картинке, это должно поддерживаться абсолютно всеми. Поэтому стандартный размер заголовка — либо 4 байта, либо 8 байт, в зависимости от этого бита. Если у нас здесь первый бит 0, соответственно, всего остального нет. Если первый бит единичка, то здесь у нас будет checksum. Checksum такая же, как в IP, такая же, как в ICMP, такая же, как в TCP, в UDP. Это checksum с протоколом internet checksum. И все остальное будет забито нулями. Здесь будет куча нулей. Фактически этот бит означает, есть ли checksum или нет. Если вам требуется checksum, заголовок 8 байт. Если вам не требуется checksum,

заголовок 4-байтовый. Дальше. Здесь все нули. Все нули, кроме нескольких первых бит, где указывается, есть ли тут еще всякое разное. Дальше. Тут поле protocol type. Это на самом деле EtherType. Что внутри лежит? EtherType. Тот же самый, который в Ethernet. Если мы говорим, что внутри лежит IP-пакет, будет 0x0800. Если внутри лежит IPv6, 0x86DD. Если хотим, не знаю, ARP отправить, вдруг зачем-то нам нужен ARP — будет 0x0806. Мы можем сказать, что все эти туннели — это, конечно, здорово, что мы их можем построить. Но иногда мы хотим предсказуемого качества. В интернете вы не можете получить гарантию того, что ваши пакеты отправляются и доходят до получателя. Во-первых, сам факт того, что они доходят, вам не гарантирован

никем. А во-вторых, даже если они доходят, они могут доходить с непредсказуемым временем прохождения трафика по сети. Может быть такое, что вы отправляете 10 пингов от одного узла до другого, один потеряется, 8 пройдут за 10 миллисекунд, один пройдет за 90 миллисекунд. В некоторых случаях такое поведение будет неприемлемо. Контролировать его, к сожалению, вы при этом не можете. Если вы используете туннель, который строите сами через интернет, ни прохождение пакетов по сети, ни время задержки вы контролировать не можете. Никак, вообще совсем никак. Вы не контролируете интернет, не контролируете маршрут трафика в интернете. Не контролируете все транзитные узлы. Если вам требуется, чтобы трафик между двумя точками имел предсказуемые задержки, имел предсказуемое качество доставки, и чтобы вы могли контролировать, если вдруг у вас где-то в сети возникает перегрузка, какие пакеты обязательно должны по сети пройти с максимальным качеством, а какими можно пожертвовать, то в этом случае вы можете подписаться на услугу так называемого провайдерского VPN.

Это точно такие же туннели по сути своей, как и в случае с тем же самым IPIP или GRE, только там немножко другие инкапсуляции будут, и за вас их будут строить провайдеры. Когда мы подключаемся к провайдеру в одной точке и говорим: мы хотим вести взаимодействие с другой железкой нашей собственной, которая находится в другой точке, в другом офисе. Провайдер говорит: никаких проблем, присылай мне данные, которые надо будет отправить в такой туннель, я сделаю так, чтобы трафик ходил через мою сеть и доходил до нужной точки тебе в офисе получателя. Эта штука бывает двух разных видов. Первый тип такого рода услуги будет называться L2VPN. L2VPN — это услуга, при которой провайдер прикидывается самым большим свитчом. Вы в одном офисе посылаете обычные кадры Ethernet,

содержащие что угодно. Хотите IPv4, хотите IPv6, хотите CDP, хотите реально что угодно, Spanning Tree. И все эти кадры проходят через коммутатор провайдера, как бы коммутатор провайдера, и доходят до железки в другой точке присутствия. Здесь нарисован один провайдерский свитч. На самом деле эти точки могут быть разнесены очень значительно друг от друга. Может быть такое, что у вас один офис во Владивостоке, другой офис в Калининграде. И действительно между ними очень большое расстояние. Но провайдер прикидывается одним большим мегасвитчом и делает так, чтобы у вас трафик ходил между двумя точками, как будто бы они соединены были через один свитч, через один, если хотите, вообще толстый кабель. Если же вы хотите, вы можете подписаться на другую услугу, которая будет называться L3VPN. И в этом случае вы провайдеру посылаете уже не кадры Ethernet, а IP-пакеты. Провайдерская сеть прикидывается одним таким мега-роутером.

Вы на канальный адрес роутера посылаете IP-пакет, и роутер дальше эти пакеты отправляет на какой-то другой узел, который принадлежит тоже вашей компании, но в другой локации, в другой точке присутствия. Разница между L2VPN и L3VPN заключается именно в том, чем прикидывается провайдерская сеть. В случае с L2 она прикидывается свитчом, в случае с L3 она прикидывается роутером. Если вы используете L3VPN, вам потребуется здесь гонять какой-то протокол динамической маршрутизации. OSPF, BGP. О чем договоритесь, то здесь и будет бегать. Мы при этом, естественно, привязаны к одному и тому же провайдеру. Если говорить про какой-то пример, который можно проиллюстрировать, у вас есть, к примеру, Ростелеком. И вы приходите в Ростелеком в Калининграде, вы приходите в Ростелеком во Владивостоке, и говорите: ребята, мы подключены к вам и там, и тут. Пожалуйста, организуйте нам ваш провайдерский VPN

так, чтобы трафик между Владивостоком и Калининградом проходил за минимальное время, чтобы мы могли разметить трафик, и трафик телефонии ни в коем случае не терялся, а трафик какой-то там, не знаю, торрентов, условно говоря, если мы будем гонять трафик торрентов по такому каналу, он бы был наименее приоритетным и в случае перегрузки сбрасывался бы первым. В таком случае провайдер может с вас взять какую-то маленькую копеечку, он построит такой канал, и он вам будет гарантировать качество прохождения пакетов по сети. Эта штука весьма и весьма дорогая. В зависимости от жадности провайдера, средняя стоимость порта по состоянию лет на пять назад — я сейчас не знаю расценок, но знаю, что она очень сильно варьировалась в зависимости от провайдера — средняя по больнице стоимость порта была порядка 500 долларов США. Если вам надо было две точки присутствия, умножайте на две. Если вам надо было три точки присутствия, умножайте на три. Допускаю, что сейчас цены могут немножко измениться, но тем не менее порядок примерно такой.

Если использовать L3VPN, вам нужно будет с провайдером обмениваться маршрутами, так же, как и в случае с роутерами, которые находятся под вашим контролем. Вы здесь должны будете обменяться маршрутами с провайдером, и он будет ваши маршруты отдавать вам же, но в другой точке. При этом он не перепутает маршруты ваши и маршруты чьи-то еще. Вы здесь можете отдавать частные маршруты, можете сказать 10.0.0.0/24, такой маршрут по OSPF отдать роутеру провайдера, и роутер провайдера вам в другой точке этот же самый 10.0.0.0/24 отдаст. При этом он не перепутает, и у него может быть здесь другой клиент, у которого точно такие же сетки есть, точно такая же сеть 10.0.0.0/24. Он поймет, что вот эта 10.0.0.0/24 — это одна сеть, а вот эта 10.0.0.0/24 — это другая сеть, и их нельзя путать между собой, нельзя роутеру одного клиента отдавать маршрут от другого клиента. Это что касается L3.

В L2VPN есть на самом деле две разные услуги. Что в одном, что в другом случае мы коммутируем кадры, но мы это можем делать несколькими разными способами. В случае, если мы подписываемся на услугу VPWS, Virtual Pseudo Wire Service, это будет просто канал точка-точка. Мы говорим: у нас есть псевдопровод, с одной стороны один узел, с другой стороны один узел, и между ними мы строим этот самый псевдопровод, туннель, если хотите. Есть вариант, при котором провайдер скажет: знаешь, я буду прикидываться именно свитчом-свитчом, коммутатором. Если ты захочешь третий узел сюда подключить, клиент 1, роутер 3, мы можем такую штуку тоже организовать. Но в этом случае со стороны провайдера настройка будет существенно более сложная. И VPLS — это Virtual Private LAN Service. PW — это Pseudo Wire, а PL — это Private LAN.

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

Это что касается теории про VPN. Продолжение следует...