Balasan Linux VPN menghilang? Periksa rp_filter dan rutenya

Permintaan meninggalkan mesin, peer VPN menjawab, dan balasannya tidak pernah mencapai soket. Terowongan aktif, log peer menunjukkan paket dikirim, dan tidak ada apa pun di aplikasi yang menjelaskan kesunyian itu. Di Linux salah satu tersangka biasa adalah penyaringan jalur balik: paket IPv4 yang masuk dapat ditolak ketika validasi sumber tidak sesuai dengan rute yang diharapkan kernel untuk sumber itu. Menelusurinya secara berurutan menunjukkan apakah itu penyebabnya atau kebetulan. Ini juga mencegah Anda mematikan kontrol keamanan untuk memperbaiki rute yang hilang.

Apa yang diputuskan validasi sumber

Kernel memeriksa apakah alamat sumber paket masuk akal untuk antarmuka tempat paket itu tiba, dengan menanyakan tabel perutean untuk rute kembali ke sumber tersebut. Jika rute balik menunjuk ke tempat lain, paket dapat dibuang sebelum aturan firewall atau soket aplikasi mana pun melihatnya. Pemeriksaan itu ada untuk mempersulit pola penyamaran tertentu, dan itulah sebabnya desain asimetris dan berperutean kebijakan menabraknya sementara setiap klien biasa di jaringan yang sama bekerja dengan baik. Klien biasa memiliki perutean simetris, yang persis seperti yang diasumsikan pemeriksaan itu.

Kata pentingnya adalah masuk akal. Paket bisa sepenuhnya sah dan tetap gagal dalam pemeriksaan, karena yang diuji bukanlah kesahihannya.

Baca mode efektifnya, bukan satu bidang

Ada tiga mode: nonaktif, ketat, dan longgar. Ketat memberlakukan harapan rute yang berbeda dari longgar, dan pengaturan global berinteraksi dengan pengaturan per antarmuka, sehingga membaca satu berkas bisa salah menggambarkan apa yang benar-benar berlaku. Baca keduanya, dan bacalah pada antarmuka yang menerima balasan, bukan pada antarmuka rute bawaan.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Pencarian rute di baris ketiga itu adalah bagian yang dilewati orang. Ini memberi tahu Anda apa yang diyakini kernel tentang sumber, dan itulah persis masukan bagi pemeriksaan.

Temukan ketidakcocokan sebelum mengubah pemeriksaan

Cari tahu mengapa balasan tiba di antarmuka itu dan apakah rute baliknya seharusnya berbeda. Aturan kebijakan yang mengirim permintaan lewat satu jalur sementara balasan kembali lewat jalur lain adalah desain yang sah, dan itulah juga desain yang ditolak validasi ketat. Tanda yang digunakan dalam perutean kebijakan juga dapat berpengaruh di sini, karena mengubah apa yang dikembalikan pencarian balik.

Jika rute balik sekadar hilang, menambahkannya memperbaiki penyebabnya alih-alih mematikan pemeriksaan. Rute yang hilang, penolakan firewall, dan pemilih lalu lintas yang salah semuanya menghasilkan gejala yang tampak sama, dan hanya satu di antaranya soal validasi sumber.

Jangan matikan pemeriksaan sumber secara global sebagai respons pertama. Itu menukar diagnosis yang spesifik dengan perubahan perilaku yang luas yang harus Anda ingat nanti.

Penyesuaian selektif yang bisa Anda pertahankan

Jika penyesuaian sempit benar-benar diperlukan, batasi pada antarmuka yang membutuhkannya, catat alasannya, dan letakkan dalam konfigurasi yang memiliki antarmuka itu agar bertahan setelah reboot. Lalu uji ulang alur yang tepat yang gagal, dari sumber yang sama ke tujuan yang sama, bukan ping ke sesuatu yang praktis.

Sertakan kasus yang seharusnya tetap ditolak. Jika kasus itu sekarang berhasil, penyesuaian melemahkan lebih dari satu jalur yang ingin Anda perbaiki.

Pisahkan IPv4 dan IPv6

sysctl yang tampak familier bukan kebijakan untuk setiap keluarga alamat. IPv6 punya perilaku dan pengaturannya sendiri, dan sebuah mesin bisa ketat pada satu keluarga dan permisif pada keluarga lain tanpa ada yang menyadarinya sampai tujuan tertentu gagal. Periksa keduanya jika beban kerja memakai keduanya.

Catat mode, antarmuka, keluaran pencarian rute, dan alasan perubahan di satu tempat. Orang berikutnya akan menemukan pengaturannya tanpa penjelasan apa pun, lalu menghapusnya atau menyalinnya ke tempat yang tidak semestinya.