Buat penerusan IPv4 tetap bertahan setelah gateway VPN dimulai ulang

Ping ke gateway berhasil tetapi menjangkau apa pun di belakangnya tidak, dan itulah bentuk masalah penerusan, bukan masalah terowongan. Pengiriman lokal ke gateway membuktikan terowongan sudah naik dan penetapan alamat berhasil; itu tidak mengatakan apa pun tentang apakah kernel akan meneruskan paket dari satu antarmuka ke antarmuka lain. Sebelum menyentuh sysctl apa pun, pastikan mesin memang dimaksudkan untuk merutekan lalu lintas ini dan temukan konteks jaringan yang memegang antarmuka menghadap klien. Lalu baca nilainya di sana, bukan di tempat panduan terakhir yang Anda baca kebetulan melihat.

Menjangkau gateway tidak sama dengan meneruskan

Dua keputusan terpisah terjadi di dalam kernel. Pengiriman ke alamat lokal mengakhiri perjalanan paket; penerusan mengirimnya keluar lagi melalui antarmuka lain, dan keputusan kedua itu diatur per namespace jaringan. Gateway bisa sepenuhnya terjangkau sementara penerusan mati, dan dari prompt ping kedua kegagalan tampak sama.

Catat antarmuka tempat paket klien datang dan antarmuka tempat jalur berikutnya keluar. Keduanya milik satu namespace, dan namespace itulah yang memegang pengaturan yang penting.

Baca nilainya di tempat paket benar-benar berada

Pada gateway yang merutekan di namespace host, satu perintah menjawab pertanyaannya: sysctl net.ipv4.ip_forward. Saat jalur masuk dan jalur berikutnya berada di namespace bernama, tanyakan namespace itu: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Nilai host bukan pengganti nilai namespace, dan angka satu di host bukan bukti apa pun.

Tidak setiap konteks perutean punya label yang bisa Anda berikan ke ip netns. Runtime kontainer dan layanan membuat namespace yang tidak pernah didaftarkan dengan nama ramah, dan untuk itu Anda memakai alat inspeksi runtime. Ganti vpn-gw dengan nama sebenarnya, atau mekanisme runtime yang mencapai konteks yang sama, dan berhenti menebak di tingkat host.

Beri pengaturan itu satu pemilik

Pada gateway host systemd konvensional, bentuk yang tahan lama adalah berkas drop-in dengan nama pilihan administrator seperti /etc/sysctl.d/60-vpn-forwarding.conf yang berisi net.ipv4.ip_forward = 1. Tulis berkasnya, lalu muat berkas spesifik itu agar status langsung juga berubah: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, diikuti pembacaan ulang. Nama berkas hanyalah contoh, bukan jalur VPN yang dicadangkan, dan angka di depan penting karena berkas yang diurutkan belakangan menang.

Prioritas adalah tempat ketahanan diam-diam rusak. Periksa pemuat distribusi sekaligus drop-in Anda sendiri, karena procps sysctl --system juga membaca /etc/sysctl.conf di akhir, sedangkan urutan sysctl.d systemd adalah urutan yang sama sekali berbeda. Penetapan yang lebih akhir bisa langsung mengembalikan kunci yang sama, membuat berkas Anda benar tetapi nilai efektifnya salah. Jangan timpa berkas administrator yang sudah ada demi memenangkan perdebatan itu; temukan pemiliknya dan ubah di sana.

Namespace yang dibuat setelah boot sama sekali tidak diatur oleh drop-in host. Pengaturannya milik apa pun yang membuatnya, entah runtime kontainer atau unit penyediaan namespace. Memberi kontainer hak istimewa host yang luas demi menghindari pertanyaan itu adalah pertukaran yang lebih buruk daripada menghabiskan sepuluh menit mengidentifikasi pemilik yang benar.

Ketahui biaya sakelar itu sebelum Anda membaliknya

ip_forward bukan boolean yang tidak berbahaya. Dokumentasi kernel mencatat bahwa mengubahnya mengatur ulang beberapa parameter IPv4 lain ke nilai bawaan host atau router, jadi pembalikan diagnostik bisa membuang penyetelan yang dilakukan di tempat lain dan tidak pernah menyebutkannya. Perlakukan sebagai perubahan konfigurasi dengan efek samping, bukan sebagai pemeriksaan yang bisa dijalankan sembarangan.

Itu juga menyingkirkan kebiasaan mematikan dan menyalakannya setiap kali klien tidak bisa menjangkau host. Jika nilainya sudah satu, kesalahannya ada di tempat lain pada jalur, dan menulis ulang kunci yang sama untuk ketiga kalinya tidak akan menggerakkannya.

Buktikan ketahanannya, lalu uji sisa jalurnya

Baca kembali nilainya pada empat momen: tepat setelah perubahan, setelah antarmuka VPN muncul, setelah tersambung ulang, dan setelah mulai ulang terencana. Nilai yang kembali seperti semula pada salah satu titik itu punya pemilik kedua, dan satu lagi penulisan sekali jalan hanya menyembunyikannya sampai reboot berikutnya.

Penerusan yang aktif masih menyisakan tiga hal untuk diverifikasi. Klien butuh rute ke tujuan, gateway butuh rute lanjutan plus izin memakainya, dan tujuan butuh jalur balik ke alamat terowongan klien. LAN privat yang dirutekan tidak otomatis membutuhkan NAT, jadi jangan menambahkan masquerading sebelum Anda tahu mana dari ketiganya yang hilang, dan ujilah dari klien yang dimaksud, bukan dari gateway itu sendiri, karena permintaan yang berasal dari gateway tidak pernah menyentuh jalur penerusan yang baru saja Anda aktifkan. IPv6 membawa kebijakan penerusan dan peruteannya sendiri, jadi uji IPv4 yang berhasil tidak mengatakan apa pun tentangnya.

Simpan jalur drop-in, pemilik namespace, dan perintah pembacaan ulang bersama-sama di runbook. Siapa pun yang mengambil ini berikutnya harus bisa membaca nilainya, melihat siapa pemiliknya, dan memutuskan dalam satu menit apakah masalahnya ketahanan atau sisa jalurnya.