Wireguard sunucusu ve istemci birbirlerine ping atabilir, ancak wireguard istemcileri birbirlerine ping atamaz

Question

Aşağıdaki varlıklara sahip olduğum bir Wireguard yapılandırması kuruyorum:

1. Google bulut veya amazon aws gibi ana bilgisayarlarda uzak sanal makine örneği. Bu, wireguard sunucumun uzak istemcisidir. Buna diyelimgcp_client

2. LAN'ımda barındırılan bir makinedeki bir wireguard sunucusu. Buna diyelim srvlan.

• IPv4 yönlendirme, bu cihazda tarafından etkinleştirildi sysctl.
• WAN ve LAN'ım arasında bir Ubiquiti Edgerouter 4 var. Bu cihazda bağlantı noktası yönlendirmeyi ve saç tokası NAT'ı etkinleştirdim. Ayrıca bu yönlendiricide dinamik bir DNS kurdum.

1. LAN'ımdaki bir veya daha fazla istemci, uzak istemciye LAN'ımdaki bir makineymiş gibi bağlanabilmelidir. İlk müşterimle ilgili problemle karşı karşıya olduğum için, onu arayalım client1.

Benim kurulumunda, ben arasında ping am güçlü srvlanve gcp_clienther iki yönde ve aralarında client1ve srvlanhem de. Ancak. pingler, gcp_client- client1(ve tersi) başarısız olur.

Sonuçlarını okuyarak tcpdump -i wg0 -n icmpşu gözlemleri yaptım:

1. Adresinden ulaşmak client1için ping atıyor, ancak yönlendiriciye iletilmiyor.gcp_clientsrvlan
2. Yönlendiricime ulaşmak gcp_clientiçin pingler, client1onları yönlendiriyor srvlan. Ancak paketler srvlanadresine iletilmez client1.

Bundan çıkarabileceğim tek şey, iletim kurallarının bir srvlanşekilde hatalı olduğu. nftablesBu cihazı yönetmek için kullanıyorum .

Bu benim wireguard konfigürasyonum; ip adresleri ve bağlantı noktası numarası değiştirildi.

# 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

Bu benim güvenlik duvarım açık 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
        }
}

Answer 1

Ne zaman srvlan ileriye trafik WireGuard-tünel, bu onu aldığı wg0 ve ... yolları bu wg0 tekrar: iki kez aynı arayüz.

Bu nedenle, bu girişi inet güvenlik duvarı ileri nftables zincirine eklemeniz gerekir :

                iifname "wg0" oifname "wg0" accept

Gelen zincirdeki diğer sorunlar :

---

                ip protocol icmp accept
                ip6 nexthdr ipv6-icmp accept
                ip protocol igmp accept

Protokol IPv4 için çalışırken , IPv6 protokolündeki nexthdr , Sonraki Başlığın ICMPv6 olacağını garanti etmez: Sabit Başlık ve üst katman protokol başlığı arasında birkaç Uzantı Başlığı olabilir. Bu tür uzantı başlıkları bazı paketlerde görünüyorsa, nexthdr ipv6-icmpartık eşleşmeyecektir. IPv4 ve IPv6 için doğru sözdizimini kullanın:

                meta nfproto ipv4 meta l4proto icmp accept
                meta nfproto ipv6 meta l4proto ipv6-icmp accept
                meta nfproto ipv4 meta l4proto igmp accept

Nftables sürümüne bağlı olarak, daha basitleştirilmiş bir biçimde geri görüntülenecektir.

---

                iifname "wg0" udp dport 50000 ct state new accept

Bağlantı noktası 50000, WireGuard arabiriminin içinde görünmez (WireGuard içinde WireGuard'ı tünellemek istemiyorsanız), ancak dışarıda (bunun için zaten bir kural vardır). Gerekli olmamalı.

---

(Doğru yaptığı gibi) daha WireGuard müşteri / eş ekledikçe orada çakışmaları olamayacağını unutmayın srvlan 'ın AllowedIPs onlar standart yönlendirme sonra, yeterli bir eş seçmek için WireGuard olur cryptorouting belirlemek beri girdileri. Ayrıca, gcp_client srvlan aracılığıyla WireGuard tünellerini kullanmayan sunuculara bağlanırsa , LAN adresleri de hem İzin VerilenIP'lere hem de gcp_client'in yönlendirme tablosuna eklenmelidir . İzin verilen IP'ler , hem kaynağına bağlı olarak bir paketi kabul etmek (ve dolaşım durumunda hangi eş ve belki de uç noktasını güncellemek) hem de hedefine bağlı olarak bir paketi hangi eşe göndereceğini belirlemek için kullanılır.