Cae a VPN tras unha renovación DHCP? Compare as direccións

A renovación do arrendamento e o fallo da VPN aparecen xuntos nos rexistros con suficiente frecuencia como para que a xente conclúa que un causa o outro. A coincidencia temporal é real; a causalidade normalmente non. Unha renovación é unha solicitude unicast ao servidor que emitiu o arrendamento, pedindo continuar coa mesma vinculación, e o servidor pode ampliala sen que o cliente cambie unha soa dirección. Revisar os valores propios do cliente arredor do evento separa un arrendamento renovado en silencio dunha rede que cambiou de verdade baixo un túnel en funcionamento.

Comece polo cliente que caeu

Abra primeiro o rexistro de conexión do cliente e anote a hora da caída ao segundo. Despois abra o rexistro de rede do sistema operativo para o mesmo minuto e lea en orde que fixo a interface. Esa orde é toda a investigación: un evento DHCP antes da desconexión, unha desconexión antes do evento DHCP e dous eventos sen nada entre eles son tres achados distintos. Unha liña de rexistro que só menciona o arrendamento mentres o túnel xa se reconectaba é decoración, non proba.

Escriba a liña temporal sobre a marcha en lugar de retela na memoria. As marcas de tempo de ferramentas distintas raramente coinciden de todo, e o desfase mesmo ás veces é a explicación.

Compare os catro valores arredor do evento

Catro valores describen o lado local dunha conexión o bastante ben como para detectar un cambio real: o enderezo da interface, a pasarela predeterminada, a lista de resolucións e o estado operativo da interface. Capture-os no minuto seguinte á caída e compáreos cunha captura tomada mentres o túnel estaba san.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Un enderezo sen cambios cunha pasarela sen cambios e unha lista de resolucións cambiada apunta á resolución de nomes e non ao encamiñamento, e o túnel puido sobrevivir mentres as aplicacións deixaban de atopar hosts. Unha pasarela cambiada significa que o camiño de saída da rede local se moveu, o que abonda para invalidar unha ruta que apuntaba á anterior. Se os catro valores coinciden coa captura san, o arrendamento non é a súa causa e a lóxica de reconexión do propio cliente pasa a ser o tema. Capture a comparación mentres o fallo é visible, porque unha captura san tomada tras un reinicio ten un historial de enderezos distinto e non coincidirá.

Que pode e que non pode cambiar unha renovación

RFC 2131 describe a renovación como unha solicitude ao servidor orixinal na metade do tempo de arrendamento, con revinculación a calquera servidor aos sete oitavos se o primeiro intento queda sen resposta. Ningún dos pasos esixe que o cliente adquira unha dirección distinta, e un servidor cooperativo normalmente amplía a vinculación existente. Un cambio real de enderezo adoita chegar por outro camiño: un servidor que rexeita a renovación, un cliente que perdeu o seu estado e comezou de novo, ou unha rede que moveu o dispositivo a outro segmento.

O lado público da conexión pode cambiar sen ningún cambio local. Detrás dunha tradución de grao operador, o enderezo que ve o par da VPN pode reasignarse con independencia do que fixera o arrendamento local, e esa reasignación vese idéntica a un fallo de rede local desde dentro do cliente. Comparar un enderezo informado localmente cunha observación do lado do par é a única forma de separalos.

Cando o cliente non logra adaptarse

Un cliente que vinculou o seu transporte ao enderezo antigo, almacenou unha ruta obsoleta cara ao par ou gardou unha identidade de interface pode seguir reintentando un camiño que xa non existe. Iso é un defecto de adaptación, e vese como retransmisións repetidas cara a un enderezo que o host xa non pode acadar. Algúns clientes xestiónano por deseño: WireGuard, por exemplo, actualiza o extremo dun par cando chega un paquete correctamente autenticado desde unha fonte nova.

Un reinicio manual que restaura o servizo é unha pista sobre onde fallou a adaptación, non unha proba de que arrendamentos e túneles sexan incompatibles. Manteña a política de bloqueo durante a proba, ou a propia proba convértese nunha caída con outra causa. Anote se o cliente se recuperou só, canto tardou e a que enderezo reintentou; esa secuencia dille máis que o motivo de desconexión que mostra a interface.

Repita o evento antes de culparlo

Reproduza a condición en lugar de agardar o calendario: libere e renove o arrendamento, ou force o evento controlado equivalente, e observe se o túnel sobrevive. Nunha rede xestionada, coordine calquera cambio de enderezo co propietario da rede, porque unha asignación estática arbitraria pode chocar cun dispositivo que xa ten ese enderezo.

Tras unha corrección soportada, repita o mesmo evento e despois probe unha aplicación e unha consulta de nome, porque un túnel que se reconecta pero rompe o DNS supera unha proba máis feble ca a que importa. Informe do cambio concreto que observou, coa súa marca de tempo, en lugar de nomear o arrendamento programado como causa. A diferenza entre eses dous informes é se a seguinte persoa pode reproducir o fallo ou só o rumor.