Die Liste der weiterzuleitenden bzw. freizugebenden Ports sieht bei jedem anders aus und auch die Provider sind etwas uneins. Um möglichst mal eine hoffentlich definitive Aussage treffen zu können, welche Ports mit welchem Protokoll denn nun genau benutzt werden, habe ich zwei Stunden "tcpdump" auf dem Linux-Router laufen lassen, ein paar RFCs durchgeblättert und alle möglichen Sachen mit dem SPA versucht:
Der SPA-2000 nutzt für SIP- und RTP-Verkehr ausschliesslich die im Webinterface eingestellten Ports, also per default für SIP die Ports 5060 u. 5061 UDP und für RTP die Ports 16384-16482, auch UDP. Nix anderes. Keine 5004-5007 (Grandstream) und keine 30000er (SIPPS-Software).
Wenn man also diese Ports für UDP mittels Router an den internen SPA weiterleitet reicht das aus!
STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) ist eine Sache für sich:
Der STUN-Server läuft laut RFC 3489 auf Port 3478. Und zwar beim Provider. Der Provider hat zwei STUN-Server - einer empfängt primär die Anfragen des Clients, der zweite STUN versucht primär die Rückverbindung.
Ablauf: Der SPA verbindet sich von einigen lokalen Ports auf den in der Konfiguration angegebenen STUN-Server des Providers. Danach versucht dieser, sich u.a. von einer anderen IP kommend (zweiter STUN-Server des Providers) zum Client auf dessen vorherige Absenderports zu verbinden. So wird erkannt, ob NAT und falls ja, welche Art von NAT benutzt wird.
Nikotel: Läuft so wie es soll.
Sipgate: Irgendwie ziemlich eigenartig:
Der SPA verbindet sich von einigen lokalen Ports auf stun.sipgate.net. Laut Konfigurationsanweisungen von Sipgate soll sich der Client auf Port 10000 des STUN-Servers verbinden. Die Rückverbindung erfolgt auch von diesem ersten STUN-Server zum SPA auf die vorherigen Absenderports des SPA, auch mit Absenderport 10000 von Seiten des Sipgate-STUN-Servers. Was das bringen soll ist mir nicht ganz klar denn richtig sinnvoll ist es ja eigentlich nur, wenn die Rückverbindung von einer anderen IP (zweiter STUN des Providers) aus erfolgt, da diese zweite IP ja möglicherweise nicht in der temporären NAT-Tabelle des Routers steht. Interessanterweise lauscht der erste Sipgate-STUN-Server neben der 10000 auch auf dem STUN-Standardport 3478. Wenn man sich auf diesen Port 3478 verbindet, erfolgt die Rückverbindung zwar auch vom ersten STUN mit Absenderport 10000, jedoch diesmal auch vom zweiten STUN und da mit dem "normalen" STUN-Absenderport 3478. Zumindest bei den Tests war das immer so. Die Frage ist nur - warum verkomplizieren die das so unnötig?
:verdaech:
Die Sipgate-Anleitung für Portforwarding auf Port 10000 ist schlicht falsch. Also, genau genommen nicht falsch sondern unpräzise, es ist die Rede von "Weiterleitung folgender Ports". Die 10000 ist aber der Absenderport des Sipgate-STUN-Servers und nicht der lokale(!) Zielport.
Der STUN-RFC 3489 beschreibt zwei Arten von Anfragen am STUN-Server, eine über UDP, die andere über TCP. Der SPA unterhält sich mit den STUN-Servern ausschliesslich via UDP.
Wem das alles zuviel war:
Der SPA-2000 benötigt Portforwarding nur für 5060/5061 UDP, die RTP-Ports sollten vom STUN geklärt werden. Auch Nikotel bietet einen STUN-Service (stun0.nikotel.com). Wenn man den Registrierungsintervall auf beispielsweise 60 Sekunden gesetzt hat (Nikotel-Default) und der Router sich die IP-Port-Zuordnung mindestens diese 60 Sekunden lang merken kann dann benötigt man zumindest für Nikotel überhaupt kein Portforwarding. STUN ja eigentlich sowieso nicht.
Gruß,
Exim
Der SPA-2000 nutzt für SIP- und RTP-Verkehr ausschliesslich die im Webinterface eingestellten Ports, also per default für SIP die Ports 5060 u. 5061 UDP und für RTP die Ports 16384-16482, auch UDP. Nix anderes. Keine 5004-5007 (Grandstream) und keine 30000er (SIPPS-Software).
Wenn man also diese Ports für UDP mittels Router an den internen SPA weiterleitet reicht das aus!
STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) ist eine Sache für sich:
Der STUN-Server läuft laut RFC 3489 auf Port 3478. Und zwar beim Provider. Der Provider hat zwei STUN-Server - einer empfängt primär die Anfragen des Clients, der zweite STUN versucht primär die Rückverbindung.
Ablauf: Der SPA verbindet sich von einigen lokalen Ports auf den in der Konfiguration angegebenen STUN-Server des Providers. Danach versucht dieser, sich u.a. von einer anderen IP kommend (zweiter STUN-Server des Providers) zum Client auf dessen vorherige Absenderports zu verbinden. So wird erkannt, ob NAT und falls ja, welche Art von NAT benutzt wird.
Nikotel: Läuft so wie es soll.
Sipgate: Irgendwie ziemlich eigenartig:
Der SPA verbindet sich von einigen lokalen Ports auf stun.sipgate.net. Laut Konfigurationsanweisungen von Sipgate soll sich der Client auf Port 10000 des STUN-Servers verbinden. Die Rückverbindung erfolgt auch von diesem ersten STUN-Server zum SPA auf die vorherigen Absenderports des SPA, auch mit Absenderport 10000 von Seiten des Sipgate-STUN-Servers. Was das bringen soll ist mir nicht ganz klar denn richtig sinnvoll ist es ja eigentlich nur, wenn die Rückverbindung von einer anderen IP (zweiter STUN des Providers) aus erfolgt, da diese zweite IP ja möglicherweise nicht in der temporären NAT-Tabelle des Routers steht. Interessanterweise lauscht der erste Sipgate-STUN-Server neben der 10000 auch auf dem STUN-Standardport 3478. Wenn man sich auf diesen Port 3478 verbindet, erfolgt die Rückverbindung zwar auch vom ersten STUN mit Absenderport 10000, jedoch diesmal auch vom zweiten STUN und da mit dem "normalen" STUN-Absenderport 3478. Zumindest bei den Tests war das immer so. Die Frage ist nur - warum verkomplizieren die das so unnötig?
:verdaech:
Die Sipgate-Anleitung für Portforwarding auf Port 10000 ist schlicht falsch. Also, genau genommen nicht falsch sondern unpräzise, es ist die Rede von "Weiterleitung folgender Ports". Die 10000 ist aber der Absenderport des Sipgate-STUN-Servers und nicht der lokale(!) Zielport.
Der STUN-RFC 3489 beschreibt zwei Arten von Anfragen am STUN-Server, eine über UDP, die andere über TCP. Der SPA unterhält sich mit den STUN-Servern ausschliesslich via UDP.
Wem das alles zuviel war:
Der SPA-2000 benötigt Portforwarding nur für 5060/5061 UDP, die RTP-Ports sollten vom STUN geklärt werden. Auch Nikotel bietet einen STUN-Service (stun0.nikotel.com). Wenn man den Registrierungsintervall auf beispielsweise 60 Sekunden gesetzt hat (Nikotel-Default) und der Router sich die IP-Port-Zuordnung mindestens diese 60 Sekunden lang merken kann dann benötigt man zumindest für Nikotel überhaupt kein Portforwarding. STUN ja eigentlich sowieso nicht.
Gruß,
Exim
