VPN 어댑터가 공용 방화벽 프로필에 남는 이유
도메인 로그인은 네트워크를 도메인으로 분류하지 않으며, 개인은 대체가 아닙니다. 먼저 규칙의 프로필을, 그다음 이를 적용하는 컴퓨터를 확인하세요.
터널은 연결되어 있고 계정은 도메인에 대해 인증되었지만, Windows는 여전히 연결을 공용으로 표시합니다. 따라서 도메인 프로필용으로 작성된 방화벽 규칙은 적용되지 않고 파일 공유는 접근할 수 없는 상태로 남습니다. 흔한 해결 시도는 어댑터를 개인으로 설정하는 것인데, 이는 어떤 규칙이 적용되는지만 바꿀 뿐 인증에 관해서는 아무것도 바꾸지 않습니다. 레이블과 해결책 모두 널리 오해되고 있으며, 둘을 분리하려면 세 개의 명령이 필요합니다.
연결한 계정은 네트워크의 범주가 아닙니다
VPN 연결 중에는 두 가지 다른 결정이 내려지며, 이를 혼동하기 쉽습니다. 게이트웨이는 계정이 연결할 수 있는지 결정합니다. Windows는 결과 네트워크를 어떻게 분류할지 결정하며, 그 분류가 인터페이스에 적용되는 방화벽 규칙을 결정합니다.
게이트웨이에서 성공한 도메인 인증은 계정에 대한 증거입니다. 엔드포인트가 네트워크를 도메인 컨트롤러에 대해 인증했다는 증거는 아니며, 도메인 범주가 나타내는 것은 바로 그 점입니다.
그래서 컴퓨터가 도메인에 가입되어 있고 도메인 계정으로 연결해도 여전히 공용으로 표시될 수 있습니다. 분류는 네트워크에 대한 로컬 판단이며, 터널을 연 자격 증명에 대한 진술이 아닙니다. 계정이 완전히 유효해도 레이블은 처음 있던 자리에 그대로 남습니다.
세 범주 중 하나는 설정할 수 없습니다
Windows는 세 가지 범주를 제공하며 관리자가 할당할 수 있는 것은 그중 두 가지뿐입니다. 세 번째는 운영 체제가 네트워크를 도메인 컨트롤러에 대해 성공적으로 인증한 뒤 결정합니다.
| Category | How it is assigned | What it affects |
|---|---|---|
| Public | Default for unidentified networks, or set manually | Rules scoped to the public profile |
| Private | Set manually, or by the user on a trusted network | Rules scoped to the private profile |
| DomainAuthenticated | Determined by Windows after domain authentication | Rules scoped to the domain profile |
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated세 번째 명령은 실패하며, 이는 권한 문제가 아니라 문서화된 동작입니다. 명령 자체의 참조 문서에도 Windows가 도메인 인증에서 도출하기 때문에 도메인 범주는 이런 방식으로 할당할 수 없다고 나옵니다. 오류를 확인하는 것은 범주가 설정이 아니라 결과라는 유용한 확인입니다.
트래픽이 차단된 엔드포인트에서 첫 번째 명령을 실행하십시오. 게이트웨이 자체 인터페이스의 분류는 각 워크스테이션이 자기 터널을 어떻게 분류했는지에 대해 아무것도 알려주지 않습니다.
규칙은 작성된 프로필을 따릅니다
범주를 알면 빠진 접근 권한은 대개 스스로 설명됩니다. 모든 Windows 방화벽 규칙은 프로필 범위를 가지며, 도메인으로 한정된 규칙은 인터페이스가 공용일 때 적용되지 않습니다. 세 개의 명령이 그것을 이론이 아닌 답으로 바꾸며, 세 번째는 프로필이 문제가 아니었던 경우를 잡아냅니다:
(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction두 번째 명령이 모호한 보고를 해결책으로 바꾸는 명령입니다. 규칙이 VPN 풀을 포함하지 않는 원격 주소 범위로 한정되어 있다면 프로필을 바꿔도 도움이 되지 않습니다.
기본 인바운드 동작도 확인하십시오. 인바운드가 기본으로 차단된 컴퓨터에서는 허용 규칙이 없을 때 거부가 아니라 침묵이 생깁니다. 클라이언트 쪽에서는 라우팅 실패와 똑같이 보이기 때문에 이런 티켓의 상당수가 잘못된 가정에서 시작됩니다.
어느 컴퓨터가 규칙을 적용하는지 파악하십시오
범주를 바꾸기 전에 차단이 어디서 일어나는지 확인하십시오. 공유를 호스팅하는 서버에 자체 방화벽이 있을 수 있으며, 그 규칙은 클라이언트가 어댑터에 붙인 이름과 무관하게 VPN 풀에서 오는 트래픽에 적용됩니다. 그곳의 거부는 실행하는 어떤 로컬 명령에도 보이지 않으며, 클라이언트 쪽은 리소스를 사용할 수 없다고만 보고합니다. 클라이언트의 분류를 건드리기 전에 목적지 자체의 규칙을 시험하십시오.
클라이언트에서 특정 포트로 시험한 뒤 같은 VPN의 다른 호스트에서 시험한 결과와 비교하십시오. 둘 다 실패하면 문제는 목적지나 경로에 있습니다. 하나만 실패하면 차이는 해당 컴퓨터에 국한되며, 프로필 범주가 그럴듯한 원인이 됩니다.
방향도 염두에 두십시오. 인바운드 SMB를 허용하는 규칙은 자체 아웃바운드 규칙이 같은 트래픽을 차단하는 클라이언트에게 아무 소용이 없습니다. 파일 탐색기 창에서는 두 실패를 구분할 수 없으므로, 무엇이든 편집하기 전에 각 방향을 따로 시험하십시오.
모두 다시 레이블링하는 대신 무엇을 해야 할까
넓은 규칙을 충족시키려고 알 수 없는 네트워크를 개인으로 만드는 것은 실제 결과를 동반한 실제 변경입니다. 개인 프로필은 보통 공용보다 더 많은 검색과 더 많은 인바운드 트래픽을 허용합니다.
특정 서비스가 VPN 클라이언트에 도달하게 하는 것이 목표라면, 규칙을 프로필이 아니라 원격 주소로 한정하십시오. 그러면 의도를 정확히 표현하고, 분류와 무관하게 작동하며, Windows가 가상 어댑터를 올바로 추측하는지에 의존하지 않습니다. 인터페이스를 다시 분류하는 클라이언트 업데이트도 견딥니다. 풀을 규칙에 적어 두면 다음 사람이 묻지 않고도 의도를 읽을 수 있습니다.
도메인 범주가 정말 기대되는데 전혀 나타나지 않는다면 그것은 별도의 조사입니다. 컴퓨터가 도메인에 가입되어 있는지, 터널을 통해 도메인 컨트롤러에 도달할 수 있는지, 보안 채널이 건강한지 확인하십시오. 다음 세 명령이 레지스트리를 한 번도 편집하지 않고 답합니다:
Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com이 세 가지는 엔드포인트가 애초에 네트워크를 인증할 수 있었는지에 답합니다. 컨트롤러에 도달할 수 없다면 어댑터를 몇 번 재설정해도 도메인 범주는 할당되지 않습니다. 쫓고 있던 방화벽 규칙이 진짜 문제였던 적은 없으며, 레이블은 원인이 아니라 끊긴 경로의 증상이었습니다.