Adakah suis mati VPN bertahan selepas but semula? Cara mengesahkannya

But semula ialah cara paling biasa orang menguji suis mati, dan ia ialah ujian yang paling kerap berbohong. Kotak semak dalam klien hanyalah keutamaan; yang penting ialah sama ada sesuatu mengenakan sekatan antara saat tindanan rangkaian naik dan saat terowong benar-benar terbentuk. Pada Windows perkara itu biasanya penapis dalam Windows Filtering Platform, pada Linux set peraturan yang dimuatkan oleh unit, pada macOS sauh pf, pada Android bendera sistem sendiri untuk sentiasa-hidup dan kunci. Susunan ini berkelakuan sangat berbeza sepanjang but semula, dan hanya yang pada peringkat platform berada di tempatnya sebelum sesiapa boleh log masuk.

But semula mengemukakan tiga soalan berasingan

Bahagikan soalan itu. Pertama, adakah dasar itu wujud pada cakera dalam bentuk yang dibaca oleh sesuatu semasa but? Kedua, adakah pembaca itu berjalan sebelum sebarang trafik boleh keluar? Ketiga, adakah dasar itu meliputi trafik yang anda pedulikan, iaitu setiap proses, kedua-dua keluarga alamat dan DNS. Ya pada yang pertama dan tidak pada yang kedua menghasilkan tepat kegagalan yang dilaporkan orang sebagai suis mati yang tidak bertahan selepas but semula: trafik terlepas selama beberapa saat semasa permulaan, dan tiada siapa menyedarinya sehingga seseorang pergi memeriksa.

Asingkan lapisannya. Set peraturan tembakan dinding yang disimpan, perkhidmatan yang bermula semasa but dan keutamaan klien ialah tiga objek berbeza dengan tiga jangka hayat berbeza. Keutamaan bertahan selepas but semula kerana ia nilai dalam fail konfigurasi. Peraturan ialah satu-satunya perkara yang menyekat paket, dan ia hilang bersama kernel yang memegangnya.

Cari objek yang memulihkan sekatan

Pada Linux peraturan netfilter hidup dalam kernel. Tiada apa menulisnya semula semasa but kecuali anda mengaturnya: iptables-save tambah netfilter-persistent, nftables.service memuatkan /etc/nftables.conf, atau unit systemd yang menjalankan skrip anda sendiri. Periksa apa yang didayakan, bukan apa yang anda ingat telah dikonfigurasikan.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Set peraturan kosong beberapa saat selepas but ialah jawapan kepada soalan dalam tajuk. Pada Windows tanyakan perkhidmatan klien bagaimana ia bermula, kemudian buang keadaan penapis platform semasa terowong turun.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Perintah kedua menulis wfpstate.xml ke direktori semasa. Cari penapis dengan tindakan menyekat yang sudah wujud sebelum klien bersambung. Base Filtering Engine bermula awal semasa but dan memulihkan penapis yang ditambah dengan bendera berterusan, sebab itulah sesetengah suis mati menyekat trafik sebelum mana-mana tetingkap klien wujud dan yang lain tidak. Pada macOS sudo pfctl -s info melaporkan sama ada pf didayakan, sudo pfctl -s rules menunjukkan apa yang dimuatkan, dan klien VPN biasanya melampirkan peraturan mereka pada sauh dan bukan pada set utama. Peraturan yang menamakan utun3 boleh menunjuk ke antara muka lain selepas but seterusnya, kerana nombor itu diberikan semasa jalan.

Perhatikan jurang antara rangkaian naik dan terowong naik

Selang berbahaya bukan seluruh but semula, ia ialah jurang itu. Antara muka menerima pajakan dan laluan lalai pada satu ketika, perkhidmatan VPN bermula pada ketika lain, dan terowong mengesahkan lebih lewat lagi, kadang-kadang hanya selepas pengguna log masuk dan agen kelayakan berjalan. Jika sekatan dikenakan terakhir, semua yang ada dalam jurang keluar secara terbuka.

