Punzonatura di fori simmetrici NAT e UDP

Ho letto questa domanda , ma la spiegazione del NAT simmetrico non era abbastanza dettagliata.

Per favore qualcuno potrebbe aiutarmi a capire i seguenti paragrafi?

Ho letto questo su NAT simmetrico :

Ogni richiesta dallo stesso indirizzo IP e porta interni a un indirizzo IP e porta di destinazione specifici è mappata a un indirizzo IP e porta di origine esterna univoci, se lo stesso host interno invia un pacchetto anche con lo stesso indirizzo e porta di origine ma a un diverso destinazione, viene utilizzata una mappatura diversa. Solo un host esterno che riceve un pacchetto da un host interno può inviare un pacchetto indietro.

http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT

E questo sulla perforazione UDP :

La perforazione UDP non funzionerà con i dispositivi NAT simmetrici (noti anche come NAT bidirezionali) che tendono ad essere trovati nelle grandi reti aziendali. Nel NAT simmetrico, la mappatura del NAT associata alla connessione al noto server STUN è limitata alla ricezione di dati dal server ben noto, e quindi la mappatura NAT che il noto server vede non è un'informazione utile all'endpoint.

http://en.wikipedia.org/wiki/UDP_hole_punching

Ma non lo sto davvero assorbendo. Ho la sensazione che mi stia dicendo che (in un'applicazione client-server in cui il client inizia la comunicazione) un server non può comunicare in altro modo a meno che non sia stato esplicitamente consentito dal dispositivo NAT. Non capisco perché sia ​​quello che sta dicendo. Se è possibile, potresti semplificare leggermente questa descrizione per me?

Abbiamo un problema nel nostro ambiente in cui un noto strumento di supporto remoto non può essere utilizzato da un fornitore di software altrettanto noto per fornirci supporto. Il client è a conoscenza del proxy, ma per alcuni reson pensa che potrebbe essere una buona idea non usarlo e fare qualcosa di completamente diverso tramite UDP sulla porta 1153.

Dalla nostra chat ... quindi altri potrebbero non avere la conversazione completa, ma le basi sono qui.

Quindi NAT di base = source address:port >> external address:port >> NAT>> new source address:port >> external address port

con NAT simmetrico è una mappatura statica e la stessa ogni volta e sia per la sorgente che per la destinazione.

Esempio: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"in un'applicazione client-server in cui il client avvia la comunicazione) un server non può comunicare in altro modo a meno che non sia stato esplicitamente consentito dal dispositivo NAT."

quella parte che dici non è corretta dovrebbe essere la seguente:

in un'applicazione client-server in cui il client avvia la comunicazione) un server PU communicate comunicare di nuovo nell'altro modo DOPO che l'origine stabilisce la sessione SOPRA le porte utilizzate nella sessione.

Ciò significa che se 2.2.2.2:43424 passa a 5.5.5.5:80, quindi 5.5.5.5:80 invia informazioni a 2.2.2.2:43424 una volta stabilita la sessione. Nella tua frase ... la sessione sarebbe sempre e solo fonte di comunicare con destinazione con destinazione mai rispondendo con pacchetti / informazioni / grafica / qualunque cosa.

"Abbiamo un problema nel nostro ambiente in cui un noto strumento di supporto remoto non può essere utilizzato da un fornitore di software altrettanto noto per fornirci supporto. Il client è a conoscenza del proxy, ma per alcuni reson pensa che potrebbe essere un buona idea non usarlo e fare qualcosa di completamente diverso tramite UDP sulla porta 1153. "

Ciò potrebbe essere dovuto al fatto che bloccano semplicemente Logmein / Teamviewer / qualunque cosa a livello di porta poiché chiedono di utilizzare una porta diversa ... quindi pensano che se consentirai o comunicherai su 1153 aggirerà le loro restrizioni IT ... meglio Mi viene in mente senza sapere in dettaglio quale app o dettagli completi. Niente a che vedere con la perforazione di fori NAT o UDP simmetrici in realtà ... almeno per quanto riguarda il problema che stanno sollevando.

Consiglierei di parlare con il loro team di supporto su quale strumento di supporto remoto lavorano con loro o lavorare con loro per determinare un modo di usare lo strumento che ti piace. Se ciò significa determinate NAT / regole di porta, dovrai lavorare con loro e con il tuo team di Networking per capire quale parte.

Spero che tutto aiuti.

Guarda queste immagini tratte dalla pagina "Traduzione dell'indirizzo di rete" di Wikipedia.

In "Full Cone NAT"

1. Una volta che un indirizzo interno (iAddr: iPort) è associato a un indirizzo esterno (eAddr: ePort), tutti i pacchetti di iAddr: iPort vengono inviati tramite eAddr: ePort.
2. Qualsiasi host esterno può inviare pacchetti a iAddr: iPort inviando pacchetti a eAddr: ePort.

In NAT simmetrico

1. Ogni richiesta dallo stesso indirizzo IP e porta interni a un indirizzo IP e porta di destinazione specifici è mappata a un indirizzo IP e porta univoci di origine esterna; se lo stesso host interno invia un pacchetto anche con lo stesso indirizzo e porta di origine ma a una destinazione diversa, viene utilizzata una mappatura diversa.
2. Solo un host esterno che riceve un pacchetto da un host interno può inviare un pacchetto indietro.

Ora parliamo del perché la perforazione UDP non può funzionare in NAT simmetrico. Diciamo che Server1 è STUN Server e Server 2 è un dispositivo NAT di diversa rete privata. Nella perforazione UDP, il client si connette con Server1 e il mapping delle porte viene creato sul dispositivo NAT. Ma quando questo client si connette all'host dietro Server2, il dispositivo NAT crea un altro mapping delle porte come mostrato nella figura 2. Server1 condivide il mapping delle porte client con l'host dietro Server2 e con questo mapping delle porte Server2 non può stabilire una connessione e Server2 non è a conoscenza del secondo mappatura delle porte creata dal dispositivo NAT.