Perché NAT non riserva le porte dal pool di porte TCP e UDP della macchina?

Ho fatto due esperimenti. Questa è la rete per entrambi:

        [private network]     [public network]
    A -------------------- R ----------------- B
192.168.0.5     192.168.0.1|192.0.2.1       192.0.2.8

A 's gateway predefinito è R . R ha inoltro IPv4 attivo e la seguente regola iptables:

iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 50000

L'intento è che qualsiasi cosa TCP da A verrà mascherata come 192.0.2.1 usando la porta 50000 di R.

Ho pubblicato un servizio TCP sulla porta 60000 su B utilizzando nc -4l 192.0.2.8 60000.

Quindi ho aperto una connessione da A :nc -4 192.0.2.8 60000

A ha iniziato a inviare pacchetti che assomigliavano a questo:

192.168.0.5:53269 -> 192.0.2.8:60000

R l'ha tradotto in

192.0.2.1:50000 -> 192.0.2.8:60000

Fin qui tutto bene.

Allora ho provato ad aprire il seguente client su R : nc -4 192.0.2.8 60000 -p 50000. Ho inviato messaggi, non succede nulla. Nessun pacchetto può essere visto su R 'tcpdump.

Poiché esiste la regola del travestimento, o almeno perché è attiva, mi sarei aspettato che R 'nc fallisse con il messaggio di errore "nc: indirizzo già in uso", che è ciò che succede se associo due nc alla stessa porta.

Ho quindi atteso un po 'in modo che la mappatura di Conntrack morisse.

Il secondo esperimento consisteva nel cercare di aprire prima il client di R. R inizia a parlare con B bene. Se poi apro la connessione da A , i suoi pacchetti vengono ignorati. A SYN s' arrivano a R , ma non si risponde, nemmeno da errori ICMP. Non so se questo perché R sa che ha finito le porte mascherate o perché Linux è semplicemente confuso (maschera tecnicamente la porta ma la connessione già stabilita interferisce in qualche modo).

Sento che il comportamento del NAT è sbagliato. Potrei configurare accidentalmente una porta sia per il mascheramento (in particolare, non specificando --to-portsdurante la regola iptables) che per un servizio, e il kernel lascerà cadere silenziosamente le connessioni. Inoltre non vedo nulla di tutto ciò documentato da nessuna parte.

Per esempio:

• A fa una richiesta normale B . Maschere R che utilizzano la porta 50k.
• Un effettua una query DNS a R . Essendo che T è ricorsivo, R (usando, per pura coincidenza, la porta effimera 50k) interroga l'autorevole nameserver Z sulla porta 53.

Una collisione è appena avvenuta; R ora sta usando la porta 50k per due connessioni TCP separate.

Immagino sia perché normalmente non pubblichi servizi sui router. Ma ancora una volta, danneggerebbe il kernel "prendere in prestito" la porta dal pool di porte TCP quando viene attivamente mascherato?

So che posso separare le mie porte effimere dalle mie --to-ports. Tuttavia, questo non sembra essere il comportamento predefinito. Entrambe le porte NAT e effimere sono impostate su 32768-61000, il che è inquietante.

(Ho trovato l'intervallo effimero interrogando / proc / sys / net / ipv4 / ip_local_port_range e l'intervallo NAT semplicemente NATting molte richieste UDP in un esperimento separato - e stampando la porta di origine sul lato server. un modo per stampare l'intervallo usando iptables.)

danneggerebbe il kernel "prendere in prestito" la porta dal pool di porte TCP quando viene attivamente mascherato?

Immagino che la risposta sia "no, ma non importa molto".

Ho erroneamente supposto che R avesse usato solo l'indirizzo di trasporto di destinazione del pacchetto di risposta per dire se era diretto verso A o se stesso. In realtà sembra utilizzare l'intera tupla degli indirizzi di trasporto di destinazione di origine per identificare una connessione. Pertanto, in realtà è normale che NAT crei più connessioni utilizzando la stessa porta (di proprietà R ); non crea confusione. Di conseguenza, i pool di porte TCP / UDP non contano.

È abbastanza ovvio ora che ci penso.

Allora ho provato ad aprire il seguente client su R : nc -4 192.0.2.8 60000 -p 50000. Ho inviato messaggi, non succede nulla. Nessun pacchetto può essere visto su R 'tcpdump.

Questa è la parte degli esperimenti in cui ho sbagliato.

L'errore si verifica perché gli indirizzi di trasporto di origine e di destinazione sono uguali, non solo perché l'indirizzo di origine è lo stesso.

Se lo faccio, diciamo, nc -4 192.0.2.8 60001 -p 50000funziona davvero. Anche se utilizza la stessa porta di una maschera NAT.

Sento che il comportamento del NAT è sbagliato. Potrei configurare accidentalmente una porta sia per il mascheramento (in particolare, non specificando --to-portsdurante la regola iptables) che per un servizio, e il kernel lascerà cadere silenziosamente le connessioni.

Non lo farà, perché le connessioni mascherate e le connessioni avviate R avranno probabilmente destinazioni diverse.

Poiché esiste la regola del travestimento, o almeno perché è attiva, mi sarei aspettato che R 'nc fallisse con il messaggio di errore "nc: indirizzo già in uso", che è ciò che succede se associo due nc alla stessa porta.

Sto ancora cercando una risposta a prova di proiettile a questo, ma tutto sembra indicare "è una conseguenza negativa del modo in cui è implementato, ed è così piccolo che siamo disposti a conviverci".