Servizo Onion fronte a servizo VPN: modelos de acceso distintos

A xente describe un servizo Onion e un servizo accesible só por VPN como dúas variantes da mesma idea: ocultar o porto e compartir o enderezo secreto. Diferéncianse no aquilo ao que está ligado o enderezo, quen pode alcanzalo e que debe ocorrer antes de que chegue unha petición. Un é un punto de encontro dentro de Tor; o outro é unha ruta dentro dunha rede privada. Tratalos como intercambiables produce deseños que non son nin privados nin mantibles.

O mito: ambos os deseños son só unha porta oculta

A propiedade compartida é real pero delgada: ningún dos dous deseños coloca a interface administrativa nun porto público directamente accesible. Todo o demais diverxe. Un enderezo Onion derívase da clave propia do servizo, así que o nome está ligado a unha identidade; un enderezo VPN é só un enderezo dentro dunha rede á que se lle admitiu. Un esconde o servizo dentro dunha capa superposta, o outro admíteo nunha topoloxía privada. Tratar o segundo como sinónimo do primeiro é onde comeza a confusión.

Ningunha das dúas propiedades é un control de seguridade para a propia aplicación. Un lugar oculto non parchea o software que hai detrás, e unha ruta privada non engade autenticación á páxina de inicio de sesión. Ambos os deseños seguen necesitando os permisos propios da aplicación, e ambos seguen necesitando a alguén responsable das actualizacións e da recuperación.

A que apunta realmente un enderezo Onion

Un enderezo Onion da versión v3 codifica a clave pública do servizo, polo que ninguén pode escoller un enderezo para un servizo que non controla. O cliente conéctase a través de Tor a un punto de encontro, e o servizo chega ao mesmo punto desde o seu lado; ningún nodo de saída corrente leva esa conexión ata o servizo. O nome é unha identidade, non un rexistro DNS.

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

Por iso engadir unha ruta ou unha entrada en hosts para un nome onion non serve de nada. A consulta non é o mecanismo; éo o cliente de Tor e os seus circuítos. Se o servizo está pensado para un grupo pequeno de persoas, a autorización de cliente onion pode esixir unha clave antes de aceptar a conexión, pero iso segue sen ser o inicio de sesión da aplicación. Publicar o enderezo tamén é un acto deliberado, xa que calquera que o coñeza pode intentar conectarse a menos que o restrinxiu.

Detéñase se a única razón do deseño onion é evitar configurar a autenticación. A capa superposta non o proporciona, e construiraa máis adiante de todos os xeitos.

Que concede realmente unha ruta VPN

Unha VPN admite un dispositivo nunha rede e dálle unha ruta cara a unha pasarela ou unha subrede. O servizo detrás desa pasarela ve un enderezo do conxunto do túnel e aplica a autorización que teña. A ruta non di nada sobre quen é o usuario; di a onde poden ir os paquetes.

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

Ese modelo encaixa cun grupo coñecido con dispositivos xestionados, porque a pasarela pode impor o estado do dispositivo e a rede pódese auditar. Encaixa mal con visitantes anónimos ou ad hoc, que primeiro terían que inscribirse. O inicio de sesión da propia aplicación segue decidindo que pode ler un usuario conectado. Confundir o alcance co permiso é como unha VPN acaba concedendo unha subrede enteira a todo o que pode conectarse.

Detéñase se o público é descoñecido ou cambia constantemente. Inscribir descoñecidos nunha rede privada para lles mostrar unha páxina é un compromiso grande comparado con publicar un servizo.

Escoller entre ambos, e o que permanece igual

Escolla o modelo onion cando o público sexa técnico, o servizo non deba ter ningunha dirección pública e poida aceptar os requisitos do cliente de Tor. Escolla o modelo VPN cando o público sexa un grupo definido cuxos dispositivos xestiona e cuxo acceso quere rexistrar na capa de rede. Ningunha elección elimina a necesidade de autenticación da aplicación, parcheo ou unha vía de recuperación. Ningunha é automaticamente máis privada no sentido que importa aos seus usuarios.

En ambos os deseños, anote quen pode alcanzar o servizo, como se identifican e que acontece cando se perde unha credencial. A resposta para un servizo onion inclúe as súas claves de autorización de cliente e o propio enderezo; a resposta para unha VPN inclúe a conta, o dispositivo e a política da pasarela. Son inventarios distintos, e só un deles resultará obvio para o seguinte administrador.

A comparación remata onde comeza a aplicación. Un enderezo oculto e unha ruta privada son opcións de transporte, e a aplicación aínda ten que decidir que pode facer unha petición. Manteña esas decisións en documentos separados e ningún dos dous deseños absorberá en silencio o traballo do outro.