La VPN del router funciona, però els clients de la LAN no tenen internet

L'estat diu que el túnel està aixecat, un navegador al mateix router carrega pàgines, i cada dispositiu que té darrere encara fa temps d'espera. Aquesta combinació redueix el problema a una capa que la majoria de guies de VPN no esmenten: el router no és l'únic amfitrió els paquets del qual han de sobreviure al túnel. El trànsit generat localment i el trànsit reenviat segueixen camins diferents per la mateixa caixa. Proveu-ho des d'un client i la diferència deixa de ser teòrica.

Llegeix la fallada des d'un amfitrió de la LAN

Comenceu pel dispositiu que falla, perquè una diagnosi al router respon una pregunta diferent. Confirmeu que la porta d'enllaç per defecte del client és aquest router, anoteu-ne l'adreça d'origen i la subxarxa, i després mireu què surt de la interfície del túnel del router.

Si l'adreça del client es tradueix, el costat remot veu l'adreça del túnel, i des d'allà tot sembla sa mentre el client encara falla. Si no es tradueix, el costat remot ha de conèixer una ruta de tornada a la subxarxa del client, i moltes portes d'enllaç no tenen aquesta ruta per defecte. En tots dos casos l'èxit del router és irrellevant, perquè els seus paquets es van generar localment i mai no van passar pel camí del reenviament.

El trànsit local i el trànsit reenviat són diferents

Linux i la majoria de firmware de router tracten els paquets originats per la mateixa caixa de manera diferent dels paquets que hi passen. La cadena output veu els primers, la cadena forward veu els segons, i una política ajustada al trànsit propi del router pot deixar el reenviament intacte.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Comproveu si el reenviament està activat, i després llegiu la cadena forward en lloc de la cadena output. Una regla que permet la connexió exterior xifrada no és una regla que permet reenviar paquets desxifrats, i confondre les dues produeix exactament aquest símptoma. Que el túnel estigui aixecat només demostra la primera.

El camí de retorn també ha d'existir

La traducció d'origen decideix si cal un camí de retorn. Amb emmascarament a la interfície del túnel, les respostes tornen a l'adreça del túnel i el router les destradueix. Sense això, la porta d'enllaç remota necessita una ruta explícita a la subxarxa del client, i la seva pròpia política ha de permetre aquesta direcció.

Anoteu quin dels dos dissenys fa servir el desplegament abans de canviar res, perquè les reparacions apunten en direccions oposades. Afegir traducció amaga una ruta de retorn absent i trenca aplicacions que necessiten l'adreça d'origen original. Afegir una ruta de retorn sense traducció falla en silenci quan el tallafoc remot descarta l'origen desconegut. Trieu-ne un, documenteu-lo i feu que l'altre costat coincideixi.

El DNS del client pertany a la mateixa revisió. El resolutor del router pot respondre mentre un client apuntat a un altre servidor no obté res de res.

Verifiqueu un flux permès i un flux denegat

Després de la correcció, proveu una connexió nova des d'un client i no una sessió existent del router. Després confirmeu que un segment que no hauria d'usar el túnel continua sense usar-lo.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Comproveu l'adreça d'origen observada a l'extrem remot, perquè us diu quin disseny s'executa realment. Verifiqueu també una consulta de nom, no només una adreça, perquè el comportament del resolutor és un camí separat per la mateixa caixa.

Mantingueu les regles limitades a les xarxes de clients que necessiten el túnel, i resistiu la temptació de desactivar el filtre de reenviament per fer passar una prova. Aquest canvi repara la prova i elimina la frontera que el túnel havia de proporcionar. Escriviu l'adreça d'origen, la decisió de traducció i la ruta de retorn en una sola nota, amb data.