[freebsd] Нагруженный VPN сервер

[skeletor]

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, что бы потом 
не разбираться почему у кого-то не работает.