WireGuard di ruang nama jaringan: mengapa socket tertinggal

Antarmuka tercantum di ruang nama yang Anda inginkan, aplikasi terikat padanya, tetapi tidak ada lalu lintas terowongan yang muncul. Ini ciri perangkat WireGuard di kernel Linux yang dibuat di satu ruang nama lalu dipindahkan ke ruang lain: antarmukanya berpindah, socket UDP terenkripsinya tidak. Keduanya harus berada di tempat yang benar sebelum lalu lintas dalam menjadi penting. Pemeriksaannya cepat begitu Anda tahu harus melihat dua konteks, bukan satu.

Gejalanya: ruang nama benar, paket tidak ada

Di dalam ruang nama, terowongan tampak sehat. Perangkatnya ada, alamat sudah diberikan, dan konfigurasi peer tersedia. Di luar, pertukaran UDP yang diharapkan tidak pernah muncul pada antarmuka yang Anda pantau, dan sisi seberang melaporkan tidak ada jabat tangan.

Sebabnya adalah paket dalam aplikasi mencapai perangkat yang dipindahkan, dan perangkat mencoba mengirimnya melalui socket yang termasuk konteks jaringan lain. Rute dasar yang dipakainya, dan setiap aturan firewall yang berlaku padanya, adalah yang ada di ruang nama tempat perangkat dibuat.

Itu bukan bug pada pemindahan, dan bukan salah konfigurasi pada peer. Begitulah implementasi kernel bekerja, dan dokumentasi ruang nama untuk WireGuard menjelaskan aturan pembuatannya secara langsung.

Mengapa socket punya tempat lahir

Perangkat WireGuard memiliki satu socket UDP untuk transport terenkripsinya, dan socket itu dibuka di ruang nama tempat perangkat dibuat. Memindahkan antarmuka dengan perintah tautan memindahkan perangkat yang terlihat tetapi meninggalkan transport di tempat awalnya. Kedua objek itu lalu punya pemilik berbeda.

Konsekuensinya mudah terlewat karena kedua belahnya diperiksa di tempat berbeda. Rute dalam ditentukan di ruang nama tempat aplikasi berjalan, dan rute luar ditentukan di tempat socket berada. Memeriksa hanya salah satunya menghasilkan kesimpulan yang yakin tetapi salah. Memeriksa keduanya biasanya menuntaskan penyelidikan dalam satu lintasan.

Buatlah di tempat Anda menginginkan socket

Solusinya adalah membuat perangkat di dalam ruang nama tujuan, bukan membuatnya di luar lalu memindahkannya. Dengan asumsi ruang nama yang disetujui sudah ada dan namanya belum dipakai:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Kini antarmuka dan socketnya termasuk konteks itu, jadi rute dasar dan aturan penyaringan yang berlaku adalah yang dikonfigurasi di sana. Jika desain membutuhkan sisi terang di tempat lain, taruh dulu antarmuka dasarnya di ruang nama, lalu buat terowongannya. Urutan adalah bagian dari desain, bukan detail implementasi.

Perlakukan ini sebagai perintah administrasi jaringan, bukan resep. Perintah ini membuat perangkat dan menampilkan status; kunci, peer, alamat, dan rute tetap harus berasal dari konfigurasi yang disetujui, dan antarmuka produksi yang sudah ada tidak boleh pernah dipakai sebagai contoh.

Baca kedua sisi jalur

Setelah perangkat berada di tempat yang benar, verifikasi kedua keputusan secara terpisah. Mulailah dengan pencarian dalam dari konteks aplikasi, lalu periksa jalur luar dari konteks yang memiliki socket:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Jika pencarian dalam terselesaikan melalui terowongan dan rekaman luar menunjukkan pertukaran terenkripsi, kedua belahnya sepakat. Jika rekamannya kosong, socket masih di tempat lain, atau rute dasar di ruang namanya tidak mencapai titik akhir.

Satu pemeriksaan lagi termasuk dalam catatan: bagaimana perangkat dibuat setelah mulai ulang. Manajer yang membuat ulang antarmuka dengan konteks pembuatan berbeda mengubah tempat lahir socket. Pemindahan manual yang berhasil sekali bukan bukti tentang jalur yang dikelola.