Du vælger en server, der ser tættere på ud, trykker på forbind, og browseren holder op med at indlæse, før den nye tunnel er oppe. Ikonet skifter til en forbinder-tilstand og bliver der, mens hver fane løber ud i tid. Den pause er som regel kill switchen, der virker efter hensigten: trafikken er blokeret, mens klienten ikke har nogen tunnel at sende den gennem. Om pausen er acceptabel afhænger af, hvad klienten gør i de sekunder, og om blokeringen løftes, når den siger, den gør.

Hvad klienten gør mellem to servere

Et skift af endpoint er flere trin, ikke en enkelt kontakt. Klienten river den nuværende tunnel ned, opdaterer sine blokeringsregler, slår det nye endpoint op og når det uden for tunnelen, og installerer derefter de nye ruter og løfter blokeringen. Det hul, du mærker, ligger mellem det første og det sidste trin.

Rækkefølgen betyder mere end hastigheden her. Hvis blokeringsreglerne sættes ind før undtagelsen for det nye endpoint, kan klienten ikke fuldføre håndtrykket og bliver på forbinder, indtil der opstår timeout. Hvis undtagelsen er en kopi af den gamle servers adresse, ser det nye håndtryk ud som enhver anden udgående pakke og bliver droppet. Begge tilfælde ser ens ud fra browseren, og derfor kan et skift, der kommer sig efter seks sekunder, og et, der aldrig kommer sig, dele samme årsag.

Det nye endpoint skal have et hul i blokeringen

For at bygge tunnelen skal klienten sende pakker til den nye servers adresse og port på det fysiske interface, for eksempel UDP 51820 til en typisk WireGuard-profil eller 1194 og 443 til OpenVPN, uanset hvad din egen profil angiver. Den trafik er ikke inde i den tunnel, der er ved at blive oprettet, så en blokering for hele enheden sluger den, medmindre der findes en tilsvarende tilladelsesregel.

Profiler baseret på værtsnavn tilføjer et andet krav: selve opslaget. Hvis klienten slår endpointet op, før blokeringen rejses, kan den bruge en cachet adresse, men når profilen skifter adresser, eller den cachede post bliver forældet, går håndtrykket mod en adresse, som tilladelsesreglen ikke dækker. IPv6 gør det synligt, fordi et endpoint med dobbelt stak kan udgive både en A- og en AAAA-post, og en tilladelsesregel, der kun dækker v4-adressen, efterlader klienten med at prøve igen mod en v6-adresse, der er blokeret.

Navne på indstillinger og standardværdier varierer efter klient og version, så læs den dokumenterede liste for din i stedet for at gætte ud fra skærmbilleder. OpenVPN Connect-opslagsværket på openvpn.net/connect-docs/app-settings-windows er et eksempel på, hvordan en klient beskriver sine blokerings- og split-tunnelindstillinger.

Fail-closed er en tilstandsmaskine, ikke en kontakt

De fleste klienter udtrykker blokeringen som firewallpolitik i tre tilstande: tunnel oppe, hvor trafikken går gennem tunnelen og ingen blokering er aktiv; tunnel nede, hvor blokeringen er aktiv; og overgang, hvor blokeringen er aktiv plus midlertidige undtagelser for endpointet. Det er i den tredje tilstand, fejlene bor, fordi den skal skifte to gange inden for et par sekunder, og en manglende udgang fra den ser præcis ud som en permanent blokering.

Mekanismen varierer efter platform, og fejlen gør også. Windows Filtering Platform-filtre har vægte, så et blokeringsfilter, der overgår din tilladelse, bliver ved med at droppe pakker, selv om tilladelsen findes, og filtre, som en dræbt klientproces har efterladt kan holde maskinen offline, efter at appen er væk. macOS-klienter skriver normalt pf-regler i et anker, hvor regelrækkefølge og hurtige beslutninger afgør, hvilken regel der gælder. Linux-klienter styrer normalt en nftables- eller iptables-kæde med drop-politik og udtrykkelige tilladelser for endpointet, tunnelinterfacet og loopback. Androids always-on VPN med muligheden for at blokere forbindelser uden VPN er den strengeste i gruppen, fordi styresystemet anvender blokeringen på hele enheden i stedet for per app.

WireGuard skal have sin egen note, fordi AllowedIPs er en rutevælger, ikke en blokering. Den afgør, hvilke destinationer der går i tunnelen; den gør intet for at forhindre en pakke uden tunnel i at forlade maskinen over Wi-Fi. I et setup med kun WireGuard og ingen firewallregel er kill switchen i virkeligheden fraværet af en rute, og efter et droppet håndtryk kan en rigtig pakke forlade det fysiske interface.

Mål hullet i stedet for at kigge på ikonet

Hold øje med pakker, ikke statuslyset. På Linux starter du en langsom ping mod en offentlig adresse i en terminal og fanger tunnelens transportport på det fysiske interface i en anden:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Skift server i klienten, mens begge kører. Tre ting betyder noget: hvor længe pingerne stopper, om optagelsen viser håndtrykket nå det nye endpoint, og om trafikken vender tilbage før eller efter klientens tilstand skifter til forbundet. Hvis ping-hullet slutter først, er blokeringen enten løftet for tidligt, eller tunnelen er oppe, før indikatoren indrømmer det. Hvis hullet slutter senere, er indikatoren optimistisk.

På Windows skriver netsh wfp show state et øjebliksbillede, du kan søge efter blokeringsfiltre i, som stadig findes, mens klienten hævder at være afbrudt. På macOS viser sudo pfctl -sr de indlæste regler og deres rækkefølge. Sæt et af øjebliksbillederne sammen med klientens egen log; tidslinjen fra din ping fortæller, om blokeringen sluttede sent eller aldrig.

Normal blackout kontra en fastlåst blokering

Lidt afbrydelse er hele pointen med funktionen, så lav en vurdering, før du ændrer nogen indstilling:

What you seeUsually meansNext check
Two or three seconds of timeouts, then normal browsingExpected fail-closed gapNothing to fix
State says connected, traffic stays deadBlock filter or route left behindFirewall snapshot, client log
One app dead while others workTCP session bound to the old exit addressRestart the app
LAN devices unreachable after the switchLAN exception not reappliedAllow-LAN or split-tunnel setting
New server hangs, the old one reconnectsPermit covers only the old addressResolved address of the new host, including AAAA

Hvis du lander i anden eller femte række, skal du ikke slå kill switchen fra for at teste, for det gør en rutebug til et læk. Genstart klientens tjeneste, eller genstart maskinen, hvor filtre overlever et dræbt process, og se så, om blokeringen forsvinder. Gør den det, ligger fejlen i oprydningen under skiftet og ikke i blokeringen selv.

Før dit næste skift skal du bekræfte fire ting: endpoint-tilladelsen dækker hver adressefamilie, din profil slår op, klientloggen viser, at overgangen fuldføres, din ping-test måler hullet i stedet for ikonet, og lukning af klienten genskaber normal forbindelse. En kill switch, der holder under skiftet og slipper bagefter, gør sit arbejde. En, der slipper tidligt eller aldrig, er værd at fejlfinde.

Relaterede artikler