Varför ändras resultaten från portskanningen bakom en VPN-utgång?

Kör samma portkontroll från en kontorslinje och från en VPN-utgång, och de två svaren kan vara oense om en adress som ingen har ändrat. Den luckan kommer från vägen och från vilken värd som svarade, inte från om tjänsten är uppe eller nere. Tre frågor skiljer de förklaringarna: vad sonden faktiskt frågade om, vilken värd som svarade och vad din egen server registrerade. Arbeta igenom dem i den ordningen och skriv ner varje svar innan du går vidare till nästa.

Reparera sonden innan du jämför två körningar

Ett tillståndsord kan bara jämföras med ett annat tillståndsord när båda kom från samma experiment. Fem fält låser fast det: källadressen som fjärrsidan såg, den upplösta destinationen, porten, skanningstypen och tiden. Ändra något av dem och du har kört ett andra experiment i stället för att mäta det första två gånger.

Kontrollera källan före allt annat, eftersom en VPN-klient kan vara uppe medan trafiken fortfarande går ut via det fysiska gränssnittet. Fråga fjärrsidan vad den ser och fråga sedan kärnan vilket gränssnitt den valde:

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

Två adresser på olika nätverk betyder att förklaringen redan är i handen, och resten av dessa kontroller kommer bara att bekräfta den. När de stämmer, fånga sonden med orsaksflaggan på, så att tillståndet kommer tillbaka knutet till en förklaring i stället för att stå ensamt som ett bart ord. Skanningstypen hör också till den posten, eftersom den beskriver vad som frågades, inte vad som kom tillbaka. Ett tillstånd utan källa, utan metod och utan tidsstämpel kan inte jämföras med något:

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

Förvara den utskriften bredvid posten och inte i en rullningsbuffert som nästa person inte kan se. Två ärliga skanningar som är oense är bara en diskussion när ingen har skrivit ner villkoren. Med villkoren fastställda antingen stämmer resultaten och frågan är stängd, eller så skiljer de sig och skillnaden är ett faktum om vägen.

Ta reda på vilken värd som slutförde handskakningen

En slutförd handskakning bevisar att någon värd slutförde den, och den värden behöver inte vara processen du har i tankarna. En lastbalanserare, en omvänd proxy eller en SYN-proxy kan svara innan den riktiga servern är inblandad, vilket är vanlig design och inte ett symptom. Ett giltigt certifikat för det förväntade namnet begränsar inte detta heller, eftersom ett certifikat beskriver en tjänsterelation och inte säger något om vilken maskin som avslutade anslutningen.

Nmaps referens för porttillstånd behandlar detta som grundläggande: ett tillstånd registrerar vad en sond kunde observera från där den skickades, inte en egenskap hos porten. Läs ett tillståndsord så och två körningar som var oense börjar se konsekventa ut i stället för motstridiga, medan frågan flyttar sig från om porten är öppen till vem som stod framför den.

Svara på den andra frågan i backend i stället för utifrån. Ett frontend som tar emot anslutningar och sedan inte når sin upstream producerar exakt den utifrån sett sunda bilden av en tjänst med en långsam applikation. Bara upstreamens egen post skiljer de två fallen:

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

Loggraden visar klientadressen som applikationen faktiskt såg, och det andra kommandot visar om processen som håller port 443 är din applikation eller något framför den. Om de två är oense om vilken adress som anslöt, tittar du på två ben av en och samma begäran och biljetten borde säga det.

Kontrollera dina egna regler innan du skyller på tunneln

Avsiktlig policy är den vanligaste orsaken till att en port svarar på ett nätverk och inte på ett annat, och det är den minst intressanta förklaringen som finns. Åtkomstregler finns för att tillåta en källa och släppa resten, så en ändring av utgången är precis den händelse de skrevs för. Därför visar ett annat tillstånd genom en VPN inte att leverantören inspekterar trafiken. Det visar att din källadress nu är annorlunda, vilket är ett mycket mindre påstående.

De reglerna går att läsa på servern, så läs dem i stället för att spekulera om mitten av nätverket. Lista filterreglerna som nämner något av de två adressområdena och kontrollera sedan om anslutningen överhuvudtaget 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

Ett tomt andra resultat är informativt, eftersom ingenting nådde daemonen och frågan hör till ett filter, en säkerhetsgrupp eller själva vägen. En träff betyder att tjänsten såg din källa och valde sitt svar, och det beslutet står vanligtvis i en regel du kan läsa. Ingen av resultaten stöder en historia om leverantören, och båda är billigare att kontrollera än en paketfångst.

Läs transport, certifikat och svar var för sig

Tre lager ger tre observationer, och en sond som testar ett av dem kan inte rapportera om de två andra. Håll dem som separata rader i posten i stället för att vika dem till en enda dom, eftersom varje rad misslyckas på sitt eget sätt och felmoden säger dig var du ska titta nästa gång.

Ett kommando producerar de tre första raderna mot en tjänst du kontrollerar. Lägg dess utdata i posten bredvid skanningen och inte i ett chattmeddelande:

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

Läs utdata i ordning: handskakningen svarar på transportfrågan, certifikatets ämne svarar på namfrågan och svarets kropp svarar på applikationsfrågan. När handskakningsraden lyckas och svarsraden inte, har du ett frontend med trasig upstream i stället för en blockerad port. Det är en annan biljett än den du öppnade, och det är värt att säga det tydligt.

Avsluta med att skriva fyra fakta i biljetten: källadress, skanningstyp, värden som svarade och tiden. Allt en senare jämförelse behöver lever i de fyra, och den som tar ärendet nästa gång har inte din terminalhistorik. Om du inte kan fylla i alla fyra är körningen inte klar.