En Tailscale-värd oåtkomlig: subnätrouter eller utgångsnod?

En Tailscale-värd svarar medan en annan blir mörk, eller så fungerar allt tills offentliga webbplatser börjar rapportera fel land. Båda klagomålen kommer som „Tailscale är trasigt“, och båda är oftast den felaktiga konstruktionen påslagen för fel mål. En subnätrouter exponerar ett privat nätverk för tailnätet, medan en utgångsnod ändrar var internettrafiken lämnar. Sortera först målet som misslyckas och välj sedan rollen som täcker det.

Börja med målet som misslyckades

Skriv ner adressen eller namnet som inte fungerade, och vad det är för sorts sak. En enhet på ett privat LAN bakom en annan plats, en tjänst på ditt eget segment och en offentlig webbplats är tre routingproblem som råkar dela en enda klient. Skillnaden är inte kosmetisk, eftersom de två konstruktionerna täcker olika uppsättningar mål. Att slå på den ena gör ingenting för den andra, och det är hela källan till förvirringen.

Lägg också märke till adressfamiljen. Ett subnät som bara annonseras som IPv4 lämnar IPv6-mål på den lokala vägen, vilket läses som ett delvis fel tills någon jämför båda routingtabellerna. Anteckna vilken väg du förväntade dig, så att testet senare har något att motsäga.

Nå en enhet som aldrig kör Tailscale

Routern annonserar specifika intervall till tailnätet och vidarebefordrar sedan paket mellan tailnätet och det privata segmentet, så enheterna på det segmentet behöver ingen egen klient. Att nå en NAS på kontoret från en bärbar dator hemma är precis detta fall. Routern är den enda medlemmen i tailnätet på den sidan.

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

Annonsering är bara det första av tre villkor. Vägen måste godkännas för tailnätet, klienten måste acceptera annonserade rutter, och en åtkomstregel måste tillåta anslutningen. Den kedjan är anledningen till att symtomet så ofta är att routern körs och NAS:en inte. En nåbar router bevisar att tunneln fungerar; den bevisar ingenting om godkännande, klientacceptans eller policy.

Var och en av de tre felen ser olika ut i administrationskonsolen. Kontrollera dem i ordning i stället för att ändra alla tre samtidigt, eftersom en andra ändring döljer vilken som spelade roll.

Skicka ut offentlig trafik genom en annan maskin

En utgångsnod routar din allmänna internettrafik genom sig själv, vilket är den närmaste motsvarigheten till fulltunneluppsättningen i andra VPN-produkter. Den behöver också tre separata samtycken: enheten annonserar rollen, en administratör tillåter den och klienten väljer den. Att gå med i ett tailnät skickar ingenting genom en annan medlem som standard.

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

Att välja en utgångsnod ger inte automatiskt åtkomst till dess eget LAN. LAN-åtkomstalternativet finns just för att det är olika behörigheter, och att lämna det avstängt är den säkrare standarden. Rutter till andra Tailscale-resurser behåller sin egen hantering även medan en utgångsnod är aktiv. Därför kan en tjänst som driftas på ett subnät fortsätta fungera medan den offentliga internetvägen har ändrats.

En utgångsnod ändrar också hur internet ser dig, inte bara hur snabbt det känns. Förvänta dig att geolokalisering, streamingkataloger och hastighetsgränser följer utgångens adress och inte din.

Läs tredelningen när bara en värd misslyckas

En skrivare på ditt eget segment, en NAS bakom en avlägsen subnätrouter och en offentlig webbplats är tre mål med tre olika vägar. Om exakt ett av dem misslyckas tillhör felet vägen för det målet och inte klienten som helhet. För den lokala skrivaren medan en utgångsnod används är LAN-åtkomstinställningen det vanliga svaret. För den avlägsna NAS:en, kontrollera det annonserade intervallet, dess godkännandestatus och åtkomstreglerna i den ordningen. För en offentlig webbplats, kontrollera vilken utgångsnod som är vald och om klienten faktiskt accepterade den.

Om adressen fungerar och namnet inte, sluta titta på rutter. Privat DNS konfigureras separat, och ett namn som löses till fel adress misslyckas på ett sätt som ser identiskt ut med en blockerad väg. Testa adressen först, sedan namnet, och de två resultaten berättar vilket lager du ska öppna.

Bekräfta vägen du tror att du har byggt

Verifiering är en ruttuppslagning plus en adresskontroll, inte en ping. Uppslagningen säger vilket gränssnitt ett mål skulle använda, och adresskontrollen säger i vilket intervall målet faktiskt ligger. En ping som lyckas säger att värden lever någonstans, vilket inte är frågan. Kör båda innan du ändrar någon konfiguration.

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

Kombinera det med tailnätets egen vy, som visar om peeren är direkt ansluten eller vidarebefordrad. En vidarebefordrad väg fungerar fortfarande, och det förklarar klagomål på latens som inte har något med vägen du felsökte att göra. dokumentationen för subnätroutern täcker godkännandesteget om det är obekant. Skriv sedan ner vilken konstruktion som täcker vilket mål i ditt eget nätverk, eftersom nästa person som lägger till en plats kommer att ställa samma fråga.