Por que unha VPN pode parecer conectada cando nada funciona

O teu cliente informa conectado mentres a interface está levantada e o navegador esgota o tempo, e ningunha desas tres afirmacións é falsa. Conectado describe unha capa que non ten nada que ver coa páxina que solicitaches. Decidir que capa informa require unha solicitude nova e unha ollada ao contador que demostraría que o tráfico se moveu. Un reinicio tira esa evidencia e reconstrúe as condicións que intentabas observar.

Tres cousas diferentes chamadas conectado

Abaixo do todo, conectado pode significar que un proceso de cliente se executa e mantén un socket cara a un par. Por riba, pode significar que existe unha interface cun enderezo, que un dispositivo persistente ou unha rutina de recuperación poden crear sen sesión viva detrás. No nivel de control, pode significar que se negociou unha asociación, o que non di nada sobre se un só paquete pasou por baixo. Cada unha sobrevive a fallos aos que as outras non sobreviven, e un cliente adoita mostrar a máis forte que pode reclamar.

Unha icona verde e un túnel morto son, por tanto, compatíbeis e non contraditorios; informan de obxectos distintos. Esa é toda a razón pola que este fallo se diagnostica mal unha e outra vez como un erro do cliente.

Envía unha solicitude inocua a un destino que realmente necesites antes de tocar o daemon, e mantén o bloque de tráfico directo requirido no seu sitio mentres traballas. Un reinicio borra a orde dos acontecementos e despois recréaos o bastante preto para ocultar a causa, e por iso o mesmo ticket volve unha semana despois sen nada novo. Unha solicitude, unha lectura do contador e o desencadeante que produciu o fallo son a evidencia mínima.

Que contador demostra que os paquetes se moveron

En IPsec a asociación IKE e a asociación CHILD son obxectos separados, e só o child leva os contadores que responden a esta pregunta. Lista o child, observa se os paquetes aumentan en ambas as direccións e compárao co que a aplicación intenta facer. Unha asociación instalada a cero é un achado distinto dunha que aumenta mentres a aplicación segue fallando; a primeira significa que o tráfico non se selecciona, a segunda que se move e que o fallo está máis adiante. Le os contadores dúas veces, con uns segundos de diferenza, porque unha soa mostra non pode mostrar unha tendencia.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Os contadores a cero apuntan á selección: o encamiñamento, a política, un espazo de nomes do que saíu o paquete ou unha interface á que o cliente nunca se vinculou. Os contadores crecentes apuntan lonxe do túnel, así que continúa co reenvío no extremo afastado, a resolución de nomes, o camiño de volta e o servizo de destino, nesa orde. Un protocolo sen obxecto child separado expón a mesma evidencia nos seus propios termos, así que usa o que informa sobre o estado do par e o reconto de paquetes en lugar de tomar prestado o vocabulario de IPsec. A forma da lectura importa máis que a ferramenta que a produciu.

Onde se sitúa o fallo despois de que os contadores se movan

Unha pasarela que responde no seu propio enderezo de xestión demostra que a pasarela funciona, non que algo detrás sirva a túa solicitude, así que proba o lado afastado e non a caixa do medio. A resolución de nomes oculta os fallos mellor que nada, porque un resolutor ao que non se pode chegar polo túnel esgota o tempo igual que unha conexión morta. Dúas consultas separan eses casos, e ambas son baratas. Pregunta primeiro ao resolutor que empurra o túnel e despois pregunta a un resolutor público polo mesmo nome.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nome que se resolve polo resolutor público pero non polo do túnel significa que a ruta DNS está rota, mentres que un nome que se resolve por ambos e aínda esgota o tempo no navegador apunta ao camiño de volta ou ao servizo. Se o ping por enderezo ten éxito e a aplicación segue negándose, a rede entregou a solicitude e o servizo rexeitouna, o que é unha etapa moito máis tardía.

Rexistra o desencadeante e despois cambia unha cousa

Rexistra que precedeu o fallo: un período de inactividade, un cambio de rede, unha renovación de chave, un portátil retomado ou un sistema restaurado. Producen mecanismos distintos, e normalmente só o sistema restaurado se repara a si mesmo, que é xusto o caso que non che ensina nada. Un reinicio elimina a orde dos acontecementos e despois recrea condicións o bastante preto para ocultar a causa. Escribe o desencadeante mentres aínda é reproducíbel.

Despois fai unha corrección apoiada e repite a solicitude orixinal xunto co desencadeante que produciu o fallo. A inactividade é o desencadeante máis doado de reproducir, así que é a confirmación máis rápida de que a corrección abordou o mecanismo e non o síntoma.

O que queres informar é a proba de que o tráfico que pretendías enviar chegou ao servizo ao que pretendías chegar. Unha icona que se pon verde, unha páxina en caché que carga e un contador que se move demostran todos menos que unha solicitude completada contra o destino previsto. Mantén xuntos a solicitude, a lectura do contador e o desencadeante, para que a seguinte persoa poida distinguir unha corrección dunha coincidencia.