Vælg det rigtige observationspunkt til en VPN-scanning på telefonen
Telefonens VPN-lytter, en tjeneste på telefonen og en routet LAN-vært er tre flader. Gå gennem disse fem trin, og stop hvor omfanget stopper.
En autoriseret vurdering af en VPN, der kører på en telefon, fejler lydløst, når scanneren sidder på den forkerte side af tunnelen. Du får resultater, de ser plausible ud, og de besvarer et spørgsmål, ingen stillede. Gå gennem de fem kontroller nedenfor i rækkefølge. Hver har en stopbetingelse, og det er billigere at stoppe tidligt end at teste forfra, efter rapporten er skrevet.
Trin 1: navngiv den flade, du vil nå
Tre flader forveksles rutinemæssigt, fordi én enhed forbinder dem. De udfører forskellig kode og forskellig politik, så skriv ned, hvilken der er i omfang, før noget startes.
| 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 |
Hvis det godkendte omfang ikke siger hvilken af de tre, skal du stoppe og spørge. Root på telefonen besvarer ikke dette spørgsmål, og det ændrer det, der testes, i stedet for observationspunktet.
Noter målene, de tilladte kildeadresser, tidsvinduet og intensitetsgrænsen på samme tid. Tunnelen bærer dig til det omfang; den giver ikke licens til at undersøge alt, den kan route.
Trin 2: vælg den kilde, der kan se den flade
En scanner, der sidder inde i VPN’en kan ikke genskabe en uautentificeret internetobservatør. Den har allerede ruter, legitimationsoplysninger og tilladelser, som den udefrakommende observatør mangler, så dens resultater beskriver visningen efter adgang, selv når målfladen er den samme. Den modsatte fejl er lige så almindelig. En offentlig scanning af VPN-porten siger næsten intet om en privat tjeneste bag login, og at rapportere det, som om den gjorde, overdriver eksponeringen i den ene retning og underdriver den i den anden.
Stop, hvis den kilde, du kan skaffe, ikke svarer til fladen. En vurdering kørt fra en peer inde i tunnelen bør ikke præsenteres som et resultat før autentificering, og en test, der kræver en godkendt ekstern kilde, bør ikke lydløst flyttes indenfor for at undgå papirarbejdet.
Trin 3: bekræft ruten og svarvejen gennem telefonen
Når telefonen videresender til et andet undernet, har scanneren brug for en tilladt rute, og målet har brug for en svarvej, der virker. Bekræft begge i stedet for at antage, at et ping-svar betyder, at vejen er komplet.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Source NAT ændrer, hvad den nedstrøms tjeneste ser. Hvis telefonen oversætter scannerens adresse, gælder adgangsreglerne og loggene på målet for den oversatte adresse, så en tjeneste, der ser ud til at acceptere dig, accepterer måske telefonen i stedet for scanneren.
Hold også øje med overlap med scannerens eget netværk. Hvis telefonen router 192.168.1.0/24, og scanneren sidder på et LAN nummereret på samme måde, rammer proberne lokale enheder, og rapporten beskriver dem som målet. Kontrollér den rute, scanneren selv ville bruge, før du sender en enkelt pakke.
Scan den faktiske målattresse, og behold det værtsnavn, applikationen har brug for til TLS-identitet og virtuel hosting. At nå en gateway beviser, at gatewayen svarer; det tester ikke tjenesten bag den.
Trin 4: behandl opdagelse som en probe med antagelser
Værtsopdagelse er der, hvor vurderingsresultater oftest går galt. Lokal Ethernet-opdagelse krydser ikke en routet VPN, så de prober, der virker på et fladt LAN, ankommer simpelthen ikke. Blokerede opdagelsesprober får derefter en tilgængelig, autoriseret tjeneste til at se fraværende ud.
Beslut bevidst, om du vil springe opdagelse over og scanne de kendte adresser direkte, og sig det i rapporten. En port, der svarer, er ikke bevis for, at VPN-autentificeringen lykkedes, og et filtreret svar er ikke bevis for, at intet lytter. Hastigheden er en del af samme problem. En telefon, der kvæler eller dropper under en hurtig scanning, producerer filtrerede tilstande, der tilhører telefonen og ikke tjenesten, så sænk samtidighed og scan igen, før du registrerer en port som lukket.
Stopbetingelsen her er fortolkning, ikke teknik: hvis du ikke kan sige, hvad en tilstand betyder for denne vej, hører resultatet i et bilag og ikke i fundene.
Trin 5: hold vinduet, og luk det så
En telefon er en dårlig server, fordi den er designet til at sove. Batterioptimering, doze og Wi-Fi-strømstyring kan suspendere appen midt i vurderingen, og en genopretning af tunnelen kan ændre den adresse, målet bruger. En kørsel, der spænder over en af disse hændelser, har et ugyldigt resultatvindue.
Hold gatewayrollen til det mindste omfang, den godkendte opgave tillader, overvåg tunnelen, mens kørslen er live, og log start og slut på hvert vindue, du rapporterer. Når vurderingen slutter, skal du fjerne den midlertidige adgang via dens ejer, beholde kilde- og ruterekorden og beskytte output som enhver anden testartefakt.
Hvis du har brug for et gentageligt observationspunkt i stedet for en enkeltstående succes, er det den leverance, der er værd at argumentere for. referencen om værtsopdagelse forklarer, hvilke prober der forudsætter et lokalt segment, og det er detaljen, der gør et tomt resultat til en forsvarlig udtalelse.