Jalankan tugas pasca-VPN dari dispatcher, bukan dari if-up

Skrip yang harus berjalan setelah VPN naik memerlukan peristiwa dari komponen yang memiliki koneksi. Berkas yang diletakkan di direktori hook jaringan lama bukan panggilan balik untuk setiap VPN yang mungkin dibuat NetworkManager, pppd, atau proses OpenVPN mandiri. Setiap pemilik tersebut melaporkan peristiwa berbeda dengan lingkungan berbeda, jadi pemiliknya harus diidentifikasi sebelum hook dipilih. Jika tidak, skrip itu benar dan sekadar tidak pernah berjalan.

Untuk VPN yang dikelola NetworkManager, dispatcher adalah tempat yang tepat, dan vpn-up adalah tindakan yang tepat.

Gunakan vpn-up, bukan peristiwa antarmuka

Dispatcher membedakan up dari vpn-up. Yang pertama melaporkan antarmuka yang diaktifkan; yang kedua melaporkan koneksi VPN yang diaktifkan. Wi-Fi naik hanya berarti tautan dasarnya ada; terowongan bisa masih bernegosiasi, atau mungkin tidak pernah terautentikasi.

Skrip menerima antarmuka dan tindakan, sementara detail koneksi datang melalui lingkungan, termasuk UUID profil dan antarmuka IP VPN. Baca variabel itu alih-alih menyimpulkan identitas dari nama perangkat.

Batasi pencocokan pada satu koneksi

Cocokkan pada UUID koneksi, atau identitas lain yang disediakan dispatcher, bukan pada awalan tun atau ppp0. Nama antarmuka tidak stabil, bisa ada lebih dari satu terowongan pada saat yang sama, dan dua profil bisa membawa nama tampilan yang sama. Mencocokkan awalan tun berarti skrip pada akhirnya akan terpicu untuk koneksi yang tidak ingin disentuh siapa pun. Skrip juga bisa terpicu dua kali untuk satu profil ketika penyambungan ulang membangun ulang perangkat.

Buat tugas menjadi idempoten. Panggilan balik yang menambahkan rute pada setiap pemanggilan akhirnya memenuhi tabel dengan duplikat, dan salinan kedua itulah yang merusak perutean.

Ketahui apa yang tidak dibuktikan aktivasi

vpn-pre-up berjalan sebelum NetworkManager melaporkan VPN sepenuhnya aktif, dan pengelola menunggu skrip tersebut. Gunakan tahap pemblokiran hanya ketika tugas memang berada di sana, karena pemeriksaan yang lambat menunda aktivasi yang ditunggu semua komponen lain.

Adanya rute tidak membuktikan bahwa aplikasi sedang mendengarkan, nama privat terurai, atau sesi pengguna ada. Periksa itu secara terpisah dengan batas waktu, dan laporkan lapisan mana yang gagal alih-alih mengulang seluruh rantai.

Hormati konteks tempat skrip berjalan

Skrip dispatcher berjalan sebagai root, di luar sesi pengguna mana pun. Jangan menganggap lingkungan pengguna yang login, sesi grafisnya, atau gantungan kunci yang terbuka tersedia. Tidak seorang pun boleh menanggapi konteks desktop yang hilang dengan membuat setiap kredensial dapat dibaca oleh setiap proses. Simpan pekerjaan sesi pengguna di layanan pengguna atau pembantu sesi yang dapat diberi sinyal oleh panggilan balik tanpa menyamar sebagai pengguna.

Kepemilikan dan izin pada skrip juga penting. Berkas yang dijalankan sebagai root dan dapat diganti oleh pengguna mana pun adalah jalur eskalasi hak istimewa, dan itu temuan yang tidak bergantung pada benar atau tidaknya logika VPN.

Rencanakan pemutusan yang tidak pernah terpicu

NetworkManager mendokumentasikan bahwa vpn-pre-down tidak dipancarkan untuk pemutusan paksa seperti penghentian tak terduga atau hilangnya konektivitas. Jadi pembersihan yang dibangun hanya di sekitar pre-down yang mulus tidak lengkap secara konstruksi. Setiap keadaan bersama yang diubah skrip memerlukan pemilik lain yang dapat memulihkannya setelah crash, dan jalur pemulihan itu harus diuji, bukan diasumsikan.

Uji hook dengan koneksi normal, penyambungan ulang, pemutusan yang disengaja, dan kabel yang dicabut. Catat UUID, tindakan, dan antarmuka yang terpicu, tanpa mencatat rahasia. Catatan itu adalah satu-satunya bukti andal bahwa hook berjalan untuk koneksi yang Anda maksud, dan itulah yang membuat perubahan berikutnya aman.