Satu rakan WireGuard tidak dapat dicapai manakala yang lain berfungsi: senarai semak

Satu rakan WireGuard menyampaikan trafik dan yang kedua menyelesaikan jabat tangan tetapi tidak pernah mencapai apa-apa di sebalik terowong. Rakan yang berfungsi memberitahu anda bahawa antara muka, port UDP dan kunci pelayan mungkin baik. Ia tidak memberitahu apa-apa tentang AllowedIPs rakan kedua, alamat sumber dalamannya atau peraturan penghantaran di antaranya. Lalui senarai mengikut urutan dan berhenti pada langkah pertama yang syaratnya gagal.

Langkah 1: Tuliskan laluan yang sepatutnya dilalui paket

Dua klien pada hab yang sama tidak saling mencapai secara automatik. Dalam reka bentuk hab dan jejari, pelayan menerima paket pada wg0 dan mesti menghantarnya semula keluar dari wg0 kepada rakan lain, yang memerlukan penghantaran IP dan peraturan penghantaran. Dalam reka bentuk rakan-ke-rakan langsung, setiap pihak memerlukan titik akhir pihak lain dan alamat terowongnya di dalam AllowedIPs. Tentukan reka bentuk mana yang anda nyahpepijat sebelum membaca sebarang konfigurasi.

Laluan yang dijangka juga memberitahu anda di mana perlu dilihat. Jika paket perlu melintasi hab, hop yang gagal ialah sama ada AllowedIPs penghantar, penghantaran hab atau AllowedIPs penerima. Jika ia perlu pergi terus, hab tidak relevan dan medan titik akhir pada kedua-dua rakan yang penting.

Langkah 2: Bandingkan AllowedIPs pada kedua-dua belah, bukan hanya satu

WireGuard menggunakan AllowedIPs sebagai jadual penghalaan dan juga senarai akses. Semasa menghantar, alamat destinasi dicari dalam AllowedIPs rakan untuk memilih terowong; semasa menerima, alamat sumber dalaman mesti jatuh di dalam AllowedIPs rakan penghantar atau paket digugurkan. Julat yang hilang pada mana-mana pihak menghasilkan gejala yang sama: pengangkutan berfungsi, muatan hilang.

Baca keadaan hidup dan bukan fail, kerana muat semula mungkin gagal secara senyap: sudo wg show wg0 allowed-ips. Pada pelayan, entri rakan yang gagal mesti merangkumi alamat terowongnya, contohnya 10.90.0.3/32. Pada klien, entri rakan pelayan mesti merangkumi destinasi yang anda uji, sama ada alamat terowong hab atau subrangkaian jauh. Julat yang bertindih menjadikan carian tidak jelas dan boleh memilih rakan yang tidak anda maksudkan, jadi asingkan kedua-duanya.

Langkah 3: Periksa alamat sumber dalaman

Klien yang menghala 10.90.0.3 melalui wg0 tetapi menghantar paket dari alamat Wi-Fi-nya akan ditolak oleh penerima, kerana sumber tidak sepadan dengan AllowedIPs rakan. Sahkan apa yang sebenarnya dipilih oleh kernel dengan ip route get 10.90.0.3 from 10.90.0.2, dan sahkan alamat yang diberikan kepada antara muka terowong dengan ip -brief addr show wg0.

Pada hos Linux penerima, penapisan laluan songsang ialah pintu kedua. rp_filter yang ketat pada antara muka yang memiliki laluan balik boleh menggugurkan trafik terowong yang laluan baliknya tidak sepadan dengan antara muka tempat ia tiba. Periksa nilai berkesan sebelum menyahaktifkannya; dalam banyak topologi pembetulan yang betul ialah laluan, bukan penapis yang dilonggarkan.

Langkah 4: Semak penghantaran hab dan laluan balik

Jika hab mesti menghantar antara rakan, kernel memerlukan net.ipv4.ip_forward=1, dan tembok api mesti menerima aliran yang dihantar: masuk pada wg0, keluar pada wg0, dari alamat terowong penghantar ke alamat penerima. Kegagalan biasa ialah peraturan input yang menerima UDP 51820 tetapi tiada peraturan penghantaran], jadi jabat tangan berjaya dan muatan mati. Senaraikan peraturan berkesan dengan sudo nft list ruleset atau setara untuk pengurus tembok api anda.

Kemudian periksa balasan. Hos destinasi mesti mempunyai laluan balik kepada penghantar, sama ada melalui hab atau melalui getnya sendiri. Jika hab juga melakukan NAT pada subrangkaian terowong, sahkan bahawa terjemahan itu terpakai pada aliran yang dihantar dan balasan sampai ke hab sebelum keadaan tamat tempoh. Kegagalan sehala yang kelihatan seperti masalah kunci selalunya hanya laluan balik ini.

Akhir sekali, asingkan jabat tangan daripada data. Rakan yang menyelesaikan jabat tangan tetapi tersekat pada pemindahan besar biasanya mempunyai masalah MTU atau MSS pada laluan itu, bukan masalah AllowedIPs. Uji dengan ping kecil dahulu, kemudian dengan ping bersaiz penuh, dan bandingkan kedua-dua rakan.

Langkah 5: Ubah satu perkara dan kekalkan rakan yang berfungsi

Buat satu perubahan sahaja pada laluan yang gagal dan uji semula kedua-dua rakan. Menggantikan AllowedIPs setiap rakan dengan 0.0.0.0/0 ialah cara terpantas untuk merosakkan rakan yang sudah berfungsi, kerana ia mengubah keputusan penghalaan untuk semua trafik pada antara muka itu. Sunting entri itu sahaja, muat semula dan baca semula keadaan hidup.

Catat laluan mana yang berjaya, mana yang gagal, dan output arahan yang tepat bagi setiap satu. Perbandingan itu lebih bernilai daripada laporan umum bahawa VPN rosak, dan itulah perkara pertama yang akan ditanya oleh orang seterusnya.