Skrip yang mesti berjalan selepas VPN naik memerlukan peristiwa daripada komponen yang memiliki sambungan itu. Fail yang diletakkan dalam direktori hook rangkaian lama bukan panggilan balik untuk setiap VPN yang mungkin dicipta oleh NetworkManager, pppd atau proses OpenVPN berasingan. Setiap pemilik tersebut melaporkan peristiwa berbeza dengan persekitaran berbeza, jadi pemilik mesti dikenal pasti sebelum hook dipilih. Jika tidak, skrip itu betul dan langsung tidak pernah berjalan.

Untuk VPN yang diuruskan oleh NetworkManager, dispatcher ialah tempat yang betul, dan vpn-up ialah tindakan yang betul.

Gunakan vpn-up, bukan peristiwa antara muka

Dispatcher membezakan up daripada vpn-up. Yang pertama melaporkan antara muka yang diaktifkan; yang kedua melaporkan sambungan VPN yang diaktifkan. Wi-Fi naik hanya bermakna pautan dasarnya wujud; terowong mungkin masih berunding, atau mungkin tidak pernah disahkan.

Skrip menerima antara muka dan tindakan, manakala butiran sambungan datang melalui persekitaran, termasuk UUID profil dan antara muka IP VPN. Baca pemboleh ubah itu dan bukannya menyimpulkan identiti daripada nama peranti.

Hadkan padanan kepada satu sambungan

Padankan pada UUID sambungan, atau identiti lain yang diberikan oleh dispatcher, bukan pada awalan tun atau ppp0. Nama antara muka tidak stabil, lebih daripada satu terowong boleh wujud pada masa yang sama, dan dua profil boleh membawa nama paparan yang sama. Memadankan awalan tun bermakna skrip akhirnya akan berjalan untuk sambungan yang tiada siapa berniat untuk menyentuhnya. Ia juga boleh berjalan dua kali untuk satu profil apabila penyambungan semula membina semula peranti.

Jadikan tugas idempoten. Panggilan balik yang menambah laluan pada setiap panggilan akhirnya memenuhi jadual dengan pendua, dan salinan kedua itulah yang merosakkan penghalaan.

Ketahui apa yang tidak dibuktikan oleh pengaktifan

vpn-pre-up berjalan sebelum NetworkManager melaporkan VPN diaktifkan sepenuhnya, dan pengurus menunggu skrip tersebut. Gunakan peringkat menyekat hanya apabila tugas itu memang tergolong di situ, kerana pemeriksaan perlahan melambatkan pengaktifan yang ditunggu oleh setiap komponen lain.

Kewujudan laluan tidak membuktikan bahawa aplikasi sedang mendengar, nama peribadi diselesaikan atau sesi pengguna wujud. Periksa perkara itu secara berasingan dengan had masa, dan laporkan lapisan mana yang gagal dan bukannya mengulangi seluruh rantaian.

Hormati konteks tempat skrip berjalan

Skrip dispatcher berjalan sebagai root, di luar mana-mana sesi pengguna. Jangan andaikan persekitaran pengguna yang log masuk, sesi grafiknya atau gantungan kunci yang tidak berkunci tersedia. Tiada siapa patut bertindak balas terhadap ketiadaan konteks desktop dengan menjadikan setiap kelayakan boleh dibaca oleh setiap proses. Simpan kerja sesi pengguna dalam perkhidmatan pengguna atau pembantu sesi yang boleh diberi isyarat oleh panggilan balik tanpa menyamar sebagai pengguna.

Pemilikan dan kebenaran pada skrip juga penting. Fail yang dijalankan sebagai root dan boleh diganti oleh mana-mana pengguna ialah laluan peningkatan keistimewaan, dan itu penemuan yang tidak bergantung pada betul atau tidaknya logik VPN.

Rancang pemutusan yang tidak pernah berlaku

NetworkManager mendokumenkan bahawa vpn-pre-down tidak dikeluarkan untuk pemutusan paksa seperti penamatan tidak dijangka atau kehilangan sambungan. Oleh itu pembersihan yang dibina hanya di sekitar pre-down yang lancar tidak lengkap secara struktur. Sebarang keadaan dikongsi yang diubah oleh skrip memerlukan pemilik lain yang boleh memulihkannya selepas ranap, dan laluan pemulihan itu mesti diuji dan bukan diandaikan.

Uji hook dengan sambungan biasa, penyambungan semula, pemutusan yang disengajakan dan kabel yang dicabut. Rekod UUID, tindakan dan antara muka yang berjalan, tanpa mencatat rahsia. Rekod itu ialah satu-satunya bukti yang boleh dipercayai bahawa hook berjalan untuk sambungan yang anda maksudkan, dan itulah yang menjadikan perubahan seterusnya selamat.

Artikel berkaitan