blockcheck не рассчитан на ipsec.
Руками проверять. Да там и варианов нет, кроме fake или ipfrag2
Смотрю это…
Хотя, имеет ли смысл обфусцировать UDP, если инкапсулированный 50 тоже не пропускает?
Имеет. udp 500 все равно есть. Можно и udp проксорить номер протокола. Правда, при этом потом придется ловить пакеты через u32 filter или payload expression на другом конце. Или над пейлоадом поиздеваться
Все-таки попрошу помощи. Штука сложная, а времени совсем нет.
Это по ipsec. Пока пытаюсь zapret-ом, без обфускации.
Вот лог.
packet: id=1 len=260 mark=20000000
IP4: 111.111.111.111 => 222.222.222.222 proto=udp ttl=64 sport=4500 dport=4500
UDP: len=232 : 00 00 00 00 15 05 77 1С A4 23 BЕ EЕ 00 00 00 00 00 00 00 00 23 24 25 08 00 00 00 00 00 00 00 E4 ... : ......r.."..........! "......... ...
desync profile search for udp target=222.222.222.222:4500 l7proto=unknown hostname=''
desync profile 0 matches
not applying tampering to unknown protocol
packet: id=1 pass unmodified
Ну и так дальше еще 5 пакетов…
Вот профиль. Начальный, для проб. И тупой как 2 копейки:
--filter-udp=4500
--hostlist=/opt/zapret/ipset/zapret-hosts-user.txt (Тут хост удаленный прописан)
--dpi-desync=fake
--dpi-desync-any-protocol=1
--dpi-desync-cutoff=n5
Что-то можно с этим сделать? Хоть начальные рекомендации.
Всего лишь надо подумать откуда берется hostname и какую роль он играет в механике подключения через ipsec.
DNS - это протокол необязательный для инета. Его цель - заресолвить имя в IP адрес. Это производится отдельным протоколом, который zapret не перехватывает , не анализирует, не запоминает имена и результат их ресолва, не соотносит с дальнейшей механикой подключения по каким-либо другим протоколам. DNS сразу отпадает.
Как может еще zapret получить hostname ? Некоторые протоколы его передают как часть себя. Для http это хедер Host: , для TLS - SNI.
А что у нас для IKE ? НИЧЕГО.
Соответственно хоста у нас нет.
Тогда как будет работать хостлист ?
Никак он не будет работать
tpws может брать hostname из запроса socks с удаленным ресолвом хостов. Но tpws работает только с tcp, здесь он неприменим. socks без удаленного ресолва хостов или прозрачный режим, и tpws тоже ничего не знает о hostname иначе, чем анализируя основной известный ему протокол.
Вывод : отказаться от фильтра по хосту , при необходимости использовать ipset-ы, а если IP мало - использовать дополнительные правила в ip/nf tables. Для linux писать custom script, тк параметры --ipset запрещены в скриптах запуска, а дополнительные параметры иначе не пронести. Хотя --ipset сработает при ручном запуске, это будет плохим решением
IPsec + IKEv2 заработало на тех же условиях. Более двух недель было поломано.
Не всем так везет (
bolvan
Понятно. И про хост и про написание скриптов. Для меня займет уйму времени изучение, тестирование… Материал глубокий. А ведь надо работу работать…
Пока решил препарировать ipobfs (kmod). Собрал сразу, но для старых архитектур пришлось повозиться с SDK.
В общем, установил на два конца для тестирования. Принцип понятен. Реализация тоже более менее. Но костыли, как всегда, есть.
Во-первых - u32 под оперврт есть (кмод-ipt-u32). Но с 23.05 iptables правила u32 все равно не заводятся.
C netfilter реально запустить? (АПДЕЙТ. Вроде сработал u32. Но все равно хотелось бы знать - по логике, если заставить netfilter маркировать пакеты, какая разница для ипобфс?..)
А во-вторых, использую xfrm интерфейс, который уже маркирует пакеты… Вот интересно, можно этот марк использовать, или на выходе из eth0 отдельно маркировать обязательно?
Не печальтесь, я тоже рано радовался. После вчерашних сбоев и донастроек ТСПУ вновь “забугор” отвалились соединения по протоколам выше.
Есть апдейт. Интересный. (на мой взгляд ))
-
есть тестовый туннель. Все ходит.
-
правила iptables поставились, пакеты хукаются, счетчики iptables крутятся. На обоих концах.
-
инсмод тоже с параметрами запустился, и главное, туннель не умер.
-
НО пинги больше не ходят… ПРИ ЭТОМ при пинге счетчики пакетов на туннеле увеличиваются.
-
tcpdump после установки insmod с параметрами затыкается и больше не ловит пакеты по указанным портам (что полагаю, хорошо). После рммод тцпдамп оживает на лету.
…но вот пинги при включенном инсмоде… При том что туннель жив. Ощущение, что ломаются маршруты…
…упс
… не то
ipsec0 от xfrm или vti ?
Единственный критерий, по которому модуль ipobfs что-то делает с трафиком, это наличие определенных битов в mark по указанной маске.
Их нужно выставлять в iptables/nftables.
Если у вас сделано выставление с учетом входящего интерфейса eth0, это значит, что mark пакета сохранился на его пути в ipsec0. Я не проверял этот случай. Если же фильтра по eth0 нет в правилах, его надо сделать
смотрю код. там сделан сброс битов mark после процессинга
|// clear mask bits to avoid processing in post hook|
skb->mark &= ~markmask;
напишите ваши правила установки марка и параметры запуска модуля ipobfs
нельзя применять нулевой марк
примерно так это работает
markmask=0x70000
mark=0x10000,0x20000,0x30000,0x40000,0x50000,0x70000 \
Извиняюсь за двойной пост…
в данном случае xfrm.
… опять
markmask сделайте равным mark
Оно. )))))))))
ЗЫ Немного смысл markmask=0x100 не понятен…
Исследовал блокировку VPN. Было интересно, как ТСПУ определяет протокол openvpn (UDP), в котором нет регулярных последовательностей.
Для исследования отправлял пакеты с помощью socat. Провайдер мобильный мегафон.
Вот что выяснил:
- Первые 5 пакетов проходят без блокировки. После этого соединение анализируется. Для теста отправлял случайные данные из /dev/random. Отслеживание подключения производится по группе {SRC IP, DST IP, SRC PORT, DST PORT}. Удаление из таблицы отслеживания подключений производится по таймауту. Направление первого пакета не влияет на блокировку.
- Производится статистический анализ 0\1 в первом пакете. Даже незначительное преобладание 0 или 1 приводит к разрешению подключения, достаточно добавить 2-4 нулевых байта в первый пакет.
Если заменять часть данных символом ‘f’, у которого количество 0 и 1 одинаковое, то для прохождения фильтра нужно заполнить им примерно половину пакета. Скорее всего есть отдельная проверка на одинаковость байт. Содержимое всех пакетов кроме первого в анализе не используется. Предположу, что они используются для поиска сигнатур известных протоколов. - Если первый пакет короче 83 байт (данные), то он не подвергается статистическому анализу и подключение не блокируется.
2 Likes