O porto do VPN está mudo? Escoitante, enderezo de enlace ou cortafogos do equipo

O VPN non responde nada no seu porto, e as dúas causas posibles esixen reparacións opostas: ou ningún proceso abriu o socket, ou o socket existe e algo entre as máquinas detén os paquetes. Un só comando resolve a primeira metade desa pregunta, por iso vai antes de tocar calquera regra do cortafogos. A orde de abaixo elimina unha explicación por paso en vez de engadir outra conxectura. Conxecturar entre as dúas é o que converte un diagnóstico de dez minutos nunha noite enteira.

Supoña que pode iniciar sesión no servidor e que o cliente é un perfil real e non un escáner. As dúas suposicións importan, porque unha sonda xenérica non pode responder unha pregunta específica do protocolo.

Existe o socket sequera

Empece polo que o servizo di de si mesmo: se arrancou e, máis útil, cal foi o seu primeiro erro de arranque. Un fallo de análise, unha clave ausente ou un erro de enlace impiden que o escoitante exista, e o proceso pode saír con tanta discreción que a liña de estado se le ambiguamente. Unha unidade que informa estar activa non é proba por si soa, porque o proceso principal pode estar vivo mentres o compoñente que debía enlazar o porto xa se rendeu.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

A listaxe de sockets é o feito sobre o que descansa o resto do diagnóstico. Lea a columna do enderezo local e non só o porto, porque é nesa columna onde aparecen os enlaces a loopback e os enlaces á interface equivocada. Un escoitante que existe en 127.0.0.1 funciona perfectamente e segue sendo invisible para o seu portátil.

En que enderezo e familia responde o socket

Dous erros vense idénticos desde o cliente e explican a maioría dos informes de "non accesible". Un servidor enlazado ao enderezo de loopback nunca acepta tráfico doutra máquina, e un servidor enlazado só a un enderezo IPv4 nunca responde a un cliente que marca o enderezo IPv6 do mesmo equipo. Compare o enderezo da táboa de sockets co enderezo que o cliente marca realmente, carácter por carácter, antes de supor nada sobre a política.

Limitar a listaxe a un só porto mantena lexible cando o equipo executa varios servizos. O filtro sport toma o porto xunto co transporte que está a probar:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

A columna de protocolo cambia toda a resposta

A táboa de sockets indexa por protocolo ademais de por porto, e son dúas entradas independentes. Un servizo que responde TCP no 1194 non lle di nada sobre se algo escoita no UDP 1194, e o cliente sempre usará só un dos dous. Confirme que transporte escolle a configuración do servidor e cal envía o perfil do cliente, e despois busque exactamente esa fila.

O UDP ten unha segunda particularidade: unha sonda non autenticada non é un erro que o servizo deba responder. Un escaneo que informa que o porto está mudo mediu a discreción do servizo, non a súa dispoñibilidade, así que probe co cliente e o perfil reais.

Un intento, tres sitios onde mirar

Desde un cliente aprobado faga exactamente un intento e anote a hora ao segundo. Logo lea tres fontes para esa xanela: a regra de rede ou a consola do provedor, os contadores ou o rexistro do cortafogos do equipo e o rexistro propio do servizo. Facelo unha vez é o que fai comparables as tres versións, e custa menos que repetir un intento cuxa marca de tempo ninguén rexistrou.

Os dous desenlaces apuntan en direccións opostas. Se ningún paquete chegou ao equipo, a ruta está a descartalo e o escoitante é irrelevante. Se o paquete chegou ao socket e o servizo rexeitouno, a ruta está ben e a resposta está no protocolo, na criptografía ou nas credenciais. Abrir un porto para un servizo que xa aceptou unha conexión fai o seguinte diagnóstico máis difícil, non máis fácil.

Nomee a etapa antes de cambiar unha regra

Unha negociación que comeza e unha autenticación que falla son un só fallo, e un túnel que se establece mentres o reenvío se atasca é un completamente distinto. Nomear a etapa primeiro mantén a reparación estreita: un problema de credenciais non o arranxa unha regra de cortafogos, e un problema de ruta de datos non o arranxa un reinicio.

Use o diagnóstico máis estreito que responda a pregunta. Unha observación temporal de paquetes nun porto, baixo o control dun administrador, é un instrumento razoable; desactivar todo o cortafogos non o é, porque o resultado se volve imposible de atribuír. A documentación de ss cobre os filtros usados arriba, e é un primeiro paso máis barato que calquera captura. Anote cal das dúas ramas demostrou, e a próxima ocorrencia comeza cunha resposta coñecida.