Windows에서 VPN이 실제로 무엇을 라우팅하는지 PowerShell로 확인하는 방법

Windows 11 노트북에서 VPN 클라이언트를 연결하자 타일이 Connected로 바뀌고 내부 파일 공유가 열렸으며, 공개 사이트는 여전히 사무실 Wi-Fi에서 직접 로드되었습니다. 이 혼합은 끊어진 터널처럼 보입니다. 하지만 일부 트래픽은 VPN으로 보내고 나머지는 물리 어댑터에 남기는 프로필의 정상적인 출력입니다. 강제 터널링은 Windows가 어떤 기본 경로를 선호하는지만 바꾸며, 더 구체적인 경로를 삭제하지 않고 연결이 끊길 때 트래픽이 멈춘다고 약속하지도 않습니다. 다음은 클라이언트가 커버리지를 주장할 때 제가 따르는 순서입니다: 클라이언트 상태, 저장된 프로필, 적용된 경로, 확인자, 그다음 실제 흐름.

클라이언트에서 시작하고, 그다음 그를 믿지 마세요

클라이언트가 시작점으로 적합한 이유는 어떤 프로필이 활성인지 알려 주기 때문입니다. 연결 속성을 열고 정확한 프로필 이름, 현재 사용자용인지 컴퓨터의 모든 사용자용인지, 연결 후 ncpa.cpl에 어떤 어댑터가 나타나는지 기록하세요. 제 테스트 노트북에서는 어댑터가 프로필 이름을 달고 있어 경로 출력을 읽기 쉬웠습니다. 다른 컴퓨터에서는 WAN Miniport 항목으로 나타나며 이름만으로는 아무것도 알 수 없습니다.

클라이언트가 알려 줄 수 없는 것은 커버리지입니다. 연결된 타일은 터널의 상태를 설명할 뿐 대상 목록이 아닙니다. 타사 클라이언트도 자체 구성을 유지하므로, 네이티브 Windows 프로필과 그에서 읽을 모든 속성은 해당 클라이언트가 설치한 것과 무관할 수 있습니다. VPN이 AnyConnect, OpenVPN GUI, WireGuard 또는 공급업체 에이전트를 통해 설치되었다면 아래 PowerShell 검사는 대부분 적용되지 않으며 대신 그 클라이언트의 분할 터널 및 라우팅 설정을 읽어야 합니다.

저장된 프로필을 읽고, 타일은 읽지 마세요

네이티브 Windows 프로필(IKEv2, L2TP, SSTP 또는 MDM이 배포한 프로필)에서 저장된 분할 터널 결정은 속성 하나입니다.

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

프로필이 장치의 모든 사용자용으로 만들어졌다면 -AllUserConnection를 추가하세요. 이 옵션이 없으면 현재 사용자 목록을 읽게 되며, 이 목록은 비어 있거나 비슷한 이름의 다른 항목을 담고 있을 수 있습니다. False 값이 SplitTunneling에 있으면 프로필이 전체 터널로 저장되었다는 뜻입니다: Windows는 VPN 어댑터를 통한 기본 경로를 설치합니다. True는 분할 터널을 뜻하며, 커버리지는 그 프로필이 푸시하는 경로와 이름 확인 규칙에 전적으로 달려 있습니다.

그 값을 구성으로 취급하고 관측으로 취급하지 마세요. 연결 시점에 프로필이 요청한 내용을 기록할 뿐입니다. Windows는 다른 인터페이스의 더 구체적인 경로, 정책 설정 또는 이전 연결의 잔여 항목 때문에 적용된 경로가 달라질 수 있으므로, 이 불리언 값만으로는 질문이 해결되지 않습니다.

저장된 값을 적용된 라우팅 테이블과 비교하세요

연결 후에는 전체 테이블을 스크롤하는 대신 터널 어댑터의 경로를 나열하세요.

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Find-NetRoute이 유용한 절반입니다. 클라이언트가 결코 답하지 않는 질문에 답합니다: 이 대상에 대해 Windows가 실제로 어떤 인터페이스와 어떤 원본 주소를 사용할까요? 내부 호스트, 공개 호스트, 의도적인 예외라고 생각하는 모든 대상에 대해 실행하세요. 전체 터널 프로필은 공개 주소에 대해 터널 인터페이스를 보여 주어야 합니다. 분할 터널 프로필은 보통 그 자리에 물리 어댑터를 보여 주며 내부 접두사는 여전히 VPN으로 확인됩니다.

