Hvorfor ændrer portscanningens resultater sig bag en VPN-udgang?

Kør den samme portkontrol fra en kontorlinje og fra en VPN-udgang, og de to svar kan være uenige om en adresse, som ingen har ændret. Det gab kommer fra ruten og fra, hvilken vært der svarede, ikke fra om tjenesten er oppe eller nede. Tre spørgsmål skiller de forklaringer: hvad sonden faktisk spurgte om, hvilken vært der svarede, og hvad din egen server registrerede. Arbejd dig igennem dem i den rækkefølge, og skriv hvert svar ned, før du går videre til det næste.

Ret sonden, før du sammenligner to kørsler

Et tilstandsord kan kun sammenlignes med et andet tilstandsord, når begge kom ud af det samme forsøg. Fem felter fastlåser det: kildeadressen, som den fjerne side så, den opløste destination, porten, scanningstypen og tiden. Ændr et af dem, og du har kørt et andet forsøg i stedet for at måle det første to gange.

Kontrollér kilden før alt andet, fordi en VPN-klient kan være oppe, mens trafikken stadig forlader via det fysiske interface. Spørg den fjerne side, hvad den ser, og spørg derefter kernen, hvilket interface den valgte:

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

To adresser på forskellige netværk betyder, at forklaringen allerede er ved hånden, og resten af disse kontroller vil kun bekræfte den. Når de er enige, skal du fange sonden med årsagsflaget slået til, så tilstanden kommer tilbage knyttet til en forklaring i stedet for at stå alene som et bart ord. Scanningstypen hører også med i den post, fordi den beskriver, hvad der blev spurgt om, ikke hvad der kom tilbage. En tilstand uden kilde, uden metode og uden tidsstempel kan ikke sammenlignes med noget:

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

Opbevar den output ved siden af posten i stedet for i en rullebuffer, som den næste person ikke kan se. To ærlige scanninger, der er uenige, er kun en diskussion, når ingen har skrevet betingelserne ned. Med betingelserne fastlagt enten stemmer resultaterne overens, og spørgsmålet er lukket, eller de er forskellige, og forskellen er et faktum om ruten.

Find ud af, hvilken vært der fuldførte håndtrykket

Et fuldført håndtryk beviser, at en eller anden vært fuldførte det, og den vært behøver ikke være den proces, du har i tankerne. En load balancer, en omvendt proxy eller en SYN-proxy kan svare, før den rigtige server er involveret, hvilket er almindeligt design og ikke et symptom. Et gyldigt certifikat til det forventede navn indsnævrer det heller ikke, fordi et certifikat beskriver en tjenesterelation og intet siger om, hvilken maskine der afsluttede forbindelsen.

Nmaps reference om porttilstande betragter dette som grundlæggende: en tilstand registrerer, hvad en sonde kunne observere fra det sted, den blev sendt fra, ikke en egenskab ved porten. Læs et tilstandsord sådan, og to kørsler, der var uenige, begynder at se konsistente ud i stedet for modstridende, mens spørgsmålet flytter sig fra, om porten er åben, til hvem der stod foran den.

Besvar det andet spørgsmål på backend i stedet for udefra. En frontend, der accepterer forbindelser og derefter ikke når sin upstream, producerer præcis det udefra set sunde billede af en tjeneste med en langsom applikation. Kun upstreamens egen post skelner de to tilfælde:

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

Loglinjen viser den klientadresse, som applikationen faktisk så, og den anden kommando viser, om processen, der holder port 443, er din applikation eller noget foran den. Hvis de to er uenige om, hvilken adresse der oprettede forbindelsen, ser du på to ben af én anmodning, og billetten bør sige det.

Kontrollér dine egne regler, før du bebrejder tunnelen

Bevidst politik er den mest almindelige grund til, at en port svarer på ét netværk og ikke på et andet, og det er den mindst interessante forklaring, der findes. Adgangsregler findes for at tillade én kilde og droppe resten, så en ændring af udgang er netop den begivenhed, de blev skrevet til. Derfor viser en anden tilstand gennem en VPN ikke, at udbyderen inspicerer trafik. Den viser, at din kildeadresse nu er anderledes, hvilket er en meget mindre påstand.

De regler kan læses på serveren, så læs dem i stedet for at spekulere om midten af netværket. List de filterregler, der nævner et af de to adresseområder, og kontrollér derefter, om forbindelsen overhovedet nåede 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 andet resultat er informativt, fordi intet nåede daemonen, og spørgsmålet tilhører et filter, en sikkerhedsgruppe eller selve ruten. Et hit betyder, at tjenesten så din kilde og valgte sit svar, og den beslutning er normalt skrevet ned i en regel, du kan læse. Ingen af udfaldene understøtter en historie om udbyderen, og begge er billigere at kontrollere end en pakkefangst.

Læs transport, certifikat og svar hver for sig

Tre lag giver tre observationer, og en sonde, der tester et af dem, kan ikke rapportere om de to andre. Hold dem som separate linjer i posten i stedet for at folde dem sammen til én dom, fordi hver linje fejler på sin egen måde, og fejltypen fortæller dig, hvor du skal kigge næste gang.

Én kommando producerer de første tre rækker mod en tjeneste, du kontrollerer. Læg dens output i posten ved siden af scanningen i stedet for i en chatbesked:

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

Læs output i rækkefølge: håndtrykket besvarer transportsprørgsmålet, certifikatets emne besvarer navnespørgsmålet, og svarets krop besvarer applikationsspørgsmålet. Når håndtrykslinjen lykkes, og svarlinjen ikke gør, har du en frontend med en brudt upstream i stedet for en blokeret port. Det er en anden billet end den, du åbnede, og det er værd at sige tydeligt.

Slut af med at skrive fire fakta i billetten: kildeadresse, scanningstype, den vært, der svarede, og tiden. Alt, hvad en senere sammenligning har brug for, lever i de fire, og den, der tager sagen næste gang, har ikke din terminalhistorik. Hvis du ikke kan udfylde alle fire, er kørslen ikke færdig.