Een ZimaOS-gebruiker dacht dat Tailscale na de eerste start was uitgevallen, omdat op de app-pagina ‘service unavailable’ werd weergegeven en een telefoon geen verbinding kon maken met services op de homeserver. Containerdiagnostiek liet een ander beeld zien: Tailscale draaide, het apparaat was geautoriseerd en de status- en tunnelaankoppelingen waren aanwezig.
Het vastgestelde probleem was het adres dat vanaf de telefoon werd gebruikt. De gebruiker probeerde een normaal thuis-LAN-adres te bereiken zonder subnetroutering te configureren. Verbinding maken met de service via het Tailscale-adres van het ZimaOS- 100.x.x.x het adres werkte.
De Tailscale-container was niet defect
Het eerste symptoom suggereerde dat de container na een herstart was gestopt, maar de verzamelde status liet het volgende zien:
- De containerstatus was running met exitcode 0.
- Tailscale ging van Starting naar Running.
- De machine was geautoriseerd in het tailnet van de gebruiker.
- De permanente statusmap was aan de container gekoppeld.
- Het voor Tailscale vereiste TUN-apparaat was ook gekoppeld.
- Het apparaat had een Tailscale IPv4-adres ontvangen en kon peers zien.
Dit bewijs maakte onderscheid tussen een melding op de ZimaOS-app-pagina of webinterface en de status van de Tailscale-daemon zelf.
Waarom de eerste diagnostische pogingen ‘Permission denied’ lieten zien
De terminalsessie gebruikte een normale ZimaOS-gebruiker. De eerste Docker-lijst werd met verhoogde rechten uitgevoerd, maar latere opdrachten probeerden zonder die rechten toegang te krijgen tot de Docker-socket en gaven daarom toestemmingsfouten. Gebogen aanhalingstekens die van het forum waren gekopieerd, verhinderden bovendien dat sommige opdrachtvervangingen correct werden geïnterpreteerd.
Die toestemmingsmeldingen hadden betrekking op de diagnostische sessie, niet op een runtimefout van Tailscale. De latere uitvoer, verkregen met de juiste rechten, liet zien dat de container gezond was.
Een thuis-LAN-adres is niet automatisch een Tailscale-adres
Een adres zoals 10.0.0.93 behoort tot het thuis-LAN. Een telefoon die op afstand met hetzelfde tailnet is verbonden, krijgt niet automatisch een route naar elk privé-LAN-adres.
Tailscale wijst elke node een eigen adres toe, meestal in het bereik 100.x.x.x. In de officiële documentatie over IP-adressen van Tailscale wordt uitgelegd dat deze adressen apparaten binnen het tailnet identificeren en losstaan van gewone LAN-adressering.
De verbindingsmethode die werkte
De beantwoorder vroeg de gebruiker om verbinding te maken met de toepassing via het Tailscale-IP-adres van de ZimaOS-node en de eigen poort van de toepassing:
http://TAILSCALE-IP:APP-PORTBijvoorbeeld een service op poort 8096 zou een URL in deze vorm gebruiken:
http://100.x.x.x:8096De telefoon moet ook bij dezelfde tailnet zijn aangemeld en actief met Tailscale verbonden zijn. De gebruiker bevestigde dat dit adres werkte, waarmee was vastgesteld dat Tailscale zelf functioneerde.
Wanneer subnetroutering vereist is
Als het doel is om apparaten te bereiken via hun bestaande LAN-adressen, zoals 10.0.0.x—een apparaat in dat netwerk moet het LAN-subnet als route adverteren en de route moet worden goedgekeurd volgens de tailnetconfiguratie.
Dit is een andere configuratie dan rechtstreeks verbinding maken met de ZimaOS-host via diens eigen Tailscale-IP. Volg de officiële documentatie over subnetrouters van Tailscale voordat je verwacht dat normale LAN-adressen op afstand werken.
Waarom op de app-pagina toch ‘Service niet beschikbaar’ kon staan
Een beschikbaarheidscontrole van de webinterface kan mislukken terwijl de netwerkdaemon actief is. In het brongeval waren de doorslaggevende aanwijzingen de actieve status, succesvolle tailnet-autorisatie, het toegewezen Tailscale-IP-adres, zichtbare peers en een werkende externe serviceverbinding.
Het willekeurig wijzigen van applicatiepoorten, het verwijderen van de Tailscale-status of het herhaaldelijk opnieuw installeren van de container zou een onjuist bestemmingsadres niet oplossen. Controleer de gezondheid van de daemon en de verbindingsmethode voordat je een werkende identiteit reset.
Waarom de werkende verbinding traag kon aanvoelen
Het uiteindelijke antwoord suggereerde dat de verbinding mogelijk een DERP-relay gebruikte in plaats van een directe peer-to-peerverbinding. Doorgestuurd Tailscale-verkeer kan correct werken en toch een lagere doorvoer of hogere latentie opleveren, afhankelijk van de netwerken, routers en beschikbare relayregio.
Alleen traagheid bewijst niet dat de container defect is. Controleer eerst of de verbinding werkt en of Tailscale een directe of doorgestuurde verbinding meldt. Onderzoek daarna NAT- en firewallgedrag als prestaties belangrijk zijn.
Een veiligere volgorde voor diagnose
- Controleer of de Tailscale-container actief is, in plaats van alleen af te gaan op de status op de app-pagina.
- Controleer of de ZimaOS-node als geautoriseerd en online wordt weergegeven in dezelfde tailnet als de telefoon.
- Identificeer het Tailscale
100.x.x.xadres via de Tailscale-interface of de beheerdersconsole. - Maak verbinding met de doelservice via dat Tailscale-adres en de servicepoort.
- Configureer subnetrouting alleen als toegang via normale thuis-LAN-adressen vereist is.
- Onderzoek het gebruik van een DERP-relay afzonderlijk als de verbinding werkt maar traag is.
Veelgestelde vragen over Tailscale-verbindingen in ZimaOS
Bewijst ‘service niet beschikbaar’ dat Tailscale is gestopt?
Nee. In dit geval draaide de container, was deze geautoriseerd en verbonden, ook al gaf de app-pagina die melding weer.
Waarom hielp het wijzigen van de applicatiepoort van Tailscale niet?
Het probleem was het bestemmingsadres, niet een normaal conflict met de poort van een webapp. De gebruiker had het Tailscale-IP-adres van de node nodig.
Welk adres moet een telefoon op afstand gebruiken?
Gebruik de Tailscale 100.x.x.x adres plus de applicatiepoort, tenzij er een subnetrouter is geconfigureerd voor LAN-adressen.
Waarom werkt een 10.0.0.x-adres niet via Tailscale?
Het is een privé-LAN-adres. Om dat subnet op afstand te bereiken, is een geadverteerde en goedgekeurde subnetroute vereist.
Waarom kan een werkende Tailscale-verbinding traag zijn?
De verbinding kan via DERP worden doorgestuurd in plaats van een directe peer-to-peerverbinding te gebruiken.
