Блокировка Wireguard на vdsina и блокировка ренджа UDP портов

,

Примерно 16 числа на хостинг vdsina раскатали блокировку Wireguard по inital хендшейк. Скорее всего, используется старый принцип с детектом UDP хедера.

Сервер находится в Нидерландах. Провайдер Дом.ру, Сибирь

Если раньше при детекте WG блокировался UDP порт, куда прилетел хендшейк от WG, то сейчас блокируются все UDP порты, но ниже 1000 остаются рабочими.

Предварительно отправил UDP пакет таким образом и он дошел

echo test | socat - UDP:ip:40000

Вывод socat

socat[26568] E read(5, 0x77e93000, 8192): Connection refused

Пойманный пакет на вдс

.203694 IP (tos 0x20, ttl 58, id 63639, offset 0, flags [DF], proto UDP (17), length 33)
    src.36294 > dst.40000: [udp sum ok] UDP, length 5
        0x0000:  4520 0021 f897 4000 3a11 40ec 1f84 e79e  E..!..@.:.@.....
        0x0010:  d476 2b8f 8dc6 9c40 000d dcca 7465 7374  .v+....@....test
        0x0020:  0a00 0000 0000 0000 0000 0000 0000       ..............

Далее хендшейк от WG отправлял таким образом

socat - UDP:ip:40000 < /opt/zapret/files/fake/wireguard_initiation.bin

Вывод socat

socat[26653] E read(5, 0x77e42000, 8192): Connection refused

Пойманный пакет на вдс

