Per què un túnel d'Azure OpenVPN cau aproximadament cada seixanta segons
Un túnel que cau cada seixanta segons ha acabat l'apretada de mans, així que res no el bloqueja. Llegeix primer el motiu de la desconnexió i després compara tots dos temporitzadors keepalive.
El túnel acaba l'apretada de mans, porta trànsit durant aproximadament un minut i després es torna a connectar. Aquesta seqüència descarta el sospitós habitual, perquè un tallafoc que bloquegés el port hauria aturat l'apretada de mans i no la sessió. El que tens és un desacord sobre la vitalitat: un costat va decidir que l'altre s'havia quedat en silenci i va enderrocar un túnel que funcionava. La línia del registre diu quin costat, i això tria la solució.
Llegeix aquesta línia abans de tocar cap temporitzador.
El mite: alguna cosa al camí bloqueja el túnel
Si un port estigués bloquejat, la connexió fallaria al principi i continuaria fallant. Un cicle que es repeteix vol dir que els missatges de control flueixen, que les sessions s'estableixen i que alguna cosa més endavant a la conversa no deixa d'expirar. El bloqueig produeix silenci, i això produeix un ritme.
El ritme és la pista útil. Els temporitzadors el produeixen; la pèrdua de paquets rares vegades.
Llegeix el motiu de la desconnexió abans que el temporitzador
OpenVPN anomena el seu motiu, i cada nom apunta a un subsistema diferent. Session invalidated: KEEPALIVE_TIMEOUT és un temporitzador que expira, així que compara els valors de ping i ping-restart a tots dos extrems. AUTH_FAILED són credencials o estat del certificat, i cap canvi de temporitzador no ajudarà. Un error TLS vol dir que les parts ni tan sols van arribar a l'etapa keepalive.
Anota l'hora de connexió, l'hora de desconnexió i si l'interval és estable fins al segon. Aquesta única mesura separa un horari configurat d'una coincidència.
Un interval estable és un temporitzador. Un que deriva és més aviat un problema de camí o una sessió desplaçada.
Dos temporitzadors keepalive que mai no es van posar d'acord
Els perfils exportats del portal de vegades encara porten línies keepalive o ping-restart copiades d'una plantilla de servidor comunitari. La passarel·la fa la seva pròpia detecció de parell mort i imposa les seves expectatives, i els dos horaris no han de coincidir. Quan discrepen, el client es reinicia segons un horari que la passarel·la mai va acceptar.
Els dos valors no són el mateix control. ping és la freqüència amb què el client envia un eco, i ping-restart és quant espera sense sentir res abans d'enderrocar el túnel. Un perfil amb un ping-restart curt i una passarel·la que respon lentament es reiniciaran a cada període de silenci, que és exactament la forma d'un cicle d'un minut.
El canvi mínim al costat del client és neutralitzar els temporitzadors al nivell superior del perfil, fora de cada bloc en línia:
keepalive 0 0Desa, recarrega el perfil, torna a connectar. Una sessió que ja és a la memòria conserva els valors antics, i per això de vegades sembla que l'edició no ha fet res.
El nom del certificat es pot moure sota els teus peus
L'autenticació per certificat d'Azure depèn que el client confiï en el nom que la passarel·la presenta avui. Una línia verify-x509-name en una descàrrega antiga pot fixar un nom que una reconstrucció de la passarel·la o una renovació del certificat ha canviat des d'aleshores, i el desajust es manifesta com un bucle de reconnexió i no com un error clar. Esborrar la línia restaura la connectivitat, cosa que la converteix en un bon diagnòstic i una mala solució permanent, perquè també elimina la verificació. Quan el túnel aguanti, restaura la línia amb el nom que la passarel·la presenta realment.
Prova una segona generació de client a la mateixa màquina abans d'editar la passarel·la. Si un client fa bucles i l'altre aguanta, el problema no és el perfil.
Què cal canviar, i en quin ordre
Comprova després si hi ha una sessió desplaçada. Dos dispositius que comparteixen un certificat es poden fer fora l'un a l'altre, i el resultat sembla periòdic perquè tots dos costats es tornen a connectar. Compara els registres de sessió de punt a lloc de la mateixa identitat que apareix una i altra vegada.
Després prova el camí inactiu executant trànsit continu durant diversos minuts. Si les caigudes s'aturen mentre flueix el trànsit, el temporitzador que importa pertany a un dispositiu NAT o a un balancejador de càrrega del camí, no a OpenVPN.
Només després d'aquestes quatre proves s'han de canviar els paràmetres de la passarel·la.