Waarom veranderen resultaten van poortscans achter een VPN-uitgang?
Wissel de uitgang en een poort kan anders antwoorden zonder dat de dienst beweegt. Scheid de waarneming van het pad van de inventaris die je echt nodig hebt.
Voer dezelfde poortcontrole uit vanaf een kantoorlijn en vanaf een VPN-uitgang, en de twee antwoorden kunnen het oneens zijn over een adres dat niemand heeft gewijzigd. Dat gat komt van de route en van welke host antwoordde, niet van of de dienst aan of uit staat. Drie vragen scheiden die verklaringen: wat de probe werkelijk vroeg, welke host antwoordde en wat je eigen server registreerde. Werk ze in die volgorde door en schrijf elk antwoord op voordat je naar de volgende gaat.
Repareer de probe voordat je twee runs vergelijkt
Een toestandswoord is alleen vergelijkbaar met een ander toestandswoord als beide uit hetzelfde experiment komen. Vijf velden leggen dat vast: het bronadres dat de verre kant zag, de opgeloste bestemming, de poort, het scantype en de tijd. Wijzig een van hen en je hebt een tweede experiment gedaan in plaats van het eerste twee keer te meten.
Controleer de bron voor al het andere, want een VPN-client kan aan staan terwijl verkeer nog steeds via de fysieke interface naar buiten gaat. Vraag de verre kant wat die ziet en vraag dan de kernel welke interface hij koos:
curl -s https://ifconfig.me
ip route get 203.0.113.20Twee adressen op verschillende netwerken betekenen dat de verklaring al in handen is, en de rest van deze controles zal die alleen bevestigen. Als ze overeenkomen, leg de probe vast met de redenvlag aan, zodat de toestand terugkomt verbonden met een verklaring in plaats van alleen als een kaal woord te staan. Het scantype hoort ook in dat record, want het beschrijft wat er gevraagd is, niet wat er terugkwam. Een toestand zonder bron, zonder methode en zonder tijdstempel valt met niets te vergelijken:
nmap -sT -p 443,8443 --reason 203.0.113.20Bewaar die uitvoer naast het record en niet in een scrollbackbuffer die de volgende persoon niet kan zien. Twee eerlijke scans die het oneens zijn, zijn alleen een discussie als niemand de voorwaarden heeft opgeschreven. Met de voorwaarden vastgelegd, of de resultaten komen overeen en de vraag is gesloten, of ze verschillen en het verschil is een feit over het pad.
Zoek uit welke host de handdruk voltooide
Een voltooide handdruk bewijst dat een of andere host hem voltooide, en die host hoeft niet het proces te zijn dat je in gedachten hebt. Een loadbalancer, een omgekeerde proxy of een SYN-proxy kunnen antwoorden voordat de echte server betrokken is, wat gewoon ontwerp is en geen symptoom. Een geldig certificaat voor de verwachte naam beperkt dit ook niet, want een certificaat beschrijft een dienstrelatie en zegt niets over welke machine de verbinding beëindigde.
De Nmap-referentie voor poorttoestanden beschouwt dit als basis: een toestand legt vast wat een probe vanaf het verzendpunt kon waarnemen, niet een eigenschap van de poort. Lees een toestandswoord zo en twee runs die het oneens waren gaan er consistent uitzien in plaats van tegenstrijdig, terwijl de vraag verschuift van of de poort open is naar wie ervoor stond.
Beantwoord de tweede vraag in de backend en niet van buitenaf. Een frontend die verbindingen accepteert en dan zijn upstream niet bereikt, levert precies het uiterlijke beeld op van een gezonde dienst met een trage applicatie. Alleen het eigen record van de upstream scheidt de twee gevallen:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'De logregel toont het clientadres dat de applicatie werkelijk zag, en de tweede opdracht toont of het proces dat poort 443 vasthoudt jouw applicatie is of iets ervoor. Als die twee het oneens zijn over welk adres verbond, kijk je naar twee benen van één verzoek en de ticket zou dat moeten zeggen.
Controleer je eigen regels voordat je de tunnel beschuldigt
Bewust beleid is de meest voorkomende reden dat een poort op het ene netwerk antwoordt en op het andere niet, en het is de minst interessante verklaring die beschikbaar is. Toegangsregels bestaan om één bron toe te staan en de rest te laten vallen, dus een verandering van uitgang is precies de gebeurtenis waarvoor ze zijn geschreven. Een andere toestand via een VPN toont daarom niet dat de provider het verkeer inspecteert. Het toont dat je bronadres nu anders is, wat een veel kleinere bewering is.
Die regels zijn op de server leesbaar, dus lees ze in plaats van te speculeren over het midden van het netwerk. Noem de filterregels die een van de twee adresbereiken vermelden, en controleer dan of de verbinding de daemon wel bereikte:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Een leeg tweede resultaat is informatief, want niets bereikte de daemon en de vraag hoort bij een filter, een beveiligingsgroep of het pad zelf. Een treffer betekent dat de dienst je bron zag en zijn antwoord koos, en die beslissing staat meestal in een regel die je kunt lezen. Geen van beide uitkomsten ondersteunt een verhaal over de provider, en beide zijn goedkoper te controleren dan een pakketopname.
Lees transport, certificaat en antwoord apart
Drie lagen produceren drie waarnemingen, en een probe die er één test kan niet over de andere twee rapporteren. Houd ze als aparte regels in het record in plaats van ze in één oordeel te vouwen, want elke regel faalt op zijn eigen manier en de faalmodus vertelt je waar je volgende keer moet kijken.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Eén opdracht produceert de eerste drie regels tegen een dienst die je beheert. Zet de uitvoer in het record naast de scan en niet in een chatbericht:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lees de uitvoer op volgorde: de handdruk beantwoordt de transportvraag, het certificaatonderwerp de naamvraag en de antwoordbody de applicatievraag. Als de handdrukregel slaagt en de antwoordregel niet, heb je een frontend met een kapotte upstream en geen geblokkeerde poort. Dat is een andere ticket dan degene die je opende, en het is de moeite waard dat duidelijk te zeggen.
Sluit af met vier feiten in de ticket: bronadres, scantype, de host die antwoordde en de tijd. Alles wat een latere vergelijking nodig heeft, leeft in die vier, en wie de zaak daarna oppakt heeft niet jouw terminalgeschiedenis. Als je niet alle vier kunt invullen, is de run niet af.