Menaruh 0.0.0.0/0, ::/0 di AllowedIPs sebuah peer adalah langkah yang semua orang ingat, dan itu hanya menentukan lalu lintas mana yang boleh dibawa peer. Prefiks itu tidak membuat rute, tidak meneruskan apa pun di sisi jauh, dan membiarkan resolver setiap aplikasi tepat di tempatnya semula. Empat hal terpisah harus berlaku bersamaan agar tunnel penuh benar-benar penuh, dan sebaiknya diperiksa dalam urutan di bawah ini, karena pemeriksaan belakangan tidak bisa menyelamatkan yang lebih awal. Setiap pemeriksaan di bawah ini adalah fakta yang bisa dibaca dari mesin, bukan pengaturan yang Anda harap sudah diterapkan.

Apa yang dipilih prefiks peer, dan apa yang tidak

AllowedIPs adalah pemilih sekaligus pemberi izin. Ia memberi tahu sisi lokal tujuan mana yang boleh dikirim ke peer ini, dan memberi tahu sisi penerima alamat sumber mana yang boleh ditampilkan peer ini. Itulah seluruh tugasnya. Tidak ada dalam deskripsi itu yang membuat rute di host, mengaktifkan penerusan di sisi jauh, atau menyentuh resolusi nama.

Itulah sebabnya konfigurasi bisa tampak lengkap dan berperilaku seperti tunnel terpisah. Prefiks mengatakan peer akan menerima semua; tabel rute host yang menentukan apa yang benar-benar sampai di sana, dan gateway yang menentukan apakah ada yang keluar. Tak satu pun dari ketiga keputusan itu tinggal di bagian peer.

Merutekan klien, bukan hanya daftar peer

Manajer seperti wg-quick memprogram tabel rute host untuk Anda, itulah sebabnya dua berkas konfigurasi yang identik berperilaku berbeda tergantung bagaimana antarmuka naik. Profil minimal cukup pendek untuk dibaca sekali duduk:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Dua detail yang memikul pekerjaan. Kolom Address adalah satu prefiks host, bukan subnet yang dikira dimiliki klien, dan manajerlah yang mengubah AllowedIPs bawaan menjadi rute bawaan sungguhan. Naikkan berkas yang sama dengan ip link dan wg setconf dan tidak ada rute yang muncul sama sekali, yang terlihat seperti tunnel rusak padahal tunnel sehat dengan langkah perutean yang dilewati. Manual wg-quick mendokumentasikan perutean dan Table perilaku yang ditambahkan manajer tersebut.

Baca hasilnya, bukan berkasnya: ip route get 1.1.1.1 seharusnya menyebut antarmuka tunnel, dan wg show seharusnya melaporkan handshake terbaru dengan penghitung transfer yang bergerak. Handshake tanpa rute berarti manajer tidak pernah berjalan, dan menyunting profil lagi tidak akan memperbaikinya. Jalankan antarmuka seperti pengguna akan menjalankannya, atau pengujian mengukur shell Anda alih-alih penerapan.

Menjaga endpoint di luar tunnel

Tunnel penuh menangkap setiap tujuan, termasuk tujuan yang harus diajak bicara agar bisa ada. Manajer menanganinya dengan menambahkan rute host untuk endpoint melalui gateway asli, itulah sebabnya konfigurasi yang benar hampir selalu berisi satu pengecualian yang disengaja. Menerapkan separuh konfigurasi dengan manajer dan separuh lainnya secara manual adalah cara biasa pengecualian ini hilang.

Jika endpoint adalah nama host yang mengarah ke beberapa alamat, atau ke keluarga yang tidak Anda bawa, pengecualian itu menua dengan buruk dan tunnel bisa gagal setelah sambung ulang yang tampak rutin. Patok endpoint ke alamat yang Anda kendalikan, atau pastikan manajer menilainya ulang, dan baca ulang rute host setelah setiap perubahan jaringan.

Mekanisme yang sama menjelaskan mengapa tunnel penuh dan portal captive bertengkar. Portal mengharapkan mencegat lalu lintas yang kini ditangkap tunnel Anda, jadi di jaringan hotel dan bandara Anda menaikkan tunnel setelah login portal, tidak pernah sebelumnya.

Penerusan dan jalur balik di gateway

Di gateway, aktifkan penerusan untuk keluarga yang Anda bawa, izinkan rantai forward di kedua arah saat Anda menerjemahkan, dan pastikan jalur balik dengan pencarian khusus sumber. Tidak satu pun dari itu berasal dari handshake yang berhasil, karena handshake hanya membuktikan kedua peer dapat bertukar UDP. Ia tidak mengatakan apa pun tentang apa yang terjadi pada paket yang didekapsulasi setelahnya.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Pencarian berjalan di gateway, bukan di klien, atau Anda akan membaca tabel rute lain. Jika ia menyebut antarmuka yang salah, atau melaporkan tidak ada rute, maka tidak ada perubahan di sisi klien yang akan menghasilkan jalan keluar internet. Saat gateway menerjemahkan alamat klien di jalan keluar, balasannya bergantung pada status penerjemahan itu, jadi aturannya harus ada untuk kedua arah aliran dan bukan hanya arah keluar.

DNS dan keadaan gagal, diuji terpisah

Protokolnya sendiri tidak mengonfigurasi resolver aplikasi mana pun. wg-quick menerapkan baris DNS melalui integrasi resolver distribusi, kontainer dan peramban dengan tumpukan sendiri bisa mengabaikannya, dan karena itu nama bisa gagal sementara tunnel membawa paket dengan sempurna. Uji dengan nama host alih-alih alamat, dan catat server mana yang menjawab alih-alih menganggap server di profil yang menjawab.

Keluarga alamat adalah uji terpisah dengan jawaban terpisah. Rute bawaan v4 tidak mengatakan apa pun tentang apa yang akan dilakukan koneksi v6 sebuah aplikasi, dan tunnel yang diam-diam membocorkan keluarga kedua lebih buruk daripada yang gagal dengan lantang. Tanyakan nama melalui setiap keluarga, baca antarmuka yang dipakai setiap permintaan, dan periksa penghitung penerjemahan sebelum dan sesudah, karena aturan yang tidak cocok dengan apa pun terlihat identik dengan aturan yang hilang.

Terakhir, uji keadaan yang Anda inginkan saat tunnel berhenti. Tunnel penuh harus gagal tertutup untuk lalu lintas yang diklaimnya: jika antarmuka turun dan aplikasi diam-diam berlanjut melalui tautan fisik, desainnya adalah tunnel terpisah dengan langkah tambahan. Tuliskan perilaku kegagalan yang dimaksud, periksa dengan sengaja, dan akhiri dengan mencatat empat jawaban — manajer mana yang menaikkan antarmuka, rute mana yang membawa bawaan, siapa yang meneruskan dan menerjemahkan di gateway, dan resolver mana yang menjawab.

Artikel terkait