Het exit-IP van een VPN is geen bewijs van een tunnel: wat servers zien

Iemand vraagt om een dienst die alleen VPN-gebruikers kunnen bereiken, en de voor de hand liggende implementatie is een lijst met exitadressen toestaan. De lijst doet iets echts: ze beperkt wie kan verbinden. Ze bewijst niet dat er een tunnel is gebruikt, want het adres is van degene die de uitgang beheert, en die operator kan ieders verkeer doorsturen. De kloof tussen die uitspraken is het hele ontwerpprobleem.

De server ziet één adres per verbinding

Een verbinding komt binnen met een bronadres en een doeltpoort, en dat is alles wat de netwerklaag meldt. Wanneer een client een tunnel gebruikt, komen de pakketten die uw listener bereiken van de uitgang of van de vertaling ervoor. Het eigen adres van de client, meestal privé, verschijnt nooit. Een firewallregel voor het LAN-bereik van de client doet dus helemaal niets.

Alles na dat bronadres zijn applicatiegegevens, en de applicatie kan ze alleen vertrouwen voor zover ze die authenticeert.

Test hoe uw uitgang eruitziet

Bekijk het pad van beide kanten voordat u een regel schrijft. De kijk van de client op zijn uitgang en de kijk van de server op de verbinding zijn de twee feiten die ertoe doen.

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

De eerste opdracht meldt het openbare adres waaronder de client verschijnt, en dat is de waarde die elke toelatingslijst moet bevatten. De tweede toont bestaande verbindingen op de server met hun peer-adressen, en dat is waar de regel werkelijk op zal matchen. Als de twee niet overeenkomen met uw mentale model, corrigeer dan het model voordat u het beleid bewerkt. Een firewall voor een clouddatabase, een toelatingslijst voor een applicatie en een loadbalancer kunnen elk een andere vertaallaag zien.

Slechts één van de twee exitsets kan worden vermeld

Het ene geval is controleerbaar op het moment van het verzoek en het andere niet, wat heel verschillende garanties oplevert.

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

De gepubliceerde Tor-exitlijst kan worden opgehaald en vergeleken, afhankelijk van de leeftijd van de lijst en het eigen beleid van elke exit, dus een weigeringsregel tegen bekende exits is afdwingbaar en controleerbaar. Voor commerciële VPN’s bestaat geen gelijkwaardig register. Adressen roteren, veel aanbieders publiceren niets, en een tunnel kan draaien op een gehuurd cloudadres dat nooit van een VPN is geweest. De lijst die u samenstelt is een momentopname van waargenomen adressen, en uitbreiding naar hostingbereiken voegt ongerelateerde werklast toe zonder bewijs toe te voegen.

Gebruik adressen als beleidsinvoer, niet als bewijs

Bepaal waar de regel voor dient. Een netwerkbeperking moet smal blijven, het waargenomen adres met datum en reden vastleggen, en legitieme gebruikers een herstelpad geven wanneer hun uitgang verandert. Toegangsbeheer vereist een geauthenticeerd account of een ondertekend token, omdat alleen die een verzoek aan een identiteit binden. Risicoscore kan het adres als één onbetrouwbaar signaal gebruiken en de valse positieven en blinde vlekken ervan accepteren. De regel als productbeslissing opschrijven is eerlijk; hem opschrijven als verificatie dat een tunnel bestaat niet.

Het spiegelverzoek, het herwinnen van het echte adres van de gebruiker achter een VPN, mislukt om dezelfde reden: één verbinding draagt één adres, en een verandering tussen sessies is verenigbaar met meerdere verklaringen. Behandel de eerdere waarde als geschiedenis, niet als waarheid.