по-хорошему вообще клиенту надо использовать системное хранилище корневых сертификатов, чтобы таких проблем не было.
хотя хз, может это как раз Google Trust CA есть только в браузерах, а в виндовой коллекции нет.
На виртуалке не заводится без Qt, если что)
Process fptn-client-gui not found.
No TUN interface found.
[2025-09-29 11:12:02] [info] [logger.h:88] Logging to file: /var/log/fptn/fptn-client-gui.log
[2025-09-29 11:12:02] [info] [logger.h:89] FPTN version: 0.3.23
[2025-09-29 11:12:02] [info] [fptn-client-gui.cpp:57] Application started successfully.
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “/opt/fptn/qt6/plugins/platforms” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: xcb, offscreen, vnc, linuxfb, minimal.
А что за виртуалка? Установка deb-пакета прошла штатно? Напишите, пожалуйста, мне в телеграм - @qwervgg. Здесь у меня ограничения на ответы: то раз в час, то через 6 часов…
У меня ещё вопрос/предложение, можно ли сделать билд статического самодостаточного бинаря под линукс, который можно просто брать и запускать, помимо .deb пакета? Сейчас он требует установки большого количества зависимостей, хотелось бы иметь возможность запускать на машинах без доступа к репозиториям.
Без этого
- Сервер тривиально выявляется сканированием. Пока его у нас не практикуют, были только отдельные сообщения об Followup active probing, но могут начать.
- Сервер потенциально работает как прокси для всех, а не только для разрешённых клиентов. Найдёт какой-нибудь умник - будут потом километровые счета за трафик и письма с жалобами.
И вопрос ещё, что из этого бОльшая проблема.
Иметь такое решение полезно, но имея прокси, можно поверх него развернуть любой стандартный VPN (OVPN, WG, ..) и свести задачу к предыдущей.
даже на этом форуме люди таким сталкивались, да
Завелось после apt --fix-broken install
Но работает только Limited access server в Питере, остальные сервера недоступны.
Подключение виртуалки через VPS в Швеции.
Как временная мера до доработки, его можно разместить за nginx без терминации ssl, а в нём через ngx_stream_ssl_preread_module задать разрешённые sni.
В форуме, где я вчера случайно узнал об этой программе, сказано, что она позволяет обходить белые списки. Это относится только к проверке цензорами SNI, или FPTN каким-то образом их обходит также при проверке IP-диапазонов (CIDR)?
(речь, конечно же, об использовании клиента FPTN с сервером, предоставляемым разработчиками)
Привет! Сканируем сети, выявляем которые из них работают при “белых списках” и далее там размещаем сервера. Против лома CIDR - нет другого приема
надеюсь, полноценный full-cone для UDP?
Чисто для себя вопрос, а возможно ли мимикрировать не мимикрируя
1. VPN клиент посылает Client-Hello от Chrome с разрешённым SNI из белого списка, допустим ozon.ru по прежнему используя session_id для определения свой-чужой
2. Далее сервер смотрит SNI и реально создаёт обычное соединение с ozon.ru и посылает обратно ответ VPN клиенту от ozon.ru попутно подтягивая, допустим не менее 16кб данных (зная однако по session_id, что это свой VPN клиент сделал запрос).
3. Далее зная, что запрос пришёл от VPN клиента VPN сервер закрывает соединение с ozon.ru но оставляет открытым TCP между VPN клиентом и VPN сервером и уже далее пытается мимикрировать под передачу TLS данных.
Тут вопрос, насколько реализуема эта мимикрия? Чтобы со стороны уже нельзя было бы заметить, что это уже именно передача TLS данных между VPN клиентом и VPN сервером, при этом обособленная?
Именно так и реализовал не так давно новый режим работы в FPTN “SNI + Reality”,
- Клиент инициализирует TCP подключение с сервером
- Клиент отправляет TLS-хендшейк прикрытия (используя session_id от функции времени) на VPN-сервер
- VPN-Cервер понимает что к нему пришел наш клиент и хочет именно “реалити мод”, VPN-сервер подключается к серверу указанном в SNI и пересылает ему TLS-хендшейк.
- VPN-Cервер получает TLS-хендшейк ответ от реально сервера и пересылает его клиенту.
- Клиент включает “режим обфускации” (мимикрируя под уже установшиеся данные TLS-application_data) и уже по этому соединению устанавливает настоящее соединение.
Единственное не понял назначение 16кб данных в вашем предложении.
Ну и сейчас в клиенте три метода обхода сделано:
- Подделка SNI.
- Обфускация (когда трафик выглядит как УЖЕ УСТАНОВИВШЕСЯ TLS соединение).
- И вот третий вариант расписанный выше, как комбинация обоих.
Сейчас работаю над изменением модели поведения соединений. Планирую отказаться от «постоянного» подключения и перейти к пулу “короткоживущих” соединений, которые будут открываться и закрываться по мере необходимости. Они будут работать “похоже” на юзерские запросы: сначала однонаправленная передача данных от клиента к серверу (как будто делается запрос), затем однонаправленная передача от сервера к клиенту. При этом таких соединений будет несколько, работающих параллельно в разных состояниях передачи данных и срок их жизни будет невелик. Тут можно будет играть размером буфера и временем жизни.
Здравствуйте, всё исключительно ситуативно, наверняка же не известно, с какой именно целью РКН 16кб в обратную сторону пропускает, может они что-то определённое в ServerHello высматривают, может mTLS?!
У себя заметил, что если подделать SNI на разрешённый (типа stackoverflow.com), а сервер не поддерживает обмен ключами mlkem, то на FireFox блокировка, а Chrome прекрасно пропускается ТСПУ, а если сервер поддерживает mlkem, то FireFox тоже оживает.
То есть можно было бы условно принять за аксиому, что клиент должен обратно ожидать некоторое количество ответов от того же реального ozon.ru словно клиент некий браузер, словно произошёл http request и response, и уже после этого ответа по установленному TCP соединению гнать трафик. Вряд ли ТСПУ пойдёт на второй раунд проверки TCP соединения.
Можно даже обусловиться на реальную расшифровку данных пришедших с ozon.ru, допустим ожидать index.html страницу, и как только это произошло уже следующие запросы по этому же TCP соединению должны быть “фейковыми”.
Ещё как идея, можно реализовать прогон трафика под видом RDP соединения на NLA (под капотом TLS). Там сравнительно просто.
- сначала идёт RDP запрос без особых сложностей, можно просимулировать разный логин hash, он и так урезается, поэтому хотя бы должен быть вариабельным.
- потом дождаться ответа либо от реального RDP сервера, либо самому сформировать этот ответ, он довольно простой и послать клиенту.
- а далее идёт самое обычное TLS соединение (как у любого браузера), только надо ALPN не добавлять, но обязательно вставлять какой-нибудь фейковый SNI.
- а уже через это TLS соединение можно свои данные посылать (обычно в RDP отсюда начинается NLA аутентификация по NTLM либо Kerberos, можно в принципе дополнительно на NTLM сделать аутентификацию для правдоподобности)
Замечено, когда браузер не открывает страницы, то RDP прекрасно пропускается, возможно это вопрос времени, когда RDP трафик тоже начнут блокировать.
Думаю, есть в этом смысл, если долго трафик не гоняется, обычно браузер тоже может прикрыть такое соединение, а то когда соединение вдруг оживает после некоторого отсутствия трафика, выглядит небраузероподобно.
Будет ли реализовано на клиенте под андроид разделение по программам? Например что бы хром шёл в FPTN, а остальное прямо.
А как расшифровка акронима FPTN?
Будет ли реализовано на клиенте под андроид разделение по программам? Например что бы хром шёл в FPTN, а остальное прямо.
Да, будет - прямо сейчас допиливаем
А как расшифровка акронима FPTN?
FPTN == Fuck PuTiN.