Wer nicht gerade über eine FRITZ!Box Fon oder einen anderen VoIP-fähigen DSL-Router verfügt, muss einige Klimmzüge anstellen, um VoIP dennoch zum Laufen zu bringen. Die Gründe dafür sind im Protokolldesign von VoIP zu finden, hier gibt es gleich zwei Stolperstellen:
1.) Über SIP meldet sich das VoIP-Endgerät beim SIP-Server an (REGISTER). Hierbei teilt es dem Server mit, unter welcher IP-Adresse und welchem Port es Anrufanfragen entgegennimmt. Hinter einer NAT-Firewall hat das Endgerät allerdings eine private IP-Adresse, die von außen nicht erreichbar ist. Die öffentliche Adresse kennt das Endgerät im Allgemeinen nicht.
2.) Über SIP/SDP wird ein Telefongespräch ausgehandelt. Die eigentlichen Sprachdaten fließen jedoch via RTP über komplett andere Ports. Welche Ports das genau sind, entscheidet das VoIP-Endgerät und teilt sie der Gegenstelle beim Gesprächsaufbau mit. Also versucht die Gegenstelle, den RTP-Strom an den spezifizierten Port zu schicken. Dieser wird allerdings von der Firewall geschlossen, weil sie nichts von SIP und VoIP versteht.
In beiden Fällen kommt es zu Schwierigkeiten, da im Protokoll auf der Anwendungsebene IP- und Port-Informationen geschickt werden. Eine normale Layer-3-Firewall kennt aber nur die Protokollebene und die darin enthaltenen IP- und Port-Informationen.
UPnP
Manche DSL-Router bieten inzwischen Unterstützung für UPnP - das Universal Plug and Play. Dabei handelt es sich um eine Protokoll-Suite, die in einem Netzwerk dasselbe leisten soll wie das Plug and Play auf einem einzelnen Computer. Ziel ist es, Dienste in einem Netzwerk automatisch zu erkennen und korrekt zu nutzen.
Im VoIP-Szenario fragt das Endgerät via UPnP am NAT-Router nach, welche öffentliche IP-Adresse und Ports es benutzen darf. Diese Informationen verwendet es als Absenderadresse in den entsprechenden Protokollen. Der NAT-Router konfiguriert seine Firewall dann so um, dass die eingehenden Pakete auch das Endgerät erreichen. Leider sind nur wenige NAT-Implementierungen UPnP-tauglich. Die Änderung von Firewall-Regeln durch eine Anwendung birgt darüber hinaus ein zusätzliches Sicherheitsrisiko. Außerdem muss das Endgerät UPnP unterstützen.
Dazu muss die Software oder das VoIP-Endgerät UPnP unterstützen. Eine solche Software ist beispielsweise SIPPS. Es gibt sie auch als kostenlose Variante, wenn Sie sich bei Freephone von web.de anmelden.
STUN
Bei STUN (Simple Traversal of UDP Through NATs, RFC3489) handelt es sich um eine weitere Möglichkeit, mit der Endgeräte hinter einem NAT-Router die Netzwerkkonfiguration herausfinden können. Hierbei sendet das Endgerät eine Nachricht an einen außerhalb des LAN befindlichen STUN-Server. Dieser schickt dann ein Paket zurück, das Absenderadresse und -port enthält, also die tatsächlichen Informationen, die vom NAT-Router dort eingetragen wurden.
Verwendet ein Endgerät beispielsweise die lokale Adresse 192.168.80.5:8888, so schickt es mit dieser Adresse eine Anfrage an den STUN-Server. Dieser empfängt das Paket mit der Absenderadresse 134.96.249.10:8899 und antwortet an diese Adresse mit einem Paket, das diese IP/Port-Kombination enthält. Somit kann das hinter dem NAT befindliche Endgerät dann für alle folgenden Verbindungen diese Kombination in den SIP/SDP-Paketen verwenden, während es selbst weiterhin auf 192.168.80.5:8888 hört.
Durch die Verbindung zum STUN-Server ist automatisch ein Port im NAT geöffnet, der zum Endgerät weitergeleitet wird. Bei bestimmten NAT-Implementationen ist es allerdings so, dass nur der STUN-Server diesen Port nutzen darf („symmetrisches NAT“). Beim so genannten „Full Cone NAT“ darf ein beliebiger externer Host den Port nutzen.
Eingeschränktes NAT
Zusätzlich zum „Full Cone NAT“ existieren noch „Restricted Cone NAT“ und „Port Restricted Cone NAT“. Beim Ersteren darf ein beliebiger externer Host nur dann den Port nutzen, wenn zuvor der interne Rechner ein Paket an den externen Host geschickt hat. Die zweite Variante ist zusätzlich dahingehend beschränkt, dass der interne Rechner zuvor ein Paket an den Port der Gegenstelle gesendet haben muss, den diese für ihr eigenes Paket genutzt hat.
Nur die letzten drei NAT-Varianten funktionieren mehr oder weniger gut mit STUN. Ein Problem ist beispielsweise, dass der NAT-Router den betreffenden Port nach einer Weile wieder schließt, wenn keine Daten mehr fließen. Der Client muss also regelmäßig Daten an den STUN-Server schicken, damit die beim SIP-Server angegebene „Kontakt-Adresse“ weiterhin korrekt bleibt.
Sitzen beide Seiten hinter NAT-Systemen, kann es trotz STUN zu Schwierigkeiten kommen, da gerade bei den eingeschränkten Varianten gegebenenfalls schon der Verbindungsaufbau verhindert oder die Sprachübertragung nach kurzer Zeit unterbrochen wird.
Ports manuell frei schalten
Die letzte Alternative zu STUN und UPnP ist die manuelle Weiterleitung der Ports am Router zum Endgerät. Das macht allerdings nur Sinn, wenn Sie am Endgerät oder der Software vorgeben können, auf welchen Ports SIP und RTP entgegengenommen werden sollen. Solange sich die Software oder das Gerät auf einen sehr kleinen Portbereich für RTP beschränkt, ist es auch kein großes Problem, wenn Sie diese Einstellungen nicht vornehmen können.
Richtig problematisch wird es nur, wenn sich das VoIP-Telefon beliebige Ports aus dem gesamten für RTP spezifizierten Bereich (Ports oberhalb 1024) herausgreift. Schließlich wollen Sie ja nicht den gesamten Bereich frei schalten. Zudem wird es dann sehr schwierig, mehrere VoIP-Endgeräte im lokalen Netz zu betreiben.
SIP
Standardmäßig ist Port 5060 für SIP vorgesehen. Wenn Sie nur ein SIP-Gerät im Netzwerk haben, stellt das auch kein weiteres Problem dar. Sie müssen nur auf diesem Port eingehende Pakete an die IP-Adresse des SIP-Endgeräts weiterleiten. Bei mehreren Endgeräten vergeben Sie einfach eine andere Portnummer, SIP hat damit kein Problem.
Achtung bei SIPPS: Hier wird zusätzlich ein zweiter Port benötigt, dessen Nummer um zwei höher ist als die des ersten SIP-Ports. Denken Sie also daran, auch diesen weiterzuleiten.
RTP
Die eigentlichen Sprachdaten fließen via RTP zum VoIP-Endgerät. Hier wird je nach Implementation eine mehr oder minder große Anzahl an Ports benötigt, mindestens jedoch zwei: ein Kanal für die Daten und einer für die Übertragung der Statusinformationen. SIPPS möchte beispielsweise per Default sechs Ports für sich reservieren: 30000 bis 30005. Reichen Sie diese Ports auch an die IP-Adresse des Clients durch. Sie können SIPPS aber auch anweisen, nur zwei Ports zu benutzen, indem Sie den Portbereich einschränken: 30000-30001.
Wollen Sie mehrere VoIP-Geräte im LAN betreiben, richten Sie mehrere Blöcke mit Ports ein, etwa 30000-30005 für das erste Gerät, 30010-30015 für das zweite Gerät und so weiter.
Damit hat sich die Konfiguration auch schon erledigt. Das Sicherheitsrisiko durch die weitergeleiteten Ports ist vergleichsweise gering. Im Vergleich zu STUN besteht eine größere Wahrscheinlichkeit, dass es klappt. Und im Gegensatz zu UPnP haben Sie die volle Kontrolle. (mha)