터널은 연결되었다고 보고하고 위키는 여전히 로드된다. 그러다 다운로드가 멈추고 선반 위의 공유가 응답을 멈춘다. 터널은 제 일을 했고, 프로필은 그저 모든 목적지를 주장했을 뿐이다.

Windows는 VPN 연결을 경로 결정으로 취급한다. 그 결정이 좁혀질 때까지 기계는 사무실로 이사한 것처럼 행동한다.

작동하는 터널이 왜 장애처럼 느껴지는가

원격 게이트웨이 사용이 허용된 프로필은 터널을 통한 기본 경로를 설치한다. 그러면 로컬 링크에 없는 모든 목적지가 사무실 방화벽을 통해 나간다. 로컬 공유는 응답을 멈추는데, 그 트래픽이 이제 다른 대륙까지 갔다가 돌아오기 때문이다. 클라이언트 상태에는 그것이 전혀 드러나지 않는다.

증상은 일부러 혼란스럽다. 공유가 시간 초과되는 동안 이름 확인은 여전히 동작할 수 있고, 그 반대도 마찬가지다. 사용자는 VPN이 고장 났다고 하고, 클라이언트는 자신이 정상이라고 하며, 두 진술 모두 정확하다.

IPv4 대화 상자에 숨어 있는 확인란

설정은 여러 대화 상자 깊숙이 있다. ncpa.cpl 를 열고 연결을 마우스 오른쪽 단추로 클릭한 다음 IPv4 속성, 고급으로 가서 연결이 원격 기본 게이트웨이가 되도록 하는 옵션을 지운다. 그 상자 하나가 프로필이 전체 터널인지 결정한다. 프로필의 다른 모든 설정은 여전히 적용된다.

다시 연결하기 전과 후에 route print -4 을 비교한다. 예전에 터널을 가리키던 0.0.0.0 항목은 사라져야 하고, 회사 접두사는 여전히 남아 있어야 한다.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

인터페이스 메트릭을 바꾸는 것은 대체가 아니다. 메트릭은 경쟁하는 두 기본 경로 사이에서만 결정하며, 연결할 때마다 자기 기본 경로를 다시 설치하는 클라이언트는 어떤 숫자를 설정하든 그 경쟁에서 이긴다.

아무도 목록에 넣지 않은 접두사

분할 터널링은 프로필에 기록된 접두사만 노출한다. 프로필을 쓴 뒤에 추가된 사무실 서브넷은 터널이 완전히 건강해도 도달할 수 없는 채로 남는다. 그러면 보고는 고장 난 VPN이 아니라 고장 난 서버 하나로 들어온다.

손으로 추가한 경로는 게이트웨이 주소가 바뀔 때까지 빈틈을 메운다. 접두사를 연결에 기록하는 편이 더 튼튼하다, 추측한 주소가 아니라 연결을 따라가기 때문이다.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

저장된 목록과 실제 표를 함께 읽는다. 저장된 접두사가 있어도 연결이 올라온 뒤 관리 에이전트가 경로를 걸러 내면 표에는 결코 들어가지 않을 수 있다. 반대로 레지스트리 경로가 꺼진 어댑터를 가리키는 경우도 있다. 어느 한쪽 시각만으로는 전체 이야기를 말할 수 없다.

재부팅 후 결과를 증명하기

양방향으로 추적하고 이름으로 확인한다. 공용 추적은 ISP를 통해 나가야 하고, 내부 추적은 터널로 들어가야 하며, 내부 호스트는 주소만이 아니라 이름으로도 응답해야 한다.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

연결 끊기, 다시 연결, 재부팅을 한 번씩 한 뒤 반복한다. 수동 재연결을 견디고 재시작 후 사라지는 접두사는 프로필에 저장된 적이 없었다.

프린터와 NAS도 시험에 남긴다. 노트북 옆의 장치를 끊어 버리는 분할 터널은 더 작고 더 성가신 문제를 만들어 하나를 해결한 것이기 때문에, 매개 변수의 철자를 모듈 버전과 맞춰 보는 곳은 Microsoft의 Add-VpnConnectionRoute 참조다.

관련 글