OpenVPN: l’adreça local davant l’adreça del túnel: dos sockets diferents
L’adreça que contacta amb el servidor no és l’adreça de dins del túnel. Llegir local, remote i nobind com a rols separats explica la majoria d’errors d’enllaç.
El client es nega a arrencar i es queixa que no pot enllaçar una adreça local, i la solució òbvia sembla apuntar-lo a l’adreça del túnel que espera rebre. Això no pot funcionar, i la raó val la pena entendre-la: abans que existeixi el túnel no hi ha cap adreça interior, i el socket que contacta amb el servidor ha d’existir primer. Hi ha dues adreces diferents i només una es pot triar localment.
L’error d’enllaç anomena una adreça local
Quan OpenVPN informa que no pot enllaçar una adreça local, parla del socket de transport: el punt final UDP o TCP que porta la connexió xifrada fins al peer.
Una directiva local explícita demana al dimoni que enllaci aquest socket a una adreça local concreta. L’adreça ha d’existir a l’espai de noms de xarxa on s’executa el procés i ha de ser assignable en el moment en què arrenca el client.
Una adreça pública traduïda en un router o a la vora del núvol no és una adreça local que el dimoni pugui enllaçar, encara que sigui l’adreça que veu el servidor. Aquesta distinció explica per què un perfil funciona a casa i falla en una instància de núvol. També explica per què afegir l’adreça pública a una interfície de loopback no ajuda, ja que llavors el transport sortiria d’una adreça a la qual la xarxa no pot tornar. Llegeix la llista d’interfícies abans d’editar el perfil.
Què seleccionen realment local i remote
remote anomena el peer amb qui contactar. local enllaça l’extrem proper del mateix socket. nobind deixa que el sistema operatiu triï tant l’adreça local com el port, i per això els clients darrere de routers domèstics solen funcionar sense cap de les dues directives.
Cap de les dues directives té res a veure amb l’adreça de dins del túnel.
En un contenidor o un espai de noms de xarxa s’aplica la mateixa regla amb límits més estrets: les adreces de l’amfitrió no hi són a dins, així que una línia local copiada de la configuració de l’amfitrió falla per un motiu completament diferent del d’una adreça incorrecta.
ip -brief address show
ip route get 203.0.113.10L’adreça interior ve del servidor
L’adreça de dins del túnel es negocia o s’assigna després d’establir el canal de control. Amb un pool dinàmic el servidor la decideix en connectar, i amb una configuració específica del client pot estar fixada per identitat.
Escriure local amb una adreça interior no demana al servidor que assigni aquesta adreça. En el millor cas l’enllaç falla; en el pitjor el client troba una adreça d’amfitrió no relacionada amb el mateix valor i comença a fer-la servir per al transport.
Les interfícies que cal llegir també són diferents. Els paràmetres de ifconfig i la configuració del pool descriuen l’interior, mentre que remote, local, proto i nobind descriuen l’exterior. Mantenir les dues llistes separades explica gairebé tots els exemples confusos que trobaràs en un fòrum. El manual d’OpenVPN 2.6 els documenta en seccions separades per aquest motiu.
El parany: un túnel complet que captura el seu propi transport
Un cop el túnel està aixecat i porta la ruta per defecte, els paquets que el sostenen no s’han d’encaminar cap a dins. És un problema d’encaminament i no d’adreçament, i el dimoni el resol instal·lant una ruta més específica cap a l’adreça del servidor a través de la passarel·la original.
Si fixeu el transport a una adreça local concreta i després canvieu el camí que fa servir aquesta adreça, la connexió exterior pot perdre’s mentre l’interior continua configurat. El túnel segueix informant que està connectat perquè l’interior està bé. Només el transport està trencat, i per això els registres es llegeixen com a contradiccions.
Llavors els símptomes semblen un túnel que connecta i es congela, o un que es reconnecta en bucle sense cap error útil. Comprova la ruta cap a l’adreça del peer abans de comprovar res de dins del túnel, i confirma que l’adreça local que has enllaçat encara pertany a la interfície que esperaves.
Un hàbit que evita la confusió
Llegeix cada adreça d’un perfil i decideix a quina capa pertany abans d’editar-la.
Si anomena l’extrem llunyà del transport o n’enllaça l’extrem proper, és una adreça exterior i ha d’existir abans de l’arrencada. Si descriu què passa dins del túnel, ve del servidor o de la topologia, i cap directiva local no la pot substituir.
Escriu les dues llistes a les notes de desplegament al costat del perfil. La propera sessió de resolució de problemes començarà llavors per la capa en lloc de per una conjectura.