Per què no és accessible la subxarxa darrere d'un client OpenVPN?

Els pings a l'adreça del túnel del servidor funcionen, la taula de rutes del client sembla correcta i la LAN darrere d'aquest client continua sense ser accessible. La taula d'encaminament del client sembla correcta, el servidor té una ruta que apunta al túnel i els paquets continuen desapareixent. És el símptoma clàssic d'un túnel layer-3 que no sap que un dels seus clients també és una passarel·la.

Una interfície tun no té següent salt per client. El nucli veu una sola interfície amb molts parells, així que la decisió de quin client ha de rebre un paquet per a una LAN remota s'ha de prendre dins del procés OpenVPN. Aquesta decisió es configura amb iroute i, sense ella, el paquet no té on anar.

El servidor encamina per client, no per interfície

Quan el servidor ha d'enviar un paquet a l'adreça del túnel d'un client, la resposta és inequívoca: l'adreça pertany a la sessió d'aquest client. Quan la destinació és tota una subxarxa darrere d'aquest client, l'adreça no pertany a ningú que el servidor conegui, i la ruta del nucli cap al túnel només diu "per aquesta interfície", sense dir quin parell.

OpenVPN ho resol amb una taula d'encaminament interna que assigna un prefix de destinació a un client concret. Aquesta taula es construeix amb entrades iroute, i per això una ruta normal a l'amfitrió del servidor no n'hi ha prou. La ruta del nucli porta el paquet a la interfície del túnel; l'assignació interna decideix quina sessió el rep. Per això també la reparació no apareix mai a la sortida de rutes del nucli.

Si falta l'assignació, el paquet arriba al servidor, coincideix amb la ruta del túnel i es descarta perquè cap client reclama la destinació. Res no registra un error net, i per això la fallada sembla un forat negre silenciós més que un bucle d'encaminament.

Escriure l'entrada iroute que anomena el client

iroute viu en un fitxer de configuració específic del client, no en la configuració principal del servidor. Apunteu el servidor a un directori amb l'opció client-config-dir, després creeu un fitxer el nom del qual sigui el nom comú del certificat del client i poseu-hi el prefix a dins.

Per a una branca la LAN de la qual és 10.20.0.0/24 i el nom comú del certificat branch-router, el fitxer en aquest camí conté una línia com iroute 10.20.0.0 255.255.255.0. La configuració principal només necessita l'opció del directori; el prefix viu amb el client.

El nom comú és la part fràgil. Un certificat emès amb un subjecte diferent, o un desplegament que autentica usuaris pel nom d'usuari mentre el fitxer es diu com el certificat, produeix un fitxer que mai es llegeix. Comproveu el nom que el servidor informa realment per a la sessió i considereu l'opció que fa fallar un client no coincident en lloc de connectar-se silenciosament sense les seves rutes. Canviar el nom del fitxer perquè coincideixi amb el certificat és una correcció de cinc minuts que evita un vespre molt llarg.

Un client pot posseir diversos prefixos. Afegiu una línia iroute per xarxa i manteniu la llista al costat de la resta de la configuració d'aquest client perquè l'assignació sigui auditable.

Construir el camí de tornada en tots dos sentits

Fer arribar paquets a la LAN remota és la meitat de la feina. El client també ha d'enviar el trànsit d'aquesta LAN al túnel, cosa que normalment es fa empenyent una ruta al client: una línia com push "route 10.8.0.0 255.255.255.0" diu a cada client com arribar a la xarxa del costat del servidor. Per a la branca, la ruta equivalent apunta al túnel per a tot allò que hagi d'assolir al costat del servidor.

El sentit de tornada necessita un propietari a l'altre costat. En aquell costat, algú ha de conèixer el camí de tornada: una ruta estàtica al router de la LAN que apunti el pool de VPN al servidor, o traducció d'adreces al servidor abans que el trànsit entri a la LAN. La ruta estàtica manté les adreces originals visibles als registres i a les regles d'accés, però requereix la col·laboració del propietari de la LAN; la traducció és autosuficient, però amaga qui s'hi va connectar realment.

L'encaminament ha d'estar activat a l'amfitrió del servidor. Sense això, el nucli accepta el paquet del túnel i es nega a passar-lo a la interfície de la LAN, cosa que des del punt de vista del client sembla idèntica a una iroute absent.

Comprovar l'abast amb les sondes correctes

Proveu per capes en lloc de fer ping a l'extrem remot i endevinar. Des del servidor, comproveu que l'assignació interna per al prefix existeix i que la ruta del nucli apunta al túnel. Des del client, confirmeu que la ruta empenyuda està instal·lada i que el seu camí per defecte per a l'adreça de la LAN és el túnel.

Després observeu els paquets. Una captura a la interfície del túnel mostra si el servidor transmet cap al client, i una captura a la interfície de la LAN mostra si reencamina. Si la primera mostra paquets i la segona no, el problema és l'encaminament o un filtre; si cap de les dues no mostra res, la cerca va fallar abans.

Dos servidors units per un túnel repeteixen la mateixa regla als dos costats: cadascun necessita una iroute per al pool de l'altre, i cadascun necessita la ruta i l'encaminament que fan simètric el camí. Encaminament i política són assumptes separats aquí. L'encaminament decideix on pot anar un paquet, mentre que una regla FORWARD decideix si pot, així que un client amb dues línies iroute pot arribar als dos prefixos tret que un filtre digui el contrari.