VPN conectada pero sen internet? Revisa as catro capas

O cliente di conectado, o navegador xira e cada sitio remata nun tempo de espera. Esa combinación é habitual e non é unha contradición: conectado significa que o túnel negociou, e nada máis. A resolución de nomes, o encamiñamento e a propia saída do servidor fallan cada un á súa maneira, e cada un ten un dono distinto. Percorre as capas en orde e detente na primeira que falle.

Comeza pola rede da que vés

Baixa o túnel co propio control de desconexión do cliente e despois proba dous sitios HTTPS non relacionados se a política o permite. Deixa o traballo sensible pechado durante esa proba. Se o acceso normal tamén falla, a VPN non é o primeiro sospeitoso.

Mira a ligazón Wi-Fi, o router e calquera páxina de portal que esixa iniciar sesión antes de tocar o túnel. Un kill switch pode bloquear o tráfico mentres estás desconectado por deseño, así que segue o seu procedemento de proba documentado en lugar de concluír que a rede está morta. Outra rede de confianza é unha comparación útil, e unha saída VPN nova non completará un inicio de sesión de hotel caducado. Se a rede aberta funciona e o túnel non, a rede queda exonerada e a seguinte capa é túa.

Decide se o fallo é de resolución de nomes

Anota o texto do erro, porque un fallo de resolución, un tempo de espera e un aviso de certificado apuntan cada un a outro lugar. O patrón que hai que detectar cedo é un nome de host que nunca visitaches fallando mentres unha aplicación con sesión aberta segue. Ese patrón trata de consultas novas, non de se o túnel transporta paquetes. Unha soa consulta mostra que devolve o resolutor e tarda un segundo. Proba tamén un segundo nome, para que unha resposta en caché ou un rexistro roto non decidan o diagnóstico.

nslookup example.com

Unha IP arbitraria na barra de enderezos HTTPS non é unha proba de DNS, porque o certificado e o host virtual adoitan depender do nome. Os nomes internos poden necesitar o resolutor da organización en lugar dun substituto público, e un navegador co seu propio resolutor seguro pode responder distinto da consulta do sistema operativo. Cando ambos discrepan, o resolutor do navegador é o que experimenta o usuario, e esa distinción pertence ao tícket.

Túnel completo ou só subredes da empresa

Algúns perfís existen só para chegar a un puñado de subredes da empresa; outros están feitos para transportalo todo e necesitan unha saída funcional detrás. Le a finalidade documentada antes de supor que o indicador cobre cada aplicación e cada familia de enderezos. Un perfil de rede privada pode funcionar exactamente como se deseñou mentres o navegador, que nunca debía usalo, segue fallando. Le a táboa de rutas sen cambiala, e inclúe IPv6, porque unha ruta IPv4 que funciona non di nada da outra familia.

Unha ruta máis específica pode gañar mentres a ruta predeterminada aínda existe, e por iso a táboa debe lerse en lugar de supoñerse. Os adaptadores virtuais competidores tamén poden posuír tráfico que esperabas noutro sitio, sobre todo despois de instalar e esquecer un segundo cliente VPN. Non borres a ruta predeterminada como experimento; iso converte un diagnóstico nunha segunda caída.

Un só sitio que falla entre os que funcionan é un problema dese sitio, e tamén demostra que o túnel transporta tráfico. As paradas que só aparecen en transferencias grandes apuntan ao tamaño do paquete e non á accesibilidade.

Cando o servidor nunca reenvía nada

Se todo destino falla en dous dispositivos e dúas redes de acceso, o túnel está levantado e a saída non reenvía. Ese emparellamento é o que separa un fallo do lado do servidor dun dispositivo mal configurado nun só lugar. Envía ao operador as preguntas de reenvío, NAT e ruta de retorno, non unha captura do indicador.

Esas tres cobren a maioría de causas do lado do servidor, e respondelas é cousa do operador. A páxina de solución de problemas de conectividade de OpenVPN percorre as mesmas preguntas desde o lado do servidor, así que pásaa co tícket. Unha captura dun indicador verde non responde a ningunha.

Revisa o rexistro do cliente despois do inicio de sesión por fallos ao aplicar rutas, axustes de DNS ou o adaptador virtual. Os erros nesa etapa apuntan ao dispositivo e non ao servidor. Un erro que nunca aparece no rexistro é igual de informativo, porque move a sospeita ao outro lado.

Comproba unha capa á vez

En canto cambies algo, volve conectar e repite exactamente a aplicación que fallou. Unha soa páxina que carga demostra menos que unha ruta repetible aos recursos para os que se construíu o perfil. Dous comandos separan a resolución da accesibilidade, e o segundo é específico do host. Executa a liña curl en calquera sitio e despois o comando de rutas que corresponda ao host que tes diante.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Se a petición numérica funciona e o nome non, queda en DNS. Se non funciona ningunha, compara a táboa de rutas co valor predeterminado esperado do túnel e comproba a familia que estás probando en realidade. Se a ruta é correcta e a petición segue morrendo na saída, a pregunta restante é do operador, e a evidencia que gardaches é o tícket.