Tailscale statt Portweiterleitung: NAS und Pi erreichen

Benötigt Tailscale eine Portweiterleitung?

Tailscale benötigt keine Portweiterleitung. Für den Zugriff auf Ihre eigenen Rechner ersetzt es Portweiterleitungen vollständig. Jedes Gerät in Ihrem tailnet, dem privaten Netzwerk, das Tailscale zwischen Ihren Geräten aufbaut, stellt eigene ausgehende Verbindungen her. An Ihrem Heimrouter müssen Sie nichts ändern: kein weitergeleiteter Port, kein DMZ-Host (Host in der demilitarisierten Zone), kein dynamischer DNS-Eintrag und keine öffentliche IP-Adresse sind erforderlich. Ein NAS (Network-Attached-Storage-Gerät), ein Raspberry Pi oder ein Gameserver hinter einem ipTIME- oder Fritz!Box-Router ist von Ihrem Laptop aus überall unter seiner privaten Adresse erreichbar. Die eingehende Seite des Routers bleibt dabei geschlossen.

Auch die Einschränkungen sind schnell erklärt. Tailscale verbindet Geräte, die bei Ihrem tailnet angemeldet oder für dieses freigegeben sind. Eine fremde Person im Internet oder ein Freund, der dem tailnet nicht beigetreten ist, kann darüber nichts erreichen. Einen Dienst dem gesamten öffentlichen Internet bereitzustellen, ist eine andere Aufgabe, die weiter unten behandelt wird.

Wie Tailscale NAT ohne Portweiterleitung durchdringt

Portweiterleitungen existieren aufgrund von NAT (Network Address Translation). Bei den meisten Heimanschlüssen besitzt der Router die eine öffentliche IPv4-Adresse, während jedes Gerät dahinter eine private Adresse verwendet. Ein eingehendes Paket, das am Router ankommt, enthält keinen Hinweis darauf, welches private Gerät es empfangen soll, weshalb der Router es verwirft. Eine Portweiterleitung ist eine manuelle Regel, die besagt: „Port 25565 gehört zu 192.168.0.20“. Tailscale erreicht dasselbe Ergebnis ohne diese Regel in vier Schritten.

Erstens baut jeder Knoten eine Verbindung nach außen auf. Beim Start verbindet sich tailscaled mit dem Koordinationsserver. Es bevorzugt normales HTTP auf TCP 80, verpackt in einen eigenen verschlüsselten Transport, und weicht auf HTTPS über TCP 443 aus, wenn Port 80 nicht antwortet. Es sendet seinen öffentlichen WireGuard-Schlüssel und lernt die öffentlichen Schlüssel sowie Adressen aller anderen Knoten im Tailnet. Der Koordinationsserver überträgt niemals Ihren Datenverkehr, sondern nur die Schlüssel und das Adressbuch.

Zweitens ermittelt jeder Knoten, wie er von außen wahrgenommen wird. Er sendet eine STUN-Anfrage (Session Traversal Utilities for NAT) über UDP an Port 3478 auf den Relay-Servern von Tailscale. Die Antwort enthält die öffentliche IP und den Port, die der Router diesem ausgehenden Paket zugewiesen hat. Dies ist die Zuordnung, die eine Portweiterleitung manuell erstellt hätte, nur dass der Router sie für einen ausgehenden Datenstrom selbstständig angelegt hat. Unterstützt der Router UPnP oder NAT-PMP, fragt Tailscale zusätzlich automatisch eine Zuordnung an, was hilfreich ist, aber nicht zwingend vorausgesetzt wird.

Drittens führen beide Seiten ein „Punching“ durch. Knoten A und Knoten B erfahren über den Koordinationsserver den öffentlichen Endpunkt des jeweils anderen. Beide senden gleichzeitig UDP-Pakete von ihrem eigenen Listener, standardmäßig Port 41641, an den öffentlichen Endpunkt der Gegenseite. Jeder Router hält bereits eine ausgehende Zuordnung für seinen eigenen Knoten, sodass das von der Gegenseite eintreffende Paket dieser Zuordnung entspricht und durchgelassen wird. Ab diesem Moment kommunizieren die beiden Knoten direkt über WireGuard, ohne dass der Router eine Regel benötigt.

