OpenVPN iroute contra la ruta del nucli: quina falta?

Un paquet per a 10.77.20.0/24 pren dues decisions separades en un servidor OpenVPN: el sistema operatiu l’ha de lliurar a la interfície VPN, i OpenVPN ha de saber quin client connectat posseeix aquest prefix. Una ruta del nucli absent el descarta abans del túnel, i una ruta del parell absent el descarta després. Els dos errors semblen idèntics des de la LAN remota, i diagnosticar quin teniu requereix una ordre a cada costat.

En el camí de dades clàssic en espai d’usuari, la ruta del nucli porta el paquet al procés del túnel i iroute diu a aquest procés quin parell l’ha de rebre. Cap de les dues substitueix l’altra, i una configuració que només en porta una semblarà raonable fins al primer ping.

Dues decisions, no una ruta

Imagineu un enllaç entre seus on 10.77.20.0/24 és darrere d’un sol client. La ruta del nucli del servidor, per exemple ip route add 10.77.20.0/24 dev tun0, envia els paquets coincidents al dispositiu del túnel. Aleshores OpenVPN consulta la seva taula interna, construïda a partir de les entrades iroute del directori de configuració del client, per decidir quina connexió de parell els rep. Sense la ruta del nucli el paquet no arriba mai al procés, i sense la ruta del parell arriba al procés i no va enlloc.

Aquesta divisió és fàcil d’oblidar, perquè una sola línia de ruta en un perfil de client pot semblar que fa les dues feines. No les fa: empènyer una ruta diu als clients què han d’enviar pel túnel, mentre que iroute diu al servidor qui posseeix un interval d’adreces darrere d’un client. Viuen en fitxers diferents, les llegeixen costats diferents i fallen en direccions oposades.

On pertany iroute i què diu

L’entrada va en un fitxer per client anomenat segons el common_name del client, dins de client-config-dir, com a iroute 10.77.20.0/24. La coincidència del nom del fitxer no és cosmètica: OpenVPN busca la identitat autenticada i llegeix el fitxer amb exactament aquell nom, així que un fitxer anomenat site-a només afecta un client el nom comú del qual sigui site-a. Afegiu ccd-exclusive si els clients sense aquest fitxer s’han de rebutjar de ple, que és la configuració correcta quan cada client és una passarel·la de seu. Manteniu un fitxer per passarel·la i anomeneu-lo segons el subjecte del certificat que realment emeteu.

Proveu l’entrada des del servidor abans de culpar la LAN remota. El fitxer d’estat llista els clients connectats amb els seus noms comuns, i un servidor que s’executa amb --verb 4 registra la instal·lació de iroute quan el parell es connecta. Si no apareix res en connectar-se, el fitxer és al directori equivocat o anomena la identitat equivocada.

El parany: fitxer present, identitat equivocada

Un iroute d’aspecte correcte lligat al parell equivocat fa perdre més temps que un fitxer absent, perquè tot al disc sembla correcte. El canvi de nom de certificats, els noms comuns duplicats i username-as-common-name canviant la identitat efectiva ho produeixen tot. Comproveu quina identitat ha autenticat el servidor en lloc de quina esperàveu: la sortida d’estat és autoritativa, mentre que el nom del fitxer només és una clau de cerca.

Una ruta també pot sobreviure al seu propietari. Les rutes estàtiques i les entrades iroute descriuen un prefix, no una garantia de disponibilitat, així que el trànsit pot continuar encaminant-se cap a un parell que ara mateix està desconnectat.

Completeu el camí més enllà del parell

La propietat del parell és el mig del camí, no el final. El client ha de reenviar paquets del túnel a la seva LAN, cosa que vol dir reenviament IP activat en aquell amfitrió i una regla de tallafocs que permeti el trànsit. Els amfitrions de la LAN remota necessiten un camí de tornada per a l’adreça del túnel: o una ruta que apunti de nou a la passarel·la, o un disseny de NAT deliberat al costat del client. Confirmeu el paràmetre de reenviament al client amb sysctl net.ipv4.ip_forward en lloc de suposar un valor per defecte de la distribució.

Si altres clients VPN han d’arribar a aquesta subxarxa, l’arranjament torna a créixer: el servidor necessita client-to-client, i aquests clients han d’encaminar el prefix pel túnel. Res d’això no ve implicat per la pròpia taula de rutes del servidor.

Verifiqueu una destinació des d’una font real en lloc del mateix servidor. Un ping des d’un amfitrió LAN no relacionat fins a un amfitrió darrere del client exercita el camí de tornada, la regla de reenviament i la propietat del parell en un sol moviment, mentre que un handshake correcte només demostra identitat. Després desconnecteu el parell propietari i anoteu què fa la ruta, perquè aquesta resposta és la vostra manera de fallar.