Menjangkau prefiks privat melalui VPN adalah persyaratan yang punya durasi: ia berlaku selama koneksi itu dapat dipakai, dan berakhir ketika koneksinya berakhir. Skrip login tidak bisa menyatakan itu, karena login dan naiknya tunnel adalah momen yang berbeda, dan tunnel yang ada saat login belum tentu yang membawa lalu lintas semenit kemudian. Keputusan pertama bukanlah perintah mana yang dijalankan. Melainkan komponen mana yang memiliki prefiks itu.

Prefiks butuh pemilik, bukan momen

Mulailah dengan menulis persyaratan sebagai kalimat bersubjek: jangkau 10.77.0.0/24 melalui VPN Kantor selama koneksi itu aktif. Kalimat itu menyebut prefiks, koneksi, dan syaratnya, dan langsung menyingkirkan dua pengganti populer: hook login dan nama antarmuka seperti ppp0 atau utun2.

Nama antarmuka diberikan saat runtime dan tidak stabil antar penyambungan ulang. Hook yang mencocokkan nama yang dilihatnya pekan lalu entah tidak akan menyala atau menyala pada antarmuka orang lain. Kedua hasil tampak seperti bug perutean, bukan seperti asumsi usang sebagaimana adanya. Keberatan yang sama berlaku untuk skrip apa pun yang bergantung pada nama yang hanya ada selama satu tunnel tertentu aktif.

Gunakan sumber niat rute yang didukung

Gateway, profil terkelola, atau mekanisme rute terdokumentasi milik klien pemilik adalah tempat yang tepat, asalkan mekanisme itu dapat menyatakan persyaratannya. Mana yang berlaku bergantung pada protokol dan penyedia, dan kuncinya tidak berpindah di antara keduanya, jadi nilai yang mengonfigurasi profil OpenVPN tidak memberi tahu Anda apa pun tentang klien L2TP atau IKEv2 bawaan.

MechanismCan carry extra prefixesWho owns the lifetime
Gateway-pushed routesOften, if the gateway is configured for itThe connection
Managed profile settingsDepends on the client and profile formatThe profile
Provider tunnel settingsYes, as included and excluded routesThe provider process
Manual commandYes, onceNobody

Bagi pengembang tunnel paket, setelan tunnel IPv4 Apple memaparkan rute yang disertakan dan dikecualikan secara eksplisit, dan IPv6 punya padanannya. Itu adalah API yang dipakai penyedia, bukan bukti bahwa setiap panel VPN bawaan menawarkan daftar rute sembarang kepada administrator. Jika kombinasi saat ini tidak dapat menyatakan prefiks yang Anda butuhkan, langkah berikutnya adalah jalur konfigurasi yang didukung dari operator, bukan aplikasi lain yang dipasang dengan harapan berperilaku lebih baik.

Masa hidup mencakup pembersihan

Kadang-kadang pembantu eksternal benar-benar diperlukan, dan saat itulah «tambahkan rute» adalah bagian terkecil dari tugasnya. Ia harus tahu koneksi mana yang dilayaninya dan antarmuka mana yang dipakai koneksi itu, menunggu sampai keadaan jaringan yang relevan tenang, tetap idempoten saat dijalankan dua kali berturut-turut, dan tidak membersihkan apa pun yang tidak ia pasang sendiri.

Klausul terakhir itulah yang menyakitkan. Pembantu yang menghapus setiap rute yang cocok dengan prefiks kantor cepat atau lambat akan menghapus rute yang tidak ia tambahkan. Gangguan yang dihasilkan lalu dituduhkan kepada klien VPN, karena klien adalah bagian yang dilihat pengguna. Memutuskan apa yang dimiliki pembantu sebelum menulisnya lebih murah daripada menjelaskan belakangan mengapa sebuah subnet lokal berhenti menjawab.

Balapan penyambungan ulang

Bayangkan penyambungan ulang cepat. Sesi A mati, sesi B hidup dan memasang rutenya, lalu pembersihan tertunda A akhirnya berjalan. Jika pembersihan itu menghapus rute berdasarkan prefiks, ia ikut membawa keadaan sah B, dan koneksi yang berfungsi sedetik sebelumnya kini merutekan ke tempat kosong.

Ini balapan kepemilikan, dan menambahkan tidur ke skrip hanya mengubah pihak mana yang menang. Perbaikannya adalah membuat pembersihan bergantung pada identitas: bandingkan antarmuka dan sesi yang dipasang pembantu dengan yang masih berlaku, dan hapus hanya bila cocok.

Apa yang diuji, dan apa yang tidak bisa dilakukan rute

Penerimaan harus mencakup empat transisi: koneksi pertama, penyambungan ulang ke antarmuka berbeda, percobaan koneksi yang gagal, dan pemutusan akhir. Setelah masing-masing, bacalah rute yang benar-benar dipilih sistem untuk sebuah alamat di sisi jauh, bukan yang Anda harapkan.

route -n get 10.77.0.5
netstat -rn -f inet

Sertakan kasus canggung dalam putaran yang sama: IPv6 di tempat yang dibutuhkan, prefiks lokal yang bertumpuk dengan prefiks jauh, dan rute ke titik akhir VPN publik itu sendiri, yang harus tetap berfungsi selama tunnel aktif. Lalu tuliskan apa yang bukan rute. Ia memilih paket; ia tidak memberi izin di sisi jauh dan tidak membuat jalur balik, dan itu tetap menjadi persyaratan terpisah dengan pemilik terpisah.

Hasil yang Anda inginkan adalah prefiks yang mengikuti pemilik koneksi yang didukungnya melewati setiap transisi, bukan perintah yang kebetulan berhasil sekali di mesin tempat perintah itu ditulis.

Artikel terkait