Prefiks host WireGuard: mengapa satu alamat berfungsi dan sisanya tidak

Tunnel menyala, handshake terjadi setiap dua menit, dan tepat satu alamat di sisi lain menjawab. Ping ke alamat tunnel peer berhasil; apa pun di belakangnya tidak. Seseorang membaca konfigurasi antarmuka, melihat prefiks host, dan menyimpulkan bahwa masknya salah. Memperlebarnya menjadi /24 memperbaiki ping untuk sementara lalu merusak hal lain. Prefiksnya tidak pernah menjadi penyebabnya, dan rute yang hilang bukan rute yang dikendalikan mask.

Apa yang sebenarnya dibuat prefiks antarmuka

Di Linux, menetapkan alamat ke antarmuka membuat rute terhubung untuk prefiks itu. Tetapkan prefiks host dan rute terhubung mencakup satu alamat. Tetapkan /24 dan rute itu mencakup 256, yang masing-masing kini dianggap dapat dijangkau melalui tautan tersebut.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Prefiks host adalah pilihan yang sepenuhnya normal untuk tunnel titik-ke-titik, karena ada tepat satu peer di ujung lainnya. Perintah ketiga adalah yang menjawab pertanyaan pengguna: ia menyebut antarmuka mana yang akan dipakai kernel untuk tujuan itu, dan tidak akan menampilkan apa pun yang berguna jika tidak ada rute yang cocok.

Itulah seluruh penjelasan gejalanya. Satu alamat menjawab karena ada rute terhubung untuknya, atau karena daftar yang diizinkan peer kebetulan memuatnya. Semua yang lain tidak punya rute dan dibuang sebelum WireGuard terlibat. Tunnel tetap sehat sepanjang waktu, itulah sebabnya penghitung handshake terus terlihat meyakinkan.

AllowedIPs adalah dua aturan dengan satu nama

Daftar yang diizinkan per peer di WireGuard melakukan dua pekerjaan sekaligus, dan sintaks konfigurasi membuat keduanya tampak satu. Pada arah masuk, ia mengizinkan alamat sumber mana yang boleh disajikan peer. Pada arah keluar, ia memilih ke peer mana sebuah paket dikirim, dengan menemukan kecocokan paling spesifik.

Tidak satu pun dari kedua pekerjaan itu adalah perutean. Kernel tetap harus memutuskan bahwa sebuah paket termasuk antarmuka tunnel sebelum WireGuard melihatnya, dan keputusan itu berasal dari tabel rute. Entri peer dengan daftar yang diizinkan lebar tidak memasang rute dengan sendirinya.

Itulah sebabnya konfigurasi bisa tampak lengkap dan berperilaku asimetris. Klien mengirim ke sisi jauh karena ada rute, dan balasan tidak pernah datang karena daftar yang diizinkan di sisi jauh tidak mengizinkan sumber klien, atau karena sisi jauh tidak punya jalur balik. Kedua arah adalah keputusan terpisah dengan mode kegagalan terpisah. Mencatat mana yang sedang Anda uji adalah separuh diagnosis.

Dari mana rute itu berasal

Jika Anda memakai wg-quick, rute dibuat untuk Anda dari daftar yang diizinkan setiap peer, kecuali Anda menetapkan Table = off dan mengambil alih kendali sendiri. Itulah perilaku yang didokumentasikan alat ini, dan itulah sebabnya konfigurasi tanpa direktif rute eksplisit tetap berfungsi.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Bandingkan daftar yang diizinkan dengan rute yang benar-benar ada. Peer yang mengizinkan seluruh subnet tetapi hanya menghasilkan rute host berarti helper tidak pernah berjalan, atau Anda mengelola antarmuka secara langsung dengan wg dan ip, dan dalam hal itu tidak ada yang membuatkan rute untuk Anda.

Ketika Anda mengelolanya dengan tangan, rutenya satu baris dan bentuknya eksplisit: tujuan melalui antarmuka, tanpa gateway karena tautannya titik-ke-titik. Menambahkannya bukan akal-akalan untuk prefiks yang buruk; itu separuh yang hilang dari rancangan yang memilih menangani perutean sendiri.

Prefiks yang lebih lebar tidak menambahkan entri peer

Perbaikan yang menggoda adalah mengubah alamat menjadi /24 agar rute terhubung mencakup LAN server. Tampaknya berhasil, dan alasan tampaknya berhasil adalah rute terhubung kini cocok, bukan karena WireGuard mempelajari sesuatu yang baru.

Yang juga Anda lakukan adalah mengklaim seluruh rentang sebagai dapat dijangkau langsung melalui tautan itu, termasuk alamat milik peer lain atau LAN yang sebenarnya berada di belakang server. Lalu lintas ke alamat tersebut kini masuk ke tunnel, dan apakah keluar di sisi lain bergantung pada perutean dan daftar yang diizinkan server itu sendiri.

Sisi kriptografi tidak terpengaruh dalam hal apa pun. WireGuard masih membutuhkan entri daftar yang diizinkan yang mencakup tujuan untuk memilih peer, dan sisi jauh masih membutuhkan entri yang mencakup sumber Anda untuk menerimanya. Prefiks antarmuka yang lebih lebar tidak dapat menyediakan keduanya.

Konfirmasikan kedua arah sebelum mengubah apa pun

Kerjakan kedua ujung secara terpisah dan catat apa yang dikatakan masing-masing. Di klien rute dan entri peer; di server bayangan cermin ditambah jalur baliknya sendiri:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Tangkapan adalah yang menyelesaikan perselisihan tentang arah. Jika paket keluar muncul di antarmuka tunnel dan server tidak mencatat apa pun, ujung jauh menolaknya, biasanya karena sumber Anda di luar daftar yang diizinkan. Jika sama sekali tidak ada yang muncul, rutenya hilang atau mengarah ke tempat lain.

Lalu perbaiki ujung yang paling sempit. Entri daftar yang diizinkan di sisi server untuk alamat klien Anda dan entri di sisi klien untuk subnet tujuan adalah bentuk yang normal, dan itu membiarkan prefiks antarmuka tidak tersentuh. Perlebar prefiks hanya jika rencana alamat benar-benar menginginkan subnet bersama pada tautan itu, dan lakukan sebagai perubahan rencana, bukan sebagai langkah debugging.