OpenVPN cau després d’una renovació DHCP: manteniu la ruta de l’extrem

El túnel es connecta, després una renovació del contracte d’arrendament a l’enllaç d’accés el mata, i el registre culpa un temps d’espera en lloc d’una ruta. No ha canviat res a la configuració de la VPN, i aquesta és la pista: ha canviat alguna cosa de fora. Un esdeveniment DHCP ha reescrit l’adreça o la porta d’enllaç, i la ruta d’amfitrió que mantenia l’extrem del túnel abastable ara apunta a un salt següent que ja no existeix. Aquest és un problema de propietat abans que un problema d’encaminament.

Comproveu el símptoma contra les rutes mig predeterminades

Amb redirect-gateway def1, l’OpenVPN instal·la 0.0.0.0/1 i 128.0.0.0/1 en lloc de substituir la ruta predeterminada. Juntes, aquestes dues cobreixen tot l’espai d’adreces, i superen 0.0.0.0/0 només per la longitud del prefix. Per tant, qualsevol destinació sense una coincidència més específica entra al túnel.

L’extrem necessita una excepció. L’OpenVPN afegeix una ruta d’amfitrió cap a l’adreça del servidor a través de la porta d’enllaç d’accés original abans que entrin les mig predeterminades, per tal que els paquets encapsulats puguin sortir. Quan aquesta excepció desapareix, o conserva un salt següent que ja no existeix, els propis paquets exteriors del túnel coincideixen amb una mig predeterminada i es tornen a enviar dins del túnel. El resultat és una connexió que mor al següent keepalive o encaixada de mans, sense res al registre que sembli un error d’encaminament.

Confirmeu la forma de la taula abans de tocar res més. ip route show hauria de llistar les dues meitats més una ruta d’amfitrió per a l’adreça del servidor; quan falta la ruta d’amfitrió, la resta de la investigació té un punt de partida obvi.

Per què les mig predeterminades guanyen sense canviar la mètrica

Una mètrica més baixa no supera un prefix més llarg. Les rutes /1 guanyen perquè el nucli coincideix primer amb la ruta més específica, així que apujar una mètrica a la ruta predeterminada no canvia res sobre on va el trànsit destinat al túnel. Perseguir mètriques és el gir equivocat més comú en aquest diagnòstic.

Comproveu la selecció amb ip route get 203.0.113.10, substituint-hi l’adreça real del servidor. La resposta anomena la interfície i el salt següent que el nucli faria servir realment, cosa que és més informativa que llegir una taula i raonar-hi a sobre.

Executeu aquesta ordre abans que arrenqui el túnel, mentre està actiu i després de l’esdeveniment del contracte. Tres respostes d’una ordre, i el punt de divergència es fa visible.

Preneu tres instantànies, no una

Recolliu l’adreça d’accés, la porta d’enllaç d’accés, la destinació de l’extrem, la ruta seleccionada i qualsevol regla de política en tres moments: després de configurar l’enllaç d’accés, després que la VPN es connecti i després de l’esdeveniment del contracte o de l’operador. Cada instantània és un grapat d’ordres, i només tenen sentit juntes. Una sola instantània posterior a la fallada registra l’estat en lloc de la transició. Escriviu les ordres en un petit script perquè cada instantània es prengui de la mateixa manera.

Guardeu les instantànies en un sol fitxer amb marques de temps, perquè la pregunta interessant més endavant és l’ordre. L’esdeveniment DHCP va arribar abans o després que l’OpenVPN refresqués la seva ruta? La resposta decideix qui ho ha d’arreglar. Una marca de temps d’un rellotge equivocat és pitjor que cap, així que preneu-la de l’amfitrió que posseeix la taula d’encaminament.

Quan l’extrem està configurat com a nom en lloc d’adreça, resoleu-lo també a cada instantània. Un canvi de DNS a l’enllaç d’accés pot moure l’extrem sense tocar cap ruta.

Decidiu quin component refresca l’excepció

En un sistema dhcpcd, els ganxos s’executen des del directori de ganxos i des del ganxo de sortida, i el mode gestor difereix en abast del mode per interfície. Facis el que facis el ganxo, ha de ser idempotent, perquè les renovacions poden arribar en ràfegues.

El propietari fiable és la integració que ja coneix els dos costats: un gestor de xarxa que gestiona la connexió VPN, o una unitat ordenada després que l’enllaç d’accés pugi. Una ruta estàtica afegida per un ganxo funciona fins al següent canvi de porta d’enllaç, i llavors falla exactament de la mateixa manera. Si feu servir un ganxo, feu que llegeixi la porta d’enllaç actual en temps d’execució en lloc de codificar la que heu vist avui.

Registreu el propietari dins de la configuració. La propera persona que depuri una reconnexió ha de saber que és un ganxo, no la VPN, qui té responsabilitat sobre la ruta d’excepció.

Proveu el cicle de vida, no només la reconnexió

Forceu una renovació amb dhcpcd -n eth0 o alliberant i renovant el contracte, i després torneu a comprovar ip route get per a l’extrem. Feu-ho dues vegades, perquè la segona passada enxampa ganxos que afegeixen rutes duplicades. Després reinicieu, perquè la persistència és una propietat diferent de la correcció.

Un túnel que sobreviu a una renovació i a un reinici té propietari i una excepció que funciona. El que només sobreviu a un reinici manual no té ni l’un ni l’altre, i fallarà al proper esdeveniment que no podeu programar.