Viertens bleibt der Datenverkehr bei fehlgeschlagenem Punching über ein Relay bestehen. Jede Verbindung beginnt tatsächlich über einen DERP-Server (Designated Encrypted Relay for Packets), der die verschlüsselten WireGuard-Pakete über HTTPS auf TCP 443 überträgt. Tailscale versucht anschließend, die Verbindung auf den direkten UDP-Pfad aus Schritt drei zu aktualisieren. CGNAT (Carrier-Grade NAT, bei dem der ISP Sie hinter ein zweites, von ihm kontrolliertes NAT schaltet) und symmetrisches NAT (bei dem der Router für jedes Ziel einen neuen Port wählt, wodurch die STUN-Antwort nutzlos wird) verhindern dieses Upgrade ebenso wie eine Unternehmens-Firewall, die UDP blockiert. Schlägt das Upgrade fehl, versucht Tailscale zunächst ein Peer-Relay – ein Gerät in Ihrem eigenen Tailnet, das Sie für die Weiterleitung von Datenverkehr über UDP konfiguriert haben. Ist kein solches verfügbar, bleibt die Verbindung über DERP bestehen. Das Relay sieht nur den Geheimtext. Dies kostet zudem Latenz und Durchsatz, und warum eine über Relay laufende Tailscale-Verbindung langsam ist und wie man eine direkte Verbindung herstellt erläutert, wie Sie den verwendeten Pfad ermitteln und was Sie ändern können.

Keiner dieser vier Schritte stellt eine eingehende Verbindung zu Ihrem Router dar. Genau deshalb ist keine Portweiterleitung erforderlich.

Client installieren und den Pfad prüfen

Die Installation besteht aus einem Skript und einer Anmeldung auf jedem Gerät.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

tailscale up gibt eine Anmelde-URL aus. Öffnen Sie sie, melden Sie sich an, und das Gerät wird dem Tailnet hinzugefügt. tailscale ip -4 gibt die Tailnet-Adresse des Geräts aus dem Bereich 100.64.0.0/10 aus. Diese Adresse bleibt über Reboots und Netzwerke hinweg unverändert. Verwenden Sie sie daher in SSH-Konfigurationen und Spieleclients.

Prüfen Sie von einem zweiten Gerät im Tailnet den Pfad zum ersten Gerät:

tailscale ping nas

Verwenden Sie den Hostnamen oder die Tailnet-Adresse. Die erste Antwort enthält häufig via DERP, weil jede Verbindung zunächst über einen Relay läuft, während der direkte Pfad noch ausgehandelt wird. Innerhalb weniger Sekunden sollten die Antworten auf eine öffentliche IP-Adresse und einen Port wechseln. Das bedeutet, dass Hole Punching erfolgreich war. Antworten, die nach einer Minute weiterhin via DERP enthalten, bedeuten, dass der Vorgang nicht abgeschlossen werden konnte. Ursache ist meist, dass sich eine Seite hinter einem NAT befindet, das Hole Punching nicht passieren lässt, oder dass ein Netzwerk UDP blockiert. In diesem Fall besteht eine Relayed-Verbindung.

Die eine Firewall-Regel, die sich lohnt

Tailscale funktioniert in den meisten Netzwerken ohne Änderungen an der Firewall, weil ausgehender UDP-Verkehr normalerweise erlaubt ist. Eine optionale Regel erhöht die Wahrscheinlichkeit einer direkten Verbindung: Erlauben Sie ausgehenden UDP-Verkehr vom Port 41641.

Auf einem Heimrouter oder in einer Unternehmens-Firewall, die ausgehenden UDP-Verkehr grundsätzlich einschränkt, bedeutet das: Geräte dürfen UDP mit dem Quellport 41641 an jede Adresse und jeden Zielport senden. Zusätzlich muss ausgehender UDP-Verkehr zum Zielport 3478 für STUN erlaubt sein. Nur den Zielport 41641 zu erlauben, reicht nicht aus, weil das NAT oder die Konfiguration eines Peers den Verbindungsendpunkt auf einen beliebigen Port legen kann. Die meisten Heimrouter erlauben ausgehenden UDP-Verkehr bereits vollständig. In diesem Fall ist keine Änderung erforderlich.

