Сервер и клиент Wireguard могут пинговать друг друга, но клиенты Wireguard не могут пинговать друг друга
Я настраиваю конфигурацию Wireguard, в которой у меня есть следующие объекты:
Экземпляр удаленной виртуальной машины на таких хостах, как Google Cloud или Amazon AWS. Это удаленный клиент моего сервера Wireguard. Назовем это
gcp_client
Сервер защиты проводов на машине, размещенной в моей локальной сети. Назовем это
srvlan
.
- Пересылка IPv4 включена на этом устройстве с помощью
sysctl
. - Между глобальной сетью и моей локальной сетью находится Ubiquiti Edgerouter 4. Я включил переадресацию портов и закрепляющий NAT на этом устройстве. Я также настроил динамический DNS на этом роутере.
- Один или несколько клиентов в моей локальной сети, которые должны иметь возможность подключаться к удаленному клиенту, как если бы это была машина в моей локальной сети. Поскольку я столкнулся с проблемой самого моего первого клиента, давайте назовем ее
client1
.
В моей установке, я могу пинговать между srvlan
и в gcp_client
обоих направлениях, и между ними client1
и srvlan
как хорошо. Тем не мение. пинги от gcp_client
до client1
(и наоборот) терпят неудачу.
Прочитав результаты tcpdump -i wg0 -n icmp
, я сделал следующие наблюдения:
- Пинги от
client1
дляgcp_client
достижения,srvlan
но не пересылаются на маршрутизатор. - Отклики от
gcp_client
кclient1
до моего маршрутизатора, который направляет ихsrvlan
. Однако пакеты не пересылаютсяsrvlan
наclient1
.
Единственное, что я могу сделать из этого, это то, что правила переадресации srvlan
каким-то образом ошибочны. Я использую nftables
для управления этим устройством.
Это моя конфигурация ограждения; IP-адреса и номер порта были изменены.
# wg0.conf for gcp_client
[Interface]
Address = 10.0.1.2/24
ListenPort = 50000
PrivateKey = gcp_client_privkey
[Peer]
PublicKey = srvlan_pubkey
AllowedIPs = 10.0.1.0/24
Endpoint = srvlan_ddns:50000
# wg0.conf for srvlan
[Interface]
Address = 10.0.1.1/24
ListenPort = 50000
PrivateKey = srvlan_privkey
[Peer]
PublicKey = gcp_client_pubkey
AllowedIPs = 10.0.1.2/32
Endpoint = gcp_client_domainname:50000
PersistentKeepalive = 25
[Peer]
PublicKey = client1_pubkey
AllowedIPs = 10.0.1.3/32
Endpoint = client1_lanhostname:50000
PersistentKeepalive = 25 # I realise this one is unnecessary, but I had added it while testing just in case the problem got fixed.
# wg0.conf for client1
[Interface]
Address = 10.0.1.3/24
ListenPort = 50000
PrivateKey = client1_privkey
[Peer]
PublicKey = srvlan_pubkey
AllowedIPs = 10.0.1.0/24
Endpoint = srvlan_lanhostname:50000
Это мой брандмауэр включен srvlan
.
# nft list ruleset
table inet firewall {
chain inbound {
type filter hook input priority filter; policy drop;
ct state established,related accept
ct state invalid drop
iif "lo" accept
ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
ip protocol igmp accept
tcp dport 22 accept
iifname "eno1" tcp dport { 80, 443 } ct state new accept
iifname "eno1" udp dport 50000 ct state new accept
iifname "wg0" udp dport 53 ct state new accept
iifname "wg0" tcp dport { 80, 443 } ct state new accept
iifname "wg0" udp dport 50000 ct state new accept
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
ct state invalid drop
iifname "wg0" oifname "eno1" ct state new accept
}
chain outbound {
type filter hook output priority filter; policy accept;
ct state invalid drop
}
}
table ip router {
chain prerouting {
type nat hook prerouting priority filter; policy accept;
}
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifname "eno1" ip saddr 10.0.1.0/24 masquerade
}
}
Ответы
Когда srvlan пересылает трафик, туннелированный WireGuard, он получает его от wg0 и снова направляет на ... wg0 : дважды тот же интерфейс.
Итак, вам нужно добавить эту запись в прямую цепочку nftables брандмауэра inet :
iifname "wg0" oifname "wg0" accept
Другие проблемы во входящей цепочке :
ip protocol icmp accept ip6 nexthdr ipv6-icmp accept ip protocol igmp accept
Хотя протокол работает для IPv4, nexthdr в протоколе IPv6 не гарантирует, что следующим заголовком будет ICMPv6: между фиксированным заголовком и заголовком протокола верхнего уровня может быть несколько заголовков расширения . Если такие заголовки расширения появляются в некоторых пакетах, они nexthdr ipv6-icmp
больше не будут совпадать. Используйте правильный синтаксис для IPv4 и IPv6:
meta nfproto ipv4 meta l4proto icmp accept
meta nfproto ipv6 meta l4proto ipv6-icmp accept
meta nfproto ipv4 meta l4proto igmp accept
В зависимости от версии nftables он будет отображаться в более упрощенном виде.
iifname "wg0" udp dport 50000 ct state new accept
Порт 50000 появляется не внутри интерфейса WireGuard (если вы не хотите туннелировать WireGuard внутри WireGuard), а снаружи (для чего уже существует правило). В этом не должно быть необходимости.
Помните , как вы добавить больше WireGuard клиентов / коллег (как вы сделали правильно), что не может быть перекрываются в srvlan «s AllowedIPs записях , так как они определяют cryptorouting , что происходит в WireGuard , чтобы выбрать адекватный пэр, после стандартной маршрутизации. Кроме того, если gcp_client подключается через srvlan к серверам, не использующим туннели WireGuard, их адрес LAN также должен быть добавлен как в AllowedIP, так и в таблицу маршрутизации gcp_client . AllowedIPs используется как для приема пакета на основе его источника (и определения того, какой одноранговый узел и, возможно, обновления его конечной точки в случае роуминга), так и для определения, какому одноранговому узлу отправить пакет на основе его пункта назначения.