Escolla o punto de observación axeitado para unha análise de VPN no teléfono
O oínte de VPN do teléfono, un servizo no teléfono e un host de LAN encamiñado son tres superficies. Percorra estes cinco pasos e detéñase onde remata o alcance.
Unha avaliación autorizada dunha VPN aloxada nun teléfono falla en silencio cando o escáner se sitúa no lado equivocado do túnel. Obtéñense resultados, parecen plausibles e responden a unha pregunta que ninguén formulou. Percorra as cinco comprobacións seguintes en orde. Cada unha ten unha condición de parada, e deterse antes é máis barato que volver probar desde cero despois de escribir o informe.
Paso 1: nomee a superficie que pretende acadar
Tres superficies confúndense habitualmente porque un só dispositivo as conecta. Executan código e políticas distintas, así que anote cal está dentro do alcance antes de comezar nada.
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
Se o alcance aprobado non di cal das tres, detéñase e pregunte. Obter root no teléfono non responde a esta pregunta e cambia a cousa sometida a proba, non o punto de observación.
Anote os obxectivos, os enderezos de orixe permitidos, a xanela temporal e o límite de intensidade ao mesmo tempo. O túnel lévao ata ese alcance; non o autoriza a sondar todo o que pode encamiñar.
Paso 2: escolla a orixe que pode ver esa superficie
Un escáner situado dentro da VPN non pode reproducir un observador de internet non autenticado. Xa ten rutas, credenciais e permisos dos que carece o observador externo, así que os seus resultados describen a visión posterior á admisión aínda que a superficie obxectivo sexa a mesma. O erro inverso é igual de común. Unha análise pública do porto VPN non di case nada sobre un servizo privado tras o inicio de sesión, e presentala como se o dixese esaxera a exposición nunha dirección e minimízaa na outra.
Detéñase se a orixe que pode obter non coincide coa superficie. Unha avaliación executada desde un par dentro do túnel non debe presentarse como resultado previo á autenticación, e unha proba que require unha orixe externa aprobada non debe trasladarse en silencio cara a dentro para evitar o papeleo.
Paso 3: confirme a ruta e o camiño de resposta a través do teléfono
Cando o teléfono reenvía a outra subrede, o escáner necesita unha ruta permitida e o obxectivo necesita un camiño de retorno que funcione. Confirme ambos en lugar de supoñer que unha resposta de ping significa que o camiño está completo.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8O NAT de orixe cambia o que ve o servizo posterior. Se o teléfono traduce o enderezo do escáner, as regras de acceso e os rexistros do obxectivo aplícanse ao enderezo traducido, así que un servizo que parece aceptalo pode estar aceptando o teléfono e non o escáner.
Vixíe tamén unha superposición coa rede do propio escáner. Se o teléfono encamiña 192.168.1.0/24 e o escáner está nunha LAN numerada do mesmo xeito, as sondas alcanzan dispositivos locais e o informe descríbeos como o obxectivo. Comprobe a ruta que usaría o propio escáner antes de enviar un só paquete.
Analice o enderezo real do obxectivo e conserve o nome de host que a aplicación necesita para a identidade TLS e o aloxamento virtual. Acadar unha pasarela demostra que a pasarela responde; non proba o servizo que hai detrás.
Paso 4: trate o descubrimento como unha sonda con supostos
O descubrimento de hosts é onde os resultados da avaliación fallan con máis frecuencia. O descubrimento local por Ethernet non atravesa unha VPN encamiñada, así que as sondas que funcionan nunha LAN plana simplemente non chegan. As sondas de descubrimento bloqueadas fan entón que un servizo accesible e autorizado pareza ausente.
Decida conscientemente se omite o descubrimento e analiza os enderezos coñecidos directamente, e dígao no informe. Un porto que responde non é proba de que a autenticación VPN teña éxito, e unha resposta filtrada non é proba de que nada escoite. O ritmo forma parte do mesmo problema. Un teléfono que limita ou descarta paquetes baixo unha análise rápida produce estados filtrados que pertencen ao teléfono e non ao servizo, así que reduza a concorrencia e volva analizar antes de rexistrar un porto como pechado.
A condición de parada aquí é de interpretación, non de técnica: se non pode dicir que significa un estado para este camiño, o resultado pertence a un apéndice e non ás conclusións.
Paso 5: manteña a xanela e despois péchea
Un teléfono é un mal servidor porque está deseñado para durmir. A optimización da batería, o doze e a xestión de enerxía do Wi-Fi poden suspender a aplicación a metade da avaliación, e unha reconexión do túnel pode cambiar o enderezo que usa o obxectivo. Unha execución que atravesa un deses eventos ten unha xanela de resultados non válida.
Manteña o rol de pasarela no alcance máis pequeno que permita a tarefa aprobada, observe o túnel mentres a execución está activa e rexistre o inicio e o final de cada xanela que informe. Cando remate a avaliación, retire o acceso temporal a través do seu propietario, conserve o rexistro de orixe e ruta e protexa a saída como calquera outro artefacto de proba.
Se necesita un punto de observación repetible en lugar dun éxito puntual, esa é a entrega pola que paga a pena argumentar. a referencia sobre o descubrimento de hosts explica que sondas presupoñen un segmento local, e ese é o detalle que converte un resultado baleiro nunha afirmación defendible.