La VPN s’ha traslladat: per què el client OpenVPN encara marca l’IP antiga

El proveïdor ha canviat la vostra adreça pública, heu actualitzat el registre DNS dinàmic i el client encara no es pot connectar. Des de fora sembla que el registre no s’hagi propagat. La majoria de les vegades el registre és correcte i el client marca l’adreça que havia resolt abans del trasllat, perquè un túnel en marxa i un perfil desat tenen cadascun la seva pròpia idea de on viu el servidor. Tres capes han de coincidir, i s’actualitzen amb calendaris diferents.

Mireu què marca el perfil, no què diu el DNS

Obriu la connexió que feu servir realment i llegiu la línia remote. Una adreça numèrica allà no segueix mai una actualització de nom d’amfitrió, per correcte que esdevingui el registre.

Després comproveu si el perfil que heu editat és el que el client ha carregat. Els perfils importats són habituals: un gestor pot haver-ne fet una còpia fa mesos i haver-ne guardat la seva versió, així que el fitxer de la carpeta de baixades i l’entrada de l’aplicació poden discrepar. Compareu el punt final a les dades de connexió del propi client abans de començar a depurar el DNS.

Dos fitxers, un punt final: aquesta és la troballa habitual aquí.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Llegiu el següent intent de connexió del client

Reinicieu la connexió amb registre detallat i llegiu la línia on s’anomena l’adreça amb què contactarà. Aquest valor és el que importa, no el que ha resolt el navegador.

La memòria cau del resoledor encara pot guardar la resposta anterior, i algunes xarxes la guarden més temps del que demana el TTL del registre. Consulteu el resoledor que el client fa servir realment, no un de públic que hàgiu provat des d’un altre lloc.

Si el registre mostra l’adreça nova i la connexió encara falla, el problema s’ha mogut: el paquet va enlloc i ningú no respon. És una qüestió d’escoltador, tallafocs o redirecció de port, i és al costat del servidor, no al camí de resolució del client. Manteniu aquests dos fracassos separats, perquè tractar un escoltador inabastable com un problema de DNS us fa fer dues vegades el mateix bucle.

Saber quin reinici feu

No tots els reinicis conserven el mateix estat, i per això un canvi d’adreça es pot comportar de manera diferent segons com es recicli el procés. Un reinici suau provocat per un senyal conserva més context de la sessió anterior, mentre que una aturada i arrencada completa torna a començar des de la configuració. Si proveu si el client torna a resoldre, voleu el camí que arrenca des de la configuració.

La configuració de persistència també importa, perquè està pensada per conservar allò que s’ha autenticat i no per perseguir adreces noves.

La prova més neta és un arrencada nova des del perfil previst, seguida d’una mirada a la línia de registre que anomena el punt final. Tot el que aprengueu d’una sessió parcialment conservada és una afirmació sobre aquesta sessió.

Les quatre opcions i les seves tasques separades

remote amb un nom d’amfitrió és l’ajust que fa possible la resolució repetida; una adreça literal en aquesta línia ho exclou. resolv-retry controla què passa quan falla una consulta, i la 2.6 ja el posa en infinit per defecte. Afegir-lo, doncs, no canvia res, i mai no programa una comprovació periòdica d’una resposta diferent. Qui diu que sondeja adreces noves ha confós la recuperació amb la frescor.

persist-remote-ip tracta de continuïtat, no de frescor: reutilitza el punt final que es va autenticar l’última vegada, durant els reinicis suaus que admet. Mentre proveu un trasllat, això és el contrari del que voleu. Desactiveu-lo per a la prova si la vostra compilació l’activa, i torneu-lo a activar quan el punt final nou estigui provat. Si el deixeu activat, una reconnexió correcta pot no dir-vos res sobre el DNS.

float accepta un company autenticat l’adreça del qual ha canviat a mig camí de la sessió, i només en configuracions que ho admeten. No refresca el DNS i no seguirà un canvi de proveïdor pel seu compte. Tracteu-lo com una funció de resiliència per a companys que van d’un lloc a un altre, no com un mecanisme d’adreces dinàmiques per a servidors.

Confirmeu el punt final nou abans de culpar el client

Des de fora de la vostra xarxa, comproveu que l’adreça nova té un escoltador al port configurat i que la redirecció del proveïdor hi apunta. Un registre A correcte per a una màquina sense port obert produeix exactament el símptoma que la gent atribueix a la memòria cau.

Després torneu-vos a connectar i verifiqueu dues coses: el client s’ha autenticat contra el certificat de servidor esperat i la sessió arriba al recurs que us proposàveu. Un canvi d’adreça no rebaixa els requisits d’identitat, i una connexió que té èxit cap a un punt final equivocat és pitjor que una que falla. El manual d’OpenVPN 2.6 llista les quatre opcions amb el seu abast propi, i és la llista de comprovació que cal tenir al costat del perfil.

Manteniu una via fora de banda cap al servidor abans de reiniciar el túnel que porta el vostre accés administratiu. Aquesta sola precaució evita la majoria d’incidents que produeix aquest escenari.