De ce o rută de subreț Tailscale aprobată tot expiră

Aprobarea în consola de administrare pare ultimul pas, și nu este. Mai întâi aplicația expiră, și abia apoi descoperiți că routerul este online și ruta aprobată. Aprobarea este un pas de distribuire, nu o permisiune și nu o garanție de transmitere. Patru etape trebuie să se alinieze înainte ca un pachet să ajungă la un gazdă din spatele unui router de subreț, și fiecare poate reuși în timp ce următoarea eșuează. Parcurgeți-le în ordine și opriți-vă la prima etapă care nu rezistă.

Patru etape, o defecțiune

Routerul anunță prefixul, tailnet-ul aprobă anunțul, clientul acceptă ruta primită, iar politica de acces permite conexiunea concretă. Sunt patru decizii separate luate de trei componente diferite. Așadar, o rută aprobată spune doar că rețeaua face acum parte din tabela de rutare a tailnet-ului.

A patra etapă este cea mai des omisă, pentru că primele trei produc o stare vizibilă. O autorizare care acoperă adresa tailnet a routerului însuși nu acoperă automat un subreț privat din spatele lui. Sunt destinații diferite, iar politica este evaluată pentru fiecare destinație.

Pe Linux a treia etapă are și o valoare implicită care surprinde: acceptarea rutelor de subreț este opțională. Mai mulți clienți cu interfață grafică acceptă implicit rutele anunțate, astfel încât o flotă mixtă poate arăta o singură mașină care eșuează în timp ce restul funcționează.

Confirmați setarea pe mașina care eșuează în loc să presupuneți o platformă. Ruta nu a fost niciodată piesa lipsă pe mașinile care funcționează, așa că lăsați-le să demonstreze că partea tailnet este sănătoasă. Documentația Tailscale despre routerele de subreț acoperă aprobarea, acceptarea rutelor la client și etapa de politică.

Verificați ruta acolo unde rulează clientul

Începeți cu clientul care eșuează, nu cu routerul. Confirmați că ruta există și că setarea clientului permite acceptarea rutelor.

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

Prima comandă arată lista de parteneri și dacă routerul de subreț este accesibil, a doua tipărește preferințele clientului, inclusiv indicatorul de acceptare a rutelor, iar a treia întreabă nucleul ce interfață ar folosi pentru un gazdă reală din subreț. Dacă ultima comandă numește interfața fizică în locul interfeței Tailscale, ruta nu a intrat niciodată în tabelă. O rută lipsă este o problemă de partea clientului, nu de aprobare. Remediați-o înainte de a privi politica.

Pentru a accepta rute pe Linux, reconectați-vă cu indicatorul în loc să presupuneți că este setat: tailscale up --accept-routes. Un client care s-a alăturat cu alți indicatori îi păstrează până când sunt schimbați, așa că verificați setarea curentă înainte de a adăuga alta. Rularea din nou a primei comenzi după modificare ar trebui să arate ruta în tabelă.

Demonstrați transmiterea și calea de întoarcere

Aprobarea nu configurează routerul să transmită pachete și nu aranjează răspunsul. Ambele sunt chestiuni la nivel de gazdă pe partea LAN a routerului. Testați-le pe router, nu pe client.

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

Prima comandă trebuie să raporteze 1, altfel nucleul va arunca pachetul transmis. A doua arată dacă mascarea rutei de subreț rescrie sursa, ceea ce este comportamentul implicit și de obicei ceea ce doriți. A treia arată dacă cererea ajunge la destinație și dacă se întoarce ceva; o cerere fără răspuns este o problemă de cale de întoarcere, nu de aprobare. Citiți cele trei rezultate împreună înainte de a schimba vreunul.

Dacă mascarea a fost dezactivată, rețeaua de destinație are nevoie de o rută înapoi la adresele tailnet, iar fiecare salt intermediar trebuie să o cunoască. Reactivarea mascării este remedierea cea mai rapidă pentru un singur serviciu, cu prețul ascunderii adresei originale a clientului față de destinație. Acest compromis contează când destinația înregistrează adresele de sursă pentru audit, așa că decideți-l deliberat în loc să comutați indicatorul în timpul unui incident. Documentați ce opțiune ați ales, pentru că următoarea persoană va vedea doar unul dintre cele două comportamente.

Citiți regula de acces pentru resursă

Cu ruta prezentă și transmiterea demonstrată, suspectul rămas este politica. Citiți autorizarea care ar trebui să permită conexiunea și verificați destinația, nu doar sursa. Identitatea clientului însuși trebuie să corespundă selectorului politicii, așa că înregistrați-o de pe aceeași mașină care eșuează.

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

Ieșirea de stare identifică adresele proprii ale clientului și partenerii pe care îi vede, iar selectorul de sursă al politicii trebuie să corespundă acestora. tailscale ping demonstrează calea tailnet până la routerul de subreț însuși; rezolvă nume de parteneri și adrese tailnet, nu gazde din interiorul unui subreț anunțat. A treia comandă trimite un ecou ICMP obișnuit prin ruta de subreț, așa că rezultatul descrie destinația, nu routerul. O respingere la nivel de tailnet se întoarce de obicei ca refuz, în timp ce un pachet care pleacă și nu se întoarce niciodată expiră.

Un nume care eșuează este o altă întrebare decât o adresă care eșuează; rezolvați gazda direct înainte de a da vina pe rută. Scrieți autorizarea după necesitatea reală a resursei, nu după întregul subreț. Deschiderea unui /24 întreg pentru ca o aplicație să funcționeze este felul în care o cerere îngustă devine o permisiune largă pe care apoi nimeni nu îndrăznește să o retragă.

Dacă scopul a fost ieșirea în internet și nu un subreț privat, componenta corectă este un nod de ieșire, nu un router de subreț, iar politica și rutarea diferă în consecință. Verificați acea decizie înainte de a extinde o autorizare. Un nod de ieșire schimbă ruta implicită; un router de subreț doar anunță un prefix.