März 6

Linux STUN Server selber aufsetzen (stuntman 1.2.9 auf Ubuntu 14.04)

Ein paar VoIP Experimente haben mich dazu gebracht, das Thema STUN
einmal selbst anzugehen und einen eigenen STUN Server bereitzustellen.

Nach etwas Recherche bin ich auf die opensource Software Stuntman von John Selbie gestoßen,
dessen Einrichtung überraschend einfach ist – noch dazu wird dieser STUN-Server
hochperformant & für den produktiven Betrieb beworben.
Die Einrichtung gestaltet sich wie folgt:

Zuerst benötigt man folgende, zum kompilieren des Quellcodes nötige, Pakete
(die Namen können bei anderen Distributionen abweichen):
g++
make
libboost-dev
libssl-dev
… alle befinden sich bei Ubuntu in den Repositories, können also per
sudo apt-get install g++ make libboost-dev libssl-dev
einfach und schnell installiert werden.

Danach lädt man sich die aktuelle Version von der Seite herunter (aktuell ist das Version 1.2.9).
Die heruntergeladene .tgz kann man mit dem Befehl
tar xvzf stunserver-1.2.9.tgz
entpacken.
Nach einem Wechsel in das entstandene Unterverzeichnis „stuntman“ kann man nun mit
dem Befehl „make“ den Quellcode kompilieren lassen. Wer bereits zuvor mal ein Programm
aus dem Sourcecode heraus kompiliert hat, kennt das.

Sobald das geschehen ist, befinden sich 3 ausführbare Dateien im Verzeichnis:
stunclient (ein Client zum Test der Funktion des eigenen oder fremder STUN-Server)
stunserver (der eigentliche Server)
stuntestcode (eine Binary zum Test des kompilierten Codes)

Letzteres sollte zur Sicherheit einmal gestartet werden. In der Ausgabe sollte dabei
kein „FAIL“ zu sehen sein. Andernfalls gab es entweder einen Fehler beim Kompilieren
oder es gibt einen schweren Bug im Quellcode (was in der Version 1.2.9 nicht der Fall ist).
Die Ausgabe sieht dann wie folgt aus:

# ./stuntestcode
Result of CTestDataStream: PASS
Result of CTestReader: PASS
Result of CTestBuilder: PASS
Result of CTestIntegrity: PASS
Result of CTestMessageHandler: PASS
Result of CTestCmdLineParser: PASS
Testing detection for DirectMapping
Testing detection for EndpointIndependent mapping
Testing detection for AddressDependentMapping
Testing detection for AddressAndPortDependentMapping
Testing detection for EndpointIndependentFiltering
Testing detection for AddressDependentFiltering
Testing detection for AddressAndPortDependentFiltering
Result of CTestClientLogic: PASS
Result of CTestRecvFromEx(IPV4): PASS
Result of CTestRecvFromEx(IPV6): PASS
Result of CTestFastHash: PASS
Result of CTestPolling: PASS
Result of CTestAtomicHelpers: PASS
Result of CTestRateLimiter: PASS

Damit ist die Installation auch schon abgeschlossen und es kann an den Betrieb gehen.

Hier kommt es nun darauf an, ob der STUN Server im Full oder Basic Mode laufen soll.
Für den Full-Mode benötigt der Server 2 IP-Adressen, für den Basic reicht eine.
Da der Server standardmäßig nicht als Daemon im Hintergrund läuft, ist es empfehlenswert,
hierfür eine screen Session zu starten (oder vergleichbares).

Für den Basic Mode reicht folgender Befehl:
stunserver --mode basic --family 4 --protocol udp --primaryinterface xxx.xxx.xxx.xxx --verbosity 1
Hier muss statt xxx.xxx.xxx.xxx die (öffentliche) IP Adresse eingetragen werden, auf
der der STUN-Server lauschen soll.
Dabei steht –family 4 dafür, dass er IPv4 benutzt (kann auch v6), –protocol udp
für – wer hätte es gedacht – die Verwendung des UPD Protokolls und –verbosity
für das Loglevel. Wenn man zum Testen etwas mehr „sehen“ will, kann man diesen
auch auf 3 setzen.

Für den Full Mode tut’s dieser Befehl:
stunserver --mode full --family 4 --protocol udp --primaryinterface xxx.xxx.xxx.xxx --altinterface yyy.yyy.yyy.yyy --verbosity 1
Hier bildet xxx.xxx.xxx.xxx die primäre IP-Adresse und yyy.yyy.yyy.yyy die sekundäre IP-Adresse.

Das war’s. Dazu sollte man ggfs. noch seine Firewall anpassen. Da ich in meinem Fall
hierfür 2 eigene IP-Adressen benutzt habe, die sonst von keinem Dienst verwendet werden,habe ich per iptables alles andere gesperrt.
Die Standardports für STUN sind 3478 und 3479 UDP.
Die Regeln sehen dabei also so aus:
iptables -A INPUT -d xxx.xxx.xxx.xxx -p udp --dport 3478 -j ACCEPT
iptables -A INPUT -d xxx.xxx.xxx.xxx -p udp --dport 3479 -j ACCEPT
iptables -A INPUT -d yyy.yyy.yyy.yyy -p udp --dport 3478 -j ACCEPT
iptables -A INPUT -d yyy.yyy.yyy.yyy -p udp --dport 3479 -j ACCEPT
iptables -A INPUT -d xxx.xxx.xxx.xxx -p icmp -j ACCEPT
iptables -A INPUT -d yyy.yyy.yyy.yyy -p icmp -j ACCEPT
iptables -A INPUT -d xxx.xxx.xxx.xxx -j DROP
iptables -A INPUT -d yyy.yyy.yyy.yyy -j DROP

Hierbei habe ich auch icmp erlaubt, damit man zu Diagnosezwecken auch mal
einen Ping an die IPs senden kann. Zwingend nötig ist das natürlich nicht.
Da man mit den letzten beiden Einträgen alles Andere aussperrt, ist es natürlich
wichtig zu verifizieren, dass auch wirklich kein weiterer Dienst auf den IPs läuft
und man sich damit nicht aussperrt.


Schlagwörter: , ,

Veröffentlicht6. März 2016 von gerger in Kategorie "Allgemein

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.