Pastikan penghantaran IPv4 kekal selepas gateway VPN dimulakan semula

Ping ke gateway berfungsi tetapi mencapai apa-apa di belakangnya tidak, dan itulah bentuk masalah penghantaran dan bukan masalah terowong. Penghantaran setempat ke gateway membuktikan terowong telah naik dan penugasan alamat berjaya; ia tidak berkata apa-apa tentang sama ada kernel akan melepaskan paket dari satu antara muka ke antara muka lain. Sebelum menyentuh mana-mana sysctl, sahkan mesin itu memang bertujuan untuk menghalakan trafik ini dan cari konteks rangkaian yang memegang antara muka menghadap klien. Kemudian baca nilainya di situ, bukan di tempat panduan terakhir yang anda baca kebetulan melihat.

Mencapai gateway bukanlah sama dengan menghantar

Dua keputusan berasingan berlaku di dalam kernel. Penghantaran ke alamat setempat menamatkan perjalanan paket; penghantaran semula menghantarnya keluar semula melalui antara muka lain, dan keputusan kedua itu dikawal mengikut ruang nama rangkaian. Gateway boleh dicapai sepenuhnya sementara penghantaran dimatikan, dan dari gesaan ping kedua-dua kegagalan kelihatan sama.

Catat antara muka tempat paket klien tiba dan antara muka tempat laluan seterusnya keluar. Kedua-duanya milik satu ruang nama, dan ruang nama itulah yang memegang tetapan yang penting.

Baca nilainya di tempat paket benar-benar berada

Pada gateway yang menghalakan dalam ruang nama hos, satu arahan menjawab soalan itu: sysctl net.ipv4.ip_forward. Apabila laluan masuk dan laluan seterusnya tinggal dalam ruang nama bernama, tanyalah ruang nama itu: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Nilai hos bukan pengganti nilai ruang nama, dan satu pada hos bukan bukti apa-apa.

Bukan setiap konteks penghalakan mempunyai label yang boleh anda berikan kepada ip netns. Persekitaran masa jalan kontena dan perkhidmatan mencipta ruang nama yang tidak pernah didaftarkan dengan nama mesra, dan untuk itu anda menggunakan alat pemeriksaan masa jalan. Gantikan vpn-gw dengan nama sebenar, atau mekanisme masa jalan yang mencapai konteks yang sama, dan berhenti meneka pada peringkat hos.

Berikan tetapan itu satu pemilik

Pada gateway hos systemd konvensional, bentuk tahan lama ialah fail drop-in dengan nama pilihan pentadbir seperti /etc/sysctl.d/60-vpn-forwarding.conf yang mengandungi net.ipv4.ip_forward = 1. Tulis fail itu, kemudian muatkan fail khusus itu supaya keadaan hidup juga berubah: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, diikuti pembacaan semula. Nama fail ialah contoh dan bukan laluan VPN terpelihara, dan nombor di hadapan penting kerana fail yang diisih kemudian menang.

Keutamaan ialah tempat ketahanan rosak secara senyap. Semak pemuat distribusi serta drop-in anda sendiri, kerana procps sysctl --system juga membaca /etc/sysctl.conf di hujungnya, manakala susunan sysctl.d systemd ialah urutan yang sama sekali berbeza. Penetapan kemudian boleh mengembalikan kunci yang sama serta-merta, meninggalkan fail anda betul tetapi nilai berkesan salah. Jangan tulis ganti fail pentadbir sedia ada untuk memenangi hujah itu; cari pemiliknya dan ubah di situ.

Ruang nama yang dicipta selepas but tidak dikawal langsung oleh drop-in hos. Tetapannya milik apa sahaja yang menciptanya, sama ada masa jalan kontena atau unit penyediaan ruang nama itu. Memberi kontena keistimewaan hos yang luas untuk mengelak soalan itu ialah tawar-menawar yang lebih buruk daripada menghabiskan sepuluh minit mengenal pasti pemilik yang betul.

Ketahui kos suis itu sebelum anda menekannya

ip_forward bukan boolean yang tidak berbahaya. Dokumentasi kernel menyatakan bahawa menukarnya menetapkan semula beberapa parameter IPv4 lain kepada nilai lalai hos atau penghala, jadi penukaran diagnostik boleh membuang penalaan yang dibuat di tempat lain dan tidak pernah menyebutnya. Anggap ia sebagai perubahan konfigurasi dengan kesan sampingan dan bukan ujian yang boleh dijalankan secara sambil lewa.

Itu juga menolak mematikannya dan menghidupkannya setiap kali klien tidak dapat mencapai hos. Jika nilainya sudah satu, kesalahannya ada di tempat lain pada laluan, dan menulis semula kunci yang sama untuk kali ketiga tidak akan menggerakkannya.

Buktikan ketahanan, kemudian uji seluruh laluan

Baca semula nilainya pada empat saat: sejurus selepas perubahan, selepas antara muka VPN muncul, selepas sambungan semula, dan selepas permulaan semula yang dirancang. Nilai yang berundur pada mana-mana titik itu mempunyai pemilik kedua, dan satu lagi tulisan sekali jalan hanya menyembunyikannya sehingga but semula berikutnya.

Penghantaran yang diaktifkan masih meninggalkan tiga perkara untuk disahkan. Klien memerlukan laluan ke destinasi, gateway memerlukan laluan seterusnya serta kebenaran menggunakannya, dan destinasi memerlukan laluan balik ke alamat terowong klien. LAN peribadi yang dihalakan tidak memerlukan NAT secara automatik, jadi jangan tambah masquerading sebelum anda tahu yang mana antara tiga itu hilang, dan uji dari klien yang dimaksudkan dan bukan dari gateway itu sendiri, kerana permintaan yang bermula di gateway tidak pernah menyentuh laluan penghantaran yang baru anda aktifkan. IPv6 membawa dasar penghantaran dan penghalakan sendiri, jadi ujian IPv4 yang berjaya tidak berkata apa-apa tentangnya.

Simpan bersama dalam runbook laluan drop-in, pemilik ruang nama dan arahan pembacaan semula. Sesiapa yang mengambil alih ini seterusnya harus boleh membaca nilainya, melihat siapa pemiliknya, dan memutuskan dalam satu minit sama ada masalahnya ketahanan atau seluruh laluan.