Mengapa net.ipv4.conf.default.forwarding membiarkan tun0 apa adanya

Anda menyetel net.ipv4.conf.default.forwarding=1, menyalakan ulang VPN, dan tunnel tetap membuang paket yang seharusnya dirutekan gateway. Setelannya terlihat benar di berkas, dan antarmuka masih melaporkan penerusan dimatikan. Tidak ada yang rusak: Anda mengubah nilai yang diwarisi antarmuka mendatang, bukan nilai yang dipakai tunnel aktif.

Telusuri ini di host yang memiliki tunnel, di namespace jaringan tempat tunnel benar-benar ada. Container atau namespace jaringan bisa memegang antarmuka sementara host menampilkan angka lain.

Baca ketiga nilai bersama-sama

Mulailah dengan membandingkan sakelar seluruh gateway, templat untuk antarmuka baru, dan antarmuka yang Anda pedulikan. Ganti tun0 dengan antarmuka masuk yang sebenarnya, dan baca juga antarmuka balik, karena penerusan dievaluasi pada titik tempat paket tiba.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Hasil yang umum adalah ip_forward = 0, default.forwarding = 1 dan tun0.forwarding = 0. Dua yang pertama tidak sepakat soal peran host, dan yang ketiga menunjukkan apa yang sebenarnya dilakukan antarmuka. Kombinasi itu konsisten dengan host yang tidak pernah dikonfigurasi sebagai router, hanya diberi nilai templat. Ketiga angka itu tidak saling bertentangan; mereka menjawab tiga pertanyaan berbeda. Menulis nilai templat juga tidak menentukan peran host.

Mengapa sakelar global yang bergerak

net.ipv4.ip_forward adalah kendali seluruh gateway. Mengubahnya memperbarui setelan penerusan per antarmuka sebagai bagian dari operasi yang sama, karena itu satu penulisan bisa membuat tunnel yang sudah ada mulai meneruskan. default.forwarding hanya menyemai antarmuka yang diinisialisasi sesudahnya, jadi tunnel yang sudah ada mempertahankan nilai saat ia lahir.

Dokumentasi kernel menandai ip_forward sebagai istimewa karena alasan terkait: mengubahnya mengatur ulang sejumlah parameter IPv4 lain ke nilai bawaan host atau router. Itu menjadikannya alat tumpul. Menyetelnya sekali sebagai bagian dari penetapan peran gateway tidak masalah; mengganti-gantinya berulang kali sebagai trik penggeledahan bisa diam-diam menulis ulang konfigurasi yang Anda butuhkan waktu untuk membenahinya.

Nilai per antarmuka juga ada alasannya. Gateway yang dikelola dengan sengaja bisa membiarkan penerusan mati pada antarmuka yang tidak boleh pernah merutekan, bahkan saat host meneruskan di tempat lain. Karena itu membaca antarmuka aktif itu penting dan karena itu nilai global saja bukan jawaban utuh. Bacalah pengecualian semacam itu sebagai keputusan yang disengaja, dan catat mengapa antarmuka itu berbeda. Kalau tidak, insinyur berikutnya akan dengan senang hati "memperbaikinya".

Jadikan setelan itu permanen di tempat yang benar

Satu sysctl -w yang berhasil membuktikan kernel menerima nilai itu. Itu tidak bertahan setelah reboot, dan tidak bertahan terhadap manajer jaringan yang menerapkan lagi gagasannya sendiri tentang konfigurasi antarmuka saat menyambung ulang. Taruh peran gateway di berkas konfigurasi sysctl atau di manajer jaringan yang memiliki host, lalu nyalakan ulang layanan yang menerapkannya.

Urutan penting pada tunnel. Jika manajer membuat antarmuka saat boot dan menerapkan penerusan sesudahnya, antarmuka bisa mewarisi bawaan lama. Restart layanan yang membuat ulang tunnel juga merupakan peristiwa pembuatan, dan itu mudah terlewat ketika unit tampak sehat. Periksa urutannya, bukan hanya isi akhir berkas.

Baca ulang ketiga nilai yang sama setelah VPN menyambung ulang dan sekali lagi setelah reboot. Tunnel yang baru dibuat adalah antarmuka baru, dan antarmuka baru mengambil bawaan yang berlaku saat pembuatan. Jika angkanya berubah di antara peristiwa itu, konfigurasinya diterapkan oleh sesuatu yang belum Anda kenali.

Jangan memperbaikinya dengan alat yang salah

Ketika penerusan tampak rusak, godaannya adalah mengosongkan firewall atau menambahkan masquerading. Keduanya tidak menyentuh sakelar penerusan. Status penerusan, izin meneruskan, rute ke tujuan, dan jalur balik adalah empat syarat terpisah, dan hanya yang pertama adalah sysctl.

Uji juga dengan aliran yang benar. Permintaan yang dibuat di gateway itu sendiri sama sekali tidak melatih penerusan; itu lalu lintas yang dihasilkan secara lokal. Pertanyaannya adalah apakah paket yang datang dari klien VPN atau host LAN diterima dan dirutekan terus, jadi pengujiannya harus berasal dari belakang gateway.

Pisahkan kasus IPv6

Semua di sini adalah IPv4. Penerusan IPv6, pengumuman router, dan perilaku accept_ra punya kendali sendiri, dan menyalin jalur ipv4 ke setelan ipv6 menghasilkan berkas yang tampak masuk akal dan tidak melakukan hal berguna. Gateway tumpukan ganda perlu kedua setel dikonfigurasi dengan sengaja.

Satu pemeriksaan terakhir: setelah nilainya cocok, pastikan rute tunnel dipilih untuk tujuan dan jalur balasannya ada. Penerusan yang aktif pada antarmuka tanpa rute tetap merupakan lubang hitam, dan kegagalan itu terlihat sama dari sisi klien.