Kvifor ei godkjend Tailscale-subnett-rute framleis går i timeout

Godkjenning i administrasjonskonsollen ser ut som det siste steget, og det er det ikkje. Fyrst går applikasjonen i timeout, og fyrst etterpå oppdagar du at rutaren er på nett og ruta er godkjend. Godkjenning er eit distribusjonssteg, ikkje eit løyve og ikkje ein garanti for videresending. Fire steg må stemme før ein pakke når ein vert bak ein subnett-rutar, og kvart steg kan lukkast medan det neste feilar. Gå gjennom dei i rekkjefølgje og stopp ved det første steget som ikkje held.

Fire steg, éin feil

Rutaren annonserer prefikset, tailnettet godkjenner annonsen, klienten godtek ruta han fekk, og tilgangspolitikken tillet den konkrete sambindinga. Det er fire separate avgjerder tekne av tre ulike komponentar. Ei godkjend rute seier derfor berre at nettverket no er ein del av rutetabellen til tailnettet.

Det fjerde steget blir oftast hoppa over, fordi dei tre første gir synleg tilstand. Ei tildeling som dekkjer rutaren si eiga tailnet-adresse, dekkjer ikkje automatisk eit privat subnett bak henne. Det er ulike destinasjonar, og politikken blir vurdert per destinasjon.

På Linux har det tredje steget òg ein standardverdi som overraskar folk: aksept av subnett-ruter er valfritt. Fleire GUI-klientar godtek annonserte ruter som standard, så ein blanda flåte kan vise éin maskin som feilar medan resten verkar.

Stadfest innstillinga på maskinen som feilar i staden for å ta ein plattform for gitt. Ruta var aldri den manglande biten på maskinene som verkar, så la dei prove at tailnet-sida er sunn. Tailscale sin dokumentasjon om subnett-rutarar dekkjer godkjenning, ruteaksept hos klienten og politikkssteget.

Kontroller ruta der klienten køyrer

Start på klienten som feilar, ikkje på rutaren. Stadfest at ruta finst og at klientinnstillinga i det heile tillet å godta ruter.

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

Den første kommandoen viser peer-lista og om subnett-rutaren er tilgjengeleg, den andre skriv ut innstillingane til klienten inkludert flagget for ruteaksept, og den tredje spør kjernen kva grensesnitt han ville bruke for ein ekte vert på subnettet. Viss den siste kommandoen nemner det fysiske grensesnittet i staden for Tailscale-grensesnittet, kom ruta aldri i tabellen. Ei manglande rute er eit klientproblem, ikkje eit godkjenningsproblem. Retta det før du ser på politikken.

For å godta ruter på Linux, kopla til på nytt med flagget i staden for å ta det for gitt at det er sett: tailscale up --accept-routes. Ein klient som kom med med andre flagg, held på dei til dei blir endra, så sjekk gjeldande innstilling før du legg til ei ny. Å køyre den første kommandoen på nytt etter endringa skal vise ruta i tabellen.

Prov videresending og returvegen

Godkjenning konfigurerer ikkje rutaren til å videresende pakkar, og ho ordnar ikkje svaret. Begge er tilhøve på vertsnivå på LAN-sida av rutaren. Test dei på rutaren, ikkje 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, elles forkastar kjernen den videresende pakken. Den andre viser om maskeringa av subnett-ruta skriv om kjelda, som er standardåtferd og vanlegvis det du vil. Den tredje viser om førespurnaden når destinasjonen og om noko kjem tilbake; ein førespurnad utan svar er eit returvegproblem, ikkje eit godkjenningsproblem. Les dei tre resultata saman før du endrar noko av dei.

Viss maskeringa er slått av, treng destinasjonsnettverket ei rute tilbake til adressene til tailnettet, og kvar hopp imellom må vite det. Å slå maskeringa på igjen er den raskaste rettinga for éi teneste, men på kostnad av å gøyme den opphavlege klientadressa for destinasjonen. Den avveginga betyr noko når destinasjonen loggar kjeldeadresser for revisjon, så avgjer det medvite i staden for å snu flagget under ei hending. Dokumenter kva val du tok, fordi neste person vil berre sjå éin av dei to åtferdene.

Les tilgangsregelen for ressursen

Når ruta finst og videresendinga er prova, er den gjenverande mistenkte politikken. Les tildelinga som skal tillete sambindinga, og kontroller destinasjonen, ikkje berre kjelda. Identiteten til klienten sjølv må òg samsvare med selektoren til politikken, så registrer han frå same maskina som feilar.

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

Statusutdata identifiserer dei eigne adressene til klienten og peerane han ser, og det er dette kjeldeslektoren til politikken må samsvare med. tailscale ping provar tailnet-vegen til sjølve subnett-rutaren; han løyser peernamn og tailnet-adresser, ikkje vertar inne i eit annonsert subnett. Den tredje kommandoen sender eit vanleg ICMP-ekko gjennom subnett-ruta, så resultatet skildrar destinasjonen i staden for rutaren. Ei avvising på tailnet-nivå kjem vanlegvis tilbake som ei avvising, medan ein pakke som forlèt og aldri kjem tilbake, går i timeout.

Eit namn som feilar er eit anna spørsmål enn ei adresse som feilar; løys opp verten direkte før du klandrar ruta. Skriv tildelinga etter det faktiske ressursbehovet i staden for heile subnettet. Å opne eit heilt /24 slik at éin applikasjon verkar, er måten ein smal førespurnad blir ei brei løyve som ingen seinare tør å fjerne.

Viss målet var internett-utgang i staden for eit privat subnett, er den rette komponenten ein utgangsnode, ikkje ein subnett-rutar, og politikken og rutinga skil seg tilsvarande. Kontroller den avgjerda før du utvidar ei tildeling. Ein utgangsnode endrar standardruta; ein subnett-rutar annonserer berre eit prefiks.