Nmap-råskanning feiler over en VPN, men -sT-tilkobling virker?

En side lastes gjennom tunnelen mens en portskanning melder at verten er nede, og den første tanken er at VPN-en blokkerer noe. Vanligvis blokkerer den ikke noe nytt. De to testene ber operativsystemet om ulike evner, og bare én av dem trenger rå pakketilgang. Finn ut hvilken evne som sviktet før du rører tunnelen.

Skill evnen fra tunnelen

En vanlig applikasjon ber kjernen åpne en TCP-tilkobling, og kjernen utfører håndtrykket uten spesielle rettigheter. En rå skanning bygger pakkene selv, noe som krever en rå socket eller en opptaksdriver avhengig av plattformen. Det er spørsmål om tillatelser og drivere, og de finnes uansett om en VPN er tilkoblet.

Denne forskjellen forklarer den vanlige asymmetrien. curl lykkes fordi socket-stien virker, mens SYN-skanningen feiler fordi prosessen ikke kan åpne en rå socket på tunnelets grensesnitt. Den forklarer også det motsatte tilfellet, der en rå skanning rapporterer filtrert fordi stien slipper sonden mens applikasjonens sti forblir bra.

Ingen av resultatene beskriver den eksterne tjenesten. Begge beskriver én sti under én metode, så hold metoden knyttet til konklusjonen.

Kjør tilkoblingssjekken på én godkjent vert

Velg den ene verten oppgaven din dekker, og bruk deretter modusen som ikke krever rå tilgang. Eksempelmålet her er 198.51.100.24, dokumentasjonsplass reservert for denne typen illustrasjon.

Én linje, én vert, én port, ingen oppdagelsesfase:

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

-sT velger en full TCP-tilkobling, så den går gjennom samme kjernesti som en applikasjon bruker og krever ingen opptaksdriver. -Pn hopper over vertsoppdagelse; nmap utfører likevel lenkelagsoppslag for mål i det lokale segmentet, så flagget er ikke et løfte om null forhåndstrafikk. --unprivileged ber nmap anta at det ikke har rå eller snusende rettigheter, noe som endrer metoden og ikke gir noe.

Les hvert flagg som én endring, ikke som en reparasjon

Behandle hvert valg som en påstand om metoden. Verken -sT, -Pn eller --unprivileged legger til en rute, åpner en ekstern brannmur eller validerer et sertifikat. En tilkoblingsskanning fullfører også et ekte håndtrykk som tjenesten logger, så en godkjent kontroll og en uautorisert gjennomgang ser like ut fra serveren bortsett fra omfang og tempo. Å stable valg til utdataene endres er måten et metodeproblem blir registrert som et nettverksfunn.

Når utdataene sier lukket, svarte noe med en tilbakestilling, og det er et annet funn enn stillhet. Når utdataene sier filtrert, slapp en enhet sonden eller svaret, og VPN-en kan være tilfeldig. Skriv ned den nøyaktige ordlyden, fordi en dom fra oppdagelsesfasen og en feil på sondenivå peker på ulike lag.

Hvis en privilegert modus virkelig er nødvendig, avgjør plattformeieren om rettigheten, driveren og grensesnittoppsettet støttes. Å heve samme kommando endrer ikke metoden.

Stopp ved transportresultatet, og test deretter tjenesten

Et fullført håndtrykk svarer på ett spørsmål om én adresse, port, kilde og tid. Det beviser ikke at backend-en er sunn, fordi en lastbalanserer eller forward-proxy kan godta tilkoblingen mens applikasjonen bak er nede.

Følg opp med tjenestens egen klient slik at TLS-identitet og applikasjonsatferd observeres som separate 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

Én vane til holder resultatet nyttig. Noter den nøyaktige kommandoen, kildeadressen den brukte og tidspunktet, fordi et transportresultat uten den sammenhengen ikke kan gjentas eller sammenlignes.

Hvis sertifikatet nevner en vert du ikke forventet, virket transporten, og ruting var aldri problemet; feilen ligger i virtuell hosting eller DNS. Hvis håndtrykket feiler, noter den lokale feilteksten i stedet for å generalisere om tunnelen. Ha omfangsnotatet ved siden av resultatet, fordi neste person må vite hvilken metode som skapte det.