Боюсь что скоро к Антизапрету доберутся их ручонки, вместе с инструментом Goodbye DPI который они могут сделать не работоспособными
Пора опять ставить WireGuard на VPS где-нибудь поближе к Англии?
Временное решение. Не за горами поиск по сигнатурам и active probing
Как решить проблемы с пропажей кнопки VPN в Opera.
Открываем C:\Users*ВАШ_ПРОФИЛЬ*\AppData\Roaming\Opera Software\Opera Stable
Находим файл Secure Preferences
Открываем его в AkelPad или NotePad++
Находим строку “vpn”:{“blacklisted_locations”:[“cn”,“ru”],“last_established_location”:“RU”}}
Заменяем на “vpn”:{“blacklisted_locations”:[“cn”],“last_established_location”:“CN”}}
В данном случае всё делается по аналогии – первый, это Россия , а второй Китай . Следовательно, первый удаляем, и параметр указываем от китайского.
Делаем файл Secure Preferences доступным только для чтения.
Ну и как хак работает или нет? Ну VyprVPN сервис такой себе сервис тех. поддержка и обслуживание клиентов могло быть лучше.
У меня VyprVPN работает все это время, и Wireguard и OpenVPN. Ростелеком, все дела, вот сейчас из-под него пишу. Ничего не менял.
)) pong на двух разных провайдерах.
Мобильный мегафон - ERR_TIMED_OUT, goodbyeDPI помогает
26 августа знакомый из Саратова жаловался на интернет соединение через Wireguard на Эстонию (не публичные vpn), провайдер ДомРу. На проводе было тоже самое, видимо тестили что-то.
На выходных переставал работать WireGuard. Примерно в середине дня по МСК заработал.
Проверял на NordVPN, Mullvad и self-hosted.
Провайдер - домашний мтс.
У NordVPN, кстати, отваливался только WireGuard. Всё остальное работало.
el3xyz started a thread on the WireGuard mailing list with a patch for per-packet payload obfuscation in WireGuard and is asking for comments.
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
To make detection more difficult two things are being done
- handshake initiation, response and cookie messages are padded with random sized garbage
- Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions).
I posted commands for setting it up that worked for me.
On both peers:
$ sudo apt install build-essential linux-headers-amd64
$ cd
$ git clone https://github.com/el3xyz/wireguard-linux-compat
$ cd wireguard-linux-compat/src
$ make DEV=wireguard_obf
$ sudo make install
$ cd
$ git clone https://github.com/el3xyz/wireguard-tools
$ cd wireguard-tools/src
$ make DEV=wireguard_obf
$ cd
$ (umask 077; ~/wireguard-tools/src/wg genkey > privatekey)
$ ~/wireguard-tools/src/wg pubkey < privatekey > publickey
One one peer:
peera$ sudo ip link add dev wgobf0 type wireguard_obf
peera$ sudo ip address add dev wgobf0 192.168.2.1 peer 192.168.2.2
peera$ sudo ~/wireguard-tools/src/wg set wgobf0 \
listen-port 51820 \
private-key privatekey \
peer [peerb-publickey] \
allowed-ips 0.0.0.0/0 \
endpoint [peerb-ip]:51820
peera$ sudo ip link set up dev wgobf0
On the other peer:
peerb$ sudo ip link add dev wgobf0 type wireguard_obf
peerb$ sudo ip address add dev wgobf0 192.168.2.2 peer 192.168.2.1
peerb$ sudo ~/wireguard-tools/src/wg set wgobf0 \
listen-port 51820 \
private-key privatekey \
peer [peera-publickey] \
allowed-ips 0.0.0.0/0 \
endpoint [peera-ip]:51820
peerb$ sudo ip link set up dev wgobf0
Nice to hear somebody works in this direction too. It did something similar about 2 years ago.
Instead of patching vpn code i created simple xor ip packet obfuscator with 2 versions : linux kernel mod and NFQUEUE handler.
The main problem is that its linux only (and android with NFQUEUE), lacks easiness and does not support all supported by wireguard platforms
From my view it would be the best for wireguard developers to implement optional obfuscation in the mainline code, including non-linux implementations.
Otherwise to make it easy for anyone someone must fork all the wireguard code and create/maintain separate version
Hey bolvan,
I talked to Jason and he is not going to add obfuscation to mainline WG and has every right to do so. His point is that this will just tighten the restrictions imposed by local regulators, while each new obfuscation method will make protocol incompatible.
My understanding is Russia currently implementing 2nd generation of blocks which is based on DPI and DNS spoofing, while China adopts 3rd generation which is based on DPI/DNS spoofing combined with statistical models and active probing. The latter can detect and block even obfuscated WG traffic, however encapsulating obfuscated WG packets to QUIC and use round robin selection for endpoints may work even in this case.
Cheers
As far as I understand wireguard is protected against replay attacks and also does not reply to malformed packets or packets encrypted with the wrong key. That’s why it may be protected from active probing. But not statistical methods. Am I right ?
Anyway, I think its good to have proper instrumentation for every blocks generation
It might take a while for the regulator to impose next block generation model
Tools such as udp2raw already exist and people will use them anyway or use another simplier solution if it appears. So it will not stop the regulator from escalating its blocking. Even not sure it will delay.
We talk about a fast vpn that supports obfuscation natively without any thirdparty usermode tools.
I think the key factor here is easiness. Most people are lazy nowadays and absenсe of easy solution can significantly reduce the number of users.
Do you have source code for these? A kernel mod or NFQUEUE is what Jason suggested in the thread. I have not done something like that before; it would be good to have a reference example.
Something to be aware of is MASQUE, an IETF project to specify proxy protocols over HTTP (including HTTP/3; i.e. QUIC). There’s a draft-ietf-masque-connect-udp for a CONNECT-UDP HTTP method. I don’t know if there are any implementations.
Of course, it may not be necessary to actually construct a QUIC tunnel; modifying the WireGuard packets to resemble QUIC will probably work as well.
Exactly. Also it’s protected against RST attack used by GFW of China, just because it’s UDP based. With statistical methods one may try to classify traffic as web browsing (idle periods intermixed with high bandwidth usage) and start blocking it if other properties match (UDP, high entropy of the packet, you name it)
Yep, I understand that doing this in kernel will reduce number of users in several orders of magnitude given the necessity to build/install from sources. Still it was fun and I decided to share results.
I’m thinking about something like udp2raw, still in kernel. I don’t want to stick to NFQUEUE/netfilter by now, given that I have plans for Windows driver as well
Thanks for the link to ipobfs. Reading the source code helped me understand how it works.
According to c - Sending queued packets with NFQUEUE? - Stack Overflow, it’s possible to do fancy traffic shaping operations (delay packets, split packets, send chaff packets, encapsulate packets into another protocol) in a somewhat roundabout way: the userspace program responds NF_DROP to every packet, queues the packets internally, and injects packets into the outgoing network interface when appropriate. In that sense, NFQUEUE can be thought of as an inconvenient and platform-specific alternative to receiving packets from the kernel over a UDP socket or Unix domain socket.