Auf einem VPS ist die eingehende Richtung relevant. Ein VPS hat seine öffentliche IP-Adresse normalerweise direkt auf der eigenen Netzwerkschnittstelle oder höchstens über ein festes 1:1-NAT, wie es beispielsweise ein AWS Internet Gateway verwendet. Eine eingehende Regel für UDP 41641 stellt daher für jeden Peer ein stabiles, erreichbares Ziel bereit. Ein Peer hinter einem problematischen NAT kann dann häufig trotzdem direkt verbinden, sofern sein eigenes Netzwerk ausgehenden UDP-Verkehr zulässt. Ein Peer in einem Netzwerk, das UDP blockiert, bleibt unabhängig von der Konfiguration des VPS auf einem Relay. Mit ufw:

sudo ufw allow 41641/udp
sudo ufw status

ufw status sollte 41641/udp als ALLOW von Anywhere aufführen. Anbieter, die in ihrem Control Panel eine separate Netzwerk-Firewall betreiben, benötigen dort dieselbe Regel, weil ein am Netzwerkrand des Anbieters blockiertes Paket ufw nie erreicht. Diese Regel ist eine Erleichterung, keine Voraussetzung. Wenn der Port geschlossen bleibt, tritt der VPS weiterhin dem Tailnet bei, und die Peers können ihn weiterhin erreichen. Einige verwenden dabei ein Relay statt einer direkten Verbindung.

Von außerhalb auf ein Heim-NAS oder einen Raspberry Pi zugreifen

Fall eins ist der einfachste. Damit ist meist „Portweiterleitung mit Tailscale“ gemeint: Sie greifen von einem Laptop oder Smartphone, das sich nicht zu Hause befindet, auf ein Gerät in Ihrem Heimnetz zu.

Installieren Sie den Client auf dem Gerät zu Hause und auf dem Laptop. Damit ist die Einrichtung abgeschlossen. Das NAS oder der Pi ist jetzt über seine Tailnet-Adresse für jeden Dienst erreichbar, der auf allen Schnittstellen lauscht. Eine Weiterleitung ist nicht erforderlich. Ein Dienst, der nur an 127.0.0.1 oder an die LAN-Adresse gebunden ist, bleibt im Tailnet unsichtbar, bis Sie seine Bind-Adresse ändern.

ssh pi@100.101.102.103
curl -I http://100.101.102.103:8080/

Ersetzen Sie die Adresse durch die Ausgabe von tailscale ip -4 auf dem Gerät zu Hause. Die SSH-Anmeldung sollte sich genauso verhalten wie im heimischen WLAN. curl -I sollte die HTTP-Statuszeile der Webanwendung ausgeben, die auf dem Gerät läuft. Da die Verbindung durch WireGuard-Schlüssel authentifiziert wird, die an ein angemeldetes Gerät gebunden sind, ist ein Dienst, der an einem weitergeleiteten Port gefährlich wäre, hier vertretbar. Dazu zählen beispielsweise eine SMB-Freigabe (Server Message Block) oder ein Webadministrationsbereich. Nur Ihre eigenen Geräte können überhaupt ein Paket an diesen Dienst senden. Der dazwischengeschaltete ipTIME- oder Fritz!Box-Router sieht keine eingehende Verbindung und muss nicht geändert werden. Wenn Ihr ISP Sie hinter CGNAT platziert hat, funktioniert dies trotzdem. Das Gerät zu Hause baut ausschließlich ausgehende Verbindungen auf. Im ungünstigsten Fall wird die Verbindung über einen Relay-Server hergestellt.

MagicDNS, das in neuen Tailnets standardmäßig aktiviert ist, weist jedem Knoten außerdem einen Namen zu. Daher funktioniert ssh pi@nas, sobald sich der Laptop im Tailnet befindet.

Wenn das Gerät Tailscale nicht ausführen kann: ein Subnet-Router

Einige Geräte können den Client nicht ausführen: ein Drucker, eine IP-Kamera, ein älteres NAS mit einem eingeschränkten Betriebssystem oder ein Smart-TV. Ein Subnet-Router löst dieses Problem. Ein Gerät im Heimnetz, auf dem Tailscale ausgeführt werden kann (ein Pi reicht aus), gibt das gesamte Heimnetz-Subnetz bekannt. Andere Geräte im Tailnet leiten den Datenverkehr zu diesem Subnetz über dieses Gerät.

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl --system
sudo tailscale up --advertise-routes=192.168.0.0/24

