Com provar l'interruptor d'emergència del VPN sense els teus comptes reals
Fes una prova de l'interruptor d'emergència amb una pàgina esquer i un perfil de reserva: cobreix cada tipus de caiguda, llegeix els codis de sortida de curl i separa un bloqueig real d'una fallada de DNS.
No necessites un compte real per saber si un interruptor d'emergència resisteix; això és exactament el que una prova posa en risc. La comprovació crea una finestra curta en què el trànsit pot o no sortir fora del túnel, així que la càrrega hauria de ser una cosa que puguis perdre. Ara ho faig amb una pàgina esquer i un perfil de navegador de reserva, i dóna una resposta més clara que la rutina de navegador i correu web que feia servir abans. El que segueix recorre el mateix ordre que presenta el client: la configuració, la destinació, la transició i després les proves.
La prova respon una pregunta estreta: durant aquesta transició, pot aquesta aplicació arribar a la xarxa fora del túnel? No diu res sobre si la resta de la política és sensata. Mantén l'abast tan petit i el resultat val la pena d'escriure.
Troba l'interruptor i el seu abast al client
Obre el client i localitza la configuració de bloqueig abans de canviar cap estat de xarxa. Els proveïdors en diuen de maneres diferents: interruptor d'emergència, mode de bloqueig, bloqueig de xarxa, bloqueja el trànsit fora del túnel. L'etiqueta diu menys que les opcions de dins. El que importa és si el bloqueig s'aplica sempre, o només quan l'aplicació decideix que un túnel acaba de fallar, i si cobreix totes les aplicacions o una llista seleccionada.
Després llista les transicions que el teu client pot fer realment. Una desconnexió iniciada per l'usuari, sortir de l'aplicació i perdre el contacte amb el servidor són tres camins de codi diferents a la majoria de clients, i no comparteixen una única política de bloqueig. Alguns alliberen el bloqueig quan l'aplicació s'atura. Altres deixen les regles de filtre instal·lades fins que alguna cosa les elimina. Llegeix la referència de configuració del proveïdor per a la versió que executes en comptes de suposar, i després anota quina de les tres proves.
Anota també el perfil: protocol, famílies d'adreces i si el túnel dividit està activat. Una afirmació de dispositiu sencer no té sentit si el perfil exclou deliberadament unes quantes aplicacions, i una exclusió que has configurat no és una fuita. La referència de configuració d'OpenVPN Connect és el tipus de pàgina que anomena quin commutador canvia quin comportament, tot i que les etiquetes difereixen per client.
Tria una destinació esquer que també funcioni sense el túnel
L'esquer necessita dues propietats, i saltar-se'n qualsevol de les dues produeix un resultat il·legible. Ha de ser accessible directament quan el túnel està aturat i el bloqueig desactivat, o “ha deixat de respondre” podria simplement significar que l'amfitrió ha desaparegut. I no ha de necessitar un inici de sessió, una galeta o un pagament, perquè una fuita et costi una línia de registre en lloc d'una sessió.
Una pàgina estàtica en un amfitrió que controles és l'opció neta. Una màquina virtual de reserva amb un servidor HTTP simple és gairebé igual de bona, i una pàgina pública de comprovació de connectivitat funciona si acceptes que la seva disponibilitat queda fora del teu control. Anota l'adreça, el port, la família d'adreces i si la petició necessita una consulta de nom, perquè cadascun d'aquests es converteix en una variable que potser hauràs d'aïllar més endavant.
Estableix la línia base abans de tocar l'interruptor. Amb el túnel actiu, l'esquer ha de respondre a través del túnel, cosa que demostra que la ruta de la política funciona. Amb el túnel aturat i el bloqueig desactivat, ha de respondre directament, cosa que demostra que la destinació és viva. Només llavors una fallada en l'estat bloquejat et diu alguna cosa.
Executa les transicions en un ordre fix
Pren les transicions d'una en una i deixa uns segons perquè cada una s'assenti, perquè els clients sovint desfan i reconstrueixen regles en aquest interval. Executar la mateixa comprovació curta cada vegada manté les observacions comparables:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"
| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
La fila de sortir de l'aplicació mereix una execució pròpia encara que no tanquis mai el client en ús normal. Si el bloqueig s'allibera en sortir, una fallada o una actualització forçada et dóna la mateixa exposició, i això és un fet sobre el desplegament, no sobre la teva paciència. A Windows les sondes equivalents són Resolve-DnsName decoy.example i curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Separa un bloqueig d'un resolutor trencat
Una pàgina que no carrega té diverses causes, i només una és que l'interruptor funcioni. Si el nom no es resol, has après que el DNS està bloquejat o trencat, no que el camí de dades estigui bloquejat. Sonda també una adreça literal, perquè la resposta no depengui gens de la resolució.
Els codis de sortida de curl separen aquests casos: 6 és una fallada de resolució de noms, 7 vol dir que la connexió fou rebutjada, 28 és un temps d'espera. Una ruta bloquejada normalment apareix com un temps d'espera o un rebuig contra una adreça literal. Un bloqueig només de DNS deixa un 6 i amaga tota la resta. Una pàgina en memòria cau o un portal captiu enganya l'ull, i per això el codi de sortida, no la pantalla, és la prova.
Repeteix la sonda per IPv6 amb una adreça literal. Un bloqueig que cobreix IPv4 i ignora IPv6 és prou comú per merèixer la seva pròpia línia a les notes, i un client que desactiva IPv6 fora del túnel hauria de fallar netament a les dues famílies.
Anota l'abast que cobreix el resultat
Quan el túnel torni, confirma la recuperació: l'esquer respon a través del túnel, el resolutor retorna respostes i la política es queda on la vas deixar. Després desfés els experiments. Una regla de tallafoc temporal, una ruta de depuració o un perfil de prova deixats al lloc confondran la propera execució i poden sobreviure a l'aplicació.
Una sola passada cobreix una versió de client, un perfil, una transició i una família d'adreces. Anota aquests quatre amb el resultat:
- Versió del client i plataforma, i si la configuració és per perfil o global.
- Perfil, protocol i qualsevol exclusió de túnel dividit.
- Transició provada, i com la vas desencadenar.
- Famílies d'adreces i DNS, amb els codis de sortida de curl per als estats bloquejat i desbloquejat.
Si alguna línia queda en blanc, la prova no ha acabat. L'itinerància significa repetir la fila de canvi de xarxa. Un reinici sense supervisió significa comprovar que les regles tornen, que és una qüestió sobre l'ordre de restauració i no sobre l'interruptor. Torna a executar la seqüència després d'una actualització del client, perquè els commutadors poques vegades canvien mentre el comportament que hi ha darrere sí que ho fa. Guarda l'esquer: no hi ha res a rotar i la propera comprovació triga cinc minuts.