Trieu el punt d’observació adequat per a un escaneig de VPN al telèfon
L’oient de VPN del telèfon, un servei al telèfon i un amfitrió de LAN encaminat són tres superfícies. Seguiu aquests cinc passos i atureu-vos on s’atura l’abast.
Una avaluació autoritzada d’una VPN allotjada al telèfon falla en silenci quan l’escàner se situa al costat equivocat del túnel. Obteniu resultats, semblen plausibles i responen una pregunta que ningú no va fer. Recorreu les cinc comprovacions següents per ordre. Cadascuna té una condició d’aturada, i aturar-se aviat és més barat que tornar a provar des de zero després d’escriure l’informe.
Pas 1: anomeneu la superfície que voleu assolir
Tres superfícies es confonen habitualment perquè un sol dispositiu les connecta. Fan servir codi i polítiques diferents, així que anoteu quina és dins de l’abast abans de començar res.
| 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 |
Si l’abast aprovat no diu quina de les tres, atureu-vos i pregunteu. Fer root al telèfon no respon aquesta pregunta i canvia la cosa que es prova, no el punt d’observació.
Anoteu els objectius, les adreces d’origen permeses, la finestra temporal i el límit d’intensitat alhora. El túnel us porta fins a aquest abast; no us llicencia a sondejar tot el que pot encaminar.
Pas 2: trieu l’origen que pot veure aquesta superfície
Un escàner situat dins de la VPN no pot reproduir un observador d’internet no autenticat. Ja té rutes, credencials i permisos que l’observador extern no té, així que els seus resultats descriuen la visió posterior a l’admissió encara que la superfície objectiu sigui la mateixa. L’error invers és igual de freqüent. Un escaneig públic del port de VPN no diu gairebé res sobre un servei privat darrere de l’inici de sessió, i presentar-lo com si ho digués exagera l’exposició en una direcció i la minimitza en l’altra.
Atureu-vos si l’origen que podeu obtenir no coincideix amb la superfície. Una avaluació feta des d’un igual dins del túnel no s’ha de presentar com a resultat previ a l’autenticació, i una prova que requereix un origen extern aprovat no s’ha de traslladar en silenci a l’interior per evitar la paperassa.
Pas 3: confirmeu la ruta i el camí de resposta a través del telèfon
Quan el terminal reenvia a una altra subxarxa, l’escàner necessita una ruta permesa i l’objectiu necessita un camí de retorn que funcioni. Confirmeu tots dos en lloc de suposar que una resposta de ping vol dir que el camí és complet.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8El NAT d’origen canvia què veu el servei posterior. Si el telèfon tradueix l’adreça de l’escàner, les regles d’accés i els registres de l’objectiu s’apliquen a l’adreça traduïda, així que un servei que sembla acceptar-vos potser accepta el telèfon i no l’escàner.
Vigileu també una superposició amb la xarxa de l’escàner. Si el telèfon encamina 192.168.1.0/24 i l’escàner se situa en una LAN numerada de la mateixa manera, les sondes arriben a dispositius locals i l’informe els descriu com l’objectiu. Comproveu la ruta que faria servir l’escàner mateix abans d’enviar un sol paquet.
Escanegeu l’adreça real de l’objectiu i conserveu el nom d’amfitrió que l’aplicació necessita per a la identitat TLS i l’allotjament virtual. Arribar a una passarel·la demostra que la passarel·la respon; no prova el servei que hi ha darrere.
Pas 4: tracteu el descobriment com una sonda amb supòsits
El descobriment d’amfitrions és on els resultats de l’avaluació fallen més sovint. El descobriment local per Ethernet no travessa una VPN encaminada, així que les sondes que funcionen en una LAN plana simplement no arriben. Les sondes de descobriment bloquejades fan que un servei accessible i autoritzat sembli absent.
Decidiu conscientment si ometeu el descobriment i escanegeu les adreces conegudes directament, i digueu-ho a l’informe. Un port que respon no és prova que l’autenticació de VPN hagi reeixit, i una resposta filtrada no és prova que no hi escolti res. El ritme forma part del mateix problema. Un telèfon que limita o descarta paquets sota un escaneig ràpid produeix estats filtrats que pertanyen al telèfon i no al servei, així que reduïu la concurrència i torneu a escanejar abans de registrar un port com a tancat.
La condició d’aturada aquí és d’interpretació, no de tècnica: si no podeu dir què significa un estat per a aquest camí, el resultat pertany a un apèndix i no a les conclusions.
Pas 5: manteniu la finestra i després tanqueu-la
Un telèfon és un mal servidor perquè està dissenyat per dormir. L’optimització de bateria, el doze i la gestió d’energia del Wi-Fi poden suspendre l’aplicació a mig avaluar, i una reconnexió del túnel pot canviar l’adreça que fa servir l’objectiu. Una execució que travessa un d’aquests esdeveniments té una finestra de resultats no vàlida.
Mantingueu el rol de passarel·la en l’abast més petit que permeti la tasca aprovada, observeu el túnel mentre l’execució és viva i registreu l’inici i el final de cada finestra que informeu. Quan acabi l’avaluació, retireu l’accés temporal a través del seu propietari, conserveu el registre d’origen i camí i protegiu la sortida com qualsevol altre artefacte de prova.
Si necessiteu un punt d’observació reproduïble en lloc d’un èxit puntual, aquesta és la prestació per la qual cal argumentar. referència sobre el descobriment d’amfitrions explica quines sondes pressuposen un segment local, que és el detall que converteix un resultat buit en una afirmació defensable.