Un amfitrió de Tailscale inaccessible: encaminador de subxarxa o node de sortida?

Un amfitrió de Tailscale respon mentre un altre es queda a les fosques, o tot funciona fins que els llocs web públics comencen a informar del país equivocat. Totes dues queixes arriben com «Tailscale està trencat», i totes dues solen ser la construcció equivocada activada per a la destinació equivocada. Un encaminador de subxarxa exposa una xarxa privada a la tailnet, mentre que un node de sortida canvia d'on surt el trànsit d'internet. Ordena primer la destinació que falla i després tria el paper que la cobreix.

Comença per la destinació que ha fallat

Anota l'adreça o el nom que no ha funcionat i de quina mena de cosa es tracta. Un dispositiu en una LAN privada darrere d'una altra seu, un servei al teu propi segment i un lloc web públic són tres problemes d'encaminament que comparteixen un sol client per casualitat. La distinció no és estètica, perquè les dues construccions cobreixen conjunts diferents de destinacions. Activar-ne una no fa res per l'altra, i aquesta és tota la font de la confusió.

Fixa't també en la família d'adreces. Una subxarxa anunciada només com a IPv4 deixa les destinacions IPv6 al camí local, cosa que es llegeix com una fallada parcial fins que algú compara les dues taules d'encaminament. Anota quin camí esperaves, perquè la prova posterior tingui alguna cosa a contradir.

Arriba a un dispositiu que mai no executa Tailscale

L'encaminador anuncia rangs concrets a la tailnet i després reenvia paquets entre la tailnet i el segment privat, de manera que els dispositius d'aquell segment no necessiten cap client propi. Arribar a un NAS de l'oficina des d'un portàtil de casa és exactament aquest cas. L'encaminador és l'únic membre de la tailnet en aquell costat.

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

L'anunci és només la primera de tres condicions. La ruta ha d'estar aprovada per a la tailnet, el client ha d'acceptar les rutes anunciades, i una regla d'accés ha de permetre la connexió. Aquesta cadena és la raó per la qual el símptoma sovint és que l'encaminador funciona i el NAS no. Un encaminador accessible demostra que el túnel funciona; no demostra res sobre l'aprovació, l'acceptació del client o la política.

Cadascuna d'aquestes tres fallades es veu diferent a la consola d'administració. Comprova-les per ordre en lloc de canviar-ne tres alhora, perquè un segon canvi amaga quin era el que importava.

Treu el trànsit públic per una altra màquina

Un node de sortida encamina el teu trànsit general d'internet a través de si mateix, que és l'equivalent més proper al túnel complet d'altres productes VPN. També necessita tres consentiments separats: el dispositiu anuncia el paper, un administrador el permet i el client el tria. Unir-se a una tailnet no envia res per un altre membre per defecte.

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

Seleccionar un node de sortida no dona accés automàtic a la seva pròpia LAN. L'opció d'accés a la LAN existeix precisament perquè són permisos diferents, i deixar-la desactivada és el valor per defecte més segur. Les rutes cap a altres recursos de Tailscale mantenen el seu propi tractament fins i tot mentre un node de sortida és actiu. És per això que un servei allotjat en una subxarxa pot continuar funcionant mentre el camí públic d'internet ha canviat.

Un node de sortida també canvia com et veu internet, no només la rapidesa amb què sembla anar. Espera que la geolocalització, els catàlegs d'streaming i els límits de velocitat segueixin l'adreça del node de sortida i no la teva.

Llegeix la divisió en tres quan només falla un amfitrió

Una impressora al teu segment, un NAS darrere d'un encaminador de subxarxa remot i un lloc públic són tres destinacions amb tres camins diferents. Si falla exactament una d'elles, el defecte pertany al camí d'aquella destinació i no al client en conjunt. Per a la impressora local mentre s'usa un node de sortida, la configuració d'accés a la LAN és la resposta habitual. Per al NAS remot, comprova el rang anunciat, el seu estat d'aprovació i les regles d'accés en aquest ordre. Per a un lloc públic, comprova quin node de sortida està seleccionat i si el client realment l'ha acceptat.

Si l'adreça funciona i el nom no, deixa de mirar les rutes. El DNS privat es configura a part, i un nom que es resol a l'adreça equivocada falla d'una manera que sembla idèntica a una ruta blocada. Prova primer l'adreça i després el nom, i els dos resultats et diuen quina capa cal obrir.

Confirma el camí que creus que has construït

La verificació és una consulta de ruta més una comprovació d'adreça, no un ping. La consulta diu quina interfície faria servir una destinació, i la comprovació d'adreça diu en quin rang viu realment la destinació. Un ping que té èxit diu que l'amfitrió és viu en algun lloc, cosa que no és la pregunta. Executa tots dos abans de canviar qualsevol configuració.

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

Combina-ho amb la visió pròpia de la tailnet, que mostra si el peer està connectat directament o retransmès. Un camí retransmès també funciona, i explica queixes de latència que no tenen res a veure amb la ruta que estaves depurant. documentació de l'encaminador de subxarxa cobreix el pas d'aprovació si no t'és familiar. Després anota quina construcció cobreix quina destinació a la teva xarxa, perquè la propera persona que afegeixi una seu farà la mateixa pregunta.