TUN은 시스템 프록시를 사용하지 않는 앱의 트래픽도 처리할 수 있지만, TUN을 켠다고 모든 연결이 프록시를 통과하는 것은 아닙니다. 이 글에서는 Windows 데스크톱용 v2rayN을 기준으로 가상 네트워크 어댑터, 관리자 권한, DNS와 라우팅 규칙의 관계를 설명하고, 사전 점검부터 연결 확인과 문제 발생 시 복구까지 안내합니다. 다른 데스크톱 운영체제는 권한 부여 방식이 다르므로 Windows의 권한 상승 절차를 그대로 적용하지 마세요.
1. TUN 모드와 시스템 프록시의 처리 범위
브라우저가 시스템 프록시를 통해 인터넷에 접속된다고 해서 다른 앱도 프록시를 사용한다는 뜻은 아닙니다. 시스템 프록시는 앱에 프록시 주소를 제공하며, 이를 따를지는 앱 구현에 달려 있습니다. TUN은 가상 3계층 네트워크 인터페이스를 만들고 운영체제의 라우팅을 통해 조건에 맞는 IP 패킷을 처리 프로그램으로 전달합니다. 이후 규칙에 따라 직접 연결하거나 프록시를 거치거나 차단합니다.
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 트래픽 유입 경로 | 앱이 프록시 설정을 읽고 로컬 프록시 포트에 연결 | 시스템 라우팅이 패킷을 가상 네트워크 어댑터로 전달 |
| 앱의 지원 여부 | 대체로 앱이 프록시 설정을 지원하고 따라야 함 | 대체로 앱별 프록시 설정이 필요하지 않음 |
| UDP 트래픽 | 시스템 HTTP 프록시만으로는 모두 처리하기 어려움 | 처리할 수 있지만 커널, 프로토콜, 서버 지원 여부에 따라 달라짐 |
| 권한 요건 | 대체로 네트워크 어댑터 생성 권한이 필요하지 않음 | 대체로 권한 상승 또는 사전 설정된 서비스 방식이 필요함 |
| 최종 연결 경로 | 앱 설정과 클라이언트 규칙에 따라 결정 | 트래픽 처리 범위와 클라이언트 규칙에 따라 결정 |
‘전체 트래픽 처리’는 유입 범위를, ‘전체 프록시’는 연결 경로 정책을 가리키며 서로 다른 설정입니다. TUN이 실행 중이어도 로컬 네트워크 주소, 로컬 도메인 또는 규칙에서 지정한 대상은 직접 연결될 수 있습니다. 반대로 전체 프록시 라우팅을 선택해도 클라이언트에 들어오지 않은 연결까지 처리할 수는 없습니다.
TUN을 켜도 노드 대역폭이 늘어나거나 서버가 지원하지 않는 UDP 연결이 갑자기 작동하지는 않습니다. 브라우저만 프록시를 사용하면 된다면 시스템 프록시가 설정과 복구 면에서 더 간단합니다. 앱이 시스템 프록시를 우회하는 경우에 TUN을 고려하세요.
2. 가상 네트워크 어댑터가 데이터를 프록시 커널로 전달하는 방식
TUN이 받는 것은 브라우저의 전체 URL이 아니라 IP 패킷입니다. 클라이언트는 대상 주소, 확인할 수 있는 도메인 정보, DNS 처리 결과를 바탕으로 규칙을 적용합니다. 도메인 정보가 보존되는지는 DNS 처리 방식, 스니핑, 앱 자체의 이름 해석 방식에 따라 다르므로 모든 연결에서 도메인을 확인할 수 있다고 단정할 수 없습니다.
v2rayN은 설정과 관리를 위한 인터페이스이며 실제 연결 처리는 함께 제공되는 커널이 담당합니다. TUN 처리 과정과 노드에 사용하는 프록시 커널은 별도 프로세스일 수 있고, 세부 구현은 클라이언트 버전에 따라 달라집니다. 문제가 발생하면 화면의 스위치 상태만 보지 말고 TUN 시작 로그와 프록시 아웃바운드 로그를 함께 확인하세요.
- 네트워크 어댑터는 트래픽 유입을 담당합니다: 가상 네트워크 어댑터가 보인다는 사실만으로 인터페이스가 생성되었을 가능성만 확인할 수 있습니다. 라우팅과 DNS까지 적용되었다고 볼 수는 없습니다.
- 라우팅은 트래픽 분기를 담당합니다: 각 대상 주소를 직접 연결할지 프록시를 거칠지는 규칙에 따라 달라지며, 규칙의 순서도 결과에 영향을 줍니다.
- 아웃바운드는 연결을 담당합니다: VLESS, VMess 등의 노드 설정이 유효해야 합니다. TUN으로 만료된 구독이나 잘못된 인증 정보를 해결할 수는 없습니다.
- 루프 방지는 안정성을 좌우합니다: 클라이언트에서 서버로 향하는 연결이 다시 클라이언트에 의해 처리되지 않도록 해야 합니다. 시스템 기본 경로를 임의로 수정하기보다 클라이언트가 생성한 설정을 우선 사용하세요.
3. 시작 전 권한, 포트, 기존 네트워크 프로그램 확인
먼저 시스템 프록시 모드가 정상 작동하는지 확인한 다음 TUN으로 전환하세요. 이렇게 하면 ‘노드 연결 문제’와 ‘가상 네트워크 어댑터 처리 실패’를 구분할 수 있습니다. 구독을 가져온 뒤 사용 가능한 서버를 선택해 실제 웹페이지에 접속해 보세요. 지연 시간만 확인해서는 DNS, TLS 연결, 페이지 리소스 로딩까지 정상인지 알 수 없습니다.
‘설정’ → ‘환경 설정’에서 로컬 수신 주소와 포트를 확인하세요. 여기서는 127.0.0.1:10808을 예로 들 뿐, 기존 설정을 이 값으로 바꾸라는 뜻은 아닙니다. TUN을 켠다고 모든 앱이 10808에 연결되는 것은 아닙니다. 이 포트는 기존 로컬 프록시 경로와 가상 네트워크 어댑터 경로를 구분하는 데 주로 쓰입니다.
- 현재 설정 저장: 현재 서버, 라우팅 모드, 로컬 포트, DNS 옵션을 기록해 두세요. 설정 백업은 접근을 통제할 수 있는 곳에 보관하고, 화면을 공유하기 전에는 구독 주소와 인증 정보를 가리세요.
- 권한 요건 확인: Windows에서 인터페이스를 만들고 라우팅을 변경하려면 대체로 관리자 권한이 필요합니다. 조직에서 관리하는 기기라면 먼저 허가를 받으세요. 단말 보안 정책을 우회하지 마세요.
- 중복 처리 방지: 테스트할 때는 다른 가상 네트워크 어댑터 기반 프록시나 VPN을 먼저 종료해 두세요. 두 프로그램이 동시에 기본 경로를 변경하는 상황을 피할 수 있습니다. 회사 네트워크 구성 요소를 함부로 제거하지 마세요.
- 설치 상태 확인: 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 사용하고, 함께 제공된 커널 파일을 보존하세요. 로그에 파일 누락이 표시되면 스위치를 반복해서 켜고 끄기보다 설치를 먼저 복구하세요.
4. Windows에서 v2rayN TUN을 켜는 순서
컨트롤 위치는 버전에 따라 다를 수 있으며, 일반적으로 메인 창 아래쪽에 ‘TUN 사용’ 항목이 있습니다. 서비스 모드를 제공하는 경우 미리 설치한 서비스가 권한을 대신 처리할 수도 있습니다. 이 방식을 설정하지 않았다면 관리자 권한으로 실행해 확인하는 것이 우선입니다. 권한 요청 창이 반복해서 뜬다고 권한 부여가 완료된 것은 아닙니다.
- 종료 후 관리자 권한으로 실행: 먼저 시스템 트레이 메뉴에서 v2rayN을 종료한 뒤 프로그램이나 바로 가기를 마우스 오른쪽 버튼으로 클릭해 ‘관리자 권한으로 실행’을 선택하고 권한 요청을 확인하세요. 메인 창을 닫기만 하면 트레이에 최소화되어 있을 수 있습니다.
- 확인된 서버 선택: 시스템 프록시 모드에서 정상 접속을 확인한 노드를 그대로 사용하세요. 이때 프로토콜, 구독, 라우팅 규칙을 동시에 변경하지 마세요.
- 라우팅 정책 유지: ‘설정’ → ‘라우팅 설정’에서 현재 규칙을 확인하세요. 테스트 중에는 기존에 정상 작동한 정책을 유지하고, 로컬 네트워크를 직접 연결해야 하는지도 확인하세요.
- 시스템 프록시 경로 분리: 시스템 프록시를 ‘시스템 프록시 해제’로 전환한 다음 ‘TUN 사용’을 켜세요. 그러면 브라우저 접속이 성공했을 때 기존 시스템 프록시 경로의 영향을 덜 받습니다.
- 시작 로그 확인: 권한 부족, 어댑터 생성 실패, 주소 충돌, 포트 점유 오류가 없는지 확인하세요. 오류가 발생하면 처음으로 명확하게 실패한 항목부터 해결하고 스위치를 연달아 켜고 끄지 마세요.
- 확인 후 복구 경로 유지: 같은 테스트 사이트에 접속한 다음, 원래 시스템 프록시를 사용하지 않던 앱도 확인하세요. 접속이 안 되면 TUN을 먼저 끄고 이전 시스템 프록시 설정을 복원해 기본 연결이 정상인지 확인하세요.
문제 해결을 위해 시스템 방화벽을 장시간 끄지 마세요. 보안 프로그램이 관련 프로세스를 차단한다면 프로그램 경로와 출처, 조직 정책을 확인한 뒤 필요한 네트워크 접근만 최소한으로 허용하세요.
5. DNS와 라우팅 설정: 트래픽 처리 후에도 확인할 항목
DNS 조회와 실제 서비스 연결은 서로 관련되지만 별개의 경로입니다. DNS 조회에 성공해도 서비스 연결이 프록시를 통과한다고 볼 수 없으며, 서비스 연결이 TUN으로 들어와도 도메인이 원격에서 해석된다는 뜻은 아닙니다. 특정 DNS 주소로 일괄 변경하기보다 실제 트래픽 분기 목적에 맞게 설정하는 편이 안전합니다.
앱의 연결 경로
- 시스템 프록시
- TUN 확인 전 먼저 해제
- TUN 상태
- 활성화한 뒤 시작 로그 확인
- 로컬 포트
- 10808은 이 글의 예시일 뿐
- 라우팅 정책
- 검증된 트래픽 분기 규칙 유지
노드 문제를 네트워크 어댑터 문제로 오해하지 않도록 한 번에 하나씩만 변경하세요.
도메인 이름 해석 경로
- 일반 DNS 조회
- 대개 UDP 또는 TCP 53 사용
- 암호화된 DNS
- 실제 연결 경로를 별도로 확인
- 내부 네트워크 도메인
- 접속 가능한 내부 DNS 서버 유지
- IPv6
- 주소, 라우팅, 트래픽 처리 범위 확인
DNS 처리 옵션은 현재 커널 설정과 일치해야 합니다. 다른 커널의 설정 항목을 그대로 붙여 넣지 마세요.
브라우저에서 암호화 DNS를 사용하면 DNS 조회 연결이 일반 암호화 트래픽처럼 보일 수 있습니다. 포트 53만 확인해서는 DNS가 어디로 전달되는지 판단할 수 없습니다. 회사 내부 도메인이 내부 DNS에 의존한다면 공용 DNS로 모두 보내는 방식은 오히려 실패할 수 있습니다. 내부 도메인의 DNS 경로를 유지하고, 해당 DNS 서버에 예상한 연결 경로로 접속할 수 있는지도 확인하세요.
- 로컬 네트워크 접근: 프린터, 공유 폴더, 게이트웨이 관리 페이지는 대개 직접 연결해야 합니다. 기존 사설 IP 주소 규칙을 우선 사용하고, 테스트를 위해 규칙 전체를 함부로 삭제하지 마세요.
- IPv6 경로 확인: IPv4만 처리하도록 설정했는데 앱이 IPv6를 우선 사용하면 두 종류의 연결이 서로 다른 경로로 나갈 수 있습니다. 먼저 로그와 시스템 라우팅을 확인한 뒤 어느 쪽을 조정할지 결정하세요.
- 규칙과 커널 확인: V2Ray, Xray 및 기타 연동 커널의 DNS·라우팅 설정 항목은 서로 호환된다고 단정할 수 없습니다. 변경하기 전에 실제로 실행 중인 커널과 설정 형식을 확인하세요.
6. 스위치 상태가 아닌 실제 TUN 작동 여부 확인
제대로 확인하려면 인터페이스, 규칙 적용 결과, 실제 앱을 모두 살펴봐야 합니다. 한 번의 외부 IP 조회는 해당 요청의 결과만 보여 줄 뿐, 모든 프로세스와 대상이 같은 경로를 사용한다는 증거가 아닙니다. 규칙에 따라 테스트 사이트가 직접 연결된다면 로컬 네트워크의 외부 IP가 표시되는 것도 정상일 수 있습니다.
- 인터페이스 확인: Windows 네트워크 어댑터 목록에서 새 가상 인터페이스를 찾고 로그를 통해 이번 실행에서 생성된 것인지 확인하세요. 인터페이스 이름은 버전에 따라 달라질 수 있으므로 특정 이름만으로 판단하지 마세요.
- 라우팅 확인: 명령 프롬프트에서 아래의 읽기 전용 명령을 실행해 IPv4와 IPv6 라우팅을 확인하세요. TUN은 더 구체적인 경로를 사용해 트래픽을 처리할 수 있으므로 기본 경로를 직접 바꾸지 않을 수도 있습니다.
- 연결 확인: 대상 앱을 실행하고 클라이언트 로그에서 대상 주소, 적용된 규칙, 아웃바운드 결과를 살펴보세요. 해당 기록이 없다면 앱이 별도 터널을 사용하거나 다른 네트워크 인터페이스에 바인딩되어 있는지도 확인하세요.
- 전후 결과 비교: 시스템 프록시를 해제한 상태로 유지하면서 TUN을 켰을 때와 껐을 때 같은 앱의 접속 결과를 기록하세요. 비교를 마친 뒤 필요한 설정을 복원하세요.
ipconfig /all
route print -4
route print -6이 명령은 네트워크 상태를 확인할 뿐 라우팅을 변경하지 않습니다. 출력에 로컬 주소와 내부 네트워크 정보가 포함될 수 있으므로 그대로 공개하지 마세요. 로그에 프록시 아웃바운드 규칙이 적용된 것으로 표시되더라도 요청이 실제로 성공했는지 확인해야 합니다. ‘규칙 적용’과 ‘원격 연결 수립’은 서로 다른 단계입니다.
7. TUN 작동 오류와 인터넷 연결 문제 FAQ
TUN을 켜자마자 인터넷이 끊기면 DNS를 바꿔야 할까요, 노드를 바꿔야 할까요?
먼저 TUN을 끄고 이전에 정상 작동했던 시스템 프록시 상태로 복원하세요. 기존 노드로 여전히 접속할 수 있다면 TUN 시작 로그, 관리자 권한, 다른 가상 네트워크 어댑터와의 충돌부터 확인하세요. 시스템 프록시도 작동하지 않는다면 노드와 기본 네트워크를 점검하세요. DNS, 노드, 라우팅을 한꺼번에 변경하지 마세요.
권한 부족 메시지가 뜨는데 스위치를 켜도 왜 작동하지 않나요?
먼저 시스템 트레이에서 프로그램을 완전히 종료한 다음 관리자 권한으로 실행하고 권한 요청을 확인하세요. 조직에서 관리하는 기기라면 가상 네트워크 어댑터 생성이 허용되는지도 확인해야 합니다. 서비스를 사용하는 버전은 해당 서비스가 실행 중인지도 확인하세요. 화면의 선택 상태만 보고 권한이 적용되었다고 판단하지 마세요.
웹페이지는 열리는데 게임이나 음성 통화는 연결되지 않아요.
먼저 로그에서 해당 앱의 연결을 찾아 TUN으로 들어왔는지, 어떤 규칙이 적용되었는지 확인한 뒤 노드와 서버가 해당 UDP 트래픽을 지원하는지 살펴보세요. 지연 시간 테스트에 성공해도 이 조건까지 검증된 것은 아닙니다. 앱이 특정 네트워크 어댑터에 바인딩되어 있다면 앱 자체의 네트워크 설정도 확인하세요.
TUN을 켠 뒤 회사 내부망이나 프린터가 보이지 않아요.
로컬 네트워크 대상이 직접 연결되는지, 내부 도메인이 접속 가능한 내부 DNS를 계속 사용하는지 확인하세요. 확인된 내부 IP 주소를 이용해 DNS 문제와 라우팅 문제를 구분하고, 내부 네트워크 전체를 프록시 서버로 강제 전송하지 마세요. 회사 네트워크 정책과 관련된 변경은 관리자의 확인을 받으세요.
창을 닫았는데도 영향이 남아 있어요. 어떻게 복구하나요?
창을 닫아도 트레이에 숨겨졌을 수 있습니다. 먼저 메인 화면에서 TUN을 끄고 시스템 프록시를 해제한 다음, 트레이에서 프로그램을 종료하고 인터페이스와 라우팅이 복구되었는지 확인하세요. 프로그램이 비정상 종료됐다면 다시 실행해 정상적으로 한 번 종료하세요. 그래도 설정이 남아 있으면 시스템을 재부팅할 수 있지만, 정체를 알 수 없는 네트워크 어댑터를 직접 삭제하지 마세요.
안정적인 설정 순서는 노드 확인, TUN 유입 경로 확인, DNS와 트래픽 분기 조정입니다. 매번 한 항목만 변경하고 이전 상태로 되돌릴 방법을 마련해 두세요. 그래야 ‘트래픽 처리 실패’, ‘이름 해석 실패’, ‘아웃바운드 연결 실패’를 구분할 수 있어 재설치나 무분별한 규칙 변경을 줄일 수 있습니다.