Kegagalan client-connect OpenVPN: adakah pembersihan semasa disconnect dijamin?
Klien yang ditolak tidak membatalkan peraturan firewall atau rekod bertulis. Bandingkan kontrak callback dengan pembalikan yang perlu dilakukan hook anda sendiri.
Apabila skrip client-connect keluar dengan kod bukan sifar, OpenVPN menolak klien itu, dan pengendali biasanya menganggap skrip client-disconnect yang sepadan akan mengemas semuanya. Selalunya ia tidak pernah berjalan, kerana pemprosesan disconnect bergantung pada apa yang berjaya diselesaikan oleh peringkat connect. Menganggap penolakan dan pembalikan sebagai satu mekanisme itulah yang menjadikan log masuk yang gagal sebagai peraturan firewall yang bocor atau rekod yatim. Kedua-duanya ialah dua kewajipan berasingan, dan hanya satu daripadanya automatik. Baca laluan keluar hook itu sendiri sebelum menyalahkan pelayan kerana meninggalkan keadaan.
Keluar dengan kod bukan sifar menolak klien; ia tidak membatalkan kerja anda
Status keluar client-connect ialah keputusan kemasukan. Sifar bermaksud terima, apa-apa lagi bermaksud merobohkan instans sebelum ia benar-benar mantap. Tiada apa-apa dalam kontrak itu yang memeriksa apa yang telah dilakukan skrip kepada dunia luar. Jika skrip menambah peraturan iptables, menulis baris atau menaikkan pembilang, perubahan itu kekal selepas penolakan.
Asimetri yang sama terpakai kepada pemalam, di mana beberapa fungsi connect boleh berjalan untuk satu instans. Kegagalan kemudian tidak membatalkan kejayaan terdahulu secara retroaktif, dan fungsi terdahulu tidak mempunyai cara untuk mengetahui bahawa fungsi adik beradik telah gagal.
Penolakan automatik, pembersihan tidak
Manual OpenVPN 2.6 mengaitkan pemprosesan client-disconnect dengan kejayaan pemprosesan connect sebelumnya. Pengecualian yang didokumenkan meliputi rantaian lata: jika satu langkah connect telah pun mengembalikan kejayaan, langkah disconnect yang sepadan masih berjalan apabila instans dirobohkan, walaupun langkah connect kemudiannya gagal. Pengecualian itu sempit dan bergantung pada berapa banyak callback dikonfigurasikan, sebab itu menguji satu skrip shell tidak memberitahu anda apa-apa tentang rantaian.
Petakan konfigurasi sebenar sebelum mereka bentuk di sekelilingnya: skrip mana, pemalam mana dan dalam susunan apa semuanya berjalan. Jadual di bawah menyenaraikan apa yang ditinggalkan oleh persediaan separuh siap.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Setiap baris berakhir sama bagi klien dan berbeza bagi hos. Klien tidak dapat mengetahui yang mana berlaku, jadi hook mesti membalikkan apa yang dilakukannya sebelum mengembalikan status kegagalan.
Pampas di dalam skrip yang gagal
Sahkan semua yang boleh sebelum menyentuh keadaan dikongsi: medan sijil, ketersediaan alamat, kumpulan tempat klien berada. Penolakan paling murah ialah yang berlaku sebelum sebarang peruntukan. Setelah persediaan merangkumi beberapa operasi luaran, simpan rekod yang mana telah selesai dan balikkan dalam susunan terbalik sebelum mengembalikan status kegagalan.
Kes konkrit: skrip mencipta entri firewall setiap klien, kemudian gagal menulis baris keadaan yang menerangkannya. Cabang yang gagal harus membuang entri yang baru diciptanya dan kemudian keluar dengan kod bukan sifar. Menunggu peristiwa disconnect yang mungkin tidak pernah dijadualkan ialah cara sesuatu peraturan hidup lebih lama daripada sesi yang dimaksudkan untuknya.
Jadikan pampasan idempoten dan mempunyai pemilik
Pembersihan mesti selamat dijalankan dua kali dan tepat tentang apa yang boleh dipadamnya. Peristiwa lewat daripada percubaan terdahulu tidak sepatutnya membuang peruntukan sesi yang lebih baharu hanya kerana kedua-duanya berkongsi nama biasa atau alamat terowong yang dikitar semula. Rekodkan pengendali atau id operasi khusus bersama sumber, dan padam mengikut kunci itu bukan mengikut nama. Transaksi pangkalan data hanya membantu dengan perubahan pangkalan data itu sendiri; peraturan firewall di luar sempadan itu memerlukan langkah pampasan yang eksplisit.
Anggap proses boleh mati antara perubahan dan pembersihan, dan tambah pendamai yang membandingkan keadaan luaran dengan senarai klien yang diterima mengikut jadual.
Uji tiga laluan yang benar-benar berbeza
Latih tiga kes: penolakan sebelum apa-apa diperuntukkan, satu selepas peruntukan separa, dan sesi diterima biasa yang berakhir kemudian. Ketiga-tiganya menghasilkan baris log berbeza dan sisa berbeza. Sahkan keadaan luaran selepas setiap satu, bukan hanya mesej kegagalan klien, kerana kegagalan klien ialah hasil yang dijangka dalam dua daripada tiga.
Log peringkat hook, status keluar dan apa yang diperuntukkan atau dilepaskan, tanpa kelayakan. Log hook yang menamakan sumber yang diciptanya itulah yang menjadikan peraturan bocor boleh ditemui enam bulan kemudian.