VPN-utgangs-IP er ikke bevis for en tunnel: hva servere ser

Noen ber om en tjeneste som bare VPN-brukere kan nå, og den åpenbare implementasjonen er å tillate en liste over utgangsadresser. Listen gjør noe reelt: den begrenser hvem som kan koble til. Den beviser ikke at en tunnel ble brukt, fordi adressen tilhører den som driver utgangen, og den operatøren kan videresende alles trafikk. Gapet mellom disse utsagnene er hele designproblemet.

Serveren ser én adresse per tilkobling

En tilkobling kommer med en kildeadresse og en destinasjonsport, og det er alt nettverkslaget rapporterer. Når en klient bruker en tunnel, kommer pakkene som når lytteren din, fra utgangen eller fra oversettelsen foran den. Klientens egen adresse, vanligvis privat, vises aldri. En brannmurregel skrevet for klientens LAN-område gjør derfor ingenting.

Alt etter den kildeadressen er applikasjonsdata, og applikasjonen kan bare stole på dem i den grad den autentiserer dem.

Test hvordan utgangen din ser ut

Se på veien fra begge ender før du skriver en regel. Klientens syn på sin utgang og serverens syn på tilkoblingen er de to faktaene som betyr noe.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Den første kommandoen rapporterer den offentlige adressen klienten fremstår som, og det er verdien enhver tillatelsesliste må inneholde. Den andre viser etablerte tilkoblinger på serveren med peer-adressene deres, og det er det regelen faktisk vil matche. Hvis de to ikke stemmer med din mentale modell, rett modellen før du redigerer policyen. En brannmur for en skydatabase, en tillatelsesliste for en applikasjon og en lastbalanserer kan hver for seg se et ulikt oversettelseslag.

Bare ett av de to utgangssettene kan listes

Det ene tilfellet kan kontrolleres i forespørselsøyeblikket, det andre ikke, noe som gir svært ulike garantier.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

Den publiserte Tor-utgangslisten kan hentes og sammenlignes, avhengig av listens alder og hver utgangs egen policy, så en avvisningsregel mot kjente utganger kan håndheves og gjennomgås. Det finnes ikke et tilsvarende register for kommersielle VPN-er. Adresser roterer, mange leverandører publiserer ingenting, og en tunnel kan kjøre på en leid skyadresse som aldri har tilhørt en VPN. Listen du setter sammen, er et øyeblikksbilde av observerte adresser, og å utvide den til hostingområder legger til urelaterte arbeidsbelastninger uten å legge til bevis.

Bruk adresser som policyinndata, ikke som bevis

Bestem hva regelen er for. En nettverksbegrensning bør forbli smal, registrere den observerte adressen med dato og årsak, og gi legitime brukere en vei tilbake når utgangen deres endres. Tilgangskontroll trenger en autentisert konto eller et signert token, fordi bare disse binder en forespørsel til en identitet. Risikoscoring kan bruke adressen som ett upålitelig signal, og akseptere dets falske positiver og blinde flekker. Å skrive regelen som en produktbeslutning er ærlig; å skrive den som verifisering av at en tunnel finnes, er det ikke.

Speilforespørselen, å gjenfinne brukerens virkelige adresse bak en VPN, mislykkes av samme grunn: én tilkobling bærer én adresse, og en endring mellom økter er forenlig med flere forklaringer. Behandle den tidligere verdien som historie, ikke som sannhet.