Ruwe scan van Nmap mislukt via een VPN, maar -sT-verbinding werkt?

Een pagina laadt via de tunnel terwijl een poortscan de host als down meldt, en de eerste gedachte is dat de VPN iets blokkeert. Meestal blokkeert die niets nieuws. De twee tests vragen het besturingssysteem om verschillende mogelijkheden, en slechts één ervan heeft ruwe pakkettoegang nodig. Stel vast welke mogelijkheid faalde voordat je de tunnel aanraakt.

Scheid de mogelijkheid van de tunnel

Een gewone toepassing vraagt de kernel een TCP-verbinding te openen, en de kernel voert de handshake uit zonder bijzonder recht. Een ruwe scan bouwt de pakketten zelf, wat een raw socket of een capture-stuurprogramma vereist, afhankelijk van het platform. Dat zijn vragen over rechten en stuurprogramma's, en ze bestaan ongeacht of er een VPN is verbonden.

Dit onderscheid verklaart de gebruikelijke asymmetrie. curl slaagt omdat het socketpad werkt, terwijl de SYN-scan mislukt omdat het proces geen raw socket op de tunnelinterface kan openen. Het verklaart ook het omgekeerde geval, waarin een ruwe scan gefilterd meldt omdat het pad de probe laat vallen terwijl het toepassingspad goed blijft.

Geen van beide resultaten beschrijft de externe dienst. Beide beschrijven één pad onder één methode, dus houd de methode aan de conclusie vast.

Voer de verbindingscontrole uit op één goedgekeurde host

Kies de enige host die je taak dekt en gebruik dan de modus die geen ruwe toegang nodig heeft. Het voorbeelddoel hier is 198.51.100.24, documentatieruimte die voor dit soort illustratie is gereserveerd.

Één regel, één host, één poort, geen ontdekkingsfase:

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

-sT kiest een volledige TCP-verbinding, dus het doorloopt hetzelfde kernelpad als een toepassing en heeft geen capture-stuurprogramma nodig. -Pn slaat hostontdekking over; nmap doet nog steeds linklaag-resolutie voor doelen op het lokale segment, dus de optie is geen belofte van nul voorafgaand verkeer. --unprivileged vertelt nmap aan te nemen dat het geen ruwe of afluisterrechten heeft, wat de methode verandert en niets verleent.

Lees elke optie als één wijziging, niet als een reparatie

Behandel elke optie als een uitspraak over de methode. Geen van -sT, -Pn of --unprivileged voegt een route toe, opent een externe firewall of valideert een certificaat. Een verbindingsscan voltooit ook een echte handshake die de dienst logt, dus een goedgekeurde controle en een niet-goedgekeurde veeg zien er vanaf de server hetzelfde uit, behalve in omvang en tempo. Opties stapelen tot de uitvoer verandert is de manier waarop een methodeprobleem als netwerkbevinding wordt vastgelegd.

Als de uitvoer gesloten zegt, antwoordde iets met een reset, en dat is een andere bevinding dan stilte. Als de uitvoer gefilterd zegt, liet een apparaat de probe of het antwoord vallen, en de VPN kan bijkomstig zijn. Schrijf de exacte formulering op, want een oordeel van de ontdekkingsfase en een fout op probeniveau wijzen op verschillende lagen.

Als een bevoorrechte modus echt nodig is, beslist de platformeigenaar of het recht, het stuurprogramma en de interface-indeling worden ondersteund. Dezelfde aanroep verhogen verandert de methode niet.

Stop bij het transportresultaat en test dan de dienst

Een voltooide handshake beantwoordt één vraag over één adres, poort, bron en moment. Het bewijst niet dat de backend gezond is, want een loadbalancer of forward-proxy kan de verbinding aannemen terwijl de toepassing erachter stil ligt.

Volg het met de eigen client van de dienst, zodat TLS-identiteit en toepassingsgedrag als afzonderlijke feiten worden waargenomen:

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

Nog een gewoonte houdt het resultaat bruikbaar. Noteer het exacte commando, het gebruikte bronadres en de tijd, want een transportresultaat zonder die context kan niet worden herhaald of vergeleken.

Als het certificaat een host noemt die je niet verwachtte, werkte het transport en was routering nooit het probleem; de fout zit in virtuele hosting of DNS. Als de handshake mislukt, noteer dan de lokale foutstring in plaats van te generaliseren over de tunnel. Houd de omvangsnotitie naast het resultaat, want de volgende persoon moet weten welke methode het heeft opgeleverd.