Bolehkah skrip cangkuk OpenVPN menggunakan terowong yang baru dibinanya?

Sama ada skrip cangkuk sampai ke sebelah sana terowong bergantung pada tiga syarat: peristiwa mana ia dipasang, sama ada OpenVPN masih dalam urutan permulaannya semasa skrip berjalan, dan sama ada kerja itu telah dipisahkan daripada urutan tersebut. Kebanyakan skrip gagal pada syarat ketiga. Menambah tidur melayan masalah kitaran hayat sebagai masalah masa, dan ia berjaya cukup kerap untuk mengelirukan.

Tentukan peristiwa dahulu, kemudian mekanisme untuk menangguhkan kerja, kemudian tempat kerja yang ditangguhkan itu berjalan. Ketiga-tiga keputusan ini bebas, dan mencampurkannya ialah cara cangkuk dua baris menjadi satu petang penuh.

Mengapa cangkuk menunggu terowong yang menunggunya

OpenVPN memanggil cangkuknya secara segerak, di dalam proses yang sama yang menggerakkan paket. up dicetuskan apabila peranti tun atau tap wujud tetapi sebelum sebarang laluan ditambah, dan route-up dicetuskan selepas laluan; tiada satu pun detik itu menjanjikan bahawa pihak lawan akan menjawab. Selagi skrip daripada mana-mana cangkuk masih berjalan, daemon tidak memajukan, jadi arahan yang menjangka trafik melintasi terowong menunggu terowong yang menunggu arahan itu. Penantian membulat inilah sebabnya larian manual lulus dan cangkuk tamat masa.

Tampalan yang jelas, tidur beberapa saat, kadangkala berjaya kerana hujung jauh naik sendiri, bukan kerana tidur itu membaiki apa-apa. Pembantu yang menyemak kesediaan ialah jawapan lain: cangkuk kembali, pemajuan bermula, dan pembantu mendapat apa yang diperlukan apabila ia benar-benar ada.

Pilih cangkuk mengikut peristiwa, bukan mengikut kemudahan

Pasang up pada kerja yang hanya memerlukan peranti, route-up pada kerja yang memerlukan laluan, dan simpan client-connect serta client-disconnect untuk tugas setiap klien di sebelah pelayan. Pembersihan semasa putus mesti tahan dijalankan dua kali, kerana sambungan semula melalui antara muka berterusan tidak mengikut urutan yang sama seperti mula semula penuh. Di pelayan, client-connect dicetuskan apabila klien mengesahkan diri, bukan apabila daemon bermula, yang wajar disahkan sebelum logik dipindahkan ke sana. Jika kerja itu milik kitaran hayat perkhidmatan dan bukan satu sambungan, unit systemd ialah tempat tinggal yang lebih baik daripada mana-mana cangkuk.

Arahan cangkuk dilaksanakan terus oleh daemon, tanpa shell di antaranya, jadi ifconfig_remote dalam baris up tiba sebagai teks literal. Balut arahan itu dalam shell yang jelas, atau simpan logik dalam skrip yang membaca persekitaran. ipchange ialah satu direktif yang menambah hujahnya sendiri: ia menyerahkan alamat dan port kepada arahan, jadi skrip yang ditulis untuk tiada satu pun melihat dua yang tidak dijangka.

Tiga cara untuk memisahkan kerja

Pilihan pertama ialah menghantar pembantu ke latar dari dalam cangkuk: mulakannya dengan setsid atau systemd-run --scope, tutup deskriptor warisan, dan keluar dengan sifar serta-merta. Yang kedua ialah membiarkan cangkuk menulis fail keadaan kecil dan membiarkan pemasa systemd atau unit laluan bertindak ke atasnya, yang mengekalkan cangkuk sebagai remeh dan meletakkan dasar cubaan semula di tempat yang ada log. Yang ketiga ialah membuang cangkuk sepenuhnya dan memindahkan kerja ke unit yang disusun selepas perkhidmatan VPN, yang merupakan jawapan betul apabila kerja itu sama sekali bukan per sambungan. Ketiga-tiganya berkongsi satu peraturan: cangkuk mesti kembali sebelum ia memerlukan terowong.

Apa pun yang anda pilih, jadikan pembantu itu idempoten dan boleh diperhati. Dua seruan yang bertindih tidak sepatutnya menjalankan tindakan tidak boleh balik yang sama dua kali, dan pembantu yang gagal mesti meninggalkan sesuatu yang boleh dibaca manusia.

Pisahkan kegagalan sandbox daripada kegagalan kitaran hayat

Apabila skrip berjalan dari gesaan root dan gagal sebagai perkhidmatan, puncanya biasanya sandbox dan bukan rangkaian. ProtectHome yang menyekat, ProtectSystem yang hanya-baca, atau direktori kerja yang tidak wujud boleh menjadikan skrip atau datanya tidak dapat dicapai, dan pada hos SELinux fail itu juga memerlukan konteks yang membenarkan pelaksanaan. Baca unit dengan systemctl cat openvpn-server@server dan jurnal dengan journalctl -u openvpn-server@server -n 80, kemudian cari ralat kebenaran atau konteks dan bukannya tamat masa sambungan. Melumpuhkan sandbox sepatutnya menjadi langkah terakhir, bukan yang pertama.

Kegagalan kitaran hayat kelihatan berbeza: cangkuk bermula, pembantu berjalan, dan soket itu memang belum ada. Tulis baris bertanda masa daripada cangkuk itu sendiri, putuskan dan sambung semula, dan baca peristiwa mengikut urutan. Apabila pembantu benar-benar memerlukan terowong, biarkan ia menyemak kesediaan dan bukannya tidur untuk tempoh tetap.

Tiga medan menjadikan laporan seterusnya berguna: cangkuk mana yang berjalan, akaun mana yang digunakan, dan di mana ia berhenti. Tanpa itu, setiap siasatan kemudian bermula dari awal.