Miért hagyja figyelmen kívül a Linux Tailscale-ügyfél a hirdetett alhálózati útvonalakat

Linuxos laptopon ül, a tailscale status listázza a többi gépet, és a 10.80.0.25 címen lévő NAS még mindig időtúllépéssel áll le. A tailnet egészséges, az alhálózati útválasztó online, és semmi nem mondja az ügyfél kimenetében, miért érhetetlen a mögötte lévő LAN. Az alábbi végigvezetés ettől a tünettől kifelé halad: az ezen az ügyfélen lévő kapcsoló, aztán a hirdetés az útválasztón, aztán a jóváhagyás, aztán a házirend, és csak ezután maga a cél. Minden kapu ugyanazzal az időtúllépéssel hibázik, ezért a sorrend fontosabb a parancsoknál.

Mit nem hajlandó telepíteni a Linux-ügyfél

A Linuxos Tailscale-ügyfelek nem fogadják el a hirdetett alhálózati útvonalakat, hacsak nem kéri őket. E beállítás nélkül az ügyfél csatlakozik a tailnethez és eléri a társak címeit, miközben minden előtag, amelyet az útválasztó hirdet, kihasználatlan marad. Az alapértelmezés szándékos, és ezért tűnik a tünet törött útválasztónak, nem helyi döntésnek.

Két különböző dolgot neveznek itt útválasztásnak, és csak az egyik az öné. Az útválasztó előtagot hirdet a tailnetbe; az ön gépe dönti el, telepíti-e. Bármelyik hibája ugyanazt az időtúllépést adja, ezért a találgatás egy délutánt pazarol el. Derítse ki, melyik oldal utasít el, mielőtt bármit szerkesztene.

Kapcsolja be az útvonalak elfogadását ezen a gépen

Állítsa be a preferenciát az ügyfélen, majd nézze meg, mi változott, ahelyett hogy feltételezné, hogy a parancs hatott. A jelenlegi forma a bejelentkezési folyamat megismétlése nélkül alkalmazza a beállítást, ami számít, ha éppen munkamenet közben van.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

A Tailscale a Linuxon a saját táblájába telepíti az elfogadott útvonalakat, ezért az 52-es táblában megjelenő előtag közvetlen bizonyítéka annak, hogy ez az ügyfél telepítette a hirdetést. Ha a tartománya hiányzik abból a táblából, álljon meg: a probléma helyi, és semmilyen útválasztón végzett munka nem változtat rajta.

A régebbi ügyfelek ugyanezt a preferenciát a bejelentkezési parancs kapcsolójaként kínálják, ezért a sudo tailscale up --accept-routes a tartalék, ha a tailscale set hiányzik. Használja ezt az útvonalak kézi szerkesztése helyett, mert a démon újraírja a saját tábláját, és a szerkesztése eltűnik a következő újracsatlakozáskor. Ellenőrizze a verziót, mielőtt egy régebbi bejegyzésből másol parancsot.

Ellenőrizze külön a hirdetést és a jóváhagyást

Az alhálózati útválasztón az előtagot hirdetni kell, és a kernelnek továbbítania kell a csomagokat az interfészek között. Hirdetés továbbítás nélkül jóváhagyott útvonalat ad, amely csendben eldobja a forgalmat, és ez a leggyakoribb félkész beállítás.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Hasonlítsa össze a hirdetett előtagot azzal a címmel, amelyet valóban el akar érni, karakterről karakterre. Egy 10.70.0.0/24-et hirdető útválasztó semmit nem mond a 10.80.0.25 címen lévő NAS-ról, és az eltérés minden állapotkimenetben láthatatlan, mert mindkét szám egyformán hihetőnek tűnik. A törött útvonalról szóló jelentések többsége itt véget ér. Javítsa a hirdetést, mielőtt bármihez hozzányúlna lejjebb.

A jóváhagyás a következő kapu, és könnyű kihagyni, ha az útválasztót shellből konfigurálták. A hirdetést engedélyezni kell annak az eszköznek az adminisztrációs konzolon, mielőtt más gépek használhatják. Az útvonalak elfogadása az ügyfélen semmit nem hagy jóvá, és egyetlen hozzáférési szabályt sem ír felül.

Előbb a privát címet tesztelje, mint a gazdagépnevet

Az útválasztó saját tailnet-címére létesített sikeres kapcsolat bizonyítja, hogy a tailnet működik, amit már tudott. A hasznos teszt az a szolgáltatás, amelyre valóban szüksége van, először a privát címen, hogy egy DNS-hiba ne adhassa ki magát útválasztási hibának.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Ha a cím válaszol és a gazdagépnév nem, névfeloldási problémája van, és hagyja abba annak útvonalproblémaként kezelését. Ha egyik sem válaszol, lépjen vissza egy szakaszt, és erősítse meg, hogy a hirdetés lefedi a címet. A két hiba az alkalmazásból azonosnak látszik, és különböző helyeken javítható.

Egy helyi ellenőrzést érdemes elvégezni, mielőtt a tailnetet okolná. Amikor a jelenlegi LAN ugyanazt az előtagot használja, mint a távoli alhálózat, a kernel a közvetlenül csatlakoztatott útvonalat részesíti előnyben, és a forgalom soha nem hagyja el a gépet; ez történik, amikor egy otthon és egy iroda is 192.168.1.0/24-et választ.

Miért nem útválasztó-beállítás az ügyfél kapcsolója

Ezek különböző szerepek különböző követelményekkel, és az ügyfél kapcsolójának átmásolása egy útválasztóra az, ahogy egy működő tailnet hurkot szerez. Az útvonalakat hirdető gépnek továbbításra, a továbbított forgalmat engedélyező tűzfal-szabályokra és döntésre van szüksége arról, mely előtagokat hirdeti. Ebből semmit nem tartalmaz a --accept-routes.

A alhálózati útválasztók dokumentációja óva int attól, hogy az útvonalak elfogadását olyan redundáns útválasztókon kapcsolja be, amelyek egy előtagot hirdetnek, mert egy készenléti csomópont a már helyi forgalmat az aktív csomóponton keresztül kifelé tolhatja. Ha HA-párt üzemeltet, kezelje ezt tervezési korlátként és ne lábjegyzetként, és döntse el, melyik csomópont birtokolja az előtagot, mielőtt mindkettőn jóváhagyja. Egyetlen útválasztón ugyanez a figyelmeztetés emlékeztetőként olvasható, hogy az elfogadás az ügyfeleké, nem a hirdető gépé. Írja fel, melyik kapu volt zárva.

Egy hétköznapi ügyfélnél a sorozat azzal az alkalmazásteszttel zárul, amely az elején elbukott. Az útválasztónál a továbbítást, a hirdetést, a jóváhagyást és a tűzfalat ebben a sorrendben vizsgálja, mert az első hiányzó pontosan azt az időtúllépést állítja elő, amellyel kezdte.