Client VPN en un servidor LAN: per què les respostes surten pel camí equivocat

Els símptomes segueixen una mateixa forma: un amfitrió funciona, després es connecta a una VPN com a client i ara els clients LAN hi arriben mentre les seves respostes desapareixen. Una captura a l’amfitrió mostra que les respostes surten pel dispositiu del túnel en lloc de la interfície LAN. No hi ha res trencat al túnel, i la solució és una ruta, no una reconnexió. Feu les quatre comprovacions següents en ordre i atureu-vos a la primera que falli.

La resposta és un paquet nou, no un camí invers

Ajuda a descartar la idea que una resposta torna pel camí que va seguir una petició. L’encaminament es decideix per paquet i per direcció, a l’amfitrió emissor. Una petició que va arribar de 10.64.0.23 dins del túnel no crea cap camí de retorn; quan l’amfitrió respon, aquesta resposta es compara amb la taula com un paquet nou i surt per la ruta que guanyi.

Per això un client de túnel complet en una màquina que també serveix una LAN produeix una fallada tan confusa. El client instal·la una ruta per defecte, o les dues mitges rutes per defecte que prefereixen alguns clients, i la resposta a un client LAN ara coincideix amb el túnel. Va al proveïdor, que no té cap motiu per reenviar-la, i el client LAN veu un temps d’espera tot i que l’amfitrió està actiu i respon localment. La captura ho fa evident, i la taula d’encaminament ho explica.

Tingueu dues subxarxes al cap mentre llegiu la resta. Una és el conjunt d’adreces VPN d’on venen els clients remots, en aquest exemple 10.64.0.0/24. L’altra és la LAN que ha de continuar funcionant, 172.16.24.0/24 amb el seu encaminador a 172.16.24.1. L’error és que el trànsit entre elles el decideix la ruta per defecte.

Demostreu-ho amb la captura i la consulta

Abans de canviar res, confirmeu quin dispositiu farà servir la resposta. Una consulta és més ràpida que una captura i respon exactament la pregunta que respondrà el nucli quan es construeixi el paquet.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Llegiu la resposta en dues parts. Si nomena dev tun0, l’amfitrió encapsularà la resposta i la lliurarà al proveïdor, i el client LAN no la veurà mai. Si nomena dev eth0 però el client encara rep un temps d’espera, la ruta ja és correcta i el paquet es descarta més tard, que és un altre problema amb una altra solució.

La captura al mateix pas resol el dubte que un ping no pot. Un eco de resposta que arriba al client LAN demostra que algun camí funciona, no quina interfície l’ha portat, així que feu la captura a l’amfitrió mateix i mireu d’on surten les trames. Una impressora a la mateixa subxarxa continua responent, perquè la seva ruta directa és més específica que la ruta per defecte del túnel. Un port reenviat falla igual que qualsevol altre flux, perquè la taula tria la interfície i la connexió no.

Instal·leu la ruta més específica que superi el túnel

Decideix la longitud del prefix, no la mètrica, així que una ruta per al conjunt de clients a través de l’encaminador LAN guanya qualsevol ruta per defecte que instal·li el client VPN. No cal cap cirurgia de mètriques, i la ruta per defecte pot quedar-se exactament on el client l’ha posada.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Feu servir replace en lloc de add, perquè un client que es reconnecti haurà instal·lat la seva pròpia entrada i un segon add falla amb un error de ruta existent que es llegeix com un problema de permisos. En un amfitrió Windows l’equivalent és route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, on -p manté l’entrada entre reinicis, ja que el client pot reconstruir la taula quan el túnel torna a pujar. En un amfitrió Windows actual l’equivalent suportat és New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, amb l’ordre route més antiga conservada com a forma heretada.

Un detall decideix si això és correcte o només versemblant: el següent salt ha de ser l’encaminador que realment posseeix el camí de tornada als clients. Apuntar la ruta a una adreça a la qual s’arriba precisament pel túnel crea un bucle que es manifesta com a pèrdua intermitent en lloc d’una fallada neta. Confirmeu que el següent salt és a la subxarxa LAN abans de confirmar la línia.

Manteniu la resposta després d’una reconnexió

Una ruta afegida a mà sobreviu com a molt fins a la propera reconnexió. Si el conjunt de clients és dinàmic, fixeu-lo a la configuració del servidor perquè el prefix que heu encaminat segueixi sent el prefix que reben els clients; si no, l’entrada apunta a un rang buit i el símptoma torna setmanes més tard sense cap causa òbvia. Escriure la ruta a l’script up del propi client és l’altra opció fiable, perquè s’executa després que el client hagi reescrit la taula.

Un tallafocs amb estat encara pot frustrar una ruta correcta. Si la captura ara mostra que la resposta surt per eth0 i el client encara rep un temps d’espera, comproveu si l’amfitrió descarta el paquet abans d’enviar-lo. El filtratge estricte de camí invers i net.ipv4.conf.all.rp_filter posat a 1 descarten els paquets l’origen dels quals no s’encaminaria de tornada per la interfície per on van arribar, que és exactament el cas asimètric que acabeu de crear i després de corregir, i l’estat de conntrack explica la mateixa història per als ports reenviats.

L’última comprovació és la que la gent s’estalvia: repetiu la consulta després que el túnel hagi baixat i tornat a pujar. Quatre valors han de coincidir amb el que vau anotar: la destinació, el següent salt, el dispositiu i l’origen triat. Si algun s’ha mogut, el client ha reescrit la taula i la solució pertany als seus hooks i no a l’historial d’una shell.