В чем разница между подходами шифрования в l2tp ipsec на mikrotik?

Question

[FloorZ]

Ниже есть скрин.

Экспериментируя и разбираясь с ipsec и туннелями, получилась такая вещь (принцип работы l2tp и ipsec я очень слабо знаю).
Первое - Это шифрование идет внутри l2tp туннеля, между точками всего трафика.
Второе - это шифрование udp трафика l2tp, внутри которого наш туннель.

В обоих случаях, если я не ошибаюсь, логин/пароль самого l2tp передается зашифрованным mschap2

Если кто может объяснить. В чем в принципе разница между этими подходами? В плане производительности и безопасности. Ведь и так и так зашифровано (а можно наверное одновременно и udp трафик по верх зашифровать и данные внутри туннеля зашифровать).
Хотя в первом случае, они не обменяются SA до тех пор, пока от кого то не пойдет трафик внутри туннеля.

Answer 1

[Клёвый Админ]

Не очень понятно о чём речь, если речь о различия туннельного и транспортного режима, то они не особо отличаются по способу шифрования или по безопасности, но разительно отличаются по удобству построения сети и по надёжности в разных условиях.

Comments

[FloorZ]

в обоих случаях tunnel no стоит же.
В первом случае идет шифрование внутри туннеля. Во втором случае по верх туннеля. Если в двух словах. Сам туннель строит l2tp

[Клёвый Админ]

FloorZ: теперь понял про что вы. В таком случае, второй (по скрину) подход безопаснее, если канал построения туннеля будет зашифрован чем то вроде sha1\sha256 и сильнее (я не криптограф, не могу в лоб сравнить надёжность передачи пароля внутри mschap2 и 3des).

Т.е. IPSec может быть безопаснее чем туннель, так как может использовать хорошие алгоритмы шифрования, в случае с туннелем же, опций по шифрованию у вас нет.

Ну и мой совет из опыта, всегда шифровать между внешними точками (если этому не препятствует NAT). Это гораздо проще обслуживать, проще переложить туннель, проще строить сеть с использованием нескольких туннелей.

[FloorZ]

Евгений Быченко: уточню. Во второй строке идет шифрование udp трафика по порту 1701. Это транспортные пакеты l2tp туннеля. (т.е. сама авторизация не шифруется сверху дополнительно)

Я в свое время строил просто GRE + IPsec и статику прописывал. Но система была очень не гибкой. Особенно там, где не было статики, наты провайдеры и постоянно двигающийся клиенты.
Замутил L2tp, плюс динамическую маршрутизацию, все нравиться, но как все таки правильнее ipsec готовить - не знаю. С одной стороны по верх мы шифруем только udp пакеты, внутри которых все данные, всего два SA у нас на два соединения, но т.к. правила policies генерируются автоматически, надо прописать несколько доп правил policies для 1701, иначе злоумышленник может заблокировать IPsec трафик и вынудить микротик не использовать шифрование, т.к. правило не будет сгенерированно.
Во втором случае, нам не надо теоретически пробрасывать порты на натах для ipsec, да и вообще париться с портами и роутингом, т.к, трафик шифруется уже непосредственно внутри туннеля. Но количество SA меня пугает. Так же тут гарантировано будет генерироваться политики.

[Клёвый Админ]

FloorZ: мыслите верно. Если параноить (или просто переживать) за шифрование, то резоннее строить l2tp (там где есть NAT), поверх него GRE+IPSec (там где NAT нет - просто GRE+IPSec).

Ну и, а что мешает во втором правиле делать 255 (all)?

[FloorZ]

Евгений Быченко: это правило сгенерировал клиент windows.

[Клёвый Админ]

FloorZ: если сделать готовый темплейт и применить его к пиру? заведётся коннект?

[FloorZ]

Если сделать правило на весь трафик этого клиента, то клиент виндовса не сможет авторизоваться, т.к. винда шифрует только сам udp трафик, а авторизация по mschap не пройдет.

[FloorZ]

Все таки я прихожу к выводу, что надо шифровать только UDP трафик по порту 1701, т.к. часть клиентов l2tp не позволяют шифровать по верх весь трафик или непосредственно внутри туннеля.