기업 VPN+Clash 동시 사용: 분할 터널·예외 라우팅

1 왜 기업 VPN과 Clash가 «싸우나»

많은 기업 VPN 클라이언트는 연결 직후 0.0.0.0/0 혹은 넓은 목적지에 대한 경로를 VPN 인터페이스 쪽으로 올리고, 기본 게이트웨이를 가상 어댑터에 맞춥니다. 이런 구성을 흔히 전체 터널(full tunnel)이라고 부릅니다. 이 상태에서 브라우저가 나가는 패킷은 이미 OS가 «VPN 쪽이 더 맞다»고 본 다음 홉으로 보내 버리기 때문에, 사용자가 Clash에서 규칙을 아무리 정교하게 써도 패킷이 Clash까지 도달하지 않는 상황이 생깁니다. 반대로 Clash TUN을 먼저 켜 두고 메트릭이 낮은 가상 터널을 만들면, 사내 메일·인트라넷이 Clash 쪽으로 끌려와 회사 방화벽 밖으로 나가려다 실패하기도 합니다.

사용자가 검색으로 찾아오는 표현인 동시 연결은 결국 «한 PC에서 두 스택이 공존하되, 목적지별로 올바른 인터페이스를 타게 만드는 것»으로 귀결됩니다. 이를 위해서는 (가능하다면) VPN 측 분할 터널(split tunnel) 정책과, Clash 측 IP·도메인 규칙, 그리고 Windows의 라우팅 테이블을 같은 설계도 위에서 맞춰야 합니다. 클라이언트 설치가 처음이라면 Windows 설치 가이드로 기본 포트·프로필을 맞춘 뒤 이 글을 적용하는 편이 디버깅이 수월합니다.

핵심 질문 지금 끊기는 트래픽이 «VPN이 잡아간 기본 경로 때문」인지, «Clash 규칙/DNS 때문」인지부터 가릅니다. 증상만 보고 노드만 바꾸면 같은 자리를 맴돕게 됩니다.

2 GlobalProtect·AnyConnect와 분할 터널

Palo Alto GlobalProtect와 Cisco AnyConnect는 배포 방식은 다르지만, 공통적으로 포털·게이트웨이에서 내려주는 라우트 목록과 분할 터널 허용 여부가 동작을 지배합니다. 관리자가 «사내망 대역만 VPN, 나머지는 로컬 인터넷」으로 exclude 목록을 주면, 사용자 PC에서는 해당 IP 접두사만 VPN 인터페이스로 가고 일반 웹은 물리 NIC의 게이트웨이를 유지합니다. 이 경우 Clash는 상대적으로 다루기 쉽습니다. 시스템 프록시나 TUN으로 일반 트래픽을 가져와 규칙에 따라 프록시 그룹으로 라우팅하면 되고, 사내 대역은 VPN이 이미 잡고 있으므로 Clash에서는 DIRECT로 두거나 아예 규칙 전에 OS가 라우팅해 줍니다.

문제는 전체 터널이 강제될 때입니다. 이때는 사용자 권한만으로 VPN 클라이언트 옵션을 바꾸기 어렵고, IT 부서에 분할 터널 예외를 요청하거나, 회사가 허용하는 범위에서만 예외 라우팅을 추가하는 수밖에 없는 경우가 많습니다. 문서 목적상 기술 가능성을 설명하지만, 실제로는 고용 계약·보안 규정을 반드시 확인해야 합니다.

용어 정리

분할 터널: 일부 목적지만 암호화 터널을 타고, 나머지는 로컬 경로를 쓰는 모델.
예외 라우트: OS 라우팅 테이블에 더 구체적인(prefix가 긴) 정적 경로를 넣어 특정 대역의 다음 홉을 바꾸는 방식.
동시 연결: VPN 세션과 Clash 프로세스가 동시에 살아 있되, 목적지별로 서로 다른 스택을 타게 설계하는 것.

3 Windows에서 라우팅 테이블 읽기

VPN 연결 전후로 라우팅 테이블을 비교하면 어떤 인터페이스가 0.0.0.0을 가져갔는지 한눈에 드러납니다. 관리자 권한이 없어도 읽기는 가능한 경우가 많습니다. 전통적으로는 명령 프롬프트에서 다음과 같이 확인합니다.

CMD

route print -4

PowerShell에서는 Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, DestinationPrefix처럼 보면 메트릭과 인터페이스 인덱스를 함께 정렬해 보기 좋습니다. VPN이 붙은 뒤 기본 경로(0.0.0.0/0)의 NextHop이 VPN 어댑터로 바뀌었다면, Clash가 시스템 프록시만 켠 상태로는 브라우저 일부는 되더라도 가상 어댑터를 타지 않는 앱은 여전히 VPN을 탈 수 있어 혼란이 생깁니다. TUN을 켜면 Clash가 커널 레벨에서 트래픽을 가로채려 하므로, VPN 드라이버와의 우선순위가 더 민감해집니다.

