16. Februar 2026
Das Beispiel: Zwei Asterisk-Server sind bereits erfolgreich über eine IAX2-Verbindung miteinander verbunden. Diese IAX2-Verbindung soll nun in beiden Richtungen durch einen VPN-Tunnel geschickt werden. Dazu kommt die VPN-Software Wireguard zum Einsatz. Beide Asterisk-Server laufen auf Linux Debian (z.B. Ubuntu oder Raspian). Das Vorgehen und Einrichten wird an einem Beispiel zwischen den beiden fiktiven Asterisk-Servern Michael und Volker erklärt, da man sonst alles vermischt. Zum Schluss erklärt der Artikel, wie man mehrere Asterik-Server mit IAX2 und Wireguard abhörsicher vernetzen kann.
Bei der Einrichtung hat mir der Chatbot Claude.ai sehr geholfen. Am besten richtet man an ihn Rückfragen und sendet Claude die Fehlermeldungen zu, falls etwas nicht klappt. Oft liegt es an Aktualisierungsproblemen. Claude hilft dann mit den richtigen Linuxbefehlen weiter. Getestet habe ich die Verbindung zwischen einem Strato-Server mit Asterisk 18 und einem Raspberry Pi und Asterisk 16.
Voraussetzung ist, dass bereits erfolgreich eine IAX2-Verbindung zwischen den beiden Servern besteht. Dies wurde bereits auf https://elektronikbasteln.pl7.de/mehrere-asterisk-server-ueber-das-iax2-protokoll-verbinden erklärt.
Die bereits vorhandenen iax.conf als fiktives Beispiel: Auf Michael befindet sich bereits folgende iax.conf:
; iax.conf auf Server von Michael [general] disallow=all allow=alaw allow=ulaw allow=gsm allow=g722 jitterbuffer=no forcejitterbuffer=no autokill=yes delayreject=yes requirecalltoken=no qualify=yes ; ++ Volker mit Vorwahl 8842 erreichbar laut extensions.conf ++ [outgoing-volker] type=peer username=incoming-michael context=telefone host=volker.dyndns.org secret=123abc auth=md5 trunk=no qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes [incoming-volker] type=user username=outgoing-michael context=telefone host=volker.dyndns.org secret=123abc auth=md5 trunk=no qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes
Auf Michaels Server könnte in der dortigen extensions.conf unter [telefone] folgender Eintrag stehen:
; IAX2-Verbindung zu Volkers Server mit Vorwahl 8842
exten => _8842X.,1,NoOp(IAX2 - Michael ruft Volker an mit Vorwahl 8842)
same => n,Dial(IAX2/outgoing-volker/${EXTEN:4})
Mit der Vorwahl 8842 lassen sich die Nummern auf Volkers Server erreichen.
Entsprechend befindet sich auf Volkers Server bereits folgende iax.conf:
; iax.conf auf Server von Volker [general] disallow=all allow=alaw allow=ulaw allow=gsm allow=g722 jitterbuffer=no forcejitterbuffer=no autokill=yes delayreject=yes requirecalltoken=no qualify=yes ; ++ Michael mit Vorwahl 8845 erreichbar laut extensions.conf ++ [outgoing-michael] type=peer username=incoming-volker context=telefone host=michael.dyndns.org secret=123abc auth=md5 trunk=no qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes [incoming-michael] type=user username=outgoing-volker context=telefone host=michael.dyndns.org secret=123abc auth=md5 trunk=no qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes
Auf Volkers Server könnte in der dortigen extensions.conf unter [telefone] folgender Eintrag stehen:
; IAX2-Verbindung zu Michaels Server mit Vorwahl 8845
exten => _8845X.,1,NoOp(IAX2 - Volker ruft Michael an mit Vorwahl 8845)
same => n,Dial(IAX2/outgoing-michael/${EXTEN:4})
Die Angaben sind fiktiv und die Passwörter sind der Übersichtlichkeit wegen schwach gewählt. Falls es die michael.dyndns.org und die volker.dyndns.org bereits gibt, ist das rein zufällig. Hier am Beispiel hat Michaels Server die URL michael.dyndns.org und Volkers Server die volker.dyndns.org, damit man sich das ganz einfach merken kann.
Abändern der beiden iax.conf: Damit wir eine VPN-Verbindung aufbauen können, müssen die beiden URLs durch andere IP-Adressen ersetzen, die der VPN-Tunnel verwendet. Im Beispiel ersetzen wir
auf Volkers Server die beiden Zeilen
host=michael.dyndns.org durch host=10.99.99.1
auf Michaels Server die beiden Zeilen
host=volker.dyndns.org durch host=10.99.99.2
Mehr müssen wir an den beiden iax.conf nicht verändern.
Firewall und Portforwarding: Wireguard verwendet den UDP-Port 51820. Auf beiden Servern eventuell die Firewall öffnen:
sudo ufw allow 51820/udp
Falls ein Server (zum Beispiel ein Raspberry Pi) hinter einem Router ist, dann im Router Portweiterleitung für 51820 UDP einrichten.
Wireguard installieren: Auf beiden Servern müssen wir Wireguard installieren:
sudo apt-get update sudo apt-get install wireguard
Dann auf beiden Servern die Schlüssel generieren:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
Die Schlüssel anzeigen lassen: Auf jeden Server wurde ein privat key und ein public key erzeugt. Der privat key bleibt auf dem Server und den geben wir nicht aus der Hand. Den public key müssen wir dem anderen Server mitteilen.
Private Key anzeigen lassen:
cat /etc/wireguard/privatekey
Public Key anzeigen lassen:
cat /etc/wireguard/publickey
Den public und private key, der auf auf Volkers Server erzeugt wurde, nennen wir zur besseren Unterscheidung hier im Beispiel volkerpublickey und volkerprivatekey. Entsprechend wurden auf Michaels server michaelpublickey und michaelprivatekey erzeugt.
Die wg0.conf auf etc/wireguard: Wir erzeugen nun eine Textdatei namens wg0.conf für Volkers Server mit folgendem Inhalt:
[Interface] PrivateKey = volkerprivatekey Address = 10.99.99.2/24 ListenPort = 51820 [Peer] PublicKey = michaelpublickey AllowedIPs = 10.99.99.1/32 Endpoint = michael.dyndns.org:51820 PersistentKeepalive = 25
Damit wir diese erstellen können, müssen wir von Michael die michaelpublickey per E-Mail, mündlich, per Post oder sonst wie erhalten haben. Unseren private key geben wir niemals her. Die puplic keys müssen wir uns gegenseitig austauschen.
Die Dateiberechtigung sollte eine Leseberechtigung für root sein, um die Schlüssel zu schützen. Vorsicht, wenn die Datei auf Windows erzeugt wurde. Sie muss dann eventuell entsprechend für Linux konvertiert werden.
Diese Datei kopieren wir in den Ordner etc/wireguard auf Volkers Server.
Entsprechend sieht dann etc/wireguard/wg0.conf auf Michaels Server aus:
[Interface] PrivateKey = michaelprivatekey Address = 10.99.99.1/24 ListenPort = 51820 [Peer] PublicKey = volkerpublickey AllowedIPs = 10.99.99.2/32 Endpoint = volker.dyndns.org:51820 PersistentKeepalive = 25
Beachte, dass 10.99.99.2 und 10.99.99.1 vertauscht wurden. Die URL volker.dyndns.org und michael.dyndns.org können wir auch durch entsprechenden statischen öffentlichen IP-Adressen der Server ersetzen. Die Eingabe einer statischen öffentlichen IP wäre die bessere Lösung.
Initialisierungen und Aktualisierungen: Wir nun alles erfolgreich eingerichtet. Nun müssen wir höchstwahrscheinlich Wireguard und Asterisk auf beiden Servern aktualisieren.
IAX2 von Asterisk neu starten:
# IAX2 komplett neu starten sudo asterisk -rx "module unload chan_iax2.so" sudo asterisk -rx "module load chan_iax2.so" # Status prüfen sudo asterisk -rx "iax2 show peers" ``` **Jetzt sollte stehen:** ``` Host: 10.99.99.2 oder 10.99.99.1
Wireguard neu starten:
sudo systemctl restart wg-quick@wg0
Oder noch sicherer:
# Komplett stoppen sudo wg-quick down wg0 # Neu starten sudo wg-quick up wg0
Nun kannst du die getunnelte IAX2-Verbindung in beiden Richtungen mit Testanrufen ausprobieren!
Testen der VPN-Verbindung:
sudo wg show
in Asterisk:
iax2 show peers
Falls dir die Meldungen verdächtig vorkommen, dann teile sie Claude.ai einfach mit und erkläre den Sachverhalt.
Regelmäßiger DNS-Lookup: Falls der andere Server eine dynamische öffentlich IP hat, könnte es laut https://elektronikbasteln.pl7.de/mehrere-asterisk-server-ueber-das-iax2-protokoll-verbinden sinnvoll sein eine dnsmgr.conf wie folgt in Asterisk einzurichten:
; Einträge in der dnsmgr.conf für einen regelmäßigen DNS-Lookup
;
[general]
enable=yes ; enable creation of managed DNS lookups
; default is 'no'
refreshinterval=120 ; refresh managed DNS lookups every <n> seconds
; default is 300 (5 minutes)
Claude konnte mir keine Antwort darauf geben. Deshalb schadet diese Einrichtung nicht, falls sich die öffentliche dynamische IP ändert, damit sich ein DynDNS-Dienst aktualisieren kann.
Weitere IAX2-Verbindungen mit Wireguard zu mehreren Asterisk-Servern aufbauen: Siehe https://claude.ai/share/b96c6135-4733-4d68-812d-5314a3d7c2ba.
Wie abhörsicher ist Wireguard? WireGuard-Verbindungen sind sehr abhörsicher und gehören zu den sichersten VPN-Lösungen, die derzeit verfügbar sind.
Kryptographische Sicherheit: WireGuard verwendet moderne, bewährte Kryptographie:
ChaCha20 für Verschlüsselung (sehr schnell und sicher)
Poly1305 für Authentifizierung
Curve25519 für Schlüsselaustausch
BLAKE2s für Hashing
HKDF für Schlüsselableitung
Diese Algorithmen sind State-of-the-Art und werden auch von Kryptographie-Experten empfohlen.
Praktische Abhörsicherheit: Sehr hoch geschützt gegen:
Passives Abhören des Netzwerkverkehrs (z.B. durch ISPs, Behörden)
Man-in-the-Middle-Angriffe
Replay-Angriffe
Unberechtigten Zugriff ohne Private Key
Was WireGuard bietet:
Ende-zu-Ende-Verschlüsselung zwischen den Servern
Perfect Forward Secrecy – selbst wenn ein Schlüssel kompromittiert wird, bleiben alte Verbindungen sicher
Authentifizierung – nur Server mit dem richtigen Key können sich verbinden
Minimaler Code (ca. 4.000 Zeilen) = weniger Angriffsfläche als komplexe VPNs wie OpenVPN
Wichtige Einschränkungen: WireGuard schützt NICHT gegen:
Kompromittierung eines Servers – wenn jemand Zugriff auf einen Server und den Private Key hat, kann er den Verkehr entschlüsseln
Metadaten – WireGuard verschlüsselt den Inhalt, aber IP-Adressen und Verbindungszeiten bleiben sichtbar
Fehlerhafte Konfiguration – z.B. wenn Private Keys unsicher gespeichert werden
Best Practices für maximale Sicherheit
Private Keys schützen: Nur Root-Zugriff, Dateiberechtigungen 600
Regelmäßige Updates der WireGuard-Software
Firewall konfigurieren – nur notwendige Ports öffnen
Schlüsselrotation bei Verdacht auf Kompromittierung
Fazit: Für deine IAX2-Verbindungen zwischen Asterisk-Servern ist WireGuard eine ausgezeichnete Wahl. Die Verbindung ist praktisch abhörsicher, solange die Server selbst nicht kompromittiert sind. Das ist deutlich sicherer als unverschlüsseltes IAX2 über das Internet.
Wie viele Telefongespräche gehen durch den IAX2-Wireguard-Tunnel? Das hängt von mehreren Faktoren ab, aber hier sind die wichtigen Aspekte:
Theoretische Kapazität
WireGuard selbst setzt hier praktisch keine Grenzen – es kann Gigabit-Geschwindigkeiten erreichen. Die Begrenzung kommt von anderen Faktoren:
Praktische Begrenzungsfaktoren
1. Bandbreite deiner Internetverbindung
Ein typisches Telefongespräch mit IAX2 benötigt:
G.711 Codec: ca. 80-90 kbit/s pro Gespräch (hohe Qualität)
G.729 Codec: ca. 25-30 kbit/s pro Gespräch (komprimiert)
GSM Codec: ca. 13-20 kbit/s pro Gespräch (stark komprimiert)
Beispielrechnung mit G.711:
10 Mbit/s Upload = ca. 100-120 gleichzeitige Gespräche
50 Mbit/s Upload = ca. 500-600 gleichzeitige Gespräche
100 Mbit/s Upload = ca. 1000+ gleichzeitige Gespräche
2. CPU-Last
WireGuard ist sehr effizient, aber Verschlüsselung kostet CPU
Asterisk selbst braucht auch CPU für Transcoding (falls nötig)
Moderne Server können typisch hunderte bis tausende Gespräche verarbeiten
3. IAX2-Trunking (wichtig!)
IAX2 kann mehrere Gespräche bündeln (Trunking):
Reduziert Overhead
Effizienter bei vielen gleichzeitigen Gesprächen
Solltest du aktivieren bei höherer Last