Azure GatewaySubnet 설정: 게이트웨이 전에 공간을 예약하세요

포털에서 가상 네트워크를 열고 서브넷 블레이드를 건드리기 전에 주소 공간을 확인하세요. 그 /24가 이미 워크로드 서브넷으로 나뉘어 아무것도 남지 않았다면 /27 예약할 자리가 없고, 결국 다시 나누거나 VNet을 넓혀야 하며 이는 다른 검토가 필요한 다른 변경입니다. 먼저 공간을 확정한 뒤 서브넷을 만드세요.

이 순서가 중요한 이유는 게이트웨이 서브넷이 특별한 이름이 붙은 워크로드 서브넷이 아니기 때문입니다. 관리형 게이트웨이 인스턴스를 위한 주소 예약이며, 예약이 잘못되면 Azure가 게이트웨이를 거부합니다.

주소 공간부터 시작하세요

무엇이든 입력하기 전에 VNet 접두사, 워크로드 서브넷, 게이트웨이 예약을 한 줄에 적으세요. 10.60.0.0/16의 VNet에는 여유가 있습니다. 워크로드 증가가 연속되도록 끝에서 범위를 고르세요.

예를 들어 10.60.255.192/26은 워크로드가 10.60.0.0/20에 머무는 동안 게이트웨이에 64개 주소를 남깁니다. 이것은 주소 계획의 예시이며 크기에 대한 약속이 아닙니다. Microsoft는 현재 Basic이 아닌 VPN 게이트웨이에 /27 이상을 요구하며, 여기서 더 크다는 것은 더 많은 주소를 뜻합니다. /26은 64개, /28은 16개를 줍니다. 주소 계획이 아직 움직이는 동안에는 올림하세요. 절대 내림하지 마세요.

정확한 이름으로 서브넷 만들기

포털에서 서브넷을 추가하고 이름을 GatewaySubnet로 정확히 입력하세요. G는 대문자, S도 대문자이며 공백이나 접미사가 없어야 합니다. Azure는 이 문자열을 대조하므로 Gateway-Subnet이나 gateway는 게이트웨이 서비스가 쓰지 않는 서브넷을 만듭니다.

CLI에서 하는 같은 단계는 검토에 적어 두기 더 쉽습니다:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

서브넷은 비워 두세요. VM도, 프라이빗 엔드포인트도, 서비스 위임도 없습니다. 이미 무언가 살고 있다면 배포가 실패하고 오류는 방해하는 리소스를 좀처럼 지목하지 않으므로, 시작 전에 서브넷의 리소스 목록을 확인하세요.

관리형 서브넷에 워크로드 규칙을 두지 마세요

이 서브넷에 네트워크 보안 그룹을 연결하지 마세요. Microsoft는 이를 지원되지 않음으로 표시합니다. 기본 경로가 0.0.0.0/0을 어딘가로 보내는 경로 테이블도 연결하지 마세요. 게이트웨이 작동을 깨뜨릴 수 있습니다. 게이트웨이 경로 전파는 켜 둔 채로 두세요.

정말로 원했던 액세스 제한은 워크로드 서브넷이나 검사 경계에 두세요. GatewaySubnet을 일반 서브넷처럼 다루는 것이, 깔끔하게 배포된 뒤 아무 트래픽도 통과시키지 않는 게이트웨이를 만드는 실수입니다.

강제 터널링에는 자체 문서화된 설계가 있습니다. 게이트웨이 서브넷에 즉흥적으로 만든 기본 경로는 그것이 아닙니다.

포털이 보여주지 않는 종속성을 확인하세요

만들기를 누르기 전에 목록을 훑으세요. 정확한 이름, VNet 공간 안의 접두사, 온프레미스 범위와 겹치지 않음, 내부에 워크로드 리소스 없음, NSG 없음, 기본 경로가 있는 경로 테이블 없음. 이 모두가 실제 배포를 깨뜨린 적이 있습니다. 그다음 더 넓은 설계를 확인하세요. 온프레미스 쪽의 로컬 네트워크 게이트웨이, 라우팅하려는 주소 공간, 그리고 활성-활성 또는 공존을 계획하는지 여부입니다. 이런 선택은 크기 논의를 바꾸며, 지금 정하는 편이 훨씬 저렴합니다.

서브넷이 VM을 담을 수 없는 이유를 누군가 물을 때 인용할 페이지는 Azure 게이트웨이 설정 참조입니다.

게이트웨이가 이미 있는 경우

게이트웨이 서브넷의 크기를 바꾸거나 교체하는 것은 마스크 편집이 아닙니다. 먼저 게이트웨이 SKU와 세대에 대해 지원되는 변경 절차를 확인하고, 종속 개체를 나열하세요. 연결, 공용 IP, 라우팅, 그리고 모든 복구 요구 사항입니다.

절차가 게이트웨이 재생성을 요구한다면 유지 시간과 롤백이 있는 서비스 마이그레이션으로 계획하세요. 선택한 예약, 그 크기의 이유, 의도적으로 연결하지 않은 규칙을 기록해 두면, 다음 검토자가 NSG를 추가해 빈 서브넷을 고치지 않습니다.