Túnel complet o ruta d'extrem: mantenir el servidor VPN accessible

Afegiu una ruta per defecte pel túnel i els seus propis paquets la seguiran. La taula conté llavors una regla que es derrota a si mateixa. La connexió xifrada al servidor intenta viatjar dins de la connexió que intenta establir.

Dos mecanismes eviten aquest bucle. Un és visible a la taula d'encaminament, l'altre viu dins de l'aplicació.

El trànsit intern i l'extern són decisions diferents

Un paquet d'aplicació entra a la interfície virtual i s'encapsula. El resultat és un paquet nou adreçat a l'adreça pública del servidor. Aquest paquet necessita una ruta a la xarxa física, perquè res d'ell no pot entrar al túnel.

Totes dues són decisions d'encaminament, i només la primera pertany al túnel. Quan el client instal·la una ruta per defecte que també cobreix el servidor, el paquet extern també queda capturat.

Els símptomes són immediats i totals. L'apretada de mans es completa i després no hi flueix res, o la connexió cau en l'instant en què s'instal·la la ruta. En tots dos casos el keepalive ja no pot sortir.

Opció u: una ruta d'host per a l'extrem

L'enfocament directe afegeix una ruta per a l'adreça del servidor a través de la passarel·la original. Només cal una línia. És visible per a qualsevol que llegeixi la taula. També és fàcil d'explicar en un registre de canvis.

La seva feblesa apareix quan canvia el camí subjacent. La ruta desada anomena una passarel·la i una interfície de la xarxa antiga. Després d'un canvi de Wi-Fi aquesta passarel·la pot no existir, i la ruta es queda enrere, sembla correcta i no fa res.

# 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 nom d'host ho fa més difícil. Si l'extrem és un nom que es resol en diverses adreces, l'exclusió ha de cobrir l'adreça realment en ús. Una consulta posterior pot retornar alguna cosa que la ruta mai no va cobrir.

Opció dos: protegir el socket

L'altre enfocament no toca mai la taula d'encaminament. El client marca o protegeix el socket que porta el túnel, de manera que el sistema operatiu envia el trànsit d'aquest socket fora del túnel per política. Android exposa el mecanisme directament a les aplicacions VPN. Els clients d'escriptori implementen equivalents amb marques de tallafoc o crides de vinculació al dispositiu.

L'avantatge és que l'excepció segueix la connexió en lloc d'una passarel·la desada. Un canvi de xarxa reescriu el camí subjacent, i el socket protegit es mou amb ell perquè mai no va estar fixat a una adreça. La taula de rutes es manté neta.

El cost és la visibilitat. Res a la taula d'encaminament no mostra l'excepció, així que un revisor que busca una ruta d'host no troba res i pot concloure que el disseny és insegur. La protecció viu al codi del client i a les regles de política que aquest codi instal·la.

Triar entre les dues

Trieu el mecanisme de nivell de socket quan el client el suporta, perquè sobreviu als canvis de xarxa que trenquen una ruta fixada. Trieu la ruta d'host quan l'excepció ha de ser visible per a altres eines, o quan el client no ofereix res millor.

Cap dels dos mecanismes elimina la necessitat que l'adreça del servidor sigui accessible. Una passarel·la privada té una adreça pública d'escolta, i aquesta adreça és la que ha de quedar fora del túnel. Les xarxes internes al darrere només esdevenen accessibles un cop el túnel existeix.

Triï's el que triï's, manteniu-ho amb el component que posseeix el túnel. Una ruta d'host errant afegida a mà funciona fins a la xarxa següent, i llavors es converteix en la caiguda misteriosa de demà.