En portscanning kan ikke fortælle, hvem der accepterer login

Tre spørgsmål bliver blandet sammen, når nogen vifter med en portscanning foran et VPN-problem: er noget tilgængeligt, er det den tjeneste, du tror, og vil den acceptere din identitet. En scanner besvarer det første og peger sløret på det andet. Det tredje kan den slet ikke besvare, fordi accept af en legitimationsoplysning ikke er det, en transportsonde gør. Beslut, hvilket spørgsmål du stiller, før du læser outputtet.

Værktøjet tager ikke fejl; det besvarer et snævrere spørgsmål end det, der ligger på bordet.

En åben socket er et faktum om en socket

En vellykket TCP-forbindelse betyder, at noget accepterede det endpoint. Den fastslår ikke, at lytteren er den tilsigtede VPN-tjeneste, at det fremlagte certifikat svarer til det navn, du forventer, eller at TLS-verifikationen ville bestå. En administrationsside for gatewayen på samme værtsnavn er en helt anden tjeneste, og den viser intet om tunnelen. Behandl resultatet som et faktum om tilgængelighed og ikke mere.

Hvor sonden faktisk hjælper, er med at udelukke ting. Hvis intet accepterer forbindelsen fra din placering, kan håndtrykket ikke lykkes, og det indsnævrer søgningen til tilgængelighed før noget andet.

UDP-stilhed har flere forklaringer

UDP-protokoller kan med rette ignorere pakker, der ikke er autentificeret, så et manglende svar er ikke en dom. Det kan betyde filtrering på vejen, et lukket endpoint eller en tjeneste, der bevidst forholder sig tavs, indtil den modtager noget gyldigt. At læse stilhed som en lukket port sender folk til firewall-regler, når den egentlige fejl er i profilen. Gentag sonden fra et andet netværk, før du drager nogen konklusion.

Tvetydigheden er en egenskab ved protokollen, ikke en mangel i værktøjet. Sig det tydeligt, når du rapporterer resultatet, fordi et selvsikkert forkert svar er værre end et usikkert rigtigt.

Tillidsbeslutningen er stadig din

En åben port træffer ikke tillidsbeslutningen, så et scannerresultat er ingen grund til at slå certifikatkontroller fra. Den verifikation findes for at besvare, om du nåede den peer, du havde tænkt på, og en scanner har ikke besvaret det. Brug operatørens rigtige profil og klient til identitet og autentificering, og behold derefter verifikationsindstillingerne præcis som de var.

Hvis scanningen siger åben, og håndtrykket mislykkes, er den interessante del af fejlen i håndtrykket, ikke i scanningen.

Test udvekslingen, derefter ruten

Når autentificeringen lykkes, undersøg de næste faser hver for sig: datatilknytning, installerede ruter og applikationsadgang. Hver af dem kan fejle, mens den foregående så sund ud, og hver har sine egne beviser. At korrelere klient- og lytterlogfiler med snævre optagelser eller tællere giver en rutediagnose, som gentagen scanning aldrig vil give. Hold profilen og endpointet fast, når du sammenligner netværk, og notér, hvor forhandlingen stopper.

Hold også diagnostikkens omfang autoriseret. At sondere systemer, du ikke ejer, er ikke en fejlfindingsmetode, uanset hvad værktøjet siger om resultatet.

Scanningen besvarer tilgængelighed. Autentificering kræver en legitimationsoplysning, og ruten kræver en pakke. En scanner kan rapportere en åben port, mens tjenesten afviser hvert login, og den kan rapportere en lukket port, mens en gyldig session virker fra et andet netværk. Behandl resultatet som én observation om én vej, og test derefter legitimationsoplysningen og returruten hver for sig.