En ZimaOS-användare trodde att Tailscale hade slutat fungera efter den första starten eftersom appsidan visade ”tjänsten är inte tillgänglig” och en telefon inte kunde nå tjänster på hemmaservern. Containerdiagnostiken visade ett annat resultat: Tailscale körde, enheten var auktoriserad och tillstånds- och tunnelmonteringarna fanns på plats.
Det bekräftade problemet var adressen som användes från telefonen. Användaren försökte nå en vanlig hemnätverksadress utan att ha konfigurerat subnätöverföring. Anslutning till tjänsten via ZimaOS-enhetens Tailscale 100.x.x.x adressen fungerade.
Tailscale-containern hade inte kraschat
Det ursprungliga symtomet tydde på att containern hade stoppats efter en omstart, men det insamlade tillståndet visade:
- Containerns status var körande med avslutningskod 0.
- Tailscale gick från Starting till Running.
- Maskinen var auktoriserad i användarens tailnet.
- Den beständiga tillståndskatalogen var mappad till containern.
- TUN-enheten som Tailscale kräver var också mappad.
- Enheten fick en Tailscale-IPv4-adress och kunde se peer-enheter.
Dessa uppgifter skilde ett meddelande från en ZimaOS-appsida eller ett webbgränssnitt från själva Tailscale-daemonens status.
Varför de första diagnostikförsöken visade ”Permission denied”
Terminalsessionen använde en vanlig ZimaOS-användare. Den första Docker-listningen kördes med förhöjda behörigheter, men senare kommandon försökte komma åt Docker-socketen utan sådana och returnerade därför behörighetsfel. Böjda citattecken som kopierats från forumet hindrade också vissa kommandosubstitutioner från att tolkas korrekt.
Dessa behörighetsmeddelanden beskrev diagnostiksessionen, inte ett driftfel i Tailscale. Den senare utdata som hämtades med rätt behörigheter visade att containern fungerade korrekt.
En hemnätverksadress är inte automatiskt en Tailscale-adress
En adress som 10.0.0.93 tillhör hemnätverket. En telefon som är fjärransluten till samma tailnet får inte automatiskt en rutt till varje privat LAN-adress.
Tailscale tilldelar varje nod en egen adress, vanligtvis i intervallet 100.x.x.x. Tailscales officiella dokumentation om IP-adresser förklarar att dessa adresser identifierar enheter i tailnet och förblir separata från vanlig LAN-adressering.
Anslutningsmetoden som fungerade
Svarande bad användaren att ansluta till programmet med ZimaOS-nodens Tailscale-IP-adress och programmets egen port:
http://TAILSCALE-IP:APP-PORTTill exempel en tjänst på port 8096 skulle använda en URL i följande format:
http://100.x.x.x:8096Telefonen måste också vara inloggad på samma tailnet och aktivt ansluten till Tailscale. Användaren bekräftade att den här adressen fungerade, vilket visade att Tailscale i sig fungerade.
När subnätöverföring krävs
Om målet är att nå enheter via deras befintliga LAN-adresser – till exempel 10.0.0.x—en enhet i det nätverket måste annonsera LAN-subnätet som en rutt, och rutten måste godkännas enligt tailnet-konfigurationen.
Detta är en annan konfiguration än att nå ZimaOS-värden direkt via dess egen Tailscale-IP-adress. Följ Tailscales officiella dokumentation om subnätsroutrar innan du förväntar dig att vanliga LAN-adresser ska fungera på distans.
Varför appsidan fortfarande kunde visa ”Tjänsten är inte tillgänglig”
En tillgänglighetskontroll i webbgränssnittet kan misslyckas även när nätverksdaemonen körs. I källfallet var den avgörande bevisningen att den körde, att tailnet-auktoriseringen lyckades, att en Tailscale-IP-adress hade tilldelats, att peers syntes och att en fjärranslutning till tjänsten fungerade.
Att ändra slumpmässiga appportar, ta bort Tailscale-tillståndet eller upprepade gånger installera om containern skulle inte åtgärda en felaktig destinationsadress. Kontrollera daemonens status och anslutningsmetoden innan du återställer en fungerande identitet.
Varför den fungerande anslutningen kunde upplevas som långsam
Det slutliga svaret föreslog att anslutningen kan använda ett DERP-relä i stället för en direkt peer-to-peer-anslutning. Vidarebefordrad Tailscale-trafik kan fungera korrekt men ändå ge lägre genomströmning eller högre fördröjning, beroende på nätverken, routrarna och den tillgängliga reläregionen.
Långsamhet i sig bevisar inte att containern fungerar fel. Bekräfta först om anslutningen fungerar och om Tailscale rapporterar en direkt eller vidarebefordrad anslutning. Undersök sedan NAT- och brandväggsbeteende om prestandan är viktig.
En säkrare felsökningsordning
- Kontrollera om Tailscale-containern körs i stället för att enbart förlita dig på statusen på appsidan.
- Bekräfta att ZimaOS-noden visas som auktoriserad och online i samma tailnet som telefonen.
- Identifiera ZimaOS-nodens Tailscale
100.x.x.xadress via Tailscale-gränssnittet eller administratörskonsolen. - Anslut till måltjänsten med den Tailscale-adressen och tjänstens port.
- Konfigurera subnätsroutning endast om åtkomst via vanliga LAN-adresser i hemnätverket krävs.
- Undersök användningen av DERP-relä separat om anslutningen fungerar men är långsam.
Vanliga frågor om Tailscale-anslutning i ZimaOS
Bevisar ”tjänsten är inte tillgänglig” att Tailscale har stoppats?
Nej. I det här fallet kördes containern, var auktoriserad och ansluten, även om appsidan visade det meddelandet.
Varför hjälpte det inte att ändra Tailscale-appens port?
Problemet var destinationsadressen, inte en vanlig portkonflikt för webbappen. Användaren behövde nodens Tailscale-IP-adress.
Vilken adress ska en fjärrtelefon använda?
Använd ZimaOS-nodens Tailscale 100.x.x.x adress plus applikationsporten, såvida inte en subnätsrouter har konfigurerats för LAN-adresser.
Varför fungerar inte en 10.0.0.x-adress via Tailscale?
Det är en privat adress i hemnätverket. För att nå det subnätet på distans krävs en annonserad och godkänd subnätsrutt.
Varför kan en fungerande Tailscale-anslutning vara långsam?
Anslutningen kan vidarebefordras via DERP i stället för att använda en direkt peer-to-peer-anslutning.
