O IP de saída dunha VPN non demostra un túnel: o que ven os servidores

Alguén pide un servizo ao que só poden chegar os usuarios de VPN, e a implementación obvia é permitir unha lista de enderezos de saída. A lista fai algo real: restrinxe quen pode conectarse. Non demostra que se usase un túnel, porque o enderezo pertence a quen opera a saída e ese operador pode reenviar o tráfico de calquera. A fenda entre esas afirmacións é todo o problema de deseño.

O servidor ve un enderezo por conexión

Unha conexión chega cun enderezo de orixe e un porto de destino, e iso é todo o que informa a capa de rede. Cando un cliente usa un túnel, os paquetes que chegan ao seu oínte veñen da saída ou da tradución diante dela. O enderezo propio do cliente, normalmente privado, nunca aparece. Por iso, unha regra de devasas escrita para o rango da LAN do cliente non fai absolutamente nada.

Todo o que vén despois dese enderezo de orixe son datos de aplicación, e a aplicación só pode confiar neles na medida en que os autentica.

Comprobe como se ve a súa saída

Mire o camiño desde ambos os extremos antes de escribir unha regra. A visión do cliente sobre a súa saída e a visión do servidor sobre a conexión son os dous feitos que importan.

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

O primeiro comando informa do enderezo público co que aparece o cliente, e ese é o valor que debe conter calquera lista de permitidos. O segundo mostra as conexións establecidas no servidor coas direccións dos seus pares, e é con iso co que a regra coincidirá realmente. Se os dous non concordan co seu modelo mental, corrixa o modelo antes de editar a política. Un devasas de base de datos na nube, unha lista de permitidos de aplicación e un balanceador de carga poden ver cada un unha capa de tradución distinta.

Só se pode listar un dos dous conxuntos de saída

Un caso pódese comprobar no momento da petición e o outro non, o que produce garantías moi distintas.

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

A lista publicada de saídas de Tor pódese obter e comparar, suxeita á idade da lista e á política propia de cada saída, polo que unha regra de denegación contra saídas coñecidas é aplicable e revisable. Non existe un rexistro equivalente para as VPN comerciais. Os enderezos rotan, moitos provedores non publican nada, e un túnel pode funcionar nun enderezo de nube alugado que nunca pertenceu a unha VPN. A lista que vostede compile é unha instantánea de enderezos observados, e ampliala a rangos de aloxamento engade cargas non relacionadas sen engadir probas.

Use os enderezos como entrada de política, non como proba

Decida para que serve a regra. Unha restrición de rede debe manterse estreita, rexistrar o enderezo observado coa súa data e o seu motivo, e dar aos usuarios lexítimos un camiño de recuperación cando cambie a súa saída. O control de acceso necesita unha conta autenticada ou un token asinado, porque só estes vinculan unha petición a unha identidade. A puntuación de risco pode usar o enderezo como un único sinal pouco fiable, aceptando os seus falsos positivos e os seus puntos cegos. Escribir a regra como decisión de produto é honesto; escribila como verificación de que existe un túnel, non.

A petición espello, recuperar o enderezo real do usuario detrás dunha VPN, falla polo mesmo motivo: unha conexión leva un enderezo, e un cambio entre sesións é compatible con varias explicacións. Trate o valor anterior como historia, non como verdade.