OpenScape > OpenScape - Office (OSO MX/LX/HX)

Client SIP su OSO MX quali porte aprire/nattare

<< < (3/5) > >>

Kimera:
Tornando al discorso relativo a come ovviare ai problemi EDIT di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).

Hunter:

--- Quote from: Kimera on March 15, 2013, 08:55:55 am ---Tornando al discorso relativo a come ovviare ai problemi EDIT di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).

--- End quote ---

Lo scenario dove sto facendo le prove è un IP Pubblico pulito (stessa espressione che usiamo con gli elettricisti quando chiediamo i contatti per i citofono) assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati. Però ormai la curiosità mi sta lacerando, giusto per la cronaca, non faccio prove mettendo la centrale su un IP Pubblico, perchè so già che funziona.

Vi terrò aggiornati.

Kimera:

--- Quote from: Hunter on March 15, 2013, 09:11:03 am ---Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.
--- End quote ---

(un IP Pubblico è) Assegnato alla WAN di chi?

...è assegnato alla WAN del Firewall (si usano 3 IP...due assegnati sulle interfacce WAN e LAN del Router ed uno sulla WAN del Firewall...) ed il Firewall, che è posto dietro il Router (quindi con un solo livello di NAT realizzato appunto dal Firewall...visto che il Router non fa NAT in questo caso), esegue poi il suo NAT (quindi NAT singolo)...oppure tale IP Pubblico è assegnato alla WAN del Router che esegue un primo NAT lasciando al Firewall il compito di eseguire il secondo (quindi double-NAT)?

Di solito quando si ha un solo IP Pubblico statico non si può evitare il doppio NAT (anche se si fa Any Port/Any Protocol Forwarding verso la WAN del Firewall)...nel senso che tale IP Pubblico è assegnato dal gestore ITSP alla WAN del Router a prescindere da cosa c'è alle spalle tale Router (potrebbe anche non esserci un Firewall)...e tale Router deve quindi realizzare forzosamente il primo NAT verso la sua LAN (ossia verso la Subnet interna o verso comunque la Subnet interna che si instaura tra la sua LAN e la WAN dell'eventuale Firewall posto alle sue spalle, sempre che questo ci sia)...e quindi l'eventuale Firewall alla fine si ritrova a fare il secondo NAT verso la LAN privata...mi pare che solo avendo un Pool di IP Pubblici si possa ricadere nel primo caso (NAT fatto solo dal Firewall).

Qualcuno potrebbe aggiungere (od obbiettare) che anche il più blasfemo dei Router ha funzionalità Firewall (benchè difficilmente funga da terminatore VPN come fa un Firewall di rango)...ma, detto in sintesi, un conto è un Firewall con "ALG Support" (ed anche qui...si spalancano le porte dell'infinito) ed un altro è un normale Router che offre il servizio di Virtual Server ([Port/Service]-Forwarding verso gli Host della IP Subnet privata)...se, all'apparenza, entrambi possono sortire effetti simili (raggiungibilità di alcuni specifici servizi interni dall'esterno, vedi RDP, VNC, SSH, HTTP/HTTPS e chi ne ha più ne metta...) dall'altro, per il VoIP ad esempio, non sono affatto la stessa cosa (quando nel Payload dei messaggi di un SIP Client è contenuto il proprio IP Privato e tale SIP Client deve connettersi con un altro SIP Client all'esterno) al punto di arrivare, se non ci si fa caso, agli annosi problemi del Simmetric NAT/Full-Cone NAT ecc.

La VPN (Client to Gateway e Gateway to Gateway) può sicuramente essere una soluzione...

Nota: insisto con lo scrivere che c'è, da qualche parte, un (xDSL)-Router interposto tra Internet ed il Firewall ma, questi due apparati, potrebbero essere anche "accorpati" in un unico device (un xDSL Modem/Router/Firewall...esempio: il Netgear DGVF338 che in più aveva anche il WiFi)...ma questa è solo una mia presunzione per tentare di dare un nome alle cose.

Correggetemi se sbaglio (Sopra ho corretto "...di NAT Traversal (ALG)..." con "...di tramite il NAT Traversal (ALG)..." altrimenti sembra che il NAT Traversal sia il problema e non una tecnica per risolvere un problema!).

Kimera:
Per gli scettici (a parte TUTTO quello che si trova in Internet relativamente al NAT e alle conseguenze, positive e negative, del suo uso) invito la lettura di questa pagina (fonte Gigaset Communications GmbH, AKA Gigaset PRO, per i suoi terminali DECT/IP). Non tanto perchè essa fa riferimento a questioni specifiche dei Gigaset VoIP ma soprattutto per la parte di "Background Informations" annessa.

Saluti, Kimera.

Hunter:

--- Quote from: Kimera on March 15, 2013, 09:28:04 am ---
--- Quote from: Hunter on March 15, 2013, 09:11:03 am ---Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.
--- End quote ---

(un IP Pubblico è) Assegnato alla WAN di chi?

--- End quote ---

Alla WAN del Firewall.  ;D Avendo una subnet pubblica /28 non aveva senso fare un doppio NAT, a che pro!?  :o
Il router diventa quindi trasparente poichè diventa il Gateway del Firewall, non ci sono NAT di mezzo.

Poi sarò io dal mio firewall che farò i vari PAT/NAT come preferite chiamarli. In ogni caso rimango abbastanza curioso sull'arcano. Perchè i casi sono veramente nell'ambito del rasoio di Occam, quindi o il firewall non fa il NAT corretto, oppure la porta 5060 non è quella che l'OSO MX utilizza per la registrazione dei client SIP, la seconda delle due mi lascia più perplesso perchè forzando internamente la registrazione sulla porta 5060 la registrazione avviene normalmente....uhm...  :-X

Navigation

[0] Message Index

[#] Next page

[*] Previous page