Сервер Wireguard и пир недоступны

Вопрос или проблема

Я ищу решение этой проблемы уже некоторое время и очень нуждаюсь в вашей помощи, чтобы увидеть, где я допустил ошибку.

Я установил Wireguard на VPS-сервер.

Вот конфигурация моего сервера:

[Interface]
Address = 10.8.88.1/24
#Address = fdb2:50d2:58fe::1/64
SaveConfig = false
ListenPort = 51820
PrivateKey = <Server-Private-Key>

PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
#X-Desktop
PublicKey = x97QepJTQaNXXXXXXXXXMdFsG97P4gxT8TbL34=
AllowedIPs = 10.8.88.2/32  
PersistentKeepalive = 25

[Peer]
#Hauwei Y9S Phone
PublicKey = N4liWuOjJFXXXXXXXXXXd/9JCnT5OGUxgYWw=
AllowedIPs = 10.8.88.3/32
PersistentKeepalive = 25

На моем компьютере (Peer) у меня следующая конфигурация:

[Interface]
PrivateKey = QO+XXXXXXXXXXXXXXXXXXXXXXXXXXXtVsLZh1VXo=
Address = 10.8.88.2
#Address = fdb2:50d2:58fe::2/64

[Peer]
PublicKey = YyC+DXXXXXXXXXXXXXXXXXXXXXCUBvxMTzCw=  # Публичный ключ сервера
AllowedIPs = 10.8.88.0/24
Endpoint = 107.X.X.X:51820 # IP-адрес сервера

Я разрешил порт через UFW:

#ufw status
51820/udp                  ALLOW       Anywhere
Anywhere                   ALLOW OUT   Anywhere on wg0           
Anywhere (v6)              ALLOW OUT   Anywhere (v6) on wg0      

Anywhere on wg0            ALLOW FWD   Anywhere on eth0          
Anywhere on eth0           ALLOW FWD   Anywhere on wg0           
Anywhere (v6) on wg0       ALLOW FWD   Anywhere (v6) on eth0     
Anywhere (v6) on eth0      ALLOW FWD   Anywhere (v6) on wg0

Я даже отключил UFW, но это не помогло!

Я также проверил переадресацию ipv4:

~# sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Если я выполню #ip a, это покажет, что интерфейс UP:

22: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.8.88.1/24 scope global wg0
       valid_lft forever preferred_lft forever

lsmod | grep wireguard
wireguard              90112  0
libchacha20poly1305    16384  1 wireguard
ip6_udp_tunnel         16384  1 wireguard
udp_tunnel             20480  1 wireguard
libblake2s             16384  1 wireguard
curve25519_x86_64      36864  1 wireguard
libcurve25519_generic    49152  2 curve25519_x86_64,wireguard

Статус службы показывает, что она активна как на сервере, так и на моем компьютере (peer)

sudo systemctl status wg-quick@wg0
● [email protected] - WireGuard via wg-quick(8) для wg0
     Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2024-09-26 03:12:36 WIB; 18min ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 740891 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 740891 (code=exited, status=0/SUCCESS)
        CPU: 301ms

Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] ip link add wg0 type wireguard
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] wg setconf wg0 /dev/fd/63
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] ip -4 address add 10.8.88.1/24 dev wg0
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] ip link set mtu 1420 up dev wg0
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] ufw route allow in on wg0 out on eth0
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740927]: Правило добавлено
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740927]: Правило добавлено (v6)
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Sep 26 03:12:36 racknerd-04bcdf wg-quick[740891]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Sep 26 03:12:36 racknerd-04bcdf systemd[1]: Завершено WireGuard via wg-quick(8) для wg0.

Проверка пиров с моего настольного компьютера (peer)

x@x-desktop:~$ sudo wg
interface: wg0
  public key: x97QeXXXXXXXXXXXXXXXXXXXXXXXXTbL34=
  private key: (hidden)
  listening port: 33558

peer: YyCfXXXXXXXXXXXXXXXXXXXXXXXX3QCUBvxMTzCw=
  endpoint: 107.X.X.X:51820
  allowed ips: 10.8.88.0/24
  transfer: 0 B received, 8.82 KiB sent

Проверка пиров со стороны сервера:

