Els clients VPN arriben al servidor però no a la LAN: quina solució?

El client fa ping a l'adreça del túnel del servidor OpenVPN i obté resposta, després prova un equip de la LAN del servidor i no obté res. Aquesta divisió acota molt l'avaria: el túnel està aixecat, el reenviament probablement funciona i la resposta surt per una porta que no torna. Hi ha tres solucions, i la correcta depèn del que controleu i del que estigueu disposats a cedir. Responeu les tres preguntes següents per ordre i l'elecció deixa de ser qüestió de gust.

Primer, confirmeu quina direcció està trencada

La petició arriba a la interfície del túnel amb una adreça d'origen del grup VPN. El servidor la reenvia a l'equip de la LAN, i aquest equip respon a la passarel·la que indica la seva pròpia taula, normalment l'encaminador de la LAN. Si l'encaminador no té ruta cap al grup, la resposta mor allà o vaga cap a internet.

Proveu les dues màquines abans d'editar-ne una. Pregunteu al servidor quina ruta prendria la seva taula cap a un client; pregunteu a l'equip de la LAN com arribaria a la mateixa adreça. La primera consulta sol apuntar al túnel i la segona a l'encaminador de la LAN, i aquesta diferència és l'avaria en una línia. Dues consultes costen menys que una auditoria de tallafocs i fixen la direcció del problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Si l'equip de la LAN ja apunta al servidor VPN, el problema és una regla de tallafocs o un límit d'MTU, no un camí de retorn absent. No afegiu una ruta per arreglar un filtre.

Pregunta u: podeu editar l'encaminador de la LAN remota?

Quan l'encaminador de la LAN és vostre, una ruta estàtica cap al grup VPN amb l'adreça LAN del servidor VPN com a següent salt és la resposta neta. Manté intactes les adreces d'origen dels clients, cosa que importa quan els equips de la LAN registren, filtren o limiten per adreça. Tampoc no necessita traducció al servidor, així que el túnel continua sent un camí pur d'encaminament. L'obligació que crea és documental, perquè el grup, la ruta i la configuració del servidor han de coincidir.

Falla en silenci el dia que algú canvia el grup. Anoteu el valor una vegada i tracteu una edició en qualsevol dels tres llocs com una edició als tres.

Un NAS o un commutador de capa 3 que allotja el servei necessita la mateixa ruta, tret que ho enviï tot per un encaminador que la tingui. Reviseu el dispositiu que acaba la subxarxa, no només el que mira a internet. Les xarxes petites solen tenir tres aparells amb opinió sobre l'encaminament.

Pregunta dos: la LAN pot deixar de veure les adreces dels clients?

Quan l'encaminador és d'una altra persona, traduir al servidor VPN no necessita cooperació. L'equip de la LAN veu l'adreça LAN del servidor, hi respon, i el servidor tradueix de tornada. Per això es comporten així els appliances i els rols d'accés remot basats en NAT.

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

El cost és l'atribució: les adreces per client desapareixen dels registres de la LAN. Qualsevol llista de permesos a l'equip de la LAN ha de nomenar llavors el servidor en lloc del grup.

Trieu la traducció quan la cooperació no estigui disponible, no quan sigui només incòmoda. Amaga el client de tota investigació futura, també de les que necessiteu saber quin portàtil va obrir una connexió. També pot trencar protocols que incrusten adreces a la càrrega útil, perquè la traducció viu a la capçalera. Cap de les dues opcions és més avançada; responen preguntes diferents sobre la propietat.

Pregunta tres: és el servidor mateix client d'un altre túnel?

Imagina la topologia oposada: el servidor VPN també marca un proveïdor comercial, així que té dos túnels i dos conjunts d'adreces. El trànsit que reenvia per als seus propis clients surt pel proveïdor, que no encaminarà les respostes cap a les adreces del grup. Per això desapareixen les respostes encara que els dos túnels estiguin sans.

La correcció és emmascarar també el túnel de sortida, perquè el proveïdor només vegi l'adreça del túnel del servidor. La direcció inversa necessita la seva pròpia regla, perquè el servidor que inicia una connexió cap a un dels seus clients és un flux diferent. Sense aquesta regla, el client respon a una adreça que no pot encaminar. Poseu la regla estreta abans de qualsevol emmascarament ampli perquè guanyi la traducció específica.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Els equips amb diverses interfícies afegeixen una avaria relacionada que es veu idèntica des del client. La resposta surt per la interfície de mètrica més baixa perquè l'adreça d'origen es va triar en una altra taula. Comproveu el camí de tornada amb una consulta en lloc de suposar que el d'anada ho implica.

Després verifiqueu les dues direccions i les dues mides

Després del canvi, feu ping del client a un equip de la LAN i després de l'equip de la LAN al client. La segona direcció és la que la gent omet, i és la que revela una regla de traducció incompleta. Anoteu els dos resultats amb marca de temps perquè una regressió posterior sigui comparable.

Després moveu dades reals, perquè un ping petit que funciona mentre una transferència gran s'encalla és un símptoma d'MTU. Aquesta avaria apareix just després que us feliciteu per haver arreglat la ruta.

Finalment, torneu a provar després d'un reinici. Les ordres de ruta i tallafocs en calent no hi sobreviuen, i una solució que desapareix al següent arrencada serà diagnosticada de nou per algú amb menys context. Feu el canvi persistent com ja fa el vostre sistema, i reinicieu un cop expressament.