Balasan keluar lewat LAN, bukan terowongan: mengapa dan bagaimana

Layanan yang diterbitkan melalui gateway berfungsi dari sebagian besar internet dan gagal dari satu kantor. Seseorang memeriksa terowongan, melihat permintaan datang, dan menyimpulkan bahwa balasan harus menempuh jalur yang sama kembali. Linux tidak bekerja seperti itu, dan sebanyak apa pun pemeriksaan terowongan tidak akan mengubah jawabannya. Balasan dirutekan berdasarkan tujuan, dan satu pemanggil yang gagal itu berada di subnet yang sudah dijangkau host secara langsung.

Apa yang sebenarnya menentukan paket keluar

Kernel mencari rute untuk tujuan paket, meninjau aturan kebijakan dalam urutan prioritas lalu tabel yang dipilih oleh aturan yang cocok. Antarmuka tempat paket tiba tidak berperan, kecuali ada aturan atau tanda yang ditulis agar hal itu penting. Ini fakta perutean host ini, bukan kesalahan pada terowongan.

Permintaan yang diterima lewat terowongan karena itu dapat menghasilkan balasan yang keluar melalui antarmuka fisik, dan alirannya menjadi satu arah tanpa perangkat apa pun melaporkan kesalahan. Periksa kedua arah sebelum menarik kesimpulan tentang terowongan. Balasan yang keluar ke arah yang salah hilang dari penghitung terowongan, itulah sebabnya kedua ujung tidak sepakat apakah ada yang dikirim. Perhatikan penghitung mana yang bergerak sebelum menyentuh aturan.

Mengapa subnet lokal menang

Host yang memiliki alamat di jaringan lokal menyimpan rute terhubung untuk prefiks itu di tabel utama, dan rute terhubung adalah kecocokan langsung. Ketika pemanggil datang dari subnet yang sama, pencarian menemukan tautan lokal sebelum terowongan dipertimbangkan.

Asimetri inilah yang membuat diagnosis membingungkan. Pemanggil dari internet yang lebih luas berfungsi karena tidak cocok dengan rute lokal mana pun, sedangkan satu pemanggil yang berbagi prefiks kantor justru gagal, dan justru pemanggil itulah yang dipakai seseorang untuk menguji.

Cakupan peer tidak sama dengan rute terpasang

Di sisi terowongan, rentang yang diizinkan milik peer menjelaskan apa yang boleh dikirim ke terowongan dan sumber mana yang diterima darinya. Semua itu tidak mengatakan apa pun tentang ke mana tabel perutean lokal akan mengirim paket.

Jika alat terowongan memasang rute default pada host, ia dapat menyeret lalu lintas yang tidak terkait ke dalam terowongan sebagai kerusakan sampingan. Di tempat aturan kebijakan seharusnya memegang keputusan, opsi pemasangan rute milik alat itu ada justru untuk mencegahnya, dan alamat, kunci, serta pengaturan endpoint tetap persis seperti semula. Rute default yang ditambahkan demi kenyamanan adalah cara umum bagi host kehilangan jaringan lokalnya sendiri.

Pilih tabel berdasarkan alamat sumber

Aturan berbasis sumber mengirim balasan dari alamat layanan ke tabel privat yang nilai default-nya adalah terowongan, sementara segala hal lain tetap memakai tabel utama. Pilih nomor tabel dan prioritas yang tidak dipakai secara lokal, dan baca aturan yang ada sebelum menyisipkan apa pun. Baca aturan yang aktif, bukan berkas tersimpan, karena keduanya dapat berbeda setelah reboot.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Baris terakhir membuat rute yang hilang gagal secara terlihat alih-alih jatuh kembali ke tautan lokal. Sumber harus benar-benar ditetapkan ke host, dan pencarian lokal serta utama yang biasa harus tetap pada posisi semula. Aturan memilih tabel berdasarkan sumber; ia tidak membandingkan panjang prefiks antartabel.

Pastikan jalurnya, lalu layanannya

Tanyakan kepada kernel apa yang akan dilakukannya alih-alih menyimpulkan dari tangkapan, dengan alamat layanan sebagai pemilih sumber. Jawaban yang salah di sini menghemat seluruh pelacakan paket.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Keluarannya seharusnya menyebut terowongan. Lalu uji sumber yang tidak Anda sentuh dan pastikan sumber itu masih memakai tautan lokal, sehingga perubahan tetap terbatas pada satu alamat. Pemilih yang lebih luas tidak akan membuktikan apa pun tentang keluhan semula.

Apa yang tidak diperbaiki ini

Biarkan penerusan, aturan firewall, dan perilaku ICMPv6 pada gateway seperti semula, karena rute sumber tidak menggantikan satu pun dari itu. Pesan Packet Too Big yang hilang tetap merusak balasan besar, tabel mana pun yang menang dalam pencarian. Perbaiki itu sebelum menambahkan aturan perutean, atau gejalanya akan bertahan setelah perubahan.

Pastikan model publikasi sebelum menerapkan semua ini. Proxy terbalik yang membuka koneksi backend-nya sendiri menampilkan sumbernya sendiri dan tidak mempertahankan pemanggil, jadi kerusakan ini tidak mungkin terjadi pada desain tersebut. Menerapkan aturan di sana akan menambahkan pengecualian perutean yang tidak menyelesaikan apa pun dan menyembunyikan penyebab sebenarnya.

Terakhir, tulis nomor aturan dan tabelnya ke manajemen konfigurasi host. Aturan kebijakan yang ditambahkan dengan tangan hilang pada pembangunan ulang berikutnya, dan pemanggil kantor kembali dengan keluhan yang sama.