Verwenden Sie Ihr tatsächliches Heimnetz-Subnetz. Die Route muss anschließend in der Admin-Konsole unter den Route-Einstellungen des Geräts genehmigt werden. Linux-Clients müssen sie mit sudo tailscale set --accept-routes aktivieren. Danach erreicht ping 192.168.0.50 vom Laptop die Kamera zu Hause. Das Forwarding-sysctl ist wichtig. Ohne diese Einstellung verwirft der Pi jedes Paket, das nicht an ihn selbst adressiert ist. Die Route wird dann zwar als genehmigt angezeigt, aber kein Gerät dahinter antwortet. Den Genehmigungsschritt, die clientseitige Aktivierung und weitere Ursachen dafür, dass eine Route zwar genehmigt, aber nicht erreichbar ist, finden Sie unter einen Tailscale-Subnet-Router einrichten. Dort wird ein VPS als Router verwendet. Die Vorgehensweise gilt jedoch unverändert für einen Pi im Wohnzimmer.

Freunden den Beitritt zu einem Minecraft-Server ermöglichen, ohne den Router zu öffnen

Fall zwei: Ein Minecraft-Server läuft auf einem PC zu Hause, und Freunde möchten beitreten. Die herkömmliche Lösung besteht darin, TCP 25565 auf dem Router weiterzuleiten und die öffentliche IP-Adresse weiterzugeben. Damit wird sie jedoch auch jedem Scanner im Internet zugänglich. Tailscale ersetzt diese Weiterleitung durch Freigaben.

Es gibt zwei Möglichkeiten. Die erste besteht darin, die Freunde als Benutzer in Ihr Tailnet einzuladen. Das funktioniert, aber Benutzerplätze im kostenlosen Tarif sind begrenzt. Außerdem kann ein eingeladener Benutzer standardmäßig jedes Gerät in Ihrem Tailnet erreichen. Für ein Spiel ist das mehr als nötig, sofern Sie den Zugriff nicht mit Zugriffsregeln einschränken. Die zweite und einfachere Möglichkeit ist die Freigabe eines Geräts. Öffnen Sie in der Admin-Konsole die Seite Machines, suchen Sie den Gaming-PC, öffnen Sie dessen Menü und wählen Sie Share. Tailscale erstellt einen Einladungslink. Jeder Freund benötigt ein eigenes kostenloses Tailscale-Konto. Damit wird er zum Besitzer eines eigenen kleinen Tailnets und kann den Link mit diesem Konto akzeptieren. Das freigegebene Gerät erscheint anschließend in seiner Geräteliste, und zwar nur dieses Gerät. Eine Freigabe gewährt dem Empfänger Zugriff auf das freigegebene Gerät und auf nichts anderes in Ihrem Tailnet. Ein freigegebenes Gerät ist standardmäßig isoliert: Es kann Verbindungen aus dem Tailnet des Freundes beantworten, aber selbst keine Verbindungen initiieren.

Die Freunde fügen den Server in Minecraft über seine Tailnet-Adresse, 100.101.102.103:25565, hinzu. Wenn der Standardport verwendet wird, genügt die Adresse allein. Auf dem Gaming-PC müssen keine Ports weitergeleitet werden, und am Router sind keine Änderungen erforderlich. Freigegebene Geräte kündigen keine Subnet-Routen an. Die Freigabe funktioniert daher für einen Dienst, der direkt auf dem freigegebenen Gerät läuft. Genau das trifft auf den Game-Server zu.

Die Einschränkung besteht darin, dass jeder Spieler Tailscale ausführen und die Freigabe akzeptieren muss. Für eine Gruppe von Freunden ist das unproblematisch. Für einen öffentlichen Server, dem jeder beitreten kann, ist es nicht geeignet. Die nächsten beiden Abschnitte behandeln diesen Fall.

Den Gameserver auf einem VPS ausführen und RCON im Tailnet halten

Eine andere Möglichkeit, Portweiterleitungen zu vermeiden, besteht darin, das Spiel nicht zu Hause zu hosten. Ein VPS verfügt über eine öffentliche IP-Adresse, die ihn direkt erreicht. Der Spieleport kann daher öffentlich erreichbar sein, ohne dass ein Router zu Hause beteiligt ist. Einen Minecraft-Server auf einem VPS betreiben behandelt die Dimensionierung, die Java-Flags, Backups und die systemd-Unit. Entscheidend ist hier, welche Ports aus dem Internet erreichbar sind.

