💩 가정
≫ VM01만 공인 IP를 부여함
≫ 외부 → VM01 SSH Port Allow 인바운드 규칙 추가되어 있음
≫ 그 외 추가된 인바운드 규칙 없음
💀 CASE 1
① 기본 정책(AllowVnetInBound)으로 인해 SSH 연결 가능
② 서로 다른 VNet에 존재하기 때문에 SSH 연결 불가
☠️ CASE 2
① 기본 정책(AllowVnetInBound)으로 인해 SSH 연결 가능
② 피어링 연결 후 기본 정책(AllowVnetInBound)으로 인해 SSH 연결 가능
👾 Peering과 NSG의 목적
기본적으로 각각의 VNet은 대역이 다르고 서로의 대역을 모르기 때문에 통신할 수 없습니다.
반대로 말하면 동일한 VNet 안에 있는 서브넷들은 서로의 대역을 알기 때문에 통신이 가능합니다.
(만약 Peering을 구성하지 않은 상태에서 NSG에 10.0.0.4 → 20.0.0.4로 들어오는 모든 트래픽을 허용하는 규칙을 추가해도 통신이 불가합니다.)
Peering은 엄밀히 말하면 리소스가 아니라 VNet의 대역을 알려주는 행위입니다.
NSG의 인바운드 규칙 중 기본 정책(AllowVnetInBound)은 VNet 위에 있는 모든 리소스의 통신을 허용한다는 뜻입니다.
하지만 각각의 VNet은 서로의 대역을 모르기 때문에 정책이 적용되지 않습니다.
≫ 따라서 Peering 연결로 서로의 대역을 알게 하는 것이 1차적인 것이고, 그 안에서 세부적으로 트래픽을 필터링하는 것이 NSG입니다.
🤖 Peering과 NSG의 활용
앞서 말했듯이 VNet 위에 있는 모든 리소스는 NSG의 기본 정책(AllowVnetInBound)으로 인해 통신할 수 있습니다.
또한 VNet 안에는 여러 서브넷이 존재할 수 있습니다.
Peering을 구성한 상태라면 서로 다른 대역의 VNet 위의 리소스들도 NSG의 기본 정책(AllowVnetInBound)에 의해서 통신이 가능하게 됩니다.
그렇다면 Peering 구성에서 특정 서브넷에 있는 리소스의 통신을 거부하고 싶다면 어떻게 할까요?
그럴 때 쓰는 것이 NSG입니다.
≫ NSG는 서브넷 수준 혹은 VM 수준에서 존재하기 때문에 서로 다른 대역의 VNet이 연결되었다고 해도 NSG 수준에서 트래픽을 거부할 수 있는 것입니다.
