Satu peer WireGuard tidak terjangkau sementara yang lain berfungsi: daftar periksa

Satu peer WireGuard meneruskan lalu lintas dan peer kedua menyelesaikan jabat tangan tetapi tidak pernah mencapai apa pun di balik terowongan. Peer yang berfungsi memberi tahu Anda bahwa antarmuka, port UDP, dan kunci server kemungkinan baik-baik saja. Ia tidak memberi tahu apa pun tentang AllowedIPs peer kedua, alamat sumber dalamnya, atau aturan penerusan di antaranya. Kerjakan daftar secara berurutan dan berhenti pada langkah pertama yang syaratnya gagal.

Langkah 1: Tuliskan jalur yang seharusnya dilalui paket

Dua klien pada hub yang sama tidak otomatis saling menjangkau. Dalam desain hub-dan-jari-jari, server menerima paket pada wg0 dan harus meneruskannya kembali keluar dari wg0 ke peer lain, yang membutuhkan penerusan IP dan aturan penerusan. Dalam desain peer-ke-peer langsung, setiap sisi membutuhkan titik akhir sisi lain dan alamat terowongannya di dalam AllowedIPs. Putuskan desain mana yang sedang Anda periksa sebelum membaca konfigurasi apa pun.

Jalur yang diharapkan juga memberi tahu Anda di mana harus melihat. Jika paket harus melintasi hub, hop yang gagal adalah AllowedIPs pengirim, penerusan hub, atau AllowedIPs penerima. Jika paket harus langsung, hub tidak relevan dan bidang titik akhir pada kedua peer yang penting.

Langkah 2: Bandingkan AllowedIPs di kedua sisi, bukan hanya satu

WireGuard menggunakan AllowedIPs sekaligus sebagai tabel perutean dan daftar akses. Saat mengirim, alamat tujuan dicari di AllowedIPs peer untuk memilih terowongan; saat menerima, alamat sumber dalam harus berada di dalam AllowedIPs peer pengirim atau paket dibuang. Rentang yang hilang di salah satu sisi menghasilkan gejala yang sama: transportasi berfungsi, muatan hilang.

Baca status langsung alih-alih berkas, karena pemuatan ulang mungkin gagal secara diam-diam: sudo wg show wg0 allowed-ips. Di server, entri peer yang gagal harus memuat alamat terowongannya, misalnya 10.90.0.3/32. Di klien, entri peer server harus memuat tujuan yang Anda uji, baik itu alamat terowongan hub maupun subnet jarak jauh. Rentang yang tumpang tindih membuat pencarian ambigu dan dapat memilih peer yang tidak Anda maksud, jadi jaga keduanya tetap terpisah.

Langkah 3: Periksa alamat sumber dalam

Klien yang merutekan 10.90.0.3 melalui wg0 tetapi mengirim paket dari alamat Wi-Fi-nya akan ditolak oleh penerima, karena sumbernya tidak cocok dengan AllowedIPs peer. Konfirmasi apa yang sebenarnya dipilih kernel dengan ip route get 10.90.0.3 from 10.90.0.2, dan konfirmasi alamat yang diberikan ke antarmuka terowongan dengan ip -brief addr show wg0.

Pada host Linux penerima, penyaringan jalur balik adalah gerbang kedua. rp_filter yang ketat pada antarmuka yang memiliki rute balik dapat membuang lalu lintas terowongan yang jalur baliknya tidak cocok dengan antarmuka tempat paket itu tiba. Periksa nilai efektifnya sebelum menonaktifkannya; pada banyak topologi, perbaikan yang benar adalah rute, bukan penyaring yang dilonggarkan.

Langkah 4: Tinjau penerusan hub dan jalur balik

Jika hub harus meneruskan antar peer, kernel membutuhkan net.ipv4.ip_forward=1, dan firewall harus menerima aliran yang diteruskan: masuk pada wg0, keluar pada wg0, dari alamat terowongan pengirim ke alamat penerima. Kegagalan yang umum adalah aturan masukan yang menerima UDP 51820 tetapi tidak ada aturan penerusan], sehingga jabat tangan berhasil dan muatan mati. Daftar aturan yang berlaku dengan sudo nft list ruleset atau padanan untuk pengelola firewall Anda.

Lalu periksa balasannya. Host tujuan harus memiliki rute balik ke pengirim, baik melalui hub maupun melalui gateway-nya sendiri. Jika hub juga melakukan NAT pada subnet terowongan, konfirmasi bahwa terjemahan tersebut berlaku untuk aliran yang diteruskan dan bahwa balasan mencapai hub sebelum status kedaluwarsa. Kegagalan satu arah yang tampak seperti masalah kunci sering kali justru rute balik ini.

Terakhir, pisahkan jabat tangan dari data. Peer yang menyelesaikan jabat tangan tetapi macet pada transfer besar biasanya memiliki masalah MTU atau MSS pada jalur itu, bukan masalah AllowedIPs. Uji dengan ping kecil lebih dulu, lalu dengan ping berukuran penuh, dan bandingkan kedua peer.

Langkah 5: Ubah satu hal dan biarkan peer yang berfungsi tetap utuh

Lakukan satu perubahan pada jalur yang gagal dan uji ulang kedua peer. Mengganti AllowedIPs setiap peer dengan 0.0.0.0/0 adalah cara tercepat untuk merusak peer yang sudah berfungsi, karena itu mengubah keputusan perutean untuk semua lalu lintas pada antarmuka tersebut. Sunting satu entri itu, muat ulang, dan baca kembali status langsungnya.

Catat jalur mana yang berhasil, mana yang gagal, dan keluaran perintah yang tepat untuk masing-masing. Perbandingan itu lebih bernilai daripada laporan umum bahwa VPN rusak, dan itulah hal pertama yang akan ditanyakan orang berikutnya.