Задать вопрос

Почему Wireguard VPN работает только после смены сети?

За рубежом взял в аренду 3 VPS в разных странах (Нидерланды, Англия, США), поставил туда ubuntu, wireguard. Настроил по максимально простым инструкциям. При подключении к любому из 3 серверов наблюдаю одинаковую картину: первый handshake нормально проходит, на сервере wg show показывает что пир подключился, какие-то пакеты сервер и клиент получили. И всё, клиент не может достучаться в интернет, не может до сервера WG (и сервер WG не может достучаться до клиента), хотя они по идее в одной сети, все следующие handshake падают по таймауту.

НО стоит при включённом VPN поменять сеть у клиента на другую (не выключая VPN), как VPN неожиданно начинает работать. Причём если вернуться обратно, на ту сеть при которой был передан первый пакет , то VPN опять перестаёт работать. Неважно в какой сети находиться, главное сменить её на другую и VPN заработает.

Уже не знаю что думать, пытался понять почему VPN не получается завести, обнаружил вот такую особенность. Это очень странно потому что 2 года назад точно так же настраивал VPN на другом VPS и тогда такой проблемы не было (жаль данные с него уже не снять).

Начинаю подозревать, что РКН по первому пакету на подключение определяет, что VPN пытаются подрубить и начинает блокировать дальнейшее общение между адресами. А после смены сети адрес меняется и блок спадает. Но надеюсь, что нет, может кто сталкивался с таким или может подсказать хотя бы куда капнуть.

Конфигурация wireguard на сервере
wg0.conf

[Interface]
PrivateKey = <server_privatekey>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <client1_publickey>
AllowedIPs = 10.0.0.2/32



Конфигурация wireguard на клиенте
client1.conf

[Interface]
PrivateKey = <CLIENT-PRIVATE-KEY>
Address = 10.0.0.2/32
DNS = 8.8.8.8

[Peer]
PublicKey = <SERVER-PUBKEY>
Endpoint = <SERVER-IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 20



И результаты команд на сервере
iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination



iptables -t nat -L -n -v

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 5 packets, 355 bytes)
 pkts bytes target     prot opt in     out     source               destination
 2780  834K MASQUERADE  0    --  *      eth0    0.0.0.0/0            0.0.0.0/0



ip route

default via XX.XX.89.1 dev eth0 proto static
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.1
XX.XX.89.0/24 dev eth0 proto kernel scope link src XX.XX.89.42



ip address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd XX:XX:XX:XX:XX:XX
    altname enp0s18
    inet XX.XX.89.42/24 brd XX.XX.89.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 XXXX::XXXX:XXXX:XXXX:9894/64 scope link
       valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

  • Вопрос задан
  • 866 просмотров
Подписаться 3 Простой 6 комментариев
Помогут разобраться в теме Все курсы
  • Нетология
    1C-программист: расширенный курс
    18 месяцев
    Далее
  • Академия Эдюсон
    Python-разработчик + ИИ
    9 месяцев
    Далее
  • ProductStar × РБК
    Профессия DevOps-инженер + ИИ
    5 месяцев
    Далее
Пригласить эксперта
Ответы на вопрос 5
VoidVolker
@VoidVolker
Dark side eye. А у нас печеньки! А у вас?
Потому что кукуруза, вот почему. (๑-﹏-๑)
Да, WG блокируют, уже давно. Ищите другие решения.
Ответ написан
Комментировать
@Quqas
вы в какой стране были последние года так 3-4? если только "Начинаю подозревать"....

про другуюсеть непонятно и странно

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

https://proton-converter.github.io/ свой клиентский конфиг скармливаешь и получаешь амнезийный, из всего изменения лишь i1 основную роль несёт. только его и можно оставлять
Ответ написан
smorman
@smorman
When In Rome do as The Romans do...
Сделай обфускацию WG с помощью
spoiler
Wstunnel
и всё сразу заработает.

На гите
spoiler
есть ссылка на аглицкий ман, как это сделать...

А просто WG уже давно рубит ркн, одного из первых подрезал именно его...
Ответ написан
@Drno
Только начинаешь?)) лет 7 уже эта котовасия продолжается...

да, по первым пакет определяет WG, обычно это 92 байта, и блокирует. никто давно уже чистым WG не пользуется
Ответ написан
CityCat4
@CityCat4 Куратор тега VPN
Жил да был черный кот за углом...
Я тут вчера замечательную картинку прикреплял - с РКН-тян и ее банхаммером :) Вот это оно и есть :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы