Ciao Andrea.
Ti rigiro le mie scuse per non essermi fatto più sentire, pensavo che nessuno mi avesse ancora risposto!
Dunque, vediamo cosa ho da dirti. Ci tengo prima di tutto a sottolineare che attualmente tutto funziona, posso fare e ricevere chiamate, e (dopo parecchie prove) sto "ufficialmente" utilizzando la telefonia VoIP da inizio gennaio.
Ad ogni modo, ho alcune domande a proposito del router: cosa sono il Port Forwarding ed il Port Triggering?
Correggetemi se sbaglio:
1. Port Forwarding: può far sì che il traffico verso una o più porte (lato WAN) del mio router venga spedito (sulle stesse porte) ad un PC lato LAN.
diciamo di si.....
Come "diciamo di si"? E' giusto o no? Potrei tranquillamente aver capito male io, eh? Contrariamente a quanto possa sembrare, io di queste cose non so nulla...
2. Port Triggering: meglio un esempio... C'è un server in Internet che ascolta sulla porta 1111, porta resa disponibile per un servizio che prevede l'invio delle risposte sulla porta 2222 che è in ascolto sul client. Allora quando il client effettua una richiesta verso la 1111 del server, ed il server invia la risposta verso la 2222, NAT (che di norma scarterebbe questa risposta perchè permette solo il transito delle info verso la strada aperta dalla richiesta, cioè verso la porta 1111) indirizzerà la risposta verso la porta 2222 del client. Che casino...
Questa non la sapevo, non si finisce mai di imparare....^^
Non è detto che sia come dico, infatti cercavo conferme. Dopo aver spulciato un po' la rete, mettendo assieme le varie informazioni ho trovato la soluzione a cui sono giunto, che mi pare anche logica.
Altra cosa: se uso la 5060, quando l'ATA fa una richiesta al SIP Proxy l'ATA mette nell'header VIA del pacchetto SIP uscente l'indirizzo pubblico (l'IP su Internet degli utenti WiPeX, il 89.202.179.222, per capirci) e la porta 5060, che sarebbe l'indirizzo a cui il SIP Proxy deve spedire la risposta. E la risposta che il SIP Server spedisce indietro al mio ATA ha nell'header VIA gli stessi parametri. Quindi tutto ok, ma come vi ho già detto non funziona.
Si ma la risposta arriva mica al tuo PC?? Arriva al router di wipex sulla porta 5060, e poi che se ne fa il router?? nulla dato che dubito che abbia regole di snat per ridirigere la richiesta a te....
E invece no, scusa, deve avere regole per redirigerla a me! Il mio ATA fa una richiesta, e mette nell'header VIA l'indirizzo pubblico a cui è raggiungibile (abbiamo detto il 89.202.179.222:5060).
(Apro una parentesi: il mettere l'indirizzo internamente al pacchetto SIP francamente non mi è chiaro, anzi è proprio per questo che sorgono casini col NAT, secondo me... Se si utilizzava solo l'IP e la porta nel pacchetto IP che incapsula i pacchetti SIP, tutto funzionava senza problemi, cioè il NAT era trasparente, esattamente come lo è per richieste HTTP, ... . Ma come al solito potrei sbagliarmi, io di queste cose non so un piffero.)
Successivamente, il pacchetto IP contenente la richiesta SIP viene trasmessa dall'ATA al mio router (che cambia l'indirizzo IP nel pacchetto IP (e non SIP) con quello assegnatomi da WiPeX. La richiesta giunge poi ai routers di Unipex, che di nuovo sostituiscono all'indirizzo 172.16.... il classsico 89.202.179.222. Il pacchetto in questione viene poi ricevuto dal SIP Proxy, che spedisce la risposta a 89.202.179.222. Il NAT di Unipex DEVE indirizzare per forza questo pacchetto al mio IP 172.16...., dal momento che da lì è uscita la richiesta!
E infine, il mio router DEVE dare all'ATA la risposta, poichè è lui che ha fatto la richiesta.
Ma, come si diceva, non va... Secondo me il problema è tutto della 5060, come dicevi tu viene filtrata (ma da chi e perchè? Che senso ha che proprio la porta destinata al VoIP sia bloccata da Unipex?).
Usando la 4444, il tutto funziona, quindi la mia logica è corretta, almeno pare...
Se invece non uso la 5060, la risposta inviata dal SIP Server cambia l'header VIA, inserendo come porta quella che io ho usato, ma come IP il famoso 172.16.x.y, cioè l'indirizzo della porta WAN del mio router, assegnatomi da WiPeX. Ma come fa il SIP Proxy ad avere questa informazione, dato che il NAT di WiPeX dovrebbe aver rimosso ogni riferimento a questo IP sostituendolo con quello pubblico?
Qua sono le magie che fa STUN credo, sistema che non conosco al 100% ma vediamo di capire....
Può essere...
Se invece non uso la 5060, la risposta inviata dal SIP Server cambia l'header VIA, inserendo come porta quella che io ho usato
la 4444 credo, e fino a qui OK
Beh, la 4444 perchè ho usato quella. Ma potevo usare una qualsiasi altra porta, solo la 5060 non va...
Nello specifico, ho provato (con successo) anche le porte 4050 e 1025!
Altra cosa: lo STUN sostituisce all'IP privato dell'ATA (192.168.x.y) l'IP visto su Internet (correttamente, il famoso 89.202.179.222), ma non effettua alcuna sostituzione della porta. Cioè la porta 4444 privata su cui il mio ATA è in ascolto viene mappata sullo stesso numero di porta pubblica. Ovvero l'indirizzo privato 192.168.x.y:4444 viene mappato da NAT come 89.202.179.222:4444.
E be si, giusto, tu non sai come viene rimappata la porta, lo fa il router di frontiera di wipex, la porta 4444 è quello che serve al server stun per capire chi sei, e sapere la porta con cui esci e usare quella per chiamarti....un po un casino
Non sono tanto d'accordo... Secondo me il router di WiPeX non cambia proprio la porta! Nel senso, STUN serve a far conoscere al mio ATA l'IP e la porta ESTERNI da cui è raggiungibile. E nella scheda "Info" dell'ATA rilevo proprio queste informazioni:
External IP: 89.202.179.222
Mapped SIP Port: 4444
Vale a dire che STUN ha fatto un test, ed ha fatto sapere all'ATA che per raggiungerlo occorre inviare pacchetti alla porta 4444 dell'IP 89.202.179.222, perchè 89.202.179.222:4444 è l'indirizzo visto per l'ATA dallo STUN Server.
Io pensavo che NAT sostituisse anche la porta, invece mi sono accorto che esistono più tipi di NAT. Quello che dovrebbe utilizzare la WiPeX è un "Restricted Cone NAT", che se ho capito bene permette l'invio di dati da parte di un server Internet verso un client sotto tale NAT su qualsiasi porta di tale client, fermo restando che prima il client abbia fatto una richiesta a quel server.
Il nat, sostituisce ANCHE le porte! Si ma quello che viene usato per mascherare + Utenti dietro un solo IP pubblico DEVONO anche sostituire le porte. Cmq si il "Restricted Cone NAT" funziona cosi, ed è anche il modo + diffuso di implementare il nat.
Anch'io pensavo che il NAT sostituisse anche le porte, ma dopo aver visto 'sto casino con l'ATA, pare proprio che la sostituzione delle porte venga compiuta solo da NAT simmetrici o "Port Restricted Cone".
Quindi ho pensato che è per questo che la porta non viene sostituta: potendo un server spedire a qualsiasi porta di un client, che senso ha sostituire i numeri di porta? Il server vuole inviare alla 4444 del client sotto NAT, e allora invia alla 4444 dell'IP pubblico, logica ineccepibile. Giusto fin qui?
Infatti non funziona cosi, il server non puo inviarlo alla 4444, ma deve inviarla all porta che è stata dinamicamente rimappata per corrispondere con quella del client.
Esatto. Per questo sono arrivato alla conclusione che porta mappata e porta sorgente sono le stesse, ovvero il NAT non sostituisce le porte, per capirci nè il NAT del mio router, nè il NAT del router WiPeX.
in pratica il nat funziona cosi:
Struttura pacchetto TCP/IP
+-------------------------+-------------------+-------------------------------+------------------------+
|Indirizzo IP sorgente|Porta sorgente |Indirizzo IP destinazione |Porta destinazione |
+-------------------------+-------------------+-------------------------------+------------------------+
Esempio di comunicazione con NAT:
Richiesta cliente dentro NAT:
+-------------------------+-------------------+-------------------------------+------------------------+
| 192.168.1.1 | 8549 | 80.50.100.50 | 80 |
+-------------------------+-------------------+-------------------------------+------------------------+
Router Nat modifica il pacchetto :
+-------------------------+-------------------+-------------------------------+------------------------+
| 70.50.15.1 | 8550 | 80.50.100.50 | 80 |
+-------------------------+-------------------+-------------------------------+------------------------+
Come vedi ha sostituito l'ip con quello pubblico, e ha anche modificato la porta sorgente inserendo la prima
porta disponibile.
Invece a me succede questo (perdona la mia non voglia di ricorrere alla grafica...):
il mio ATA effettua la richiesta SIP, che viene incapsulata in un pacchetto IP con questi campi:
indirizzo src: 192.168.1.2:4444
indirizzo dst: sip.server.voip:5060 <-- porta di default per il protocollo SIP
Dopo il transito attraverso il mio router, il pacchetto IP contiene questa informazione:
indirizzo src: 172.16.x.y:4444
indirizzo dst: sempre quello precedente, ovviamente.
Dopo il transito attraverso il router di Unipex, il pacchetto IP contiene questa:
indirizzo src: 89.202.179.222:4444
indirizzo dst: il solito.
In tutti i casi, il pacchetto SIP all'interno del pacchetto IP contiene, nell'header VIA, l'indirizzo pubblico dell'ATA, che sarà utilizzato dal SIP Proxy per inviare la risposta. Esso è:
89.202.179.222:4444.
Ma nel pacchetto spedito dal SIP Proxy in risposta alla mia request, si ha nell'header VIA questo:
172.16.x.y:4444, anche se è strano perchè il SIP Server non dovrebbe avere da nessuna parte questo indirizzo.
Si nota a questo punto che la porta è rimasta invariata durante tutto il tragitto.
Solo se usavo in origine la 5060, c'erano delle modifiche sulla porta (ad esempio, mi forniva nell'header VIA porte
tipo 4704, che se poi usavo manualmente (cioè aggirando STUN) l'ATA funzionava, mentre se non le usavo, l'ATA non ce la faceva, e come ho già detto la cosa non funzionava. 'sta 5060...).
Ma allora sorge l'altro problema: se non c'è la sostituzione delle porte, e se due ATA fanno una richiesta allo stesso SIP Proxy, dalla stessa porta privata, come fa poi l'ATA a sapere dove inviare le risposte?
Esempio: l'ATA 192.168.0.1:5060, mappato dal router come 172.16.20.20:5060, viene sostituito dal NAT di Unipex come 89.202.179.222:5060. Ma anche l'ATA di un altro utente, mappato dal router come 172.16.20.21:5060, finisce per essere associato al 89.202.179.222:5060. E allora? Se le richieste dei due ATA sono dirette allo stesso server, questo poi spedirà due risposte (una per richiesta), entrambe al 89.202.179.222:5060. E come fa il NAT di Unipex a separare le risposte e mandarle l'una al 172.16.20.20:5060, l'altra al 172.16.20.21:5060?
Infatti non può le porte devono essere rimappate altrimenti non funziona un tubo.....!
Sono d'accordo con te! Ma perchè allora mi funziona! Vuoi che è solo legato al fatto che sono l'unico ad utilizzare quella porta? Mentre la 5060 era usata da più persone, e questo incasinava la cosa?
P.S.: Andrea, ora ho capito perchè non sopporti il NAT...
Be si, da + problemi che altro , poi come avrai capito dentro Nat non puoi avere servizi server quali:
HTTP---->80
Posta----> 25,110
... a meno di non abilitare il port forwarding, il port triggering, o la DMZ sul router...
Ciao e grazie!
