Waarom een goedgekeurde Tailscale-subnetroute nog steeds in een time-out loopt

Goedkeuring in de beheerconsole lijkt de laatste stap, en dat is het niet. Eerst loopt de applicatie in een time-out, en pas daarna ontdekt u dat de router online is en de route goedgekeurd. Goedkeuring is een distributiestap, geen toestemming en geen garantie voor doorsturing. Vier fasen moeten op één lijn komen voordat een pakket een host achter een subnetrouter bereikt, en elk kan slagen terwijl de volgende faalt. Werk ze in volgorde af en stop bij de eerste fase die geen stand houdt.

Vier fasen, één fout

De router adverteert het prefix, het tailnet keurt die aankondiging goed, de client accepteert de ontvangen route en het toegangsbeleid staat de specifieke verbinding toe. Dat zijn vier afzonderlijke beslissingen van drie verschillende componenten. Een goedgekeurde route zegt dus alleen dat het netwerk nu deel uitmaakt van de routetabel van het tailnet.

De vierde fase wordt het vaakst overgeslagen, omdat de eerste drie een zichtbare toestand opleveren. Een toestemming die het eigen tailnet-adres van de router dekt, dekt niet automatisch een privésubnet erachter. Dat zijn verschillende bestemmingen, en het beleid wordt per bestemming beoordeeld.

Op Linux heeft de derde fase ook een standaard die mensen verrast: het accepteren van subnetroutes is optioneel. Verschillende GUI-clients accepteren geadverteerde routes standaard, dus een gemengde vloot kan één falende machine tonen terwijl de rest werkt.

Bevestig de instelling op de falende machine in plaats van een platform aan te nemen. De route was nooit het ontbrekende stuk op de machines die werken, dus laat die bewijzen dat de tailnet-kant gezond is. De documentatie van Tailscale over subnetrouters behandelt goedkeuring, routeacceptatie op de client en de beleidsfase.

Controleer de route waar de client draait

Begin bij de client die faalt, niet bij de router. Bevestig dat de route aanwezig is en dat de clientinstelling het accepteren van routes überhaupt toestaat.

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

Het eerste commando toont de peerlijst en of de subnetrouter bereikbaar is, het tweede drukt de voorkeuren van de client af inclusief de vlag voor routeacceptatie, en het derde vraagt de kernel welke interface hij zou gebruiken voor een echte host op het subnet. Als dat laatste commando de fysieke interface noemt in plaats van de Tailscale-interface, is de route nooit in de tabel gekomen. Een ontbrekende route is een clientprobleem, geen goedkeuringsprobleem. Los het op voordat u naar het beleid kijkt.

Om op Linux routes te accepteren, verbindt u opnieuw met de vlag in plaats van aan te nemen dat die is ingesteld: tailscale up --accept-routes. Een client die met andere vlaggen is toegetreden, houdt die tot ze worden gewijzigd, dus controleer de huidige instelling voordat u er nog een toevoegt. Het opnieuw uitvoeren van het eerste commando na de wijziging zou de route in de tabel moeten tonen.

Bewijs doorsturing en het retourpad

Goedkeuring configureert de router niet om pakketten door te sturen en regelt het antwoord niet. Beide zijn zaken op hostniveau aan de LAN-kant van de router. Test ze op de router, niet op de client.

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

Het eerste commando moet 1 melden, anders gooit de kernel het doorgestuurde pakket weg. Het tweede toont of de maskering van de subnetroute de bron herschrijft, wat het standaardgedrag is en meestal wat u wilt. Het derde toont of het verzoek de bestemming bereikt en of er iets terugkomt; een verzoek zonder antwoord is een retourpadprobleem, geen goedkeuringsprobleem. Lees de drie resultaten samen voordat u een ervan wijzigt.

Als de maskering is uitgeschakeld, heeft het bestemmingsnetwerk een route terug naar de tailnet-adressen nodig, en elke hop ertussen moet die kennen. De maskering weer inschakelen is de snelste oplossing voor één dienst, ten koste van het verbergen van het oorspronkelijke clientadres voor de bestemming. Die afweging is belangrijk wanneer de bestemming bronadressen logt voor audits, dus beslis het bewust in plaats van de vlag tijdens een incident om te zetten. Documenteer welke keuze u hebt gemaakt, want de volgende persoon ziet slechts één van de twee gedragingen.

Lees de toegangsregel voor de resource

Nu de route aanwezig is en doorsturing is bewezen, is het beleid de resterende verdachte. Lees de toestemming die de verbinding moet toestaan en controleer de bestemming, niet alleen de bron. Ook de identiteit van de client moet overeenkomen met de selector van het beleid, dus leg die vast op dezelfde machine die faalt.

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

De statusuitvoer identificeert de eigen adressen van de client en de peers die hij ziet, en daarmee moet de bronselector van het beleid overeenkomen. tailscale ping bewijst het tailnet-pad tot de subnetrouter zelf; het lost peernamen en tailnet-adressen op, geen hosts binnen een geadverteerd subnet. Het derde commando stuurt een gewone ICMP-echo door de subnetroute, dus het resultaat beschrijft de bestemming in plaats van de router. Een weigering op tailnet-niveau komt meestal terug als een weigering, terwijl een pakket dat vertrekt en nooit terugkomt in een time-out loopt.

Een naam die faalt is een andere vraag dan een adres dat faalt; los de host direct op voordat u de route de schuld geeft. Schrijf de toestemming naar de werkelijke behoefte van de resource en niet naar het hele subnet. Een heel /24 openzetten zodat één applicatie werkt, is de manier waarop een smal verzoek een brede toestemming wordt die niemand later durft in te trekken.

Als het doel internetuitgang was en geen privésubnet, is het juiste component een exit-node, geen subnetrouter, en het beleid en de routing verschillen daarmee. Controleer die beslissing voordat u een toestemming verbreedt. Een exit-node verandert de standaardroute; een subnetrouter adverteert alleen een prefix.