「잘못된 방향으로 라우팅한다」는 보고의 대부분은 두 가지 함정으로 설명됩니다. 가장 구체적인 접두사가 항상 이기므로 물리 어댑터의 /24는 터널 메트릭이 아무리 낮아도 VPN의 기본 경로를 이깁니다. 메트릭은 같은 접두사 경로 사이의 동점만 가릅니다. 그리고 IPv4와 IPv6는 따로 결정됩니다: 0.0.0.0/0을 포함하는 프로필도 IPv6를 로컬 링크에 남길 수 있어 이중 스택 사이트가 절반만 터널링된 것처럼 보입니다. 터널이 정상이라고 결론 내리기 전에 Get-NetRoute -AddressFamily IPv6을 확인하세요.

NRPT로 이름 확인을 따로 점검하세요

내부 IP 주소는 되는데 내부 이름이 실패한다면 라우팅이 아니라 확인자 정책을 가리킵니다. Windows는 이름 공간마다 이름 확인 정책 테이블로 DNS를 결정하며, 이는 라우팅 테이블과 독립적입니다.

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

규칙이 *.corp.example과 일치하면 해당 이름 공간의 쿼리는 터널의 DNS 서버로 가며, 분할 터널 모드에서 그 서버로 가는 데이터 경로가 물리 어댑터에 남아 있어도 마찬가지입니다. 그것이 설계이며, 공개 사이트를 여는 브라우저 테스트가 내부 이름에 대해 아무것도 알려 주지 않는 이유입니다. 어댑터가 예상 서버를 나열하는데도 조회가 다른 곳으로 간다면 NRPT 규칙 순서를 비교하고 더 구체적인 이름 공간이 먼저 일치하는지 확인하세요.

흐름을 검증하고, 그다음 실제로 무엇을 요청했는지 결정하세요

결과를 컴퓨터 간에 비교할 수 있도록 대상을 정해진 순서로 확인하세요: 공개 주소, 내부 주소, 내부 이름, 그리고 로컬 프린터나 화상 통화 같은 의도적인 예외 하나입니다. 각 대상에 대해 Find-NetRoute가 반환하는 인터페이스와 원본 주소를 기록하세요. 정책을 변경한 뒤에는 다시 연결하고 같은 네 가지 검사를 반복해야 하며, 재연결 후의 라우팅 테이블만이 새 프로필이 적용되었다는 증거입니다.

다음으로 라우팅과 강제를 분리하세요. 강제 터널링은 터널이 올라와 있는 동안 대상 트래픽에 터널을 선호합니다. 킬 스위치는 아닙니다. 터널이 끊길 때 컴퓨터에서 아무것도 나가지 않아야 한다는 요구라면 차단 설계에서 와야 합니다: 터널 상태에 묶인 방화벽 프로필, 트래픽 필터가 있는 상시 연결 프로필, 또는 공급업체 클라이언트 자체의 실패 시 차단 옵션입니다. 강제 터널링은 VPN 서버 자체의 주소를 터널 밖에서도 접근 가능하게 남겨야 하며, 「모든 것을 강제」한다는 이름으로 그것을 차단하면 적용하려는 연결에서 스스로 잠기는 확실한 방법입니다.

무엇이든 바꾸기 전에 이 목록을 확인하세요. 실패하는 항목은 실제 문제가 어디에 있는지 좁혀 줍니다.

• 프로필 이름과 범위를 확인했고, 컴퓨터 전체 프로필에는 -AllUserConnection을 사용했습니다.
• SplitTunneling를 읽고 커버리지의 증거가 아니라 구성으로 취급했습니다.
• 터널 어댑터 경로를 IPv4와 IPv6에 대해 따로 나열했습니다.
• 공개, 내부, 예외 대상 각각 하나씩에 대해 Find-NetRoute를 실행했습니다.
• 이름 실패를 경로 탓으로 돌리기 전에 NRPT 규칙을 확인했습니다.
• 차단 요구 사항을 다시 읽었습니다: 선호 라우팅은 강제 차단과 같지 않습니다.

전체 터널인지 분할 터널인지의 결정은 프로필 소유자에게 있으며, Microsoft의 라우팅 노트는 프로필이 설정할 때 Windows가 구현하는 동작을 설명합니다. Microsoft: 강제 및 분할 터널링은 출력을 읽을 때 제가 열어 두는 참조입니다.