A telefonon futó VPN engedélyezett értékelése csendben elbukik, ha a vizsgálóeszköz a csatorna rossz oldalán ül. Kapunk eredményeket, azok hihetőnek látszanak, és olyan kérdésre válaszolnak, amelyet senki nem tett fel. Járja végig az alábbi öt ellenőrzést sorrendben. Mindegyiknek van leállási feltétele, és a korai leállás olcsóbb, mint a jelentés megírása után nulláról újra tesztelni.

1. lépés: nevezze meg a felületet, amelyet el szeretne érni

Három felületet szokás összekeverni, mert egyetlen eszköz köti össze őket. Eltérő kódot és eltérő házirendet futtatnak, ezért bármi elkezdése előtt írja le, melyik van a hatókörben.

Assessment targetWhat the path exercises
Public VPN listener on the handsetReachability before login, plus the exposed VPN daemon
A service on the handset, by its tunnel addressAccess after admission to something hosted locally
A LAN host behind the handset gatewayForwarding, the return path and downstream access policy

Ha a jóváhagyott hatókör nem mondja meg, melyik a három közül, álljon meg és kérdezzen. A telefon rootolása nem válaszol erre a kérdésre, és a tesztelt dolgot változtatja meg, nem a megfigyelési pontot.

Rögzítse a célokat, az engedélyezett forráscímeket, az időablakot és az intenzitáskorlátot egyszerre. A csatorna elvisz a hatókörig; nem ad engedélyt mindennek a vizsgálatára, amit át tud irányítani.

2. lépés: válassza ki azt a forrást, amely látja ezt a felületet

A VPN-en belül ülő vizsgálóeszköz nem tud hitelesítetlen internetes megfigyelőt reprodukálni. Már rendelkezik olyan útvonalakkal, hitelesítő adatokkal és engedélyekkel, amelyekkel a külső megfigyelő nem, ezért eredményei a beengedés utáni képet írják le akkor is, ha a célfelület ugyanaz. A fordított hiba ugyanilyen gyakori. A VPN-port nyilvános vizsgálata szinte semmit sem mond a bejelentkezés mögötti privát szolgáltatásról, és úgy bemutatni, mintha mondana, egy irányban túlbecsüli a kitettséget, a másikban alábecsüli.

Álljon meg, ha a beszerezhető forrás nem illik a felülethez. A csatornán belüli partnertől futtatott értékelést nem szabad hitelesítés előtti eredményként bemutatni, és a jóváhagyott külső forrást igénylő tesztet nem szabad csendben belülre vinni a papírmunka elkerülésére.

3. lépés: erősítse meg az útvonalat és a válaszútvonalat a telefonon keresztül

Amikor az eszköz egy másik alhálózatba továbbít, a vizsgálóeszköznek engedélyezett útvonalra van szüksége, a célnak pedig működő visszaútra. Erősítse meg mindkettőt, ahelyett hogy feltételezné, hogy a ping-válasz teljes útvonalat jelent.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

A forrás NAT megváltoztatja, mit lát a továbbított szolgáltatás. Ha a telefon lefordítja a vizsgálóeszköz címét, a cél hozzáférési szabályai és naplói a lefordított címre vonatkoznak, ezért a szolgáltatás, amely úgy tűnik, elfogadja Önt, talán a telefont fogadja el, nem a vizsgálóeszközt.

Figyeljen a vizsgálóeszköz saját hálózatával való átfedésre is. Ha a telefon a 192.168.1.0/24 hálózatot irányítja, és a vizsgálóeszköz ugyanígy számozott LAN-on ül, a próbák helyi eszközöket találnak el, és a jelentés célként írja le őket. Egyetlen csomag elküldése előtt ellenőrizze, melyik útvonalat használná maga a vizsgálóeszköz.

A cél tényleges címét vizsgálja, és tartsa meg a hosztnevet, amelyre az alkalmazásnak a TLS-identitáshoz és a virtuális hosztinghoz szüksége van. Az átjáró elérése bizonyítja, hogy az átjáró válaszol; nem teszteli a mögötte lévő szolgáltatást.

4. lépés: kezelje a felderítést feltételezésekkel járó próbának

A hosztfelderítés az a pont, ahol az értékelési eredmények leggyakrabban félremennek. A helyi Ethernet-felderítés nem lép át egy irányított VPN-t, ezért a lapos LAN-on működő próbák egyszerűen nem érkeznek meg. A blokkolt felderítési próbák aztán elérhető, engedélyezett szolgáltatást mutatnak hiányzónak.

Tudatosan döntse el, kihagyja-e a felderítést és közvetlenül vizsgálja az ismert címeket, majd mondja ezt a jelentésben. A válaszoló port nem bizonyítéka a sikeres VPN-hitelesítésnek, és a szűrt válasz nem bizonyítéka annak, hogy semmi sem figyel. A sebesség ugyanazon probléma része. A gyors vizsgálat alatt fojtó vagy csomagot ejtő telefon olyan szűrt állapotokat hoz létre, amelyek a telefonhoz és nem a szolgáltatáshoz tartoznak, ezért csökkentse a párhuzamosságot, és a port zártként rögzítése előtt vizsgálja újra.

A leállási feltétel itt értelmezés, nem technika: ha nem tudja megmondani, mit jelent egy állapot ezen az útvonalon, az eredmény a függelékbe tartozik, nem a megállapításokba.

5. lépés: tartsa az ablakot, majd zárja le

A telefon rossz szerver, mert alvásra tervezték. Az akkumulátor-optimalizálás, a doze és a Wi-Fi energia-gazdálkodás felfüggesztheti az alkalmazást az értékelés közepén, és a csatorna újracsatlakozása megváltoztathatja a célt használó címet. Az ilyen események egyikét átfogó futás érvénytelen eredményablakot kap.

Tartsa az átjáró szerepét a jóváhagyott feladat által engedett legszűkebb hatókörben, figyelje a csatornát, amíg a futás él, és naplózza minden jelentett ablak kezdetét és végét. Amikor az értékelés véget ér, távolítsa el az ideiglenes hozzáférést a tulajdonosán keresztül, őrizze meg a forrás- és útvonalrekordot, és védje a kimenetet, mint bármely más tesztartefaktumot.

Ha ismételhető megfigyelési pontra van szüksége egyszeri siker helyett, az az a szállítandó eredmény, amely mellett érvelni kell. a hosztfelderítésről szóló hivatkozás elmagyarázza, mely próbák tételeznek fel helyi szegmenst, és ez az a részlet, amely az üres eredményt védhető állítássá változtatja.

Kapcsolódó cikkek