Tailscale 호스트 하나에 닿지 않을 때: 서브넷 라우터인가 출구 노드인가

한쪽 Tailscale 호스트는 응답하는데 다른 쪽은 깜깜한 상태가 되거나, 모든 것이 잘 돌아가다가 갑자기 공개 사이트가 엉뚱한 국가를 보고하기 시작합니다. 두 불만 모두 „Tailscale이 고장 났다“는 형태로 들어오지만, 대개는 잘못된 목적지에 잘못된 구성을 켠 것뿐입니다. 서브넷 라우터는 사설 네트워크를 tailnet에 노출하고, 출구 노드는 인터넷 트래픽이 어디서 나가는지를 바꿉니다. 먼저 실패한 목적지를 정리하고, 그 목적지를 덮는 역할을 고르십시오.

실패한 목적지에서 시작하십시오

동작하지 않은 주소나 이름, 그리고 그것이 무엇인지 적어 두십시오. 다른 사이트 뒤의 사설 LAN에 있는 장치, 자기 세그먼트의 서비스, 공개 웹사이트는 우연히 같은 클라이언트를 공유하는 세 가지 라우팅 문제입니다. 구분은 겉모양 문제가 아닙니다. 두 구성이 덮는 목적지 집합이 다르기 때문입니다. 하나를 켜도 다른 하나에는 아무 효과가 없고, 혼란의 원인은 바로 거기에 있습니다.

주소 체계도 살펴보십시오. IPv4로만 광고된 서브넷은 IPv6 목적지를 로컬 경로에 남겨 둡니다. 누군가 두 라우팅 테이블을 비교할 때까지 이것은 부분 장애처럼 보입니다. 경로가 어떨 것이라고 예상했는지 적어 두면, 나중에 테스트가 반박할 재료가 됩니다.

Tailscale을 전혀 실행하지 않는 장치에 닿게 하기

라우터는 특정 범위를 tailnet에 광고한 뒤 tailnet과 사설 세그먼트 사이에서 패킷을 중계합니다. 그래서 그 세그먼트의 장치에는 자체 클라이언트가 필요 없습니다. 집의 노트북에서 사무실 NAS에 닿는 것이 바로 이 경우입니다. 그쪽에서 tailnet의 구성원은 라우터 하나뿐입니다.

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

광고는 세 조건 중 첫 번째일 뿐입니다. 경로가 tailnet에 승인되어야 하고, 클라이언트가 광고된 경로를 받아들여야 하며, 접근 규칙이 연결을 허용해야 합니다. 이 사슬 때문에 증상은 흔히 라우터는 살아 있는데 NAS는 안 되는 형태가 됩니다. 닿는 라우터는 터널이 동작한다는 증거일 뿐, 승인이나 클라이언트 수락, 정책에 대해서는 아무것도 증명하지 않습니다.

이 세 가지 실패는 관리 콘솔에서 각각 다르게 보입니다. 셋을 한꺼번에 바꾸지 말고 순서대로 확인하십시오. 두 번째 변경은 어느 것이 효과가 있었는지를 가려 버립니다.

공개 트래픽을 다른 머신으로 내보내기

출구 노드는 일반 인터넷 트래픽을 자기 자신을 통해 라우팅합니다. 다른 VPN 제품의 전체 터널 구성에 가장 가까운 형태입니다. 여기에도 세 가지 동의가 따로 필요합니다. 장치가 역할을 광고하고, 관리자가 이를 허용하고, 클라이언트가 이를 선택합니다. tailnet에 참여하는 것만으로는 기본적으로 다른 구성원을 거쳐 아무것도 흐르지 않습니다.

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

출구 노드를 선택해도 그 노드 자체의 LAN 접근이 자동으로 주어지지는 않습니다. LAN 접근 옵션이 있는 이유가 바로 이것이 다른 권한이기 때문이며, 꺼 두는 편이 더 안전한 기본값입니다. 다른 Tailscale 리소스로 가는 경로는 출구 노드가 켜져 있는 동안에도 자체 처리를 유지합니다. 그래서 서브넷에 호스팅된 서비스는 공개 인터넷 경로가 바뀌어도 계속 동작할 수 있습니다.

출구 노드는 얼마나 빠르게 느껴지는지만이 아니라 인터넷이 당신을 어떻게 보는지도 바꿉니다. 지리 위치, 스트리밍 카탈로그, 속도 제한이 당신의 주소가 아니라 출구의 주소를 따른다고 예상하십시오.

호스트 하나만 실패할 때는 삼분할을 읽으십시오

자기 세그먼트의 프린터, 원격 서브넷 라우터 뒤의 NAS, 공개 사이트는 서로 다른 세 경로를 가진 세 목적지입니다. 그중 정확히 하나만 실패한다면 결함은 그 목적지의 경로에 속하며, 클라이언트 전체의 문제가 아닙니다. 출구 노드를 쓰는 동안 로컬 프린터에 대해서는 LAN 접근 설정이 늘 쓰는 답입니다. 원격 NAS에 대해서는 광고된 범위, 승인 상태, 접근 규칙을 이 순서로 확인하십시오. 공개 사이트에 대해서는 어떤 출구 노드가 선택되었는지, 클라이언트가 실제로 그것을 받아들였는지 확인하십시오.

주소는 되는데 이름이 안 된다면 경로를 보는 것을 멈추십시오. 사설 DNS는 따로 설정되며, 잘못된 주소로 해석되는 이름은 차단된 경로와 똑같은 방식으로 실패합니다. 먼저 주소를, 다음에 이름을 시험하면 어느 계층을 열어야 하는지 알 수 있습니다.

만든 것이라고 생각하는 경로를 확인하십시오

검증은 경로 조회와 주소 확인이며 ping이 아닙니다. 조회는 목적지가 어느 인터페이스를 쓸지 알려 주고, 주소 확인은 목적지가 실제로 어느 범위에 있는지 알려 줍니다. 성공한 ping은 호스트가 어딘가에 살아 있다는 것뿐이라, 그것은 질문의 답이 아닙니다. 설정을 바꾸기 전에 둘 다 실행하십시오.

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

그것을 tailnet 자체의 보기와 함께 보십시오. 피어가 직접 연결되었는지 중계되었는지 보여 줍니다. 중계 경로도 동작하며, 그 사실이 당신이 조사하던 경로와 무관한 지연 불만을 설명해 줍니다. 서브넷 라우터 문서 는 익숙하지 않다면 승인 단계를 다룹니다. 그다음 자기 네트워크에서 어떤 구성이 어떤 목적지를 덮는지 적어 두십시오. 다음에 사이트를 추가할 사람도 같은 질문을 할 테니까요.