Dos dispositius, un certificat OpenVPN: el bucle de reconnexió

Un túnel que s’aixeca i després es reinicia cada mig minut no sol ser un problema de xifratge ni d’MTU. És una identitat feta servir dues vegades. El servidor veu un nom comú conegut, pren la sessió nova com la més recent, i el dispositiu més antic descobreix que ha estat substituït. Des del costat del client això sembla un temps d’inactivitat i un reinici, i per això la investigació tantes vegades comença al lloc equivocat.

Comença per l’interval de reinici

L’interval és una pista abans que res. Una cadència regular que coincideix amb la finestra ping-restart apunta a una sessió substituïda més que a un camí fallit, perquè les fallades de camí rares vegades són tan regulars. Anota l’interval exacte entre reinicis i la línia de motiu al registre del client. Un temps esgotat seguit d’un reinici explica una història diferent d’una negociació fallida.

Comprova quan van començar els reinicis respecte d’un segon dispositiu. Un portàtil nou, un telèfon o un perfil copiat a una màquina de recanvi són els desencadenants habituals, i el moment sol coincidir amb el dia que algú el va configurar.

Apunta l’interval i el motiu. Tots dos són proves, i tots dos són barats de recollir.

Llegeix què va dir el servidor del segon inici de sessió

En un servidor que controles, el registre anomena el nom comú i mostra una segona connexió que arriba. Sense duplicate-cn, aquesta arribada substitueix la sessió existent per al mateix nom, i el missatge normalment ho diu ben clar. Amb duplicate-cn, les dues sessions conviuen i el símptoma canvia: els clients es queden connectats però comparteixen un sol joc de paràmetres per client i una sola decisió de revocació. Llegeix les dues entrades juntes, perquè la substitució només es veu en seqüència.

En un servei allotjat potser no tens cap registre del servidor. Llavors la pista és el moment: un túnel estable que cau sempre que es connecta una altra màquina, sense res al registre del client més enllà del temps esgotat.

Compara els blocs de certificat i clau dels dos perfils, no només el nom d’amfitrió remot. Els perfils copiats normalment només difereixen en el nom del fitxer.

Separa la identitat al costat del servidor

Emiteix un certificat per dispositiu a través de l’autoritat que signa per a aquest servidor. Amb Easy-RSA això vol dir un nom de client separat per a cada dispositiu, i el perfil es construeix després amb aquest certificat i la seva clau. El nom comú es converteix en la identitat del dispositiu, que és exactament el que li faltava al servidor. Anomena’ls pel dispositiu i no per la persona, perquè una substitució produeixi un nom nou.

La clau compartida del canal de control és una altra cosa. tls-crypt o tls-auth protegeix el canal de control de cada client i està pensat per compartir-se. No és una identitat de client, i substituir-la no arreglarà un certificat duplicat.

Mantén el certificat, la clau i qualsevol fitxer de configuració per client amb el mateix nom comú, o el mapatge es trenca a la connexió següent. Una discrepància allà produeix un client que s’autentica i després no rep res.

Mantén adreces i paràmetres alineats després de la separació

Les adreces fixes introdueixen una segona manera de xocar. Si el servidor les assigna mitjançant ifconfig-pool-persist o un fitxer per client, aquests registres encara apunten al nom antic. Dos dispositius poden acabar amb la mateixa adreça de túnel fins i tot després de separar els certificats, i aquesta fallada es veu diferent del bucle original.

Actualitza el mapatge al mateix temps que el certificat, després reconnecta els dos dispositius i compara les adreces assignades. Una adreça duplicada es mostra com a pèrdua intermitent més que com una reconnexió neta.

Envia els paràmetres que han de diferir per dispositiu a través del fitxer propi d’aquell dispositiu, no d’una plantilla compartida. Una plantilla compartida també fa més difícil detectar el proper duplicat.

Retira la identitat antiga com cal

Revoca el certificat quan es retira o es perd el maquinari, en lloc d’esborrar el perfil de la màquina antiga. La revocació produeix una CRL nova, i el servidor necessita aquest fitxer on apunta crl-verify. Amb aquesta directiva al seu lloc, una CRL absent o il·legible fa que el servidor rebutgi tots els clients, així que prova un compte conegut després de cada actualització.

Mantén un inventari que lligui cada certificat a una persona o dispositiu, amb dates d’emissió i de revocació. Aquest inventari respon qui encara té accés sense llegir noms de fitxers, i evita que el proper perfil copiat torni a començar el bucle.