Un host de Tailscale inaccesible: enrutador de subrede ou nodo de saída?

Un host de Tailscale responde mentres outro queda a escuras, ou todo funciona ata que os sitios web públicos comezan a informar do país equivocado. Ambas as queixas chegan como «Tailscale está roto», e ambas adoitan ser a construción equivocada activada para o destino equivocado. Un enrutador de subrede expón unha rede privada á tailnet, mentres que un nodo de saída cambia por onde sae o tráfico de internet. Ordena primeiro o destino que falla e logo escolle o rol que o cobre.

Comeza polo destino que fallou

Anota o enderezo ou o nome que non funcionou e que tipo de cousa é. Un dispositivo nunha LAN privada detrás doutra sede, un servizo no teu propio segmento e un sitio web público son tres problemas de enrutamento que comparten un único cliente por casualidade. A distinción non é estética, porque as dúas construcións cobren conxuntos distintos de destinos. Activar unha non fai nada pola outra, e esa é toda a fonte da confusión.

Fíxate tamén na familia de enderezos. Unha subrede anunciada só como IPv4 deixa os destinos IPv6 na ruta local, o que se le como un fallo parcial ata que alguén compara as dúas táboas de enrutamento. Anota que ruta esperabas, para que a proba posterior teña algo que contradicir.

Chega a un dispositivo que nunca executa Tailscale

O enrutador anuncia rangos concretos á tailnet e despois reenvía paquetes entre a tailnet e o segmento privado, de xeito que os dispositivos dese segmento non necesitan o seu propio cliente. Chegar a un NAS da oficina desde un portátil na casa é exactamente este caso. O enrutador é o único membro da tailnet nese lado.

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

O anuncio é só a primeira de tres condicións. A ruta debe aprobarse para a tailnet, o cliente debe aceptar as rutas anunciadas, e unha regra de acceso debe permitir a conexión. Esa cadea é a razón pola que o síntoma tantas veces é que o enrutador está activo e o NAS non. Un enrutador accesible demostra que o túnel funciona; non demostra nada sobre a aprobación, a aceptación do cliente ou a política.

Cada un deses tres fallos vese distinto na consola de administración. Compróbaos en orde en lugar de cambiar os tres á vez, porque un segundo cambio oculta cal era o que importaba.

Saca o tráfico público por outra máquina

Un nodo de saída enruta o teu tráfico xeral de internet a través de si mesmo, que é o equivalente máis próximo ao túnel completo doutros produtos VPN. Tamén necesita tres consentimentos separados: o dispositivo anuncia o rol, un administrador permíteo e o cliente selecciónao. Unirse a unha tailnet non envía nada por outro membro por defecto.

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 nodo de saída non concede automaticamente acceso á súa propia LAN. A opción de acceso á LAN existe precisamente porque son permisos distintos, e deixala desactivada é o valor por defecto máis seguro. As rutas cara a outros recursos de Tailscale manteñen o seu propio tratamento mesmo mentres un nodo de saída está activo. Por iso un servizo aloxado nunha subrede pode seguir funcionando mentres a ruta pública de internet cambiou.

Un nodo de saída tamén cambia como te ve internet, non só o rápido que parece ir. Espera que a xeolocalización, os catálogos de streaming e os límites de velocidade sigan o enderezo da saída e non o teu.

Le a división en tres cando só falla un host

Unha impresora no teu segmento, un NAS detrás dun enrutador de subrede remoto e un sitio público son tres destinos con tres rutas distintas. Se falla exactamente un deles, o defecto pertence á ruta dese destino e non ao cliente en conxunto. Para a impresora local mentres se usa un nodo de saída, o axuste de acceso á LAN é a resposta habitual. Para o NAS remoto, comproba o rango anunciado, o seu estado de aprobación e as regras de acceso nesa orde. Para un sitio público, comproba que nodo de saída está seleccionado e se o cliente realmente o aceptou.

Se o enderezo funciona e o nome non, deixa de mirar as rutas. O DNS privado configúrase á parte, e un nome que resolve ao enderezo equivocado falla dun xeito que parece idéntico a unha ruta bloqueada. Proba primeiro o enderezo e logo o nome, e os dous resultados dinche que capa abrir.

Confirma a ruta que cres que construíches

A verificación é unha consulta de ruta máis unha comprobación de enderezo, non un ping. A consulta di que interface usaría un destino, e a comprobación de enderezo di en que rango vive realmente o destino. Un ping que ten éxito di que o host está vivo nalgures, o cal non é a pregunta. Executa ambos antes de cambiar calquera configuración.

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

Combínao coa visión propia da tailnet, que mostra se o par está conectado directamente ou retransmitido. Unha ruta retransmitida segue funcionando, e iso explica queixas de latencia que non teñen nada que ver coa ruta que estabas depurando. A documentación do enrutador de subrede cobre o paso de aprobación se non che resulta familiar. Despois anota que construción cobre que destino na túa propia rede, porque a próxima persoa que engada unha sede fará a mesma pregunta.