Per què la vostra LAN no pot arribar a un servei en un client VPN

El vostre túnel està actiu, el servei escolta i la LAN de l’oficina encara no rep res de tornada. Ningú no ha trencat la VPN. Des del costat de la LAN, l’adreça del túnel de l’ordinador portàtil no existeix fins que alguna cosa diu a la LAN com arribar-hi, i la resposta ha de tornar pel mateix camí pel qual va sortir la petició. He vist gent reconstruir tres vegades un túnel perfectament bo abans que algú mirés el camí de tornada.

El túnel no és el que s’ha trencat

Els dos extrems seuen en rangs privats, que és el cas normal i no una configuració errònia. Una adreça com 10.8.0.6 és real dins del túnel i inexistent a qualsevol altre lloc, així que la LAN no té cap motiu per enviar-hi res. Abans de tocar l’encaminament, confirmeu que el servei és accessible dins del túnel: al client, ss -ltn mostra si l’oient s’enllaça a 127.0.0.1, a la interfície de la LAN o a l’adreça del túnel. Un dimoni enllaçat només a loopback no respon a ningú més que a si mateix, i cap ruta, DNAT ni redirecció de port ho canvia.

Un proxy al port 80 o 443 és una altra eina amb una altra visibilitat. Mou peticions, no paquets, així que és la capa equivocada per a una connexió directa a una base de dades, i recórrer-hi és com aquest problema acaba tres eines endins abans que algú mesuri res.

Forma de ruta: digueu a la LAN on és el conjunt

Una ruta estàtica a la passarel·la de la LAN és la resposta més neta quan la LAN i el conjunt del túnel no se superposen. Apunteu el conjunt a la màquina que acaba el túnel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Això arregla només una direcció, i per això les versions mig fetes d’aquest canvi semblen progrés. El costat del túnel necessita la meitat corresponent, o la resposta surt del client per la seva pròpia ruta per defecte i mor pel camí:

push "route 192.168.1.0 255.255.255.0"

Per a una subxarxa que se seu darrere d’un client en lloc de darrere del servidor, el servidor necessita tant una ruta de sistema com una entrada iroute al fitxer d’aquell client sota client-config-dir. Sense iroute, OpenVPN sap que el prefix existeix i no té ni idea de quin client en és el propietari: els paquets arriben i el dimoni no té amb què emparellar-los.

Aquí teniu el mite que val la pena nomenar. Una ruta fa que una adreça sigui abastable; no fa que l’altra banda estigui disposada a respondre. Els parells lloc a lloc hi afegeixen una altra capa, perquè la passarel·la remota només accepta orígens dins dels prefixos de la seva política, i un portàtil que arriba d’un conjunt domèstic no hi és dins.

Forma NAT: DNAT cap endins i la línia SNAT que tothom omet

Quan no podeu tocar la passarel·la de la LAN, o voleu publicar exactament un port, la traducció a l’amfitrió VPN funciona sense cap ruta a la LAN. Publiqueu el port, redirigiu-lo i traduïu l’origen camí del túnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

La tercera línia és la que desapareix. Ometeu-la i el client veu l’adreça original de la LAN com a origen, respon per la seva pròpia ruta per defecte, i aquesta resposta se’n va cap al túnel en lloc de tornar cap a la LAN. Si la connexió sobreviu depèn llavors d’un encaminament que no vau planificar mai. Amb SNAT el client veu l’adreça del túnel del servidor, així que la resposta segueix el túnel de tornada fins a l’únic amfitrió que pot desfer la traducció.

El firmware de consum fa servir noms de cadena propis i no genera aquesta traducció per vosaltres. A Tomato, una regla d’entrada cau a WANPREROUTING i després en una cadena de filtratge com wanin, i un conjunt de regles que sembla complet encara necessita una línia POSTROUTING manual. Això no és un error del firmware; és un conjunt de regles escrit només per al trànsit d’entrada.

Per què una regla que sembla correcta encara descarta el paquet

La majoria d’aquestes fallades no són a la regla que mireu fixament. Comproveu quatre coses en aquest ordre i atureu-vos a la primera que no es compleixi:

• Ordre de les cadenes. iptables -I inserisca a dalt i -A afegeix al final, així que una regla permissiva o bloquejant anterior decideix primer.
• Cadena equivocada. El trànsit adreçat al mateix encaminador travessa INPUT, i el trànsit redirigit no el toca mai. Publicar un sol servei pot necessitar regles a totes dues.
• Indicadors de direcció. -i tun0 coincideix amb el trànsit que arriba dels clients i -o tun0 amb el trànsit que en surt. Un REJECT amb l’indicador equivocat bloqueja una cosa que no volíeu.
• Restricció d’origen. Una redirecció que accepta una adreça de client funciona des d’aquell client i descarta qualsevol altre origen sense dir res.

Una regla amb un comptador de paquets a zero no és al camí de cap manera, i llegir els comptadors és la manera més ràpida de separar un problema de cadena equivocada d’un problema de regla equivocada.

La redirecció local, quan a la LAN no hi ha res que es pugui canviar

Una redirecció SSH local esquiva tota la qüestió. No necessita cap ruta a la LAN, ni la col·laboració del tallafoc del client, ni cap port publicat enlloc:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

El servei apareix llavors a localhost:3000 de la màquina que manté el túnel, i enlloc més. Aquí hi ha el límit: una estació de treball, un port, i la redirecció mor amb la sessió tret que alguna cosa la reiniciï. Per a un administrador que comprova una base de dades de proves és l’eina correcta. Per a una càmera o un escàner a què altres persones han d’arribar, no ho és, perquè cada usuari necessitaria la seva pròpia redirecció.

Verifiqueu les dues direccions abans d’afegir una altra regla

La traducció deixa rastres, i llegir-los és millor que endevinar. A l’amfitrió VPN, conntrack -L mostra si la traducció s’ha produït, iptables -t nat -L -n -v mostra si els comptadors s’han mogut, i tcpdump -ni any port 3000 mostra quina adreça d’origen ha arribat realment. Al client, ss -ltn confirma que l’oient és en una adreça que el túnel pot assolir.

Després trieu la forma que conserveu. Un port publicat, una ruta per a tot el conjunt i una redirecció per a un sol administrador són tres compromisos diferents, i barrejar-los és com una configuració que funciona es converteix en una que ningú no sabrà explicar sis mesos més tard. Escriviu quina adreça és abastable des d’on, i la propera persona que depuri això començarà per la resposta en lloc del túnel.