vitus_wagner: My photo 2005 (Default)
vitus_wagner ([personal profile] vitus_wagner) wrote2024-06-25 09:00 pm

Про SSTP

Поисследовал немножко вопрос перевода своей VPN с openvpn на sstp. sstp это фактически ppp over tls. То есть отличить это от веб-траффика существенно менее реально. Правда, наиболее распространенной реализацией sstp-сервера пол linux является softether на который у меня аллергия. Он какой-то цисковский по всей идеологии. а не юниксовый.

Правда, существует еще sstpd. Но он вообще на питоне написан. Зато, правда. заточен на работу за полноценным веб-сервером в качестве frontend-proxy.

Кроме этого вопроса с реализациями у SSTP есть проблема с аутентификацией Почему-то не поддерживается в sstpc аутентификация по клиентским сертификатам. Хотя вроде у микрософта в RAS она была. А тут вся аутентификация спихнута на pppd. А в пароли я как-то не верю в наше время. Даже в CHAP.

Upd Оказывается, в linux-овом pppd версии 2.4.9 и выше поддержка EAP-TLS, в том числе и с использованием аппаратных токенгов все же есть. Правда. исключительно хреново документирована.

[personal profile] borisk 2024-06-25 10:56 pm (UTC)(link)
Fortinet сделали работу с SAML в этом протоколе. Так что можно отдавать вместо пароля session cookie

[personal profile] borisk 2024-06-26 04:20 am (UTC)(link)
Когда на шлюзе VPN стоит только SAML SP, «на сервере» пользовательской информации нет, она вся на SAML IdP.

Проблема с SAML решениями общая со всеми Web штуками — воровство session cookie на клиенте.

[personal profile] borisk 2024-06-26 06:22 am (UTC)(link)
Можно и так.
stanislavvv: (Default)

[personal profile] stanislavvv 2024-06-28 06:19 pm (UTC)(link)
У нас в качестве аварийного входа сделан cloak за одним из вебсерверов с более-менее приличным путём. В нём включили проброс для обоих вариантов openvpn (upd и tcp) и для некоторых любителей — wireguard. С точки зрения openvpn, требуется цепляться не к целевому серверу, а к 127.0.0.1:1984, в остальном всё работает как работало, включая немодифицированный сервер на удалённой стороне.
На sstp пытались смотреть, но тоже не осилили клиентские сертификаты, на которых у нас построена бОльшая часть доступов.
stanislavvv: (Default)

[personal profile] stanislavvv 2024-06-29 06:27 am (UTC)(link)
Собственно, cloak выбирался в спешке и в том числе с целью минимизации вмешательства в инфраструктуру из того, что умело и udp тоже. Просто проверили — работает. В моменты "учений" используется, в основное время — лучше без него, так как +50мс телефонию не радует.
Openconnect — штука хорошая, есть планы по переезду на него, но это пока только планы, потому не упоминал.

[personal profile] 0xfeedca75 2024-07-10 10:34 am (UTC)(link)
Проблема современного VPN в том, что он должен быть малообнаружимым. Все типовые протоколы заранее известны и детектируются (и если не блокируются, завтра будут).

pppd -- это хорошая идея для использования совместно с чем-то другим. pppd лишь заворачивает траффик в последовательный канал, а дальше этот последовательный канал может быть каким-то образом завёрнут в SSL, где уже будет авторизация на основе сертификатов и т.п. Впрочем вместо pppd кажется подойдёт и vtun.

К сожалению, в linux'овом pppd всё плохо с multilink. Оно толком не работает, виснет, куда-то пропадает траффик. Я не разобрался. Multilink был бы интересен, чтоб обойти такую проблему TCP, что одни пакеты в канале не могут обгонять другие и когда буфер сокета уже заполнен, всё упирается в очередь (даже разные не связанные соединения). Вроде в FreeBSD хороший ppp демон, но он увы не работает в линуксе.

Практически pppd может работать совместно с trojan-gfw например. Впрочем последний детектируется тривиально по размеру пакетов. И в нём течёт память.

[personal profile] 0xfeedca75 2024-07-10 10:39 am (UTC)(link)
Штуки вроде v2ray и т.п. с большим объёмом кода и дичайшими зависимостями (и блобами) пугают. Код не обозрим, делается это всё непонятно кем, и недавние истории с xz намекают, что лучше такого сторониться. Тем более немного разбираясь в вопросе начинаешь понимать, что вот такое нагромождение вовсе и не нужно. Потому, что примеры vtun или trojan (C++-версии) показывают, что вагон кода не нужен. Более того, часто может быть достаточно вовсе socat'а. И то же самое касается клиентов для мобильника. Нормальных, кажется, нет вообще. А там казалось бы задачка: простейший UI на Java, установить SSL-соединение (тоже Java вполне достаточна, зачем длинная цепочка зависимостей не понятно), траффик вынуть из SSL-сокета и переложить в tun/tap. Десятки библиотек нативного кода явно тут не нужны.