특정 사내 서브넷만 VPN으로 보내고 싶다면, 테이블에 이미 그 접두사에 대한 경로가 있는지 확인하세요. 없다면 IT 가이드에 따라 정적 라우트를 추가하는 방법이 있으나, 회사 장비에서는 금지되거나 재부팅 시 사라지는 경우가 많습니다. 개인 연구 목적이라도 권한 없는 라우트 추가는 위험하므로 절차는 내부 위키를 따르는 것이 안전합니다.

4 연결 순서: «먼저»가 의미 있을 때

사용자 커뮤니티에서 자주 나오는 질문이 «VPN과 Clash 중 무엇을 먼저 켜야 하냐」입니다. 엄밀히는 OS가 최종적으로 택한 라우트·메트릭이 정답이지, 클릭 순서만으로 보장되지는 않습니다. 다만 실무에서는 (1) VPN을 연결해 필수 사내 경로가 잡힌 뒤, (2) Clash를 실행해 규칙·TUN 스택을 올리는 순서가 디버깅하기 쉬운 경우가 많습니다. 반대로 Clash TUN을 먼저 올리면 VPN 클라이언트가 기동하면서 라우트를 덮어쓰고, Clash 쪽에서 재시작이 필요해질 수 있습니다.

인터페이스 메트릭이 낮을수록(숫자가 작을수록) 일반적으로 선호도가 높습니다. VPN이 자신의 어댑터 메트릭을 매우 낮게 잡으면, Clash TUN이 트래픽을 가져오기 전에 커널이 VPN으로 보내 버릴 수 있습니다. 이때는 VPN 측 분할 터널로 기본 경로를 물리 NIC에 돌려놓거나, Clash 문서에서 안내하는 bypass·route-include·stack 등 Mihomo 계열 옵션으로 로컬·사내 대역을 TUN 처리에서 제외하는 방향을 검토합니다. 구체 키 이름은 사용 중인 코어 버전의 스키마를 확인하세요. TUN 동작 개요는 TUN 모드 가이드와 함께 보시면 전체 그림이 잡힙니다.

재현성 같은 순서라도 절전 해제·Wi-Fi 재연결·VPN 재인증 후에는 라우트가 바뀝니다. 문제가 간헐적이면 «연결 직후 1분 이내의 route print 스냅샷」을 남기세요.

5 Clash 측에서 트래픽 분리하기

OS가 이미 올바른 인터페이스로 보내 주는 트래픽이라면, Clash는 그저 프록시 체인만 투명하게 제공해도 됩니다. 그러나 TUN·시스템 프록시 경로로 들어온 연결에 대해서는 규칙 순서가 생명입니다. 일반적으로는 사내 IP 대역(IP-CIDR, IP-CIDR6)·내부 DNS 이름(DOMAIN-SUFFIX)을 규칙 상단에 두고 DIRECT로 보내, 나머지를 PROXY 그룹으로 넘기는 패턴이 많습니다. 이때 «DIRECT로 보냈다»는 것은 Clash가 로컬 스택에 다시 맡긴다는 뜻이므로, 그다음 홉은 여전히 Windows 라우팅 테이블이 결정합니다. 즉 Clash 규칙과 OS 라우트는 곱셈 관계이지 덧셈으로 한쪽만 고치면 끝나지 않습니다.

GlobalProtect나 AnyConnect가 붙은 뒤에도 특정 공인 IP만 회사망을 거쳐야 한다면, 그 접두사는 VPN 쪽 split tunnel include에 들어 있어야 하고, Clash에서는 해당 대역을 DIRECT로 두어 이중 프록시를 피합니다. 반대로 회사 정책상 모든 인터넷이 VPN을 타야 한다면, 사용자가 Clash로 우회하는 행위 자체가 정책 위반일 수 있으므로 이 문서의 기술을 허가된 시나리오에만 적용해야 합니다.

규칙 예시는 환경마다 다르므로 YAML 전체를 강요하지 않습니다. 대신 원칙만 적습니다. 첫째, LAN·사내 RFC1918 대역을 DIRECT 후보로 명시한다. 둘째, 로그인 포털·캡티브 포털 도메인은 DIRECT로 두어 VPN 인증 자체가 막히지 않게 한다. 셋째, Rule Provider로 긴 목록을 쓰더라도 회사 전용 스니펫을 그보다 위에 둔다. 이렇게 하면 분할 의도가 설정 파일에도 드러나 유지보수가 쉬워집니다.

6 TUN과 시스템 프록시 중 무엇을 쓸까

시스템 프록시는 WinHTTP/브라우저 등 프록시 인식 스택에만 영향을 주는 경량 옵션입니다. 기업 VPN이 전체 터널이어도, «브라우저만 Clash를 태운다»는 식으로 범위를 좁히면 충돌 면적이 줄어듭니다. 반면 터미널·특정 데스크톱 앱은 시스템 프록시를 무시하므로, 그때는 TUN이 필요합니다. TUN은 강력하지만 VPN 가상 NIC·다른 필터 드라이버와 공존 순서를 신경 써야 합니다. UWP·스토어 앱은 Loopback 이슈가 겹칠 수 있어, 시스템 프록시를 쓰는 경우 UWP·Loopback 가이드를 함께 참고하는 것이 좋습니다.

