Tailscale VPN Support in kommender Version

[darkbrain85]

Ich musste gerade auch erst eine reboot machen, sonst führte ein Klick auf den Button nur zum reload der WebUI. Danach läuft es allerdings normal.

[jmaus]

Bitte mal mit dem nächsten kommenden nightly snapshot nochmal die Einrichtung, etc. probieren. Hab nun einiges nochmal hier+da optimiert und umgestellt und denke nun sollte das ganze noch runder gehen. Und auch das Problem mit dem Zugriff auf die Authentifizierungsseite im HA Addon habe ich nun korrigiert, sollte also gehen.

[darkbrain85]

Danke für Deine Mühe!

Ich teste seit gestern und bin schwer beeindruckt. Einfacher kann man kein VPN zwischen Geräten aufbauen.
Und vor allem ist es schnell. Cloudmatic ist teilweise ein bisschen träge, vor allem bis PocketHome die Verbindung aufgebaut hat.

Mit Tailscale geht das direkt und ohne jede Verzögerung. Ich bin sogar in Versuchung, mein bisheriges VPN über Unifi komplett damit zu ersetzen.
Den neuen Snapshot kann ich erst später testen, da ich ungern Remoteupdates mache.

[jmaus]

Cloudmatic ist teilweise ein bisschen träge, vor allem bis PocketHome die Verbindung aufgebaut hat.

Das ist nicht verwunderlich. CloudMatic setzt ja leider noch auf OpenVPN welches im Grunde als obsolete anzusehen ist heutzutage und dafür bekannt ist nicht mehr die schnellste/performanteste VPN Lösung zu sein. Dazu kommt noch, das man via CloudMatic ja eine direkte VPN Verbindung zum CloudMatic Anbieter aufbaut und damit diesem doch schon sehr vertrauen muss, da er prinzipiell aus seiner Infrastruktur heraus recht leicht auf alle CCUs zugreifen kann - wenn er es denn will oder wenn er gehackt wird. Hier hat Tailscale bzw. Wireguard den ganz klaren Vorteil nur direkte Point-to-Point Verbindungen aufzubauen zwischen den Geräten und damit wird keinerlei Nutzertraffic über irgendwelche Tailscale Server geleitet (was ja auch die Performance ziemlich in die Knie gehen lassen würde).

[Newbie-1]

Mit der Testversion von heute war eine Anmeldung für Talescale kein Problem.
Nur konnte ich mich nicht auf der WebUI anmelden.
Ist auch egal. Ich wollte das ganze nur testen, weil ich sowieso über die VPN der Fritzbox rein gehe.

[jmaus]

Mit der Testversion von heute war eine Anmeldung für Talescale kein Problem.
Nur konnte ich mich nicht auf der WebUI anmelden.
Ist auch egal.

Nein, ist nicht egal, denn dieser Beitrag existiert ja, damit ich Feedback bekomme und eventl. noch Fehler vor dem Release ausmerzen kann. Also bitte mehr Details was denn nicht ging? Das du auch einen Tailscale-Client auf deinem Rechner laufen lassen musst und ggf. die Firewall von RaspberryMatic noch um die 100.x.x.x adressen von Tailscale erweitern musst, ist dir aber bewusst oder?

[darkbrain85]

Das einzige was ich auf dem iPhone gerade feststelle, ist ein recht hoher Stromverbrauch wenn das VPN aktiv ist.
Ist das ein Zufall, oder kann das jemand bestätigen?

Hier wird auch darüber berichtet. Ist auch recht aktuell...

https://www.reddit.com/r/Tailscale/comm ... os_ipados/

Edit:
Ich habe zum experimentieren in meinem internen Netzwerk einen Tailscale Subnetz Router aktiviert.
Sobald ich in der Tailscale WebUI die Routing Funktion aktiviere, ist Raspberrymatic nicht mehr im LAN erreichbar. Ein anderer Debian Server allerdings schon, trotz installiertem Tailscale.

Ursache noch unbekannt

[Xel66]

