La resposta de la VPN de lloc a lloc no travessa el túnel
Una resposta que s’escapa del túnel és una decisió d’encaminament del costat remot. Reviseu la taula d’amfitrions, els selectors i rp_filter, i després trieu ruta o NAT.
Vaig passar un matí amb un túnel que s’aixecava net i movia trànsit exactament en una direcció: la sucursal arribava al servidor de fitxers de la seu, i cada connexió oberta des de la seu cap a la sucursal moria al primer SYN. Les SA estaven actives, els comptadors del túnel pujaven i l’apretada de mans mai no va ser el problema. La resposta s’encaminava cap a un lloc que el túnel no cobreix, i aquesta tria pertany al costat remot. Una VPN de lloc a lloc només transporta els paquets que un amfitrió lliura a la passarel·la, i cada amfitrió fa aquesta tria per separat, en cada direcció, des de la seva pròpia taula d’encaminament.
Les dues direccions s’encaminen per separat
IP no conserva cap memòria de la direcció d’una conversa. Cada amfitrió que envia un paquet fa la seva pròpia cerca del prefix més llarg, tria un sol salt següent i oblida la decisió. La petició i la resposta són dos paquets sense relació que casualment pertanyen a la mateixa connexió, i el túnel és un salt que qualsevol dels dos pot usar o no. Res de l’intercanvi IKE no ensenya al servidor remot com arribar a la vostra subxarxa; la negociació només acorda quins prefixos es poden xifrar.
Aquest acord és la segona porta. A strongSwan els selectors de trànsit són leftsubnet i rightsubnet, i un paquet l’origen o la destinació del qual cau fora de la parella negociada no es xifra, digui el que digui la taula d’encaminament. Un prefix que s’encamina cap al túnel però falta als selectors és una fallada unilateral silenciosa: la ruta sembla correcta, el paquet encara surt en clar o es descarta, i només el registre de charon es queixa.
L’amfitrió remot no sap res del vostre túnel
Dins de la LAN remota la resposta és un paquet corrent adreçat al vostre client. L’amfitrió de destinació no veu cap capçalera IPsec i no té cap motiu per preferir la passarel·la VPN; busca el vostre prefix, no troba res més específic que la seva ruta per defecte i la segueix. Si la ruta per defecte apunta a un tallafoc central, el tallafoc o té una ruta de tornada al túnel o no en té. Quan no en té, obteniu un descart silenciós, un ICMP unreachable o una resposta que surt per la interfície orientada a internet i mor.
Una segona interfície n’hi ha prou per trencar això fins i tot quan la ruta existeix. Un NAS amb un enllaç de gestió en una altra VLAN, un servidor amb un uplink de reserva, una regla de política que envia un rang d’orígens a una segona taula: qualsevol d’aquestes coses pot capturar la resposta. A Linux, ip rule show i ip route show table all mostren regles i taules que el llistat per defecte amaga.
Llegiu la decisió a la màquina que envia la resposta
Pregunteu al nucli abans de canviar res, i doneu-li l’adreça d’origen, perquè les regles dependents de l’origen canvien la resposta.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"La sortida anomena la interfície de sortida i el salt següent. Si la interfície no és la que mira a la passarel·la VPN, heu trobat el defecte, i la feina que queda és triar on ha d’anar la ruta. Un ping des de la passarel·la aquí demostra poc: respon amb una adreça que l’amfitrió remot pot situar, no amb l’adreça del vostre portàtil.
A Windows els equivalents són Find-NetRoute -RemoteIPAddress 10.10.5.10 per a la decisió i Get-NetRoute per a la taula. Una ruta afegida amb New-NetRoute que porta una mètrica més alta que la per defecte perd en silenci, així que llegiu la columna de mètrica, no l’entrada. Després confirmeu-ho amb paquets: tcpdump -ni any "host 10.10.5.10 and tcp port 445" a la interfície LAN remota mostra la petició, i el mateix filtre al costat del túnel mostra si ha tornat una resposta. Petició visible sense resposta vol dir que la resposta s’ha encaminat a un altre lloc o s’ha descartat; una resposta a la interfície equivocada us dóna el culpable abans de tocar cap ruta.
Quan la passarel·la del servidor no és el punt final de la VPN
Molts llocs posen un tallafoc entre els servidors i el concentrador. Aquest tallafoc reenvia la resposta, així que necessita una ruta per al prefix del vostre client apuntant a la passarel·la VPN, i política de reenviament en les dues direccions. Els dispositius amb estat ho empitjoren: la petició va travessar el tallafoc des d’un amfitrió LAN que va permetre, la resposta ara arriba d’una altra direcció i l’entrada de seguiment de connexions ja no coincideix, així que el paquet es descarta com a invàlid en lloc de denegat. Per això el registre de política sembla buit mentre el trànsit desapareix.
La passarel·la té un segon filtre propi. El filtratge de camí invers de Linux descarta paquets l’origen dels quals no és abastable per la interfície per la qual han arribat, que és exactament la forma d’un camí de tornada asimètric legítim. la guia de reenviament d’strongSwan demana net.ipv4.ip_forward i un net.ipv4.conf.all.rp_filter relaxat per aquest motiu. Un valor estricte d’1 en qualsevol de les dues passarel·les trenca en silenci una ruta correcta, i nstat -az mostra els descarts si sabeu on mirar.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Encamineu o traduïu, i després verifiqueu en les dues direccions
Les dues reparacions no són equivalents. Afegir una ruta manté intacta l’adreça del client, així que les regles basades en l’origen, els registres d’auditoria i les aplicacions que anoten qui truca continuen funcionant; el preu és que cada salt que pren la decisió necessita la ruta, que són més llocs on equivocar-se. Emmascarament a la passarel·la remota redueix el camí de tornada a un sol salt, perquè la resposta ara s’adreça a la mateixa passarel·la, i amaga quin client ha fet què.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADETriau-lo deliberadament: un cop els clients apareixen com l’adreça de la passarel·la, les ACL basades en l’origen deixen de distingir-los, i conntrack ha de mantenir la correspondència perquè la resposta es reescrigui de tornada al túnel. Si els selectors encara exclouen el prefix del client, NAT no canvia res, perquè la petició mai no ha entrat al túnel.
Abans de donar-ho per arreglat, confirmeu quatre coses en ordre: la ruta a l’amfitrió que envia la resposta, la ruta a cada salt que la reenvia, els selectors que cobreixen tots dos prefixos i una captura que mostri la resposta entrant al túnel amb l’origen que espereu. Després repetiu la prova des de l’altre lloc. Una direcció que passa és un disseny mig obert, i la segona direcció normalment falla per un motiu diferent del que acabeu de reparar.