SMB 방화벽 규칙의 LocalSubnet은 VPN 클라이언트를 포함하지 않습니다
LocalSubnet 허용 규칙은 서버 자체의 서브넷을 포함하며, 라우팅된 VPN 풀은 포함하지 않습니다. 범위를 넓히기 전에 서버가 보는 원본 주소를 비교하십시오.
사무실 데스크톱은 공유에 접근하지만 VPN 사용자는 시간 초과가 나고, 같은 계정이 휴대폰 핫스폿에서는 작동합니다. 공유 권한이 차이인 경우는 드물고, 보통 파일 서버에 도착하는 주소가 차이입니다. LocalSubnet으로 범위가 제한된 규칙은 서버 자체에 연결된 서브넷을 허용하며, 별도로 라우팅된 VPN 풀은 그중 하나가 아닙니다. 두 가지 설계가 이 간극을 메우지만 남기는 기록은 크게 다릅니다.
두 가지 설계, 하나의 증상
첫 번째 설계는 규칙의 원격 주소 조건에 VPN 풀을 추가합니다. 그러면 서버가 각 클라이언트의 터널 주소를 보므로 로그에서 한 원격 사용자를 다른 사용자와 구분할 수 있습니다. 두 번째 설계는 VPN 트래픽을 서버가 보기 전에 LAN 주소로 변환하는 게이트웨이를 통해 라우팅합니다. 이렇게 하면 연결이 복구되지만 같은 단계에서 구분도 사라집니다.
표는 주소가 아니라 역할을 설명하며, 어느 행이 적용되는지는 자신의 접두사가 결정합니다. 블로그 글의 예를 복사하지 말고 서버의 실제 값을 출력하십시오:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength표는 결정을 돕는 도구이며 모든 배포에 대한 주장이 아닙니다. 추가 인터페이스, 두 번째 사이트 링크 또는 다른 마스크를 가진 호스트는 로컬 집합이 다릅니다.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft의 New-NetFirewallRule 참조는 원격 주소 조건과 LocalSubnet 키워드를 문서화합니다. 이 키워드가 모든 사설 주소를 의미한다고 판단하기 전에 읽어 보십시오. 실제로 그렇지 않습니다.
서버가 실제로 받는 것을 비교하십시오
누군가가 만들었다고 기억하는 규칙이 아니라 실제 적용되는 규칙을 읽으십시오. 규칙이 활성화되어 있는지, 활성 프로필에 적용되는지, 원격 주소 조건이 서버가 보는 원본과 일치하는지 확인하십시오. Domain 프로필에서만 활성화된 규칙은 네트워크 변경 후 어댑터가 Public으로 넘어가면 아무 효과가 없습니다.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction첫 번째 명령은 파일 공유 규칙에 연결된 주소 필터를 출력하고, 두 번째는 어떤 프로필이 활성인지, 일치하지 않는 인바운드 트래픽이 어떻게 처리되는지를 보여 줍니다. 차단 규칙과 중앙에서 관리되는 정책도 찾아보십시오. 차단 규칙은 허용 규칙보다 우선하며, 로컬 규칙 병합을 사용하지 않도록 하는 정책은 새 로컬 예외를 무효로 만들 수 있습니다.
콘솔에서 규칙이 올바르게 보이는데 트래픽에 효과가 없는 경우가 바로 이것입니다. 동시에 프로필 할당을 확인하십시오. 다른 네트워크에 가입한 노트북은 누구도 방화벽을 건드리지 않아도 Public 프로필로 이동할 수 있습니다.
로그인 전에 전송을 테스트하십시오
연결 가능성과 인증을 분리하십시오. TCP 445의 수신기는 서비스가 포트에 바인딩되었음을 증명하지만, 원격 패킷이 도달할 수 있음을 증명하지는 않습니다. 반대로 완료된 TCP 연결은 SMB 세션 설정이나 공유 권한에 대해 아직 아무것도 말하지 않습니다. 규칙을 편집하기 전에 양쪽에서 핸드셰이크를 테스트하십시오.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed첫 번째 명령은 실행하는 시스템에서 TCP 핸드셰이크가 성공하는지 보고하고, 두 번째는 확인된 주소와 인터페이스 세부 정보를 추가합니다. VPN 클라이언트와 사무실 데스크톱에서 실행한 뒤 비교하십시오. Ping은 두 질문 모두에 답하지 않습니다. SMB가 열려 있어도 ICMP가 차단될 수 있고, 방화벽이 445를 버려도 허용될 수 있기 때문입니다.
VPN에서만 핸드셰이크가 실패하면 원본 범위가 주요 용의자입니다. 성공하는데도 공유가 계속 거부하면 방화벽 규칙을 편집하는 대신 SMB 세션과 권한 진단으로 넘어가십시오.
원본 NAT가 구분을 없앨 때
경로에 변환이 있으면 서버는 개별 VPN 클라이언트를 주소로 구분할 수 없습니다. 모든 원격 사용자는 게이트웨이로 도착합니다. 이들을 구분하는 데 의존하는 모든 권한 부여는 신원이 여전히 보이는 곳, 보통 VPN 집중기나 인증 프록시에서 시행해야 합니다. 방화벽 규칙은 트래픽을 허용할 수 있지만 변환이 없앤 구분을 복원할 수는 없습니다.
그 게이트웨이 주소가 허용되면 모든 원격 사용자가 하나의 주소로 기록되므로, 규칙은 게이트웨이에 도달할 수 있는 모든 사람에게 풀 전체를 부여합니다. 사용자별 판단이 중요하다면 원래 주소를 볼 수 있게 유지하거나 사용자를 여전히 아는 계층으로 판단을 옮기십시오. 그렇지 않으면 모든 원격 사용자가 서버가 볼 수 있는 단 하나의 주소 권한을 물려받고, 감사 추적은 나중에 이들을 구분할 수 없습니다. 이는 설계 결정이며 방화벽의 세부 사항이 아닙니다.
두 설계 중 하나를 의도적으로 선택하십시오. 서버가 누가 연결되었는지 봐야 한다면 규칙을 실제 VPN 풀로 제한하고, 서버가 그 정보를 정말로 필요로 하지 않을 때만 변환된 경로를 받아들이십시오. 선택한 원본 범위를 규칙 옆에 기록하십시오. 다음에 이 문제를 디버그할 사람은 먼저 주소 표를 보게 될 것이기 때문입니다.