Én Tailscale-vert utilgjengelig: subnett-ruter eller utgangsnode?
Sorter først målet som mangler: en privat NAS trenger et annonsert subnett, mens offentlig surfing trenger en utgangsnode.
Én Tailscale-vert svarer mens en annen blir mørk, eller alt fungerer til offentlige nettsteder begynner å rapportere feil land. Begge klagene kommer som „Tailscale er ødelagt“, og begge er vanligvis den feil konstruksjonen slått på for feil mål. En subnett-ruter eksponerer et privat nettverk for tailnettet, mens en utgangsnode endrer hvor internettrafikken går ut. Sorter først målet som feiler, og velg så rollen som dekker det.
Start med målet som feilet
Skriv ned adressen eller navnet som ikke virket, og hva slags ting det er. En enhet på et privat LAN bak et annet sted, en tjeneste på ditt eget segment og et offentlig nettsted er tre rutingproblemer som tilfeldigvis deler én klient. Forskjellen er ikke kosmetisk, fordi de to konstruksjonene dekker ulike sett av mål. Å slå på den ene gjør ingenting for den andre, og det er hele kilden til forvirringen.
Legg også merke til adressefamilien. Et subnett som bare annonseres som IPv4, lar IPv6-mål ligge på den lokale veien, noe som ser ut som en delvis feil til noen sammenligner begge rutetabellene. Noter hvilken vei du forventet, slik at testen senere har noe å motsi.
Nå en enhet som aldri kjører Tailscale
Ruteren annonserer bestemte områder til tailnettet og videresender deretter pakker mellom tailnettet og det private segmentet, så enhetene på det segmentet ikke trenger egen klient. Å nå en NAS på kontoret fra en bærbar hjemme er nettopp dette tilfellet. Ruteren er det eneste medlemmet av tailnettet på den siden.
tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status
Annonsering er bare den første av tre betingelser. Ruten må godkjennes for tailnettet, klienten må godta annonserte ruter, og en tilgangsregel må tillate forbindelsen. Denne kjeden er grunnen til at symptomet så ofte er at ruteren kjører og NAS-en ikke. En tilgjengelig ruter beviser at tunnelen virker; den beviser ingenting om godkjenning, klientgodtakelse eller policy.
Hver av de tre feilene ser forskjellig ut i administrasjonskonsollen. Sjekk dem i rekkefølge i stedet for å endre alle tre samtidig, fordi en annen endring skjuler hvilken som betydde noe.
Send offentlig trafikk ut gjennom en annen maskin
En utgangsnode ruter din vanlige internettrafikk gjennom seg selv, noe som er den nærmeste analogien til fulltunneloppsettet i andre VPN-produkter. Den trenger også tre separate samtykker: enheten annonserer rollen, en administrator tillater den, og klienten velger den. Å bli med i et tailnett sender ingenting gjennom et annet medlem som standard.
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
Å velge en utgangsnode gir ikke automatisk tilgang til dens eget LAN. LAN-tilgangsalternativet finnes nettopp fordi dette er forskjellige tillatelser, og å la det være av er den sikrere standarden. Ruter til andre Tailscale-ressurser beholder sin egen håndtering selv mens en utgangsnode er aktiv. Derfor kan en tjeneste som driftes på et subnett fortsette å virke mens den offentlige internettveien er endret.
En utgangsnode endrer også hvordan internett ser deg, ikke bare hvor raskt det føles. Forvent at geolokasjon, strømmekataloger og hastighetsgrenser følger utgangens adresse og ikke din.
Les tredelingen når bare én vert feiler
En skriver på ditt eget segment, en NAS bak en ekstern subnett-ruter og et offentlig nettsted er tre mål med tre ulike veier. Hvis nøyaktig ett av dem feiler, hører feilen til veien til det målet og ikke til klienten som helhet. For den lokale skriveren mens en utgangsnode er i bruk, er LAN-tilgangsinnstillingen det vanlige svaret. For den eksterne NAS-en, sjekk det annonserte området, godkjenningsstatusen og tilgangsreglene i den rekkefølgen. For et offentlig nettsted, sjekk hvilken utgangsnode som er valgt og om klienten faktisk godtok den.
Hvis adressen virker og navnet ikke, slutt å se på ruter. Privat DNS konfigureres separat, og et navn som løses til feil adresse feiler på en måte som ser identisk ut med en blokkert rute. Test adressen først, deretter navnet, og de to resultatene forteller deg hvilket lag du skal åpne.
Bekreft veien du tror du har bygget
Verifisering er et ruteoppslag pluss en adressekontroll, ikke en ping. Oppslaget forteller hvilket grensesnitt et mål ville bruke, og adressekontrollen forteller i hvilket område målet faktisk ligger. En ping som lykkes sier at verten lever et sted, noe som ikke er spørsmålet. Kjør begge før du endrer noen konfigurasjon.
ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55
Kombiner det med tailnettets eget bilde, som viser om peeren er direkte tilkoblet eller videresendt. En videresendt vei virker fortsatt, og det forklarer klager på ventetid som ikke har noe med ruten du feilsøkte å gjøre. dokumentasjonen for subnett-ruteren dekker godkjenningstrinnet hvis det er ukjent. Skriv deretter ned hvilken konstruksjon som dekker hvilket mål i ditt eget nettverk, fordi neste person som legger til et sted vil stille det samme spørsmålet.