Comments 39
если UDP сессия не началась с Handshake Initiate - Handshake Response, то претензий к данной сессии у DPI не будет
А зачем тогда хитрые телодвижения с соксом ? (я при беглом прочтении так и не понял, как именно вы его используете).
Шлите первым пакетом со стороны клиента какой-нибудь мусор, сервер этот пакет проигнорирует, но на брандмауэре сессия создастся и она будет начинаться с этого мусора, а не с wireguard handshake
Если послать мусорный пакет, то сервер ничего не ответит, а DPI похоже ждет первую подходящую пару в обоих направлениях. Впрочем, наверняка сложно сказать, это только мои предположения.
Через SOCKS пробрасывается Handshake Initiate и приходит ответный Hadnshake Response, остальные пакеты ходят напрямую между клиентом и сервером WireGuard. Другими словами SOCKS используется для маскировки handshake.
я что-то немного упустил.. почему хэндшейк не шифруется так же как остальные пакеты? вроде же это собирались добавить в мейнстримный wg??
Вопрос скорее к Джейсону, но вообще все кроме первого байта для DPI выглядит как произвольные бинарные данные. Основная проблема в фиксированном размере пакетов handshake и первом байте указывающем тип пакета, который 1 для initiate, 2 для response и 4 для пакетов с данными.
Мда, ну тут я тоже не вижу проблемы подмешивать в пакет рандома для изменения веса..
Согласен, можно было бы сделать Wireguard более стойким к детектированию. Но по всей видимости это вряд ли уже произойдёт. Никто не захочет ломать совместимость. А ее к слову ломает даже использование зарезервированных байтов.
Насколько я знаю UDP, там всё равно вычитывается вся датаграмма, которая влезет в буфер. Неужели сервер создаёт буфер для чтения всего в 148 байт?
wireguard-go код проверяет размер полученного пакета и отбрасывает его если он не совпадает с ожидаемым. Другие реализации не проверял, но думаю там все аналогично. Поэтому дописывать в Handshake Initiate рандомный мусор в конец пакета не получится.
case MessageInitiationType:
okay = len(packet) == MessageInitiationSize
case MessageResponseType:
okay = len(packet) == MessageResponseSize
case MessageCookieReplyType:
okay = len(packet) == MessageCookieReplySize
default:
device.log.Verbosef("Received message with unknown type")
}
if okay {
select {
case device.queue.handshake.c <- QueueHandshakeElement{
msgType: msgType,
buffer: buffer,
packet: packet,
endpoint: endpoint,
}:
buffer = device.GetMessageBuffer()
default:
}
}Тогда придётся форкать. Проблема только в том, что теперь он аж в ядре линуха :(
Можно использовать альтернативный BoringTun от Cloudflare. Не kernel mode, но производительность неплохая, существенно лучше чем wireguard-go.
Так же похоже, что верно и обратное, если UDP сессия не началась с Handshake Initiate — Handshake Response, то претензий к данной сессии у DPI не будет, даже если эти пакеты покажутся там в дальнейшем.
Может тогда будет достаточнл отправлять перед началом сессии WG произвольные UDP пакеты со случайными данными?
Возможно, здесь мы вступаем области предположений. Меня главным образом смущает, что у пользователя туннель не падал через две минуты. Так же вполне вероятно, что нужен еще и произвольный пакет в обратном направлении. А для этого придется еще и сервер модифицировать.
Возможно SOCKS - это действительно overkill и может отработать и более простой вариант. Но главное, что работает.
Что-то похожее было в KZ в начале января, в самом начале блокировок интернета -
у меня перестали подключаться клиенты к Wireguard VPN серверу в облаке Oracle, хотя доступ по SSH к нему оставался. Успел выяснить, что как раз Handshake Initiate до сервера доходил, и Handshake Response отправлялся, но до клиента не добирался - терялся на территории KZ провайдеров.
Решил проблему, подняв на том же сервере рядом с Wireguard сервис Outline, который как раз прячется в shadowsocks. Но на заметку вашу статью возьму, спасибо.
Сейчас в Узбекистане очень плохо работает Warp VPN, может они тоже используют похожую ДПИ системы как КЗ.
Нужно смотреть внимательнее, никогда нельзя исключать ошибки конфигурации или проблемы маршрутизации у провайдеров услуг или интернета.
Судя по https://www.ntkernel.com/forums/topic/cant-start-instalation-wiresock-on-windows7-x64/ в Узбекистане и SOCKS5 блокируют. Я пока на 100% не уверен, но очень на это похоже: SOCKS4 работает, а SOCKS5 рубят по первому пакету.
Если есть желание, то можем повозиться, ничего не мешает добавить еще один метод обфускации в клиента.
Вадим, вроде нет, скорее всего некоторые настройки железа приобретенного из поднебесной оставили по умолчанию заблокированным, не вникаясь что этим могут иногда пользоваться энтузиасты.
Настроив WG сервер и убедившись что хендшейки обратно до клиента не долитают я наткнулся на эту статью и соответственно на Ваш сайт с решением WireSock. Что и стало причиной создания темы по вышеуказаннгой вами ссылке, тк еще очень было интересно узнать/убедиться что это глобальная блокировка или мои кривые руки в настройке сервера WG. Правда, перемудрив с настройками уже Данте также начал подумывать о заблокированном еще и SOCKS5 что в итоге после удачного подключения не оказалось правдой.
В решении с WireSock меня смущает только тот факт, что порты Данте сервера с 40000 по 45000 перманентно остаются открытыми для входа, не повлияет ли это на безопасность сервера?
Также, хотел узнать, нет ли таких же решений как Ваш WireSock для андроид и линукс? Ну чтобы не гонять весь трафик по соксам а только заголовки хендшейков.
Да, согласен, ошибочка вышла, но по итогу разобрались. Похоже на то, что режут wireguard по хендшейкам, это объясняет почему "очень плохо работает Warp VPN". Для WARP могу посоветовать следующее:
Создать файл конфигурации, например с использованием https://github.com/ViRb3/wgcf
Настроить Dante сервер, аналогично описанному https://www.ntkernel.com/dante-in-oracle-cloud/
Добавить в конфиг WARP адрес/логин/пароль от Dante и скормить результат моему WireGuard клиенту https://www.wiresock.net
В решении с WireSock меня смущает только тот факт, что порты Данте сервера с 40000 по 45000 перманентно остаются открытыми для входа, не повлияет ли это на безопасность сервера?
Открытый диапазон UDP портов нам вряд ли чем-то угрожает, я не смотрел код, но предполагаю, что Dante начинает слушать порт из этого диапазона только после команды UDP ASSOCIATE. При этом конкретный порт для каждой сессии выбирается из этого диапазона с некой долей "случайности". Остальной трафик направленный на эти порты благополучно отбрасывается стеком.
Также, хотел узнать, нет ли таких же решений как Ваш WireSock для андроид и линукс? Ну чтобы не гонять весь трафик по соксам а только заголовки хендшейков.
Насколько я знаю, нет. Сделать, впрочем, не слишком сложно, можно добавить соответствующий код в тот же boringtun. Было бы время... Если надо подключить к wireguard серверу не Windows систему (например Smart TV или колонку), то можно расшарить подключение с Windows, используя например Internet Connection Sharing или Mobile Hotspot. В отличие от стокового клиента, мой так умеет работать. Как-то использовали одну из ранних версий, чтобы активировать "серый" Smart TV от Samsung через европейский сервер после массовых блокировок в 2020 году.
WireGuard vpn (свой сервер, клиент iOS / Mac) отлично работал в начале года в Египте, в отличие от многих других сервисов. Может они ещё и адрес смотрят?
Возможно, у пользователя был конфиг от Warp+. С другой стороны здесь вообще корпоративный VPN заблокировали, в отличие от того же Warp вряд ли адреса были засвечены. Может быть еще не у всех провайдеров блокировка налажена, насколько я понимаю история довольно свежая.
государство, которое таким оригинальным способом "подталкивает" население к более глубокому изучению сетевых технологий
Тем временем, граждане Египта более глубоко изучают сетевые технологии:
А OpenVPN там так же блокируют?
У меня не было возможности проверить, но судя по тому, что пишут, OpenVPN работает только в паре с shadowsocks.
Даже через TCP с TLS crypt и на 443 порту? Не знал, что DPI умеет распознавать такое...
Да, сейчас нахожусь в египте. Работает только через obfsproxy, ssh tunnel. Shadowsock еще не пробовал. 443 tls ломается на фазе автоиизации
Еще в прошлом году у меня получалось подключаться, видимо что-то изменили совсем недавно.
Неделю назад у нашего сотрудника тоже получалось подключиться просто по 443 TLS, но видимо когда я приехал что-то случилось. Очень похоже что ломается пакет ответа от VPN на стадии авторизации.
Я пробовал как отельный wifi (Link Egypt), так и vodafone 4G.
К сожалению сейчас нет времени особо пробовать другие методы обфусцирования траффика, так что не получится сделать нормальное исследование.
А откуда вообще проблема, был осенью там и не испытал никаких проблем с доступом ко всему включая домашний сервер.
Ссылки на пруфы разбросаны по статье. То с чего я начал этим заниматься: https://www.ntkernel.com/forums/topic/can-i-select-the-default-interface-when-using-wiresock-vpn-client-on-win10/
Еще пара ссылок, которые я нашел пока, разбирался:
https://www.reddit.com/r/Egypt/comments/lsnyk7/is_wireguard_blocked/
https://twitter.com/6h4n3m/status/1459462360003919875
Не исключено, что наличие блокировок зависит от конкретных провайдеров.
При этом маскировка под TLS возможно не лучший выбор. Как вариант можно было бы маскироваться под трафик популярных онлайн игр, в особенности построенных на основе UDP.
А есть документация по таковым протоколам? А также статистика по трафику, и т.д.
Например, протокол Minecraft Bedrock Protocol имеет подробную документацию. Однако, если заморочиться, можно попытаться использовать недокументированный протокол, например, Fortnite активно использует UDP.
У VPN все же немного иное предназначение - создание виртуальной сети поверх другой сети (даже шифрование не является обязательным), а использование VPN для обхода блокировок и сокрытия реального местоположения пользователя - это лишь частный случай. Поэтому подавляющее большинство реализаций VPN задачу сокрытия факта использования даже не пытается решать.
Интересно, решат ли у нас тоже блочить Wireguard. Только что настроил.
Что-то похожее наблюдаю в настоящее время на cloudflare warp в России на провайдере Ростелеком (PPPoE) инет1 май 2022, т.е. от клиента на сервер "Endpoint = engage.cloudflareclient.com:2408" уход пакет c первыми байтами 01 00 00 00 84 9B .....
Ipv4: Src = 1хх.1хх.1хх.1хх, Dest = 162.159.192.1, Next Protocol = UDP, Packet ID = 17885, Total IP Length = 176Udp: SrcPort = 65100, DstPort = 2408, Length = 156 SrcPort: 65100 DstPort: 2408 TotalLength: 156 (0x9C) Checksum: 26068 (0x65D4)UDPPayload: SourcePort = 65100, DestinationPort = 2408 UDPPayloadData: Binary Large Object (148 Bytes)
А в ответ тишина.
Если взять другого провайдера просто на проводе инет2 то проблем с установкой соединения нет на том же самом конфиге имеем с "Endpoint = engage.cloudflareclient.com:2408"
От клиента 01 00 00 00 72 С4 6B 80 F1...
Ipv4: Src = 10.10.ххх.ххх, Dest = 162.159.192.1, Next Protocol = UDP, Packet ID = 52908, Total IP Length = 176
Udp: SrcPort = 65100, DstPort = 2408, Length = 156 SrcPort: 65100 DstPort: 2408 TotalLength: 156 (0x9C) Checksum: 53093 (0xCF65)UDPPayload: SourcePort = 65100, DestinationPort = 2408 UDPPayloadData: Binary Large Object (148 Bytes)
От сервера 03 00 00 00 72 С4 6B 80 99 ...
Ipv4: Src = 162.159.192.1, Dest = 10.10.ххх.ххх, Next Protocol = UDP, Packet ID = 38633, Total IP Length = 92
Udp: SrcPort = 2408, DstPort = 65100, Length = 72 SrcPort: 2408 DstPort: 65100 TotalLength: 72 (0x48) Checksum: 44684 (0xAE8C)UDPPayload: SourcePort = 2408, DestinationPort = 65100 UDPPayloadData: Binary Large Object (64 Bytes)
От клиента 01 00 00 00 3А 12 38 68 48 E4 ...
UDPPayload: SourcePort = 65100, DestinationPort = 2408 UDPPayloadData: Binary Large Object (148 Bytes)
От сервера 02 00 00 00 0E 11 00 3F 12 38 ...
UDPPayload: SourcePort = 2408, DestinationPort = 65100 UDPPayloadData: Binary Large Object (92 Bytes)
От клиента 04 00 00 00 00 0E 11 00 00 00 00 00 00 00 00 00 C1 ...
UDPPayload: SourcePort = 65100, DestinationPort = 2408 UDPPayloadData: Binary Large Object (32 Bytes)
От клиента 04 00 00 00 00 0E 11 00 01 00 00 00 00 00 00 00 B8 ...
UDPPayload: SourcePort = 65100, DestinationPort = 2408 UDPPayloadData: Binary Large Object (128 Bytes)
Далее от сервера и клиента шли пакеты 04 00 00 00 c length 124 от сервера и 136 от клиента. Туннель поднялся на провайдере инет2. Далее самое интересное, делаем смену default на инет1 (практичестки моментально) туннель остаеться рабочим и ни каких проблем на нем нет, может работать несколько дней.
На megаfоn, yoта блokиpyют . установил на телефоне сегодня, не работает guard, на проводном провайдере работает . Есть какие то новые решения для ухода от блока?
Обход блокировок WireGuard в Египте