Icona verde, mesma IP pública: que ruta saltou a VPN

Conectado, icona verde na bandexa e unha páxina de eco de enderezo que aínda mostra o enderezo do provedor non significan automaticamente unha avaría. Un cliente fai dous traballos separados: constrúe un túnel e edita a táboa de encamiñamento. Calquera dos dous pode ocorrer sen o outro, e o encamiñamento selectivo é a configuración na que o segundo se omite a propósito.

Que instalou realmente o cliente

Pregunta que interface levaría un paquete a un destino real en lugar de preguntar se o túnel está activo. Un túnel sen ruta cara a ese destino é un camiño privado que ninguén usa.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

O primeiro comando responde en Linux e macOS, e os outros dous son os equivalentes de Windows, onde abonda un. Se a resposta nomea o adaptador físico, o túnel está activo e a ruta predeterminada nunca se moveu. Repite a consulta para un destino que debería usar o túnel, porque dúas consultas, unha remota e outra ordinaria, din que deseño está despregado.

Tres formas de encamiñamento selectivo

Un perfil de túnel completo adoita escribir unha ruta predeterminada que apunta á interface, ou escribe o par de prefixos de medio rango que gañan por lonxitude de prefixo mentres a ruta predeterminada orixinal queda na táboa. O encamiñamento selectivo é a outra opción, e chega en varias formas. Un perfil encamiña un só host como un servidor RDP, outro encamiña un rango público ao que hai que chegar desde un lugar concreto, e un terceiro exclúe unha aplicación a propósito. Os tres son lexítimos, e ningún cambia o enderezo que ve un sitio web calquera.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Le o perfil para a directiva que decide e despois a táboa para o que produciu. Unha directiva empurrada tamén se pode suprimir no cliente, por iso o perfil e a táboa teñen que coincidir antes de culpar o servidor.

O lado remoto debe reescribir o enderezo de orixe

Hai un segundo fallo que desde o navegador parece idéntico. A ruta apunta ao túnel, o servidor recibe os paquetes e logo reenvíaos co enderezo privado do cliente intacto. O seguinte salto non ten camiño de volta para ese enderezo, así que as respostas desaparecen e as páxinas colgan. O servidor ten que reenviar sequera, e ten que traducir a orixe en algo que internet poida encamiñar de volta.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Nomea a interface que realmente mira a internet, que nunha distribución moderna non sempre é eth0. Un servidor aloxado con enderezo fixo pode traducir explicitamente a ese enderezo en lugar de usar masquerade. As dúas metades importan, porque o reenvío sen tradución filtra orixes non encamiñables mentres que a tradución sen reenvío nunca ve o paquete.

A resolución de nomes toma o seu propio camiño

O tráfico pode saír polo túnel mentres a consulta que atopou o nome foi a un resolutor da rede local. O enderezo visible segue igual, as consultas non, e ese oco é exactamente o que escolle un deseño de DNS dividido.

resolvectl status | head -20
resolvectl query example.org

Fíxate en que servidor respondeu e se difire da liña base previa ao túnel. Nun túnel dividido adoita ser o axuste que a xente quería cambiar cando se queixaba do enderezo, e é o que nunca mirou.

Catro observacións que o resolven

Captura o enderezo de saída co túnel baixado e despois co túnel subido. Executa a consulta de destino en ambos os estados e anota a interface cada vez.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Cando a consulta cae dentro do túnel e o eco aínda mostra o enderezo do provedor, falta a tradución na saída. Cando a consulta cae no adaptador físico, o perfil é selectivo e o enderezo público nunca estivo en xogo. Substitúe o servizo de eco por un de confianza e anota as catro observacións xuntas, porque por separado son anécdotas. Xuntas identifican cal dos dous traballos fixo realmente o cliente.