Como probar o interruptor de seguridade dun VPN sen as túas contas reais
Executa unha proba do interruptor de seguridade cunha páxina señuelo e un perfil de reserva: cobre cada tipo de corte, le os códigos de saída de curl e separa un bloqueo real dun fallo de DNS.
Non necesitas unha conta real para saber se un interruptor de seguridade aguanta; iso é xustamente o que unha proba pon en risco. A comprobación crea unha xanela breve na que o tráfico pode ou non saír fóra do túnel, así que a carga útil debería ser algo que poidas perder. Agora fago isto cunha páxina señuelo e un perfil de navegador de reserva, e dá unha resposta máis clara que a rutina de navegador e correo web que usaba antes. O que segue percorre a mesma orde que presenta o cliente: o axuste, o destino, a transición e logo as probas.
A proba responde unha pregunta estreita: durante esta transición, pode esta aplicación chegar á rede fóra do túnel? Non di nada sobre se o resto da política é sensato. Mantén o alcance así de pequeno e o resultado merece escribirse.
Atopa o interruptor e o seu alcance no cliente
Abre o cliente e localiza o axuste de bloqueo antes de cambiar calquera estado de rede. Os provedores chámano de xeito distinto: interruptor de seguridade, modo de bloqueo, bloqueo de rede, bloquear o tráfico fóra do túnel. A etiqueta di menos que as opcións de dentro. O que importa é se o bloqueo se aplica sempre, ou só cando a aplicación decide que un túnel acaba de fallar, e se cobre todas as aplicacións ou unha lista escollida.
Despois enumera as transicións que o teu cliente pode realizar de verdade. Unha desconexión iniciada polo usuario, saír da aplicación e perder o contacto co servidor son tres rutas de código distintas na maioría dos clientes, e non comparten unha soa política de bloqueo. Algúns liberan o bloqueo cando a aplicación se pecha. Outros deixan as regras de filtrado instaladas ata que algo as elimina. Le a referencia de axustes do provedor para a versión que executas en vez de supoñer, e despois anota cal das tres estás probando.
Anota tamén o perfil: protocolo, familias de enderezos e se o túnel dividido está activado. Unha afirmación sobre todo o dispositivo non ten sentido se o perfil exclúe a propósito unhas poucas aplicacións, e unha exclusión que configuraches non é unha fuga. A referencia de axustes de OpenVPN Connect é o tipo de páxina que nomea que conmutador cambia que comportamento, aínda que as etiquetas difiren segundo o cliente.
Escolle un destino señuelo que tamén funcione sen o túnel
O señuelo necesita dúas propiedades, e saltarse calquera delas produce un resultado ilexible. Debe ser accesible directamente cando o túnel está caído e o bloqueo desactivado, ou «deixou de responder» podería significar simplemente que o host desapareceu. E non debe necesitar un inicio de sesión, unha cookie nin un pagamento, para que unha fuga che custe unha liña de rexistro en lugar dunha sesión.
Unha páxina estática nun host que controlas é a opción limpa. Unha máquina virtual de reserva cun servidor HTTP sinxelo é case igual de boa, e unha páxina pública de comprobación de conectividade serve se aceptas que a súa dispoñibilidade queda fóra do teu control. Anota o enderezo, o porto, a familia de enderezos e se a petición necesita unha consulta de nome, porque cada un deses convértese nunha variable que quizais teñas que illar máis adiante.
Establece a liña base antes de tocar o interruptor. Co túnel activo, o señuelo debe responder a través do túnel, o que demostra que a ruta da política funciona. Co túnel caído e o bloqueo desactivado, debe responder directamente, o que demostra que o destino está vivo. Só entón un fallo no estado bloqueado che di algo.
Executa as transicións nunha orde fixa
Toma as transicións dunha en unha e dálle a cada unha uns segundos para asentarse, porque os clientes a miúdo desmontan e reconstruen regras nese oco. Executar a mesma comprobación breve cada vez mantén as observacións 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 |
A fila de saír da aplicación merece a súa propia execución aínda que nunca peches o cliente no uso normal. Se o bloqueo se libera ao saír, un fallo ou unha actualización forzada danche a mesma exposición, e iso é un feito sobre o despregamento, non sobre a túa paciencia. En Windows as sondas equivalentes son Resolve-DnsName decoy.example e curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Separa un bloqueo dun resolutor roto
Unha páxina que non carga ten varias causas, e só unha é que o interruptor funcione. Se o nome non se resolve, aprendiches que o DNS está bloqueado ou roto, non que a ruta de datos estea bloqueada. Sonda tamén un enderezo literal, para que a resposta non dependa en absoluto da resolución.
Os códigos de saída de curl separan eses casos: 6 é un fallo de resolución de nomes, 7 significa que se rexeitou a conexión, 28 é un tempo de espera. Unha ruta bloqueada adoita aparecer como un tempo de espera ou un rexeitamento contra un enderezo literal. Un bloqueo só de DNS deixa un 6 e oculta todo o demais. Unha páxina en caché ou un portal cativo enganan o ollo, e por iso a proba é o código de saída, non a pantalla.
Repite a sonda sobre IPv6 cun enderezo literal. Un bloqueo que cobre IPv4 e ignora IPv6 é abondo común como para merecer a súa propia liña nas túas notas, e un cliente que desactiva IPv6 fóra do túnel debería fallar limpamente en ambas as familias.
Anota o alcance que cobre o resultado
Cando o túnel volva, confirma a recuperación: o señuelo responde a través do túnel, o resolutor devolve respostas e a política queda onde a deixaches. Despois desfai os experimentos. Unha regra de cortalumes temporal, unha ruta de depuración ou un perfil de proba que queden no seu sitio confundirán a seguinte execución e poden sobrevivir á aplicación.
Unha soa pasada cobre unha versión do cliente, un perfil, unha transición e unha familia de enderezos. Anota eses catro xunto co resultado:
- Versión do cliente e plataforma, e se o axuste é por perfil ou global.
- Perfil, protocolo e calquera exclusión de túnel dividido.
- Transición probada, e como a desencadeaches.
- Familias de enderezos e DNS, cos códigos de saída de curl para os estados bloqueado e desbloqueado.
Se algunha liña queda en branco, a proba non rematou. A itinerancia significa repetir a fila do cambio de rede. Un reinicio sen supervisión significa comprobar que as regras volven, que é unha pregunta sobre a orde de restauración e non sobre o interruptor. Repite a secuencia tras unha actualización do cliente, porque os conmutadores raramente cambian mentres o comportamento que hai detrás si o fai. Garda o señuelo: nada que rotar e a próxima comprobación leva cinco minutos.