Encaminador LAN més client VPN: dos dispositius, dues taules d’encaminament

Dos dispositius reenvien el paquet i cadascun manté la seva taula. L’encaminador LAN sap que el prefix remot pertany al client VPN, i el client VPN sap com arribar a aquest prefix a través del seu túnel. Configura només la primera taula i el paquet arriba a una màquina que no té cap ruta coincident, de manera que torna a sortir per la ruta per defecte. Aquesta és tota la fallada, i des del costat de la LAN sembla un bucle d’encaminament perquè gairebé ho és.

Dibuixa els dos salts abans de tocar cap ruta

Pren un disseny il·lustratiu: amfitrions de la LAN a 192.168.50.0/24, l’encaminador habitual a 192.168.50.1, un client dedicat a 192.168.50.15 i una LAN remota a 10.60.0.0/24 accessible només a través del túnel que manté aquest client. Cap dels dos rangs privats se superposa a l’altre, i el túnel té el seu propi pla d’adreçament.

Tots dos rangs privats importen perquè decideixen quin dispositiu pot respondre. El costat remot veurà el paquet arribar des de l’adreça de túnel del client, i la seva resposta ha de trobar un camí de tornada a 192.168.50.0/24. Si només es configura la direcció de sortida, la sol·licitud pot funcionar mentre la resposta desapareix.

Pas 1: apunta l’encaminador al client, no al túnel

A l’encaminador LAN, afegeix una ruta de destinació el següent salt de la qual sigui l’adreça LAN del client:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Aquest registre diu «lliura-ho a la màquina que pot fer túnel». No diu res sobre com es construeix el túnel i no substitueix la ruta pròpia del client. En un encaminador gestionat, l’equivalent viu a la pàgina de rutes estàtiques del dispositiu; en un encaminador Linux pertany a la configuració de la interfície que posseeix la LAN, no a un shell que tancaràs.

Comprova la resposta de la segona ordre. Si informa el client com a gateway i la interfície LAN com a device, el primer salt és correcte i la feina restant és a l’altra màquina.

Pas 2: dona al client una ruta pròpia pel costat del túnel

El client ara rep un paquet per a 10.60.0.0/24 i consulta la seva pròpia taula. Si la seva configuració de túnel ha instal·lat una ruta per a aquest prefix, el paquet continua xifrat. Si no ho ha fet, el paquet coincideix amb la ruta per defecte habitual i torna a 192.168.50.1, que el torna a enviar al client.

Mira abans d’afegir res:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Una ruta de prefix absent a totes les taules és la troballa que busques. Afegeix-la a través de la configuració pròpia del túnel, perquè la propera reconnexió la reinstal·li; una ip route add manual desapareix amb la sessió i fa tornar la fallada en el moment més inconvenient. El següent salt és la interfície de túnel o l’adreça que la VPN assigna com a parell, segons el client, i l’adreça del parell hauria de venir del perfil actual i no d’una nota antiga.

El bucle, quan passa, no és infinit a la pràctica: el TTL baixa a cada pas i el paquet mor amb un missatge de temps excedit. Per això un traceroute repetit pot suggerir un cicle mentre un client que simplement no reenvia deixa caure el mateix paquet en silenci.

Pas 3: permet el reenviament i tria el camí de tornada

Rebre i reenviar són permisos diferents. net.ipv4.ip_forward=1 al client permet el trànsit a nivell de nucli, i una regla de tallafocs encara ha de permetre’l entre la interfície LAN i el túnel. Una regla que permet l’accés a la pàgina de gestió del client no permetrà el trànsit cap a la LAN remota, i la distinció és fàcil de passar per alt quan el mateix amfitrió respon pings localment.

El costat remot té el problema mirall. Ha de saber que 192.168.50.0/24 és accessible a través d’aquest client autenticat. Amb OpenVPN això normalment vol dir una ruta per client empenyuda per la configuració del servidor, o un fitxer específic del client al servidor que declara la LAN darrere del client. Sense això, la LAN remota o descarta la resposta o l’envia a la seva pròpia passarel·la per defecte, que és internet.

La traducció de la font és l’alternativa quan el prefix de la LAN no es pot anunciar. Una regla de masquerade amb abast al client reescriu la font a l’adreça del túnel, i les respostes tornen aleshores de manera natural. També amaga quin amfitrió de la LAN va fer la sol·licitud, i per si sola no permet al costat remot iniciar connexions cap a dins. Tria aquest intercanvi deliberadament en lloc d’afegir un masquerade global i descobrir l’efecte secundari més tard.

Pas 4: fes persistents les dues decisions i després prova el camí real

Cada ruta té un propietari, i el propietari és la configuració que es regenera en arrencar o en reconnectar. A l’encaminador pot ser una entrada de ruta estàtica; al client pot ser el perfil VPN, NetworkManager o systemd-networkd. Verifica reconnectant el túnel i reiniciant el client, i després llegeix la taula de nou en lloc de confiar en l’edició.

Mantén intacta la ruta per defecte que porta la connexió exterior del túnel. Substituir-la per «simplificar» la configuració trenca el camí xifrat abans que cap trànsit interior el pugui usar, i el símptoma és un túnel que no es torna a establir mai després del canvi.

Prova des d’un amfitrió LAN corrent, no des del client, perquè una sol·licitud originada al client no exerceix mai el primer salt de l’encaminador. Obtén un servei que només existeix a la LAN remota i confirma el cos de la resposta, i després mira els comptadors o els registres del client per veure el trànsit. Un traceroute interior que mostra salts privats demostra el reenviament, no el xifratge: el camí exterior és una observació separada, i només els comptadors de la interfície del túnel mostren què en va sortir.