#wg
interface: wg0
  public key: YyCfXXXXXXXXXXXXXXXXXXXXXXXXXXMTzCw=
  private key: (hidden)
  listening port: 51820

peer: x97QXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXT8TbL34=
  allowed ips: 10.8.88.2/32
  persistent keepalive: каждые 25 секунд

peer: N4liXXXXXXXXXXXXXXXXXXXXXXOGUxgYWw=
  allowed ips: 10.8.88.3/32
  persistent keepalive: каждые 25 секунд

Когда я пингую со стороны сервера:

ping 10.8.88.2
PING 10.8.88.2 (10.8.88.2) 56(84) bytes of data.
From 10.8.88.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.8.88.1 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.8.88.1 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.8.88.1 icmp_seq=4 Destination Host Unreachable
ping: sendmsg: Destination address required

Когда я пингую со стороны Peer, запрос просто зависает и ничего не показывает.

Многие говорят, что это проблема с “AllowedIP“, но я пробовал многие варианты:

10.8.88.2
10.8.88.2/32 (указывая CIDR). Ничто не сработало.

Что может быть не так?

Ответ или решение

Проблема, с которой вы столкнулись, может быть вызвана несколькими факторами. Давайте рассмотрим возможные причины и шаги по устранению неполадок, чтобы убедиться, что ваш сервер WireGuard и клиенты (пиры) могут общаться друг с другом.

1. Проверка конфигурации

Убедитесь, что конфигурации на сервере и пирах корректны.

На сервере:

  • PrivateKey должен быть вашим приватным ключом.
  • Каждому пире (клиенту) необходимо присвоить уникальный AllowedIPs.
  • Убедитесь, что PersistentKeepalive установлен для всех клиентов (пиров), чтобы поддерживать соединение активным.

На клиенте (пи):

  • В поле PublicKey у вас должен быть публичный ключ сервера, а не клиента. Убедитесь, что вы указали правильный ключ.
  • AllowedIPs прописан правильно. Для вашего сценария 10.8.88.0/24 подходит, так как позволяет доступ ко всем адресам в подсети.

2. Сетевые настройки и NAT

Вы указали, что на сервере настроен iptables, чтобы маскировать пакеты. Убедитесь, что это правило работает корректно. Попробуйте добавить такие правила, которые разрешают весь трафик с интерфейса wg0:

iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Убедитесь, что NAT настроен правильно:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

3. Проверка маршрутизации

Убедитесь, что маршрутизация настроена правильно:

  • На клиенте, вы можете проверить маршруты с помощью команды:

    ip route

    Убедитесь, что маршруты к подсетям WireGuard (10.8.88.0/24).

  • На сервере, проверьте, что он может отправлять пакеты в подсеть WireGuard.

4. Проверка подключения

На сервере выполните:

wg

Убедитесь, что пиры отображаются и что вы видите законные AllowedIPs. Затем проверьте статус интерфейса:

ip a

Проверьте, что интерфейс wg0 настроен и активен.

5. Отладка пакетов

Используйте утилиту tcpdump, чтобы отследить пакеты:

На сервере:

sudo tcpdump -i wg0

На клиенте (пи):

sudo tcpdump -i wg0

Это даст вам понять, проходят ли пакеты через интерфейс. Если вы не видите пакетов, это указывает на проблемы с конфигурацией или маршрутизацией.

6. Проверка UFW

Попробуйте временно отключить UFW и проверить, решает ли это проблему. Если связь восстанавливается, убедитесь, что ваши правила UFW настроены корректно.

7. Логи и сообщения об ошибках

Проверьте логи службы WireGuard на сервере и клиенте, чтобы найти возможные сообщения об ошибках. Вы можете использовать:

journalctl -xe | grep wg

Заключение

При устранении неполадок важно систематически проверять каждую из этих областей. Иногда проблема может быть в одной из мелочей, такой как неправильный ключ или неактивный интерфейс. Убедитесь, что все ключи, адреса и правила настроены правильно. Если проблема все еще не решена, сообщите больше информации о статусе вашего соединения и описания, что именно происходит, когда вы пытаетесь подключиться.

Оцените материал
Добавить комментарий

Капча загружается...