Hvorfor en godkendt Tailscale-undernetværksrute stadig løber ind i timeout

Godkendelse i administrationskonsollen ser ud som det sidste skridt, og det er det ikke. Applikationen rammer først timeout, og først derefter opdager du, at routeren er online, og at ruten er godkendt. Godkendelse er et distributionstrin, ikke en tilladelse og ikke en garanti for videresendelse. Fire trin skal passe sammen, før en pakke når en vært bag en undernetværksrouter, og hvert trin kan lykkes, mens det næste fejler. Tag dem i rækkefølge, og stop ved det første trin, der ikke holder.

Fire trin, én fejl

Routeren annoncerer præfikset, tailnettet godkender den annoncering, klienten accepterer den rute, den modtog, og adgangspolitikken tillader den konkrete forbindelse. Det er fire separate beslutninger truffet af tre forskellige komponenter. En godkendt rute siger derfor kun, at netværket nu er en del af tailnettets routingtabel.

Det fjerde trin er det, der oftest springes over, fordi de første tre giver synlig tilstand. En tildeling, der dækker routerens egen tailnet-adresse, dækker ikke automatisk et privat undernet bag den. Det er forskellige destinationer, og politikken vurderes pr. destination.

På Linux har det tredje trin også en standard, der overrasker folk: accept af undernetværksruter er tilvalg. Flere GUI-klienter accepterer annoncerede ruter som standard, så en blandet flåde kan vise én fejlende maskine, mens resten fungerer.

Bekræft indstillingen på den fejlende maskine i stedet for at antage en platform. Ruten var aldrig den manglende brik på de fungerende maskiner, så lad dem bevise, at tailnet-siden er sund. Tailscales dokumentation om undernetværksroutere dækker godkendelse, klientens accept af ruter og politiktrinnet.

Kontroller ruten der, hvor klienten kører

Begynd på klienten, der fejler, ikke på routeren. Bekræft, at ruten er til stede, og at klientindstillingen overhovedet tillader at acceptere ruter.

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

Den første kommando viser peer-listen, og om undernetværksrouteren kan nås, den anden udskriver klientens indstillinger inklusive flaget for rutegodkendelse, og den tredje spørger kernen, hvilken grænseflade den ville bruge til en rigtig vært på undernettet. Hvis den sidste kommando nævner den fysiske grænseflade i stedet for Tailscale-grænsefladen, kom ruten aldrig i tabellen. En manglende rute er et klientproblem, ikke et godkendelsesproblem. Ret det, før du ser på politikken.

For at acceptere ruter på Linux skal du genoprette forbindelsen med flaget i stedet for at antage, at det er sat: tailscale up --accept-routes. En klient, der blev tilknyttet med andre flag, beholder dem, indtil de ændres, så kontroller den aktuelle indstilling, før du tilføjer endnu et. Hvis du kører den første kommando igen efter ændringen, bør ruten vises i tabellen.

Bevis videresendelse og returvejen

Godkendelse konfigurerer ikke routeren til at videresende pakker, og den sørger ikke for svaret. Begge er forhold på værtsniveau på routerens LAN-side. Test dem på routeren, 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 kommando skal rapportere 1, ellers kasserer kernen den videresendte pakke. Den anden viser, om undernetværksrutens maskering omskriver kilden, hvilket er standardadfærden og normalt det, du ønsker. Den tredje viser, om anmodningen når destinationen, og om der kommer noget tilbage; en anmodning uden svar er et returvejsproblem, ikke et godkendelsesproblem. Læs de tre resultater sammen, før du ændrer nogen af dem.

Hvis maskeringen er slået fra, har destinationsnetværket brug for en rute tilbage til tailnettets adresser, og hvert hop imellem skal kende den. At slå maskeringen til igen er den hurtigere løsning for en enkelt tjeneste, men på bekostning af at skjule klientens oprindelige adresse for destinationen. Den afvejning betyder noget, når destinationen logger kildeadresser til revision, så beslut det bevidst i stedet for at vende flaget under en hændelse. Dokumentér, hvilket valg du traf, fordi den næste person kun vil se én af de to adfærdsmåder.

Læs adgangsreglen for ressourcen

Når ruten er til stede, og videresendelsen er bevist, er den resterende mistænkte politikken. Læs den tildeling, der skulle tillade forbindelsen, og kontroller dens destination, ikke kun dens kilde. Klientens egen identitet skal også matche politikkens selector, så registrér den fra den samme maskine, der fejler.

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

Statusoutputtet identificerer klientens egne adresser og de peers, den kan se, hvilket er det, politikkens kildeselector skal matche. tailscale ping beviser tailnet-stien til selve undernetværksrouteren; den opløser peer-navne og tailnet-adresser, ikke værter inde i et annonceret undernet. Den tredje kommando sender et almindeligt ICMP-ekko gennem undernetværksruten, så resultatet beskriver destinationen i stedet for routeren. En afvisning på tailnet-niveau kommer normalt tilbage som en afvisning, mens en pakke, der forlader og aldrig vender tilbage, rammer timeout.

Et navn, der fejler, er et andet spørgsmål end en adresse, der fejler; opløs værten direkte, før du bebrejder ruten. Skriv tildelingen efter det faktiske ressourcekrav i stedet for hele undernettet. At åbne et helt /24, så én applikation virker, er den måde, en snæver anmodning bliver en bred tilladelse, som ingen senere tør fjerne.

Hvis målet var internetudgang i stedet for et privat undernet, er den korrekte komponent en exit node, ikke en undernetværksrouter, og politikken og routingadfærden afviger tilsvarende. Kontroller den beslutning, før du udvider en tildeling. En exit node ændrer standardruten; en undernetværksrouter annoncerer kun et præfiks.