CloudMatic setzt ja leider noch auf OpenVPN welches im Grunde als obsolete anzusehen ist heutzutage und dafür bekannt ist nicht mehr die schnellste/performanteste VPN Lösung zu sein.

Für einen Verbindungsaufbau von eigenen (mobilen) Geräten mag ein direktes VPN auch zielführend sein und nutze ich auch selbst so. Es gibt aber eben auch Szenarien, in denen diese Lösung kein adäquater Ersatz ist. Das ist zum Beispiel der Zugriff von einem Gerät, welches nicht unter vollständiger eigener Kontrolle steht und von anderer Seite administriert wird (das dürfte bei vielen Leuten der PC in der Firma oder das Diensttelefon sein). Hier kann und darf man häufig keine eigene VPN-Lösung einrichten. Inwieweit man solchen Rechnern vertrauen kann und muss, ist eine andere Sache. Ich bringe meinem Brötchengeber das dazu notwendige Vertrauen entgegen.

Nun muss man ja nicht ständig aus dem Unternehmen auf die eigene CCU zugreifen, aber auch ich habe gelegentlich eine Anwendung dafür. Glücklicherweise ist der Zugriff auf Cloudmatic nicht von den Administratoren gesperrt. Private sowie bekannte "gefährliche" und unbekannte Domains sind aber geblockt. Mit einer anderen (VPN-)Lösung hat man also keine Chance. Insofern würde ich z.B. solche Lösungen wie Cloudmatic (ja, denen muss man ja auch vertrauen) nicht von vornherein verteufeln oder als obsolet bezeichnen. Und auch für die Einbindung einer Smartspeaker-Steuerung kann diese VPN-Lösung relativ wenig tun. Die Welt ist eben nicht schwarz/weiß. Und mit welcher VPN-Lösung die CCU an solche Anbieter angebunden ist, ist letztendlich vernachlässigbar, da die Performance dieses VPN für die Ansteuerung einer CCU eher von untergeordneter Relevanz ist. Es sind weder große Datenmengen zu handlen noch kommt es auf Echtzeit an. Der Administrationsaufwand auf Anwenderseite ist gerade bei der mitgelieferten Cloudmatic-Lösung überschaubar.

Gruß Xel66

[Baxxy]

Ursache noch unbekannt

Dann werde ich mal Licht ins Dunkel bringen nachdem ich gestern vor dem gleichen Problem stand.
Zumindest schonmal gut das ich damit nicht alleine bin, dachte schon ich hätte meine Netzwerk nicht mehr im Griff.

Hier mal die Parameter die beim Start von Tailscale aktiviert werden:

Code: Alles auswählen

TAILSCALE_UP_ARGS="--hostname ${HOSTNAME} --advertise-exit-node --accept-routes --advertise-routes $(/sbin/ip route | grep -v default | awk '{ print $1 }' | xargs | tr ' ' ',')"

"Schuld" ist der Tailscale Startup Parameter "--accept-routes". Damit verliert man den Zugriff über die lokale IP-Adresse der RM wenn z.B. ein anderer "Tailscale-Server" (im selben Netz) die gleiche Route publiziert und diese im WebPortal auch aktiviert wurde.

Es geht wieder wenn man...

• die publizierte Route der RM im Webportal aktiviert (damit wird aber mein gesamtes Netz irgendwie "laggy", als ob die Daten über die Routen erstmal ne Extrarunde drehen)
• Tailscale auf der RM (Zugriff per ssh und Tailscale IP) mittels

  Code: Alles auswählen

  tailscale up --reset

  resettet. Damit werden auch alle anderen "nicht-default" Settings auf Standard gesetzt, RM ist dann einfach nur ein Client im Tailscale Netz. ...läuft.

Mein Workaround sieht aktuell wie folgt aus:
die /usr/local/etc/rc.prelocal anlegen, ausführbar machen und mit folgendem Inhalt füllen:

Code: Alles auswählen

#!/bin/sh
tailscale up --reset

