Porto VPN reenviado: que poden ver os visitantes e o provedor

Reenviar un porto dá a descoñecidos unha ruta cara a un servizo a través do enderezo público do provedor. Ese único cambio afecta á vez a exposición e a reconocibilidade, e ningún dos dous publica o nome de quen xestiona o servizo. Mantelos separados evita os erros opostos de tratar o 'reenvío' como anonimato e de tratalo como identificación. Tres preguntas sepáranos con claridade, e as respostas veñen de probas distintas.

Tres obxectos, tres preguntas distintas

Manteña o enderezo público separado da aplicación que responde detrás del, e manteña ambos separados da persoa ou organización que xestiona a cousa. Cada un ten o seu propio público e as súas propias probas. Mesturalos produce conclusións que soan ordenadas e son erróneas.

Percórraas nesa orde. A primeira é unha pregunta de accesibilidade, a segunda é unha pregunta de identidade da aplicación e a terceira é unha pregunta de atribución que as dúas primeiras só informan en parte. Cando alguén pregunte se o reenvío de portos é privado, pregunte cal das tres quere dicir. As respostas difiren de verdade, e unha páxina de políticas adoita abordar só unha delas.

Que pode ligar un visitante entre extremos

Un visitante conéctase ao extremo e ve o que a aplicación presenta lexitimamente: 'nome de host', nome de certificado, páxina de inicio de sesión, contido publicado. Eses detalles identifican o servizo incluso cando o seu enderezo habitual de acceso queda oculto tras o túnel. Dous extremos que presentan o mesmo sitio nomeado dan aos observadores unha base para ligalos. Nada nese comportamento é unha fuga, porque a aplicación deseñouse para ser vista.

Que coincidan certificados, redireccións e contido de páxinas entre dous extremos é un sinal forte de que pertencen a un mesmo servizo. Segue sendo unha afirmación sobre o servizo, non sobre unha persoa, ata que algún outro rexistro conecte os dous.

As directrices de privacidade do IETF describen como os identificadores persistentes permiten correlacionar interaccións ao longo do tempo. A correlación non é atribución, xa que varias persoas poden administrar un só servizo e un enderezo pode pasar entre subscritores non relacionados. Esa distinción é a que impide que un achado de correlación se converta nunha acusación.

Que debe saber o provedor de reenvío

Para entregar unha conexión entrante, o sistema do provedor debe manter a relación activa entre o punto de entrada público e o destino interno. Ese feito operativo é distinto do que ve un visitante, e distinto á súa vez do que o provedor decide conservar. Manteña as dúas preguntas separadas ao ler unha páxina de políticas, porque unha é inevitable e a outra é unha decisión. Unha afirmación de que non se garda historial de navegación non di nada sobre o historial de asignacións.

Se persisten as asignacións históricas, as asociacións de conta ou os rexistros de conexión é unha cuestión da política e da implementación reais do provedor. O reenvío non demostra que se rexistre cada categoría. Pregunte en concreto que campos sobreviven tras retirar a asignación, e durante canto tempo.

A accesibilidade entrante tamén está separada do encamiñamento saínte do cliente, do DNS e do comportamento ante fallos. Engadir unha asignación non describe como sae o resto do tráfico do cliente.

Canto dura a asignación cambia a exposición

Unha asignación pode persistir durante unha sesión, durante unha reserva ou segundo unha política do provedor que a cambie. Non debe supoñerse nin a asignación permanente nin a rotación constante; lea o comportamento documentado do produto e anote o que observe. Dúas observacións separadas por unha semana din máis sobre a 'rotación' que calquera frase de márketing da páxina do produto. Anote o intervalo observado xunto ao extremo nas súas notas, porque o intervalo forma parte da exposición.

A duración cambia que correlación é posible. Un extremo estable invita ao seguimento a longo prazo dun servizo, mentres que un rotatorio fai que cada observación sexa máis difícil de unir coa anterior. Ningunha das dúas propiedades é unha garantía sobre os rexistros do provedor, e ningunha substitúe a decisión sobre que publica o propio servizo.

Publique con deliberación e despois peche as dúas portas

Confirme que o provedor permite o protocolo que necesita, que o oínte de destino é o que quería e que os controis do host e da aplicación seguen limitando o acceso. Antes de publicar, mire que presentará o servizo a un descoñecido. Estes dous comandos mostran o certificado e as cabeceiras que recibe un visitante.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

Publicar algo non xustifica expoñer as súas páxinas de administración nin deixar caer o inicio de sesión da aplicación, e a tradución non achega TLS a un servizo que nunca o tivo. Manteña o protocolo cifrado e as súas comprobacións de identidade do servidor no seu sitio, sexa cal sexa a forma en que chega o tráfico. Despois revise as cabeceiras de resposta, porque un 'banner' ou unha páxina de depuración pode dicirlle a un descoñecido máis do que o servizo pretende. O que devolven os dous comandos é a mesma vista que obtén un observador.

Retirar o servizo significa dous peches, non un: retire a asignación a través do seu propietario e despois trate o oínte e o dereito como elementos separados. Un extremo gardado en marcadores que deixa de responder non revoga unha credencial nin recupera información xa entregada.