Varför en godkänd Tailscale-subnätväg ändå tar timeout

Godkännandet i administratörskonsolen ser ut som det sista steget, och det är det inte. Först tar programmet timeout, och först därefter upptäcker du att routern är online och vägen godkänd. Godkännandet är ett distributionssteg, inte en behörighet och inte en garanti för vidarebefordran. Fyra steg måste stämma innan ett paket når en värd bakom en subnätrouter, och varje steg kan lyckas medan nästa misslyckas. Gå igenom dem i ordning och stanna vid det första steget som inte håller.

Fyra steg, ett fel

Routern annonserar prefixet, tailnätet godkänner annonsen, klienten accepterar vägen den fick, och åtkomstpolicyn tillåter den specifika anslutningen. Det är fyra separata beslut fattade av tre olika komponenter. En godkänd väg säger därför bara att nätverket nu är en del av tailnätets routingtabell.

Det fjärde steget hoppas oftast över, eftersom de tre första ger ett synligt tillstånd. En tilldelning som täcker routerns egen tailnet-adress täcker inte automatiskt ett privat subnät bakom den. Det är olika destinationer, och policyn utvärderas per destination.

På Linux har det tredje steget också en standardinställning som överraskar: att acceptera subnätvägar är valfritt. Flera GUI-klienter accepterar annonserade vägar som standard, så en blandad flotta kan visa en maskin som misslyckas medan resten fungerar.

Bekräfta inställningen på maskinen som misslyckas i stället för att anta en plattform. Vägen var aldrig den saknade biten på maskinerna som fungerar, så låt dem bevisa att tailnätssidan är frisk. Tailscales dokumentation om subnätrouter täcker godkännande, klientens vägacceptans och policyinställningen.

Kontrollera vägen där klienten kör

Börja med klienten som misslyckas, inte med routern. Bekräfta att vägen finns och att klientinställningen överhuvudtaget tillåter att vägar accepteras.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Det första kommandot visar peer-listan och om subnätroutern är nåbar, det andra skriver ut klientens inställningar inklusive flaggan för vägacceptans, och det tredje frågar kärnan vilket gränssnitt den skulle använda för en riktig värd i subnätet. Om det sista kommandot nämner det fysiska gränssnittet i stället för Tailscale-gränssnittet kom vägen aldrig in i tabellen. En saknad väg är ett klientproblem, inte ett godkännandeproblem. Rätta det innan du tittar på policyn.

För att acceptera vägar på Linux, anslut igen med flaggan i stället för att anta att den är satt: tailscale up --accept-routes. En klient som anslöt med andra flaggor behåller dem tills de ändras, så kontrollera nuvarande inställning innan du lägger till en till. Att köra det första kommandot igen efter ändringen bör visa vägen i tabellen.

Bevisa vidarebefordran och returvägen

Godkännandet konfigurerar inte routern att vidarebefordra paket och ordnar inte svaret. Båda är frågor på värdnivå på routerns LAN-sida. Testa dem på routern, inte på klienten.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Det första kommandot måste rapportera 1, annars kastar kärnan det vidarebefordrade paketet. Det andra visar om maskningen av subnätvägen skriver om källan, vilket är standardbeteendet och oftast det du vill. Det tredje visar om förfrågan når destinationen och om något kommer tillbaka; en förfrågan utan svar är ett returvägsproblem, inte ett godkännandeproblem. Läs de tre resultaten tillsammans innan du ändrar något av dem.

Om maskningen har stängts av behöver destinationsnätverket en väg tillbaka till tailnätets adresser, och varje hopp däremellan måste känna till den. Att slå på maskningen igen är den snabbaste åtgärden för en enda tjänst, men till priset av att klientens ursprungliga adress döljs för destinationen. Den avvägningen spelar roll när destinationen loggar källadresser för revision, så besluta den medvetet i stället för att vända flaggan under en incident. Dokumentera vilket val du gjorde, eftersom nästa person bara kommer att se ett av de två beteendena.

Läs åtkomstregeln för resursen

När vägen finns och vidarebefordran är bevisad är den kvarvarande misstänkta policyn. Läs tilldelningen som ska tillåta anslutningen och kontrollera dess destination, inte bara dess källa. Klientens egen identitet måste också matcha policyns selector, så registrera den från samma maskin som misslyckas.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Statusutdata identifierar klientens egna adresser och de peers den ser, och det är detta policyns källselector måste matcha. tailscale ping bevisar tailnätvägen ända till själva subnätroutern; den löser peer-namn och tailnet-adresser, inte värdar inne i ett annonserat subnät. Det tredje kommandot skickar ett vanligt ICMP-eko genom subnätvägen, så resultatet beskriver destinationen i stället för routern. En avvisning på tailnätsnivå kommer vanligtvis tillbaka som en avvisning, medan ett paket som lämnar och aldrig kommer tillbaka tar timeout.

Ett namn som misslyckas är en annan fråga än en adress som misslyckas; lös värden direkt innan du skyller på vägen. Skriv tilldelningen efter resursens faktiska behov i stället för hela subnätet. Att öppna ett helt /24 så att en applikation fungerar är sättet en snäv förfrågan blir en bred behörighet som ingen senare vågar ta bort.

Om målet var internetutgång i stället för ett privat subnät är rätt komponent en utgångsnod, inte en subnätrouter, och policyn och routingen skiljer sig i enlighet med det. Kontrollera det beslutet innan du utökar en tilldelning. En utgångsnod ändrar standardvägen; en subnätrouter annonserar bara ett prefix.