macOS에서 qBittorrent를 VPN 인터페이스에 바인딩하는 방법
macOS의 qBittorrent 고급 설정에서 Network Interface를 지정하고, utun 이름을 실제 터널에 매핑한 뒤 클라이언트를 다시 시작하고, 전송으로 바인딩을 증명합니다.
Mac mini에서 qBittorrent를 열고 Network Interface를 utun4로 설정한 뒤 다시 시작했고, 그다음 VPN은 여전히 정상 연결을 보여주는데 토렌트가 메타데이터 가져오기에서 멈춰 있는 모습을 반나절 동안 지켜봤다. 설정 자체는 원칙적으로 틀리지 않았다. 이름이 낡은 것이었다. macOS는 서비스가 시작될 때마다 utun 번호를 부여하므로, 지난주에 정확했던 utun4는 더 이상 존재하지 않는 터널을 가리켰고, 클라이언트는 경로가 없는 장치에 소켓을 묶고 있었다. 아래 순서가 지금 내가 쓰는 방법이다. 실행 중인 터널에서 인터페이스를 읽고, 클라이언트에서 선택하고, 세션을 다시 시작한 다음, 전송과 의도적인 연결 끊기로 바인딩을 증명한다.
고급 설정을 열고 인터페이스 항목을 찾으세요
qBittorrent 창에서 Cmd+, 로 환경설정을 열고 고급 페이지로 이동한다. 중요한 항목은 Network Interface다. 여기에는 시스템의 인터페이스 이름이 나열되며 기본값은 Any Interface인데, 이는 클라이언트가 여는 모든 소켓에 대해 운영체제가 경로를 선택한다는 뜻이다. 프로젝트의 옵션 설명서 가 이 항목과 그 기본값을 문서화하며, 안에 들어가는 이름은 같지 않더라도 모든 플랫폼에서 같은 설정이다.
여기서 사람들이 걸려 넘어지는 지점이 두 가지다. 목록에는 en0, en1, utun0부터 utun9까지 같은 장치 이름이 나오고 VPN 제공업체의 제품 이름은 절대 나오지 않으므로, 합리적인 선택을 하기 전에 대응 관계를 알아야 한다. 그리고 선택은 BitTorrent 세션이 시작될 때 적용되고 OK를 누르는 순간이 아니므로, 저장된 것처럼 보이는 변경이 여전히 예전 바인딩으로 돌아가고 있을 수 있다.
애플리케이션은 Cmd+Q로 제대로 종료하고 다시 열기 전에 프로세스가 사라졌는지 확인한다. 창을 닫는 것만으로는 숨겨질 뿐이고, 숨겨진 클라이언트는 세션과 수신 포트, 예전 인터페이스를 그대로 유지한다.
pgrep -fl qbittorrentVPN이 실제로 소유한 인터페이스를 찾으세요
먼저 제공업체의 클라이언트로 VPN에 연결하고, 그다음 클라이언트 메뉴가 아니라 시스템의 시각을 읽는다. 아래 명령은 각 인터페이스를 주소와 함께 나열하고, 시스템이 어느 것을 활성으로 보는지 보여 주며, 라우팅 테이블을 출력한다. 찾는 것은 제공업체가 할당한 사설 대역을 가진 utun 장치다.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5세 가지 판독으로 어느 장치가 터널인지 알 수 있다. utun 항목에는 VPN 풀에 속한 inet 주소가 필요하다. scutil --nwi는 시스템이 어떤 인터페이스를 활성으로 보는지와 어느 것이 기본인지 보여 준다. netstat -rn은 기본 경로가 어디를 향하는지 보여 주며, utun에 주소가 있는데도 그 경로가 여전히 en0를 향한다면 터널이 모든 트래픽을 나르지 않는 것이고, 이는 나중에 바인딩이 하는 일을 바꾼다.
두 터널이 동시에 존재할 수 있을 때, 예를 들어 업무용 프로필과 개인용 프로필이 있으면 두 utun 장치가 모두 나타나고 그중 하나만 쓸모가 있다. 바이트 카운터가 답을 준다. 카운터를 기록하고 페이지를 열거나 작은 전송을 시작해 어느 쪽이 움직였는지 본다.
netstat -ib | grep utun번호를 안정적이라고 여기지 마세요. 재연결은 같은 터널에 다른 utun 이름을 줄 수 있고, iCloud나 Continuity 서비스가 VPN이 연결되기 훨씬 전에 utun0을 차지하고 있을 수 있다.
바인딩을 터널의 범위에 맞추세요
이 항목은 장치를 바인딩할 뿐 그 이상은 하지 않는다. VPN이 0.0.0.0/0을 utun으로 라우팅하는 전체 터널이라면, 그 장치에 바인딩하면 모든 피어 연결과 트래커 요청이 VPN을 통과한다. VPN이 몇 개의 서브넷만 라우팅하는 분할 터널이라면, utun에 바인딩하면 피어 트래픽이 그 피어들에 대한 경로가 없는 장치로 가고, 전송은 새어 나가는 대신 멈춘다. 두 결과 모두 Any Interface보다 안전하지만, 클라이언트가 계속 동작하는 것은 하나뿐이다. 클라이언트 밖은 아무것도 바뀌지 않는다. 브라우저와 다른 앱은 자기 경로를 유지하므로, 모든 애플리케이션을 아우르는 요구 사항은 VPN 쪽에서 강제해야 한다.
무엇이든 선택하기 전에 상황을 읽으세요.
| What you see | What it means for the bind |
|---|---|
| A utun with a provider address and the default route pointing at it | Full tunnel; the bind covers peer and tracker traffic |
| A utun with a provider address but the default route still on en0 | Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0 |
| No utun carrying a provider address | The VPN is down or connects on demand; bring it up before selecting |
| A utun number that changed since the last session | The saved name is stale; reselect and restart |
주소 체계도 중요하다. IPv4만 할당하는 제공업체는 바인딩된 인터페이스에 IPv6 주소가 없게 하므로, IPv6 피어는 Wi-Fi로 빠져나가는 대신 실패한다. 별개로, 소켓 바인딩은 이름 해석을 고정하지 않는다. 트래커 호스트 이름은 macOS 리졸버로 해석되며, 이는 선택한 장치가 아니라 시스템의 DNS 구성을 따른다.
올바로 보이는 선택이 실패하는 세 가지 방식
첫 번째 실패는 다시 시작하지 않는 것이다. 항목은 utun4를 보여 주고 설정은 구성된 것처럼 보이는데도 시험 전송은 Wi-Fi로 나간다. 실행 중인 세션이 예전 바인딩을 유지했기 때문이다. 완전히 종료하고 pgrep으로 확인한 뒤 다시 열고 전송을 다시 시작한다.
두 번째는 재연결 후의 낡은 이름이다. 바인딩된 장치가 사라지면 피어 연결이 실패하고, 클라이언트는 인터페이스가 사라졌다는 명확한 메시지 대신 트래커 오류를 보고하는 경향이 있어 죽은 토렌트처럼 보인다. ifconfig를 다시 읽고 새 이름을 선택한 뒤 다시 시작한다.
세 번째는 바인딩이 닫힌 방식으로 실패한다고 가정하는 것이다. 인터페이스를 선택하는 것은 소켓을 장치 이름에 붙이도록 시스템에 요청하는 일이며, 그 이름이 없거나 재사용될 때 무슨 일이 일어나는지는 설정 화면이 보장하지 않는다. 다음 절의 연결 끊기 시험이 유일하게 의미 있는 증거다.
실제 전송과 연결 끊기로 검증하세요
실행이 허용된 전송, 예를 들어 Linux 배포판 이미지를 사용해 VPN이 연결된 상태에서 시작한다. 전후로 인터페이스별 카운터를 보고 VPN 클라이언트 자체의 데이터 카운터와 비교한다. 피어 목록이 차는 동안 둘 다 함께 올라가야 한다.
netstat -ib | grep utun
pgrep -fl qbittorrent그다음 VPN을 자체 화면에서 연결 해제하고 전송을 관찰한다. 피어는 사라지고 새 연결은 터널이 끊긴 직후 실패해야 한다. 속도가 계속된다면 바인딩이 적용되지 않은 것이고, 방화벽이 아니라 다시 시작 단계로 돌아온 것이다.
다시 연결하고 선택한 이름을 한 번 더 확인한다. 터널이 다른 utun으로 돌아올 수 있기 때문이다. 터널 유형, 인터페이스 이름, VPN이 끊길 때 예상되는 동작을 짧게 기록해 두면 다음 세션이 편해진다. 이 설정은 컴퓨터마다, 제공업체마다 다르며, 클라이언트 업그레이드나 VPN 앱 변경을 견디지 못한다.