Server dan klien Wireguard dapat melakukan ping satu sama lain tetapi klien wireguard tidak dapat melakukan ping satu sama lain
Saya sedang menyiapkan konfigurasi Wireguard di mana saya memiliki entitas berikut:
Instance VM jarak jauh di host seperti google cloud atau amazon aws. Ini adalah klien jarak jauh ke server wireguard saya. Sebut saja ini
gcp_client
Server wireguard di mesin yang dihosting di LAN saya. Sebut saja ini
srvlan
.
- Penerusan IPv4 diaktifkan di perangkat ini oleh
sysctl
. - Ada Ubiquiti Edgerouter 4 antara WAN dan LAN saya. Saya telah mengaktifkan penerusan port dan NAT hairpin di perangkat ini. Saya juga telah menyiapkan DNS dinamis di router ini.
- Satu atau lebih klien di LAN saya, yang seharusnya dapat terhubung ke klien jarak jauh seolah-olah itu adalah mesin di LAN saya. Karena saya menghadapi masalah dengan klien pertama saya itu sendiri, sebut saja
client1
.
Dalam pengaturan saya, saya dapat melakukan ping antara srvlan
dan gcp_client
kedua cara, dan juga antara client1
dan srvlan
. Namun. ping dari gcp_client
ke client1
(dan sebaliknya) gagal.
Berdasarkan hasil pembacaan tcpdump -i wg0 -n icmp
, saya melakukan observasi sebagai berikut:
- Ping dari
client1
untukgcp_client
menjangkausrvlan
tetapi tidak diteruskan ke router. - Ping dari
gcp_client
untukclient1
mencapai router saya, yang meneruskannya kesrvlan
. Namun paket tidak diteruskansrvlan
keclient1
.
Satu-satunya hal yang dapat saya simpulkan dari sini adalah bahwa aturan penerusan srvlan
entah bagaimana salah. Saya menggunakan nftables
untuk mengelola perangkat ini.
Ini adalah konfigurasi wireguard saya; alamat ip dan nomor port telah diubah.
# 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
Ini firewall saya 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
}
}
Jawaban
Ketika srvlan meneruskan lalu lintas terowongan WireGuard, ia menerimanya dari wg0 dan merutekannya ke ... wg0 lagi: dua kali antarmuka yang sama.
Jadi, Anda perlu menambahkan entri ini ke rantai penerusan firewall inet nftables :
iifname "wg0" oifname "wg0" accept
Masalah lainnya, dalam rantai masuk :
ip protocol icmp accept ip6 nexthdr ipv6-icmp accept ip protocol igmp accept
Meskipun protokol berfungsi untuk IPv4, nexthdr dalam protokol IPv6 tidak menjamin bahwa Header Berikutnya adalah ICMPv6: terdapat beberapa Ekstensi Header antara Fixed Header dan header protokol lapisan atas. Jika header ekstensi seperti itu muncul di beberapa paket, maka nexthdr ipv6-icmp
tidak akan cocok lagi. Gunakan sintaks yang benar, untuk IPv4 dan IPv6:
meta nfproto ipv4 meta l4proto icmp accept
meta nfproto ipv6 meta l4proto ipv6-icmp accept
meta nfproto ipv4 meta l4proto igmp accept
Bergantung pada versi nftables , itu akan ditampilkan kembali dalam bentuk yang lebih disederhanakan.
iifname "wg0" udp dport 50000 ct state new accept
Porta 50000 tidak muncul di dalam antarmuka WireGuard (kecuali Anda ingin menyalurkan WireGuard di dalam WireGuard), tetapi di luar (yang sudah ada aturannya). Seharusnya tidak dibutuhkan.
Ingat ketika Anda menambahkan lebih WireGuard klien / rekan-rekan (seperti yang Anda lakukan dengan benar), bahwa tidak mungkin ada tumpang tindih dalam srvlan 's AllowedIPs entri karena mereka menentukan cryptorouting yang terjadi di WireGuard untuk memilih rekan yang memadai, setelah routing standar. Selain itu, jika gcp_client terhubung melalui srvlan ke server yang tidak menggunakan tunnel WireGuard, maka alamat LAN mereka juga harus ditambahkan ke AllowedIPs dan tabel routing gcp_client . AllowedIPs digunakan untuk menerima paket berdasarkan sumbernya (dan menentukan peer mana dan mungkin mengupdate endpoint-nya jika ada roaming), dan untuk menentukan peer mana yang akan mengirim paket berdasarkan tujuannya.