Ein Minecraft-Server öffnet zwei Ports. TCP 25565 ist der Spieleport, den die Spieler benötigen. TCP 25575 ist RCON (Remote Console). Dieser Port akzeptiert ein Passwort und führt anschließend beliebige Serverbefehle aus, darunter op und stop. Ein aus dem Internet erreichbarer RCON-Port ist ein Ziel für Passwortversuche. Binden Sie den VPS in Ihr Tailnet ein und verwenden Sie für die beiden Ports unterschiedliche Regeln:

sudo ufw allow OpenSSH
sudo ufw allow 25565/tcp
sudo ufw allow in on tailscale0 to any port 25575 proto tcp
sudo ufw enable
sudo ufw status

Die zweite Regel macht den Spieleport für alle erreichbar. Die dritte Regel erlaubt RCON nur für Pakete, die über das Interface tailscale0 eingehen. Damit ist RCON nur von Geräten in Ihrem Tailnet sowie von Personen erreichbar, mit denen Sie den VPS geteilt haben. Wenn Sie den VPS teilen, verwenden Sie Zugriffsregeln in Ihrer Tailnet-Richtlinie, um geteilten Benutzern den Zugriff auf Port 25575 zu verwehren. Die Interface-Regel allein kann diese Benutzer nicht von Ihren eigenen Geräten unterscheiden. Die öffentliche IP-Adresse antwortet weiterhin auf 25565. Eine Verbindung zu 25575 von der öffentlichen Seite wird von der standardmäßigen deny-Regel von ufw verworfen. Prüfen Sie beides von Ihrem Laptop aus, der sich im Tailnet befindet:

nc -zv 100.101.102.103 25575
nc -zv <vps-public-ip> 25575

Der erste Befehl sollte succeeded ausgeben. Der zweite Befehl sollte hängen bleiben und anschließend wegen eines Timeouts abbrechen. Das Paket ist über das öffentliche Interface eingegangen und hat keine allow-Regel gefunden. Dasselbe Muster gilt für SSH, eine Webkarte, eine Datenbank oder ein Monitoring-Dashboard: Der öffentliche Port wird auf der öffentlichen IP-Adresse veröffentlicht, administrative Ports bleiben ausschließlich auf tailscale0 erreichbar.

Etwas dem gesamten Internet bereitstellen: Funnel oder ein Reverse-Tunnel über einen VPS

Fall drei lässt sich mit Tailscale allein nicht lösen. Ein Blog, eine öffentliche API, ein öffentlicher Gameserver oder eine Statusseite: Die Besucher befinden sich nicht in Ihrem Tailnet und werden es auch nie sein. Dafür gibt es zwei Möglichkeiten. Jede davon wird in einem eigenen Beitrag behandelt.

Tailscale Funnel veröffentlicht einen HTTPS-Dienst eines Knotens über die Tailscale-Relays im öffentlichen Internet. Der Dienst funktioniert ausschließlich über TLS (Transport Layer Security) und nur auf den Ports 443, 8443 und 10000. Damit eignet er sich für eine Webanwendung, aber nicht für ein unverschlüsseltes Spieleprotokoll auf Port 25565. Tailscale Serve im Vergleich zu Funnel erklärt, was die beiden Varianten jeweils veröffentlichen und für wen.

Ein Reverse-Tunnel über einen VPS deckt alle anderen Fälle ab. Der Rechner zu Hause baut einen ausgehenden Tunnel zu einem VPS mit öffentlicher IP-Adresse auf. Der VPS leitet einen öffentlichen Port über diesen Tunnel zurück zum Heimrechner weiter, per TCP oder UDP und mit einer beliebigen Portnummer. Das ist das passende Werkzeug für einen öffentlichen Minecraft-Server, der zu Hause hinter CGNAT betrieben wird. Ein Reverse-Tunnel über einen VPS für einen Heimserver hinter CGNAT beschreibt die Einrichtung Schritt für Schritt. Wählen Sie eine dieser beiden Varianten. Suchen Sie nicht weiter nach einer Tailscale-Einstellung, die einen Port für das gesamte Internet öffnet. Eine solche Einstellung gibt es nicht.

Was Tailscale nicht leistet

• Tailscale leitet keinen Port für beliebige öffentliche Clients weiter. Ein Paket von außerhalb des Tailnets erreicht Ihren Node nicht, weil dafür kein WireGuard-Schlüssel vorhanden ist. Ein WireGuard-Paket ohne gültigen Schlüssel wird ohne Antwort verworfen.
• Tailscale bietet der Öffentlichkeit keinen Zugang. Benutzer müssen Mitglied Ihres Tailnets sein oder einen freigegebenen Node akzeptiert haben.
• Tailscale garantiert keinen direkten Pfad. Bei schwierigen NAT-Bedingungen wird die Verbindung über einen Relay-Server geleitet. Das ist langsamer.
• Tailscale öffnet den Router nicht. Der Router bleibt geschlossen. Genau das ist der Zweck.

