WireGuard berfungsi di data seluler tetapi tidak di wifi yang sama

Tunnel menyala di data seluler lalu tertahan di menghubungkan saat di rumah, dengan profil yang sama, kunci peer yang sama, dan tanpa perubahan konfigurasi di antaranya. Bedanya ada pada perjalanan: permintaan dari dalam LAN ke alamat publik router bukan perjalanan yang sama dengan permintaan yang datang dari internet. Sebagian besar gateway rumah entah tidak menerapkan jalur balik atau hanya menerapkannya untuk protokol tertentu. Itu membuat gejalanya tampak seperti kunci rusak padahal tidak ada yang berubah pada kuncinya. Tentukan jalur mana yang gagal sebelum menyentuh kunci, penerusan port, atau profil klien.

Satu alamat, dua jalur berbeda

Dari luar, paket mencapai alamat publik router dan aturan penerusan port menyerahkannya ke listener WireGuard di host internal. Dari dalam, klien memanggil alamat publik yang sama, sehingga paket meninggalkan klien, tiba di router, dan harus diputar balik ke arah LAN. Di titik pemutaran balik itulah kedua jalur bercabang, karena router harus menerjemahkan aliran yang keluar dan masuk lagi melalui antarmuka yang sama. Banyak implementasi membuangnya alih-alih menerjemahkannya, dan klien lalu menunggu jabat tangan yang tidak pernah dikirim.

Perilaku ini biasanya disebut NAT loopback atau hairpinning, dan itu milik router, bukan WireGuard; RFC 4787 memaparkan kasus penerjemahan yang mungkin atau tidak mungkin didukung gateway. WireGuard sendiri tidak berpendapat soal jalur, karena ia hanya melihat paket yang mencapai antarmukanya. Saat router membuang aliran itu, daemon tidak pernah menerima apa pun, klien melaporkan batas waktu jabat tangan, dan log server tetap kosong. Log kosong karena itu adalah petunjuk di mana paket berhenti, bukan bukti bahwa server mati. Itu juga sebabnya memasang ulang tidak mengubah apa pun.

Kebalikannya juga penting: log server yang menunjukkan upaya jabat tangan dari alamat LAN membuktikan paket sudah tiba dan jalurnya baik, yang memindahkan penyelidikan ke kunci dan alamat yang diizinkan. Bacalah log untuk apa yang dibuktikannya, bukan untuk apa yang Anda harap terlihat.

Reproduksi dulu sebelum mengubah apa pun

Ujilah dari jaringan eksternal yang diizinkan dengan perangkat yang sama dan profil yang sama, lalu ulangi uji itu di dalam LAN tanpa menyunting apa pun. Jabat tangan yang selesai di luar dan klien yang di dalam tidak pernah meninggalkan perangkat mereproduksi kondisi itu alih-alih menebaknya. Kedua percobaan harus memakai profil yang sama, atau perbandingannya tidak membuktikan apa pun.

Lalu lihat ke mana nama endpoint diselesaikan untuk perangkat ini. Tiga perintah berikut juga menunjukkan alamat mana yang sebenarnya dipanggil klien:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Perintah pertama melaporkan endpoint yang sedang dipakai antarmuka saat ini, dan dua lainnya menunjukkan ke mana nama itu diselesaikan di mesin ini. Klien yang memanggil alamat publik saat berada di jaringan yang sama dengan server sedang memakai jalur hairpin. Klien yang memanggil alamat LAN tidak melakukannya, dan kegagalan di sana termasuk penyelidikan lain. Perbedaan itulah yang menentukan apakah bagian berikutnya berlaku sama sekali.

Cara yang didukung untuk mencapai server terdekat

Susunan terbersih adalah jawaban split-horizon: nama publik diselesaikan ke alamat publik untuk internet dan ke alamat LAN server untuk klien di dalam. Profil menyimpan satu nama endpoint dan resolver memilih jalurnya. Itu memerlukan kendali atas jawaban DNS internal, yang biasanya ditawarkan router rumah dan dapat diatur sengaja oleh organisasi. Tanpa kendali itu, pilihan yang tersisa adalah fitur router atau profil kedua.

Fitur router itu adalah refleksi: gateway menerjemahkan aliran dari dalam ke luar dan mengirimnya kembali ke dalam. Di tempat yang berfungsi, tidak perlu perubahan klien, dan di tempat yang tidak berfungsi, tidak ada pengaturan klien yang menyelamatkannya. Ujilah dengan mengamati log server selama percobaan internal alih-alih membaca daftar fitur router.

Mengubah profil ke alamat privat adalah diagnosis, bukan desain. Itu membuktikan server menjawab di LAN, dan itu merusak profil yang sama begitu laptop meninggalkan rumah.

Jaga profil tetap berguna di luar rumah

Jalur mana pun yang Anda pilih, biarkan pemeriksaan identitas. Alamat endpoint bukan identitas peer, dan perubahan alamat tidak pernah membenarkan menerima kunci publik asing yang kebetulan menjawab. WireGuard mengautentikasi lewat kunci, jadi host yang salah gagal pada jabat tangan alih-alih memberi akses ke sesuatu yang tak terduga.

Jika alamat publik berpindah, DNS dinamislah yang menjaga nama tetap berguna, dan perilaku penyegaran klien menentukan seberapa cepat perubahan itu tiba. Ujilah dari luar setelah perubahan alamat, karena kasus LAN tidak dapat memvalidasinya. Waspadai resolver yang menyimpan jawaban lama melewati masa hidup record. Nama yang masih menunjuk ke alamat sebelumnya tampak persis seperti server yang mati.

Catat nama mana yang dipakai profil dan ke mana ia diselesaikan di tiap sisi batas. Profil yang bergantung pada fitur router yang tidak dicatat siapa pun adalah panggilan dukungan yang menunggu pembaruan firmware berikutnya. Catatan itu juga yang memberi tahu orang berikutnya apakah kegagalan internal adalah kasus hairpin yang dikenal atau sesuatu yang baru.