Windows에서 VPN이 로컬 LAN을 차단할 때: 경로 문제인가 클라이언트 정책인가?

업무용 VPN이 연결되는 순간 책상 위의 프린터, NAS, 개발 장비가 응답을 멈춘다. 경로 명령 하나로 몇 초 만에 해결될 때도 있고, 같은 경로가 올바른데도 패킷이 계속 사라질 때도 있는데, 그때는 비슷한 증상을 가진 다른 문제를 보고 있는 것이다. 판단은 세 가지 질문으로 좁혀지며, 이 순서를 잘못 잡는 것이 사람들이 저녁 내내 경로를 지웠다 다시 추가하는 이유다.

명령을 치기 전의 세 가지 질문

첫째, 로컬 접두사에 대한 항목이 있고 그것이 물리 어댑터를 가리키는가? 둘째, 연결할 때 클라이언트가 게이트웨이로부터 로컬 네트워크 허용 또는 거부를 받는가? 셋째, LAN으로 나가는 접근만 필요한가, 아니면 인터넷의 무언가도 내 컴퓨터에서 도는 서비스에 도달해야 하는가?

첫 질문은 라우팅 결함과 필터링 결함을 구분한다. 둘째는 경로 수정이 애초에 허용되는지 알려 준다. 셋째는 수리를 바꾼다: 경로는 나가는 트래픽을 고치지만, 도달할 수 없는 들어오는 서비스는 보통 리스너 바인딩과 반환 경로 문제이며 경로가 오히려 악화시킨다.

질문 하나: 경로, 필터, 아니면 이름

무언가를 추가하기 전에 표를 읽어라. 인터페이스 인덱스가 중요한데, 아래의 모든 경로 명령이 거기에 고정되어 있다:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

직접 연결된 서브넷은 터널이 올라와 있어도 보통 온링크 경로를 유지하므로, 항목이 존재해도 트래픽이 실패할 수 있다. 그 조합은 라우팅 뒤에 실행되는 필터의 서명이며, 더 구체적인 두 번째 경로가 아무것도 바꾸지 못하는 경우다.

주소와 이름으로 따로 시험하라. ping 192.168.1.50이 응답하고 net view 192.168.1.50이 응답하지 않는다면 라우팅 표는 처음부터 문제가 아니었다: 터널이 리졸버를 바꿨고 로컬 이름이 더 이상 해석되지 않는다. 그것 때문에 경로를 추가하는 것은 헛수고다.

질문 둘: 게이트웨이가 로컬 LAN 접근을 허용하는가?

상용 클라이언트는 경로 이상을 설치한다. 연결할 때 정책을 받고, 그 정책에 로컬 네트워크에 대한 명시적 허용이 포함될 수 있다. Cisco IPsec 배포에서는 그룹 정책이 스플릿 터널링 설정과 로컬 LAN 접근용 별도 플래그를 담는다; 클라이언트의 확인란은 게이트웨이가 거부할 수 있는 요청이다. AnyConnect에서는 프로필이 스플릿의 포함 및 제외 목록과 같은 허용을 제어한다. Windows RRAS에서는 프로필의 기본 게이트웨이 옵션과 서버가 할당하는 정적 경로가 그에 해당한다.

플래그가 꺼져 있을 때 문서화된 동작은, 유효하고 더 구체적인 경로가 있어도 클라이언트가 직접 연결된 서브넷으로 가는 트래픽을 차단한다는 것이다. 클라이언트가 소유하지 않은 경로가 추가한 지 몇 초 만에 사라질 수 있는 것도 같은 이유다: 클라이언트는 지시받은 상태를 다시 만드는 중이며 당신과 싸우는 것이 아니다.

클라이언트 로그는 연결 시점의 결정을 기록하며, 그것을 읽는 것이 장비에서의 어떤 실험보다 빠르다. 로그가 로컬 접근이 차단되었다고 하면 멈춰라: 어떤 명령줄 수정도 그것을 이겨내지 못하며, 남은 길은 정책 변경, 터널을 통한 리소스 접근, 또는 클라이언트를 가상 머신에 가두고 호스트를 로컬 네트워크에 남겨 두는 것뿐이다.

질문 셋: 어느 방향이 필요한가?

가까운 장치로 나가는 트래픽은 라우팅 문제다. LAN 접두사를 로컬 게이트웨이로 향하게 하되, 터널의 기본 경로를 이길 만큼 낮은 메트릭을 주어라:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

두 번째 형식은 장치 하나를 고정한다. 주소 하나가 요구 사항의 전부일 때 원하는 것이 바로 그것이고, netsh에 해당하는 것은 같은 결정을 인덱스 대신 인터페이스 이름으로 기록한다:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

주소와 마스크가 맞지 않으면 경로 명령은 매개 변수가 잘못되었습니다로 실패한다(예를 들어 /24 마스크를 가진 호스트 주소). 서브넷 경로에는 네트워크 주소를, 단일 호스트에는 호스트 마스크를 사용하라.

들어오는 방향은 다르다. 같은 장비의 VNC나 SSH 서버는 들어오는 연결에 대한 응답이 VPN 게이트웨이로 나가 돌아오지 않으면 도달할 수 없게 된다. 경로를 건드리기 전에 서비스가 무엇을 듣는지 확인하라:

netstat -ano | findstr :5900

특정 주소 하나에 바인딩된 리스너는 다른 인터페이스에서는 응답하지 않는다. 그것을 모든 인터페이스에 바인딩하는 것은 의도적인 결정이며, 신뢰하는 네트워크로 범위를 좁힌 방화벽 규칙과 함께 한다. 그 뒤에야 경로 수리가 반환 경로를 복원한다.

맞는 가장 작은 변경을 적용하라

또 다른 흔한 조치는 IPv4 고급 속성에서 “원격 네트워크에서 기본 게이트웨이 사용”의 선택을 해제하는 것이다. 인터넷 트래픽은 로컬로 유지되지만 동시에 두 가지 일이 일어난다: VPN이 기본 경로가 아니게 되고, 클라이언트는 멀티캐스트를 포함한 원격 네트워크 경로를 받지 않게 된다. 해제하면 서버가 모든 클라이언트에 필요한 특정 원격 접두사를 밀어 넣지 않는 한 원격 LAN은 사라진다.

그 비대칭이 작업 순서를 결정한다. 원격 쪽이 완전히 도달 가능해야 한다면 서버에서 원격 서브넷을 밀어 넣고 로컬 기본 경로는 그대로 두어라. 서버를 바꿀 수 없다면 터널이 할당한 주소를 통해 원격 접두사에 영구 경로를 추가하고, route print로 접두사가 VPN 인터페이스를 가리키며 기본 경로는 여전히 물리 게이트웨이를 가리키는지 확인하라.

그다음 수리가 재연결 후에도 유지되는지 확인하라(비영구 경로는 어댑터와 함께 사라지고, 연결할 때마다 실행되는 스크립트가 그것을 두는 정직한 자리이기 때문이다). 같은 세션에서 로컬 장치 하나와 원격 리소스 하나를 시험하고, 연결을 끊었다가 다시 연결해 다시 시험하라. 경로가 올바르게 보이는데도 로컬 장치가 계속 실패하면 질문 둘로 돌아가라: 클라이언트가 필터링하고 있으며, 답은 두 번째 경쟁 경로가 아니라 정책 변경이다.