Pull to refresh

Comments 43

Вот это накатиииил. Отличная статья. В избранное.
Придерживаюсь правила: не выйти за 100к символов)
IPSec over GRE: данная «похабщина» может быть сделана к примеру если Вы хотите использовать только сертифицированные средства криптозащиты (читай шифрования), но при этом к примеру сертифицированный модуль в циску стоит «нехилую такую копейку» (если все правильно помню порядка 100 тыс. руб), а бюджет ограничен. Тогда вы ставите какой нибудь дешевый «шифратор» с лицензией (какой нибудь VIPNet к примеру). Загоняете в него трафик который хотите шифровать, а дальше пускаете этот трафик до удаленной точки через GRE-туннель.
Дешего, сердито, и не нарушает ФЗ о защите ПДн:)
Ну вообще да, я согласен, если нужно шифровать не весь трафик, а какую-то его часть, например с компьютера бухгалтера, то, вероятно, такая схема и будет.
А вообще статья отличнейшая!
спасибо — написано простым языком о сложном! буду курить дальше! Единственное, что смутило — это «Брно» — это Барнаул? Или абстрактный пункт?
Как всегда, все разложено по полочкам. Спасибо!
Небольшая заметка про Default MTU.

Вендоры по разному показывают MTU на интерфейсах:
— Juniper (1-Port Gigabit Ethernet )
Physical Interface MTU (Bytes) 1514
Logical Interface MTU (Bytes) 1500

-Cisco
IOS (MTU 1500 bytes) — maximum size of the layer-3 payload without the layer-2 header
IOS-XR (MTU 1514 bytes) — includes the L2 header + payload but excludes the 4 byte FCS trailer.

Но по сути, результат тот же: Ethernet MTU = 1500 bytes.
Ну да, кратко я это отметил в статье. Вообще для меня MTU в купе со всем другими параметрами, вроде MFL — просто больное место.
Ethernet – витая пара. До 100 метров. Максимум по зданию или между соседними строениями. Скорость до 1 Гбит/c.
10GBASE-T 10 Гбит/с
Покажите мне, где реально это применяется? Оно, конечно, есть, но смысл?
Вы не поверите, в продукции Cisco например, точно знаю что для 4900 и 6500 серий есть модули. И вообще какая разница где оно применяется и тем более какой смысл, в вашей статье неточность.
Да я не спорю же, что реализации существуют. Естественно, кто-то их использует, но я этого не встречал, плюс кабель нужен 6е.
Ну тогда извините, я думал что это полноценная статья а не частный опыт. До 40 метров линк поднимется и на 5е а дальше уже 6a категория (6е не существует).
Хорошо, я согласен, добавлю в статью это.
Есть фексы под Nexus, битком набитые 10G медными портами и 40G аплинками. Есть соответствующие сетевухи.
UFO just landed and posted this here
Одному мне интернет на фотках напомнил Хабра-лого?
Спасибо за красивую иллюстрацию! Но OpenVPN не поддерживается, как правило сетевым оборудованием. Впрочем, к статье можно добавить.
Негодная табличка. Она рассматривает ровно одну реализацию IPSec VPN — L2TP поверх IPSec, и как раз про нее в статье ни слова не говорилось (так как она используется только для client access, и сейчас на самом деле уже почти забыта). На самом деле реализаций полно.

В conclusion там вообще какой-то бред написан. Но предпосылки понятны: разработчик сервиса рекламирует используемый у него транспорт, потому про объективность дружно забываем.

Сейчас самым популярным в мире механизмом защиты пересылаемых между площадками данных является IPSec, с колоссальным отрывом. OpenVPN — выбор разве что маленьких фирм.
Для RA — набирает популярность SSL VPN.
Интересно, что можно добавить к этой статье, чтобы ее название стало — «Сети для продвинутых»?
На самом деле через 2-3 выпуска вполне можно было бы её и так назвать)
Года полтора назад на, скажем, собеседовании мне был задан вопрос: «У нас сеть с более 50 филиалов. Как ты думаешь, почему мы отказались от использования DMVPN».
Поскольку ни тогда (ни сейчас) с технологией я близко знаком не был, ответа, конечно, не дал. Но поинтересовался правильным ответом.
«Потому что с DMVPN я никак не могу контролировать/ограничивать трафик между споками.»

