Een portscan vertelt niet wie de login accepteert

Drie vragen raken door elkaar wanneer iemand een portscan voor een VPN-probleem houdt: is er iets bereikbaar, is het de dienst die je denkt, en zal die je identiteit accepteren. Een scanner beantwoordt de eerste en wijst vaag naar de tweede. De derde kan hij helemaal niet beantwoorden, want het accepteren van inloggegevens is niet wat een transportprobe doet. Bepaal welke vraag je stelt voordat je de uitvoer leest.

Het gereedschap heeft geen ongelijk; het beantwoordt een engere vraag dan die op tafel ligt.

Een open socket is een feit over een socket

Een geslaagde TCP-verbinding betekent dat iets dat eindpunt heeft geaccepteerd. Het bewijst niet dat de luisteraar de bedoelde VPN-dienst is, dat het aangeboden certificaat bij de verwachte naam past, of dat de TLS-verificatie zou slagen. Een beheerpagina van de gateway op dezelfde hostnaam is een heel andere dienst, en die toont niets over de tunnel. Behandel het resultaat als een bereikbaarheidsfeit en niets meer.

Waar de probe wel helpt, is bij het uitsluiten. Als niets de verbinding vanaf jouw locatie accepteert, kan de handshake niet slagen, en dat vernauwt de zoektocht naar bereikbaarheid vóór al het andere.

UDP-stilte heeft meerdere verklaringen

UDP-protocollen mogen pakketten die niet geauthenticeerd zijn legitiem negeren, dus een ontbrekend antwoord is geen vonnis. Het kan filtering op het pad betekenen, een gesloten eindpunt of een dienst die bewust stil blijft tot hij iets geldigs ontvangt. Stilte als een gesloten poort lezen stuurt mensen naar firewallregels terwijl de echte fout in het profiel zit. Herhaal de probe vanaf een ander netwerk voordat je enige conclusie trekt.

De dubbelzinnigheid is een eigenschap van het protocol, geen gat in het gereedschap. Zeg het duidelijk wanneer je het resultaat rapporteert, want een zelfverzekerd fout antwoord is erger dan een onzeker juist.

De vertrouwensbeslissing blijft aan jou

Een open poort neemt de vertrouwensbeslissing niet, dus een scannerresultaat is geen reden om certificaatcontroles uit te schakelen. Die verificatie bestaat om te beantwoorden of je de bedoelde peer hebt bereikt, en een scanner heeft dat niet beantwoord. Gebruik het echte profiel en de client van de operator voor identiteit en authenticatie, en laat daarna de verificatie-instellingen precies zoals ze waren.

Als de scan open zegt en de handshake mislukt, zit het interessante deel van de fout in de handshake, niet in de scan.

Test de uitwisseling, dan de route

Zodra de authenticatie slaagt, inspecteer je de volgende fasen apart: gegevenskoppeling, geïnstalleerde routes en toepassingstoegang. Elk kan mislukken terwijl de vorige gezond leek, en elk heeft zijn eigen bewijs. Client- en luisteraarlogs correleren met smalle opnames of tellers geeft een paddiagnose die herhaald scannen nooit zal geven. Houd het profiel en het eindpunt vast bij het vergelijken van netwerken, en noteer waar de onderhandeling stopt.

Houd ook de diagnostische scope geautoriseerd. Systemen sonderen die niet van jou zijn is geen probleemoplossingstechniek, wat het gereedschap ook over het resultaat zegt.

De scan beantwoordt bereikbaarheid. Authenticatie heeft inloggegevens nodig, en de route heeft een pakket nodig. Een scanner kan een open poort melden terwijl de dienst elke login weigert, en hij kan een gesloten poort melden terwijl een geldige sessie vanaf een ander netwerk werkt. Behandel het resultaat als één observatie over één pad, en test dan de inloggegevens en de retourroute apart.