Используете ли вы DPI для фильтрации трафика в своей локальной сети?

Нахуя?

Я вот недавно написал свой DPI на C для фильтрации HTTPS-трафика, который закрывает соединение, если в SNI в Client Hello вместо домена IP,

И как это должно помочь? Домен в SNI нужен для облаков чтоб на них роутить запрос к конкретному сервису (тогда можно хостить кучу сервисов на одном IP/инстансе). Т.е. это имя используется внутри хоста, когда пакет уже доставлен по IP протоколу.

Инструменты скрытия трафика как раз и ставят в SNI какой-то известный и легальный домен, специально для DPI, чтоб он вынул имя из ClientHello, увидел что это какой-нибудь cloudflare.com (так в SNI будет написано) и пустил трафик, а трафик на самом деле инкапсулирует OpenVPN канал и никакого cloudflare.com на том конце нет, а есть VPN за SSL.

Всякие OpenConnect и VLESS своим шифрованием сеть адски грузят.

И как это должно помочь?

Владельцы «бесплатных VPN» на домен обычно не заморачиваются.

По крайней мере, все известные мне рабочие «VPN» отвалились.

Теперь я проверяю, есть ли адрес, полученный getsockopt’ом с SO_ORIGINAL_DST в списке адресов, зарезолвенных по SNI. Нет — какой-то обход 100%, соединение в бан летит. Вообще, сейчас такая схема из 3 уровней защиты:

1. IP-адрес вместо домена в SNI — разрыв соединения.
2. Проверка, есть ли IP-адрес из SO_ORIGINAL_DST в списке IP-адресов, зарезолвенных по SNI. Нет — разрыв соединения.
3. Проверка кода ответа HTTP от главной страницы сайта по домену из SNI. Выдает 4xx или 5xx — разрыв соединения. Этот этап несколько замедляет время загрузки сайтов, может какие-то API поломать, но он окончательно добьет всё.

Если все уровни защиты успешно пройдены, я начинаю проксирование соединения клиента с сервером.

Этот шиз строит систему фильтрации для своего кокорда. Сформулировать нахера она ему нужна он до сих пор не может. Пацан игрушку себе нашел, пусть играет.

Всякие OpenConnect и VLESS своим шифрованием сеть адски грузят.

А зачем блокировать, организуй канал через который желающие могут слать vpn без особых шифрований и маскировок, тогда и у них vpn будет, и у тебя нагрузка на сеть уменьшится.

Этот шиз строит систему фильтрации для своего кокорда.

Понятно, чукча не читатель, чукча только писатель.

А зачем блокировать, организуй канал через который желающие могут слать vpn без особых шифрований и маскировок

YouTube в моей локалке работает, а VPN’ы только для него и нужны.

Ты о твиттере забыл, да и будет ли без vpn работать Discord?

2. Проверка, есть ли IP-адрес из SO_ORIGINAL_DST в списке IP-адресов, зарезолвенных по SNI. Нет — разрыв соединения.

Так этот список нужно постоянно актуализировать, там будет работы непочатый край, все время будут обнаруживаться не работующие службы, сайты и т.д. Вообще это уже фактически белые списки, т.е. разрешенные ip, разрешенные ip для sni (в sni разрешенные хосты).
Кто это будет актуализировать непонятно.

3. Проверка кода ответа HTTP от главной страницы сайта по домену из SNI.

Против самостоятельно поднятых VPN не поможет, можно поднять сайт, купить домен и прятаться за https. Открыв через браузер увидишь форму авторизации на вход в gitea, cgit, ownCloud, или сайт с котиками.

Ты о твиттере забыл

Не нужно.

Discord

Не нужно.

Так этот список нужно постоянно актуализировать

Что актуализировать? Я беру IP, на который идет клиент, резолвлю список IP-адресов по SNI, смотрю, есть ли IP, на который обратился клиент, в этом списке: нет — разрыв соединения.

Против самостоятельно поднятых VPN не поможет

Чаще всего просто делают авторизацию на сайте, а тогда я получу 401, что и заблокирует всё.

резолвлю список IP-адресов по SNI

А, ну тогда это мусор… у тебя все облака поломаются :)

dig @8.8.8.8 google.com

google.com.             244     IN      A       173.194.222.113                                                    
google.com.             244     IN      A       173.194.222.100                                                    
google.com.             244     IN      A       173.194.222.102                                                    
google.com.             244     IN      A       173.194.222.138                                                    
google.com.             244     IN      A       173.194.222.101                                                    
google.com.             244     IN      A       173.194.222.139 

dig @8.8.8.8 google.com

google.com.             10      IN      A       108.177.14.138
google.com.             10      IN      A       108.177.14.101
google.com.             10      IN      A       108.177.14.139
google.com.             10      IN      A       108.177.14.113
google.com.             10      IN      A       108.177.14.102
google.com.             10      IN      A       108.177.14.100

dig @77.88.8.8 google.com

google.com.             232     IN      A       64.233.163.139
google.com.             232     IN      A       64.233.163.100
google.com.             232     IN      A       64.233.163.102
google.com.             232     IN      A       64.233.163.113
google.com.             232     IN      A       64.233.163.138
google.com.             232     IN      A       64.233.163.1

dig @1.1.1.1 google.com

142.250.74.46

Ты даже популярные фразы невпопад используешь.

Не нужно.

Видимо те кто тянут vpn другого мнения, ну это твой выбор соревноваться с ними создавая ситуацию когда сеть забита трафиком для противодействия твоей DPI, или же попробовать договорится с ними на приемлемых условиях.

Ничего не поломается, DNS у всех в моей локалке один.

Можно было бы снифить запросы к DNS (на 53 порт) которые проходят через твой шлюз, там ничего не шифрованно.
Ответы от DNS серверов можно кешировать, в том числе вносить IP в разрешенные. Для каждого пользователя такие списки лучше делать раздельными.

Пострадают только параноики которые форсировали DNS over TLS без fallback на обычный протокол. Может ошибаюсь.