Hvorfor endrer portskanneresultater seg bak en VPN-utgang?

Kjør den samme portkontrollen fra en kontorlinje og fra en VPN-utgang, og de to svarene kan være uenige om en adresse ingen har endret. Det gapet kommer fra ruten og fra hvilken vert som svarte, ikke fra om tjenesten er oppe eller nede. Tre spørsmål skiller de forklaringene: hva sonden faktisk spurte om, hvilken vert som svarte, og hva din egen server registrerte. Arbeid deg gjennom dem i den rekkefølgen, og skriv ned hvert svar før du går videre til det neste.

Reparer sonden før du sammenligner to kjøringer

Et tilstandsord kan bare sammenlignes med et annet tilstandsord når begge kom fra det samme forsøket. Fem felt låser det fast: kildeadressen den fjerne siden så, den oppløste destinasjonen, porten, skanningstypen og tiden. Endre ett av dem, og du har kjørt et andre forsøk i stedet for å måle det første to ganger.

Sjekk kilden før alt annet, fordi en VPN-klient kan være oppe mens trafikken fortsatt går ut via det fysiske grensesnittet. Spør den fjerne siden hva den ser, og spør deretter kjernen hvilket grensesnitt den valgte:

curl -s https://ifconfig.me
ip route get 203.0.113.20

To adresser på forskjellige nettverk betyr at forklaringen allerede er i hånden, og resten av disse kontrollene vil bare bekrefte den. Når de stemmer, fang sonden med årsaksflagget på, slik at tilstanden kommer tilbake knyttet til en forklaring i stedet for å stå alene som et bart ord. Skanningstypen hører også med i den posten, fordi den beskriver hva som ble spurt om, ikke hva som kom tilbake. En tilstand uten kilde, uten metode og uten tidsstempel kan ikke sammenlignes med noe:

nmap -sT -p 443,8443 --reason 203.0.113.20

Oppbevar den utskriften ved siden av posten i stedet for i en rullebuffer som neste person ikke kan se. To ærlige skanninger som er uenige, er bare en diskusjon når ingen har skrevet ned betingelsene. Med betingelsene fastsatt, enten stemmer resultatene og spørsmålet er lukket, eller de er forskjellige og forskjellen er et faktum om ruten.

Finn ut hvilken vert som fullførte håndtrykket

Et fullført håndtrykk beviser at en eller annen vert fullførte det, og den verten trenger ikke være prosessen du har i tankene. En lastbalanserer, en omvendt proxy eller en SYN-proxy kan svare før den virkelige serveren er involvert, noe som er vanlig design og ikke et symptom. Et gyldig sertifikat for det forventede navnet snevrer heller ikke inn dette, fordi et sertifikat beskriver et tjenesteforhold og ikke sier noe om hvilken maskin som avsluttet forbindelsen.

Nmaps referanse for porttilstander behandler dette som grunnleggende: en tilstand registrerer hva en sonde kunne observere fra der den ble sendt, ikke en egenskap ved porten. Les et tilstandsord slik, og to kjøringer som var uenige begynner å se konsistente ut i stedet for motstridende, mens spørsmålet flytter seg fra om porten er åpen til hvem som sto foran den.

Svar på det andre spørsmålet i backend i stedet for utenfra. En frontend som godtar forbindelser og deretter ikke når upstreamen sin, produserer nøyaktig det utenfra sett sunne bildet av en tjeneste med en treg applikasjon. Bare upstreamens egen post skiller de to tilfellene:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Logglinjen viser klientadressen applikasjonen faktisk så, og den andre kommandoen viser om prosessen som holder port 443 er applikasjonen din eller noe foran den. Hvis de to er uenige om hvilken adresse som koblet til, ser du på to ben av én forespørsel, og billetten bør si det.

Sjekk dine egne regler før du klandrer tunnelen

Bevisst politikk er den vanligste grunnen til at en port svarer på ett nettverk og ikke på et annet, og det er den minst interessante forklaringen som finnes. Tilgangsregler finnes for å tillate én kilde og forkaste resten, så en endring av utgang er nettopp hendelsen de ble skrevet for. Derfor viser en annen tilstand gjennom en VPN ikke at leverandøren inspiserer trafikk. Den viser at kildeadressen din nå er annerledes, noe som er en mye mindre påstand.

Disse reglene kan leses på serveren, så les dem i stedet for å spekulere om midten av nettverket. List opp filterreglene som nevner et av de to adresseområdene, og sjekk deretter om forbindelsen i det hele tatt nådde daemonen:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Et tomt andre resultat er informativt, fordi ingenting nådde daemonen, og spørsmålet tilhører et filter, en sikkerhetsgruppe eller selve ruten. Et treff betyr at tjenesten så kilden din og valgte svaret sitt, og den beslutningen er vanligvis skrevet i en regel du kan lese. Ingen av resultatene støtter en historie om leverandøren, og begge er billigere å sjekke enn en pakkefangst.

Les transport, sertifikat og svar hver for seg

Tre lag gir tre observasjoner, og en sonde som tester ett av dem kan ikke rapportere om de to andre. Hold dem som separate linjer i posten i stedet for å brette dem sammen til én dom, fordi hver linje feiler på sin egen måte, og feilmodusen forteller deg hvor du skal se neste gang.

Én kommando produserer de tre første radene mot en tjeneste du kontrollerer. Legg utdataene i posten ved siden av skanningen i stedet for i en chatmelding:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Les utdataene i rekkefølge: håndtrykket svarer på transportspørsmålet, sertifikatets emne svarer på navnespørsmålet, og svarets kropp svarer på applikasjonsspørsmålet. Når håndtrykkslinjen lykkes og svarlinjen ikke, har du en frontend med brutt upstream i stedet for en blokkert port. Det er en annen billett enn den du åpnet, og det er verdt å si det tydelig.

Avslutt med å skrive fire fakta i billetten: kildeadresse, skanningstype, verten som svarte, og tiden. Alt en senere sammenligning trenger, lever i de fire, og den som tar saken neste gang vil ikke ha terminalhistorikken din. Hvis du ikke kan fylle ut alle fire, er kjøringen ikke ferdig.