Azure 피어링인가 VNet 간 VPN인가? 라우팅 전에 결정하라

Azure는 두 가상 네트워크를 연결하는 방법을 최소 두 가지 제공하며, 이는 같은 개체에서 서로 바꿔 쓸 수 있는 설정이 아닙니다. 피어링은 게이트웨이 없이 Microsoft 백본에서 VNet을 연결합니다. VNet 간 VPN은 직접 배포하고 크기를 정하고 감시하는 두 게이트웨이 사이에 IPsec 관계를 놓습니다. 결정은 세 가지 조건으로 좁혀지며, 경로를 추가하기 전에 세 가지 모두에 답할 수 없다면 선택한 적 없는 모델을 위한 우회로를 만들려는 것입니다.

모델을 결정하는 세 가지 조건

첫째는 요구 사항 어딘가에 직접 소유하고 지목할 수 있는 IPsec 경계가 필요한지입니다. 둘째는 주소 공간이 깨끗하고 두 VNet이 서로만 대화하면 되는지입니다. 셋째는 전이 경로와 게이트웨이 청구서를 누가 소유하는지입니다. 이 순서로 답하십시오. 둘째가 아무리 매력적으로 보여도 첫째가 피어링을 배제할 수 있기 때문입니다.

두 모델의 공통점은 엄격한 주소 규칙입니다. VNet 주소 공간은 겹쳐서는 안 됩니다. 피어링도 VNet 간 VPN도 동일한 두 범위를 명확하게 만드는 지원되는 방법이 아니며, 겹침은 다른 연결 유형이 아니라 매핑 설계나 재설계가 필요합니다.

조건 1: 직접 소유하는 IPsec 경계가 필요한가

피어링은 Azure의 사설 백본으로 트래픽을 운반하며 피어링 연결 자체에 VPN 게이트웨이가 필요하지 않습니다. 이것은 전송에 대한 진술이며, 감사자에게 «우리는 IPsec을 운영합니다»라고 건넬 수 있는 암호화 진술이 아닙니다. 요구 사항이 고객이 구성한 터널, 특정 IKE 정책 또는 직접 통제하는 장비에서 종료되는 경계를 지정한다면, 백본이 아무리 사설이어도 피어링은 이를 충족하지 못합니다.

VNet 간 VPN은 그 경계를 제공합니다. 두 게이트웨이, IPsec/IKE 관계, 공유 키, 그리고 그에 따르는 모든 운영 표면입니다. 터널 상태, 게이트웨이 용량, SKU 한도, 터널이 살아 있음을 증명하는 감시를 물려받습니다. 요구 사항이 바로 그 경계에 관한 것일 때 이것이 정답이며, 그 경계는 피어링 개요에서 피어링과 구별되는 연결 유형으로 설명됩니다.

반대 방향에서도 같은 주의가 필요합니다. «VNet 사이에 암호화가 필요하다»는 대개 워크로드 자체의 TLS로 충족되며, 그때 게이트웨이는 뒤에 요구 사항이 없는 비용입니다. 메커니즘을 고르기 전에 감사자가 읽을 문장을 쓰십시오.

조건 2: 토폴로지가 직접인가, 아니면 무언가 전이해야 하는가

피어링은 전이적이지 않습니다. 허브에 피어링된 두 VNet이 그것으로 서로 연결되지는 않으며, 한 방향으로 동작하는 것처럼 보이는 경로는 보통 한쪽에서만 Connected에 도달한 피어링입니다. 양쪽이 존재해야 하고 둘 다 Connected를 보여야 하며, 트래픽이 조용히 사라질 때 가장 먼저 확인하는 것이 그것입니다.

요구 사항이 허브를 통한 온프레미스 도달이라면 게이트웨이 전이는 특정 역할을 가진 별도 설계입니다. 허브가 게이트웨이를 소유하고, 스포크 피어링이 게이트웨이 전이를 허용하며, 스포크는 전달된 트래픽을 허용해야 합니다. 이는 피어링의 속성이지 VNet 연결의 자동 결과가 아닙니다:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

유효 경로 테이블이 «경로가 존재하는가»에 대한 정직한 답입니다. 플랫폼이 실제로 사용할 다음 홉 유형을 보여 주므로, 구성된 것처럼 보이지만 연결되지 않은 피어링은 수수께끼가 아니라 없거나 잘못된 경로로 나타납니다.

조건 3: 전이 경로와 청구서를 누가 소유하는가

추가되는 모든 홉에는 소유자가 있습니다. 피어링에서는 새 VNet이 양쪽의 새 피어링 쌍을 뜻하고, 전이를 위해서는 트래픽을 계속 전달하는 허브와 그것을 계속 가리키는 경로 테이블이 필요합니다. VPN에서는 새 VNet이 또 다른 게이트웨이 또는 기존 게이트웨이 위의 또 다른 연결을 뜻하며, 감시할 자체 용량 한도가 따릅니다.

비용은 같은 모양을 따르지만 같은 항목은 아닙니다. 피어링 요금은 연결과 데이터 전송이고, VPN은 게이트웨이 시간과 자체 전송 요금을 더합니다. 실제로 일 년 동안 운영할 토폴로지의 총액을 비교하십시오. 두 번째 터널과 감시를 포함하고, 오늘의 연결 하나 가격이 아닙니다. 아무도 청구하지 않는 노동도 넣으십시오. 누군가는 키를 돌리고, 터널 상태를 지켜보고, 게이트웨이가 재시작하면 새벽 세 시의 경보에 답해야 합니다. 보통 이 항목이 논쟁을 결정합니다. 견적서에 결코 나타나지 않는 유일한 항목이기 때문입니다.

무엇을 고르든 세 흐름을 시험하십시오. 의도한 것, 거부된 채 남아야 하는 것, 허브 게이트웨이나 피어링이 내려간 복구 사례입니다. 행복한 경로만 설명하는 모델은 검증된 것이 아니라 시연된 것입니다.

선택을 그 자체의 주장과 대조해 검증하라

모델, 경계, 소유자를 지목하는 문장 하나를 쓰고, 배포된 상태가 그것과 맞는지 확인하십시오. 피어링이라면 두 피어링 상태가 모두 Connected, 유효 경로가 목적지 프리픽스에 대한 피어링 다음 홉을 보여 줌, 경로에 게이트웨이가 없음입니다. VNet 간 VPN이라면 두 연결이 모두 Connected, 두 게이트웨이에서 키와 정책이 일치, 다음 홉이 가상 네트워크 게이트웨이인 경로입니다.

확인이 문장과 어긋나면 먼저 문장을 고치십시오. 이런 설계의 혼란 대부분은 아무도 설명하지 않은 혼합에서 옵니다. 워크로드 서브넷에는 피어링, 오래된 서비스 하나에는 VPN, 그리고 조용히 둘 중 하나를 선호하는 경로 테이블입니다.