Un host Tailscale inaccesibil: router de subrețea sau nod de ieșire?

Un host Tailscale răspunde în timp ce altul rămâne întunecat, sau totul funcționează până când site-urile publice încep să raporteze țara greșită. Ambele reclamații vin ca „Tailscale este stricat”, și ambele sunt de obicei construcția greșită activată pentru destinația greșită. Un router de subrețea expune o rețea privată către tailnet, în timp ce un nod de ieșire schimbă pe unde iese traficul de internet. Sortează mai întâi destinația care eșuează, apoi alege rolul care o acoperă.

Începe de la destinația care a eșuat

Notează adresa sau numele care nu a funcționat și ce fel de lucru este. Un dispozitiv într-o LAN privată în spatele altei locații, un serviciu pe propriul segment și un site public sunt trei probleme de rutare care împart din întâmplare un singur client. Distincția nu este cosmetică, pentru că cele două construcții acoperă seturi diferite de destinații. Activarea uneia nu face nimic pentru cealaltă, și aceasta este toată sursa confuziei.

Observă și familia de adrese. O subrețea anunțată doar ca IPv4 lasă destinațiile IPv6 pe calea locală, ceea ce se citește ca o eșuare parțială până când cineva compară ambele tabele de rutare. Notează ce cale ai așteptat, ca testul să aibă mai târziu ce contrazice.

Ajunge la un dispozitiv care nu rulează niciodată Tailscale

Routerul anunță intervale specifice către tailnet, apoi retransmite pachete între tailnet și segmentul privat, astfel încât dispozitivele din acel segment nu au nevoie de propriul client. Ajungerea la un NAS de la birou de pe un laptop de acasă este exact acest caz. Routerul este singurul membru al tailnet-ului din acea parte.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

Anunțarea este doar prima dintre trei condiții. Ruta trebuie aprobată pentru tailnet, clientul trebuie să accepte rutele anunțate, iar o regulă de acces trebuie să permită conexiunea. Acest lanț este motivul pentru care simptomul este atât de des ca routerul să funcționeze și NAS-ul nu. Un router accesibil dovedește că tunelul funcționează; nu dovedește nimic despre aprobare, acceptarea de către client sau politică.

Fiecare dintre aceste trei eșecuri arată diferit în consola de administrare. Verifică-le în ordine în loc să le schimbi pe toate trei deodată, pentru că o a doua modificare ascunde care conta.

Scoate traficul public prin altă mașină

Un nod de ieșire rutează traficul tău general de internet prin el însuși, ceea ce este cel mai apropiat analog al tunelului complet din alte produse VPN. Are nevoie și de trei consimțăminte separate: dispozitivul anunță rolul, un administrator îl permite, iar clientul îl selectează. Alăturarea la un tailnet nu trimite nimic prin alt membru în mod implicit.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Selectarea unui nod de ieșire nu acordă automat acces la propria sa LAN. Opțiunea de acces la LAN există exact pentru că acestea sunt permisiuni diferite, iar lăsarea ei oprită este valoarea implicită mai sigură. Rutele către alte resurse Tailscale își păstrează propria tratare chiar în timp ce un nod de ieșire este activ. De aceea un serviciu găzduit într-o subrețea poate continua să funcționeze în timp ce calea publică de internet s-a schimbat.

Un nod de ieșire schimbă și cum te vede internetul, nu doar cât de rapid pare. Așteaptă-te ca geolocația, cataloagele de streaming și limitele de viteză să urmeze adresa ieșirii și nu pe a ta.

Citește împărțirea în trei când eșuează doar un singur host

O imprimantă în segmentul tău, un NAS în spatele unui router de subrețea îndepărtat și un site public sunt trei destinații cu trei căi diferite. Dacă eșuează exact una dintre ele, defectul aparține căii acelei destinații și nu clientului în ansamblu. Pentru imprimanta locală în timp ce se folosește un nod de ieșire, setarea de acces la LAN este răspunsul obișnuit. Pentru NAS-ul îndepărtat, verifică intervalul anunțat, starea lui de aprobare și regulile de acces în această ordine. Pentru un site public, verifică ce nod de ieșire este selectat și dacă clientul l-a acceptat cu adevărat.

Dacă adresa funcționează și numele nu, oprește-te din a te uita la rute. DNS-ul privat se configurează separat, iar un nume care se rezolvă la adresa greșită eșuează într-un mod care arată identic cu o rută blocată. Testează mai întâi adresa, apoi numele, iar cele două rezultate îți spun ce strat să deschizi.

Confirmă calea pe care crezi că ai construit-o

Verificarea este o căutare de rută plus o verificare de adresă, nu un ping. Căutarea spune ce interfață ar folosi o destinație, iar verificarea de adresă spune în ce interval se află de fapt destinația. Un ping reușit spune că hostul este viu undeva, ceea ce nu este întrebarea. Rulează ambele înainte de a schimba orice configurație.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Combină asta cu vederea proprie a tailnet-ului, care arată dacă partenerul este conectat direct sau prin releu. O cale prin releu funcționează în continuare, și asta explică reclamațiile de latență care nu au nimic de-a face cu ruta pe care o depanai. documentația routerului de subrețea acoperă pasul de aprobare dacă nu îți este familiar. Apoi notează ce construcție acoperă ce destinație în propria rețea, pentru că următoarea persoană care adaugă o locație va pune aceeași întrebare.