VPN connectada però sense internet? Reviseu les quatre capes

El client diu connectat, el navegador gira i cada lloc acaba en un temps d'espera esgotat. Aquesta combinació és habitual i no és cap contradicció: connectat vol dir que el túnel ha negociat, i res més. La resolució de noms, l'encaminament i la pròpia sortida del servidor fallen cadascun a la seva manera, i cadascun té un amo diferent. Recorreu les capes en ordre i atureu-vos a la primera que falli.

Comenceu per la xarxa d'on veniu

Baixeu el túnel amb el control de desconnectar del mateix client i després proveu dos llocs HTTPS no relacionats si la política ho permet. Deixeu la feina sensible tancada durant aquesta prova. Si l'accés ordinari també falla, la VPN no és el primer sospitós.

Mireu l'enllaç Wi-Fi, el router i qualsevol pàgina de portal que demani inici de sessió abans de tocar el túnel. Un kill switch pot bloquejar el trànsit mentre esteu desconnectat per disseny, així que seguiu el seu procediment de prova documentat en lloc de concloure que la xarxa és morta. Una altra xarxa de confiança és una comparació útil, i una sortida VPN nova no completarà un inici de sessió d'hotel caducat. Si la xarxa oberta funciona i el túnel no, la xarxa queda exonerada i la capa següent és vostra.

Decidiu si la fallada és de resolució de noms

Anoteu el text de l'error, perquè una fallada de resolució, un temps d'espera i un avís de certificat apunten cadascun a un lloc diferent. El patró que cal detectar aviat és un nom d'amfitrió que no heu visitat mai que falla mentre una aplicació amb una sessió oberta continua. Aquest patró tracta de consultes noves, no de si el túnel transporta paquets. Una sola consulta mostra què retorna el resolutor i triga un segon. Proveu també un segon nom, perquè una resposta en memòria cau o un registre trencat no decideixin el diagnòstic.

nslookup example.com

Una IP arbitrària a la barra d'adreces HTTPS no és una prova de DNS, perquè el certificat i l'amfitrió virtual solen dependre del nom. Els noms interns poden necessitar el resolutor de l'organització en lloc d'un substitut públic, i un navegador amb el seu propi resolutor segur pot respondre diferent de la consulta del sistema operatiu. Quan els dos discrepen, el resolutor del navegador és el que l'usuari experimenta, i aquesta distinció pertany al tiquet.

Túnel complet o només subxarxes de l'empresa

Alguns perfils existeixen només per arribar a un grapat de subxarxes de l'empresa; d'altres estan fets per transportar-ho tot i necessiten una sortida funcional al darrere. Llegiu la finalitat documentada abans de suposar que l'indicador cobreix cada aplicació i cada família d'adreces. Un perfil de xarxa privada pot funcionar exactament com es va dissenyar mentre el navegador, que mai no havia de fer-lo servir, encara falla. Llegiu la taula d'encaminament sense canviar-la, i incloeu IPv6, perquè un camí IPv4 que funciona no diu res de l'altra família.

Una ruta més específica pot guanyar mentre la ruta per defecte encara existeix, i per això cal llegir la taula en lloc de suposar-la. Els adaptadors virtuals competidors també poden posseir trànsit que esperàveu en un altre lloc, sobretot després que un segon client VPN s'hagi instal·lat i oblidat. No esborreu la ruta per defecte com a experiment; això converteix un diagnòstic en una segona avaria.

Un sol lloc que falla entre els que funcionen és un problema d'aquell lloc, i també demostra que el túnel transporta trànsit. Les aturades que només apareixen en transferències grans apunten a la mida del paquet, no a l'abastabilitat.

Quan el servidor no reenvia mai res

Si tota destinació falla en dos dispositius i dues xarxes d'accés, el túnel està aixecat i la sortida no reenvia. Aquest emparellament és el que separa una fallada del costat del servidor d'un sol dispositiu mal configurat en un lloc. Envieu a l'operador les preguntes de reenviament, NAT i camí de retorn, no una captura de l'indicador.

Aquestes tres cobreixen la majoria de causes del costat del servidor, i és l'operador qui les ha de respondre. La pàgina de resolució de problemes de connectivitat d'OpenVPN recorre les mateixes preguntes des del costat del servidor, així que passeu-la amb el tiquet. Una captura d'un indicador verd no respon a cap d'elles.

Repasseu el registre del client posterior a l'inici de sessió per fallades en aplicar rutes, paràmetres DNS o l'adaptador virtual. Els errors en aquesta etapa apunten al dispositiu, no al servidor. Un error que no apareix mai al registre és igualment informatiu, perquè mou el sospitós cap a l'altre costat.

Comproveu una capa alhora

Un cop canvieu alguna cosa, torneu-vos a connectar i repetiu exactament l'aplicació que va fallar. Una sola pàgina que carrega demostra menys que un camí repetible als recursos per als quals es va construir el perfil. Dues ordres separen la resolució de l'abastabilitat, i la segona és específica de l'amfitrió. Executeu la línia curl a qualsevol lloc i després l'ordre de rutes que correspongui a l'amfitrió que teniu davant.

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

Si la petició numèrica funciona i el nom no, quedeu-vos al DNS. Si no funciona cap de les dues, compareu la taula d'encaminament amb el valor per defecte esperat del túnel i comproveu la família que esteu provant realment. Si la ruta és correcta i la petició encara mor a la sortida, la pregunta restant és de l'operador, i l'evidència que heu guardat és el tiquet.