Always-on VPN vs kill switch: yang mana sebenarnya anda hidupkan?

Always-on dan kill switch terletak dua baris antara satu sama lain pada skrin tetapan yang sama, jadi orang membacanya sebagai dua nama untuk satu ciri. Ia bukan begitu. Always-on ialah dasar sambung semula: mulakan tunnel semasa boot, bawa ia kembali selepas ranap atau perubahan rangkaian, dan terus cuba selagi ia gagal. Kill switch ialah dasar trafik: ia menamakan paket yang masih boleh meninggalkan mesin semasa tunnel turun. Anda boleh hidupkan yang pertama tanpa yang kedua, dan pada kebanyakan platform hasil lalai masih membenarkan trafik keluar dalam selang itu.

Semakan 1: adakah sekatan itu suis tersendiri?

Pada Android 10 dan lebih baru, profil VPN yang disimpan membuka dua togol bebas di belakang ikon gear: Always-on VPN dan Block connections without VPN. Hanya yang kedua ialah kill switch. Dengan always-on sahaja, tunnel memang kembali selepas terputus, dan mana-mana aplikasi yang sedang membuat permintaan boleh mencapai rangkaian melalui Wi-Fi atau data mudah alih sehingga itu berlaku.

Peranti terurus mengekalkan pemisahan yang sama dalam API dasar. setAlwaysOnVpnPackage() mengambil nama pakej dan bendera lockdownEnabled; pentadbir yang menetapkan pakej dan membiarkan bendera itu false telah membina tunnel berterusan, bukan peranti tertutup. Kata-kata dalam konsol jarang menjadikan perbezaan itu kelihatan.

Baca keadaan dari peranti, bukan dari konsol: adb shell settings get global always_on_vpn_app dan adb shell settings get global always_on_vpn_lockdown. Jika yang pertama mengembalikan null, tiada pakej dikuatkuasakan pada peringkat platform; jika yang kedua mengembalikan 0, platform tidak menyekat apa-apa. Panduan VPN Android mendokumentasikannya sebagai keupayaan berasingan, bukan satu mod.

Semakan 2: lapisan mana yang memiliki sekatan itu?

Label tinggal dalam klien dan sekatan biasanya dalam firewall, sebab itulah perkataan yang sama bermaksud lain pada setiap platform. Baris di bawah ialah yang wajar dipastikan sebelum anda mempercayai mana-mana daripadanya.

Windows ialah contoh paling jelas bagi label yang tidak menyekat. Di sana Always On menerangkan ketekalan tunnel: tunnel peranti untuk pengesahan mesin dan tunnel pengguna untuk akaun yang log masuk, dikonfigurasikan melalui XML profil atau Add-VpnConnection. Tiada apa-apa dalam profil itu yang menghentikan paket keluar apabila tunnel tiada, dan penapisan keluar tidak dihidupkan secara lalai, jadi komputer riba di Wi-Fi terus berfungsi semasa VPN turun.

WireGuard berpecah dengan cara yang sama, tetapi mengikut klien. WireGuard for Windows mempunyai pilihan Block untunneled traffic bagi setiap tunnel yang memasang peraturan penapis; alat Linux tiada suis seumpamanya. wg-quick menambah laluan bagi setiap entri AllowedIPs serta peraturan fwmark, dan wg-quick down membuang kedua-duanya, jadi laluan lalai fizikal mengambil alih semula tanpa satu paket pun tercicir.

Pada platform Apple, always-on datang sebagai ciri profil pengurusan untuk peranti yang diselia dan dinyatakan sebagai peraturan on-demand, bukan kotak semak. Soalan yang perlu dijawab daripada muatan ialah sama ada tunnel yang gagal menolak trafik atau hanya meminta sambungan lain. Tajuk menu tidak akan memberitahu anda.

Semakan 3: ukur jurangnya, bukan ikonnya

Empat peralihan penting, dan semuanya gagal dengan cara berbeza: boot sebelum sesiapa log masuk, tidur dan bangun, perubahan daripada Wi-Fi ke data mudah alih, dan ranap klien yang meninggalkan antara muka tunnel separuh dikonfigurasikan. Sambungan semula yang bersih pada salah satunya tidak membuktikan apa-apa tentang tiga yang lain.

Ujian paling murah menghentikan tunnel dengan sengaja dan kemudian cuba keluar. Semasa tunnel turun, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com yang mengembalikan 200 bermakna dasar itu fail-open; tamat masa atau sambungan ditolak bermakna sesuatu masih menyekat. ip route get 1.1.1.1 menamakan antara muka yang akan membawa paket, yang biasanya lebih bermaklumat daripada ikon trei, dan systemctl status wg-quick@wg0 menunjukkan sama ada antara muka dibuang dengan bersih.

Jalankan semakan yang sama di tetingkap kedua semasa rangkaian berubah, bukan hanya selepas ia stabil. Selang antara kejatuhan dan cubaan semula ialah bahagian yang penting, dan penyelesaian nama ialah cara terpantas untuk menyedari trafik terlepas: jika penyelesai setempat menjawab semasa tunnel turun, sekatan itu tidak lengkap.

Semakan 4: tentukan pengecualian sebelum anda mengunci

Dua pengecualian bersifat struktur. Klien mesti mencapai pelayan VPN itu sendiri, jadi set peraturan yang menjatuhkan segalanya turut menghalang sambungan semula yang akan memulihkan perlindungan. Portal tawanan juga tidak dapat dicapai melalui tunnel yang belum naik, jadi peranti terkunci di Wi-Fi hotel memerlukan cara berdokumentasi untuk membuka portal, bukan cara improvisasi.

Bentuk minimum, titik akhir dibenarkan dan semua yang lain dijatuhkan:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Anggap baris titik akhir itu sebagai pemboleh ubah, bukan pemalar. Penyedia menukar alamat, dan pengecualian yang lapuk ialah sebab biasa kill switch yang berfungsi bertukar menjadi peranti yang tidak boleh menyambung semula. Pencetak setempat, perkongsian NAS dan perkhidmatan pembangunan tergolong dalam senarai bertulis yang sama, jika tidak ia ditemui satu tiket sokongan demi satu.

Semakan 5: catat apa yang sebenarnya anda buktikan

Simpan jadual empat lajur dan isikannya dengan ujian: keadaan, tingkah laku dijangka, tingkah laku diperhatikan, bukti. Baris ialah peralihan daripada semakan 3 serta satu kegagalan yang disengajakan. Baris yang tidak dapat anda isi dengan output arahan ialah baris yang belum diuji, dan peranti yang lulus baris sambung semula tetapi gagal pada baris boot cukup biasa sehingga sepuluh minit tambahan itu berbaloi.

Sebelum anda menyebutnya selesai:

• Pastikan tetapan penyekatan berasingan daripada tetapan sambung semula, dan baca nilainya pada peranti.
• Ketahui lapisan mana yang menguatkuasakan sekatan - pilihan klien, dasar peranti atau firewall - dan di mana lapisan itu dikonfigurasikan.
• Simpan satu arahan semakan yang membuktikan sekatan, dan jalankannya semasa peralihan, bukan selepasnya.
• Tulis senarai pengecualian, termasuk titik akhir, dan catat siapa yang menyegarkannya.
• Pada perkakasan terurus, biarkan dasar yang dikuatkuasakan; membuang sekatan mengubah keperluan, bukan membaiki tunnel.