Túnel completo fronte á ruta de extremo: manter accesible o servidor VPN

Engada unha ruta predeterminada polo túnel e os propios paquetes do túnel seguiranas. A táboa contén entón unha regra que se derrota a si mesma. A conexión cifrada co servidor tenta viaxar dentro da conexión que tenta establecer.

Dous mecanismos impiden ese bucle. Un é visible na táboa de rutas, o outro vive dentro da aplicación.

O tráfico interno e o externo son decisións distintas

Un paquete de aplicación entra na interface virtual e encapsúlase. O resultado é un paquete novo dirixido ao enderezo público do servidor. Ese paquete necesita unha ruta na rede física, porque nada del pode entrar no túnel.

Ambos son decisións de encamiñamento, e só a primeira pertence ao túnel. Cando o cliente instala unha ruta predeterminada que tamén cobre o servidor, o paquete externo tamén queda capturado.

Os síntomas son inmediatos e totais. O handshake complétase e despois non flúe nada, ou a conexión cae no instante en que se instala a ruta. En ambos os casos o keepalive xa non pode saír.

Opción un: unha ruta de host para o extremo

O enfoque directo engade unha ruta para o enderezo do servidor a través da pasarela orixinal. Só require unha liña. É visible para calquera que lea a táboa. Tamén é fácil de explicar nun rexistro de cambios.

A súa debilidade aparece cando cambia a ruta subxacente. A ruta gardada nomea unha pasarela e unha interface da rede antiga. Tras un cambio de Wi-Fi esa pasarela pode non existir, e a ruta queda atrás, parece correcta e non fai nada.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Un nome de host fai isto máis difícil. Se o extremo é un nome que se resolve en varios enderezos, a exclusión debe cubrir o enderezo realmente en uso. Unha consulta posterior pode devolver algo que a ruta nunca cubriu.

Opción dous: protexer o socket

O outro enfoque nunca toca a táboa de rutas. O cliente marca ou protexe o socket que leva o túnel, de xeito que o sistema operativo envía o tráfico dese socket fóra do túnel por política. Android expón o mecanismo directamente ás aplicacións VPN. Os clientes de escritorio implementan equivalentes con marcas de firewall ou chamadas de vinculación ao dispositivo.

A vantaxe é que a excepción segue a conexión en lugar dunha pasarela gardada. Un cambio de rede reescribe a ruta subxacente, e o socket protexido móvese con ela porque nunca estivo fixado a un enderezo. A táboa de rutas mantense limpa.

O custo é a visibilidade. Nada na táboa de rutas mostra a excepción, así que un revisor que busca unha ruta de host non atopa nada e pode concluír que o deseño é inseguro. A protección vive no código do cliente e nas regras de política que ese código instala.

Escoller entre ambas

Escolla o mecanismo de nivel de socket cando o cliente o admite, porque sobrevive aos cambios de rede que rompen unha ruta fixada. Escolla a ruta de host cando a excepción deba ser visible para outras ferramentas ou cando o cliente non ofreza nada mellor.

Ningún dos dous mecanismos elimina a necesidade de que o enderezo do servidor sexa accesible de todo. Unha pasarela privada ten un enderezo público de escoita, e ese enderezo é o que debe quedar fóra do túnel. As redes internas detrás dela só se fan accesibles unha vez que existe o túnel.

Escolla o que escolla, mantéñao xunto ao compoñente que posúe o túnel. Unha ruta de host perdida engadida á man funciona ata a seguinte rede, e entón convértese na misteriosa caída de mañá.