RDP 허용 규칙을 추가해도 VPN 액세스는 좁아지지 않습니다

계획은 그럴듯하게 들립니다: 기존 원격 데스크톱 허용은 그대로 두고, 액세스가 있어야 할 유일한 VPN 클라이언트를 위해 작은 허용을 추가하는 것입니다. Windows Firewall은 그렇게 동작하지 않습니다. 규칙은 가장 구체적인 항목이 이기는 정렬된 목록이 아니며, 넓은 허용 옆에 좁은 허용을 두어도, 넓은 허용이 이미 허용하던 모든 사람을 계속 허용하기 때문에 아무것도 바뀌지 않습니다. 서비스를 좁힌다는 것은 이미 그 일을 하고 있는 허용 자체를 편집한다는 뜻입니다.

추가하는 규칙은 중요한 규칙이 아닙니다

Windows Firewall은 컴퓨터에 적용되는 정책 저장소의 모든 해당 인바운드 규칙을 평가한 다음, 어떤 허용이 일치하는지, 어떤 차단이 그것을 무시하는지를 결정합니다. 규칙을 추가하면 허용이 추가될 뿐, 이미 있는 허용을 제거하거나 한정하지는 않습니다.

따라서 질문은 결코 무엇을 추가했는지가 아닙니다. 질문은 로컬 정책, 도메인 정책, 프로필 기본값이 병합된 후 유효 정책에 무엇이 들어 있는지 입니다. 로컬 규칙이 하나뿐인 워크스테이션은 따져 보기 쉽지만, 도메인에 가입된 서버는 그렇지 않습니다.

그래서 관리자가 올바로 보이는 변경을 하고, 잘못된 컴퓨터에서 시험한 뒤, 작동했다고 결론지을 수 있습니다. 제외된 원본은 시험된 적이 없습니다. 성공만 증명하는 시험은 그 변경이 무엇을 위한 것이었는지의 절반도 증명하지 못합니다.

서버가 어떤 주소를 보는지 알아내세요

무엇이든 범위를 정하기 전에 Windows 호스트에서 허용된 세션 하나를 관찰하고 서버가 보고하는 원본 주소를 기록하세요. 그것은 클라이언트가 자신에게 있다고 믿는 주소와 항상 같지는 않습니다.

VPN 게이트웨이가 클라이언트 주소를 보존하면 서버는 클라이언트의 터널 주소를 보게 되고, 주소로 범위를 정한 규칙은 의미가 있습니다. 게이트웨이가 변환하면 모든 클라이언트가 게이트웨이 주소로 도착하며, 그 주소로 범위를 좁히면 그 뒤의 모든 클라이언트에 액세스를 주게 됩니다. 그러면 그 규칙은 잘못된 대상에 대해 정확합니다.

이 두 설계에는 서로 다른 답이 필요합니다: 첫 번째는 방화벽 규칙으로 표현할 수 있습니다. 두 번째는 신원이 아직 존재하는 곳, 즉 VPN 자체나 서비스 앞의 인증된 게이트웨이에서 강제해야 합니다.

방화벽 필터는 네트워크 변환이 버린 신원을 되찾을 수 없습니다: 주소를 아무리 주의 깊게 입력해도 마찬가지입니다.

유효 규칙의 소유자를 바꾸세요

유효 인바운드 정책을 검사하고 현재 RDP 트래픽을 허용하는 모든 규칙을 찾으세요. 표시 이름에 포트 3389가 전혀 언급되지 않는 규칙도 포함합니다: 서비스로 범위를 정한 규칙과 애플리케이션으로 범위를 정한 규칙도 포함되며, 일부 RDP 배포가 사용하는 UDP 전송도 마찬가지입니다.

그런 다음 그 규칙을 소유한 저장소를 통해 기존 규칙을 편집하세요. 도메인 정책도 정의하는 규칙에 대한 로컬 편집은 병합되거나 무시되거나 덮어써질 수 있으며, 그것에 의존하기 전에 어느 쪽이 일어나는지 아는 것이 좋습니다.

다음 명령은 활성 규칙을 찾고, 그중 하나에 연결된 주소 필터를 표시하고, 범위 변경을 미리 봅니다:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

여기서 규칙 이름은 검토에서 찾은 것의 자리 표시자이며, 미리 보기 플래그는 주소의 오타로 편집 중인 서버에서 잠기지 않도록 존재합니다.

먼저 차단한 뒤 허용하는 것은 다른 모델입니다

다른 방화벽의 습관은 넓은 차단을 쓰고 그 위에 좁은 허용을 두는 것입니다. Windows에서는 명시적 차단이 일반적으로 허용을 이기므로, 그 순서는 한 클라이언트를 위한 예외가 아니라 아무도 도달할 수 없는 서비스를 만듭니다. 결과는 고장 난 RDP 서비스처럼 보이는 중단입니다. 실제로는 우선순위 실수이며, 해결책은 다른 허용을 추가하는 것이 아니라 차단을 제거하는 것입니다.

활성 프로필에서 기본 인바운드 차단 동작을 유지하고 대신 특정 허용을 좁히세요. 그러면 상호 작용이 우선순위 세부 사항에 달려 있는 두 개의 모순된 규칙 대신 하나의 이해 가능한 상태가 컴퓨터에 남습니다.

두 번째 원본으로 증명하세요

허용된 클라이언트에서, 그리고 이제 실패해야 할 원본에서 시험하세요. 성공한 연결 하나는 허용된 경로가 작동한다는 것만 증명하며, 방금 만든 제외에 대해서는 아무것도 말하지 않습니다.

서버에서 사용하도록 설정되어 있으면 IPv6로 시험을 반복하세요: IPv4만을 의도한 경우 아무도 보지 않은 넓은 IPv6 허용과 공존할 수 있기 때문입니다.

마지막으로, 인증을 도달 가능성과 분리해 두세요. 네트워크 수준 인증, 계정 권한, 로그온 제한은 여전히 누가 세션을 사용할 수 있는지 결정하고, 방화벽은 누가 물어볼 수 있는지만 결정합니다. 나중에 장치를 제거할 때는 VPN 등록과 이 네트워크 권한을 모두 제거해야 하며, 그렇지 않으면 범위를 정한 주소는 언젠가 다른 사람의 것이 됩니다.