Kial kill switch faligas trafikon kiam vi ŝanĝas servilon
Kial kill switch blokas trafikon dum servila ŝanĝo, kion la kliento faras en tiu fenestro, kaj kiel distingi normalan paŭzon de fiksiĝinta blokado.
Vi elektas servilon, kiu aspektas pli proksima, premu la butonon konekti, kaj la retumilo ĉesas ŝargi antaŭ ol la nova tunelo supreniĝos. La ikono ŝanĝiĝas al konektanta stato kaj restas tie, dum ĉiu langeto elĉerpiĝas per tempolimo. Tiu paŭzo kutime estas la kill switch laboranta laŭplane: la trafiko estas blokata dum la kliento havas neniun tunelon por sendi ĝin. Ĉu la paŭzo estas akceptebla dependas de tio, kion la kliento faras en tiuj sekundoj, kaj de tio, ĉu la blokado leviĝas kiam ĝi diras, ke ĝi leviĝis.
Kion la kliento faras inter du serviloj
Servila ŝanĝo estas pluraj paŝoj, ne unu ŝaltilo. La kliento malkonstruas la nunan tunelon, ĝisdatigas siajn blokajn regulojn, solvas kaj atingas la novan finpunkton ekster la tunelo, poste instalas la novajn vojojn kaj levas la blokadon. La breĉo, kiun vi sentas, kuŝas inter la unua kaj la lasta paŝo.
Ordo ĉi tie gravas pli ol rapideco. Se la blokaj reguloj ekvalidas antaŭ la escepto por la nova finpunkto, la kliento ne povas fini la manpremon kaj restas ĉe konektado ĝis tempolimo. Se la escepto estas kopio de la adreso de la malnova servilo, la nova manpremo aspektas kiel iu ajn alia elira pako kaj estas forĵetata. Ambaŭ kazoj aspektas identaj el la retumilo, kaj tial ŝanĝo, kiu resaniĝas post ses sekundoj, kaj unu, kiu neniam resaniĝas, povas havi la saman kaŭzon.
La nova finpunkto bezonas truon en la blokado
Por konstrui la tunelon, la kliento devas sendi pakojn al la adreso kaj pordo de la nova servilo sur la fizika interfaco, ekzemple UDP 51820 por tipa WireGuard-profio aŭ 1194 kaj 443 por OpenVPN, kion ajn via propra profio specifas. Tiu trafiko ne estas ene de la tunelo, kiun ĝi ĵus kreos, do blokado por la tuta aparato glutas ĝin, se ne ekzistas kongrua permesa regulo.
Hostnomaj profioj aldonas duan postulon: la serĉo mem. Se la kliento solvas la finpunkton antaŭ ol la blokado leviĝas, ĝi povas uzi konservitan adreson, sed kiam la profio rotacias adresojn aŭ la konservita rikordo malnoviĝas, la manpremo celas adreson, kiun la permesa regulo ne kovras. IPv6 igas tion videbla, ĉar dunivela finpunkto povas publikigi kaj A-rikordon kaj AAAA-rikordon, kaj permesa regulo kovranta nur la adreson v4 lasas la klienton reprovi kontraŭ blokita adreso v6.
Opcioj nomoj kaj defaŭltoj malsamas laŭ kliento kaj versio, do legu la dokumentitan liston por via anstataŭ diveni el ekrankopioj. La agorda referenco de OpenVPN Connect ĉe openvpn.net/connect-docs/app-settings-windows estas unu ekzemplo pri tio, kiel kliento priskribas siajn blokajn kaj disigitan-tunelajn opciojn.
Fail-closed estas statmaŝino, ne ŝaltilo
Plej multaj klientoj esprimas la blokadon kiel fajroŝirma politiko en tri statoj: tunelo supren, kun trafiko tra la tunelo kaj neniu blokado; tunelo malsupren, kun la blokado aktiva; kaj transiro, kun la blokado aktiva plus portempaj esceptoj por la finpunkto. En la tria stato loĝas la cimoj, ĉar ĝi devas ŝanĝiĝi dufoje ene de kelkaj sekundoj, kaj malsukceso eliri el ĝi aspektas precize kiel daŭra blokado.
La mekanismo malsamas laŭ platformo, kaj same la fiasko. Filtriloj de Windows Filtering Platform portas pezojn, do bloka filtrilo, kiu superas vian permeson, daŭre forĵetas pakojn eĉ se la permeso ekzistas, kaj filtriloj lasitaj de mortigita klienta procezo povas teni la maŝinon senkonekta post kiam la aplikaĵo malaperis. macOS-klientoj kutime skribas pf-regulojn en ankron, kie regula ordo kaj rapidaj decidoj difinas, kiu regulo validas. Linux-klientoj kutime administras ĉenon nftables aŭ iptables kun drop-politiko kaj eksplicitaj permesoj por la finpunkto, la tunela interfaco kaj loopback. La always-on VPN de Android kun la opcio bloki konektojn sen VPN estas la plej strikta de la grupo, ĉar la operaciumo aplikas la blokadon al la tuta aparato anstataŭ po aplikaĵo.
WireGuard bezonas propran noton, ĉar AllowedIPs estas voj-elektilo, ne blokilo. Ĝi decidas, kiuj celoj iras en la tunelon; ĝi faras nenion por malhelpi pakon sen tunelo eliri tra Wi-Fi. En agordo nur kun WireGuard kaj sen fajroŝirma regulo, la kill switch estas fakte la manko de vojo, kaj post forĵetita manpremo povas sekvi reala pako eliranta tra la fizika interfaco.
Mezuru la breĉon anstataŭ rigardi la ikonon
Observu pakojn, ne la statlampon. En Linux komencu malrapidan ping al publika adreso en unu terminalo kaj kaptu la transportan pordon de la tunelo sur la fizika interfaco en alia:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Ŝanĝu servilojn en la kliento dum ambaŭ funkcias. Tri aferoj gravas: kiom longe la pingoj haltas, ĉu la kaptaĵo montras la manpremon atinganta la novan finpunkton, kaj ĉu trafiko revenas antaŭ aŭ post kiam la stato de la kliento ŝanĝiĝas al konektita. Se la ping-breĉo finiĝas unue, aŭ la blokado leviĝis frue, aŭ la tunelo estas supre antaŭ ol la indikilo konfesas tion. Se la breĉo finiĝas pli malfrue, la indikilo estas tro optimisma.
En Windows, netsh wfp show state skribas momentan bildon, en kiu vi povas serĉi blokajn filtrilojn ankoraŭ ĉeestajn dum la kliento asertas esti malkonektita. En macOS, sudo pfctl -sr listigas la ŝargitajn regulojn kaj ilian ordon. Kunmetu iun ajn momentan bildon kun la propra protokolo de la kliento; la templinio el via ping diras al vi, ĉu la blokado finiĝis malfrue aŭ neniam.
Normala mallumo kontraŭ fiksiĝinta blokado
Iom da interrompo estas la celo de la funkcio, do trivu antaŭ ol vi ŝanĝi ajnan agordon:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Se vi alteriĝas en la dua aŭ kvina vico, ne malŝaltu la kill switch por testi, ĉar tio igas voj-eraron liko. Restartigu la servon de la kliento, aŭ restartigu la maŝinon kie filtriloj postvivas procezan mortigadon, poste vidu, ĉu la blokado forviŝiĝas. Se ĝi forviŝiĝas, la fuŝo estas en la purigado dum la ŝanĝo, ne en la blokado mem.
Antaŭ via sekva ŝanĝo, konfirmu kvar aferojn: la permeso por la finpunkto kovras ĉiun adresan familion, kiun via profio solvas, la klienta protokolo montras kompletigitan transiron, via ping-testo mezuras la breĉon anstataŭ la ikonon, kaj fermo de la kliento restarigas normalan konektecon. Kill switch, kiu tenas dum la ŝanĝo kaj poste ellasas, faras sian laboron. Unu, kiu ellasas frue aŭ neniam, indas sencimigadon.