Per què els clients d’Access Server no són abastables des de la LAN

L’ordinador portàtil es connecta, el túnel s’aixeca i les peticions a un servei intern es queden penjades en connectar. Al mateix servei, la petició arriba des d’una adreça com 10.90.0.25, la resposta surt cap a la passarel·la per defecte i no torna res, perquè aquesta passarel·la no té ni idea d’on viu 10.90.0.25. Des de l’altre extrem, la mateixa fallada sembla un amfitrió intern que no pot fer ping a un client connectat. Totes dues són un sol objecte que falta: una ruta de tornada al pool de clients VPN, que només la xarxa privada pot afegir.

Llegeix l’adreça d’origen que veu el servei

Aquest únic camp decideix tota la resta. Si el servei intern veu l’adreça del pool, l’Access Server enruta en lloc d’amagar el trànsit dels clients, i cada resposta s’ha d’enrutar de tornada al pool. Si en canvi veu l’adreça privada del mateix servidor, el servidor fa masquerade i la ruta de tornada ja funciona, a canvi de perdre qualsevol identitat per client als registres i a les regles d’accés del servei.

Compara els dos extrems abans de canviar res. Al servidor, llista les interfícies del túnel i les seves adreces; al client, confirma quina d’aquestes adreces té realment; a l’amfitrió intern, mira una connexió activa.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

L’última ordre és la que falla en el cas trencat: o bé informa que el prefix del túnel no és abastable o, pitjor, retorna la teva passarel·la per defecte, i així és com les respostes acaben a internet.

No assumeixis un sol pool. Un servidor pot tenir un rang dinàmic més assignacions estàtiques per usuari, i l’adreça estàtica pot quedar completament fora del prefix dinàmic. Si només enrutes el rang que recordes, els usuaris amb adreces fixes continuen trencats i tota la resta informa que el problema està resolt.

Afegeix la ruta on es decideix la resposta

La ruta pertany a la passarel·la que el servei intern ja utilitza, no al servei, tret que enruti el seu propi trànsit. Apunta-la a l’adreça privada abastable de l’Access Server, que és un valor diferent de l’adreça del túnel que té un client.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

En una xarxa de núvol, la mateixa afirmació es converteix en una entrada de la taula de rutes el destí de la qual és la instància o la interfície de xarxa on s’executa el servidor, amb la comprovació d’origen i destinació desactivada en aquesta interfície. Fixa’t en què no fa aquesta entrada: una ruta no és una concessió d’accés, així que els grups de seguretat, les ACL de xarxa i el tallafoc de l’amfitrió encara han de permetre el trànsit.

Fes-la persistent i mantingues honestes les mides dels pools. Dos pools no contigus necessiten dues rutes, i un pool que creix més enllà del prefix configurat genera silenciosament clients les respostes dels quals no tenen on anar. Si controles els rangs dels pools, tria un resum que puguis enrutar una vegada i deixar estar.

L’encaminament i els filtres han de coincidir amb la ruta

L’encaminament és només la meitat del camí. Cal permetre al servidor que encamini entre el túnel i la interfície privada, cosa que a Linux vol dir net.ipv4.ip_forward més una cadena d’encaminament que permeti la parella d’interfícies, i en un amfitrió endurit normalment una regla explícita per a cada direcció.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

El filtratge amb estat explica un símptoma que porta la gent pel camí equivocat. Una resposta dins d’un flux establert no necessita cap regla d’entrada nova, així que una connexió que es penja després del SYN-ACK no està sent bloquejada per una regla d’acceptació que falta; s’està descartant o enrutant malament. Mantén aquesta distinció, perquè separa un canvi d’encaminament d’un canvi de tallafoc.

Els camins de tornada asimètrics són la versió més silenciosa del mateix problema. Si dues rutes arriben al pool i la resposta pren la que surt per una interfície diferent d’aquella per on va arribar la petició, el filtratge estricte de camí invers la descarta i el flux falla només per a alguns clients.

Enrutat o emmascarat: tria-ho deliberadament

El mode enrutat conserva l’adreça del pool del client al servei, cosa que fa possible el registre i la política per client, i a canvi cada xarxa interna que hagi de respondre a un client necessita la ruta del pool. El mode emmascarat elimina aquest requisit perquè les respostes tornen al servidor, però el servei ja no distingeix un client de l’altre i no pot iniciar res cap a un client concret.

Canviar aquest comportament en un servidor en producció fa caure les sessions existents, així que prova-ho primer amb un client i un flux. Si el canvi és la resposta correcta, és una decisió de configuració al servidor, no una cosa que s’hagi d’esquivar afegint rutes que esdevindran innecessàries.

Una subxarxa darrere del client és una tasca a part

Arribar a un dispositiu a la LAN pròpia de l’ordinador portàtil no és el mateix que arribar a l’adreça del túnel de l’ordinador portàtil. Requereix que el client faci de passarel·la de subxarxa: una xarxa declarada al costat del client, l’encaminament activat al sistema operatiu del client i una ruta en aquesta LAN de tornada cap al client. Afegir una ruta de xarxa privada per al rang de casa de l’ordinador portàtil no ho fa, i crea conflictes quan dos usuaris tenen el mateix rang de casa.

La direcció també és una qüestió de política. El permís perquè un client obri una connexió a un servei intern no deixa automàticament que un amfitrió intern obri una connexió a aquest client. Comprova la política d’accés del servidor i el tallafoc de l’amfitrió del client abans de concloure que el camí està trencat.

Verifica amb un flux i una captura

Demostra el camí amb una sola connexió en lloc d’una prova general d’abastabilitat. Observa el mateix flux als dos extrems: la petició que arriba al servei i la resposta que en surt.

tcpdump -ni any host 10.90.0.25 and port 443

Abans de l’arreglada, la captura mostra la resposta sortint cap a una passarel·la que no l’enrutarà. Després de l’arreglada, la resposta surt cap al servidor i el flux es completa. Després confirma la ruta que la passarel·la faria servir per a una segona adreça de client, perquè un pool que no has cobert aparegui ara i no d’aquí a una setmana.

Acaba amb les quatre comprovacions que tanquen el tema: l’adreça d’origen al servei coincideix amb el mode que pretenies, la passarel·la té ruta a cada pool en ús, l’encaminament i els filtres permeten les dues direccions, i un flux real es completa d’extrem a extrem. Preguntes freqüents sobre encaminament d’Access Server exposa el mateix principi per a la versió instal·lada, la interfície de configuració admesa de la qual pot diferir de les guies antigues.