Alegeți punctul de observare potrivit pentru o scanare VPN pe telefon
Ascultătorul VPN al telefonului, un serviciu pe telefon și un host LAN rutat sunt trei suprafețe. Parcurgeți acești cinci pași și opriți-vă acolo unde se termină domeniul.
O evaluare autorizată a unui VPN găzduit pe un telefon eșuează în tăcere când scannerul stă de partea greșită a tunelului. Obțineți rezultate, par plauzibile și răspund la o întrebare pe care nimeni nu a pus-o. Parcurgeți cele cinci verificări de mai jos în ordine. Fiecare are o condiție de oprire, iar oprirea devreme costă mai puțin decât retestarea de la zero după ce raportul este scris.
Pasul 1: numiți suprafața pe care intenționați să o atingeți
Trei suprafețe sunt confundate frecvent pentru că un singur dispozitiv le conectează. Rulează cod și politici diferite, așa că notați care este în domeniu înainte de a începe ceva.
| 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 |
Dacă domeniul aprobat nu spune care dintre cele trei, opriți-vă și întrebați. Obținerea root pe telefon nu răspunde la această întrebare și schimbă lucrul testat, nu punctul de observare.
Notați țintele, adresele sursă permise, fereastra de timp și limita de intensitate în același timp. Tunelul vă duce la acel domeniu; nu vă autorizează să sondați tot ce poate ruta.
Pasul 2: alegeți sursa care poate vedea acea suprafață
Un scanner aflat în interiorul VPN-ului nu poate reproduce un observator de internet neautentificat. Are deja rute, credențiale și permisiuni pe care observatorul din exterior nu le are, așa că rezultatele sale descriu vederea de după admitere chiar și când suprafața țintă este aceeași. Greșeala inversă este la fel de frecventă. O scanare publică a portului VPN nu spune aproape nimic despre un serviciu privat din spatele autentificării, iar prezentarea ei ca și cum ar spune exagerează expunerea într-o direcție și o subestimează în cealaltă.
Opriți-vă dacă sursa pe care o puteți obține nu corespunde suprafeței. O evaluare executată de la un partener din interiorul tunelului nu trebuie prezentată ca rezultat dinaintea autentificării, iar un test care cere o sursă externă aprobată nu trebuie mutat în tăcere înăuntru pentru a evita hârtiile.
Pasul 3: confirmați ruta și calea de răspuns prin telefon
Când dispozitivul redirecționează către altă subrețea, scannerul are nevoie de o rută permisă, iar ținta de o cale de întoarcere care funcționează. Confirmați ambele în loc să presupuneți că un răspuns ping înseamnă că calea este completă.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8NAT-ul sursă schimbă ce vede serviciul din aval. Dacă telefonul traduce adresa scannerului, regulile de acces și jurnalele din țintă se aplică adresei traduse, așa că un serviciu care pare să vă accepte poate accepta telefonul, nu scannerul.
Fiți atenți și la o suprapunere cu rețeaua scannerului. Dacă telefonul rutează 192.168.1.0/24 și scannerul stă într-o LAN numerotată la fel, sondele lovesc dispozitive locale, iar raportul le descrie ca țintă. Verificați ruta pe care ar folosi-o scannerul însuși înainte de a trimite un singur pachet.
Scanați adresa reală a țintei și păstrați numele de gazdă de care aplicația are nevoie pentru identitatea TLS și găzduirea virtuală. Atingerea unui gateway dovedește că gateway-ul răspunde; nu testează serviciul din spatele lui.
Pasul 4: tratați descoperirea ca pe o sondă cu presupuneri
Descoperirea gazdelor este locul unde rezultatele evaluării greșesc cel mai des. Descoperirea locală prin Ethernet nu traversează un VPN rutat, așa că sondele care funcționează într-o LAN plată pur și simplu nu ajung. Sondele de descoperire blocate fac atunci un serviciu accesibil și autorizat să pară absent.
Decideți conștient dacă săriți descoperirea și scanați direct adresele cunoscute, apoi spuneți asta în raport. Un port care răspunde nu este dovada că autentificarea VPN a reușit, iar un răspuns filtrat nu este dovada că nimic nu ascultă. Și ritmul face parte din aceeași problemă. Un telefon care limitează sau pierde pachete la o scanare rapidă produce stări filtrate care aparțin telefonului, nu serviciului, așa că reduceți concurența și rescanați înainte de a înregistra un port ca închis.
Condiția de oprire aici este de interpretare, nu de tehnică: dacă nu puteți spune ce înseamnă o stare pentru această cale, rezultatul aparține unui anexă, nu constatărilor.
Pasul 5: țineți fereastra, apoi închideți-o
Un telefon este un server slab pentru că este proiectat să doarmă. Optimizarea bateriei, doze și gestionarea energiei Wi-Fi pot suspenda aplicația la mijlocul evaluării, iar o reconectare a tunelului poate schimba adresa folosită de țintă. O execuție care traversează unul dintre aceste evenimente are o fereastră de rezultate invalidă.
Țineți rolul de gateway în cel mai mic domeniu pe care îl permite sarcina aprobată, observați tunelul cât timp execuția este activă și consemnați începutul și sfârșitul fiecărei ferestre pe care o raportați. Când evaluarea se termină, eliminați accesul temporar prin proprietarul lui, păstrați înregistrarea sursei și a rutei și protejați rezultatul ca orice alt artefact de test.
Dacă aveți nevoie de un punct de observare repetabil în locul unui succes unic, acesta este rezultatul pentru care merită să argumentați.referința despre descoperirea gazdelor explică ce sonde presupun un segment local, iar acel detaliu este cel care transformă un rezultat gol într-o afirmație care poate fi apărată.