WireGuard baru berfungsi setelah server mengirim: pengetahuan titik akhir

Tunnel tampak berfungsi hanya setelah server mengirim sesuatu lebih dulu. Mulai dari klien dan tidak terjadi apa-apa, tunggu beberapa detik, coba lagi dan berhasil. Diagnosis yang biasa adalah NAT rusak, dan diagnosis yang biasa itu salah. Yang berubah adalah salah satu peer mengetahui di mana peer lain berada.

Pengetahuan titik akhir, bukan keterjangkauan

Peer WireGuard tidak akan memulai jabat tangan sampai ia tahu ke mana harus mengirimnya. Konfigurasi menyediakannya sebagai titik akhir berupa alamat dan port, dan status berjalan melacak titik akhir yang saat ini dipercayainya.

wg show mencetak kedua sisi gambaran itu, dan peer tanpa titik akhir di keluaran tidak dapat memulai apa pun, betapa pun benar kunci publik dan prefiks yang diizinkannya. Bandingkan pandangan klien dengan pandangan server sebelum mengubah aturan apa pun, karena keduanya sering tidak sepakat tentang siapa mengetahui apa.

Bagaimana peer mempelajari titik akhir

WireGuard sengaja dibuat senyap. Ketika paket yang terautentikasi dengan benar tiba dari alamat yang tidak diharapkan peer, implementasi memperbarui titik akhir peer itu ke sumber baru, dan begitulah perayapan bekerja pada laptop yang berpindah jaringan. Perilaku itu menjelaskan ketergantungan arah: jika server mengirim lebih dulu dan paketnya sampai ke klien, klien mempelajari alamat server saat ini dan dapat menjawab. Sampai saat itu ia tidak punya tempat untuk mengirim. Mekanismenya adalah perayapan terautentikasi dan bukan jalan pintas percaya pada penggunaan pertama, karena paket harus valid sebelum titik akhir berpindah.

Dokumentasi perkakas untuk wg menjelaskan pembaruan itu, dan layak dibaca sekali jika Anda akan merancang di sekitarnya.

Terjemahan stateful menambahkan arahnya sendiri

Ketika UDP melewati gateway yang menerjemahkan, gateway membuat status untuk paket pertama yang dilihatnya. RFC 4787 menjelaskan perilaku itu dan batas waktu yang akhirnya menghapus pemetaan. Pemetaan diam akan kedaluwarsa, dan paket masuk dari sisi jauh kemudian dibuang oleh gateway sebelum mencapai host. Tunnel yang berfungsi sepanjang pagi berhenti menjawab sore hari justru karena alasan ini.

Ini adalah mekanisme kedua dan mandiri yang menghasilkan gejala arah yang sama. Pengetahuan titik akhir dan status terjemahan keduanya harus benar, dan memperbaiki yang satu tidak memperbaiki yang lain.

Konfigurasikan arah yang sebenarnya Anda inginkan

Untuk klien yang harus memulai koneksi, letakkan titik akhir server di bagian peer klien dan biarkan di sana. Mengandalkan server mengirim lebih dulu berarti mengandalkan kebetulan dalam urutan lalu lintas yang akan berubah di jaringan yang tenang. Konfigurasi seharusnya menyatakan arah yang dimaksud, bukan menemukannya.

Untuk peer di balik terjemahan yang harus tetap terjangkau, aktifkan keepalive persisten di sisi itu. Keepalive setiap 25 detik adalah nilai awal yang biasa, dan tujuannya menahan pemetaan tetap terbuka, bukan menguji tunnel. Pilih satu sisi untuk membawanya, karena mengaktifkannya di kedua sisi menggandakan lalu lintas dan kebisingan log tanpa memperbaiki hasilnya.

Bandingkan status sebelum dan sesudah pemicu

Tangkap kedua pandangan pada saat gagal, lalu lagi setelah server mengirim. Perintah pertama menunjukkan titik akhir dan usia jabat tangan. Perintah kedua menunjukkan apakah ada entri terjemahan untuk port tersebut. Tangkapan itu menunjukkan arah mana yang benar-benar melintasi kabel, dan pemeriksaan rute memastikan klien tidak mengirim lalu lintas itu ke tempat lain sama sekali.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Catat kolom titik akhir dan entri terjemahan bersama-sama. Peer tanpa titik akhir dan gateway tanpa pemetaan adalah dua kesalahan berbeda. Hanya satu di antaranya diperbaiki oleh keepalive.