La IP de sortida d’una VPN no demostra un túnel: què veuen els servidors

Algú demana un servei al qual només poden arribar els usuaris de VPN, i la implementació òbvia és permetre una llista d’adreces de sortida. La llista fa una cosa real: restringeix qui es pot connectar. No demostra que s’hagi fet servir un túnel, perquè l’adreça pertany a qui opera la sortida i aquest operador pot reenviar el trànsit de qualsevol. La diferència entre aquestes afirmacions és tot el problema de disseny.

El servidor veu una adreça per connexió

Una connexió arriba amb una adreça d’origen i un port de destinació, i això és tot el que informa la capa de xarxa. Quan un client fa servir un túnel, els paquets que arriben al vostre oient vénen de la sortida o de la traducció que hi ha al davant. L’adreça pròpia del client, normalment privada, no apareix mai. Per tant, una regla de tallafoc escrita per al rang de la LAN del client no fa absolutament res.

Tot el que hi ha després d’aquesta adreça d’origen són dades d’aplicació, i l’aplicació només se’n pot fiar en la mesura que les autentica.

Comproveu com es veu la vostra sortida

Mireu el camí des de les dues bandes abans d’escriure una regla. La visió del client sobre la seva sortida i la visió del servidor sobre la connexió són els dos fets que importen.

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

La primera ordre informa de l’adreça pública amb què apareix el client, i aquest és el valor que ha de contenir qualsevol llista d’admesos. La segona mostra les connexions establertes al servidor amb les adreces dels seus parells, i és amb això que la regla coincidirà realment. Si les dues no concorden amb el vostre model mental, corregiu el model abans d’editar la política. Un tallafoc de base de dades al núvol, una llista d’admesos d’aplicació i un balancejador de càrrega poden veure cada un una capa de traducció diferent.

Només es pot llistar un dels dos conjunts de sortida

Un cas es pot comprovar en el moment de la petició i l’altre no, cosa que produeix garanties molt diferents.

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

La llista publicada de sortides de Tor es pot obtenir i comparar, subjecta a l’edat de la llista i a la política pròpia de cada sortida, de manera que una regla de denegació contra sortides conegudes és aplicable i revisable. No hi ha cap registre equivalent per a les VPN comercials. Les adreces roten, molts proveïdors no publiquen res, i un túnel pot funcionar en una adreça de núvol llogada que mai no va pertànyer a una VPN. La llista que compileu és una instantània d’adreces observades, i ampliar-la a rangs d’allotjament afegeix càrregues no relacionades sense afegir proves.

Feu servir les adreces com a entrada de política, no com a prova

Decidiu per a què serveix la regla. Una restricció de xarxa ha de romandre estreta, enregistrar l’adreça observada amb la data i el motiu, i donar als usuaris legítims un camí de recuperació quan canvia la seva sortida. El control d’accés necessita un compte autenticat o un testimoni signat, perquè només aquests lliguen una petició a una identitat. La puntuació de risc pot fer servir l’adreça com un sol senyal poc fiable, acceptant-ne els falsos positius i els punts cecs. Escriure la regla com a decisió de producte és honest; escriure-la com a verificació que un túnel existeix no ho és.

La petició mirall, recuperar l’adreça real de l’usuari darrere d’una VPN, falla pel mateix motiu: una connexió porta una adreça, i un canvi entre sessions és compatible amb diverses explicacions. Tracteu el valor anterior com a història, no com a veritat.