El client OpenVPN arriba al servidor però no als equips de la LAN: llista de comprovació

El client diu que està connectat, l’adreça del túnel respon a un ping i res de la LAN de l’oficina no respon. Ho veig després de gairebé cada actualització del client, i el primer instint és obrir el tallafoc, que normalment és el moviment equivocat: el túnel està bé i la ruptura és en un dels tres salts que el paquet ha de travessar. Recorreu el camí en l’ordre en què el paquet el fa, primer la ruta del client, després el reenviament del servidor, després el viatge de tornada, i trobareu el responsable de la fallada en un parell de minuts.

Pas u: observeu la decisió d’encaminament del client

Abans de tocar el servidor, demostreu que el client envia el paquet al túnel. Pregunteu al nucli quina interfície faria servir per a un equip LAN concret, en lloc de llegir tota la taula:

ip route get 192.168.50.10

Si la resposta anomena el vostre adaptador físic i la porta d’enllaç de l’oficina, cap canvi al costat del servidor no pot ajudar. OpenVPN només reparteix rutes quan el servidor les empeny, així que busqueu push "route 192.168.50.0 255.255.255.0" a la configuració del servidor i torneu a connectar el client després. La majoria de clients apliquen les rutes empenyudes en connectar-se, no quan recarregueu el perfil.

A Windows la mateixa pregunta té una altra ordre. Find-NetRoute -RemoteIPAddress 192.168.50.10 imprimeix la interfície i el següent salt que triaria la pila, i route print -4 mostra si el prefix empenyut existeix o no.

Pas dos: confirmeu que el servidor reenviarà el paquet

Si la ruta del client és correcta, el paquet arriba al servidor i el servidor ha d’acceptar reenviar-lo. L’interruptor del nucli és la primera porta, i sysctl net.ipv4.ip_forward ha de retornar 1. Posar-lo amb echo 1 > /proc/sys/net/ipv4/ip_forward funciona fins al proper reinici, i és exactament per això que la mateixa queixa torna setmanes després.

Anoteu-ho en un lloc que sobrevisqui a un reinici:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

La segona porta és la taula de filtres. Un equip amb Docker instal·lat sovint porta una política FORWARD de DROP, i el túnel n’hereta la decisió. iptables -L FORWARD -v -n mostra tant la política com els comptadors de paquets; si la política és DROP, el reenviament necessita una acceptació explícita per al sentit del túnel cap a la LAN i una altra per a la resposta.

Pas tres: seguiu el paquet fins a la LAN i busqueu la resposta

Vigileu els dos costats del servidor alhora. Captureu al túnel i a la interfície LAN, filtrat a un client i un equip perquè la sortida segueixi sent llegible:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Les peticions que apareixen a tun0 i de nou a eth0 amb una font 10.8.0.x, seguides de silenci, volen dir que el paquet va arribar i la resposta va anar a un altre lloc. L’equip LAN respon a la seva porta d’enllaç per defecte, aquesta porta no té cap ruta per al pool de VPN, i la resposta mor al router de la LAN. Fer ping a l’equip LAN des del servidor no demostra res sobre aquest camí, perquè aquest trànsit mai no travessa el túnel.

Pas quatre: trieu entre traducció i una ruta de tornada

Dos arranjaments tanquen el forat, i l’elecció té conseqüències més enllà de si el ping funciona. La traducció d’origen fa que el servidor sigui el remitent aparent:

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

Limiteu la regla al pool i a la interfície LAN, i feu-la permanent, o la propera recàrrega del tallafoc eliminarà la vostra solució sense soroll. El cost és la identitat: cada client sembla el servidor VPN als registres de la LAN i a les regles d’accés, i per-client policy becomes guesswork.

Una ruta estàtica per a 10.8.0.0/24 al router de la LAN, apuntant al servidor VPN, manté visibles les adreces dels clients i és la millor resposta a llarg termini quan aquest router és vostre. Molts llocs fan servir les dues coses durant un temps, NAT per a l’arranjament immediat i la ruta un cop escrita la política del tallafoc. Si el servidor és un parell site-to-site en lloc d’un pool, el costat del servidor també necessita un iroute per a la subxarxa remota, altrament la ruta del parell existeix però el trànsit dels clients no s’hi associa mai.

Pas cinc: verifiqueu des del client i anoteu què ha canviat

Tanqueu el bucle des del client, no des del servidor. Connecteu-vos a un servei real a l’equip LAN, i després confirmeu que els comptadors de traducció s’han mogut amb iptables -t nat -L POSTROUTING -v -n, perquè una regla amb zero paquets és una regla que mai no ha coincidit. conntrack -L -s 10.8.0.5 mostra el flux i el seu estat quan necessiteu proves que el sentit de tornada es fa un seguiment.

Deixeu una nota a la configuració del servidor: quina subxarxa, quina interfície, quina regla i si el router de la LAN porta una ruta de tornada. La propera vegada que una actualització del client esborri una ruta empenyuda, aquesta nota converteix una sessió d’apagar focs en un arranjament d’una línia.