Microsoft Way

Маршрутизируемая сеть через ssh туннель

В сетях подвижной радиосвязи, периодически, видимо, по велению голосов в голове и без малейших предупреждений, некие, явно набранные по объявлению на трамвайной остановке чудо-специалисты, вместо распространения новых сетевых политик на частных абонентов, применяют их на всех.
И честно оформленное на юридическое лицо подключение, где сумма оплаты по ежемесячному тарифу в страшном сне не привидится Васе-колхознику с прошитым смартфонным тарифом модемом, вдруг оказывается, скажем так, сильно лимитированным по качеству сетевого доступа.
А техподдержка этой вашей йобты делает вид, что вовсе ничего подобного происходить не может. Не режется wireguard udp как подозрение на работу с торрентами, притом, что по корпоративному тарифу нет и такого запрета: хоть бы ими и качать весь нужный архив образов свободных ОС.
По их же словам, оказывается, резкое падение пропускной способности всех openvpn подключений никак не связано с работой dpi систем и лишь с флуктуациями уровня сигнала. Да-да, а отчего же и почему же одновременно с этим параллельный https коннект до ровно той локации, где и терминируется туннель, показывает совсем другую скорость. Да, другую на порядок. Да, буквально.
Но решение правовых вопросов в части неустоек оставим юристам. А кадровых вопросов — HR департаменту самого оператора подвижной радиосвязи.

Наиболее быстрым способом нивелировать технические последствия кадрового голода у оператора подвижной радиосвязи, является заворачивание openvpn туннеля внутрь ssh.
То есть на стороне-клиенте запускаем туннель
ssh -fL 127.0.0.1:1149:127.0.0.1:1194 -N remotun@gamadrily.ru -i /etc/sshkeys/keyforhq
Где 1149 произвольный локальный порт, 1194 — порт сервиса на стороне openvpn сервиса. Разумеется, для этого openvpn сервер должен представлять из себя не чухонскую коробку с корродированными элементами резьбового крепежа. Что не всегда по факту так, поскольку уровень производительности коробок enterprise сегмента у тех чухонцев неплохой, не смотря на все ограничения.
И, разумеется, сервер должен быть доступен по ssh. Последнее, впрочем, при его (ssh) отключенной парольной авторизации существенной проблемой не является.

Далее на стороне-клиенте достаточно изменить в настройках подключения myserverpublicip 1194 на 127.0.0.1 1149 и сделать рестарт процесса.
Весь маршрутизируемый трафик пойдет по прежним, ранее настроенным, правилам. Более никаких изменений вносить не нужно.

Единственное, но, несомненно важное, здесь то, что, фактически, трафик будет подвергаться шифрованию дважды: в туннеле vpn и затем в транспортном ssh туннеле.
И, конечно же, возможное падение производительности есть смысл измерить опытным путем. Хотя бы в неких относительных значениях.
Возьмем опытный стенд из двух машин соединенных линком, заведомо более скоростным, чем типичный в публичных сетях.
Тестирование будем проводить использую утилиту iperf3, то есть результаты будут оценочными, впрочем, иного и не требуется.

Прямое соединение:
iperf3 -c 192.168.128.150 -t 30 -P 16 -w 32768
[SUM] 0.00-30.00 sec 8.37 GBytes 2.40 Gbits/sec

Поднимем ssh туннель:
ssh -fL 127.0.0.1:5201:127.0.0.1:5201 -N adm001@192.168.128.150
iperf3 -c 127.0.0.1
— а у меня друг вчера сервер сломал
— он что, хакер?
— нет, он дурак
В целом, примерно 1.50 Gbits/sec Но стенд падет. Несущественно, это частная проблема с аппаратным обеспечением стенда.
Для общего понимания, тем не менее, данных достаточно.

Измерим производительность, не меняя настроек openvpn туннеля
Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key
iperf3 -c 192.168.124.209 -w 32768 -t 30 -P 16
[SUM] 0.00-30.00 sec 1.31 GBytes 376 Mbits/sec

Полностью отключим все шифрование в openvpn туннеле (cipher none, ncp-disable, #tls-auth)
iperf3 -c 192.168.124.209 -w 32768 -t 30 -P 16
[SUM] 0.00-30.00 sec 1.97 GBytes 564 Mbits/sec
Это заведомо не является производственной конфигурацией, т.к. отключение необходимо произвести для всех клиентов сервера.

Предыдущие тесты, хочу напомнить, были поверх ssh туннеля. Хорошо, а что бы было без него?

При включенном шифровании
[SUM] 0.00-30.00 sec 2.57 GBytes 736 Mbits/sec

При отключенном шифровании
[SUM] 0.00-30.00 sec 3.10 GBytes 887 Mbits/sec

Если к тому же включить сжатие
[SUM] 0.00-30.00 sec 3.19 GBytes 913 Mbits/sec
В реальном мире реальных данных, конечно же, вместо повышения показателей была бы просадка.
Так как даже внутри закрытого сегмента сетей подавляющее большинство данных передается в несжимаемом виде (обернутыми в ssl, tls).

Еще пара странных вырожденных случаев.

Включенное сжатие для ssh туннеля, при отсутствии шифрования на участке vpn.
[SUM] 0.00-30.00 sec 1.20 GBytes 344 Mbits/sec

Включенное сжатие для ssh туннеля, при включении шифрования на участке vpn.
[SUM] 0.00-30.00 sec 734 MBytes 205 Mbits/sec