Eén Tailscale-host onbereikbaar: subnetrouter of exit-node?

De ene Tailscale-host antwoordt terwijl de andere donker blijft, of alles werkt totdat openbare websites het verkeerde land beginnen te melden. Beide klachten komen binnen als „Tailscale is kapot“, en beide zijn meestal de verkeerde constructie die voor de verkeerde bestemming is aangezet. Een subnetrouter stelt een privénetwerk beschikbaar aan het tailnet, terwijl een exit-node verandert waar internetverkeer naar buiten gaat. Sorteer eerst de bestemming die faalt en kies dan de rol die die bestemming dekt.

Begin bij de bestemming die is mislukt

Noteer het adres of de naam die niet werkte, en wat voor ding het is. Een apparaat op een privé-LAN achter een andere locatie, een dienst op je eigen segment en een openbare website zijn drie routeringsproblemen die toevallig één client delen. Het onderscheid is niet cosmetisch, want de twee constructies dekken verschillende sets bestemmingen. De ene aanzetten doet niets voor de andere, en dat is de hele bron van de verwarring.

Let ook op de adresfamilie. Een subnet dat alleen als IPv4 wordt aangekondigd, laat IPv6-bestemmingen op het lokale pad, wat als een gedeeltelijke storing leest tot iemand beide routeringstabellen vergelijkt. Noteer welk pad je verwachtte, zodat de test later iets heeft om tegen te spreken.

Bereik een apparaat dat nooit Tailscale draait

De router kondigt specifieke bereiken aan het tailnet aan en stuurt daarna pakketten tussen het tailnet en het privésegment door, zodat de apparaten op dat segment geen eigen client nodig hebben. Een NAS op kantoor bereiken vanaf een laptop thuis is precies dit geval. De router is het enige lid van het tailnet aan die kant.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

Aankondigen is slechts de eerste van drie voorwaarden. De route moet voor het tailnet worden goedgekeurd, de client moet aangekondigde routes accepteren, en een toegangsregel moet de verbinding toestaan. Die keten is de reden dat het symptoom zo vaak is dat de router draait en de NAS niet. Een bereikbare router bewijst dat de tunnel werkt; hij bewijst niets over goedkeuring, clientacceptatie of beleid.

Elk van die drie fouten ziet er in de beheerconsole anders uit. Controleer ze op volgorde in plaats van alle drie tegelijk te wijzigen, want een tweede wijziging verbergt welke ertoe deed.

Stuur openbaar verkeer via een andere machine naar buiten

Een exit-node routeert je algemene internetverkeer door zichzelf, wat het dichtst in de buurt komt van de volledige tunnelopstelling bij andere VPN-producten. Ook hij heeft drie afzonderlijke toestemmingen nodig: het apparaat kondigt de rol aan, een beheerder staat die toe, en de client selecteert hem. Lid worden van een tailnet stuurt standaard niets via een ander lid.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Een exit-node selecteren geeft niet automatisch toegang tot zijn eigen LAN. De LAN-toegangsoptie bestaat juist omdat dat verschillende rechten zijn, en hem uit laten staan is de veiligere standaard. Routes naar andere Tailscale-resources houden hun eigen afhandeling, ook terwijl een exit-node actief is. Daarom kan een dienst die op een subnet wordt gehost blijven werken terwijl het openbare internetpad is veranderd.

Een exit-node verandert ook hoe het internet jou ziet, niet alleen hoe snel het aanvoelt. Verwacht dat geolocatie, streamingcatalogi en snelheidslimieten het adres van de exit volgen en niet het jouwe.

Lees de driesplitsing wanneer maar één host faalt

Een printer op je eigen segment, een NAS achter een externe subnetrouter en een openbare site zijn drie bestemmingen met drie verschillende paden. Als er precies één van faalt, hoort het defect bij het pad van die bestemming en niet bij de client als geheel. Voor de lokale printer terwijl een exit-node in gebruik is, is de LAN-toegangsinstelling het gebruikelijke antwoord. Voor de externe NAS controleer je het aangekondigde bereik, de goedkeuringsstatus en de toegangsregels in die volgorde. Voor een openbare site controleer je welke exit-node is geselecteerd en of de client hem echt heeft geaccepteerd.

Als het adres werkt en de naam niet, stop dan met naar routes te kijken. Privé-DNS wordt apart geconfigureerd, en een naam die naar het verkeerde adres oplost, faalt op een manier die identiek lijkt aan een geblokkeerde route. Test eerst het adres, dan de naam, en de twee resultaten vertellen je welke laag je moet openen.

Bevestig het pad dat je denkt te hebben gebouwd

Verificatie is een routeopzoeking plus een adrescontrole, geen ping. De opzoeking zegt welke interface een bestemming zou gebruiken, en de adrescontrole zegt in welk bereik de bestemming werkelijk zit. Een geslaagde ping zegt dat de host ergens leeft, wat niet de vraag is. Voer beide uit voordat je enige configuratie wijzigt.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Combineer dat met de eigen weergave van het tailnet, die laat zien of de peer direct is verbonden of via een relay. Een relaypad werkt nog steeds, en dat verklaart klachten over latentie die niets te maken hebben met de route die je aan het debuggen was. de documentatie van de subnetrouter behandelt de goedkeuringsstap als die onbekend is. Noteer daarna welke constructie welke bestemming in je eigen netwerk dekt, want de volgende persoon die een locatie toevoegt, stelt dezelfde vraag.