WSL2·가상 머신에서 호스트 Clash를 쓰는 경우에는 또 다른 브리지·NAT 층이 생깁니다. 그때는 WSL2와 Clash 문서의 프록시·DNS 정렬을 먼저 맞춘 뒤, 본문의 라우팅 논의를 적용하세요.

7 DNS가 VPN과 Clash 사이를 흔들 때

연결은 되는데 특정 이름만 타임아웃이면 DNS가 VPN의 내부 리졸버로만 가고, Clash의 fake-ip·DoH 설정과 엇갈리는 경우가 많습니다. 사내 전용 존은 VPN이 붙었을 때만 응답하는 경우가 있어, 해당 접미사는 DIRECT와 함께 «VPN이 제공하는 DNS를 쓰게» 맞추는 편이 안전합니다. 반대로 공인 도메인만 Clash로 보내고 싶다면, 분할 DNS에 해당하는 설정을 클라이언트와 OS 양쪽에서 일관되게 유지해야 합니다. 세부는 DNS 유출 방지 가이드를 참고하세요.

8 보안·컴플라이언스 주의

이 글은 Windows에서 라우팅 테이블과 Clash 규칙을 이해해 동시 연결 문제를 줄이는 기술 참고용입니다. 조직마다 MDM·그룹 정책·호스트 점검으로 클라이언트 변경이 금지되어 있을 수 있고, 분할 터널 자체가 보안 사유로 막혀 있을 수 있습니다. 허가 없이 VPN 정책을 우회하면 징계·법적 문제로 이어질 수 있으므로, 실제 변경 전에는 IT·보안 부서 확인이 선행되어야 합니다. 오픈 소스 Mihomo·Clash 계열 클라이언트의 소스와 이슈 트래커는 GitHub에서 열람할 수 있지만, 설치 패키지는 공식 다운로드 페이지를 통해 받는 편이 출처 관리에 유리합니다.

경고 기밀 취급 정보가 오가는 기기에서 개인 프록시를 병행하는 것은 정보 유출 경로를 늘릴 수 있습니다. 허용된 용도인지 반드시 확인하세요.

9 현장 체크리스트

VPN 연결 전·후 route print -4 또는 Get-NetRoute로 기본 경로와 사내 대역 경로 비교
VPN 클라이언트 설정에 분할 터널·제외 목록이 있는지(잠금 여부 포함) 확인
Clash 로그에서 해당 목적지가 DIRECT인지 프록시인지, DNS는 어디로 갔는지 확인
TUN 사용 시 VPN과의 우선순위·bypass 목록 재점검
시스템 프록시만으로 충분한지(대상 앱이 프록시 인식인지) 판단
정책상 허용되는지 내부 규정·담당자와 최종 확인

한 줄 요약 OS 라우트가 «어디로 나갈지」를 정하고, Clash 규칙은 «그중 Clash를 거친 흐름을 어떻게 나눌지」를 정합니다. 두 층을 같이 보면 기업 VPN과의 공존이 정리됩니다.

10 정리

Windows에서 GlobalProtect·AnyConnect 같은 기업 VPN과 Clash를 동시 연결하려면, 우선 VPN이 만든 라우팅 테이블 변화를 이해하고 분할 터널 가능 여부를 확인하는 것이 출발점입니다. 그 위에서 사내 대역은 DIRECT·VPN 쪽으로, 일반 인터넷은 시스템 프록시나 TUN을 통해 Clash 규칙에 맡기는 식으로 분할하면 «한쪽만 고쳤는데도 안 된다»는 느낌이 줄어듭니다. 메트릭·연결 순서는 환경마다 달라서 스냅샷 비교가 가장 빠른 진단입니다.

같은 목적지라도 앱마다 프록시 인식 여부가 다르다는 점에서, 장기적으로는 Clash Verge Rev처럼 로그·프로필 관리가 쉬운 클라이언트가 유지보수 비용을 낮춥니다. 다른 범용 프록시 도구에 비해 규칙 표현과 커뮤니티 자료가 풍부한 편이라, 라우팅과 규칙을 같이 다듬는 작업에 잘 맞습니다.

설치 파일은 GitHub 릴리스 직링크보다 사이트 다운로드 페이지를 거치는 것을 권장합니다. 소스·라이선스는 저장소에서 확인하되, 실행 파일 출처는 한곳으로 통일해 두면 감사 대응도 단순해집니다.

→ Clash 무료 다운로드 후 Windows에서 VPN과 함께 써 보기

Windows 기업 VPN과 Clash를 동시에:
분할 터널·예외 라우팅으로 트래픽 나누기