04.10.2018 20:56, Eugene Grosbein пишет:
04.10.2018 17:35, skeletor write:
Учитывая, что GRE почти везде заблокирован, остаются варианты:
Неправда, что "GRE почти везде заблокирован" - правда, что он не пролазит через
NAT
мобильных операторов связи (и ещё у некоторых). С публичными IP у GRE нет
проблем.
Правда, и NAT в моём случае (и не только в моём) был не при чём: тесты были и с
NAT'ом и без NAT'a и на разных провайдерах.
Осталось ещё пару провайдеров, где нормально проходит GRE, но таких единицы.
Я не верю в это и вот почему: в отсутствие NAT пакеты IP с GRE внутри
для маршрутизатора ничем вообще не отличаются от пакетов IP с TCP внутри
и роутятся точно так же и чтобы их резать, провайдеру нужно выполнять
дополнительные действия непонятно зачем, заодно нарушая RFC 1812
Requirements for IP Version 4 Routers.
Кроме NAT, я знаю только одну реальную причину, когда такое действительно может
быть:
если пакеты GRE идут фрагментированными и за счёт этого маршрутизатор вынужден
форвардить их
программно процессором вместо того, чтобы обрабатывать аппаратными ASIC на
платформах типа
Cisco 7600 - и в таком случае GRE-фрагменты могут дропаться, но это решается
отказом
от больших пакетов GRE (уменьшением MTU), чтобы они не фрагментировались.
Ну и да, ещё в ранних версиях Cisco IOS были баги, из-за которых транзитный GRE
мог тупо дропаться из-за багов в CEF, но это было очень давно.
Может быть, ваши тесты тоже уже утратили актуальность - как давно они были?
Нынешняя реальность - GRE без NAT пролазит через интернет без проблем.
В теории оно возможно так и есть. На практике, совсем иначе. Итог - GRE
не проходит. Причин может быть много, и разбираться с каждым клиентом
почему у него не проходит GRE - ещё то занятие.
Тесты мои проходили около 2-х лет назад.
- l2tp: что бы использовать без ipsec'a, нужно лезть в реестр винды
Не нужно, начиная с Windows Vista есть галка в свойствах VPN-подключения.
Я на 7-ке не нашёл это галочки. Подскажите, как она выглядит/называется?
У меня уже нет Vista и семерок, и на Win 8.1 я тоже её не нашел.
Может быть, я ошибся насчет галки или перепутал с чем другим за давностью
времён,
но это и неважно - l2tp/ipsec нынче работает без проблем.
с ipsec может и без проблем работает, но вот без него (а разговор был
именно об l2tp без ipsec) - у меня тоже не вышло запустить. после правок
в рееестре - проблема была решена.
L2TP/IPSEC для клиента гораздо легче в настройке, так как клиент нынче
встроен практически во все платформы из коробки и нужно прописать только
адрес сервера, psk, логин и пароль для PPP.
Настройка сервера (racoon) под встроенный клиент тех же платформ не сложнее
настройки openvpn.
Не соглашусь с вами, и вот почему: когда у вас в клиенте стоит поддержка IPsec
и выбрать там можно только 1-2 параметра,
Вообще не нужно ничего выбирать.
это не означаете что это просто. Это ад!!! У одного только ikev2,
Назовите клиента, который не поддерживает l2tp/ipsec с ikev1.
у второго только ikev1,
Для l2tp/ipsec это нормально.
у третьего поддерживаются только некоторые cipher'ы,
И этого достаточно - серверу надо просто включить все возможности.
Ну, кроме des (3des можно оставить).
у чётвертого только сертификат,
Имя в студию.
Постараюсь вспомнить
а у пятого только pre-shared key и всё это можно узнать только отдебажив на
стороне сервера.
И подключения каждого клиента - это квест. А, и это ещё не всё! Весёлая
проблема клиентов за NAT'ом.
Есть патчи, но у меня они не заработали (точнее патчились, но толку 0).
Это всё устаревшая информация. Начиная с FreeBSD 11.1, всё работает из коробки.
Да, я пробовал на FreeBSD 9.X/10.X, Собственно, после этого отпала вся
охота с ним возится.
Точно такая-же весёлая проблема и сервера за NAT'ом.
Это больше проблема виндоклиентов, которым надо редактировать реестр (и то один
параметр),
но в контексте FreeBSD на маршрутизаторе она вообще не актуальна.
А ещё, дебаг - просто песня, понять-то что не так, не всегда можно, а если и
можно, то непонятно как решить.
Может когда-то давно это и было просто, когда все сетапили по одному мануалу,
но сейчас, ИМХО, уже далеко не так просто.
Теперь OpenVPN. Есть конфиг сервера, есть такой же конфиг
(где такие же cipher'ы, такие же параметры компрессии, такие же наборы
сертификатов,...)
клиента. Всё! Вы просто отдаёте его клиенту и неважно на каком девайсе он
запущен,
оно а 99% будет работать. Идём дальше, openvpn прекрасно работает за NAT'ом,
как клиент, так и сервер. Порог вхождения настроек значительно ниже, чем у
IPSec'a. Дебаг и поиск проблем гораздо удобнее.
Это всё можно сформулировать короче - вы умеете готовить openvpn (есть опыт),
но не умеете готовить IPSEC.
Нынче это совсем не сложно.
Кроме того, у openvpn есть свои недостатки. Он не совместим ни с чем, кроме
самого себя
(попробуйте запустить его на Cisco ASA, например; а вот IPSEC там есть) и иногда
не совместим с собственными старыми версиями. Он гоняет трафик через userland
и поэтому на порядок сильнее нагружает процессор. Его авторы слабо разбираются
в сетях и реально легко его использовать только в простейших сетевых
конфигурациях.
Запустить протоколы динамической маршрутизации через туннели openvpn,
интегрировать их в SNMP-мониторинг по-отдельности или в какую другую систему
управления сетевыми интерфейсами задача весьма нетривиальная и в некоторых
случаях вообще не решаемая.
Недостатки есть у всего, но вместе с тем его преимущества значительно
перевешивают его недостатки. И это совсем не означает, что его нужно
пихать везде (где он не сильно подходит). Просто в данном контексте,
ИМХО, он подходит больше. У ТС'а не было задач по интеграции SNMP или
динамической маршрутизации.
Насчёт версий несовместимости - не совсем правда. Вся загвоздка может
быть в переименовании параметра, что решается просто выкладке новой
версии конфига.
И да, мне так и не удалось победить IPsec как VPN сервер для множества
клиентов (соединение точка-точка между *nix системами с некоторыми
усилиями всё же удавалось поднять), особенно Windows. Зато с этой целью
справился openvpn.
Повторюсь ещё раз: если бы мне поставили задачу поднять VPN сервер на
500-1000 клиентов, я бы не задумываясь выбрал бы openvpn, что бы потом
не разбираться почему у кого-то не работает.
_______________________________________________
freebsd mailing list
[email protected]
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
