Hoekom 'n kill switch verkeer laat val wanneer jy van bediener verander
Hoekom 'n kill switch verkeer tydens 'n bedienerwissel blokkeer, wat die kliënt in daardie tyd doen, en hoe om 'n normale pouse van 'n vasgehaakte blok te onderskei.
Jy kies 'n bediener wat nader lyk, klik op verbind, en die blaaier hou op laai voordat die nuwe tonnel oop is. Die ikoon flits na 'n verbindingstoestand en bly daar terwyl elke oortjie uitput. Daardie pouse is gewoonlik die kill switch wat werk soos ontwerp: verkeer word geblokkeer terwyl die kliënt geen tonnel het om dit deur te stuur nie. Of die pouse aanvaarbaar is, hang daarvan af wat die kliënt in daardie sekondes doen, en of die blok opgehef word wanneer dit sê dit is.
Wat die kliënt tussen twee bedieners doen
'n Eindpuntwissel is verskeie stappe, nie een skakelaar nie. Die kliënt breek die huidige tonnel af, werk sy blokreëls by, los die nuwe eindpunt op en bereik dit buite die tonnel, en installeer dan die nuwe roetes en hef die blok op. Die gaping wat jy voel, lê tussen die eerste stap en die laaste.
Orde is hier belangriker as spoed. As die blokreëls voor die uitsondering vir die nuwe eindpunt ingestel word, kan die kliënt nie die handdruk voltooi nie en bly dit op verbind tot 'n tydverstryking. As die uitsondering 'n kopie van die ou bediener se adres is, lyk die nuwe handdruk soos enige ander uitgaande pakket en word dit laat vaar. Albei gevalle lyk dieselfde in die blaaier, en daarom kan 'n wissel wat ná ses sekondes herstel en een wat nooit herstel nie, dieselfde oorsaak hê.
Die nuwe eindpunt het 'n gat in die blok nodig
Om die tonnel te bou, moet die kliënt pakkette na die nuwe bediener se adres en poort op die fisiese koppelvlak stuur, byvoorbeeld UDP 51820 vir 'n tipiese WireGuard-profiel of 1194 en 443 vir OpenVPN, wat jou eie profiel ook al spesifiseer. Daardie verkeer is nie binne die tonnel wat dit op die punt is om te skep nie, so 'n blok vir die hele toestel sluk dit tensy 'n ooreenstemmende toestemmingsreël bestaan.
Profiele op grond van gasheername voeg 'n tweede vereiste by: die opsoektog self. As die kliënt die eindpunt oplos voordat die blok opkom, kan dit 'n gekassie adres gebruik, maar sodra die profiel adresse roteer of die gekassie inskrywing verouder, mik die handdruk na 'n adres wat die toestemmingsreël nie dek nie. IPv6 maak dit sigbaar, want 'n dubbele-stapel-eindpunt kan beide 'n A- en 'n AAAA-rekord publiseer, en 'n toestemmingsreël wat net die v4-adres dek, laat die kliënt herprobeer teen 'n v6-adres wat geblokkeer is.
Opsiename en verstekwaardes verskil per kliënt en weergawe, so lees die gedokumenteerde lys vir joune eerder as om uit skermkiekies te raai. Die OpenVPN Connect-instellingverwysing by openvpn.net/connect-docs/app-settings-windows is een voorbeeld van hoe 'n kliënt sy blok- en split-tonnel-opsies beskryf.
Fail-closed is 'n toestandmasjien, nie 'n skakelaar nie
Die meeste kliënte druk die blok as firewallbeleid in drie toestande uit: tonnel op, met verkeer deur die tonnel en geen blok nie; tonnel af, met die blok aktief; en oorgang, met die blok aktief plus tydelike uitsonderings vir die eindpunt. Die derde toestand is waar foute woon, want dit moet twee keer binne 'n paar sekondes verander, en om dit nie te verlaat nie lyk presies soos 'n permanente blok.
Die meganisme verskil per platform, en die fout ook. Windows Filtering Platform-filters het gewigte, so 'n blokfilter wat jou toestemming oortref, hou aan om pakkette te laat vaar selfs al bestaan die toestemming, en filters wat deur 'n gedode kliëntproses agtergelaat is kan die masjien vanlyn hou nadat die app weg is. macOS-kliënte skryf gewoonlik pf-reëls in 'n anker, waar reëlorde en vinnige besluite bepaal watter reël geld. Linux-kliënte bestuur gewoonlik 'n nftables- of iptables-ketting met 'n drop-beleid en eksplisiete toestemmings vir die eindpunt, die tonnelkoppelvlak en loopback. Android se always-on VPN met die opsie om verbindings sonder VPN te blokkeer is die strengste van die groep, want die bedryfstelsel pas die blok op die hele toestel toe eerder as per app.
WireGuard het sy eie nota nodig, want AllowedIPs is 'n roetekieser, nie 'n blokkeerder nie. Dit bepaal watter bestemmings in die tonnel ingaan; dit doen niks om 'n pakket wat nog geen tonnel het, te keer om oor Wi-Fi uit te gaan nie. In 'n slegs-WireGuard-opstelling sonder firewallreël is die kill switch eintlik die afwesigheid van 'n roete, en 'n laat vaar handdruk kan gevolg word deur 'n werklike pakket wat oor die fisiese koppelvlak uitgaan.
Meet die gaping eerder as om die ikoon dop te hou
Hou pakkette dop, nie die statuslig nie. Op Linux begin jy 'n stadige ping teen 'n publieke adres in een terminaal en vang die tonnel se vervoerpoort op die fisiese koppelvlak in 'n ander:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Wissel bedieners in die kliënt terwyl albei loop. Drie dinge maak saak: hoe lank die pings stop, of die opname wys die handdruk bereik die nuwe eindpunt, en of verkeer hervat voor of nadat die kliënt se toestand na verbind verander. As die ping-gaping eerste eindig, is die blok óf vroeg opgehef óf die tonnel is op voordat die aanwyser dit erken. As die gaping later eindig, is die aanwyser optimisties.
Op Windows skryf netsh wfp show state 'n momentopname wat jy kan deursoek vir blokfilters wat nog daar is terwyl die kliënt beweer hy is ontkoppel. Op macOS lys sudo pfctl -sr die gelaaide reëls en hulle orde. Paar enige momentopname met die kliënt se eie log; die tydlyn uit jou ping sê of die blok laat geëindig het of nooit nie.
Normale onderbreking teenoor 'n vasgehaakte blok
Sommige onderbreking is die punt van die funksie, so triageer voordat jy enige instelling verander:
| 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 |
As jy in die tweede of vyfde ry beland, moenie die kill switch deaktiveer om te toets nie, want dit verander 'n roetefout in 'n lek. Herbegin die kliënt se diens, of herbegin die rekenaar waar filters 'n prosesdoding oorleef, en kyk dan of die blok opklaar. As dit wel, is die fout opruiming tydens die wissel eerder as die blok self.
Voordat jy volgende keer wissel, bevestig vier dinge: die eindpunttoestemming dek elke adresfamilie waarna jou profiel oplos, die kliëntlog wys die oorgang voltooi, jou pingtoets meet die gaping eerder as die ikoon, en om die kliënt te sluit herstel normale verbinding. 'n Kill switch wat tydens die wissel hou en daarna loslaat, doen sy werk. Een wat vroeg loslaat, of nooit nie, is werd om te ontfout.