.367181 IP (tos 0x20, ttl 58, id 35839, offset 0, flags [DF], proto UDP (17), length 176)
    src.40912 > dst.40000: [udp sum ok] UDP, length 148
        0x0000:  4520 00b0 8bff 4000 3a11 acf5 1f84 e79e  E.....@.:.......
        0x0010:  d476 2b8f 9fd0 9c40 009c a9d6 0100 0000  .v+....@........
        0x0020:  053f a03f 7932 19e2 b0c1 9463 809a 368e  .?.?y2.....c..6.
        0x0030:  ca4b 075d 6b60 adaf e610 b880 689c 1309  .K.]k`......h...
        0x0040:  c85b 5112 3c40 215f 01f7 8c7e 6aaf 7686  .[Q.<@!_...~j.v.
        0x0050:  d046 f6a4 6702 d231 751b 3707 0603 24bc  .F..g..1u.7...$.
        0x0060:  9e0f 84e7 b638 3807 cecb f238 dde9 df4d  .....88....8...M
        0x0070:  c2e9 225c 5901 47ce 6e40 62eb 4379 fc1f  .."\Y.G.n@b.Cy..
        0x0080:  a1f4 04a2 62f3 d2ae c515 6fef 4422 abd6  ....b.....o.D"..
        0x0090:  f4ae 428e e9f9 0d81 25f0 0769 d504 c07e  ..B.....%..i...~
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................

После отправки этого хенджейка ни один UDP пакет не дойдет до сервера ни по одному порту, если они находятся выше 1000, но TCP будет доступным по всем портам.

echo test | socat - TCP:ip:40000

Вывод socat

socat[26773] W connect(5, AF=2 ip:40000, 16): Connection refused
socat[26773] E TCP:ip:40000: Connection refused

Пойманный пакет на вдс

406877 ens3  In  IP (tos 0x20, ttl 58, id 15255, offset 0, flags [DF], proto TCP (6), length 60)
    src.32852 > dst.40000: Flags [S], cksum 0x6ebf (correct), seq 4079626019, win 64240, options [mss 1436,sackOK,TS val 1994729849 ecr 0,nop,wscale 5], length 0
        0x0000:  4520 003c 3b97 4000 3a06 fddc 1f84 e79e  E..<;.@.:.......
        0x0010:  d476 2b8f 8054 9c40 f32a 2723 0000 0000  .v+..T.@.*'#....
        0x0020:  a002 faf0 6ebf 0000 0204 059c 0402 080a  ....n...........
        0x0030:  76e5 2979 0000 0000 0103 0305            v.)y........
406981 ens3  Out IP (tos 0x20, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    dst.40000 > src.32852: Flags [R.], cksum 0x71c4 (correct), seq 0, ack 4079626020, win 0, length 0
        0x0000:  4520 0028 0000 4000 4006 3388 d476 2b8f  E..(..@.@.3..v+.
        0x0010:  1f84 e79e 9c40 8054 0000 0000 f32a 2724  .....@.T.....*'$
        0x0020:  5014 0000 71c4 0000                      P...q...

Блокировка ренджа UDP портов какая-то рандомная по времени, я так не смог её замерить. Когда-то это 5 минут, сейчас уже она длится уже 30 минут.

С сервера на хостинге в Москве UDP летает без проблем, триггера на WG хендшейк нет

у тебя какой-то триггер включает блокировку, она длится 10 минут. вг хендшейк щас проверю

UPD: не могу воспроизвести, скинь вг конф в лс

Триггер именно хендшейк от WG, по крайней мере только у меня. Отправки любых других пакетов с размером от 1 до 400 байт по всем UDP портам ничего не триггерят.

Про 10 минут это я знаю, но на данный момент уже 35 минут. Возможно, отправка любого UDP на порт выше 1000 обновляет таймер и эти 10 минут возвращаются вновь

Дело даже не в вг конф, я тестирую на втором сервере, где из сервисов только SSH

ну я тоже протестил на ip без wg, блока не поймал. дай свой ip или подсеть хотя бы

Блок моментально после socat - UDP:ip:any_port>1000 < /opt/zapret/files/fake/wireguard_initiation.bin

На другом сервере как раз развернут WG, при попытке подключения в клиенте получено 0 байт.

image

Подсеть одного из серверов 212.118.43.0.

Если я ловлю блокировку, то я больше не могу отправить UDP ни на один адрес в сети вдсины, но на сервер от вдсины в Москве могу без проблем и в любом количестве, как и хендшейки от wg

root@OpenWrt:~# socat - UDP:ip:40000 < /opt/zapret/files/fake/wireguard_initiation.bin
socat[26994] E read(5, 0x77e3c000, 8192): Connection refused
root@OpenWrt:~# socat - UDP:ip:40000 < /opt/zapret/files/fake/wireguard_initiation.bin
socat[26995] E read(5, 0x77e65000, 8192): Connection refused
root@OpenWrt:~# socat - UDP:ip:40000 < /opt/zapret/files/fake/wireguard_initiation.bin
socat[26996] E read(5, 0x77e38000, 8192): Connection refused
root@OpenWrt:~#

Скорее всего, эту фигню накатили чисто на область, округ или провайдера. Дом.ру, Сибирь

на рт сз не получается у меня

у тебя вг работал до любых серверов? у меня уже с 23г чтоли он в блоке

Ну вот до 16 числа WG работал только до вдсины в Нидерландах, более европейские хостинги как раз года с 23 отвалились, а постоянно слать мусор перед шейком было лениво. Раньше как раз при handshake initiation UDP блокировка была конкретно на том порту, который получил этот шейк, сейчас у меня при шейке до вдсины бан udp на всех портах выше 1000.

WG кстати перенес на порт ниже 600, проблем снова нет, но на всякий случай шлю 20 байт мусора перед подключением

Если хочется побаловаться, то можно взять AmneziaWG (лучше последнюю, в сорцах из гитхаба) - это WG+обфускация разного рода, причём, обратно-совместимая (т.е. AWG-клиент, при соответствующих настройках, сохранил возможность подключаться к обычному WG-серверу).
Или openvpnxor в режиме udp (+могу кинуть свой вариант патчей, которые делают его похожим на AWG по степени обфускации).
Только это всё мало помогает :frowning: В моём случае любой “непонятный” UDP трафик (а после хорошего обфускатора он именно так и выглядит: рандомные пакеты рандомных байт рандомного размера) просто начинает дропаться после N-ного пакета. И так как логика такого бана довольно проста, думаю, её скоро “раскатают” максимально широко.

Я пробовал амнезию wg, но я видимо пытался во время блока udp портов, так что блок не дал awg заработать. В шарке выглядело это вот так

То есть тоже блок на этапе инициализации, как и при обычном WG, и постоянные попытки отправить initiation handshake. У меня есть идеи, что такой блок может триггерить, но мне нужно это пару дней на более подробное изучение, чтобы не хламить тему догадками

А с местного провайдера до хостинга в Москве? А то может просто раскочегарить на московском сервере nginx со stream и на зарубежный WG ходить через Москву?

С местного и отправлял до Москвы шейки от wg в этом сообщении внизу Блокировка Wireguard на vdsina и блокировка ренджа UDP портов - #6 by Vobla

После отправки 0 блокировок и нет проблем.

То есть:

  1. Отправка по udp initiation шейка с местного провайдера на сервер вдсины на Нидерландах = бан всего udp выше 1000 порта
  2. Отправка по udp initiation шейка с местного провайдера на сервер вдсины в Москве = нет блокировки, как и любого другого udp-like трафика с любым размером пакета, от 1 байт до 400 байт. В том числе и zero_1024.bin, zero_256.bin, etc
  3. Отправка по udp initiation шейка с вдсины из Москвы до вдсины в Нидерландах = 0 проблем, всё доходит, 0 блокировок, как и наоборот.

У меня есть стойкое ощущение, что мой случай связан с темой Блокировка OVH после отправки UDP-пакетов DHT-пирам - Internet censorship all around the world / Russia - NTC, т.к я настроил dnat на тоннель через cgnat провайдера с lan клиента для торрент-клиента, чтобы люди могли подключаться ко мне p2p без использования трекере, чтобы людям было проще качать от меня торренты. Схема примерно такая

Пир → VDS (DNAT торрент порта) → WG → роутер (redirect торрент порта) → LAN клиент → роутер → WG → VDS (masquerade) → Пир

Считаю, что моя тема похожа с вышеупомянутой, потому что мой торрент клиент может триггерить блоки целых подсетей хостеров, просто у меня какая-то новая итерация усложнения жизни людей. Пока считаю, что блок udp портов у меня так и не спал, потому что торрент клиент продолжает общение с нерукопожатными адресами, а мои попытки отправить вг шейк тоже помогали блокировке. Или же они теперь не просто обновляют таймер блокировки, а при каждой отправке добавляют N количество минут к блоку, поэтому я уже 9(?) часов не могу получить udp с местного провайдера на 2 сервера к вдсиные в Нидерландах, но к вдсине в Москве никаких проблем туда и обратно

квик мусор от гугла суньте, с ним норм все при блоке триггерном, через запрет или амнезию, хватает одного

Спойлер

<b 0x494e56495445207369703a626f624062696c6f78692e636f6d205349502f322e300d0a5669613a205349502f322e302f55445020706333332e61746c616e74612e636f6d3b6272616e63683d7a39684734624b3737366173646864730d0a4d61782d466f7277617264733a2037300d0a546f3a20426f62203c7369703a626f624062696c6f78692e636f6d3e0d0a46726f6d3a20416c696365203c7369703a616c6963654061746c616e74612e636f6d3e3b7461673d313932383330313737340d0a43616c6c2d49443a20613834623463373665363637313040706333332e61746c616e74612e636f6d0d0a435365713a2033313431353920494e564954450d0a436f6e746163743a203c7369703a616c69636540706333332e61746c616e74612e636f6d3e0d0a436f6e74656e742d547970653a206170706c69636174696f6e2f7364700d0a436f6e74656e742d4c656e6774683a20300d0a0d0a>

Такая блокировка в ЛНР с августа месяца на мобильном интернете, если раньше трекался handshake request и можно было фейковый пакет амнезии отправить первым - прокатывало, сейчас же смотрится и первый пакет от сервера и весь трафик прибивается минут на 10. Клиент все шлет handshake request, сервер иногда все-же както получает и отправляет handshake response, входящего трафика на клиенте нет.

Обойти можно своим билдом сервера что будет отправлять перед handshake response фейковый пакет или полноценно пробовать все параметры амнезии h1/h2/s1/s2 меняющие форму хенжшейка

Возвращаюсь с новыми наблюдениями.

Я так и не смог дождаться сброса блокировки портов почти за сутки, хотя до этого это было 5-30 минут. Решением оказалось получение нового ip от провайдера рестартом wan на роутере, простые udp пакеты снова начали доходить с меня и до двух серверов у вдсины в Нидерландах.

186742 ens3  In  IP (tos 0x20, ttl 58, id 58577, offset 0, flags [DF], proto UDP (17), length 33)
    src.47164 > dst.40001: [udp sum ok] UDP, length 5
        0x0000:  4520 0021 e4d1 4000 3a11 54b2 1f84 e79e  E..!..@.:.T.....
        0x0010:  d476 2b8f b83c 9c41 000d b253 7465 7374  .v+..<.A...Stest
        0x0020:  0a00 0000 0000 0000 0000 0000 0000       ..............
945981 ens3  In  IP (tos 0x20, ttl 58, id 40781, offset 0, flags [DF], proto UDP (17), length 33)
    src.48833 > dst.40001: [udp sum ok] UDP, length 5
        0x0000:  4520 0021 9f4d 4000 3a11 9a36 1f84 e79e  E..!.M@.:..6....
        0x0010:  d476 2b8f bec1 9c41 000d abce 7465 7374  .v+....A....test
        0x0020:  0a00 0000 0000 0000 0000 0000 0000       ..............
613660 ens3  In  IP (tos 0x20, ttl 58, id 49008, offset 0, flags [DF], proto UDP (17), length 33)
    src.43343 > dst.40001: [udp sum ok] UDP, length 5
        0x0000:  4520 0021 bf70 4000 3a11 7a13 1f84 e79e  E..!.p@.:.z.....
        0x0010:  d476 2b8f a94f 9c41 000d c140 7465 7374  .v+..O.A...@test
        0x0020:  0a00 0000 0000 0000 0000 0000 0000       ..............

Отправка quick от гугл по udp снова вешает блокировку и даже bin не доходит до сервера, дальнейшие udp доходят только для портов <1000

socat - UDP:ip:40001 < /opt/zapret/files/fake/quic_initial_www_google_com.bin

Отправка этого bin по tcp никак не триггерит блокировку, все tcp и udp продолжают доходить

889123 ens3  In  IP (tos 0x20, ttl 58, id 62482, offset 0, flags [DF], proto TCP (6), length 60)
    src.59482 > dst.40001: Flags [S], cksum 0xbd3e (correct), seq 846631211, win 64240, options [mss 1436,sackOK,TS val 1139924759 ecr 0,nop,wscale 5], length 0
        0x0000:  4520 003c f412 4000 3a06 27e6 05a7 1ef7  E..<..@.:.'.....
        0x0010:  d476 2b8f e85a 9c41 3276 912b 0000 0000  .v+..Z.A2v.+....
        0x0020:  a002 faf0 bd3e 0000 0204 059c 0402 080a  .....>..........
        0x0030:  43f1 df17 0000 0000 0103 0305            C...........
889217 ens3  Out IP (tos 0x20, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    dst.40001 > src.59482: Flags [R.], cksum 0x42ee (correct), seq 0, ack 846631212, win 0, length 0
        0x0000:  4520 0028 0000 4000 4006 160d d476 2b8f  E..(..@.@....v+.
        0x0010:  05a7 1ef7 9c41 e85a 0000 0000 3276 912c  .....A.Z....2v.,
        0x0020:  5014 0000 42ee 0000                      P...B...

Пока что считаю, что эта даже не блокировка конкретно шейков WG, а блокировка всех udp пакетов выше какого-то размера, т.к 3 пакета с длиной 10 байт (38 байт) проходят и блокировки нет

Отправка 10 байт из букв А

printf 'AAAAAAAAAA' | socat - UDP:ip:40000

Тспдамп на сервере

077538 ens3  In  IP (tos 0x20, ttl 58, id 50525, offset 0, flags [DF], proto UDP (17), length 38)
    src.42356 > dst.40000: [udp sum ok] UDP, length 10
        0x0000:  4520 0026 c55d 4000 3a11 5d63 05a7 183a  E..&.]@.:.]c...:
        0x0010:  d476 2b8f a574 9c40 0012 59e8 4141 4141  .v+..t.@..Y.AAAA
        0x0020:  4141 4141 4141 0000 0000 0000 0000       AAAAAA........
901499 ens3  In  IP (tos 0x20, ttl 58, id 20819, offset 0, flags [DF], proto UDP (17), length 38)
    src.53564 > dst.40000: [udp sum ok] UDP, length 10
        0x0000:  4520 0026 5153 4000 3a11 d16d 05a7 183a  E..&QS@.:..m...:
        0x0010:  d476 2b8f d13c 9c40 0012 2e20 4141 4141  .v+..<.@....AAAA
        0x0020:  4141 4141 4141 0000 0000 0000 0000       AAAAAA........
082139 ens3  In  IP (tos 0x20, ttl 58, id 26812, offset 0, flags [DF], proto UDP (17), length 38)
    src.53612 > dst.40000: [udp sum ok] UDP, length 10
        0x0000:  4520 0026 68bc 4000 3a11 ba04 05a7 183a  E..&h.@.:......:
        0x0010:  d476 2b8f d16c 9c40 0012 2df0 4141 4141  .v+..l.@..-.AAAA
        0x0020:  4141 4141 4141 0000 0000 0000 0000       AAAAAA........

А при отправке свыше 140 задевает триггер и помогает только получение нового адреса от провайдера.

Саппорт хостинга отрицает, что это они блочат, мол, это не анти-дудос

UPD: будто бы откатили всё, любые шейки и пакеты любой другой длины начали долетать…

А что-то на tcp у вас работает? Поднимите сайт, проверьте. Лучше по тяжелее, я для этого использую speedtest

По здешним наблюдениям про рабочие порты ниже 1000 поигрался с AWG 2.

Сначала был порт 47990/udp - работало на РТК и МТС/Т-Мобайл, но не работало на гостевом интернете на работе (там сейчас ни WG обычный не работает, xray и обычный AWG 2 сначала поработает, потом отваливается).

Поменял на 990/udp - заработало ещё и на гостевом интернете. При этом в конфиге ещё и дополнительно добавлен quic junk google откуда-то, но маловероятно что оно влияет.