Linux의 Tailscale 클라이언트가 광고된 서브넷 경로를 무시하는 이유

당신은 Linux 노트북을 쓰고 있고, tailscale status은 다른 머신을 나열하며, 10.80.0.25의 NAS는 여전히 시간 초과가 납니다. tailnet은 건강하고 서브넷 라우터는 온라인이며, 클라이언트 출력 어디에도 뒤쪽 LAN에 닿을 수 없는 이유가 없습니다. 아래 설명은 그 증상에서 바깥으로 나아갑니다. 먼저 이 클라이언트의 플래그, 다음 라우터의 광고, 다음 승인, 다음 정책, 그다음에야 목적지 자체입니다. 모든 관문이 같은 시간 초과로 실패하므로 명령보다 순서가 더 중요합니다.

Linux 클라이언트가 설치를 거부하는 것

Linux의 Tailscale 클라이언트는 요청하지 않으면 광고된 서브넷 경로를 받아들이지 않습니다. 이 설정이 없으면 클라이언트는 tailnet에 가입해 피어 주소에는 닿지만 라우터가 광고하는 모든 접두사는 쓰이지 않은 채 남습니다. 기본값은 의도된 것이며, 증상이 로컬 결정이 아니라 고장 난 라우터처럼 보이는 이유입니다.

여기서는 서로 다른 두 가지를 라우팅이라 부르는데, 그중 하나만 당신 것입니다. 라우터는 tailnet에 접두사를 광고하고, 당신의 머신은 그것을 설치할지 결정합니다. 어느 쪽이 실패해도 같은 시간 초과가 나므로 추측은 반나절을 낭비합니다. 무엇이든 고치기 전에 어느 쪽이 거부하는지 찾아내세요.

이 머신에서 경로 수락 켜기

클라이언트에서 설정을 켜고, 명령이 먹혔다고 가정하지 말고 무엇이 바뀌었는지 보세요. 현재 형태는 로그인 흐름을 반복하지 않고 설정을 적용하므로 세션 중간일 때 중요합니다.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale은 Linux에서 수락된 경로를 자체 표에 설치하므로, 표 52에 접두사가 나타나는 것은 이 클라이언트가 광고를 설치했다는 직접 증거입니다. 그 표에 당신의 범위가 없으면 멈추세요. 문제는 로컬이며 라우터에서 아무리 작업해도 바뀌지 않습니다.

오래된 클라이언트는 같은 설정을 로그인 명령의 플래그로 제공하므로 tailscale set이 없을 때 sudo tailscale up --accept-routes이 대안입니다. 경로를 손으로 고치는 대신 이것을 쓰세요. 데몬이 자기 표를 다시 쓰기 때문에 다음 재연결에서 편집이 사라집니다. 오래된 글에서 명령을 복사하기 전에 버전을 확인하세요.

광고와 승인을 따로 확인하기

서브넷 라우터에서는 접두사를 광고해야 하고, 커널은 인터페이스 사이로 패킷을 전달해야 합니다. 전달 없이 광고하면 트래픽을 조용히 버리는 승인된 경로가 생기며, 이것이 가장 흔한 반쯤 끝난 구성입니다.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

광고된 접두사를 실제로 도달하려는 주소와 글자 하나씩 비교하세요. 10.70.0.0/24를 광고하는 라우터는 10.80.0.25의 NAS에 대해 아무 말도 하지 않으며, 두 숫자가 똑같이 그럴듯해 보이기 때문에 이 불일치는 어떤 상태 출력에도 드러나지 않습니다. 고장 난 경로 신고의 대부분은 여기서 끝납니다. 아래쪽의 무엇이든 건드리기 전에 광고를 고치세요.

승인이 다음 관문이며, 라우터를 셸에서 구성했다면 건너뛰기 쉽습니다. 다른 머신이 쓰기 전에 관리 콘솔에서 그 장치의 광고를 켜야 합니다. 클라이언트에서 경로를 수락하는 것은 아무것도 승인하지 않으며 어떤 접근 규칙도 무효화하지 않습니다.

호스트 이름보다 사설 주소를 먼저 시험하기

라우터 자체의 tailnet 주소로 연결되면 tailnet이 동작한다는 증거이며, 그것은 이미 알고 있었습니다. 유용한 시험은 정말로 필요한 서비스를 먼저 사설 주소로 확인하는 것이며, 그래야 DNS 실패가 라우팅 실패로 위장할 수 없습니다.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

주소는 응답하는데 호스트 이름이 응답하지 않으면 이름 해석 문제이므로 경로 문제로 다루기를 그만두어야 합니다. 둘 다 응답하지 않으면 한 절 뒤로 가서 광고가 주소를 포함하는지 확인하세요. 두 실패는 애플리케이션에서는 똑같이 보이고 서로 다른 곳에서 고칩니다.

tailnet을 탓하기 전에 로컬 확인을 하나 할 가치가 있습니다. 현재 LAN이 원격 서브넷과 같은 접두사를 쓰면 커널은 직접 연결된 경로를 선호하고 트래픽은 머신을 떠나지 않습니다. 집과 사무실이 모두 192.168.1.0/24를 고를 때 생기는 일입니다.

클라이언트 플래그가 라우터 설정이 아닌 이유

이것들은 요구 사항이 다른 서로 다른 역할이며, 클라이언트 플래그를 라우터에 복사하는 것이 동작하는 tailnet이 루프를 얻는 방법입니다. 경로를 광고하는 머신에는 전달, 전달된 트래픽을 허용하는 방화벽 규칙, 어떤 접두사를 광고할지에 대한 결정이 필요합니다. 그중 어느 것도 --accept-routes에서 함축되지 않습니다.

서브넷 라우터 문서는 하나의 접두사를 광고하는 중복 라우터에서 경로 수락을 켜지 말라고 경고합니다. 대기 노드가 이미 로컬인 트래픽을 활성 노드를 통해 밖으로 밀어낼 수 있기 때문입니다. HA 쌍을 운영한다면 그것을 각주가 아니라 설계 제약으로 다루고, 둘 다에서 승인하기 전에 어느 노드가 접두사를 소유하는지 정하세요. 단일 라우터에서는 같은 경고가 수락은 클라이언트의 것이지 광고하는 머신의 것이 아니라는 알림으로 읽힙니다. 어느 관문이 닫혀 있었는지 적어 두세요.

일반 클라이언트에서는 순서가 처음에 실패한 애플리케이션 시험으로 끝납니다. 라우터에서는 전달, 광고, 승인, 방화벽을 그 순서로 검토하세요. 처음 빠진 것이 당신이 시작한 바로 그 시간 초과를 만들기 때문입니다.