Azure 웹앱이 VPN을 통해 온프레미스에 연결하는 방법

웹 앱의 아웃바운드 요청으로 인해 귀하가 선택하지 않은 소스로부터 전혀 볼 수 없는 작업자가 남게 되며 사무실 방화벽은 이를 수락해야 합니다. 이것이 바로 한 문장에 담긴 문제의 전부입니다. 지역 VNet 통합은 요청에 가상 네트워크에 대한 경로를 제공하고 사이트 간 VPN은 해당 요청을 거기에서 전달합니다. 나중에 문제가 되는 모든 것은 패킷이 실제로 사용된 소스 범위와 경로에 관한 것입니다.

근로자가 실제로 보내는 것

App Service는 구독의 네트워크 보기 외부에 있는 작업자에서 코드를 실행합니다.지역 통합을 사용하도록 설정하면 아웃바운드 트래픽이 동일한 지역의 VNet에 있는 위임된 서브넷으로 전달되고 패킷은 계속되기 전에 해당 서브넷에 나타납니다. 통합은 앱을 VNet으로 이동하지 않으며 인바운드 주소를 변경하지 않습니다. 아웃바운드 흐름에만 다른 첫 번째 홉을 제공합니다.

기본적으로 개인 주소 공간만 해당 경로를 사용하므로 일반 인터넷 대상은 여전히 작업자로부터 직접 떠납니다. VNet을 통해 모든 것을 라우팅하는 것은 터널을 통해 공용 종속성도 보내기 때문에 별도의 설정이자 결정입니다.

시작 시 컨테이너 이미지 가져오기와 같은 구성 트래픽은 자체 라우팅 규칙을 따르며 API 호출이 성공하더라도 실패할 수 있습니다.

통합 서브넷은 허용해야 하는 소스입니다

사무실에서는 앱의 공개 아웃바운드 주소가 아닌 통합 서브넷의 주소 범위 또는 어플라이언스가 이를 변환하는 모든 것을 확인합니다. 해당 범위를 사이트 VPN의 트래픽 선택기와 온프레미스 방화벽 규칙에 넣습니다. 터널이 정책 기반인 경우 경로가 존재하더라도이를 생략하는 선택기가 패킷을 삭제합니다.

우연히 관찰한 단일 작업자 주소를 허용하지 마세요. 인스턴스는 확장 및 플랫폼 유지 관리에 따라 변경되며, 하나의 주소에 고정된 규칙은 최악의 순간에 중단됩니다.

대상 측을 좁게 유지하세요: 하나의 서비스, 하나의 포트, 하나의 방향으로 반환 경로가 명시적으로 허용됩니다.

피어링 및 게이트웨이 전송이 명시적임

VPN 게이트웨이가 허브 VNet에 있고 통합 서브넷이 스포크에 있는 경우 경로에는 허브 피어링에서 게이트웨이 전송이 허용되고 스포크 피어링에서 원격 게이트웨이 사용이 활성화되어야 합니다. 피어링 자체는 두 VNet 간에 트래픽을 전달하며 그 이상은 아닙니다. 통합 서브넷의 유효 경로는 게이트웨이 다음 홉이 실제로 있는지 확인하는 곳입니다.

라우팅 테이블이 0.0.0.0/0을 방화벽으로 보내는 허브 앤 스포크 설계는 일반적인 변형이며, 그러면 해당 방화벽에는 온프레미스 접두사에 대한 자체 규칙이 필요합니다.

추측하는 시간을 절약할 수 있으므로 네트워크 팀과 함께 티켓을 열기 전에 종이에 경로를 그려보세요.복귀 방향을 그림에 포함하세요, 절반의 사람들이 잊어버리기 때문입니다.

인바운드 개인 끝점이 반대 방향입니다

프라이빗 엔드포인트를 사용하면 VNet 내부에서 앱에 연결할 수 있습니다. 앱의 사무실 발신 통화에는 아무 작업도 수행하지 않으며 팀에서는 정기적으로 구성을 구성하지만 실제 요구 사항은 그 반대였습니다.

이전 문서에서는 자체 요구 사항이 있는 다른 기능인 지점 및 사이트 간 VPN을 기반으로 구축된 게이트웨이 필수 통합에 대해 설명합니다. Microsoft는 해당 기능이 2027년 삼월 31일에 중단될 예정이며 대신 지역 통합을 권장합니다.

오래된 예에서 사용했다는 이유만으로 기존 지점 및 사이트 간 구성을 복사하지 마세요.

앱 자체 컨텍스트로 확인

노트북이나 동일한 VNet의 VM이 아닌 배포된 앱에서 테스트하세요. DNS 실패, TCP 시간 초과 및 세 명의 다른 소유자에 대한 인증 거부 지점이 있으므로 확인된 주소, 연결 결과 및 애플리케이션 수준 응답을 별도로 기록합니다. 이름 확인에 실패하면 터널을 터치하기 전에 VNet의 프라이빗 DNS를 수정하세요.

녹색 터널 상태는 게이트웨이가 작동 중임을 증명할 뿐입니다. 선택기, 방화벽 규칙 또는 DNS에 대해서는 아무 말도 하지 않습니다.

요청이 마침내 작동하면 원본 범위, 대상 포트 및 DNS 영역을 앱의 Runbook에 씁니다. 다음 디버깅을 수행할 사람은 게이트웨이의 상태 페이지 대신 메모에서 시작합니다.