Moderatoren: jmaus, Co-Administratoren
Das passiert auch ohne den Parameter. Es wird immer der aktuelle Hostname beim Reboot gepublished. Kann weg.
Kaum weiß man wie es geht... geht's auch.
) 
Das ist nicht kompliziert, das ist eigentlich recht standard das man das so macht
Passiert ja mit dem /var/hm_mode file auch an verschiedensten Stellen des Startups, btw.
Im nachhinein gesehen nicht, das stimmt. Hatte mich an den einfachen Sachen wie "CustomStoragePath" orientiert. Aber man lernt ja zum Glück nie aus.
Jup, bitte raus damit!Bleibt nur also nur der (in bestimmten Situationen problematische) "--accept-routes" Parameter der beim allerersten Aktivieren gesetzt wird. Der sollte m.E. raus. Kann man ja dann bei Bedarf immer noch selbst setzen.
Also nachdem ich mir die Dokumentation zur "--accept-routes" nochmal angeschaut habe bin ich mir ehrlich gesagt nicht ganz so sicher ob sie wirklich raus sollte. Wenn ich das richtig verstanden habe erlaubt diese eben prinzipiell zwei LANs hinter jeweils zwei Tailscale Systeme so miteinander zu verbinden das dazwischen geroutet wird. Und da man das erst in der Tailscale Konfiguration freischalten muss damit das passiert sollte die Option doch eigentlich unkritisch sein. Oder übersehe ich was?darkbrain85 hat geschrieben: ↑01.10.2021, 19:06Jup, bitte raus damit!Bleibt nur also nur der (in bestimmten Situationen problematische) "--accept-routes" Parameter der beim allerersten Aktivieren gesetzt wird. Der sollte m.E. raus. Kann man ja dann bei Bedarf immer noch selbst setzen.
)
!!! Ich habe mich auch schon gefragt ob ich was übersehe oder falsch mache.
Ich sehe das so, das "--accept-routes" die gepublishedten Routen anderer (eigener) Tailscale "Klienten" übernimmt, ohne irgendeine Freischaltung. Mein "Server" published die Route ins Heimnetz 192.168.1.0/24 und die ist im Portal auch aktiviert. Somit kann ich per Handy aus dem Mobilfunknetz auf alle meine Geräte im Heimnetz zugreifen. RM übernimmt die Route, aber sie ist noch nicht (im WebPortal) aktiviert. Und schwupps verliere ich den lokalen Zugriff, und dabei ist es egal ob auf dem PC der Tailscale Klient aktiv oder inaktiv ist. Der geht erst wieder wenn ich im Portal auch die gepublishedte Route von RM aktiviere und zusätzlich über den PC Klienten eingeloggt bin.
Na wenn du deinen zentralen server bereits dein internes Heimnetz durchrouten lässt, dann brauchst du eigentlich doch keinerlei weiteres Gerät (auch nicht RaspberryMatic) in das Tailscale Netzwerk verbinden, denn dann solltest du doch auch ohne das RaspberryMatic sich mit Tailscale selbst verbunden hat auf RaspberryMatic (welches ja auch im 192.168.1.0/24 liegt) zugreifen können, oder?
Nein, ein Fehler wird das nicht sein, sondern das ergibt ja auch sinn. Denn wie gesagt solltest du in deinem Netzwerk immer nur ein einzelnes Gerät haben das sein gesamtes Subnetz nach aussen bekannt gibt und dann brauchst du doch keinerlei andere Geräte aus dem selbsten Subnetz mit Tailscale verbinden. Oder du schaltest das routing im WebInterface von Tailscale eben komplett für das 192.168.1.0/24 netz ab und verbindest dann jedes Gerät einzeln mit Tailscale.Baxxy hat geschrieben: ↑01.10.2021, 21:14Und schwupps verliere ich den lokalen Zugriff, und dabei ist es egal ob auf dem PC der Tailscale Klient aktiv oder inaktiv ist. Der geht erst wieder wenn ich im Portal auch die gepublishedte Route von RM aktiviere.
Vielleicht ist das auch ein Fehler in Tailscale, oder irgendwas in meinem Netzwerk.
Die anderen Optionen habe ich im Grunde "nur" hinzugefügt weil diese auch z.B. in der Tailscale-Umsetzung in HomeAssistant so standardmäßig gesetzt sind, sicherlich damit man seine HomeAssistant Zentrale so eben zum zentralen VPN Router seines Netzwerkes machen kann.
Da hast du natürlich recht. Irgendwie habe ich vor lauter "Test-Euphorie" den Fokus etwas aus den Augen verloren.
Ja, damit kann man sich prima auch selbst aussperren sollte schon ein anderer "Server" mit aktiver Route aktiv sein.