Изберете правилната точка за наблюдение при сканиране на VPN от телефон
Слушателят на VPN на телефона, услуга на телефона и маршрутизиран LAN хост са три повърхности. Извървете тези пет стъпки и спрете там, където спира обхватът.
Оторизирана оценка на VPN, хостван на телефон, се проваля тихо, когато скенерът стои от грешната страна на тунела. Получавате резултати, те изглеждат правдоподобни и отговарят на въпрос, който никой не е задавал. Преминете през петте проверки по-долу по ред. Всяка има условие за спиране и спирането по-рано е по-евтино от повторно тестване от нулата, след като докладът е написан.
Стъпка 1: назовете повърхността, която искате да достигнете
Три повърхности редовно се бъркат, защото едно устройство ги свързва. Те задействат различен код и различна политика, затова запишете коя е в обхвата, преди да започне каквото и да е.
| 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 |
Ако одобреният обхват не казва коя от трите, спрете и попитайте. Получаването на root на телефона не отговаря на този въпрос и променя тестваното, а не точката за наблюдение.
Запишете целите, разрешените изходни адреси, времевия прозорец и ограничението за интензивност едновременно. Тунелът ви отвежда до този обхват; той не дава право да проверявате всичко, което може да маршрутизира.
Стъпка 2: изберете източника, който вижда тази повърхност
Скенер, разположен вътре във VPN не може да възпроизведе неавтентикиран интернет наблюдател. Той вече има маршрути, идентификационни данни и разрешения, които външният наблюдател няма, затова резултатите му описват гледката след допускане, дори когато целевата повърхност е същата. Обратната грешка е също толкова честа. Публичното сканиране на VPN порта не казва почти нищо за частна услуга зад входа и представянето му като такова преувеличава излагането в една посока и го подценява в другата.
Спрете, ако източникът, който можете да получите, не съответства на повърхността. Оценка, изпълнена от партньор вътре в тунела, не бива да се представя като резултат преди автентикация, а тест, който изисква одобрен външен източник, не бива тихо да се мести вътре, за да се избегне документацията.
Стъпка 3: потвърдете маршрута и пътя на отговора през телефона
Когато апаратът препраща към друга подмрежа, на скенера му трябва разрешен маршрут, а на целта — работещ път за отговор. Потвърдете и двете, вместо да предполагате, че отговор на ping означава, че пътят е пълен.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Source NAT променя това, което вижда услугата надолу по веригата. Ако телефонът преобразува адреса на скенера, правилата за достъп и журналите в целта се прилагат към преобразувания адрес, затова услуга, която изглежда ви приема, може да приема телефона, а не скенера.
Следете и за застъпване със собствената мрежа на скенера. Ако телефонът маршрутизира 192.168.1.0/24, а скенерът е в LAN с номерация по същия начин, сондите удрят локални устройства и докладът ги описва като целта. Проверете маршрута, който самият скенер би използвал, преди да изпратите дори един пакет.
Сканирайте истинския адрес на целта и запазете името на хоста, което приложението изисква за идентичност на TLS и виртуален хостинг. Достигането на шлюз доказва, че шлюзът отговаря; то не тества услугата зад него.
Стъпка 4: третирайте откриването като сонда с предположения
Откриването на хостове е мястото, където резултатите от оценката най-често се объркват. Локалното откриване по Ethernet не преминава през маршрутизиран VPN, така че сондите, които работят в плоска LAN, просто не пристигат. Блокираните сонди за откриване тогава правят достъпна, оторизирана услуга да изглежда отсъстваща.
Решете съзнателно дали да пропуснете откриването и да сканирате известните адреси направо, и го кажете в доклада. Порт, който отговаря, не е доказателство, че автентикацията на VPN е успешна, а филтриран отговор не е доказателство, че нищо не слуша. Скоростта е част от същия проблем. Телефон, който ограничава или изпуска при бързо сканиране, създава филтрирани състояния, които принадлежат на телефона, а не на услугата, затова намалете паралелността и сканирайте отново, преди да запишете порт като затворен.
Условието за спиране тук е интерпретация, не техника: ако не можете да кажете какво означава дадено състояние за този път, резултатът принадлежи в приложение, а не в констатациите.
Стъпка 5: задръжте прозореца, после го затворете
Телефонът е лош сървър, защото е проектиран да спи. Оптимизацията на батерията, doze и управлението на захранването на Wi-Fi могат да спрат приложението по средата на оценката, а повторното свързване на тунела може да промени адреса, който целта използва. Изпълнение, което обхваща едно от тези събития, има невалиден прозорец на резултатите.
Дръжте ролята на шлюз в най-малкия обхват, който одобрената задача позволява, наблюдавайте тунела, докато изпълнението е активно, и записвайте началото и края на всеки прозорец, който докладвате. Когато оценката приключи, премахнете временния достъп чрез неговия собственик, запазете записа за източника и пътя и защитете изхода както всеки друг тестов артефакт.
Ако имате нужда от възпроизводима точка за наблюдение, а не от еднократен успех, това е резултатът, за който си струва да аргументирате. справката за откриване на хостове обяснява кои сонди предполагат локален сегмент и това е детайлът, който превръща празния резултат в защитимо твърдение.