Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Отличная статья. По размера охваченного материала вам бы неплохо связаться с создателем цикла Сети для самых маленьких и добавить ее в их библиотечку)
так это они вроде и есть.
Спасибо!
На самом деле по хронологии событий сначала я написал статью для Сетей для самых маленьких и только потом Марат предложил мне опубликовать её здесь)
На самом деле по хронологии событий сначала я написал статью для Сетей для самых маленьких и только потом Марат предложил мне опубликовать её здесь)
Вы забыли предупредить, что Aggressive Mode использовать можно только в случае с PKI. С PSK его использовать нельзя, т.к. он не выполняет аутентификацию сторон.
Это просто прекрасно. Хабр торт!
Могуче! Вот именно такие статьи и создают Хабру славу ресурса, где есть не только корпоративный PR!
sstp уже не сыр?)
Про VXLAN ни слова, хотя вполне себе туннель, причём работающий в интернетах. Алсо, два моих любимых метода организации VPN:
через ssh
через tor с помощью ssh (отлично работает, кстати).
через ssh
через tor с помощью ssh (отлично работает, кстати).
Если Вы имеете в виду VXLAN применительно к Дата центрам (а если точнее то для применению их на Nexus 1000v и проч Nexus ), то это уже немного другая религия под названием «Дата центры», туда же можно было бы отнести и технологию OTV, для объединения нескольких дата центров через IP, но это я сознательно опустил.
Через ssh вполне справедливое замечание и я так понимаю, что она относится к Remote Access? Однако, представьте задачу объяснить, допустим, женщине из бухгалтерии, которой нужно в выходные подключиться к корпоративной сети для сверки баланса, проделать следующее: «запускаете Putty, стучитесь по ssh на такой то IP, авторизуетесь и вуа-ля — теперь можно подключаться на свой лупбэк» ) Если это выглядит как-то по-другому, то поправьте меня.
Через ssh вполне справедливое замечание и я так понимаю, что она относится к Remote Access? Однако, представьте задачу объяснить, допустим, женщине из бухгалтерии, которой нужно в выходные подключиться к корпоративной сети для сверки баланса, проделать следующее: «запускаете Putty, стучитесь по ssh на такой то IP, авторизуетесь и вуа-ля — теперь можно подключаться на свой лупбэк» ) Если это выглядит как-то по-другому, то поправьте меня.
А что мне мешает поднять vxlan через интернеты? юдипя юдипёй. И без мультикастиков работающая.
А для бухгалтерии эта штука во-первых будет «в автозапуске», а во-вторых ярлыком на «рабочем столе». Что там шайтан-майтан ключи сысыха её касаться не должно.
Алсо, при чём тут лупбэк? Я про -w режим. socks proxy — это уже для гурманов и индивидуального использования.
А для бухгалтерии эта штука во-первых будет «в автозапуске», а во-вторых ярлыком на «рабочем столе». Что там шайтан-майтан ключи сысыха её касаться не должно.
Алсо, при чём тут лупбэк? Я про -w режим. socks proxy — это уже для гурманов и индивидуального использования.
За туннели over ssh не в качестве временного workaround, а production-решения, я бы с волчьим билетом выгонял из профессии.
Я бы добавил в описание класс ошибок, связанный с тем, что на одной стороне есть SA, а на другой его нет. Такая ситуация может возникнуть например при перезагрузке одного из роутеров, на котором терминируется IPSEC-канал. В общем случае при возникновении данных условий, сторона, которая имеет SA будет по прежнему шифровать трафик, который не может быть расшифрован другой стороной, т.к. она не имеет соответствующего SA. Данная ситуация может сохраняться в течении lifetime для SA, который по умолчанию кажется что-то около суток. Особенно данная ошибка критично там, где используются dynamic crypto map, т.к. в этом случае обмен пакетами ISAKMP может начать только одна сторона, как правило это spoke, и если там есть stale SA, то это закончится описанной ситуацией. Проблема решается включением isakmp keepalive.
Ну и хотелось бы услышать в статье, чем отличается DMVPN Phase 2 от Phase3. Самое важное архитектурное отличие — Phase3 позволяет строить spoke-to-spoke туннели между разными NBMA.
Ну и хотелось бы услышать в статье, чем отличается DMVPN Phase 2 от Phase3. Самое важное архитектурное отличие — Phase3 позволяет строить spoke-to-spoke туннели между разными NBMA.
Добавьте пожалуйста упоминание о vtun. Простой, надежный, популярный, а упоминания нет. Спасибо.
В Linux есть еще multipoint GRE — получается один виртуальный интерфейс на большое поличество туннелей, масштабируется он заметно лучше одноточечных GRE.
geektimes.ru/post/48276/
Все маршрутизаторы получаются в одной подсети + своя подсеть на каждый офис.
На каждом маршрутизаторе настроен один туннельный интерфейс, независимо от количества офисов.
geektimes.ru/post/48276/
Все маршрутизаторы получаются в одной подсети + своя подсеть на каждый офис.
На каждом маршрутизаторе настроен один туннельный интерфейс, независимо от количества офисов.
mGRE — это часть технологии DMVPN, о которой тут упоминается. Там кроме mGRE задействован ещё NHRP и IGP. Ну и ipsec естественно.
да, mGRE упоминается как часть DMVPN.
Я делаю акцент на том что mGRE доступен в Linux системах из коробки, снимает проблему GRE с кучей туннелей и очень прост в настройке.
Думаю что mGRE вполне может упоминаться в таблице отдельной строкой, наравне с GRE.
Я делаю акцент на том что mGRE доступен в Linux системах из коробки, снимает проблему GRE с кучей туннелей и очень прост в настройке.
Думаю что mGRE вполне может упоминаться в таблице отдельной строкой, наравне с GRE.
GRE и mGRE сам по себе, без ipsec не может считаться VPN-технологией, т.к. он не реализует функции целостности, конфиденциальности, аутентификации и т.п. Это просто туннель, данные идут чистым текстом.
Частично согласен, но тут он ничуть не хуже GRE, который выделен в отдельный тип сети.
Трафик действительно лучше защищать через ipsec, не только из-за секретности, но из-за фильтрации вложенного трафика. Например в моём случае неожиданно внутри GRE без шифрования стал фильтроваться OSPF-трафик, хотя в дата-центре фильтрация выключена — сейчас дата-центр общается на тему этой фильтрации с поставщиком оборудования.
Опять же ipsec не добавляет значительных сложностей с настройкой сети, не добавляет туннелей и т.п. — всё остается прозрачным и может настраиваться автоматически простыми скриптами.
Трафик действительно лучше защищать через ipsec, не только из-за секретности, но из-за фильтрации вложенного трафика. Например в моём случае неожиданно внутри GRE без шифрования стал фильтроваться OSPF-трафик, хотя в дата-центре фильтрация выключена — сейчас дата-центр общается на тему этой фильтрации с поставщиком оборудования.
Опять же ipsec не добавляет значительных сложностей с настройкой сети, не добавляет туннелей и т.п. — всё остается прозрачным и может настраиваться автоматически простыми скриптами.
К VPN технологии отродясь не предъявлялось тех базовых требований к защите данных. Или будете говорить, что MPLS VPN не VPN? Главное и единственное требование, чтобы считаться VPN — эмуляция выделенного канала по ни разу не выделенной инфраструктуре. Да-да, GRE и даже 802.1q — тоже VPN. Ну и любой вид VPN запросто можно назвать туннелем.
Для DMVPN IPSec является лишь необязательным дополнением. Можно запросто работать и без него.
Далее. mGRE — это тот же GRE, но с маленькими отличиями на уровне control plane (адрес получателя пакета не фиксированный, определяется динамически). Обычно для той задачи (определение адреса терминации туннеля по адресу внутри туннеля) используют NHRP.
Без IGP DMVPN поднимается и работает. Формально, наличие IGP настолько же необязательное, как и наличие IPSec защиты. Вот только неудобно без него будет, мягко говоря.
Для DMVPN IPSec является лишь необязательным дополнением. Можно запросто работать и без него.
Далее. mGRE — это тот же GRE, но с маленькими отличиями на уровне control plane (адрес получателя пакета не фиксированный, определяется динамически). Обычно для той задачи (определение адреса терминации туннеля по адресу внутри туннеля) используют NHRP.
Без IGP DMVPN поднимается и работает. Формально, наличие IGP настолько же необязательное, как и наличие IPSec защиты. Вот только неудобно без него будет, мягко говоря.
Главное и единственное требование, чтобы считаться VPN — эмуляция выделенного канала по ни разу не выделенной инфраструктуре.
Голый IPSEC в транспортном режиме эмулирует выделенный канал? Может ли он считаться VPN? Согласен, с терминологией относительно VPN нужно быть предельно осторожным.
Голый IPSEC в транспортном режиме эмулирует выделенный канал?
Трафик идет по общей инфре? Да. Есть изолированная труба? Да. Нюансы того, какие инкапсуляции добавляются к трафику и как он заворачивается в трубу, кого-то интересуют? Нет.
Очень не хватает фразы «туннели на маршрутизаторах Cisco» в заголовке или в первом абзаце статьи.
Другими словами: в статье хорошо описаны варианты туннелей, которые реализуются на оборудовании Cisco. Все прочие варианты даже не упомянуты, например, Ethernet over IP, OpenVPN,…
Если говорить о преимуществах, многими любимый OpenVPN масштабируется ничуть не хуже IPSec.
Другими словами: в статье хорошо описаны варианты туннелей, которые реализуются на оборудовании Cisco. Все прочие варианты даже не упомянуты, например, Ethernet over IP, OpenVPN,…
Если говорить о преимуществах, многими любимый OpenVPN масштабируется ничуть не хуже IPSec.
многими любимый OpenVPN масштабируется ничуть не хуже IPSec.
Верю. Потому что голый IPSec не масштабируется. Слишком трудоемкое у него сопровождение.
Для DMVPN с хабами из линейки ASR1k цифры в несколько тысяч узлов на облако (с кучей сервисов вплоть до переключения трафика на резерв за пару секунд в случае появления небольших потерь пакетов, и с гигабитами трафика) вполне достижимы и легко сопровождаются (конфиги всего связанного с DMVPN могут быть в буквальном смысле под копирку, даже IP адреса можно не вводить => работа легко скриптуется). Если строить многоуровневые иерархии, то можно десятки тысяч узлов получить.
По поводу EoIP — если он потребовался между площадками, то вы что-то делаете не так.
Опять подразумеваете Cisco :-D
Конкретно EoIP на DD-WRT пришлось сделать в одном месте из-за ограниченности бюджета заказчика. (Ничего другое просто не влезало в маршрутизаторы-мыльницы с 2 Мб NVRAM.) Обычно же я предпочитаю OpenVPN и IPSec, в некоторых случаях PPTP.
Конкретно EoIP на DD-WRT пришлось сделать в одном месте из-за ограниченности бюджета заказчика. (Ничего другое просто не влезало в маршрутизаторы-мыльницы с 2 Мб NVRAM.) Обычно же я предпочитаю OpenVPN и IPSec, в некоторых случаях PPTP.
Конкретно EoIP на DD-WRT пришлось сделать в одном месте из-за ограниченности бюджета заказчика. (Ничего другое просто не влезало в маршрутизаторы-мыльницы с 2 Мб NVRAM.)
Вот я и говорю — «что-то делаете не так» :)
Обычно же я предпочитаю OpenVPN и IPSec, в некоторых случаях PPTP.
OpenVPN на нормальном оборудовании не поддерживается. Впрочем, для SOHO сгодится. Голый IPSec — кошмар в сопровождении (плавал с сотнями узлов, знаю). PPTP — просто кошмар со всех сторон, у него фактически нет безопасности, проще уж тогда GRE сделать.
У нас разные критерии нормальности :). Я работаю как раз в сегменте SOHO.
Про «голый» IPSec никто и не говорит, он подходит для соединения двух, максимум трёх точек (дальше сложность становится неприемлимой). Однажды понадобилось соединить две площадки с резервированием — сделал на IPSec+BGP, пришлось потрахаться, чтобы заработали линки 2х2.
IMHO, «ниша» PPTP — дистанционные пользователи с голым Windows, в том числе мобильные и/или за NAT.
Про «голый» IPSec никто и не говорит, он подходит для соединения двух, максимум трёх точек (дальше сложность становится неприемлимой). Однажды понадобилось соединить две площадки с резервированием — сделал на IPSec+BGP, пришлось потрахаться, чтобы заработали линки 2х2.
IMHO, «ниша» PPTP — дистанционные пользователи с голым Windows, в том числе мобильные и/или за NAT.
Я работаю как раз в сегменте SOHO.
Искренне соболезную :) Я больше привык к более серьезным инфраструктурам, мне сложно осознать проблемы SOHO. Вот например я прочитал ваше сообщение и вообще не понял, с чем там можно трахаться в процессе настройки двух линков между двумя площадками с относительно равномерной балансировкой трафика и резервированием — типовая задача, делов на 10 минут от силы.
«ниша» PPTP — дистанционные пользователи с голым Windows, в том числе мобильные и/или за NAT.
PPTP — сложный с сетевой точки зрения протокол, вовсе не обязательно заработающий нормально через NAT (зависит собственно от делающей NAT/PAT коробки). Почему не SSTP к примеру (TCP, пролезет в любую дырку), или не L2TP/IPSec (который тоже непрост, но куда более распространен)?
Опять же, «PPTP» и «безопасность» — не слишком пересекающиеся понятия. Ну и приличных коробок, умеющих терминировать много сессий, нет.
голый IPSec не масштабируется. Слишком трудоемкое у него сопровождение.
Это не совсем корректно. Вы говорите только об одном аспекте масштабируемости, причём не самом важном, так называемом административном оверхеде. Да, поддержка большого количества туннелей — это головная боль для администратора. Но чем в этом смысле IPSEC хуже, например, full-mesh mpls-TE, где на каждом устройстве может терминироваться тысячи туннелей? На IPSEC ничто чисто технически не мешает построить очень большую сеть, поэтому, всё же, основной ограничивающий фактор масштабируемости ipsec — это топология spoke-and-hub, которая тянет за собой большую нагрузку на хабы по трафику, и увеличение delay в случае телефонии или видео между spoke-сайтами. Развитие DMVPN подтверждает это, т.к. только первая фаза решала проблему административного оверхеда. Вторая и третья фаза направлена на решение более острой проблемы масштабирования — разгрузить хабы от трафика и уменьшить задержку путём ввода spoke-to-spoke туннелей. Кстати, в статье нет ничего про отличие второй и третьей фазы, хотя бы архитектурно. А раз мы говорим про масштабирование, это очень важно. Вторая фаза имела серьёзные проблемы с масштабированием, т.к. она требует использование daisy-chain. Вторая проблема — невозможность создавать spoke-to-spoke между роутерами, которые находятся в разных NBMA. Третья фаза очень эффектно решает эти ограничения.
Вы говорите только об одном аспекте масштабируемости, причём не самом важном, так называемом административном оверхеде.
Не сказал бы. В небольших или средних сетях (где цифра узлов не более трехзначной) в другие аспекты упереться сложно. А этот напрямую влияет на стоимость сопровождения решения, как и на общую стабильность сети (зоопарк конфигураций — плохо, единая конфигурация на всех — хорошо)…
Но чем в этом смысле IPSEC хуже, например, full-mesh mpls-TE, где на каждом устройстве может терминироваться тысячи туннелей?
Ничем. TE еще более ужасен. И там реально рабочих альтернатив нет. Потому приходится всякие сторонние решения закупать для автоматизации сопровождения. Ручному сопровождению это не поддается.
основной ограничивающий фактор масштабируемости ipsec — это топология spoke-and-hub, которая тянет за собой большую нагрузку на хабы по трафику, и увеличение delay в случае телефонии или видео между spoke-сайтами.
А вот со spoke-to-spoke туннелями возникает ряд очень трудных вопросов, и нередко правильным ответом на них будет «запретить динамические туннели и пускать всё через хаб».
К примеру: для голоса и видео фиксированная задержка в 100-200мс не страшна, а вот пара процентов потерь или джиттер в 50мс — почти фатальны. Если вы строите VPN инфраструктуру поверх интернета — у вас нет QoS для входящего в любой конкретный офис трафика. Вообще нет, ни в каком виде.
Есть интересное решение — per-tunnel QoS. Вроде все здорово — спок сообщает хабу, какие политики к нему применять (шейпер и внутри него приоритезация), и из канала спока становится возможно выжать 100% емкости без проседаний приоритетного трафика. Но вдруг строится динамический туннель до другого спока — и вся схема летит к черту, PE у спока начинает получать трафик больше CIR (хаб ведь не знает, сколько трафика второй спок вдруг вздумает влить в третий в данный момент времени), и соответственно PE без разбора дропает этот трафик вместе с голосом и видео.
И если на хабе можно накидать побольше емкости, чтобы там не было дропов во входящем к нему направлении (обычно в разы менее нагруженном, так как споки чаще качают, чем передают) — со споками это уже не реалистично. И дорого, и все равно периодически найдется чем прогрузить канал под завязку.
Так что да, многие предпочитают вариации на тему phase 1 (не обязательно «tunnel destination», можно и phase 2-3, но со сломанными динамическими туннелями). Которая все-таки вполне нормально масштабируется. Масштабирование ведь зависит от двух вещей:
1) Data plane. Емкость каналов + возможности железа, первое решается не слишком дорого, если говорим про небольшое число каналов, а для второго есть ASR1k, для которых гигабиты трафика со всеми сервисами — не нагрузка.
2) Control plane. Например, отсутствие суммаризации как в полноценном phase 2 — сильный ограничивающий фактор в связи с экспоненциальным ростом нагрузки на всех при добавлении новых узлов (так как в сети на тысячи узлов постоянно что-то происходит, слабенькие споки рано или поздно просто захлебнутся от апдейтов, если станут обмениваться маршрутной информацией), ну а если споки не знают друг друга — вопрос только к хабу, и у того же ASR1k хватит ресурсов RP для работы с тысячами споков разом в таком сценарии. Даже после рестарта он сумеет поднять все соседства разом за несколько десятков секунд, без всяких нестабильностей в процессе этого дела, без повторных ребутов из-за диких перегрузок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поговорим о VPN-ах? Типы VPN соединений. Масштабирование VPN