Gateway o client inoltrato? Leggere l'indirizzo di origine

Il server web registra un indirizzo, e tutti presumono che appartenga al processo del gateway stesso. Può appartenere a un client inoltrato il cui indirizzo privato è sparito nel passaggio di traduzione. La destinazione vede l'origine di rete visibile e nulla di più. È un'affermazione di confine, non la pretesa che l'origine non possa mai essere stabilita.

Che cosa vede davvero la destinazione

Prendete un client a 10.20.0.7, un gateway con indirizzo esterno 198.51.100.10 e una destinazione su internet. Se il gateway traduce l'origine del client, il socket della destinazione registra 198.51.100.10. L'indirizzo privato sparisce dal pacchetto, e la destinazione non può rileggerlo da quell'intestazione. Quei numeri sono illustrativi, non una cattura dalla vostra rete.

L'osservazione resta utile: identifica l'origine di rete che la destinazione deve consentire o bloccare. Semplicemente non identifica la persona o il processo dietro di essa. Per l'operatore della destinazione, questa distinzione decide se un blocco è una decisione di rete o una decisione di account.

Lo stato di traduzione non è visibile alla destinazione

Il gateway conserva la corrispondenza tra la connessione tradotta e il client originale, ed è esattamente quello stato che manca alla destinazione. descrizione tradizionale del NAT separa il record di traduzione dalle intestazioni visibili dopo. Leggere un lato non dà l'altro.

Disegni diversi producono prove diverse. Il traffico instradato con indirizzi di origine preservati mostra l'indirizzo reale del client, mentre un proxy applicativo termina la connessione e ne crea una nuova. Una rotta con origine preservata richiede anche che l'indirizzo del client sia instradabile di ritorno dalla destinazione, cosa che non ogni distribuzione offre. Chiedete quale progetto è distribuito prima di interpretare una riga di log.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL e impronte sono indizi, non prove

Il TTL in IPv4 dipende dal valore iniziale scelto dal mittente e dal numero di salti attraversati dal pacchetto. Senza entrambi i fatti, un valore non può dimostrare che sia avvenuto un salto VPN. Un salto instradato aggiuntivo noto non riesce neppure a distinguere un router LAN, un percorso tunnel o un'altra disposizione di inoltro. Trattate una differenza di TTL come una domanda, non come una conclusione.

Altri segnali si comportano allo stesso modo. Un'intestazione User-Agent può essere impostata dall'applicazione, e la somiglianza dei tempi può riflettere un'infrastruttura condivisa invece di una persona condivisa. Più utenti possono condividere un'uscita, e un utente può cambiare percorso tra sessioni. Raccolti insieme, diversi segnali deboli possono giustificare uno sguardo più attento ai registri di un gateway, ma non diventano prove solide per accumulo.

Autorizzate per identità, non per indirizzo

Se la destinazione deve separare l'amministrazione del gateway dall'attività degli utenti remoti, date a quei ruoli identità autenticate separate e operazioni consentite. Un'origine pubblica condivisa può ancora servire come restrizione di rete, ma non sostituisce l'autenticazione dell'utente o del dispositivo.

Tenete le prove etichettate: origine osservata, account autenticato, tempistica e l'inferenza in esame. Non traducete «nessuna origine interna visibile qui» con «nessuna attribuzione possibile ovunque». L'etichetta conta quando qualcuno che non ha partecipato all'indagine legge il registro mesi dopo.

Registrate la data dell'osservazione e il sistema che l'ha prodotta. Un estratto di log senza attribuzione è difficile da difendere in seguito.