VPN-killbrytar: kva trafikk han blokkerer, og når
Gjenoppkopling gjenopprettar ein tunnel; ein killbrytar avgjer kva som skjer medan han er borte. Test tap, manuell fråkopling, app-avslutning og nettverksbytte kvar for seg.
To funksjonar blir skrivne om med same ordet og gjer ulike arbeid. Automatisk gjenoppkopling prøver å få tunnelen tilbake, og det kan lukkast innan eit sekund medan førespurnader feilar i mellomtida. Ein killbrytar avgjer kva som skjer med trafikken i det tidsrommet. Å lese ein klient som om dei to var éin innstilling er korleis folk endar med å stole på eit ikon i staden for ein policy.
Blokkering og gjenoppkopling er to separate avgjerder
Éin klient blokkerer berre når tapet er uventa, koplar deretter til att og opphevar blokkeringa. Ein annan held ei blokkering på systemnivå til nokon endrar ei innstilling manuelt, og ein tredje ser ei medvite fråkopling som løyve til å gjenopprette vanleg tilgang. Det er tre ulike åtferder, og dokumentasjonen til leverandøren seier kva for ein bygget ditt implementerer.
Import av ein profil avgjer ingenting i det spørsmålet. Same tenarprofil blir lasta inn i to klientar med motsett blokkeringsåtferd, fordi profilen ber innstillingar og ikkje eit løfte. Difor kan òg ein avkrysningsboks på skrivebordet og ein brytar på mobilen med liknande etikettar implementere ulike reglar. Les skildringa ved kontrollen på plattformen din, og test deretter kva han gjer.
Same profil oppfører seg ulikt i to klientar
Innstillingane i OpenVPN Connect-appen skildrar ein tunneltilstand som held vanleg trafikk tilbake berre medan klienten rapporterer ein pausa eller gjenoppkoplande tilstand, noko som er smalare enn eit generelt løfte om kvar hending på kvar plattform. Les tilstandane som er lista opp, ikkje produktnamnet. Ei skildring skriven for éin klientversjon blir ikkje overført til klienten til ein annan leverandør.
Android viser same ordet for to kontrollar, fordi alltid-på VPN og blokkering av tilkoplingar utan VPN blir dokumentert kvar for seg. Ein skrivebordsklient med ein liknande avkrysningsboks kan implementere noko smalare eller breiare enn nokon av dei. Handsame ein felles etikett i to menyar som ein tilfeldigheit til begge skildringane er lesne. Administrerte einingar legg til eit tredje lag, fordi ein einingsprofil kan handsame ei innstilling brukaren ikkje ser eller kan overstyre.
Plattforminnstillingar som ser like ut, er ikkje likeverdige
Samanlikn kontrollen du ser, med policyen som faktisk gjeld. På ei administrert eining kan den synlege brytaren vere grå, eller han kan vere slått på medan ein profil på høgare nivå handsamar det motsette. Be om den effektive policyen i staden for den lokale, og få svaret skriftleg.
Skriv ned kva kvart lag hevdar før du testar noko, fordi dei to ofte er usamde og usemja er lett å miste når testane byrjar. Ei eining som blokkerer rett under ein test, blokkerer kanskje av ein grunn ingen har dokumentert.
Køyr éi hending om gongen og noter koden
Test éi hending per køyring, med ein ufarleg førespurnad, og gjer kvart forsøk til ein ny førespurnad i staden for ei side som kanskje alt ligg i hurtigbufferen. Kommandoane nedanfor tek tunnelen ned, ber om ei side og viser om grensesnittet kom tilbake.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0
Tabellen knyter kvar handling til observasjonen som betyr noko og til beviset som er verdt å ta vare på. Ein førespurnad som feilar innan tidsgrensa, fortel at blokkeringa slo inn; ein førespurnad som går gjennom, fortel at trafikken fann ein annan veg, som kan vere ei utelaten rute og ikkje ei deaktivert blokkering. Gjer heile settet om att etter ei vesentleg programvareoppdatering eller endring i rutepolicyen, fordi begge kan endre greina utan at noka synleg innstilling flyttar seg. Til slutt vil du ha føreseieleg feilåtferd, ikkje eit beroligande ikon.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Unntak, gjesteportalar og kva ei blokkering ikkje kan
Tilgang til det lokale nettverket er det vanlege unntaket, og det endrar omfanget av løftet. Ein klient kan nå ein skrivar på same subnett medan han blokkerer alt anna, noko som er rimeleg heime og tvilsamt på eit gjestenettverk. Bestem om du vil ha det unntaket før ei hending oppdagar det for deg.
Ei streng blokkering gjer òg innlogging på ein gjesteportal tungvint, fordi portalen nettopp er den direkte trafikken blokkeringa finst for å stoppe. Lær den støtta måten å autorisere nettverket på, og gjenopprett deretter policyen medvite i staden for å slå av kontrollar til ei side blir lasta. Hald svaret frå resolvaren og rutetabellen i same notatet, som nedanfor. Det ein killbrytar ikkje kan, er å gjere tenesta anonym, fordi blokkering av trafikk utanfor tunnelen ikkje seier noko om kva som skjer inni han.
resolvectl query example.com
ss -tunp | grep -v tun0