원격 컴퓨터가 VPN에 연결될 때 RDP가 멈추는 이유

당신은 RDP 창 안에 있고, 데스크톱이 화면에 떠 있으며, 그 원격 머신에서 실행 중인 VPN 클라이언트에서 Connect를 누른다. 몇 초 뒤 창이 멈추고 이내 닫힌다. 터널은 올라왔다. VPN 로그가 보고할 것은 바로 그 사실이며, 그것이 사건 전체에서 가장 쓸모없는 정보다. 세션이 죽은 이유는 대화하던 머신이 당신에게 응답하는 방식을 바꿨기 때문이므로, 터널을 건드리기 전에 반환 경로를 살펴야 한다.

세션이 실제로 사용하는 엔드포인트를 기록하라

RDP 클라이언트에 입력한 주소가 원격 PC가 응답하는 주소와 같다는 보장은 없다. NAT, RD Gateway, 또는 호스트 앞단의 로드 밸런서가 그 주소를 다시 쓸 수 있고, 반환 경로는 원격 머신이 이미 성립된 연결에서 보는 출발지 주소로 결정된다. 여기서 틀리면 관여한 적도 없는 경로를 찾아 나서게 된다.

원격 PC에서 VPN을 연결하기 전에, 성립된 세션을 나열하고 표에서 피어 주소를 읽는다. 그리고 그 머신 밖에 어딘가에 적어 두어라. 세션이 끊긴 뒤에는 읽을 수 없기 때문이다.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

그 주소를 계속 도달 가능해야 하는 대상으로 취급하라. 관리 VLAN의 사설 주소라면 터널은 그 경로를 그대로 두어야 한다. 공인 주소라면 응답은 요청을 들여온 것과 같은 인터페이스로 나가야 한다.

그 엔드포인트에 응답하는 경로를 읽어라

Windows는 목적지마다 인터페이스를 고르고, Find-NetRoute은 지금 내릴 결정을 보여 준다. 연결하기 전에 피어 주소에 대해 실행하고, 터널이 올라온 상태에서 다시 실행한 뒤, 두 답변의 인터페이스 인덱스와 다음 홉을 비교하라. 인터페이스가 바뀌는 것, 그것이 출력 한 줄에 담긴 버그의 전부다.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

전체 터널 프로필은 터널을 지나는 기본 경로를 설치한다. Windows VPN 라우팅 가이드가 설명하듯이, 이제 모든 응답이 VPN을 통해 나가고 상대편이 당신의 클라이언트로 되돌아가는 경로를 갖고 있는지에 달려 있다. 분할 터널 프로필은 기본적으로 더 안전하지만, 피어 주소를 덮는 특정 경로가 물리적 기본 경로를 여전히 이길 수 있기에 면역은 아니다. 어느 쪽이든 질문은 하나다: 터널이 올라온 뒤에도 피어 주소가 세션을 들여온 인터페이스로 해석되는가?

아니라면 수정은 프로필에 속하거나 VPN 정책 소유자가 승인한 명시적 예외 경로에 속한다. 사고 중에 운영 호스트에서 라우팅 테이블을 손으로 고치는 것이 바로 임시 우회책이 문서화되지 않은 구성으로 변하는 방식이다.

방화벽 프로필의 변화를 지켜봐라

새 인터페이스는 나타나는 순간 분류되고, 그 분류가 어떤 방화벽 프로필로 트래픽을 판정할지 결정한다. Public 범주로 떨어진 터널 어댑터는 라우팅 테이블이 완벽해 보여도 인바운드 RDP를 조용히 막을 수 있다. 이것이 두 번째 실패 모드이며 다른 증상을 낸다. 경로는 맞고 패킷은 도착하는데 호스트가 연결을 거부한다.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

터널 인터페이스에 붙은 프로필을 Remote Desktop 규칙이 대상으로 삼는 프로필과 비교하라. Domain과 Private에만 사용하도록 설정된 규칙은 Public으로 분류된 인터페이스에 아무 일도 하지 않으며, 어떤 경로 수정도 그것을 바꾸지 못한다. 일부 VPN 클라이언트는 설계상 로컬 서브넷 접근까지 제한하는데, 이는 다른 제어에서 같은 형태의 실패를 만든다.

복구할 수 있는 곳에서 전환을 시험하라

전체 순서를 대역 외 콘솔이나 두 번째 관리 경로에서 이 순서로 수행하라. 기존 세션을 확인하고, VPN을 연결하고, 새 세션을 열고, 그다음 VPN을 끊고 하나 더 열어라. 각 단계는 서로 다른 전환을 시험하며, 처음 실패하는 지점이 어느 제어가 책임인지 알려 준다.

시작하기 전에 롤백을 예약하라. 예를 들어 정해진 간격 뒤에 rasdial "Work VPN" /disconnect을 실행하는 예약 작업이다. 그것은 잃어버린 세션을 현장 방문 대신 다섯 분짜리 중단으로 바꾸며, 절차 전체에서 가장 싼 보험이다.

세션이 이미 사라진 뒤 다시 들어가라

호스트가 이미 도달 불가능하다면 같은 클라이언트에서 새 RDP 연결을 시도하는 것을 멈추고, 환경이 이미 가진 복구 채널을 사용하라. RD Gateway, 하이퍼바이저 콘솔, 또는 대역 외 관리 인터페이스다. 콘솔 접근 권한이 있는 사람에게 같은 Find-NetRoute과 Get-NetConnectionProfile 명령을 실행해 달라고 요청해, 증거가 복구 이후에도 남게 하라.

그다음 가장 빠른 안이 아니라 영구적인 배열을 결정하라. 관리 경로를 VPN 프로필이 명시적으로 보존하거나, 관리가 호스트의 기본 경로에 의존하지 않는 채널로 옮겨가야 한다. 둘 다 지지할 수 있다. 추측한 게이트웨이를 쓰는 호스트 경로는 그렇지 않다. 어느 쪽을 골랐는지 적고, 살아남아야 했던 피어 주소를 기록하라.