VPN conectada pero un servizo falla: illa a etapa

«Conectado» é o dato menos informativo dun ticket de VPN. Rexistra que dous pares completaron un handshake e nada sobre o nome consultado, a interface pola que saíu o paquete, o seu tamaño ou se o extremo remoto o aceptou. Por iso un servizo pode fallar mentres o resto de aplicacións do mesmo portátil funciona. Percorre as etapas en orde e a primeira que falle nomeará a avaría.

Empeza polo nome, non polo túnel

Resolve antes de encamiñar, porque unha mala resposta fai inútil toda proba posterior. Consulta o nome co resolutor do sistema e compara esa resposta co enderezo que a aplicación usou realmente. Un nome privado que volve como enderezo público significa que a consulta foi a un resolutor que non ten nada que ver. Un nome que non resolve é a mesma categoría, só máis ruidosa.

resolvectl query host.internal
getent hosts host.internal

Os navegadores co seu propio axuste de DNS seguro fallan aquí mentres o resto do sistema funciona. Por iso unha queixa só do navegador pertence primeiro a esta etapa, antes de que ninguén toque unha ruta. Compara ambos os comandos e non un, porque getent segue a ruta NSS e a consulta ao resolutor non.

Pregunta ao núcleo que camiño escolleu

A táboa de encamiñamento é unha orde de preferencia, e o camiño que escolle o núcleo non sempre é o que mostra o diagrama. Pregúntalle directamente polo destino en cuestión. A resposta nomea a interface, o seguinte salto e o enderezo de orixe que se usará. Un paquete pode saír polo túnel cun enderezo de orixe que o extremo remoto rexeita, e unha entrada máis específica na táboa física pode envialo pola interface Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Le os campos dev, via e src nesa orde, porque cada un descarta unha sospeita distinta. Esta etapa tamén posúe o estado que instalou o cliente, xa que as regras de devasa e as rutas poden persistir tras unha saída anormal. Por iso «sen internet sen o túnel» e «sen internet se o cliente non se executa» son unha mesma familia de fallos, non dúas.

Proba o tamaño do paquete

Unha resposta pequena que volve mentres unha transferencia grande se atasca apunta primeiro ao MTU da ruta. Unha soa sonda co bit do-not-fragment activado, enviada desde dentro do túnel, separa esta etapa do resto. Sube a carga útil ata que a sonda falle e terás o número que importa.

ping -M do -s 1400 10.20.30.40

Sondas pequenas que pasan mentres unha listaxe de directorio ou unha subida se colga é a sinatura desta etapa. A queixa soa a credenciais ou a regra de devasa, e non é ningunha das dúas.

O número é unha propiedade da ruta, non do cliente, así que un valor que funciona nunha conexión de oficina pode fallar nunha ligazón móbil. Garda o comando de sonda co ticket, porque a seguinte persoa necesita a mesma medición. Se pasa unha carga menor, a solución é un clamp ou un MTU de túnel máis baixo, non un cifrado novo.

Proba o extremo remoto

Proba o destino polo seu enderezo e logo mira que escoita alí. Unha conexión rexeitada e unha conexión que nunca responde son achados distintos. A primeira di que algo está arriba e non serve ese porto, e a segunda di que non volveu nada. Ningunha é un problema de cliente por defecto.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nada accesible por un túnel pode ser un servizo que só escoita en 127.0.0.1, porque o oínte nunca ve o paquete. Cando a devasa do host remoto permite a subrede de oficina e rexeita o grupo do túnel, o resultado parece unha avaría do cliente e non o é. O escritorio remoto ou a compartición de ficheiros rompen mentres o tráfico web sobrevive; normalmente acaba aquí, diga como diga o usuario.

Asigna a queixa a unha etapa

A maioría dos informes encaixan nunha de cinco formas, e cada forma nomea unha etapa. Un sitio que só funciona polo túnel é unha resposta de nome ou unha política ligada ao enderezo de orixe. As actualizacións fallan sen o túnel mentres a navegación funciona: é un problema de nome ou de ruta para ese cliente.

Que todo se deteña ao arrincar un cliente de provedor é estado instalado, é dicir, unha cuestión de ruta e devasa. Un servizo inalcanzable mentres o resto está ben é o extremo remoto. As transferencias que se atascan aos poucos segundos son o tamaño do paquete. Emparella a forma antes de executar comandos, porque decide que probas recoller primeiro.

Anota a etapa que produciu o primeiro fallo xunto coa saída do comando. Un ticket que di que o enderezo de orixe era incorrecto, coa liña de ruta adxunta, merece actuación, mentres que un que informa da VPN como rota non.