Servei Onion davant del servei VPN: models d'accés diferents

La gent descriu un servei Onion i un servei només accessible per VPN com dues variants de la mateixa idea: amaga el port i comparteix l'adreça secreta. Es diferencien en allò a què està lligada l'adreça, qui hi pot arribar i què ha de passar abans que arribi una petició. Un és un punt de trobada dins de Tor; l'altre és una ruta dins d'una xarxa privada. Tractar-los com a intercanviables produeix dissenys que no són ni privats ni sostenibles.

El mite: tots dos dissenys són només una porta amagada

La propietat compartida és real però prima: cap dels dos dissenys no posa la interfície administrativa en un port públic directament accessible. Tota la resta divergeix. Una adreça Onion es deriva de la clau pròpia del servei, així que el nom va lligat a una identitat; una adreça VPN és només una adreça dins d'una xarxa on us han admès. Un amaga el servei dins d'una capa superposada, l'altre us admet en una topologia privada. Tractar el segon com a sinònim del primer és on comença la confusió.

Cap de les dues propietats no és un control de seguretat per a l'aplicació mateixa. Un lloc amagat no pedaça el programari que hi ha al darrere, i una ruta privada no afegeix autenticació a la pàgina d'inici de sessió. Tots dos dissenys encara necessiten els permisos propis de l'aplicació, i tots dos encara necessiten algú responsable de les actualitzacions i la recuperació.

A què apunta realment una adreça Onion

Una adreça Onion de la versió v3 codifica la clau pública del servei, i per això ningú no pot triar una adreça per a un servei que no controla. El client es connecta a través de Tor a un punt de trobada, i el servei arriba al mateix punt des del seu costat; cap node de sortida corrent no porta aquesta connexió fins al servei. El nom és una identitat, no un registre DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Per això afegir una ruta o una entrada a hosts per a un nom onion no serveix de res. La consulta no és el mecanisme; ho és el client de Tor i els seus circuits. Si el servei és per a un grup petit de persones, l'autorització de client onion pot exigir una clau abans que s'accepti la connexió, però això encara no és l'inici de sessió a l'aplicació. Publicar l'adreça també és un acte deliberat, ja que qualsevol que la conegui pot intentar connectar-s'hi tret que l'hàgiu restringida.

Atureu-vos si l'única raó del disseny onion és evitar de configurar l'autenticació. La capa superposada no ho ofereix, i la construireu més tard de tota manera.

Què concedeix realment una ruta VPN

Una VPN admet un dispositiu en una xarxa i li dona una ruta cap a una passarel·la o una subxarxa. El servei darrere d'aquesta passarel·la veu una adreça del conjunt del túnel i aplica l'autorització que té. La ruta no diu res sobre qui és l'usuari; diu on poden anar els paquets.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Aquest model encaixa amb un grup conegut amb dispositius gestionats, perquè la passarel·la pot imposar l'estat del dispositiu i la xarxa es pot auditar. Encaixa malament amb visitants anònims o ad hoc, que primer s'haurien d'inscriure. L'inici de sessió de l'aplicació continua decidint què pot llegir un usuari connectat. Confondre l'abast amb el permís és com una VPN acaba concedint una subxarxa sencera a tothom qui es pot connectar.

Atureu-vos si el públic és desconegut o canvia constantment. Inscriure desconeguts en una xarxa privada per mostrar-los una pàgina és un compromís gran comparat amb publicar un servei.

Triar entre ells, i què es manté igual

Trieu el model onion quan el públic sigui tècnic, el servei no hagi de tenir cap adreça pública i pugueu acceptar els requisits del client de Tor. Trieu el model VPN quan el públic sigui un grup definit els dispositius del qual gestioneu i l'accés del qual vulgueu registrar a la capa de xarxa. Cap de les dues opcions no elimina la necessitat d'autenticació de l'aplicació, pedaçament o un camí de recuperació. Cap de les dues no és automàticament més privada en el sentit que importa als vostres usuaris.

En tots dos dissenys, anoteu qui pot arribar al servei, com s'identifiquen i què passa quan es perd una credencial. La resposta per a un servei onion inclou les seves claus d'autorització de client i l'adreça mateixa; la resposta per a una VPN inclou el compte, el dispositiu i la política de la passarel·la. Són inventaris diferents, i només un serà obvi per al proper administrador.

La comparació acaba on comença l'aplicació. Una adreça amagada i una ruta privada són opcions de transport, i l'aplicació encara ha de decidir què pot fer una petició. Mantingueu aquestes decisions en documents separats i cap dels dos dissenys no absorbirà en silenci la feina de l'altre.