Porta sorgente del client contro listener del server in un flusso VPN
Confronta i due numeri di porta in un tunnel: il listener fisso del server e l'origine effimera del client, e come la traduzione del router stia tra loro.
Nella stessa conversazione compaiono due numeri e nessuno dei due è sbagliato. Il registro del server mostra il listener che offre il servizio, il portatile mostra il socket che ha inviato il datagramma, e un router intermedio può riscrivere il secondo in uscita. Confrontare le estremità della conversazione è più utile che confrontare le cifre. Il confronto qui sotto tiene separati il listener, il socket del client e l'origine tradotta, perché rispondono a domande diverse.
Due numeri che descrivono estremità opposte
La porta configurata del server è la destinazione verso cui il client chiama. È fissata dalla politica, compare nel profilo e deve essere aperta lato server. La porta sorgente del client viene scelta localmente, di solito dall'intervallo effimero, ed esiste perché la risposta abbia dove atterrare. Può cambiare a ogni riconnessione, e nulla del progetto dipende dalla sua stabilità.
Un router intermedio può riscrivere quell'origine nella propria associazione 'NAT'. Per questo il numero osservato sul server spesso non ha alcun rapporto con quello scelto dal portatile.
Dove cambia il numero di origine in uscita
Prendete un esempio IPv4 inventato: un client dietro un router che traduce, un server con un solo listener 'UDP' e un unico datagramma che attraversa entrambi. La tabella nomina ogni estremità e ciò che le accade, invece di riprodurre il pacchetto in tre punti di osservazione.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
La destinazione è costante in ogni riga, e cambia solo l'identità dell'origine. Requisiti di UDP NAT distinguono un indirizzo e una porta interni dall'associazione esterna, che è esattamente lo scarto tra la seconda e la terza riga. Un router può conservare la porta sorgente del client o sceglierne un'altra; la conservazione non è qualcosa che un'applicazione debba dare per scontata.
Leggete le tre estremità dagli host stessi
Gli elenchi qui sotto provengono da tre macchine diverse e, insieme, mostrano tutta la conversazione. Eseguite il primo sul server, il secondo sul client e il terzo dove esiste l'associazione. Una sola riga di registro non mostra mai tutti e tre.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Il primo elenco dimostra che il server è legato alla porta del servizio e mostra quale processo la possiede. Il secondo mostra il socket locale del client e la destinazione verso cui ha chiamato. Il terzo mostra l'associazione creata dal router, ed è l'unico luogo in cui compare l'origine tradotta. Leggeteli in quest'ordine e i due numeri smettono di sembrare contraddittori.
Cosa cambia una riconnessione e cosa no
Alcuni router conservano la porta sorgente del client quando è libera, altri ne assegnano una diversa ogni volta. Entrambi i comportamenti sono normali, e un'applicazione che esige il primo si romperà sul secondo. Un cambio di associazione dopo una riconnessione o un cambio di rete non è un guasto del server: il client apre un nuovo socket, il router assegna ciò che ha, e il server vede una nuova origine sullo stesso listener. Sarebbe un guasto aspettarsi che il server accetti traffico indirizzato a una porta client arbitraria.
I client OpenVPN della comunità ottengono questo comportamento tramite nobind, che lascia al sistema operativo la scelta della porta locale; la porta remota proviene comunque dal profilo. Legarla esplicitamente è una scelta deliberata, non un requisito del protocollo. Il server continua a offrire un'estremità mentre i client scelgono le proprie identità locali.
Etichettate i livelli separatamente nel registro
Dentro il tunnel esiste una seconda conversazione con porte proprie. Una richiesta HTTPS trasportata dal tunnel ha destinazione TCP 443, mentre la connessione cifrata esterna usa UDP 1194, quindi cambiare la porta sorgente esterna non cambia nulla del servizio interno.
Anche al livello esterno il protocollo conta. UDP 1194 e TCP 1194 sono estremità diverse, e un listener 'TCP' non riceverà mai un datagramma UDP solo perché il numero coincide. Quando documentate un dispiegamento, etichettate il listener del server, il socket del client e l'origine tradotta come tre cose distinte, e aggiungete il trasporto a ciascuna.
Poi lasciate che la politica segua i ruoli. Il server apre il trasporto previsto sul proprio listener e autentica comunque il peer; il firewall del client ammette le risposte al proprio scambio in uscita senza pubblicare un servizio in entrata. Un filtro senza stato ha bisogno della direzione di ritorno scritta esplicitamente, ed è la ragione pratica per cui la distinzione conta oltre gli schemi ordinati.