Els clients VPN es connecten però no tenen internet: tres peces que falten

El client obté una adreça, el servidor respon als ping i, tot i així, cada pàgina acaba expirant. La majoria de la gent comença a editar el perfil del client en aquest punt, cosa que normalment és un esforç perdut: un cop el túnel està aixecat, el servidor ha de comportar-se com un encaminador. Tres condicions han de complir-se alhora abans que un paquet surti i torni una resposta, i el símptoma és idèntic sigui quina sigui la que falta.

Per què un túnel que funciona encara no té camí de sortida

El nucli ha de reenviar paquets entre interfícies, cosa que està desactivada per defecte a la majoria de distribucions de Linux. El trànsit s’ha de traduir a una adreça a la qual el món exterior pugui respondre, tret que cada encaminador superior ja conegui la ruta de tornada a la subxarxa del túnel. El camí de reenviament del tallafoc ha de permetre el trànsit en tots dos sentits, incloses les respostes.

Cadascuna d’aquestes coses es pot arreglar per separat, i aquí hi ha el parany. Activar el reenviament sense una regla de traducció deixa els paquets sortint amb una font privada i sense camí de tornada. Afegir la traducció sense una regla de reenviament deixa el nucli descartant el paquet un pas més enllà.

Per tant, proveu les tres capes en lloc del client, i canvieu-ne una cada vegada perquè el resultat signifiqui alguna cosa.

El reenviament és un commutador del nucli que cal fer persistent

Comproveu el valor actual abans de canviar-lo, després establiu-lo i confirmeu que el canvi ha tingut efecte.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

La primera ordre informa del valor actual, la segona l’estableix en temps d’execució i la tercera demostra que l’escriptura ha funcionat. El valor en temps d’execució desapareix al proper reinici, i per això una sessió que funciona es pot trencar després d’un manteniment sense cap canvi de configuració.

Feu-lo permanent en un fitxer sota /etc/sysctl.d/, i després apliqueu aquest fitxer en lloc de reiniciar per esbrinar-ho. A FreeBSD l’equivalent és net.inet.ip.forwarding, amb gateway_enable=YES a rc.conf per a la persistència. Un aparell que informa que el reenviament està desactivat explica tota una classe d’informes de «els paquets arriben i no en torna res». Reviseu el paràmetre després de cada actualització, perquè un nucli reconstruït o una imatge d’aparell substituïda poden reiniciar-lo sense avisar ningú.

Trieu masquerade o una adreça de traducció fixa

Amb una adreça exterior dinàmica, masquerading és la forma correcta més senzilla. Anomeneu la subxarxa del túnel com a origen i la interfície exterior com a sortida.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Amb una adreça pública estàtica, la traducció d’origen a aquesta adreça exacta és més predictible i més fàcil d’auditar.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

La segona forma porta un parany de manteniment: una adreça escrita al codi que després canvia manté el túnel funcionant mentre l’accés a internet s’atura en silenci. Feu servir masquerade o actualitzeu la regla sempre que el proveïdor us mogui. La interfície també importa, perquè un encaminador que comparteix el seu propi túnel superior ha de traduir per aquest túnel i no pel WAN físic.

La taula de filtratge és la tercera porta

El reenviament i la traducció poden ser tots dos correctes mentre el paquet encara mor a la taula de filtratge. ufw és un culpable freqüent: la seva política de reenviament ve com a DROP, i la resta de la configuració pot semblar perfectament correcta mentre aquell únic paràmetre mata el trànsit. Apujar-la és una decisió de seguretat deliberada i no una casella de selecció.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

La primera regla permet trànsit nou del túnel cap a fora, i la segona només les respostes de tornada. Estrebeu les dues a la subxarxa del túnel i a la destinació que voleu, perquè una acceptació general a la interfície del túnel converteix la VPN en un punt de sortida obert per a qualsevol que es pugui autenticar.

Un túnel pontat necessita una resposta diferent. L’adreça pertany al pont, no al port físic, de manera que esclavitzar la interfície elimina l’adreça que abans tenia i l’amfitrió sembla inabastable fins que el mateix pont en rep una, cosa que dhclient br0 pot proporcionar. Aquest fallada sembla un problema de VPN i és un problema de capa dos. Reviseu l’adreça pròpia del pont abans de tocar el tallafoc, perquè un canvi de filtre no pot arreglar un amfitrió que ja no té cap adreça des d’on enviar.

On mirar quan una pàgina no carrega mai

Feu ping a l’adreça del túnel del servidor per demostrar que el túnel existeix. Després executeu un traceroute des del client cap a una adreça pública i llegiu on s’atura: al servidor el paquet arriba però no es reenvia ni es tradueix; més enllà del servidor el problema és aigües amunt i fora de les vostres mans.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

La primera ordre demostra que el túnel porta trànsit al mateix servidor, i la segona mostra fins on arriba un paquet cap a fora. Un traçat que acaba a l’adreça del túnel apunta al reenviament o a la traducció del servidor, mentre que un traçat que s’atura un salt més enllà apunta al proveïdor o a la ruta de tornada de l’encaminador superior.

Al servidor, observeu la interfície exterior mentre un client carrega una pàgina. El trànsit que surt amb una adreça d’origen privada vol dir que falta la traducció, i l’absència total de resposta vol dir que el camí de reenviament o la ruta de tornada superior l’està descartant.

Si els clients remots també han d’arribar als amfitrions de la LAN del servidor, recordeu que la LAN necessita una ruta de tornada a la subxarxa del túnel. Això és encaminament i no traducció, i és el pas que més sovint s’oblida quan el camí d’internet finalment funciona.