Internet només funciona amb l'aplicació VPN encesa? Comprova quatre capes

Proves un client VPN gratuït o una extensió del navegador durant una setmana, l'apagues i internet s'atura. La icona del Wi-Fi encara mostra connexió, els altres dispositius del mateix router funcionen i l'única cosa que recupera la navegació és tornar a activar l'aplicació o desinstal·lar-la. Aquest patró no és un xifratge que crea una dependència. És configuració que l'aplicació va escriure en un lloc que el túnel no posseeix.

El client modifica paràmetres que no són del túnel

Un client de privadesa a Windows o macOS normalment toca tres llocs alhora. Fixa el proxy HTTP del sistema, que és el mateix camp que exposa Internet Options. Instal·la un adaptador virtual, sovint un controlador TAP, per poder capturar paquets. I reescriu la llista de resolutors, mentre que en prémer desconnecta només desapareix el túnel.

Una extensió del navegador és una cosa més estreta. Normalment canvia el seu propi perfil o el proxy que segueix un sol navegador. Per això un navegador pot fallar mentre les eines de línia d'ordres continuen funcionant, o al revés: l'extensió mai no va tenir autoritat per tocar les altres capes. Quina capa va editar decideix quines eines es trenquen.

En qualsevol cas, la decisió antiga la va prendre un programari que no tenia cap motiu per desfer-la. El túnel era la part visible i també l'única part amb un camí de tancament net. Tota la resta és un paràmetre en un magatzem que sobreviu al procés, així que eliminar l'aplicació és l'únic pas que reverteix les tres alhora. Llegir aquests magatzems abans de reinstal·lar res és el que converteix el símptoma en un diagnòstic.

Tres romanents, tres fallades diferents

El primer romanent és un proxy que no apunta enlloc: la casella del proxy de LAN encara marcada, o un URL de script de configuració adreçat a un port localhost on ja no escolta cap procés. El navegador envia cada petició a aquest port mort i s'encalla fins que el temps d'espera sembla una xarxa morta. El segon és un adaptador que encara posseeix una ruta per defecte, perquè un dispositiu TAP-Windows o un controlador d'encaminament del proveïdor continua sent una interfície real després de desinstal·lar. Conserva la ruta que se li va donar i el trànsit desapareix en un túnel que no hi és. Cap dels dos romanents s'anuncia; tots dos semblen exactament una caiguda.

El tercer és el DNS, i falla abans que els altres dos. Si la llista de resolutors només conté servidors accessibles pel túnel, cada consulta expira abans que es demani una sola pàgina, així que el navegador informa d'un lloc inabastable en lloc d'un proxy mort. Sigui quin sigui el que tinguis, cap no és una caiguda en el sentit de xarxa. Cadascun és un romanent que ningú no va revocar, i cadascun es repara en un lloc diferent.

Baixa per les quatre capes

Comença el més a prop de l'aplicació i baixa, perquè les capes fallen en aquest ordre de visibilitat. Canvia una capa per prova i torna a provar després de cadascuna. Restablir-ho tot alhora normalment recupera la navegació i et deixa sense poder dir quin romanent ho va causar, així que la instal·lació següent recrea el mateix trencaclosques. L'ordre és proxy, adaptadors, rutes, resolutors.

A Windows cada comprovació és una sola ordre que ve amb el sistema operatiu, així que no cal instal·lar res. Executa-les en ordre i mantén la sortida junta, perquè les quatre respostes només tenen sentit costat a costat. Informen del proxy, dels adaptadors, de les rutes IPv4 i de la llista de resolutors, en aquest ordre:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux i macOS necessiten les seves pròpies ordres, i no són intercanviables. A Linux les rutes vénen d'ip route i el resolutor de resolvectl status on systemd-resolved en és l'amo, amb retrocés a cat /etc/resolv.conf. A macOS les rutes vénen de netstat -rn, els resolutors de scutil --dns i el proxy del sistema de scutil --proxy. Un lector de macOS que executi ip route obté command not found, i /etc/resolv.conf allà és un stub generat i no la configuració autoritativa. Comprova la plataforma abans de comprovar la capa, o la primera ordre es converteix en la troballa.

Per a cada capa fes una pregunta: aquest valor encara apunta a alguna cosa que existeix mentre l'aplicació està tancada? Un proxy en un port mort, un adaptador sense túnel, una ruta per defecte per una interfície caiguda i un resolutor dins del túnel tots responen no. Un sol no n'hi ha prou per explicar el símptoma, i per això importa un canvi per prova.

Un proxy no és un túnel

Un proxy accepta una petició, la va a buscar enlloc i torna la resposta, cosa que vol dir que coneix la destinació i veu tot el que el lloc no va xifrar ell mateix. No transporta altres protocols. No protegeix el camí tret que la destinació ja faci servir TLS. I el pot canviar qui l'hagi instal·lat, sense la teva intervenció.

Aquesta distinció canvia la pregunta que val la pena fer. Quan queda un proxy, esbrina quin programa encara dirigeix el navegador en lloc de si el túnel està aixecat. El túnel pot estar perfectament sa i ser del tot irrellevant per a la fallada.

Si vols saber què va fer realment aquest client, observa'l en lloc de llegir el seu tauler. Process Monitor registra quines claus del registre i fitxers toca, mentre que una captura de paquets revela on va anar el seu trànsit. Totes dues són eines corrents i totes dues responen millor la pregunta del romanent que qualsevol llum d'estat. Cap de les dues necessita que l'aplicació segueixi en marxa.

Elimina el component, no les proves

La solució duradora és eliminar la cosa que va escriure el paràmetre. Desinstal·la l'aplicació, esborra l'adaptador virtual que va afegir, neteja el proxy i la llista de resolutors, reinicia i prova amb l'aplicació encara desinstal·lada. Si en aquest punt la navegació funciona, has trobat la causa i no una solució provisional. Anota quina capa era obsoleta, perquè el mateix proveïdor sol repetir el mateix error dues vegades.

Si el símptoma torna després d'instal·lar el client següent, recorre de nou les quatre capes abans de decidir que el servei ha trencat alguna cosa. Les proves solen ser-hi encara, en un dels quatre llocs. Una segona aplicació no crea una cinquena capa; edita una de les quatre.

Reinstal·lar restableix el proxy però no un adaptador obsolet, i pot deixar dos resolutors a la llista. Aquesta asimetria és per què desinstal·la-i-prova guanya un botó de restablir-ho tot. També et dona una línia base per comparar la propera vegada que caigui la connexió.