Zašto odobrena Tailscale ruta podmreže i dalje završava vremenskim istekom

Odobrenje u administratorskoj konzoli izgleda kao posljednji korak, ali nije. Aplikacija prvo doživi istek vremena, a tek onda otkrijete da je ruter na mreži i da je ruta odobrena. Odobrenje je korak distribucije, a ne dozvola i ne garancija prosljeđivanja. Četiri faze moraju se poravnati prije nego što paket stigne do hosta iza rutera podmreže, i svaka može uspjeti dok sljedeća ne uspijeva. Prođite ih po redu i zaustavite se na prvoj fazi koja ne stoji.

Četiri faze, jedan neuspjeh

Ruter oglašava prefiks, tailnet odobrava to oglašavanje, klijent prihvata rutu koju je primio, a pravilo pristupa dozvoljava konkretnu vezu. To su četiri odvojene odluke koje donose tri različite komponente. Odobrena ruta zato kaže samo da je mreža sada dio tablice rutiranja tailneta.

Četvrta faza je ona koja se najčešće preskače, jer prve tri daju vidljivo stanje. Dozvola koja pokriva vlastitu tailnet adresu rutera ne pokriva automatski privatnu podmrežu iza njega. To su različita odredišta, a pravilo se procjenjuje za svako odredište pojedinačno.

Na Linuxu treća faza ima i zadano ponašanje koje ljude iznenadi: prihvatanje ruta podmreža je opcionalno. Nekoliko GUI klijenata prihvata oglašene rute po zadanom, pa mješovita flota može pokazati jedan neispravan stroj dok ostali rade.

Provjerite postavku na stroju koji ne uspijeva, umjesto da pretpostavljate platformu. Ruta nikada nije bila dio koji nedostaje na strojevima koji rade, pa neka oni dokažu da je strana tailneta zdrava. Tailscaleova dokumentacija o ruterima podmreža pokriva odobrenje, prihvatanje ruta na klijentu i fazu pravila.

Provjerite rutu tamo gdje klijent radi

Počnite na klijentu koji ne uspijeva, ne na ruteru. Potvrdite da ruta postoji i da postavka klijenta uopće dopušta prihvatanje ruta.

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

Prva naredba pokazuje listu partnera i je li ruter podmreže dostupan, druga ispisuje postavke klijenta uključujući zastavicu prihvatanja ruta, a treća pita jezgru koje bi sučelje koristilo za stvarni host na podmreži. Ako ta posljednja naredba navede fizičko sučelje umjesto Tailscaleovog sučelja, ruta nikada nije ušla u tablicu. Ruta koja nedostaje problem je na strani klijenta, a ne problem odobrenja. Ispravite je prije nego što pogledate pravilo.

Da biste prihvatili rute na Linuxu, ponovno se povežite sa zastavicom umjesto da pretpostavite da je postavljena: tailscale up --accept-routes. Klijent koji je pridružen s drugim zastavicama zadržava ih dok se ne promijene, pa provjerite trenutnu postavku prije nego dodate još jednu. Ponovno pokretanje prve naredbe nakon promjene trebalo bi pokazati rutu u tablici.

Dokažite prosljeđivanje i povratni put

Odobrenje ne postavlja ruter da prosljeđuje pakete i ne uređuje odgovor. Oboje su stvari na razini hosta na LAN strani rutera. Testirajte ih na ruteru, ne na klijentu.

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

Prva naredba mora prijaviti 1, inače će jezgra odbaciti proslijeđeni paket. Druga pokazuje prepisuje li maskerada rute podmreže izvor, što je zadano ponašanje i obično ono što želite. Treća pokazuje stiže li zahtjev do odredišta i vraća li se išta; zahtjev bez odgovora problem je povratnog puta, a ne odobrenja. Pročitajte tri rezultata zajedno prije nego promijenite bilo koji od njih.

Ako je maskerada isključena, mreža odredišta treba rutu natrag prema tailnet adresama, i svaki skok između mora to znati. Ponovno uključivanje maskerade brže je rješenje za jednu uslugu, ali po cijeni skrivanja izvorne adrese klijenta od odredišta. Ta razmjena je važna kada odredište bilježi izvorne adrese za reviziju, pa odlučite svjesno umjesto da prebacujete zastavicu tijekom incidenta. Dokumentirajte koju ste opciju odabrali, jer će sljedeća osoba vidjeti samo jedno od dva ponašanja.

Pročitajte pravilo pristupa za resurs

Kad ruta postoji i prosljeđivanje je dokazano, preostali sumnjivac je pravilo. Pročitajte dozvolu koja bi trebala omogućiti vezu i provjerite njezino odredište, a ne samo izvor. Identitet samog klijenta također mora odgovarati selektoru pravila, pa ga zabilježite sa istog stroja koji ne uspijeva.

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

Izlaz statusa identificira vlastite adrese klijenta i partnere koje vidi, a s tim mora odgovarati selektor izvora pravila. tailscale ping dokazuje tailnet put do samog rutera podmreže; on razrješava imena partnera i tailnet adrese, a ne hostove unutar oglašene podmreže. Treća naredba šalje običan ICMP odjek kroz rutu podmreže, pa njezin rezultat opisuje odredište, a ne ruter. Odbijanje na razini tailneta obično se vraća kao odbijanje, dok paket koji ode i nikada se ne vrati istječe.

Ime koje se ne razrješava drugo je pitanje od adrese koja ne uspijeva; razriješite host izravno prije nego okrivite rutu. Pišite dozvolu prema stvarnoj potrebi resursa, a ne prema cijeloj podmreži. Otvaranje cijele /24 da bi jedna aplikacija radila jest način na koji uzak zahtjev postaje široka dozvola koju se kasnije nitko ne usudi ukloniti.

Ako je cilj bio izlaz na internet, a ne privatna podmreža, ispravna komponenta je izlazni čvor, a ne ruter podmreže, i pravilo te rutiranje se u skladu s tim razlikuju. Provjerite tu odluku prije nego proširite dozvolu. Izlazni čvor mijenja zadanu rutu; ruter podmreže samo oglašava prefiks.