FAQ

Benötigt Tailscale eine Portweiterleitung?

Nein. Jeder Tailscale-Knoten baut ausschließlich ausgehende Verbindungen auf. Er erreicht den Koordinationsserver über TCP 80 und wechselt auf HTTPS über TCP 443, wenn Port 80 nicht antwortet. Seine öffentliche Adresse ermittelt er mit STUN über UDP 3478. Jede Peer-Verbindung wird zunächst über DERP über TCP 443 weitergeleitet. Dieser Datenverkehr ist weiterhin ausgehend. Anschließend wird die Verbindung per UDP Hole Punching von Port 41641 auf einen direkten Pfad umgestellt. Wenn das Hole Punching fehlschlägt, wird der Datenverkehr an ein Peer-Relay weitergeleitet, sofern Sie eines konfiguriert haben. Andernfalls bleibt er bei DERP. Ein Heimrouter benötigt daher weder eine weitergeleitete Portzuordnung noch einen DMZ-Host. Auch ein Gerät hinter CGNAT tritt auf dieselbe Weise bei.

Kann Tailscale eine Portweiterleitung für einen Minecraft-Server ersetzen?

Ja, wenn Ihre Freunde dem Server beitreten. Installieren Sie Tailscale auf dem Spiele-PC. Teilen Sie diesen Computer auf der Seite „Machines“ der Administratorkonsole mit jedem Freund. Die Freunde verbinden sich dann ohne weitergeleiteten Port über die Tailnet-Adresse des Computers mit Port 25565. Für einen öffentlichen Server ersetzt Tailscale keine Portweiterleitung, weil Spieler außerhalb Ihres Tailnets den Knoten nicht erreichen können. Hosten Sie das Spiel in diesem Fall auf einem VPS mit öffentlicher IP-Adresse. Lassen Sie RCON im Tailnet. Alternativ können Sie einen Reverse-Tunnel von der Heimmaschine zu einem VPS verwenden.

Welche Ports verwendet Tailscale?

Vier. TCP 80 ausgehend ist die bevorzugte Verbindung zum Koordinationsserver. Sie wird über Tailscales eigenen verschlüsselten Transport übertragen. TCP 443 ausgehend ist der Fallback für diese Verbindung, wenn Port 80 nicht antwortet. Dieser Port überträgt außerdem immer den DERP-Relay-Datenverkehr. UDP 3478 ausgehend wird für STUN verwendet. Damit wird die öffentliche Adresse ermittelt. UDP 41641 ist der lokale WireGuard-Standardport für direkte Verbindungen. Pakete verlassen den Knoten über diesen Port und werden an den Port gesendet, den die Peer-Seite verwendet. Der Port kann geändert werden, wenn 41641 bereits belegt ist. Keiner dieser Ports muss eingehend geöffnet werden. Das Blockieren von TCP 80 ist unproblematisch, weil der Client auf 443 ausweicht. Das eingehende Zulassen von UDP 41641 auf einem VPS ist optional. Dadurch erhalten Peers häufiger einen direkten Pfad.

Warum wird meine Tailscale-Verbindung weitergeleitet statt direkt aufgebaut?

tailscale ping antwortet weiterhin über via DERP, wenn das UDP Hole Punching nicht abgeschlossen werden kann. Häufige Ursachen sind ein NAT, das das Hole Punching nicht passieren lässt, beispielsweise CGNAT oder ein symmetrisches NAT, das für jedes Ziel einen neuen Port vergibt, sowie eine Firewall, die ausgehendes UDP blockiert. Beheben Sie die kontrollierbaren Ursachen: Lassen Sie ausgehendes UDP von Port 41641 zu jedem Zielport zu. Erlauben Sie ausgehendes UDP zu Port 3478. Oder platzieren Sie einen Peer auf einem VPS, auf dem eingehendes UDP 41641 geöffnet ist. Dadurch erhält das Hole Punching der anderen Seite ein festes, erreichbares Ziel. Ein Peer, dessen eigenes Netzwerk UDP blockiert, bleibt in jedem Fall weitergeleitet.