El client VPN encaminat arriba al servidor però no als equips de la LAN

El túnel s'aixeca, el client fa ping al servidor VPN, i un recurs compartit en una màquina a un salt de distància no respon mai. Res a la configuració del client ho explica, perquè la petició sí que va sortir del client i sí que va arribar. El que va fallar és el viatge de tornada, i el dispositiu que va fallar sol ser la passarel·la de la LAN i no l'amfitrió VPN. Rastrejar el paquet de resposta explica tota aquesta classe de símptomes.

Seguiu la resposta, no la petició

El servidor VPN desxifra el paquet del client i l'envia a la LAN amb l'adreça del client encara al camp d'origen. L'amfitrió de destinació respon a aquesta adreça, i ara la seva pròpia taula d'encaminament decideix tot. La seva passarel·la per defecte no sap res del pool del túnel, així que la resposta surt cap al proveïdor d'internet i es descarta en algun punt d'aquest camí.

Al client el símptoma és un temps d'espera silenciós: cap refús, cap reinici, només res. La navegació per un recurs compartit s'encalla, el ping informa que no hi ha resposta, i els registres del servidor semblen sans perquè el servidor va fer la seva feina.

Poseu la ruta de tornada on miren els equips

Cada equip de la LAN consulta la seva passarel·la per defecte, així que la passarel·la és l'únic dispositiu que ha de saber on viu el pool del túnel. Afegiu-hi una ruta estàtica i cada equip hereta el camí correcte sense que el toquin.

Si la passarel·la reparteix la seva pròpia adreça com a opció DHCP, distribuïu la ruta d'aquesta manera perquè les màquines noves la prenguin automàticament. En cas contrari, la ruta viu en un fitxer de configuració i desapareix a la propera reconstrucció.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Per què el NAT d'origen sembla que ho arregla

Emmascarar el pool de clients darrere l'adreça del servidor VPN elimina el problema tot eliminant l'adreça del client del paquet. Aleshores les respostes tornen al servidor, que ja sap com arribar al túnel, i tot funciona. El cost és que els equips interns ja no poden veure qui és el client, i cada connexió sembla originar-se en una sola màquina.

Aquest intercanvi de vegades és correcte, per exemple quan a un aparell del proveïdor no se li pot donar una ruta estàtica. Feu la regla no més ampla que el pool actual, perquè una regla escrita per a un /24 deixa de coincidir el dia que el pool es renumera a un /16, i el primer senyal és un lot de clients nous que es connecten i no arriben enlloc.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

El camí al núvol necessita tres ajustos

En una VPC la mateixa llacuna torna amb una altra forma, perquè la subxarxa no té cap ruta per al rang de clients. La taula d'encaminament necessita una entrada per al pool del túnel que apunti a la interfície de xarxa de la instància, i la interfície ha de tenir desactivada la comprovació d'origen i destinació perquè la plataforma accepti paquets l'origen dels quals no és la seva pròpia adreça. Els grups de seguretat i les ACL de xarxa també han d'admetre el pool en tots dos sentits.

Cada omissió produeix una fallada parcial diferent. Ometeu l'entrada de la taula d'encaminament i les instàncies privades responen en una subxarxa que no pot portar la resposta de tornada al pool. Amb la comprovació encara activa, la plataforma descarta la resposta després que la instància ja l'hagi enviada. Sense la regla del grup de seguretat, la petició mateixa no arriba mai, i el client veu el temps d'espera una capa abans.

Executeu les comprovacions en aquest ordre

Confirmeu l'encaminament i la política de filtratge abans de culpar l'encaminament de xarxa, perquè un equip que no encaminarà falla de la mateixa manera silenciosa. Després llegiu l'ajust efectiu de camí invers a la interfície que porta el túnel, ja que un filtre estricte pot descartar respostes que arriben d'una direcció inesperada.

Acabeu amb una captura feta a l'equip de la LAN mentre el client li fa ping. Una petició que arriba sense resposta corresponent demostra el camí de tornada, i una petició que no arriba mai torna la culpa al servidor o al túnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

La comprovació d'origen i destinació està documentada a la guia de la interfície de xarxa elàstica. Configureu-la a la interfície que realment porta el trànsit del túnel, no en un adaptador no relacionat connectat a la mateixa instància.