부제: split tunneling 으로 차단된 사이트에만 VPN 사용
할 것
- VPN 에 연결 (여기에서는 다루지 않음)
- VPN 을 사용하는 디폴트(기본) 라우팅을 지움
- 프린세스 커넥트 re:Dive 게임 서버(app.priconne-redive.jp) 의 ip 을 확인
- 게임 서버의 ip 에 접속할 때 VPN 네트워크 어댑터를 사용하도록 라우팅을 추가
1. VPN에 연결
여기에서는 protonVPN을 사용하였다. 아무 VPN이라도 무방함.
protonVPN 1.5.0 에서 1.5.1 로 업데이트 함에 따라 VPN으로의 기본 라우팅을 지울 경우 인터넷 접속이 되지 않는 문제가 발생했다. 검색해보니 VPN 어플리케이션에 따라 윈도우의 라우팅 기능에 간섭하는 경우가 있다는 듯하다. protonVPN의 경우 업데이트하면서 kill switch 의 버그가 발생한 것 같은데 (해당 기능을 켜지 않았음에도 VPN을 통하지 않는 네트워크가 모두 차단됨) 아무튼 이것으로 보아 윈도우의 기본 VPN 기능을 사용하지 않고 어플리케이션을 설치하여 사용하는 타입의 경우는 이 문서가 적용되지 않을 수 있다.
2. VPN을 사용하는 디폴트(기본) 라우팅을 지움
윈도우의 기본 vpn 네트워크 기능을 이용하면 일반적인 네트워크 어댑터와는 다른 형태로 네트워크 어댑터가 생긴다. openVPN 을 사용하는 경우에는 가상 드라이버를 사용하는 네트워크 어댑터가 생긴다. 하지만 어느 경우에도, vpn에 연결하게 되면 가상 네트워크 어댑터가 생기고 이를 통하여 네트워크 트래픽이 전송되도록 시스템의 라우트 테이블이 작성된다. (기본 VPN 어댑터의 경우 고급 TCP/IP 옵션에서 디폴트 라우팅을 생성하지 않도록 지정할 수 있다. 고급-일반-원격 네트워크에서 기본 게이트웨이 사용 을 해제하면 디폴트 라우팅을 생성하지 않는다.)
기본 내장 route.exe 를 사용할 수도 있지만 프론트엔드를 제공하는 nirsoft 의 NetRouteView 를 실행하여 확인한다. 관리자로 실행 메뉴가 있긴 하나 버그가 있는지 처음에 보통 권한으로 실행한 경우 라우팅 테이블 수정이 안 되는 문제가 있으므로 처음부터 관리자로 실행하도록 한다. 권한 관련 문제가 아니고 metric 값 관련 문제인 것으로 확인되었다.
metric 은 해당 route 을 사용할 때 드는 cost 를 의미하는 것으로, windows 는 이 값이 낮은 순서대로 연결을 시도한다.
그러므로 위에서부터 메트릭이 낮은 순서대로, destination 0.0.0.0 mask 128.0.0.0 은 0.0.0.0~127.255.255.255 까지의 대역을 뜻하고, interface IP 10.8.8.6 는 10.8.8.6 이라는 ip 가 설정된 네트워크 어댑터를 통해 해당 트래픽을 보낸다는 뜻이다. 그리고 여기에서 속하지 않는 ip들은 아래로 내려가면서 일치하는 route 규칙이 있는지 찾아 routing 되게 된다.
… 는 것이 windows 의 기술문서나 wikipedia 의 네트워크 라우팅 항목을 보면 나오는 내용이지만, metric 이전에 더 구체적인 destination 이 더 우선되는 것으로 보인다.
위의 예에서, 185.xxx.xxx.xxx/32 는 ip 확인 사이트에서 확인할 수 있는 vpn 서버의 ip이다. vpn 의 구조상 서버 ip에는 실제 네트워크 어댑터를 통하여 연결되어야 하는데, 이것이 그것을 처리하기 위한 라우팅 규칙으로 보인다. 그런데 이 규칙의 metric 값은 10 인데, 위를 보면 이보다 낮은 metric 3을 가진 128.0.0.0/1 에도 포함되는 ip이다. 그러면 어느 라우트를 사용하는가? vpn이 정상 작동하는 것으로 보아 metric 값이 높아도 destination 을 더 구체적으로 지정한 라우팅이 사용된 것으로 보인다.
이 뿐 아니라 192.0.0.0/24 도 metric 이 3보다 높게 지정되어 있음에도 실제 어댑터의 로컬 서브넷에는 정상 작동되는 것으로 보아, metric 값은 destination 이 동일한 수준에서 중복 지정되었을 때 우선순위를 정하기 위한 값으로 보인다.
아무튼 여기에서는 VPN 의 네트워크 어댑터를 사용하는 디폴트 라우팅을 지운다. 0.0.0.0/0 또는 위 사진에서는 0.0.0.0/1 과 128.0.0.0/1 을 지운다.
만약 실제 네트워크 어댑터에 할당된 디폴트 라우팅이 남아있지 않다면 추가해준다.
기본 라우팅의 예. 0.0.0.0/0 에 인터페이스 네임이 실제 네트워크 어댑터가 맞는지 확인한다. 위의 예에서는 Broadcom Netlink (TM) Gigabit Ethernet 어댑터이다.
3. 프린세스 커넥트 re:Dive 게임 서버(app.priconne-redive.jp) 의 ip 을 확인
fiddler 를 통해 확인해보면 게임이 접속하는 서버는 다음과 같다.
게임 서버: app.priconne-redive.jp
게임 리소스 CDN: priconne-redive.akamaized.net
기타: omotenashi.cygames.jp, analytics.app-adforce.jp, graph.facebook.com, android.clients.google.com
omotenashi.cygames.jp 의 경우는 계정 생성을 담당하는 서버인 것으로 보인다. 또한 계정 연동에도 사용하는 것으로 보인다.
게임의 UI 상에는 ID가 0으로 표시되는 상태에서 튜토리얼을 시작하지 않고 메뉴의 일괄 다운로드로 리소스만 다운받는 중에 VM 을 복사해본 결과, 원본과 복사본이 같은 계정으로 시작되었다. 그러므로 계정 생성은 게임을 처음 켜자마자 사용자 입력을 기다리지 않고 시작되는 것으로 보이는데, 그 과정에서 접속하는 서버 중에는 omotenashi.cygames.jp 가 가장 유력해보인다.
graph.facebook.com, android.clients.google.com 는 각각 facebook, google play 계정 연동에 사용되는 것으로 보인다.
analytics.app-adforce.jp 는 검색해본 결과 광고 경로를 수집하는 사이트라는데, 정확히 무슨 데이터를 수집하는지 불명확하다.
아무튼 이 중 게임 서버만 지역 락이 걸려있으므로 게임서버만 VPN을 통해서 연결해주면 된다.
nslookup.exe 를 사용하여 ip 를 확인한다.
nslookup app.priconne-redive.jp
2018-06-07 현재 ip 는 203.104.108.141 이다.
4. 게임 서버의 ip 에 접속할 때 VPN 네트워크 어댑터를 사용하도록 라우팅을 추가
다시 NetRouteView 로 돌아가 새 라우팅을 추가한다.
destination: 게임 서버의 ip 를 적는다.
203.104.108.141
mask: 모든 주소가 일치하는 ip 에 대해서만 적용한다.
255.255.255.255
gateway: vpn 의 게이트웨이를 적는다. 이것은 vpn 마다 다르다.
metric: 이전에 같은 규칙을 만들지 않았다면 뭐든 상관없다. metric 값을 너무 작게 지정하면 “하나 이상의 인수가 올바르지 않습니다” 라는 에러를 띄운다. 이유는 잘 모르겠다. 적당히 큰 값 (약 100 가량)을 입력하면 정상적으로 추가된다.
interface: vpn 의 네트워크 어댑터를 고른다.
persistent: 재부팅해도 규칙이 유지되게 하려면 Yes, 아니면 No. 기본값은 No 이다. Yes 로 하고 추가하면 표에서 Persistent 로 표시되지만 실제 재부팅 후 사라지는 것 같다. route add -p 명령을 썼을 때에는 유지되는 것으로 보임.
원래는 게임 서버만 vpn 을 써서 접속하고 다른 어플리케이션에서는 vpn 을 통하지 않고 사용하여 전체 대역폭을 활용하려는 계획이었다. 그런데 이번에 테스트한 vpn이 vpn을 통하고도 속도가 충분히 빠르게 나와서 빛이 바랬다. 그래도 나중에 참조를 위해 남겨두도록 한다.
정확한 용어에 대해서는 조금 혼란스럽다. split tunneling 이 가장 오래되고 정확한 표현인 것으로 보이지만 이 키워드로 검색했을 때에는 검색 결과는 별로 좋지 않았다. 다른 후보로는 selective routing 이 역시 검색어로서는 별로인 듯하다.
2018-06-08: protonVPN 클라이언트를 1.5.0 에서 1.5.1 로 업데이트한 후 vpn 의 기본 라우팅을 지우면 외부로의 네트워크가 작동하지 않는 것을 발견하여 VPN 어플리케이션을 사용할 시의 문제를 업데이트함.
2018-06-10: route 추가 시의 문제가 권한 문제가 아니고 metric 값의 문제임을 확인. 관련 내용을 수정.
2018-06-10 17:28: netrouteview 에서 persistent 옵션이 적용되지 않는 문제가 확인됨.
2018-06-23: 윈도우의 기본 VPN 어댑터 사용 시 기본 라우팅을 추가하지 않도록 하는 내용을 추가.
Reference
NetRouteView:
https://www.nirsoft.net/utils/network_route_view.html
IPv4 CIDR blocks:
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks
How to Add a Static TCP/IP Route to the Windows Routing Table:
https://www.howtogeek.com/howto/windows/adding-a-tcpip-route-to-the-windows-routing-table/
Add a static IP route:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc757323%28v%3dws.10%29
The IP routing table:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc779122(v=ws.10)
Direct versus indirect routing:
http://osr507doc.xinuos.com/en/NetAdminG/iproutingC.direct_indirect.html
Split Tunneling for Concurrent Access to the Internet and an Intranet:
https://technet.microsoft.com/en-us/library/bb878117.aspx