OpenVPN funciona na casa pero non nunha rede: UDP ou TCP?

O mesmo perfil conéctase desde a casa e atasca nunha rede de hotel, campus ou sucursal. As credenciais non cambiaron, así que a variable interesante é a ruta: que pasa cos paquetes antes de que OpenVPN os lea. Comparar catro causas candidatas na orde en que se poden probar supera adiviñar sobre certificados. Cada unha deixa un rastro distinto, e o rastro é o que as separa.

Que etapa fallou di que comparación importa

O rexistro do cliente xa anota ata onde chegaches. Unha liña que di que a negociación de clave TLS non ocorreu dentro do prazo significa que un primeiro paquete saíu e non volveu nada usable, o que apunta á ruta. O rexeitamento dun certificado vese moi distinto: chega unha resposta e despois un erro de verificación concreto nomea a causa. Fíxate na última liña antes do bucle de reintentos, porque ese é o valor que comparas entre redes.

Captura mentres reintentas, non despois. No cliente, tcpdump -ni any udp port 1194 mostra se volve algunha resposta. Repíteo na interface WAN dun servidor que controles, o que revela se eses paquetes chegan de todo ao extremo remoto.

O tráfico dun só lado é o resultado máis útil dispoñible aquí, porque converte unha queixa intermitente nunha dirección onde investigar. Garda os ficheiros de captura, porque o seguinte informe do mesmo problema péchase máis facilmente con probas que cunha descrición.

Filtrado UDP fronte a un porto pechado

Moitas redes de acceso consideran sospeitoso o UDP sostido, e algúns provedores están de acordo. Un porto pechado produce o mesmo silencio desde o lado do cliente. A diferenza é a selectividade: un filtro adoita ser esixente sobre que destinos ou portos descarta, mentres que un porto pechado rexeita todo o dirixido a ese único porto.

Un perfil TCP no porto 443 é o rodeo habitual, porque se parece a un fluxo HTTPS normal e pasa a maioría de portais cativos e filtros de saída. Débense cumprir dúas condicións. O servidor debe escoitar con proto tcp-server e o cliente debe coincidir con proto tcp-client, e o operador ten que publicar ese extremo alternativo. Reescribir un perfil UDP que funciona para declarar TCP 443 non leva a ningures cando no outro lado non escoita ninguén.

Un porto pechado é un problema de configuración e non de censura. Un servidor detrás dun router doméstico necesita que se reenvíe o seu porto UDP, e a devasa do router debe permitilo. Cando o porto nunca se permitiu, todos os clientes fallan na negociación independentemente das credenciais, e o fallo segue o servidor en vez de a rede.

Os protocolos máis antigos saen mal parados neste eixe. PPTP necesita TCP 1723 máis GRE, e GRE é o protocolo IP 47 e non un porto, así que ningún reenvío de porto corrente o expresa.

Cando é o conmutador o que descarta paquetes

Un conmutador xestionado pode descartar o túnel a propósito. Algúns modelos HPE e Aruba ofrecen un control de protección contra inundacións UDP, ás veces etiquetado Prevent UDP Blat Attack, na súa sección de seguridade avanzada. Unha vez que ese control está activo, un servidor detrás do conmutador non responde nada e todos os clientes esgotan o tempo do mesmo xeito. Desactivalo e gardar a configuración en curso é toda a reparación, pero só despois de establecer que o conmutador está realmente na ruta.

As probas contrarias son o que separa un descarte do conmutador dun bloqueo do provedor. Le os contadores da interface e o rexistro de protección contra inundacións antes de abrir un tícket co provedor. Os routeres domésticos con protección DoS ou contra inundacións fallan do mesmo xeito, e tamén calquera dispositivo intermedio cun tempo de inactividade UDP curto. Un handshake que nunca se completa suxire un descarte, mentres que un túnel que morre tras minutos de silencio suxire o tempo de espera.

Anota cada dispositivo entre o cliente e o servidor antes de cambiar un perfil. Unha corrección aplicada na capa equivocada parece correcta ata a seguinte rede. Esa lista tamén lle di ao seguinte enxeñeiro onde mirar sen repetir toda a investigación.

Un solapamento de enderezos que parece un fallo de DNS

Unha rede de acceso numerada dentro de 10.0.0.0/8 pode solaparse co conxunto do túnel, e o resolvedor adoita vivir dentro dese conxunto. Cando un portátil recibe un enderezo como 10.184.178.50 cunha máscara /8 na Wi-Fi, todo destino 10.x é local por definición. Os paquetes para 10.4.0.1 van entón á LAN, o túnel segue arriba e a resolución de nomes falla.

ip addr expón o solapamento dun vistazo, e ip route get 10.4.0.1 mostra onde se entregaría realmente o paquete. Como o síntoma visible é un fallo do resolvedor, este caso adoita sobrevivir a varias roldas de cambios de DNS.

Renumera o conxunto ou mantén esa rede de acceso fóra do alcance. Ningún axuste do lado do cliente se recupera dun solapamento.

Decidir entre un TCP alternativo e unha corrección da ruta

Elixe o TCP alternativo cando non controles a ruta e os usuarios precisen traballar hoxe, e acepta os seus custos: TCP dentro de TCP compórtase mal en enlaces con perdas, e o alternativo necesita un oínte que ti operes. Elixe a corrección da ruta cando o bloqueo estea en infraestrutura que ti poses, porque unha regra de devasa é máis barata ca un segundo oínte. De calquera xeito, percorre as capas en orde: enlace, transporte externo, negociación, enrutamento interno. A etapa que fallou nesa rede é o único feito que importa.

Rexistra o resultado por rede e non por usuario. O seguinte informe do mesmo fallo comeza entón nunha etapa coñecida en lugar dunha teoría sobre certificados. Ese rexistro é tamén o que xustifica un segundo oínte permanente, se algunha vez fai falta.