Kvifor endrar portskanneresultata seg bak ein VPN-utgang?

Køyr den same portkontrollen frå ei kontorlinje og frå ein VPN-utgang, og dei to svara kan vere usamde om ei adresse ingen har endra. Det gapet kjem frå ruta og frå kva vert som svarte, ikkje frå om tenesta er oppe eller nede. Tre spørsmål skil dei forklaringane: kva sonden faktisk spurde om, kva vert som svarte, og kva din eigen server registrerte. Arbeid deg gjennom dei i den rekkjefølgja, og skriv ned kvart svar før du går vidare til det neste.

Reparer sonden før du samanliknar to køyringar

Eit tilstandsord kan berre samanliknast med eit anna tilstandsord når begge kom frå det same forsøket. Fem felt låser det fast: kjeldearadressa den fjerne sida såg, den oppløyste destinasjonen, porten, skanningstypen og tida. Endre eitt av dei, og du har køyrt eit andre forsøk i staden for å måle det første to gonger.

Sjekk kjelda før alt anna, fordi ein VPN-klient kan vere oppe medan trafikken framleis går ut via det fysiske grensesnittet. Spør den fjerne sida kva ho ser, og spør deretter kjernen kva grensesnitt han valde:

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

To adresser på ulike nettverk tyder at forklaringa allereie er i handa, og resten av desse kontrollane vil berre stadfeste ho. Når dei stemmer, fang sonden med årsaksflagget på, slik at tilstanden kjem tilbake knytt til ei forklaring i staden for å stå åleine som eit bart ord. Skanningstypen høyrer også med i den posten, fordi han skildrar kva som vart spurt om, ikkje kva som kom tilbake. Ein tilstand utan kjelde, utan metode og utan tidsstempel kan ikkje samanliknast med noko:

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

Oppbevar den utskrifta ved sida av posten i staden for i ein rullebuffer som neste person ikkje kan sjå. To ærlege skanningar som er usamde, er berre ein diskusjon når ingen har skrive ned vilkåra. Med vilkåra fastsette, anten stemmer resultata og spørsmålet er lukka, eller dei er ulike og skilnaden er eit faktum om ruta.

Finn ut kva vert som fullførte handtrykket

Eit fullført handtrykk beviser at ein eller annan vert fullførte det, og den verten treng ikkje vere prosessen du har i tankane. Ein lastbalansar, ein omvend proxy eller ein SYN-proxy kan svare før den verkelege serveren er involvert, noko som er vanleg design og ikkje eit symptom. Eit gyldig sertifikat for det forventa namnet snevrar heller ikkje inn dette, fordi eit sertifikat skildrar eit tenesteforhold og seier ingenting om kva maskin som avslutta sambandet.

Nmaps referanse for porttilstandar behandlar dette som grunnleggjande: ein tilstand registrerer kva ein sonde kunne observere frå der han vart send, ikkje ein eigenskap ved porten. Les eit tilstandsord slik, og to køyringar som var usamde byrjar å sjå konsistente ut i staden for motstridande, medan spørsmålet flyttar seg frå om porten er open til kven som stod framfor han.

Svar på det andre spørsmålet i backend i staden for utanfrå. Eit frontend som tek imot samband og deretter ikkje når upstreamen sin, produserer nøyaktig det utanfrå sett sunne biletet av ei teneste med ein treg applikasjon. Berre den eigne posten til upstreamen skil dei to tilfella:

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

Logglinja viser klientadressa applikasjonen faktisk såg, og den andre kommandoen viser om prosessen som held port 443 er applikasjonen din eller noko framfor han. Viss dei to er usamde om kva adresse som kopla til, ser du på to bein av éin førespurnad, og billetten bør seie det.

Sjekk dine eigne reglar før du klandrar tunnelen

Medviten politikk er den vanlegaste grunnen til at ein port svarer på eitt nettverk og ikkje på eit anna, og det er den minst interessante forklaringa som finst. Tilgangsreglar finst for å tillate éi kjelde og forkaste resten, så ei endring av utgang er nettopp hendinga dei vart skrivne for. Derfor viser ein annan tilstand gjennom ein VPN ikkje at leverandøren inspiserer trafikken. Han viser at kjeldearadressa di no er annleis, noko som er ein mykje mindre påstand.

Desse reglane kan lesast på serveren, så les dei i staden for å spekulere om midten av nettverket. List opp filterreglane som nemner eitt av dei to adresseområda, og sjekk deretter om sambandet i det heile 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

Eit tomt andre resultat er informativt, fordi ingenting nådde daemonen, og spørsmålet høyrer til eit filter, ei sikkerheitsgruppe eller sjølve ruta. Eit treff tyder at tenesta såg kjelda di og valde svaret sitt, og den avgjerda er vanlegvis skriven i ein regel du kan lese. Ingen av resultata støttar ei historie om leverandøren, og begge er billegare å sjekke enn ei pakkefangst.

Les transport, sertifikat og svar kvar for seg

Tre lag gir tre observasjonar, og ein sonde som testar eitt av dei kan ikkje rapportere om dei to andre. Hald dei som separate linjer i posten i staden for å brette dei saman til éin dom, fordi kvar linje feilar på sin eigen måte, og feilmodusen fortel deg kvar du skal sjå neste gong.

Éin kommando produserer dei tre første radene mot ei teneste du kontrollerer. Legg utdataa i posten ved sida av skanningen i staden for i ei chatmelding:

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

Les utdataa i rekkjefølgje: handtrykket svarar på transportspørsmålet, emnet til sertifikatet svarar på namnespørsmålet, og kroppen til svaret svarar på applikasjonsspørsmålet. Når handtrykkslinja lukkast og svarlinja ikkje, har du eit frontend med broten upstream i staden for ein blokkert port. Det er ein annan billett enn den du opna, og det er verdt å seie det tydeleg.

Avslutt med å skrive fire fakta i billetten: kjeldearadresse, skanningstype, verten som svarte, og tida. Alt ei seinare samanlikning treng, lever i dei fire, og den som tek saka neste gong vil ikkje ha terminalhistorikken din. Viss du ikkje kan fylle ut alle fire, er køyringa ikkje ferdig.