Handshake WireGuard berhasil, tetapi subnet kantor tidak menjawab

Handshake selesai, wg show melaporkan transfer terbaru, dan alamat tunnel server menjawab ping. Host di LAN server tidak. Tiga syarat harus terpenuhi sekaligus: klien harus merutekan prefiks LAN ke tunnel, server harus meneruskan paket, dan balasan memerlukan jalur kembali. Jika salah satu dari tiga hilang, gejalanya sama.

AllowedIPs adalah daftar akses sekaligus tabel perutean

Pada klien, daftar AllowedIPs menentukan apa yang boleh dikirim ke peer itu dan rute mana yang dipasang WireGuard. Entri peer yang hanya mencantumkan alamat tunnel server memasang satu rute host, sehingga tujuan LAN tidak pernah masuk ke tunnel. Menambahkan prefiks LAN adalah hal pertama yang harus diperiksa, dan juga perubahan yang paling sering hilang setelah konfigurasi disalin. Peer yang diperluas ke rute default adalah desain lain, dan itu juga akan memindahkan lalu lintas internet klien.

Pisahkan rute host dan prefiks LAN sebagai entri terpisah. Jika kantor memiliki dua subnet, keduanya masuk ke daftar, dan prefiks kedua yang hilang menghasilkan kegagalan yang tampak selektif, bukan menyeluruh.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Penerusan dan penerjemahan ada di server

Server memerlukan penerusan IP yang aktif, aturan penerusan yang menerima lalu lintas dari tunnel, dan aturan penerjemahan ke antarmuka LAN-nya. Penerjemahan itulah yang membuat desain ini bekerja tanpa menyentuh setiap host di jaringan kantor. Balasan kemudian kembali ke server, bukan ke alamat yang belum pernah didengar LAN. Tanpanya, setiap host memerlukan rute ke subnet tunnel dan aturan firewall yang mengizinkannya, yang jarang dapat diterima di jaringan yang dikelola orang lain.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Aturan yang ditambahkan secara manual hilang saat reboot, jadi ikatkan ke antarmuka dengan perintah hook di konfigurasi server. Kumpulan aturan yang bertahan lebih lama daripada antarmukanya adalah cara sebuah mesin akhirnya menerjemahkan lalu lintas untuk tunnel yang sudah tidak ada.

Ketika LAN pindah dan aturannya tidak

Penggantian router yang menomori ulang subnet kantor adalah versi klasik dari kegagalan ini. Tunnel tetap aktif, handshake tetap segar, dan tidak ada yang menjawab di belakang server, karena aturan penerjemahan masih menyebut alamat lama. Skrip pemasang sering menanamkan alamat LAN server ke dalam aturan POSTROUTING, dan setelah penomoran ulang alamat itu tidak ada di antarmuka mana pun. Paket lalu ditulis ulang ke tujuan yang tidak dapat menjawab.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Bandingkan kedua keluaran. Target penerjemahan yang tidak muncul di daftar antarmuka adalah bugnya, dan memperbaikinya adalah perubahan satu baris setelah Anda melihatnya. Aturan itu mungkin berada di unit yang dihasilkan, bukan di konfigurasi WireGuard, jadi muat ulang unit tersebut setelah mengedit dan pastikan boot berikutnya tidak menulis ulang perubahan Anda.

Dua situs di belakang NAT perlu tempat bertemu

Ketika tidak ada pihak yang menerima koneksi masuk, jawaban praktisnya adalah host kecil dengan alamat publik dan dua antarmuka WireGuard. Setiap situs terhubung ke luar, host tengah mencantumkan LAN setiap peer di AllowedIPs-nya sendiri, dan penerusan membawa paket di antara kedua tunnel. Tidak ada yang perlu diubah di firewall situs mana pun, itulah sebabnya desain ini mudah menyebar.

Perutean antar situs mempertahankan alamat sumber asli dan karena itu menjaga pencatatan per host tetap bermakna. Penerjemahan di host tengah lebih sederhana ketika kedua LAN tumpang tindih, dengan biaya kehilangan identitas sumber di log. Putuskan properti mana yang penting sebelum memilih.

Pisahkan lapisan dengan empat pemeriksaan

Jalankan satu pemeriksaan per lapisan alih-alih mengubah tiga hal dan berharap. Yang pertama menunjukkan usia handshake dan penghitung untuk setiap peer. Yang kedua menunjukkan apakah klien benar-benar merutekan tujuan itu ke tunnel. Yang ketiga dan keempat memberi tahu apakah permintaan tiba dan apakah suatu kebijakan menjatuhkannya setelah tiba.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Permintaan yang tiba dan tidak memicu balasan menunjuk ke jalur balasan atau ke host LAN. Permintaan yang tidak pernah tiba menunjuk ke AllowedIPs atau ke rute klien. Kedua hasil itu memerlukan perbaikan berbeda, dan tangkapanlah yang membedakannya.