Usuari de passarel·la d’Access Server: encaminar la LAN de la branca d’un client

Podeu fer ping a l’adreça del túnel d’un client OpenVPN i tot i així no arribar a cap amfitrió de la LAN que hi ha darrere. Access Server dona a aquest client una adreça del pool VPN, i l’adreça del pool és tot el que el servidor sap que posseeix. El prefix de la branca és un fet separat que s’ha de declarar, i fins i tot aleshores la branca necessita un reenviador i la seu un camí de tornada. Una ruta escrita al lloc equivocat sembla una solució i no canvia res.

Dues adreces, dues reclamacions de propietat diferents

Quan un client es connecta, Access Server li assigna una adreça del pool VPN configurat, per exemple 10.90.0.0/24. Aquesta assignació és un arrendament per a un sol amfitrió. Res de la connexió no diu que el mateix client també sigui davant de 10.60.0.0/24, i el servidor no ho endevinarà: un prefix LAN només és abastable a través d’un client concret si un administrador ho declara.

Per això una ruta estàtica en una altra màquina no serveix. La ruta diu envieu 10.60.0.0/24 a aquesta adreça, però si l’adreça pertany a un client que no s’ha marcat com a passarel·la, el servidor no té cap motiu per lliurar-hi aquests paquets, i la pila del client els pot descartar. La declaració i la ruta són dues meitats d’un mateix mecanisme.

Què instal·la realment el paràmetre de passarel·la

A l’Admin Web UI la declaració és una propietat d’usuari: activeu Configure VPN gateway a l’usuari connector i introduïu el prefix real de la branca a Network on the VPN client side. Aquest usuari s’autentica com qualsevol altre, així que necessita una política de credencials adequada a un dispositiu sense supervisió, i el seu perfil d’inici automàtic és un secret, no un fitxer de comoditat.

Darrere d’aquesta casella el servidor tracta el prefix com a abastable a través de l’adreça del pool d’aquell client, i la configuració d’encaminament d’Access Controls decideix què s’anuncia als altres clients: les rutes que s’envien als clients ordinaris i les regles d’accés que permeten el trànsit de les xarxes de la seu cap a les adreces i subxarxes dels clients. Activeu l’encaminament per a les xarxes que han d’arribar a la branca i manteniu curta la llista de xarxes permeses.

Una directiva d’estil Community enganxada en un fitxer generat no participa en aquest model. El producte és propietari de la taula d’encaminament que envia; una línia editada a mà es sobreescriu en la propera generació o s’ignora.

Completeu els camins de tornada de les dues xarxes

Un pla concret: seu 10.40.0.0/24, branca 10.60.0.0/24, pool VPN 10.90.0.0/24, i Access Server abastable en una adreça privada del costat de la seu. L’encaminador de la seu necessita rutes per al prefix de la branca i per al pool, totes dues cap a Access Server. Sense elles el túnel porta la petició i la resposta surt per la passarel·la per defecte, cosa que produeix la clàssica connexió mig oberta.

A la branca el connector ha de reenviar els paquets que no van adreçats a ell: reenviament IP al seu sistema operatiu més un permís de reenviament limitat a les interfícies del túnel i de la LAN; a Linux és net.ipv4.ip_forward=1 amb les regles de la cadena forward, a Windows és routing and remote access. Després els amfitrions de la branca necessiten un camí de tornada: o el connector és la seva passarel·la per defecte, o la passarel·la existent porta rutes específiques per als prefixos de la seu i del pool.

La taula d’encaminament del connector no reconfigura tots els amfitrions de la LAN de la branca. Si els amfitrions apunten a un altre encaminador, les rutes de tornada hi pertanyen, i aquest encaminador ha d’acceptar que l’adreça d’origen que veu no és un veí de la subxarxa local.

Llegiu una fallada com un camí, no com un permís

Proveu en un ordre fix. Primer un servei permès d’Access Server a un amfitrió de la branca, després el mateix servei des d’un amfitrió ordinari de la seu, i després la direcció inversa si la política ho permet. Si el primer passa i el segon falla, el problema són les rutes enviades o les regles d’accés. Si tots dos passen però no arriben respostes, examineu el reenviament a la branca i la ruta de tornada a la seu.

El tallafoc de l’amfitrió és el següent sospitós, perquè amb accés encaminat la destinació veu com a origen una adreça de la seu o del pool. Una regla escrita per a la subxarxa local no coincidirà i el paquet es descarta després que l’encaminament hagi funcionat perfectament.

Dos dissenys necessiten més que aquest patró. Els prefixos solapats entre llocs fan ambigua la destinació i exigeixen renumeració o traducció, i un Access Server en clúster necessita que cada node tingui un camí funcional cap al connector de la branca, no un sol node que retingui la ruta. Apliqueu els canvis pel camí normal de desar i actualitzar, torneu a connectar el connector i verifiqueu-ho des dels dos extrems; reiniciar completament cada màquina no forma part del procediment.

El tutorial site-to-site d’Access Server llista els mateixos paràmetres en ordre de producte; val la pena seguir-lo un cop abans d’adaptar el disseny als vostres prefixos.