Pada hos systemd, baca susunannya dan bukan menekanya. Jalankan systemctl cat pada unit VPN dan tembakan dinding dan cari After= atau Before= terhadap network-pre.target dan network-online.target. Unit tembakan dinding yang disusun selepas network-online.target kalah kepada antara muka; yang diminta oleh dan disusun sebelum network-pre.target menang. Pada Windows soalan setara ialah jenis permulaan perkhidmatan dan kebergantungannya, kerana perkhidmatan yang ditetapkan kepada Manual tidak boleh menyekat proses semasa but. Jika keperluan anda merangkumi trafik sebelum log masuk, hanya susunan peringkat peranti yang memenuhinya: terowong peranti Always On VPN mengesahkan dengan sijil mesin dan bersambung sebelum pengguna log masuk, dan Microsoft mendokumenkan konfigurasi terowong peranti secara berasingan daripada terowong pengguna. Android mengambil jalan lain, menguatkuasakan VPN sentiasa-hidup dan menyekat sambungan tanpanya daripada sistem dan bukan daripada proses aplikasi.

Jalankan ujian, kemudian bandingkan dua garis masa

But semula dengan destinasi yang tidak merugikan jika ia bocor, dan tangkap keadaan semasa jurang dan bukan selepasnya. Kaedah paling bersih ialah prob semasa but: unit oneshot atau tugas berjadual yang bermula sedini yang dibenarkan platform, merekod laluan lalai dan keadaan tembakan dinding, mencuba satu permintaan dengan tamat masa pendek dan menambah satu baris pada fail setempat. Bandingkan rekod itu dengan masa mula perkhidmatan VPN daripada journalctl -b -u atau log Sistem.

Kemudian jalankan ujian biasa: terowong naik, putuskan sambungan, perhatikan sama ada trafik terus disekat, pulihkan. Lulus yang kedua dan gagal yang pertama ialah hasil biasa, dan ia bermakna penguatkuasaan berada di pihak klien, dikenakan apabila klien bersambung dan bukan semasa but. Pada mesin terakhir yang saya audit, sekatan datang daripada skrip penghantar NetworkManager: hadir dan betul dan tidak berguna untuk saat-saat sebelum antara muka naik. Tuliskan kedua-dua hasil, kerana bertahan selepas but semula hanya bermakna apabila anda menyatakan lapisan mana yang bertahan dan sejak bila.

Tutup jurang tanpa memutuskan jalan pulang anda

Jika sekatan tiada semasa but, turunkan penguatkuasaan satu lapisan dan bukan menambah peraturan klien kedua. Simpan set peraturan dan muatkannya daripada unit yang disusun sebelum rangkaian boleh digunakan, dan pastikan unit itu tidak memerlukan carian DNS atau lekap rangkaian yang sepatutnya dilindunginya. Skop sama pentingnya dengan masa: peraturan yang sepadan dengan ID pengguna atau cgroup membiarkan setiap daemon sistem di luar sekatan, dan set peraturan yang hanya mengendalikan IPv4 membiarkan IPv6 dan DNS boleh dicapai.

Tinggalkan jalan pulang untuk diri anda. Mesin yang menyekat segala-galanya semasa but dan kemudian tidak boleh mengesahkan tidak mempunyai rangkaian sama sekali, dan pembaikannya bukan memadam sekatan tetapi membaiki kelayakan atau susunannya. Kekalkan prosedur konsol setempat yang didokumenkan dan pengecualian sempit yang disengajakan untuk apa yang benar-benar diperlukan terowong, seperti alamat pelayan dan penyelesai yang digunakan sebelum terowong wujud.

Sebelum mempercayai susunan ini, sahkan empat perkara mengikut urutan. Dasar disimpan di tempat yang dibaca oleh but. Pembaca itu berjalan sebelum antara muka boleh digunakan. Sekatan meliputi kedua-dua keluarga alamat dan DNS. VPN masih boleh mengesahkan semasa sekatan aktif. Apabila keempat-empatnya dipenuhi, but semula tidak mengubah apa-apa.