A VPN por UDP atasca en repouso: o cortafuegos esqueceu o teu fluxo

A VPN conéctase, funciona un anaco e despois deixa de pasar tráfico mentres o cliente aínda mostra unha sesión. Reconectar arranxa o problema, o que fai que pareza un fallo do cliente. Normalmente é un cortafuegos ou un dispositivo NAT que descartou unha asignación UDP inactiva e non ten nin idea de que o túnel segue existindo.

O síntoma é o bastante consistente para diagnosticalo: aparece tras a inactividade, non baixo carga.

Como se ve un atasco por inactividade

Mídeo en lugar de describilo. Anota canto tempo o túnel fica inactivo antes de que o tráfico se deteña, se un paquete saínte novo o revive e se a interface do cliente aínda conserva o seu enderezo. Se unha petición nova do cliente funciona pero unha resposta a un fluxo existente non, a asignación é a sospeitosa. Se nada funciona ata que reconectas, o estado de sesión do cliente tamén se perdeu.

Ambos están relacionados coa inactividade e necesitan solucións distintas.

Apunta os tempos antes de cambiar nada. Un informe de que se detén tras uns dez minutos de inactividade é verificable, mentres que un informe de que cae ao chou non o é. Esa diferenza decide se persegues un temporizador ou un cambio de encamiñamento.

Atopa o dispositivo que esqueceu

Varios dispositivos poden manter estado para o mesmo fluxo: o router local, un tradutor augas arriba, unha fronteira de nube e o cortafuegos do host. Cada un ten o seu propio temporizador, e gaña o máis curto. Unha interrupción de cinco minutos adoita significar que un dispositivo está configurado moi por baixo dos demais.

Non deas por feito que o valor predeterminado documentado é o tempo de espera da túa ruta. É o valor predeterminado dun só dispositivo.

• Router doméstico: a miúdo minutos, ás veces moito menos.
• NAT na nube ou balanceador de carga: consulta o tempo de espera de inactividade documentado especificamente para UDP.
• Cortafuegos do host: os temporizadores de seguimento de netfilter aplícanse por fluxo.

Comproba os temporizadores na ruta real

En Linux, os temporizadores de seguimento de netfilter son visibles e axustables: sysctl net.netfilter.nf_conntrack_udp_timeout e net.netfilter.nf_conntrack_udp_timeout_stream. O segundo aplícase cando xa se viu tráfico nos dous sentidos, e por iso un túnel establecido pode sobrevivir a unha sonda simple.

RFC 4787 estabelece o comportamento de UDP NAT e os mínimos recomendados. É a referencia que hai que citar cando o valor predeterminado dun provedor parece inusualmente curto.

Keepalive e reconexión son ferramentas distintas

Un keepalive mantén viva unha asignación; unha reconexión reconstrúe unha sesión morta. Resolven fallos diferentes e non son axustes de velocidade intercambiables. A opción PersistentKeepalive de WireGuard envía un paquete a un intervalo fixo para manter aberta a vinculación NAT. A opción keepalive de OpenVPN fai o mesmo traballo á súa maneira. Ningunha axuda se o dispositivo intermedio xa esqueceu o fluxo e descarta as dúas direccións.

As sondas extremadamente frecuentes engaden traballo sen arranxar o límite equivocado.

Verifica cunha petición nova, non cunha recarga de páxina

Despois de cambiar un temporizador ou engadir un keepalive, repite o escenario de inactividade exactamente como antes. Logo fai unha petición realmente nova desde a aplicación cuberta. Unha lapela do navegador xa cargada pode renderizarse desde a caché e non dicirche nada.

Se o atasco persiste, móvete un salto cara a fóra e comproba a táboa de estados dese dispositivo.