Прокомментируйте, пожалуйста.
Странно как-то… О каком контроле идет речь?
Ничто не мешает остановиться на phase 1, и тогда получаем чертовски простую конфигурацию и хождение всего трафика через хаб (и будут отлично отрабатывать политики per-tunnel QoS, ACLы и т.д.
Реализация того же самого средствами, отличными от DMVPN — ад и мегабайтные конфиги даже на 50 филиалов.
Я уж не говорю о том, что есть MPLSoDMVPN…
Так что я бы сказал, что и ответ, и даже сам вопрос — неправильные (из-за такой формулировки невозможно ответить на вопрос, заранее не зная детали по требованиям). И мне кажется, кто-то там просто не осилил документацию по DMVPN.

А на чем они остановились в итоге? Какое решение им подходит лучше?
Полагаю, под контролем как раз подразумевались политики per-tunnel QoS, ACLы и т.д.
В итоге, они просто сделали VTI IPSec с хабом и всё бегает через него.
Ну так все это делается на phase 1. Только phase 2 дает динамические туннели. Они точно не осилили документацию.
И автоматический per-tunnel qos (т.е. когда spoke сам сообщает hub'у, какую политику к себе применить) как раз только на mGRE интерфейсах работает. Иначе снова куча туннелей, куча политик, мегабайты конфигурации.
Скорее всего ответ потому, что разные вендоры используются
Нет, там везде Cisco.
Были сложности с написанием QoS политик для трафика Spoke-spoke.
eucariot у Вас ошибка там, где идет вначале про GRE, где делаете
R1#ping 10.1.1.0

и дальше 1-ый пункт формирует пакет без заполнения Source ip, 2-ой пункт смотрит таблицу маршрутизации и выбирает исходящий интерфейс для пакета (для заполнения поля Source ip), потом формирует поле пакета Source ip, там у вас на картинке S 10.0.0.0, а нужно 10.2.2.1 и это видно дальше в снифере.
Согласен, спасибо. Поправлю ping 10.1.1.0 source 10.0.0.0
Кроме того очень актуальна сейчас тема FlexVPN. Это новый виток развития VPN-технологий. Но использует IKE версии 2 и поддерживается в данный момент, как обычно только оборудованием cisco.

Насколько я понимаю, FlexVPN — это новый cli под IKEv2, а последний поддерживается Juniper и различными клиентскими устройствами (в том числе Windows 7).
Насколько я понимаю, FlexVPN — это новый cli под IKEv2

А DMVPN — это всего лишь cli для mGRE + NHRP с опциональным добавлением IPSec? :)
Flex — навороченный фреймворк, базирующийся на IKEv2. Да, он может стыковаться с самыми разными системами (он изначально разрабатывался как универсальный фреймворк под практически все задачи от site-to-site до RA, чтобы избавиться от текущего бардака), но фич больше, когда циска стыкуется с циской.
Ну и да, IKEv2 — баян… Хотя — могу и ошибаться, но у жунипера оно вроде появилось менее двух лет назад (т.е. позже, чем у циски).
А DMVPN — это всего лишь cli для mGRE + NHRP с опциональным добавлением IPSec?

Если используются, то так и есть.

С другой стороны, FlexVPN может повторить успех Active Directory, который тоже является интегрированным фреймворком из LDAP, Kerberos и кучи всего.
Ну я примерно о том и говорю. Говоря о проприетарном фреймворке, не вполне корректно раскладывать его на составляющие.
Он позволяет динамически динамически изучать адреса удалённых точек, который желают подключиться к основной.

Исправьте, пожалуйста — у вас дублируются слова в предложении.
Спасибо, почитаю об этом.

В чём разница между tunnel mode ipip и tunnel mode ipsec ipv4 если и там и там используется tunnel protection? И там и там вроде пакеты выглядят одинаково – [IP ext] [ESP] [IP int] [payload]. Мы вроде в обоих случаях говорим, что нам не нужен GRE, а сразу идёт IP, и в обоих случаях у нас есть IPsec и трафик через туннель шифруется.

Sign up to leave a comment.

Articles

Change theme settings