Per què els clients OpenVPN es perden els selectors IPsec de la passarel·la

Fes un ping a un amfitrió darrere del túnel IPsec remot des de la passarel·la i respon net, així que el túnel sembla sa i el tiquet avança. Després un client connectat prova el mateix amfitrió i no rep res. Aquell ping mai no va ser una prova per al flux del client, perquè va sortir amb l’adreça d’origen de la mateixa passarel·la i va coincidir amb un selector IPsec diferent. Entendre per què divergeixen els dos casos és la major part de la solució.

El ping de la passarel·la prova un flux que el teu client no fa servir mai

L’adreça d’origen decideix quina política s’aplica. Un paquet generat a la passarel·la surt amb una adreça de la seva LAN local o del seu extrem del túnel, i la política que hi coincideix es va escriure exactament per a aquest cas. El paquet d’un client arriba a la interfície OpenVPN amb una adreça del pool de clients, que és un selector completament diferent.

Per això la fallada sembla un problema d’encaminament quan en realitat és un problema d’abast de la política. La connectivitat des de la passarel·la demostra que el peer és actiu i que les propostes s’han negociat, i no demostra res sobre si el pool està protegit.

Empeny el prefix remot que l’aplicació necessita realment

Pren la parella il·lustrativa 10.8.0.0/24 per als clients connectats i 172.30.239.0/25 per a la xarxa remota protegida. El que un client necessita és una ruta cap a aquest segon prefix, no cap a la LAN de la passarel·la ni cap a cap altra adreça de túnel. Una ruta empenyada al pool és el que fa que el client lliuri aquest trànsit a la passarel·la. Sense ella, el paquet no arriba mai a la decisió de política que estàs depurant.

En un servidor Community que accepta rutes empenyades, la directiva pren la màscara real: push "route 172.30.239.0 255.255.255.128". Access Server configura la mateixa destinació mitjançant la configuració de xarxa privada o de regles d’accés de la versió instal·lada, amb el mode encaminat o traduït triat deliberadament. Editar les cadenes de tallafoc generades en lloc de la configuració propietària és com una instal·lació funcional es torna impossible de reproduir.

Després de connectar, llegeix la taula d’encaminament del client i no la intenció del servidor. Una ruta que només cobreix el pool vol dir que l’empenyiment no ha arribat, i una ruta per defecte pel túnel és més àmplia que aquest requisit i et sorprendrà més endavant. Comprova la màscara i també el prefix, perquè un /25 empenyut com a /24 envia el trànsit d’adreces veïnes per un camí que no el pot portar. Després confirma que el client ha triat la interfície del túnel per a aquesta destinació.

Fes que els selectors incloguin el pool de clients

Per a un accés encaminat que conserva les adreces dels clients, la política IPsec ha de protegir el trànsit entre el pool i el prefix remot. Els selectors escrits per a la LAN pròpia de la passarel·la admeten el ping i descarten la petició del client, i aquesta és exactament l’asimetria que va iniciar aquesta investigació.

Inspecciona la política negociada i també les propostes configurades, per exemple amb ipsec statusall a strongSwan o l’ordre d’estat equivalent de la teva implementació. Amb IPsec basat en polítiques, la ruta ordinària pot apuntar a una interfície física mentre el trànsit coincident encara es xifra, així que un dispositiu de túnel absent no demostra res. Compara les parelles de selectors amb el pool i el prefix que vas anotar.

El NAT d’origen genèric a la passarel·la també pot trencar la coincidència. Si una regla de masquerade reescriu l’origen del client abans de la comprovació de política, el paquet ja no sembla el selector que vas escriure. Aquesta és una raó per la qual una regla de masquerade àmplia és una mala solució per a un segon VPN: canvia quina política s’aplica i quina adreça registra el costat remot. Eximeix el trànsit que vols encaminar, o tradueix-lo deliberadament i actualitza els selectors.

Tria encaminament o traducció a propòsit

L’encaminament manté l’adreça del client visible per al costat remot, així que els registres remots i les regles per origen continuen tenint sentit, i requereix que la passarel·la remota conegui el camí de retorn al pool. La traducció amaga el pool darrere una sola adreça, cosa que elimina el problema de la ruta de retorn i destrueix la identitat de cada client.

Tria un disseny i escriu-lo, perquè els dos necessiten selectors diferents i un ordre de tallafoc diferent. Un masquerade mig aplicat queda entremig i no satisfà cap dels dos. L’elecció escrita també és el que permet al següent enginyer distingir un error d’una decisió deliberada.

Tanca el bucle amb el reenviament i la resposta

La passarel·la ha de reenviar el protocol i la destinació que vols, cosa que vol dir reenviament IP activat i una cadena de reenviament que permeti la parella. Després el costat remot ha d’enviar les respostes de tornada pel camí IPsec, i això és una decisió d’encaminament a la seva passarel·la i no a la teva. Totes dues meitats són configuració corrent, i totes dues són fàcils de deixar a mitges. Prova-les per separat perquè una regla de reenviament absent no es confongui amb un túnel trencat.

Verifica amb una petició real de client a aplicació, mirant com travessa la interfície OpenVPN, la decisió IPsec i l’amfitrió remot. Inspecciona la resposta com una observació separada, perquè una petició que arriba i una resposta que no torna mai es veuen iguals des del seient del client. Una petició traçada val més que qualsevol nombre de pings des de la passarel·la.

Mantén l’autorització de destinació estreta mentre proves, i confirma que un client sense la regla no pot arribar al servei. Una ruta instal·lada més una associació establerta no és el mateix que un accés concedit.