Azure VM의 RRAS는 지원되지 않습니다: 설계 전에 확인하세요

포털을 열고 Windows Server 2022를 서브넷에 배포하면 Remote Access 역할이 문제없이 설치됩니다. 이 순서가 증명하는 것은 설치 관리자가 작동한다는 것이지, Microsoft가 그 구성을 지원한다는 것이 아닙니다. Azure 가상 머신용으로 게시된 서버 소프트웨어 지원 지침은 RRAS를 Azure VM에서 지원되지 않는 Windows Server 기능에 포함시키며, 이는 문제 해결의 세부 사항이 아니라 아키텍처 결정입니다. 터널이 올라온다고 해서 배포가 지원 경계 안으로 들어가는 것은 아닙니다.

아래 안내는 지원 페이지에서 시작해 요구 사항과 대체 옵션으로 나아갑니다.

랩이 아니라 지원 페이지에서 시작하세요

무엇이든 규모를 정하기 전에 Azure VM 지원 지침을 읽으세요. 이 지침은 Windows Server를 하나의 구분 없는 블록으로 취급하는 대신 지원되는 제품, 역할, 기능을 분리합니다. 의도한 워크로드가 실제로 어느 행에 속하는지, 그리고 콘솔에서 관련 있어 보이는 두 구성 요소가 서로 다른 행에 있을 수 있는지 확인하세요.

페이지가 열려 있는 동안 설계 문서에 인용을 적어 두세요. 지원 상태는 출처가 있는 사실이며, 이를 인용할 수 없는 설계 검토는 데모를 가진 사람에게 논파됩니다.

OS 지원과 역할 및 기능 지원을 분리하세요

같은 지침은 Network Policy and Access Services를 지원되는 역할에 포함시키면서 RRAS는 별도로 지원되지 않는다고 나열합니다. 이 두 항목은 서로 다른 것을 설명하며, 이를 “원격 액세스가 지원된다”로 합치는 것이 잘못 읽은 것을 근거로 프로젝트가 승인되는 방식입니다. 운영 체제가 지원된다는 사실은 자체 행을 가진 기능에 대해 아무것도 말해 주지 않습니다.

이 제한은 때때로 인용되는 것보다도 좁습니다. Azure VM 내부에서 실행되는 그 기능에 관한 것이며, 사설 네트워크가 Azure에 연결할 수 없다는 뜻도 아니고 RRAS가 어디에서나 지원되지 않는다는 뜻도 아닙니다. 패킷을 올바르게 전달하는 오래된 랩은 패킷에 대한 증거이지, 지원 진술에 대한 증거가 아닙니다.

프로젝트의 나머지 기간 동안 이 두 질문, 즉 작동하는가, 그리고 지원되는가를 분리하세요. 각각에 다른 답과 때로는 다른 담당자가 필요합니다.

설계가 실제로 무엇을 해야 하는지 적으세요

대체안을 고르기 전에 사이트 목록을 제품을 측정할 수 있는 요구 사항으로 바꾸세요:

• 지사 장비가 이미 사용하는 터널 프로토콜, 그리고 동적 라우팅이 필요한 사이트가 있는지 여부.
• 원격 접두사, 라우팅이 아니라 변환이 필요한 겹치는 주소 공간을 포함합니다.
• Azure와의 경로 교환, 그리고 라우팅 테이블의 각 항목을 누가 소유하는지.
• 가장 바쁜 시간에 견뎌야 하는 처리량과 연결 수.
• 사이트 소유자가 합의한 장애 조치 동작이며, 여러분이 만들 수 있는 것만이 아닙니다.

NAT는 건너뛰기 쉬운 항목이며 그다음 전체 설계를 결정합니다. IPsec을 설정할 수 있는 장치라도 대체하는 RRAS 배포와 다르게 주소를 변환할 수 있으며, 이는 지사가 어떤 주소를 원본으로 보는지와 로그에 무엇이 기록되는지를 바꿉니다.

목록을 네트워크 소유자에게 가져가 제품 논의 전에 확인받으세요. 모호한 요구 사항은 모든 공급업체 비교를 선호 논쟁으로 바꿉니다.

그 요구 사항에 비추어 대체안을 평가하세요

Azure의 관리형 연결 서비스와 공급업체가 지원하는 네트워크 가상 어플라이언스는 둘 다 같은 목록에 비추어 점수를 매겨야 합니다. IPsec을 종료할 수 있다는 이유만으로 둘 중 하나가 RRAS VM의 직접적인 동등물이라고 가정하지 말고, NAT 모델과 경로 소유권, 그리고 고가용성 설계가 기존 사이트의 연결 방식과 응답이 돌아가는 곳을 결정한다는 점을 보세요. 각 후보를 종이 위에서 목록에 비추어 점수 매기고 어떤 요구 사항을 충족하지 못하는지 적어 두면, 그 메모가 나중에 선택을 검토 가능하게 만듭니다.

두 어플라이언스 VM 앞의 로드 밸런서는 그 자체로 고가용성이 아닙니다. 프런트 엔드를 제공할 뿐 동기화된 터널 상태가 아니며, 모든 세션을 떨어뜨리는 장애 조치는 누군가 의도적으로 내려야 하는 설계 선택입니다. 어플라이언스 공급업체에 지원되는 HA 패턴이 무엇이며 사이트에 약속된 가용성과 일치하는지 물으세요. 그 사이트가 의존하기 전에 장애 조치를 테스트하고, 잃어버린 세션은 모두 놀라움이 아니라 발견으로 취급하세요.

요구 사항이 정말 단순할 때 — 사이트 하나, 접두사 하나, 겹침 없음 — 관리형 서비스가 보통 운영 비용에서 이깁니다. 변환과 동적 라우팅이 둘 다 관련되면 어플라이언스 경로가 유일하게 적합할 수 있으며, 그것이 지원되지 않는 VM을 유지하는 대신 더 긴 마이그레이션을 계획할 이유입니다.

RRAS VM이 이미 실행 중이라면

발견은 삭제할 이유가 아닙니다. 그 VM이 쌓아 온 의존성, 즉 다른 서브넷이 의존하는 경로, 원본 주소를 숨기는 NAT 규칙, 모니터링이 그 주소에서 기대하도록 배운 모든 것 주변으로 변경을 계획하세요. 지원되는 대상이 옆에서 설계되고 검증되는 동안 필요한 경로와 테스트된 복구 경로를 유지하세요.

지원 가능성과 기술 진단을 항상 별도의 발견으로 유지하세요. 지원되지 않는 구성에도 평범한 라우팅 오류가 있을 수 있으며, 그 오류를 고쳐도 지원 상태는 바뀌지 않습니다. 두 진술 모두 보고서에 속하며, 어느 하나가 다른 하나를 무효화하지 않습니다.

지원 인용, 요구 사항 목록, 선택한 대체안, 전환 순서를 기록하여 안내를 마무리하세요. 감사자나 새 팀원이 가장 먼저 요청할 것이 바로 이 네 가지입니다.