VPN-udgangs-IP er ikke bevis for en tunnel: hvad servere ser

Nogen beder om en tjeneste, som kun VPN-brugere kan nå, og den oplagte implementering er at tillade en liste over udgangsadresser. Listen gør noget rigtigt: den begrænser, hvem der kan forbinde. Den beviser ikke, at der blev brugt en tunnel, fordi adressen tilhører den, der driver udgangen, og den operatør kan videresende enhvers trafik. Forskellen mellem de udsagn er hele designproblemet.

Serveren ser én adresse per forbindelse

En forbindelse ankommer med en kildeadresse og en destinationsport, og det er alt, netværkslaget rapporterer. Når en klient bruger en tunnel, kommer pakkerne, der når din lytter, fra udgangen eller fra oversættelsen foran den. Klientens egen adresse, normalt privat, vises aldrig. En firewallregel skrevet til klientens LAN-interval gør derfor slet ingenting.

Alt efter den kildeadresse er applikationsdata, og applikationen kan kun stole på dem i det omfang, den autentificerer dem.

Test, hvordan din udgang ser ud

Se på stien fra begge ender, før du skriver en regel. Klientens syn på sin udgang og serverens syn på forbindelsen er de to fakta, der betyder noget.

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

Den første kommando rapporterer den offentlige adresse, klienten fremstår som, og det er den værdi, enhver tilladelsesliste skal indeholde. Den anden viser etablerede forbindelser på serveren med deres peer-adresser, og det er det, reglen faktisk vil matche. Hvis de to er uenige med din mentale model, skal du rette modellen, før du redigerer politikken. En firewall til en clouddatabase, en tilladelsesliste til en applikation og en load balancer kan hver især se et forskelligt oversættelseslag.

Kun det ene af de to udgangssæt kan listes

Det ene tilfælde kan kontrolleres i anmodningens øjeblik, og det andet kan ikke, hvilket giver meget forskellige garantier.

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

Den offentliggjorte Tor-udgangsliste kan hentes og sammenlignes, afhængigt af listens alder og hver udgangs egen politik, så en afvisningsregel mod kendte udgange kan håndhæves og gennemgås. Der findes ikke et tilsvarende register for kommercielle VPN’er. Adresser roterer, mange udbydere offentliggør intet, og en tunnel kan køre på en lejet cloudadresse, der aldrig har tilhørt en VPN. Den liste, du sammensætter, er et øjebliksbillede af observerede adresser, og at udvide den til hostingintervaller tilføjer urelaterede arbejdsbelastninger uden at tilføje bevis.

Brug adresser som politikinput, ikke som bevis

Beslut, hvad reglen er til. En netværksbegrænsning bør forblive snæver, registrere den observerede adresse med dato og årsag og give legitime brugere en vej tilbage, når deres udgang ændrer sig. Adgangskontrol kræver en autentificeret konto eller et signeret token, fordi kun disse binder en anmodning til en identitet. Risikovurdering kan bruge adressen som et enkelt upålideligt signal og acceptere dets falske positiver og blinde pletter. At skrive reglen som en produktbeslutning er ærligt; at skrive den som verifikation af, at en tunnel findes, er ikke.

Spejlanmodningen, at gendanne brugerens rigtige adresse bag en VPN, fejler af samme grund: én forbindelse bærer én adresse, og en ændring mellem sessioner er forenelig med flere forklaringer. Behandl den tidligere værdi som historie, ikke som sandhed.