Waarom ’n goedgekeurde Tailscale-subnetroete steeds tyd uitloop
Roetegoedkeuring versprei net ’n subnetroete. As die diens steeds tyd uitloop, kyk na roeteaanvaarding by die kliënt, aansturing en die toegangsreël daarvoor.
Goedkeuring in die administrasiepaneel lyk soos die finale stap, en dit is nie. Die toepassing se versoek verstryk eerste, en eers daarna sien jy die roeteerder aanlyn en die roete goedgekeur. Goedkeuring is ’n verspreidingsstap, nie ’n toestemming en nie ’n waarborg dat pakkette aangestuur word nie. Vier fases moet in lyn kom voordat ’n pakkie ’n gasheer agter ’n subnetroeteerder bereik, en elkeen kan slaag terwyl die volgende misluk. Werk hulle in volgorde deur en stop by die eerste fase wat nie standhou nie.
Vier fases, een mislukking
Die roeteerder adverteer die voorvoegsel, die tailnet keur daardie advertensie goed, die kliënt aanvaar die roete wat hy ontvang het, en die toegangsbeleid laat die spesifieke verbinding toe. Dit is vier afsonderlike besluite wat deur drie verskillende komponente geneem word. ’n Goedgekeurde roete sê dus net dat die netwerk nou deel van die tailnet se roetetabel is.
Die vierde fase is die een wat die meeste oorgeslaan word, want die eerste drie lewer sigbare toestand. ’n Toekenning wat die roeteerder se eie tailnet-adres dek, dek nie outomaties ’n private subnet agter hom nie. Dit is verskillende bestemmings, en beleid word per bestemming geëvalueer.
Op Linux het die derde fase ook ’n verstekwaarde wat mense verras: die aanvaarding van subnetroetes is opsioneel. Verskeie GUI-kliënte aanvaar geadverteerde roetes by verstek, so ’n gemengde vloot kan een mislukkende masjien wys terwyl die res werk.
Bevestig die voorkeur op die masjien wat misluk eerder as om ’n platform te veronderstel. Die roete was nooit die ontbrekende stuk op die werkende masjiene nie, so laat hulle bewys dat die tailnet-kant gesond is. Tailscale se dokumentasie oor subnetroeteerders dek goedkeuring, kliëntaanvaarding van roetes en die beleidsfase.
Kontroleer die roete by die kliënt
Begin by die kliënt wat misluk, nie by die roeteerder nie. Bevestig dat die roete teenwoordig is en dat die kliëntvoorkeur die aanvaarding van roetes hoegenaamd toelaat.
tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42
Die eerste opdrag wys die portuurlys en of die subnetroeteerder bereikbaar is, die tweede druk die kliënt se voorkeure uit, insluitend die vlag vir roeteaanvaarding, en die derde vra die kern watter koppelvlak hy vir ’n werklike gasheer op die subnet sou gebruik. As daardie laaste opdrag die fisiese koppelvlak noem in plaas van die Tailscale-koppelvlak, het die roete nooit in die tabel beland nie. ’n Ontbrekende roete is ’n kliëntprobleem, nie ’n goedkeuringsprobleem nie. Maak dit reg voordat jy na beleid kyk.
Om roetes op Linux te aanvaar, maak weer verbinding met die vlag eerder as om te veronderstel dit is gestel: tailscale up --accept-routes. ’n Kliënt wat met ander vlae aangesluit het, hou hulle totdat dit verander word, so kyk na die huidige voorkeur voordat jy nog een byvoeg. As jy die eerste opdrag ná die verandering weer loop, behoort die roete in die tabel te wys.
Bewys aansturing en die terugpad
Goedkeuring stel nie die roeteerder op om pakkette aan te stuur nie, en dit reël nie die antwoord nie. Albei is gasheervlak-aangeleenthede aan die roeteerder se LAN-kant. Toets hulle op die roeteerder, nie op die kliënt nie.
sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443
Die eerste opdrag moet 1 rapporteer, anders laat die kern die aangestuurde pakkie val. Die tweede wys of subnetroete-masquerading die bron herskryf, wat die verstekgedrag is en gewoonlik wat jy wil hê. Die derde wys of die versoek by die bestemming aankom en of iets terugkom; ’n versoek sonder antwoord is ’n terugpadprobleem, nie ’n goedkeuringsprobleem nie. Lees die drie resultate saam voordat jy enigeen daarvan verander.
As masquerading gedeaktiveer is, het die bestemmingsnetwerk ’n roete terug na die tailnet se adresse nodig, en elke sprong tussenin moet dit weet. Om masquerading weer aan te skakel is die vinniger oplossing vir ’n enkele diens, ten koste daarvan dat die oorspronklike kliëntadres vir die bestemming weggesteek word. Daardie ruil maak saak wanneer die bestemming bronadresse vir ouditering teken, so besluit dit doelbewus eerder as om die vlag tydens ’n voorval om te swaai. Dokumenteer watter keuse jy gemaak het, want die volgende persoon sal net een van die twee gedragswyses sien.
Lees die toegangsreël vir die hulpbron
Met die roete teenwoordig en aansturing bewys, is die oorblywende verdagte beleid. Lees die toekenning wat veronderstel is om die verbinding toe te laat en kontroleer die bestemming daarvan, nie net die bron nie. Die kliënt se eie identiteit moet ook by die beleidskeurder pas, so teken dit op van dieselfde masjien wat misluk.
tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42
Die status-uitset identifiseer die kliënt se eie adresse en die portuurs wat hy kan sien, wat is waarmee ’n beleidsbronkeurder moet pas. Die tailscale ping-opdrag bewys die tailnet-pad na die subnetroeteerder self; dit los die name van porture en tailnet-adresse op, nie gashere binne ’n geadverteerde subnet nie. Die derde opdrag stuur ’n gewone ICMP-eggode deur die subnetroete, so die resultaat beskryf die bestemming eerder as die roeteerder. ’n Weiering op tailnet-vlak kom gewoonlik terug as ’n weiering, terwyl ’n pakkie wat vertrek en nooit terugkeer nie, verstryk.
’n Mislukte naam is ’n ander vraag as ’n mislukte adres; los die gasheer direk op voordat jy die roete blameer. Skryf die toekenning teen die werklike hulpbronvereiste eerder as teen die hele subnet. Om ’n hele /24 oop te maak sodat een toepassing werk, is hoe ’n eng versoek ’n breë toestemming word wat niemand later durf verwyder nie.
As die doel internet-uitgang was eerder as ’n private subnet, is die korrekte komponent ’n uitgangsknooppunt, nie ’n subnetroeteerder nie, en die beleid en roetering verskil dienooreenkomstig. Kontroleer daardie besluit voordat jy ’n toekenning verbreed. ’n Uitgangsknooppunt verander die verstekroete; ’n subnetroeteerder adverteer net ’n voorvoegsel.