Handshake WireGuard berhasil tetapi tidak ada internet: lacak paketnya

Terowongan aktif, wg show melaporkan handshake baru, Anda bisa ping alamat terowongan server, dan tidak ada apa pun di baliknya yang menjawab. Naluri pertama adalah membuat ulang kunci atau membagikan ulang konfigurasi. Itu justru mengubah bagian jalur yang sudah terbukti berfungsi.

Handshake yang selesai mengatakan kedua pihak sepakat soal kunci, UDP mencapai titik akhir, dan perutean kripto menerima paket. Itu tidak mengatakan apa pun tentang apakah paket bisa meninggalkan server setelahnya.

Jadi lacak satu paket alih-alih menebak. Ada empat tempat paket itu bisa mati, dan masing-masing meninggalkan jejak berbeda.

Apa yang sebenarnya dibuktikan handshake

WireGuard adalah protokol UDP yang membangun sesi dengan handshake Noise lalu mengenkripsi paket untuk sebuah peer. Saat wg show menampilkan handshake berumur beberapa detik dan penghitung transfer yang naik, titik akhir, kunci, dan kunci publik peer semuanya benar.

Yang tidak dibuktikannya adalah bahwa klien Anda mengirim lalu lintas menuju internet ke antarmuka sama sekali, bahwa server bersedia meneruskannya, atau bahwa balasan bisa menemukan jalan pulang. Itu keputusan perutean kernel dan firewall, dan diambil di luar terowongan.

Inilah sebabnya ping ke alamat terowongan server menjadi uji yang begitu menyesatkan. Paket itu ditujukan ke server itu sendiri, jadi ia berakhir secara lokal. Ia tidak pernah butuh penerusan, tidak pernah butuh terjemahan, dan tidak pernah butuh rute balik dari internet.

AllowedIPs adalah keputusan perutean

Di klien, AllowedIPs melakukan dua tugas. Ini adalah tabel perutean kunci kripto yang memutuskan alamat tujuan mana yang dikirim ke terowongan peer ini, dan ini adalah daftar alamat sumber yang akan diterima peer dari Anda. Jika konfigurasi klien hanya mencantumkan 10.8.0.0/24, tujuan publik tidak pernah masuk ke antarmuka dan rute default biasa Anda membawanya ke luar terowongan. Terowongan lalu bekerja sempurna dan tidak melakukan apa pun yang Anda inginkan.

Lihat apa yang benar-benar dipasang klien, bukan apa yang dikatakan berkas konfigurasi:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Perintah kedua yang menentukan. Jika jawabannya menyebut antarmuka fisik Anda dan gateway biasa, paket tidak sedang diterowangkan dan tidak ada perubahan di sisi server yang akan memperbaikinya. Tambahkan 0.0.0.0/0 untuk IPv4 dan ::/0 untuk IPv6 secara terpisah; aturan yang menangkap semua untuk satu keluarga membiarkan yang lain di jalur aslinya, dan itu penyebab umum terowongan IPv4 yang berfungsi dan pencarian IPv6 yang macet.

Di mana paket mati di gateway

Jika rutenya benar dan paket tetap tidak ke mana-mana, paket itu tiba di server dan berhenti di sana. Empat pemeriksaan mencakup sebagian besar gateway.

Penerusan. sysctl net.ipv4.ip_forward yang mengembalikan 0 adalah jawaban klasik, dan banyak distribusi masih bernilai 0 secara bawaan. Nilainya harus 1, dan disetel permanen di berkas sysctl, bukan dengan perintah yang hilang saat reboot. Penerusan IPv6 adalah sakelar terpisah.

Kebijakan penyaringan. Rantai FORWARD dengan kebijakan drop bawaan akan membuang lalu lintas terowongan sementara mengizinkan lalu lintas ke host itu sendiri, yang persis cocok dengan gejalanya. Baca kumpulan aturan yang hidup, bukan berkas tersimpan: nft list ruleset atau iptables -S.

Terjemahan atau perutean. Klien dengan alamat terowongan privat membutuhkan NAT sumber di antarmuka keluar server, atau prefiks terutek yang diketahui jaringan di atasnya cara mengembalikannya. Pilihan di antara keduanya mengikuti rencana alamat. Menambahkan MASQUERADE ke jaringan yang sudah merutekan prefiks Anda kembali tidak berbahaya tetapi sia-sia, dan menghilangkannya di tempat yang tidak ada rute membuat balasan dialamatkan ke rentang privat yang tidak dapat dirutekan.

Jalur pulang. Dalam desain terutek, router di atasnya membutuhkan rute yang menunjuk ke server Anda. Jaringan penyedia juga bisa memblokirnya: beberapa cloud mengaktifkan pemeriksaan sumber dan tujuan pada instans, yang diam-diam membuang paket yang sumbernya bukan alamat instans itu sendiri sampai pemeriksaan itu dinonaktifkan.

DNS gagal dengan cara yang berbeda dari perutean

Paket ke alamat yang dikenal dan pencarian nama adalah dua kegagalan terpisah, dan pesan kesalahannya menyesatkan ke arah yang berlawanan. Jika ping 1.1.1.1 berfungsi dan peramban tidak bisa memuat apa pun, rutenya baik dan resolusi namanya tidak. Jika ping-nya sendiri gagal, DNS tidak relevan dan Anda kembali ke bagian sebelumnya.

wg-quick dapat menyetel resolver dari baris DNS = dalam konfigurasi, dan systemd-resolved punya perilakunya sendiri per tautan. VPN yang menimpa resolver dengan alamat yang hanya terjangkau di dalam terowongan akan menggagalkan setiap pencarian pada saat terowongan putus, yang terlihat seperti terowongan merusak internet.

Urutan yang menghasilkan bukti

Jalankan pemeriksaan sisi klien lebih dulu, karena itu satu perintah dan menghilangkan separuh kemungkinan. Lalu pastikan apakah server memang dimaksudkan sebagai pintu keluar internet; gateway yang dibangun untuk akses privat tidak rusak ketika tujuan publik gagal.

Di server, pantau antarmuka saat Anda mengirim ping dari klien: tcpdump -ni wg0 icmp seharusnya menunjukkan permintaan, dan tcpdump -ni eth0 icmp seharusnya menunjukkan paket itu keluar, diterjemahkan atau tidak. Jika muncul di yang pertama dan tidak pernah di yang kedua, penghentiannya lokal di server. Jika keluar dan tidak ada balasan yang kembali, masalahnya di hulu, dan itu pembicaraan lain.

Terakhir, buat perbaikannya bertahan setelah restart. Penerusan masuk ke berkas sysctl, aturan firewall masuk ke layanan yang memuatnya, dan rute klien masuk ke konfigurasi yang menaikkan antarmuka, bukan ke shell yang akan Anda lupakan. Sambungkan ulang, ulangi dua uji yang sama, dan pastikan penghitungnya bergerak.