Azure 사이트 간 VPN 트래픽에 NSG를 적용할 위치

사이트 간 터널은 작동하고, 온프레미스 클라이언트는 일부 Azure 호스트에는 도달하지만 다른 호스트에는 도달하지 않습니다. 그래서 누군가가 이를 고치려고 GatewaySubnet에 네트워크 보안 그룹을 연결했습니다. 거기서 멈추세요. Azure는 GatewaySubnet에서 NSG를 지원하지 않으며, 그 그룹은 워크로드 규칙처럼 내부 패킷을 볼 수 없습니다. 정책을 대상 서브넷이나 NIC에 두고, 복호화 후에 존재하는 원본 주소를 일치시키고, 오래된 연결이 아닌 새 연결로 확인하세요.

Azure가 평가하는 위치에 NSG를 두세요

워크로드 필터링에 지원되는 경계는 대상 서브넷 또는 대상 네트워크 인터페이스입니다. 게이트웨이 서브넷은 인프라이며, Azure는 그곳에서 NSG가 지원되지 않고 게이트웨이 작동을 손상시킬 수 있다고 문서화합니다.

배치에는 논리적 문제도 있습니다. GatewaySubnet의 NSG는 두 게이트웨이에 속한 주소를 가진 외부 IPsec 교환을 평가하게 됩니다. 애플리케이션 규칙에는 터널 내부의 사설 원본이 필요하고, 그 패킷은 게이트웨이가 복호화한 후에만 존재합니다. 그룹을 워크로드 서브넷에 연결하면 규칙은 원래 의도한 주소를 봅니다.

무엇이든 바꾸기 전에 현재 연결을 확인해 무엇을 옮기는지 파악하세요.

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

복호화 후 원본 주소를 찾으세요

내부 원본은 온프레미스 클라이언트의 사설 주소이거나, 어플라이언스나 VPN NAT가 변환 후 제시하는 주소입니다. 온프레미스 VPN 게이트웨이의 공인 주소가 아니며, 그것은 외부 교환에 속합니다.

NAT가 설계의 일부라면 가정하지 말고 제시된 원본을 확인하세요. Azure VM에서의 패킷 캡처나 서비스 연결 로그의 원본 필드가 온프레미스 구성을 읽는 것보다 질문을 빨리 정리합니다. 그런 다음 해당 주소와 실제 대상 포트에 대해 규칙을 작성하세요.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

노출하려는 서비스마다 규칙 하나를 사용하고 포트 목록은 짧게 유지하세요. 온프레미스 범위의 모든 포트를 허용하는 규칙은 NSG를 형식적인 것으로 만듭니다.

기본 VirtualNetwork 범위를 확인하세요

VirtualNetwork 서비스 태그는 로컬 가상 네트워크보다 넓습니다. 그 정의에는 연결된 온프레미스 주소 공간, 피어링된 네트워크, 게이트웨이로 연결된 다른 접두사가 포함됩니다. 따라서 VirtualNetwork로 범위가 지정된 기본 허용 규칙은 운영자가 외부로 여겼던 터널 트래픽을 이미 허용할 수 있습니다.

좁은 규칙을 추가하기 전에 기본 규칙을 읽고, 먼저 일치할 수 있는 높은 우선 순위 규칙을 모두 읽으세요. 명시적 허용을 추가해도 이미 흐름을 허용하는 더 넓은 규칙은 제거되지 않습니다. 정책이 거부를 요구하는 경우 허용보다 실제로 먼저 평가되는 우선 순위에 두세요.

Microsoft의 서비스 태그 설명서는 VirtualNetwork 태그가 무엇을 포함하는지 나열하며, 태그가 VNet 범위만 의미한다고 주장할 때 인용할 참고 자료입니다.

양쪽 경계에서 유효 규칙을 읽으세요

서브넷 NSG와 NIC NSG가 모두 적용되면 흐름은 둘 다 만족해야 합니다. 한쪽의 허용이 다른 쪽의 거부를 무효화하지 않으며, 패킷이 실제로 마주치는 것은 집계된 보기입니다.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Azure Virtual Network Manager 보안 관리자 규칙이 관여한다면 그 계층도 검토하세요. 관리자 Always allow 규칙은 NSG 평가 없이 트래픽을 전달할 수 있고, 관리자 Deny는 NSG가 보기 전에 중지합니다. 그런 구성에서는 NSG만 검토하는 것은 불완전합니다.

NSG는 상태 저장 방식입니다. 규칙을 편집해도 기존 허용 연결이 반드시 종료되지는 않으므로 수용 테스트에는 새 흐름이 필요합니다. 이 속성은 운영에서 유용하고 변경 작업 중에는 오해를 부릅니다.

새 연결로 확인하세요

온프레미스 클라이언트에서 서비스 포트로 새 세션을 열고, 거부되어야 하는 호스트에서 다시 반복하세요. VM 쪽에서도 흐름 테스트를 실행해 반환 경로가 온전한지 확인하세요.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG 허용은 하나의 액세스 결정이며 경로도 리스너도 아닙니다. 규칙이 흐름을 허용하는데 연결이 여전히 실패하면 그룹을 다시 편집하기 전에 VPN으로 들어가는 클라이언트 경로, Azure의 반환 경로, 호스트 방화벽을 확인하세요. 실제 원본 주소, NSG 연결, 일치하는 규칙을 승인된 서비스와 함께 기록하세요. 다음 피어링이나 경로 변경이 VirtualNetwork 태그의 범위를 바꿀 수 있기 때문입니다.