@jmaus:

Code: Alles auswählen

--hostname ${HOSTNAME}

kann raus. Das ist ja zum overriden des Hostnamens gedacht der auch ohne diesen Parameter korrekt benutzt wird.

Code: Alles auswählen

--accept-routes

macht in bestimmten Konstellationen (siehe oben) Probleme, kann/sollte? raus.

Nochmal zu...

Und darüber hinaus kann man alle Standard Kommandozeilenparameter die im Startskript für die tailscale binaries verwendet werden überschreiben/ändern indem man einfach in der /etc/config/tailscaleEnabled Datei diese anders angibt.

Die "/etc/config/tailscaleEnabled" scheint mir dafür ungeeignet denn sie wird ja bei Aktivierung über die WebUI "leer" erzeugt. D.h. der erste Start von Tailscale wird immer mit den RM-default Parametern ausgeführt. Womit man sich dann unter obigen Umständen instant aussperrt. Die Parameter werden auch "gespeichert", um sie loszuwerden braucht es ein "tailscale up --reset".

Trage ich zum Test "--hostname baxxy-test" oder auch "--hostname=baxxy-test" in die "/etc/config/tailscaleEnabled" ein und reboote klappt das nicht und es wird folgender Fehler sichtbar:

Code: Alles auswählen

/etc/init.d/S46tailscaled: /etc/config/tailscaleEnabled: lin 1: --hostname=baxxy-test: not found

Um eigene Parameter zu nutzen habe ich testweise S46tailscaled erweitert:

Code: Alles auswählen

# check for external user startup parameters
[ -f /etc/config/tailscaleStartupArgs ] && TAILSCALE_UP_ARGS=$(cat /etc/config/tailscaleStartupArgs)

In meiner "/usr/local/etc/config/tailscaleStartupArgs" steht dann z.B. "--hostname baxxy-test" drin.
Damit klappt die Übergabe mit eigenen Parametern wunderbar, auch beim ersten Start.

Zusammengefasst:

• die aktuellen RM-default Startparameter für Tailscale sind suboptimal. "--hostname" kann und "--accept-routes" sollte raus
• der User-Override mittels /etc/config/tailscaleEnabled funktioniert (bei mir) nicht, oder ich mache was falsch
• die User-Override Parameter sollten in eine zusätzliche Kontroll-Datei ausgelagert werden

[jmaus]

Zusammengefasst:
- die aktuellen RM-default Startparameter für Tailscale sind suboptimal. "--hostname" kann und "--accept-routes" sollte raus

Kann ich gerne entfernen. Bisher bin ich allerdings davon ausgegangen, das gerade das setzen von hostname eben dazu führt das bei jedem neustart der aktuellen hostname dann übertragen wird. Denn im aktuellen init file habe ich deshalb ja extra ein explizites "tailscale up" mit den jeweiligen optionen hinzugefügt damit er das bei jedem start quasi aktualisiert. sollte eigentlich gehen.

- der User-Override mittels /etc/config/tailscaleEnabled funktioniert (bei mir) nicht, oder ich mache was falsch

Nun, du hast den Override ja auch nicht richtig gemacht. Da musst du schon die gesamten Variablen hinterlegen. Also sowas wie:

Code: Alles auswählen

TAILSCALE_UP_ARGS="--hostname blah"

Du kannst in der tailscaleEnabled Datei quasi alle shell variablen überschreiben die oberhalb des "." sourcen der Datei definiert sind. Du musst halt nur in der tailscaleEnabled Datei das immer ala VAR="abcd" schreiben, dann sollte das gehen.

- die User-Override Parameter sollten in eine zusätzliche Kontroll-Datei ausgelagert werden

Das ist ja der Charme an der Sache (wie oben beschrieben). Das man eben nur diese eine Datei dann braucht und darin zusätzlich optionen definieren kann wenn man es denn will. Und das ist ja ohnehin nur für Powernutzer. Die standardoptionen/args sollten schon so gesetzt werden das die auch für DAUs passen.