Perché i risultati della scansione delle porte cambiano dietro un’uscita VPN?

Eseguite lo stesso controllo di porta da una linea d’ufficio e da un’uscita VPN, e le due risposte possono non essere d’accordo su un indirizzo che nessuno ha cambiato. Quello scarto viene dal percorso e da quale host ha risposto, non dal fatto che il servizio sia attivo o spento. Tre domande separano queste spiegazioni: che cosa ha chiesto davvero la sonda, quale host ha risposto e che cosa ha registrato il vostro server. Percorretele in quest’ordine e scrivete ogni risposta prima di passare alla successiva.

Riparate la sonda prima di confrontare due esecuzioni

Una parola di stato è confrontabile con un’altra parola di stato solo quando entrambe provengono dallo stesso esperimento. Cinque campi lo fissano: l’indirizzo sorgente visto dal lato remoto, la destinazione risolta, la porta, il tipo di scansione e l’ora. Cambiatene uno qualsiasi e avete fatto un secondo esperimento invece di misurare il primo due volte.

Controllate la sorgente prima di ogni altra cosa, perché un client VPN può essere attivo mentre il traffico esce ancora dall’interfaccia fisica. Chiedete al lato remoto che cosa vede, poi chiedete al kernel quale interfaccia ha scelto:

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

Due indirizzi su reti diverse significano che la spiegazione è già in mano, e il resto di questi controlli non farà che confermarla. Quando concordano, catturate la sonda con il flag della causa attivo, così che lo stato torni legato a una spiegazione invece di restare da solo come parola nuda. Il tipo di scansione appartiene anch’esso a quel record, perché descrive ciò che è stato chiesto e non ciò che è tornato. Uno stato senza sorgente, senza metodo e senza marca temporale non è confrontabile con nulla:

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

Tenete quell’output accanto al record e non in un buffer di scorrimento che la persona successiva non può vedere. Due scansioni oneste che discordano sono una discussione solo quando nessuno ha scritto le condizioni. Con le condizioni fissate, o i risultati coincidono e la questione è chiusa, oppure differiscono e la differenza è un fatto sul percorso.

Scoprite quale host ha completato la stretta di mano

Una stretta di mano completata dimostra che un host l’ha completata, e quell’host non deve necessariamente essere il processo che avete in mente. Un bilanciatore di carico, un proxy inverso o un proxy SYN possono rispondere prima che il server reale sia coinvolto, il che è progettazione ordinaria e non un sintomo. Un certificato valido per il nome atteso non restringe ulteriormente la cosa, perché un certificato descrive un rapporto di servizio e non dice nulla su quale macchina ha terminato la connessione.

Il riferimento di Nmap sugli stati delle porte lo considera basilare: uno stato registra ciò che una sonda ha potuto osservare dal punto in cui è stata inviata, non una proprietà della porta. Leggete una parola di stato in questo modo e due esecuzioni che discordavano cominciano a sembrare coerenti invece che contraddittorie, mentre la domanda si sposta da «la porta è aperta» a «chi stava davanti».

Rispondete alla seconda domanda nel backend e non dall’esterno. Un frontend che accetta connessioni e poi non raggiunge il proprio upstream produce esattamente l’immagine esterna di un servizio sano con un’applicazione lenta. Solo il record proprio dell’upstream separa i due casi:

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

La riga di log mostra l’indirizzo client che l’applicazione ha davvero visto, e il secondo comando mostra se il processo che tiene la porta 443 è la vostra applicazione o qualcosa davanti a essa. Se i due discordano su quale indirizzo si è connesso, state guardando due gambe di una stessa richiesta e il ticket dovrebbe dirlo.

Controllate le vostre regole prima di dare la colpa al tunnel

Una politica deliberata è la ragione più comune per cui una porta risponde su una rete e non su un’altra, ed è la spiegazione meno interessante disponibile. Le regole di accesso esistono per permettere una sorgente e scartare il resto, quindi un cambio di uscita è esattamente l’evento per cui sono state scritte. Perciò uno stato diverso attraverso una VPN non dimostra che il fornitore ispezioni il traffico. Dimostra che il vostro indirizzo sorgente ora è diverso, il che è un’affermazione molto più piccola.

Quelle regole sono leggibili sul server, quindi leggetele invece di speculare sul mezzo della rete. Elencate le regole di filtro che menzionano uno dei due intervalli di indirizzi, poi controllate se la connessione ha raggiunto il demone:

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

Un secondo risultato vuoto è informativo, perché nulla ha raggiunto il demone e la domanda appartiene a un filtro, a un gruppo di sicurezza o al percorso stesso. Un riscontro significa che il servizio ha visto la vostra sorgente e ha scelto la sua risposta, e quella decisione di solito è scritta in una regola che potete leggere. Nessuno dei due esiti sostiene una storia sul fornitore, ed entrambi costano meno da verificare di una cattura di pacchetti.

Leggete trasporto, certificato e risposta separatamente

Tre livelli producono tre osservazioni, e una sonda che ne testa una non può riferire sulle altre due. Tenetele come righe separate nel record invece di piegarle in un unico verdetto, perché ogni riga fallisce a modo suo e il modo di fallire vi dice dove guardare dopo.

Un solo comando produce le prime tre righe contro un servizio che controllate. Mettete il suo output nel record accanto alla scansione e non in un messaggio di chat:

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

Leggete l’output in ordine: la stretta di mano risponde alla domanda del trasporto, il soggetto del certificato a quella del nome e il corpo della risposta a quella dell’applicazione. Quando la riga della stretta di mano riesce e quella della risposta no, avete un frontend con un upstream rotto e non una porta bloccata. È un ticket diverso da quello che avete aperto, e vale la pena dirlo chiaramente.

Concludete scrivendo quattro fatti nel ticket: indirizzo sorgente, tipo di scansione, l’host che ha risposto e l’ora. Tutto ciò che un confronto successivo richiede vive in quei quattro, e chi riprenderà il caso dopo non avrà la cronologia del vostro terminale. Se non riuscite a compilare tutti e quattro, l’esecuzione non è finita.