Výstupní IP adresa VPN není důkazem tunelu: co servery vidí

Někdo chce službu, kam se dostanou jen uživatelé VPN, a zřejmá implementace je povolit seznam výstupních adres. Seznam dělá něco skutečného: omezuje, kdo se může připojit. Nedokazuje, že byl použit tunel, protože adresa patří tomu, kdo provozuje výstup, a tento operátor může přeposlat provoz kohokoli. Rozdíl mezi těmito tvrzeními je celý problém návrhu.

Server vidí jednu adresu na připojení

Připojení přichází se zdrojovou adresou a cílovým portem a to je vše, co síťová vrstva hlásí. Když klient použije tunel, pakety, které dorazí k vašemu posluchači, přicházejí z výstupu nebo z překladu před ním. Vlastní adresa klienta, obvykle privátní, se nikdy neobjeví. Pravidlo firewallu napsané pro rozsah klientské LAN proto nedělá vůbec nic.

Vše za touto zdrojovou adresou jsou data aplikace a aplikace jim může věřit jen natolik, nakolik je ověřuje.

Otestujte, jak vypadá váš výstup

Podívejte se na cestu z obou konců, než napíšete pravidlo. Pohled klienta na jeho výstup a pohled serveru na připojení jsou dva fakty, na kterých záleží.

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

První příkaz hlásí veřejnou adresu, pod kterou se klient objevuje, a to je hodnota, kterou musí obsahovat každý seznam povolených. Druhý ukazuje navázaná připojení na serveru s adresami protějšků, a právě s tím se pravidlo skutečně porovná. Pokud se obojí neshoduje s vaší mentální představou, opravte model dřív, než upravíte politiku. Firewall cloudové databáze, seznam povolených aplikace a nástroj pro vyvažování zátěže mohou každý vidět jinou vrstvu překladu.

Uvést lze jen jednu ze dvou množin výstupů

Jeden případ lze zkontrolovat v okamžiku požadavku a druhý ne, což dává velmi odlišné záruky.

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

Zveřejněný seznam výstupů Toru lze stáhnout a porovnat, s ohledem na stáří seznamu a vlastní politiku každého výstupu, takže pravidlo odmítnutí známých výstupů je vymahatelné a přezkoumatelné. Ekvivalentní registr pro komerční VPN neexistuje. Adresy se točí, mnoho poskytovatelů nic nezveřejňuje a tunel může běžet na pronajaté cloudové adrese, která nikdy VPN nepatřila. Seznam, který sestavíte, je snímek pozorovaných adres a jeho rozšíření na hostingové rozsahy přidává nesouvisející zátěž, aniž by přidalo důkaz.

Používejte adresy jako vstup politiky, ne jako důkaz

Rozhodněte, k čemu pravidlo je. Síťové omezení má zůstat úzké, zaznamenat pozorovanou adresu s datem a důvodem a dát legitimním uživatelům cestu k obnově, když se jejich výstup změní. Řízení přístupu potřebuje ověřený účet nebo podepsaný token, protože jen ty vážou požadavek k identitě. Hodnocení rizika může adresu použít jako jeden nespolehlivý signál a přijmout jeho falešné poplachy i slepá místa. Napsat pravidlo jako produktové rozhodnutí je poctivé; napsat ho jako ověření, že tunel existuje, ne.

Zrcadlový požadavek, tedy získání skutečné adresy uživatele za VPN, selhává ze stejného důvodu: jedno připojení nese jednu adresu a změna mezi relacemi je slučitelná s několika vysvětleními. Berte dřívější hodnotu jako historii, ne jako pravdu.