Сервер и клиент Wireguard могут пинговать друг друга, но клиенты Wireguard не могут пинговать друг друга

Aug 18 2020

Я настраиваю конфигурацию Wireguard, в которой у меня есть следующие объекты:

  1. Экземпляр удаленной виртуальной машины на таких хостах, как Google Cloud или Amazon AWS. Это удаленный клиент моего сервера Wireguard. Назовем этоgcp_client

  2. Сервер защиты проводов на машине, размещенной в моей локальной сети. Назовем это srvlan.

  • Пересылка IPv4 включена на этом устройстве с помощью sysctl.
  • Между глобальной сетью и моей локальной сетью находится Ubiquiti Edgerouter 4. Я включил переадресацию портов и закрепляющий NAT на этом устройстве. Я также настроил динамический DNS на этом роутере.
  1. Один или несколько клиентов в моей локальной сети, которые должны иметь возможность подключаться к удаленному клиенту, как если бы это была машина в моей локальной сети. Поскольку я столкнулся с проблемой самого моего первого клиента, давайте назовем ее client1.

В моей установке, я могу пинговать между srvlanи в gcp_clientобоих направлениях, и между ними client1и srvlanкак хорошо. Тем не мение. пинги от gcp_clientдо client1(и наоборот) терпят неудачу.

Прочитав результаты tcpdump -i wg0 -n icmp, я сделал следующие наблюдения:

  1. Пинги от client1для gcp_clientдостижения, srvlanно не пересылаются на маршрутизатор.
  2. Отклики от 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
        }
}

Ответы

A.B Aug 26 2020 at 00:35

Когда 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 используется как для приема пакета на основе его источника (и определения того, какой одноранговый узел и, возможно, обновления его конечной точки в случае роуминга), так и для определения, какому одноранговому узлу отправить пакет на основе его пункта назначения.