En VPN:s utgående IP är inte bevis på en tunnel: vad servrar ser

Någon ber om en tjänst som bara VPN-användare kan nå, och den uppenbara implementeringen är att tillåta en lista med utgångsadresser. Listan gör något verkligt: den begränsar vem som kan ansluta. Den bevisar inte att en tunnel användes, eftersom adressen tillhör den som driver utgången, och den operatören kan vidarebefordra vem som helsts trafik. Gapet mellan dessa påståenden är hela designproblemet.

Servern ser en adress per anslutning

En anslutning kommer in med en källadress och en destinationsport, och det är allt nätverkslagret rapporterar. När en klient använder en tunnel kommer paketen som når din lyssnare från utgången eller från översättningen framför den. Klientens egen adress, vanligtvis privat, visas aldrig. En brandväggsregel skriven för klientens LAN-område gör därför ingenting alls.

Allt efter den källadressen är applikationsdata, och applikationen kan bara lita på dem i den mån den autentiserar dem.

Testa hur din utgång ser ut

Titta på vägen från båda ändar innan du skriver en regel. Klientens syn på sin utgång och serverns syn på anslutningen är de två fakta som spelar roll.

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

Det första kommandot rapporterar den offentliga adress som klienten framträder som, och det är det värde som varje tillåtelselista måste innehålla. Det andra visar etablerade anslutningar på servern med deras peer-adresser, och det är vad regeln faktiskt kommer att matcha. Om de två inte stämmer med din mentala modell, rätta modellen innan du redigerar policyn. En brandvägg för en molndatabas, en tillåtelselista för en applikation och en lastbalanserare kan var och en se ett annat översättningslager.

Endast en av de två utgångsuppsättningarna kan listas

Det ena fallet går att kontrollera i begäranögonblicket och det andra inte, vilket ger mycket olika garantier.

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

Den publicerade Tor-utgångslistan kan hämtas och jämföras, beroende på listans ålder och varje utgångs egen policy, så en avvisningsregel mot kända utgångar är genomförbar och granskningsbar. Det finns inget motsvarande register för kommersiella VPN:er. Adresser roterar, många leverantörer publicerar ingenting, och en tunnel kan köra på en hyrd molnadress som aldrig har tillhört en VPN. Listan du sammanställer är en ögonblicksbild av observerade adresser, och att utöka den till hostingintervall lägger till orelaterade arbetsbelastningar utan att lägga till bevis.

Använd adresser som policyindata, inte som bevis

Bestäm vad regeln är till för. En nätverksbegränsning bör förbli smal, registrera den observerade adressen med datum och orsak, och ge legitima användare en väg tillbaka när deras utgång ändras. Åtkomstkontroll kräver ett autentiserat konto eller en signerad token, eftersom bara dessa binder en begäran till en identitet. Riskpoängsättning kan använda adressen som en enda opålitlig signal och acceptera dess falska positiva och blinda fläckar. Att skriva regeln som ett produktbeslut är ärligt; att skriva den som verifiering av att en tunnel finns är det inte.

Spegelbegäran, att återvinna användarens riktiga adress bakom en VPN, misslyckas av samma skäl: en anslutning bär en adress, och en förändring mellan sessioner är förenlig med flera förklaringar. Behandla det tidigare värdet som historia, inte som sanning.