Hvorfor en godkjent Tailscale-subnett-rute fortsatt går i timeout

Godkjenning i administrasjonskonsollen ser ut som det siste trinnet, og det er det ikke. Først går applikasjonen i timeout, og først etterpå oppdager du at ruteren er på nett og ruten er godkjent. Godkjenning er et distribusjonstrinn, ikke en tillatelse og ikke en garanti for videresending. Fire trinn må stemme før en pakke når en vert bak en subnett-ruter, og hvert trinn kan lykkes mens det neste feiler. Gå gjennom dem i rekkefølge og stopp ved det første trinnet som ikke holder.

Fire trinn, én feil

Ruteren annonserer prefikset, tailnettet godkjenner annonsen, klienten godtar ruten den fikk, og tilgangspolicyen tillater den konkrete forbindelsen. Det er fire separate beslutninger tatt av tre ulike komponenter. En godkjent rute sier derfor bare at nettverket nå er en del av tailnettets rutetabell.

Det fjerde trinnet hoppes oftest over, fordi de tre første gir synlig tilstand. En tildeling som dekker ruterens egen tailnet-adresse, dekker ikke automatisk et privat subnett bak den. Det er forskjellige destinasjoner, og policyen vurderes per destinasjon.

På Linux har det tredje trinnet også en standardverdi som overrasker folk: aksept av subnett-ruter er valgfritt. Flere GUI-klienter godtar annonserte ruter som standard, så en blandet flåte kan vise én maskin som feiler mens resten virker.

Bekreft innstillingen på maskinen som feiler i stedet for å anta en plattform. Ruten var aldri den manglende brikken på maskinene som virker, så la dem bevise at tailnet-siden er sunn. Tailscales dokumentasjon om subnett-rutere dekker godkjenning, klientens ruteaksept og policynivået.

Kontroller ruten der klienten kjører

Start på klienten som feiler, ikke på ruteren. Bekreft at ruten finnes og at klientinnstillingen i det hele tatt tillater å godta ruter.

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

Den første kommandoen viser peer-listen og om subnett-ruteren er tilgjengelig, den andre skriver ut klientens innstillinger inkludert flagget for ruteaksept, og den tredje spør kjernen hvilket grensesnitt den ville bruke for en ekte vert på subnettet. Hvis den siste kommandoen nevner det fysiske grensesnittet i stedet for Tailscale-grensesnittet, kom ruten aldri i tabellen. En manglende rute er et klientproblem, ikke et godkjenningsproblem. Rett det før du ser på policyen.

For å godta ruter på Linux, koble til på nytt med flagget i stedet for å anta at det er satt: tailscale up --accept-routes. En klient som ble med med andre flagg, beholder dem til de endres, så sjekk gjeldende innstilling før du legger til en ny. Å kjøre den første kommandoen på nytt etter endringen skal vise ruten i tabellen.

Bevis videresending og returveien

Godkjenning konfigurerer ikke ruteren til å videresende pakker, og den ordner ikke svaret. Begge er forhold på vertsnivå på ruterens LAN-side. Test dem på ruteren, ikke 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

Den første kommandoen må rapportere 1, ellers forkaster kjernen den videresendte pakken. Den andre viser om maskeringen av subnett-ruten skriver om kilden, som er standardadferden og vanligvis det du vil. Den tredje viser om forespørselen når destinasjonen og om noe kommer tilbake; en forespørsel uten svar er et returveiproblem, ikke et godkjenningsproblem. Les de tre resultatene sammen før du endrer noen av dem.

Hvis maskeringen er slått av, trenger destinasjonsnettverket en rute tilbake til tailnettets adresser, og hvert hopp imellom må vite det. Å slå maskeringen på igjen er den raskeste rettelsen for én tjeneste, men på bekostning av å skjule klientens opprinnelige adresse for destinasjonen. Den avveiningen betyr noe når destinasjonen logger kildeadresser for revisjon, så bestem det bevisst i stedet for å vende flagget under en hendelse. Dokumenter hvilket valg du tok, fordi neste person bare vil se én av de to adferdene.

Les tilgangsregelen for ressursen

Når ruten finnes og videresendingen er bevist, er den gjenværende mistenkte policyen. Les tildelingen som skal tillate forbindelsen, og kontroller destinasjonen, ikke bare kilden. Klientens egen identitet må også samsvare med policyens selektor, så registrer den fra samme maskin som feiler.

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

Statusutdata identifiserer klientens egne adresser og peerne den ser, og det er dette policyens kildeselektor må samsvare med. tailscale ping beviser tailnet-veien til selve subnett-ruteren; den løser peer-navn og tailnet-adresser, ikke verter inne i et annonsert subnett. Den tredje kommandoen sender et vanlig ICMP-ekko gjennom subnett-ruten, så resultatet beskriver destinasjonen i stedet for ruteren. En avvisning på tailnet-nivå kommer vanligvis tilbake som en avvisning, mens en pakke som forlater og aldri kommer tilbake, går i timeout.

Et navn som feiler er et annet spørsmål enn en adresse som feiler; løs opp verten direkte før du klandrer ruten. Skriv tildelingen etter det faktiske ressursbehovet i stedet for hele subnettet. Å åpne et helt /24 slik at én applikasjon virker, er måten en smal forespørsel blir en bred tillatelse som ingen senere tør å fjerne.

Hvis målet var internett-utgang i stedet for et privat subnett, er den riktige komponenten en utgangsnode, ikke en subnett-ruter, og policyen og rutingen avviker tilsvarende. Kontroller den beslutningen før du utvider en tildeling. En utgangsnode endrer standardruten; en subnett-ruter annonserer bare et prefiks.