구성 사례 · Clash 기술 블로그

Tailscale과 Clash 충돌 해결 방법: TUN, LAN 및 라우팅 우선순위 수정

Tailscale과 Clash를 동시에 켰을 때만 문제가 발생해야 실제 공존 충돌입니다. 이를 확인한 뒤 tailnet, MagicDNS 및 LAN 라우팅은 Tailscale에 남기고 일반 공용 인터넷 트래픽은 Clash로 보내세요.

본문 읽기블로그로 돌아가기
  • Tailscale
  • TUN
  • LAN
이 글의 목차
게시일
업데이트 날짜
예상 읽기 시간
약 6분

Tailscale과 Clash가 각각은 정상인데 함께 켤 때만 끊겨야 실제 충돌입니다

Tailscale만 켰을 때는 tailnet 기기에 접속할 수 있어야 하고 Clash TUN만 켰을 때는 평소 분리 라우팅이 되어야 합니다. 두 도구가 각각은 정상인데 함께 실행할 때만 실패한다면 라우팅, DNS 또는 기본 출구의 경쟁을 확인하세요. 어느 한쪽이 단독으로도 실패한다면 해당 도구의 설정부터 수정해야 합니다.

Tailscale만 켠 상태, Clash만 켠 상태, 둘 다 켠 상태를 각각 기록하세요. 각 상태에서 tailnet IP 하나, tailnet 기기 이름 하나, LAN 주소 하나, 공용 인터넷 주소 하나를 테스트합니다. IP와 기기 이름의 결과가 다르면 라우팅 문제와 MagicDNS 문제를 이미 구분할 수 있습니다.

세 가지 비교 결과가 알려 주는 것

결과가능성이 높은 문제
100.x 주소와 기기 이름이 모두 연결되지 않음Tailscale 대역을 TUN 또는 기본 경로가 가져감
100.x 주소에는 접속되지만 기기 이름은 연결되지 않음MagicDNS 또는 Clash DNS의 인계 순서
tailnet은 정상이나 공용 인터넷이 끊김두 도구가 기본 출구 또는 exit node를 두고 경쟁함
특정 LAN 대역만 연결되지 않음Tailscale 서브넷 경로와 로컬 네트워크 대역이 겹침

어떤 네트워크 어댑터가 대상 대역을 가져갔는지는 라우팅 테이블에서 확인할 수 있습니다

Tailscale은 기기에 100.64.0.0/10 범위의 주소를 할당하고 관리자가 승인한 서브넷 경로를 받을 수도 있습니다. exit node를 선택하면 기본 경로도 설치합니다. Clash TUN도 라우팅을 작성하므로 두 개의 스위치만 보고 충돌을 판단할 수는 없습니다.

문제가 발생한 상태에서 route print, ip route 또는 netstat -rn 결과를 저장하고 각 도구를 단독 실행했을 때와 비교하세요. 100.64.0.0/10, 실제로 게시된 서브넷, 홈 LAN, 기본 경로가 각각 어느 인터페이스를 가리키는지와 동일한 접두사에 metric만 다른 항목이 두 개 있는지를 중점적으로 확인합니다.

시스템별 라우팅 확인
# Windows
route print

# Linux
ip route
ip rule

# macOS
netstat -rn

기본 인터넷 출구는 한 도구에만 맡기세요

Tailscale exit node와 Clash TUN은 모두 기본 인터넷 트래픽에 영향을 줄 수 있습니다. Tailscale로 집의 NAS에 접속하고 공용 인터넷 분리 라우팅은 Clash가 맡는 것이 목적이라면 이 기기에서 Tailscale exit node를 선택하지 마세요.

Tailscale은 tailnet과 게시된 서브넷만 담당하게 하세요.

반대로 회사 정책상 모든 공용 인터넷 트래픽이 지정된 Tailscale exit node를 거쳐야 한다면 Clash는 명시한 애플리케이션 또는 프록시 포트만 처리하게 하고, 이런 조합이 조직 정책에 맞는지 확인해야 합니다. 두 도구가 모두 기본 출구를 선언했는데 연결이 간헐적으로 성공하는 것은 라우팅 metric이 잠시 유리했을 뿐 안정적인 설정이 아닙니다.

tailnet과 실제 서브넷은 Tailscale이 맡게 하세요

Clash Verge Rev처럼 TUN에서 사용자 지정 대역을 제외할 수 있는 클라이언트에서는 100.64.0.0/10, 실제로 사용하는 홈 LAN, Tailscale 관리 콘솔에서 승인한 advertised routes를 제외 범위에 추가할 수 있습니다.

