Порткнокинг- не впн

А женщина не человек

Переходить на ikev2

Можно победить, если не использовать ip в роли идентификатора

Вот я сегодня с ним наигрался. Обнаружил пару подводных камней

У ipsec-esp нет порта

А Причем тут порт?

При том, что как контрек должен понять какому клиенту за натом его прокидываиь?

Кстати, на инпуте по есп трафика по нулям

Да и без этого правила все отлично подключается. По крайней мере с клиентской винды

Пользуясь случаем хочу спросить, был ли у кого опыт kernel тюнинга для high latency сетей, в частности под tcp протокол (может игрались с алгоритмами tcp congestion). Данный вопрос из-за нужды максимально стабилизировать DNS tunnel поверх которого бегает TCP.
MTU, buffer size, txqueuelen уже крутил и особого результата не дало, может как-то нужно подкрутить tcp retries? При пакет капчуре заметил что возможно сервер отправляет клиенту слишком быстро и стоит выдерживать какую-то паузу (от того и вопрос про tcp congestion)

По икев2 да, там удп

попробуй bbr и cake

bbr на днях потестю, а что на счёт westwood?

загугли таблицу сравнения

для high latency специально сделали bic

спасибо за совет, уже смотрю https://haltaro.github.io/comparing-tcp-algorithms/

столкнулся с тем, что рекурсивная маршрутизация для файловера не работает, если в рекурсивном маршруте шлюз провайдера указан через %интерфейс, аля gateway=91.2.1.1%ether4 Эту конструкцию убрать не могу, т.к. есть несколько линков от одного провайдера с адресами из одной сети. Какие могут быть варианты обойти это ? ну кроме как перейти на нетвотч вместо рекурсивных маршрутов

)

в икев1 с нат-т тоже юдп