지점 및 사이트 간 VPN으로 프라이빗 Container Apps 앱에 연결

내부 Container Apps 환경에는 프라이빗 진입점, 일치하는 호스트 이름, VPN이 도달할 수 있는 확인자가 필요합니다. 각 단계를 실행한 다음 거부를 확인하세요.

이 런북은 워크로드 프로필이 있는 Container Apps 환경과 내부 가상 네트워크 진입점을 다루며, 승인된 지점 및 사이트 간 VPN을 통해 노트북에서 도달하고, 앱의 직접 FQDN을 사용하며 환경 수준 HTTP 경로는 사용하지 않습니다. 환경 진입점이 클라이언트에서 도달 가능함, 앱의 인그레스 범위가 호출자를 허용함, 호스트 이름이 프라이빗 진입점으로 확인됨입니다. 아래의 각 단계는 검증 가능한 결과와 변경하지 않은 것에 손대지 않는 롤백을 남깁니다. 1단계에서 잘못 내린 범위 결정은 이후 어떤 단계로도 보완할 수 없으므로 주어진 순서대로 진행하세요.

DNS를 건드리기 전에 내부라는 단어를 정리하세요. 이 제품에서는 두 가지 다른 범위에 쓰이며, 이를 뒤바꾸는 것이 작동하는 이름이 여전히 유용한 것을 반환하지 않는 가장 흔한 이유입니다.

1단계: 환경과 앱의 범위를 확정합니다

레코드를 변경하기 전에 앱의 인그레스 구성을 읽으세요:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

내부 인그레스는 환경 VNet 내부의 환경 내부 부하 분산 장치에 노출되므로, 질문은 노트북이 다른 컨테이너 앱인지가 아니라 해당 VNet에 도달할 수 있는지입니다. VNet으로의 경로가 있고 환경 기본 도메인이 프라이빗 영역을 통해 확인되는 VPN 클라이언트가 적격 호출자이며, 나머지 단계가 바로 그것을 만듭니다. 공용 진입점이 없는 내부 환경은 내부 인그레스가 있는 앱과 다른 사실이며, 앱 수준의 외부 인그레스는 환경에 공용 문을 주지 않습니다. 다음 엔지니어가 티켓을 먼저 읽으므로 범위를 포털뿐 아니라 티켓에도 적으세요.

계속하기 전에 구성 소유자와 그 범위를 확인하고 게이트를 좁게 유지하세요: 환경 VNet으로의 경로가 없거나 환경 기본 도메인이 프라이빗 영역을 통해 확인되지 않으면 멈추고 먼저 그 경로를 고치세요. VNet에 도달하지 못하거나 이름을 확인하지 못하는 호출자를 이후 어떤 단계도 대체할 수 없습니다.

2단계: 실제 호스트 이름과 진입 주소를 수집합니다

환경의 기본 도메인, 고정 프라이빗 진입 주소, 앱에 구성된 FQDN을 오래된 스크린샷이나 위키 페이지가 아니라 리소스에서 가져와 기록하세요:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Container Apps의 프라이빗 진입점 지침 은 애플리케이션 호스트 이름을 그대로 유지하면서 환경의 도메인을 내부 주소에 맞추는 방법을 설명합니다. 여기서 직접 만드는 형태가 바로 그것이므로 새로운 이름 지정 체계를 고안하는 대신 영역 내용을 그것에 맞추세요.

읽은 도메인이 앱이 보고하는 FQDN과 일치하지 않으면 멈추고 지금 서로 맞추세요. 잘못된 접미사에 영역을 만들면 완벽하게 확인되면서도 잘못된 가상 호스트에 도착하는 호스트 이름이 생깁니다.

3단계: 프라이빗 영역을 VPN 확인자 경로에 둡니다

환경의 실제 기본 도메인에 지원되는 프라이빗 DNS 영역을 만들거나 다시 사용하고, 문서화된 와일드카드 및 주소 레코드가 고정 진입점을 가리키게 하세요. 그 영역을 적절한 가상 네트워크에 연결하고, 연결만으로 충분하다고 가정하지 말고 VPN의 승인된 확인자 경로를 통해 프라이빗 권한에 도달할 수 있게 하세요.

지점 및 사이트 간 클라이언트는 보통 해당 영역에 도달하려면 프라이빗 확인자의 인바운드 엔드포인트나 지원되는 DNS 전달자가 필요합니다. 영역을 연결하면 연결된 네트워크에 대해 Azure가 확인하는 내용이 바뀔 뿐, 모든 외부 노트북의 공용 확인자를 리디렉션하지는 않습니다. 다른 Container Apps 네트워킹 모델에서 빌려온 레코드 이름과 영역 접미사가 맞지 않으므로 다른 Container Apps 네트워킹 모델에서 빌려온 프라이빗 엔드포인트 DNS 영역으로 대체하지 마세요.

이 단계의 롤백은 추가한 영역 연결이나 레코드를 제거하는 것입니다. 단일 연결을 되돌리려고 공유 영역을 삭제하는 것은 두 번째 환경을 망가뜨리는 잘 알려진 방법이므로 둘 중 무엇이었는지 기록하세요.

4단계: 이름을 테스트한 다음 거부되는 대상을 테스트합니다

주소만이 아니라 호스트 이름과 TLS 신원을 함께 테스트하세요. 통제된 이름 매핑 진단을 위해 호스트 이름을 유지하면서 주소를 고정할 수 있습니다:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

호스트 이름을 실제 앱 FQDN으로, 주소를 실제 내부 진입점으로 바꾸세요. 이는 그 한 요청에만 영향을 주며 DNS 프로비저닝이 아닙니다. 인증서 불일치는 잘못된 수신기를 치고 있다는 신호이므로 신원 실패를 겉보기 통과로 바꾸기 위해 -k를 추가하지 마세요.

숫자 주소를 직접 요청하면 TCP 443이 응답하더라도 잘못된 가상 호스트를 선택하거나 유효성 검사가 실패할 수 있으므로, 성공한 IP 테스트는 네트워크에 대한 증거로만 취급하세요. 의도한 노트북에서 정상 확인자 경로는 클라이언트의 DNS 전달자이거나 영역을 호스트하는 프라이빗 확인자의 인바운드 엔드포인트이며, 그곳의 실패는 레코드 누락이 아니라 확인자 도달성 문제입니다. 같은 요청이 그 경로에서 성공하는지 확인한 다음 거부된 대상이 여전히 거부되는지 확인하세요.

무엇을 기록하고 무엇을 롤백할지

컨테이너 대상 포트와 클라이언트 HTTPS 포트는 별개 설정입니다. 컨테이너가 그곳에서 수신한다고 해서 대상 포트를 VPN을 통해 게시하지 말고, 포트 테스트를 통과시키려고 네트워크 규칙을 넓히지 마세요. 두 변경 모두 사고 이후에도 남고 나중에 귀속시키기 어렵습니다.

의도한 노트북에서 승인된 신원과 정상 DNS를 사용해 새 애플리케이션 작업으로 마무리한 다음, 권한 없는 호출자가 여전히 실패하는지 확인하세요. 그 경로는 인그레스 범위가 설명하지 않는 두 번째 문이므로, 앱 구성에 있는 동안 환경 수준 HTTP 경로가 이 앱을 대상으로 노출하는지도 확인하세요.

다섯 값을 함께 기록하세요: 환경 범위, 앱 인그레스 범위, FQDN, 프라이빗 진입 주소, 확인자 소유자입니다. 이 다섯이 전체 액세스 계약을 설명하며, 다음에 디버그할 사람은 정확히 그것을 요청할 것입니다.

관련 글