다른 사람의 모든 사설 대역을 그대로 복사하지 마세요. 제외 범위가 지나치게 넓으면 Clash가 처리해야 할 연결까지 직접 빠져나갑니다.

Mihomo 규칙에서도 해당 대역을 명시적으로 DIRECT 처리할 수 있지만 라우팅 계층의 제외와 규칙 계층의 DIRECT는 완전히 같지 않습니다. 연결이 먼저 코어에 들어와야 규칙이 판단할 수 있습니다. 100.x 요청이 Clash 연결 기록에 전혀 나타나지 않으면 시스템 라우팅을 바로 확인하고, 나타나면서 프록시에 일치하면 규칙을 조정하세요.

자신의 네트워크에 맞게 입력해야 합니다

  • 100.64.0.0/10 tailnet 주소 범위
  • 집 또는 사무실에서 실제 사용하는 LAN 대역
  • Tailscale 콘솔에서 승인한 서브넷 경로
  • Docker, WSL 또는 가상 머신에서 실제로 tailnet과 겹치는 대역

IP에는 접속되지만 기기 이름은 실패하면 라우팅이 아니라 MagicDNS를 점검하세요

100.x 주소에 직접 접속된다면 tailnet으로 가는 경로는 대체로 존재합니다. 이때 기기 이름 확인이 실패하면 Clash DNS, 브라우저 DoH 또는 시스템 resolver가 tailnet 이름을 Tailscale DNS 설정에 넘기지 않았을 가능성이 큽니다.

먼저 tailscale status에서 기기 주소를 확인하고 nslookup 또는 시스템 이름 확인 도구로 짧은 이름과 전체 tailnet 이름을 비교하세요. 점검 중에는 브라우저의 독립 DoH를 끄고 Clash의 nameserver-policy 또는 로컬 도메인 제외 설정을 확인해 tailnet 이름을 공용 DNS로 전달하지 마세요.

WSL, Docker, 원격 LAN이 우연히 같은 네트워크 대역을 사용할 수 있습니다

Tailscale 서브넷 경로가 192.168.1.0/24를 게시하는데 현재 카페나 집에서도 192.168.1.0/24를 사용하면 시스템은 주소만 보고 어느 쪽에 접속할지 구분할 수 없습니다. Docker와 WSL2도 자체 사설 대역을 추가하므로 충돌이 컨테이너나 하위 시스템에서만 나타날 수도 있습니다.

대역이 겹치면 자신이 제어할 수 있는 LAN, Docker 또는 가상 머신의 주소 설계를 우선 변경하세요. 같은 접두사를 더 높은 우선순위 경로로 계속 가로채는 방식은 네트워크 전환, 절전 모드 복귀, 업그레이드 뒤 다시 실패하게 만듭니다.

절전 모드 복귀 또는 Wi-Fi 전환 뒤에만 실패하면 대개 라우팅 재작성 순서가 바뀐 것입니다

노트북이 절전 모드에서 깨어나거나 유선에서 Wi-Fi 또는 모바일 핫스팟으로 전환되면 두 클라이언트가 기본 인터페이스를 다시 감지하고 경로를 작성합니다. 재연결이 끝날 때까지 기다린 뒤 라우팅 테이블을 비교하세요. 한쪽을 일정한 순서로 다시 시작하면 복구되는 현상은 시작 순서가 원인이라는 근거입니다.

두 클라이언트를 업데이트한 뒤에도 반복된다면 자동 시작 시 경쟁을 줄이세요. 시스템 네트워크가 준비된 뒤 필요한 터널을 시작하고 Tailscale exit node를 동시에 자동 선택하지 않도록 합니다. 매번 전체 네트워크 초기화를 실행하면 문제와 무관한 설정까지 더 많이 지워집니다.

수정을 마친 뒤에는 두 작업이 모두 여전히 성립하는지 입증해야 합니다

같은 차례에 검증할 항목

  1. tailnet IP 접속

    100.x 경로를 여전히 Tailscale이 맡고 있음을 확인합니다.

  2. tailnet 이름으로 접속

    MagicDNS 또는 전용 이름 확인을 계속 사용할 수 있음을 확인합니다.

  3. 게시된 서브넷에 접속

    승인된 subnet route를 Clash가 가져가지 않았는지 확인합니다.

  4. 공용 인터넷에 접속하고 Clash 기록 확인

    일반 분리 라우팅이 여전히 예상 정책으로 처리됨을 확인합니다.

네 항목 중 실패한 항목이 있으면 해당 라우팅, DNS, 서브넷 또는 기본 출구만 다시 조정하세요. Tailscale과 Clash가 각각 무엇을 담당하는지 동시에 설명할 수 있어야 우연한 metric 순서에 의존하지 않는 설정입니다.

참고 자료