Handshake WireGuard berfungsi tetapi tiada internet: jejak paket

Terowong berfungsi, wg show melaporkan handshake baru-baru ini, anda boleh ping alamat terowong pelayan, dan tiada apa-apa di sebaliknya menjawab. Naluri pertama ialah menjana semula kunci atau berkongsi semula konfigurasi. Itu mengubah bahagian laluan yang sudah terbukti berfungsi.

Handshake yang selesai mengatakan kedua-dua pihak bersetuju tentang kunci, UDP sampai ke titik akhir, dan perutean kripto menerima paket itu. Ia tidak mengatakan apa-apa tentang sama ada paket itu boleh meninggalkan pelayan selepas itu.

Jadi jejak satu paket daripada meneka. Terdapat empat tempat ia boleh mati, dan setiap satu meninggalkan kesan yang berbeza.

Apa yang sebenarnya dibuktikan oleh handshake

WireGuard ialah protokol UDP yang menubuhkan sesi dengan handshake Noise dan kemudian menyulitkan paket untuk rakan. Apabila wg show menyenaraikan handshake berusia beberapa saat dan pembilang pemindahan yang meningkat, titik akhir, kunci dan kunci awam rakan semuanya betul.

Apa yang tidak dibuktikannya ialah klien anda menghantar trafik menuju internet ke antara muka, pelayan bersedia menghantarnya, atau balasan dapat menemui jalan balik. Itu keputusan perutean kernel dan firewall, dan ia dibuat di luar terowong.

Sebab itulah ping ke alamat terowong pelayan ialah ujian yang begitu mengelirukan. Paket itu dituju kepada pelayan itu sendiri, jadi ia berakhir secara setempat. Ia tidak pernah memerlukan penghantaran, tidak pernah memerlukan terjemahan, dan tidak pernah memerlukan laluan balik dari internet.

AllowedIPs ialah keputusan perutean

Pada klien, AllowedIPs melakukan dua tugas. Ia ialah jadual perutean kunci kripto yang menentukan alamat destinasi mana yang dihantar ke dalam terowong rakan ini, dan ia ialah senarai alamat sumber yang akan diterima rakan daripada anda. Jika konfigurasi klien hanya menyenaraikan 10.8.0.0/24, destinasi awam tidak pernah masuk ke antara muka dan laluan lalai biasa anda membawanya ke luar terowong. Kemudian terowong berfungsi dengan sempurna dan tidak melakukan apa-apa yang anda mahukan.

Lihat apa yang sebenarnya dipasang oleh klien, bukan apa yang dikatakan fail konfigurasi:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Perintah kedua yang menentukan. Jika jawapan menyebut antara muka fizikal anda dan gateway biasa, paket itu tidak diterowongkan dan tiada perubahan di pihak pelayan akan membaikinya. Tambah 0.0.0.0/0 untuk IPv4 dan ::/0 untuk IPv6 secara berasingan; peraturan yang menangkap segala-galanya untuk satu keluarga meninggalkan yang lain pada laluan asalnya, dan itu punca biasa terowong IPv4 yang berfungsi dan carian IPv6 yang tersekat.

Di mana paket mati di gateway

Jika laluan betul dan paket masih tidak ke mana-mana, ia sampai ke pelayan dan berhenti di situ. Empat semakan meliputi kebanyakan gateway.

Penghantaran. sysctl net.ipv4.ip_forward yang mengembalikan 0 ialah jawapan klasik, dan banyak pengedaran masih lalai pada 0. Ia mesti 1, dan ditetapkan secara kekal dalam fail sysctl dan bukan dengan perintah yang hilang semasa but semula. Penghantaran IPv6 ialah suis berasingan.

Dasar penapisan. Rantaian FORWARD dengan dasar drop lalai akan membuang trafik terowong sambil membenarkan trafik ke hos itu sendiri, yang sepadan tepat dengan gejala. Baca set peraturan yang hidup, bukan fail yang disimpan: nft list ruleset atau iptables -S.

Terjemahan atau perutean. Klien dengan alamat terowong peribadi memerlukan sama ada NAT sumber pada antara muka keluar pelayan, atau awalan berute yang diketahui oleh rangkaian di atas cara memulangkannya. Pilihan antara keduanya mengikut pelan alamat. Menambah MASQUERADE pada rangkaian yang sudah merutekan awalan anda balik adalah tidak berbahaya tetapi sia-sia, dan meninggalkannya di tempat tiada laluan membiarkan balasan dialamatkan ke julat peribadi yang tidak boleh dihalakan.

Laluan balik. Dalam reka bentuk berute, penghala di atas memerlukan laluan yang menunjuk ke pelayan anda. Rangkaian penyedia juga boleh menyekatnya: beberapa awan mengaktifkan semakan sumber dan destinasi pada instans, yang membuang secara senyap paket yang sumbernya bukan alamat instans itu sendiri sehingga semakan itu dimatikan.

DNS gagal secara berbeza daripada perutean

Paket ke alamat yang diketahui dan carian nama ialah dua kegagalan berasingan, dan mesej ralat mengelirukan ke arah bertentangan. Jika ping 1.1.1.1 berfungsi dan pelayar tidak dapat memuatkan apa-apa, laluan itu betul dan penyelesaian nama tidak. Jika ping itu sendiri gagal, DNS tidak relevan dan anda kembali ke bahagian sebelumnya.

wg-quick boleh menetapkan penyelesai daripada baris DNS = dalam konfigurasi, dan systemd-resolved mempunyai tingkah laku sendiri bagi setiap pautan. VPN yang menimpa penyelesai dengan alamat yang hanya boleh dicapai di dalam terowong akan menggagalkan setiap carian pada saat terowong jatuh, yang kelihatan seperti terowong merosakkan internet.

Urutan yang menghasilkan bukti

Jalankan semakan di pihak klien dahulu, kerana ia satu perintah dan menghapuskan separuh kemungkinan. Kemudian sahkan sama ada pelayan itu memang dimaksudkan sebagai pintu keluar internet; gateway yang dibina untuk akses peribadi tidak rosak apabila destinasi awam gagal.

Di pelayan, perhatikan antara muka semasa anda menghantar ping dari klien: tcpdump -ni wg0 icmp sepatutnya menunjukkan permintaan itu, dan tcpdump -ni eth0 icmp sepatutnya menunjukkan ia keluar, diterjemah atau tidak. Jika ia muncul pada yang pertama dan tidak pernah pada yang kedua, perhentian itu setempat pada pelayan. Jika ia keluar dan tiada balasan kembali, masalahnya di hulu, dan itu perbualan lain.

Akhirnya pastikan pembetulan itu bertahan selepas but semula. Penghantaran tergolong dalam fail sysctl, peraturan firewall tergolong dalam perkhidmatan yang memuatkannya, dan laluan klien tergolong dalam konfigurasi yang menaikkan antara muka dan bukannya dalam shell yang akan anda lupakan. Sambung semula, ulangi dua ujian yang sama, dan sahkan pembilang bergerak.