https://tailscale.com/docs/reference/faq/firewall-ports listet noch ein paar andere Sachen.
Wichtig ist, dass die Netcup-Firewall für UDP stateless ist. Du musst immer darauf achten, dass beide Richtungen durch die Firewall kommen. Das kann durch die automatische Regel sein, wenn es keine anderen Regeln für die selbe Richtung gibt, oder du musst eigene Regeln definieren. Anders als bei den Firewalls, mit denen die meisten Nutzer sonst zu tun haben, kommen Antworten auf erlaubte Pakete nicht automatisch durch, nur weil sie zur selben "Verbindung" gehören.
Da Tailscale für die Hauptfunktion und wichtige Nebenfunktionen UDP verwendet, wäre das der erste Instinkt. Wie sehen denn deine Default-Regeln aus?
Da du keine ausgehenden Regeln hast, steht die implizite Regel auf "accept", und das sollte alles für Tailscale abdecken, außer der einen eingehenden Regel, die du erstellt hast. Funktioniert es, wenn du die Netcup-Firewall komplett abschaltest? Hast du auf dem Host noch eine Firewall laufen, z.B. ufw?
Evtl. gibt es da noch Portmappings, so dass die Portnummer nicht passt. Ich würde mir den Datenverkehr mit tcpdump anschauen, wenn die Firewall aus ist. Dann siehst du, was durchkommen muss, und kannst die Firewall entsprechend anpassen.
Wenn Du Peer-To-Peer kommunizieren willst, brauchst Du m. E. noch eine weitere Regel für UDP mit Src Port 41641 und Dst Port beliebig, Richtung "eingehend".
Wenn Du Peer-To-Peer kommunizieren willst, brauchst Du m. E. noch eine weitere Regel für UDP mit Src Port 41641 und Dst Port beliebig.
Hab ich auch schon probiert, funktioniert aber damit auch nicht.
Ich habe in #8 noch die Richtung ergänzt.
Hier wird noch von Port 3478 gesprochen: https://tailscale.com/docs/reference/faq/firewall-ports - aber persönlich habe ich Tailscale nicht im Einsatz.
Vielleicht kannst Du mal TBT dazu fragen, der hat das ja wohl selbst in Benutzung: RE: Ab sofort: Firewall für netcup vServer verfügbar
TBT : WIe hast Du es denn gelöst? Es muss mit der NC Firewall zusammenhängen, sobald ich diese deaktiviere sind direct Verbindungen möglich. Tailscale läuft auf docker.
Damit hast Du doch Dein Problem schon. Tailscale gehört auf den Host, nicht in einen Docker Container. Bei mir ist TS auf dem Host und 41641 UDP incoming reicht für direkte Verbindungen. Nebenbei kann es übrigens auch immer an beiden Seiten liegen, wenn ein "direct" nicht geht, also die andere Seite auch prüfen.
Parallel zu der normalen TS Konfig habe ich zwei (für die Redundanz) meiner Netcup Server als https://tailscale.com/docs/features/peer-relay mit offenem Port 40000 konfiguriert. Dann hat man - selbst wenn es keine "direct" Verbindung gibt die eigenen schnellen Server als Relay und nicht Tailscales ultralangsame Relay Server. Auch praktisch für schwierige andere Verbindungen im eigenen Tailnet.
Kann auch noch nen Screenshot der Policies machen, geht aber grade wegen SCP Wartung nicht.
Meine Standard-Tailscale Policy (in den Policies erstellt, allen Servern zugewiesen):
| 1 | tailscale 41641 UDP | EINGEHEND | UDP | ACCEPT | beliebig | beliebig | beliebig | 41641 | |
| 2 | tailscale 3478 UDP (STUN) | EINGEHEND | UDP | ACCEPT | beliebig | 3478 | beliebig | 3278-60999 |
Regel 2 aufgrund der DERP Server : https://tailscale.com/docs/reference/faq/firewall-ports (unten). Diese ist nicht unbedingt nötig, hilft aber beim Anzeigen.
Relay Server:
| 1 | 40000 UDP eingehend | EINGEHEND | UDP | ACCEPT | beliebig | beliebig | beliebig | 40000 |
bei mir nur für die beiden Server die Relays sind.
Zudem muss TS auf diesen Servern entsprechend konfiguriert sein: https://tailscale.com/docs/features/peer-relay in Kombination mit https://tailscale.com/docs/reference/derp-servers und es muss eine Policy eingerichtet sein, die es allen Geräten erlaubt, diese Peer Relay Server zu verwenden.
Allerdings ist deine Aussage, dass Tailscale nicht als Docker laufen soll falsch.
Die Pauschalität dieser Aussage ist gleichfalls falsch. TS "kann" sicherlich als Container arbeiten, hat aber dann massive Nachteile:
Wenn man Tailscale in einen Container mit eigenem Subnetz einsperrt statt es auf dem Host laufen zu lassen, kauft man sich den ganzen Rattenschwanz hinsichtlich Docker Networking und Firewall Handling ein. Ich nutze TS um meine Server (auf denen nur Docker Container laufen) zu warten. Dazu zählt häufig, dass Container oder Docker selbst neu gestartet werden müssen. Wenn TS in einem Container läuft, schneidet man sich bei solchen Neustarts selbst von der Möglichkeit ab, weiterhin mit dem Rechner per SSH verbunden zu sein. Wenn Docker oder der TS Container ein Problem hat, stehst Du vor der Türe und musst die NC Firewall aufmachen.
Ich containerisiere praktisch alles was bei mir läuft. Immer und überall. Aber es gibt sehr gute Gründe für TS als Netzwerktool NICHT in einem Container zu laufen.
