Surové skenování Nmap selhává přes VPN, ale připojení -sT funguje?

Stránka se načítá tunelem, zatímco sken portů hlásí hostitele jako nedostupného, a první instinkt je, že VPN něco blokuje. Obvykle neblokuje nic nového. Oba testy žádají operační systém o různé schopnosti a jen jeden z nich potřebuje surový přístup k paketům. Zjistěte, která schopnost selhala, než se dotknete tunelu.

Oddělte schopnost od tunelu

Běžná aplikace požádá jádro o otevření TCP spojení a jádro provede handshake bez zvláštního oprávnění. Surové skenování sestavuje pakety samo, což vyžaduje surový socket nebo zachytávací ovladač podle platformy. To jsou otázky oprávnění a ovladačů a existují bez ohledu na to, zda je VPN připojená.

Tento rozdíl vysvětluje obvyklou asymetrii. curl uspěje, protože cesta socketu funguje, zatímco SYN sken selže, protože proces nemůže otevřít surový socket na rozhraní tunelu. Vysvětluje i opačný případ, kdy surové skenování hlásí filtrováno, protože cesta zahodí sondu, zatímco cesta aplikace zůstává v pořádku.

Ani jeden výsledek nepopisuje vzdálenou službu. Oba popisují jednu cestu pod jednou metodou, takže držte metodu připojenou k závěru.

Spusťte kontrolu připojení na jednom schváleném hostiteli

Vyberte jediného hostitele, který vaše úloha pokrývá, a pak použijte režim, který nevyžaduje surový přístup. Ukázkový cíl je zde 198.51.100.24, dokumentační prostor vyhrazený pro tento druh ilustrace.

Jeden řádek, jeden hostitel, jeden port, žádná fáze objevování:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT volí plné TCP spojení, takže procvičí stejnou cestu jádra, kterou používá aplikace, a nepotřebuje zachytávací ovladač. -Pn přeskakuje objevování hostitelů; nmap přesto provádí rozlišení linkové vrstvy pro cíle v místním segmentu, takže přepínač není slibem nulového předběžného provozu. --unprivileged říká nmap, aby předpokládal, že nemá surová ani odposlouchávací práva, což mění metodu a nic neuděluje.

Čtěte každý přepínač jako jednu změnu, ne jako opravu

Berte každou volbu jako tvrzení o metodě. Ani -sT, ani -Pn, ani --unprivileged nepřidává trasu, neotevírá vzdálený firewall ani neověřuje certifikát. Skenování připojení také dokončí skutečný handshake, který služba zaznamená, takže schválená kontrola a neschválené pročesávání vypadají ze serveru stejně kromě rozsahu a tempa. Vrstvení voleb, dokud se výstup nezmění, je způsob, jak se problém metody zapíše jako síťový nález.

Když výstup říká zavřeno, něco odpovědělo resetem, a to je jiný nález než ticho. Když výstup říká filtrováno, zařízení zahodilo sondu nebo její odpověď a VPN může být náhodná. Zapište přesnou formulaci, protože verdikt fáze objevování a selhání na úrovni sondy ukazují na různé vrstvy.

Pokud je privilegovaný režim skutečně nutný, vlastník platformy rozhodne, zda jsou oprávnění, ovladač a uspořádání rozhraní podporovány. Povýšení stejného volání nemění jeho metodu.

Zastavte se u výsledku transportu, pak otestujte službu

Dokončený handshake odpovídá na jednu otázku o jedné adrese, portu, zdroji a okamžiku. Nedokazuje, že backend je zdravý, protože vyvažovač zátěže nebo dopředná proxy může přijmout spojení, zatímco aplikace za ní neí běží.

Následujte jej vlastním klientem služby, aby se identita TLS a chování aplikace pozorovaly jako oddělená fakta:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

Ještě jeden zvyk udrží výsledek užitečný. Zapište přesný příkaz, zdrojovou adresu, kterou použil, a čas, protože výsledek transportu bez tohoto kontextu nelze reprodukovat ani porovnat.

Pokud certifikát uvádí hostitele, kterého jste nečekali, transport fungoval a směrování nikdy nebylo problémem; závada je ve virtuálním hostingu nebo DNS. Pokud handshake selže, zapište místní chybový řetězec místo zobecňování o tunelu. Držte poznámku o rozsahu vedle výsledku, protože další člověk musí vědět, která metoda jej vytvořila.