Kan et nettverk blokkere VPN-en din uten å bryte krypteringen?
Kryptering beskytter innholdet, ikke leveringen. Sammenlign blokkeringslister, tillatelseslister og nedstengninger, og spør deretter hva én enkelt observasjon egentlig kan underbygge.
Ingen operatør trenger en sesjonsnøkkel for å stoppe en tunnel: forkast pakkene på stien, og den feiler, mens kryptografien forblir nøyaktig så sterk som designet lovet. Kryptering beskytter det en samtale bærer, ikke viljen i et gitt nettverk til å bære det. Å skille disse to egenskapene gjør en diskusjon om ublokkerbarhet til et spørsmål om hvilken policy som gjelder, og hvor langt den rekker. Sammenligningen nedenfor holder tilgjengelighet og konfidensialitet fra hverandre, fordi de fleste selvsikre påstander om VPN-blokkering stille smelter dem sammen.
Tilgjengelighet er en beslutning stien tar
Hver transport avhenger av en sti som videresender pakker, og hvert policyspørsmål her reduseres til den videresendelsesbeslutningen. En regel som forkaster pakker, endrer tilgjengeligheten uten å røre konfidensialiteten, og det er slik en tunnel kan være ulastelig kryptert og fullstendig ubrukelig i samme øyeblikk. Ingenting ved det utfallet krever å bryte en chiffre eller gjenopprette en nøkkel. Det krever bare kontroll over stien.
Forvirring starter vanligvis med at to egenskaper deler ett ord. Sterk kryptografi handler om hvem som kan lese en strøm; den sier ingenting om hvorvidt en mellomliggende boks slipper den gjennom. Påstanden om at en VPN ikke kan blokkeres trenger derfor en annen påstand under seg, nemlig at ingen på stien er villig til å forkaste pakkene.
Håndhevingsstiler og prisen for hver
Tre stiler dekker de fleste virkelige policyer, og de skiller seg i hva de må vite, hva de koster å drive og hvem andre som lider. Hver av dem kan avvise en tunnel uten å dekryptere noe. Forskjellene betyr noe fordi det samme ordet, blokkering, brukes om alle tre.
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
Den tabellen er et kostnadskart, ikke en rangering. En blokkeringsliste er billig å starte og dyr å holde nøyaktig; en tillatelsesliste bytter oppdagelse mot vedlikehold av det tillatte settet, og en nedstengning trenger ingen klassifisering i det hele tatt. Det som skiller dem, er ikke teknisk raffinement, men hvor hver av dem legger den løpende innsatsen. En policy som ser enkel ut på papiret, har som regel en skjult vedlikeholdspost et annet sted.
En blokkeringsliste begrenses av hvor godt en adresse navngir en tjeneste
En blokkeringsliste avviser destinasjoner som allerede er identifisert, og lar resten være generelt tilgjengelig. Å håndheve den krever adresser og porter, ikke klartekst, og det er det som gjør den billig å drive i starten. Kostnaden kommer senere, fordi et område som en gang identifiserte én leverandør, kan ende med å huse et dusin uvedkommende leietakere. Hver adresseendring tvinger en listenedring, og hver foreldet oppføring tar uskyldig trafikk med seg.
Presisjon er på denne modellen begrenset av hvor godt en destinasjon identifiserer en tjeneste, og et travelt delt endepunkt er en dårlig identifikator. Det er en strukturell grense og ikke en implementeringsfeil, så bedre verktøy fjerner den ikke. Det forklarer også hvorfor blokkeringslister har en tendens til å vokse: hvert nytt endepunkt ser ut som et lite tillegg, og følgeskadene vokser med listen.
En tillatelsesliste flytter vedlikeholdsbyrden
En tillatelsesliste snur standarden, slik at bare de forhåndsvalgte destinasjonene eller trafikktypene kan passere. Den trenger ikke å ramse opp hvert forbudt endepunkt, noe som hjelper når det forbudte settet er stort eller endrer seg raskt. Det den trenger i stedet, er en vedlikeholdt definisjon av hva som er tillatt, pluss håndheving som passer til den definisjonen.
Portnumre er det vanlige svake punktet i en slik definisjon. Å tillate en port er ikke det samme som å identifisere hver applikasjon som kan bruke den, så en portbasert tillatelsesliste slipper ofte gjennom mer enn forfatteren hadde tenkt. Protokollfingeravtrykk har samme problem fra en annen vinkel, fordi de identifiserer en form for trafikk og ikke en hensikt. En tillatelsesliste er derfor ikke automatisk mer presis enn en blokkeringsliste; den er presis om noe annet.
Hva én enkelt observasjon kan og ikke kan underbygge
Enhver påstand om blokkering bør leses med fire spørsmål ved hånden: hvilke tilgangsnettverk, hvilke destinasjoner, hvilke protokoller og hvilken observasjonsperiode. En feil som ses i dag på ett mobilnett, sier ingenting om samme endepunkt i morgen fra et annet nett. En tunnel som virket én gang, sier heller ingenting om vedvarende tilgjengelighet.
Formen på en feil kan observeres før du teoretiserer om årsaken. Et stille heng, en øyeblikkelig avvisning og en tilbakestilling etter tilkobling peker på ulike håndhevingsstiler, og to kommandoer skiller dem:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comEt heng som ender i en tidsavbrudd, tyder på stille forkasting, en rask avvisning tyder på en avvisende enhet på stien, og en tilbakestilling etter tilkobling tyder på tilstandsbasert innblanding fremfor en manglende rute. RFC 9505-undersøkelsen av sensurteknikker beskriver kontrollpunktene og innblandingsmønstrene bak disse formene. Ingen av dem forteller imidlertid hvor bredt policyen gjelder. Varighet er en sterkere påstand enn tilgjengelighet: endepunkter, programvare, policyer og tillatte tjenester endrer seg alle, så ubestemt effektivitet krever antakelser om fortsatt håndheving og ikke en liste over adresser sett på ett tidspunkt.