Azure P2S VPN이 프라이빗 엔드포인트 이름을 확인하지 못함

지점 및 사이트 간 터널을 연결하고, 프라이빗 주소로 ping을 보내고, 앱을 열면 대신 403이나 인증서 오류가 납니다. 두 증상 모두 DNS를 가리키지만 서로 다른 고장입니다. 하나는 클라이언트가 공용 주소를 확인했다는 뜻이고, 다른 하나는 프라이빗 주소를 확인한 뒤 인증서가 다루지 않는 이름을 제시했다는 뜻입니다. 아래 점검을 순서대로 진행하고 첫 실패에서 멈추세요. hosts 항목이나 캐시된 응답이 있으면 이후 점검이 잘못된 이유로 통과할 수 있습니다. 저는 이 순서를 VPN 프로필 옆 텍스트 파일에 남겨 둡니다. 수정은 터널 쪽은 아무것도 바꾸지 않고 클라이언트가 아는 것은 전부 바꾸기 때문입니다.

클라이언트가 실제로 받는 주소부터 시작하세요

애플리케이션을 믿지 말고 확인자에 직접 물어보세요. Windows에서는 nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net이 클라이언트가 어느 뷰를 받았는지 보여 줍니다. 공용 응답이면 그 아래 어디도 엔드포인트에 닿지 못합니다. 엔드포인트의 프라이빗 주소라면 DNS는 끝났고 다음 점검은 연결 자체입니다.

프라이빗 엔드포인트는 서비스 이름을 바꾸지 않습니다. 계정이나 앱은 평소의 정규화된 이름을 유지하고, 엔드포인트는 가상 네트워크 안의 클라이언트에 대해 그 이름이 확인되는 주소만 바꿉니다. 그래서 같은 호스트 이름이 네트워크 안 VM에서는 프라이빗으로, 프라이빗 뷰를 받은 적 없는 노트북에서는 공용으로 확인됩니다.

터널 전에 영역과 그 링크, 레코드를 확인하세요

세 조건이 함께 성립해야 합니다. 프라이빗 영역이 있어야 하고, VPN 게이트웨이와 클라이언트가 Azure로 들어오는 가상 네트워크에 연결되어 있어야 하며, 엔드포인트에 대한 A 레코드가 프라이빗 주소를 가리켜야 합니다. 영역을 무관한 네트워크에 연결하면 게이트웨이는 계속 공용 레코드를 확인하고, 터널 쪽은 여전히 건강해 보입니다.

영역 이름은 서비스에 속하며 프라이빗 링크 일반에 속하지 않습니다. App Service는 보통 privatelink.azurewebsites.net을 쓰고, 스토리지와 SQL은 자체 네임스페이스를 가지며, 다른 서비스의 영역을 빌리면 존재하지만 유용한 응답을 하지 않는 영역이 생깁니다.

클라이언트가 실제로 도달할 수 있는 확인자를 주세요

168.63.129.16은 Azure 가상 머신에서 응답하며 지점 및 사이트 간 터널 반대편의 노트북을 위한 DNS 서버가 아닙니다. 클라이언트에는 터널을 통해 도달할 수 있는 확인자가 필요합니다. Azure DNS Private Resolver의 인바운드 엔드포인트, 가상 네트워크 내부의 전달자, 또는 VPN 클라이언트 프로필에 실어 보내는 DNS 서버 항목이 그것입니다. 그래야 클라이언트가 가상 네트워크에 직접 묻습니다.

구성되었지만 도달할 수 없는 확인자는 확인자가 없는 것과 똑같이 동작하고, 증상은 잘못된 응답이 아니라 시간 초과라서 방화벽 문제로 잘못 읽힙니다. 터널이 나르도록 되어 있는 쿼리로 시험하고, 로컬 링크로도 성공했을 공용 이름으로 시험하지 마세요.

설정을 밀어 넣는 대신 전달한다면 프라이빗 영역이 소유한 네임스페이스만 전달하세요. azurewebsites.net 전체가 아니라 privatelink.azurewebsites.net입니다. 부모 접미사 전체를 삼키는 조건부 전달자는 로컬에 남아야 할 조회까지 그 서비스의 모든 조회를 Azure로 보냅니다.

인증서가 발급된 이름을 사용하세요

주소가 맞으면 두 번째 고장이 드러납니다. 스토리지와 App Service는 privatelink 별칭을 게시하는데, 그 별칭이 반드시 인증서의 이름은 아닙니다. privatelink.blob.core.windows.net으로 보낸 AzCopy 업로드는 유효성 검사에서 실패했습니다. 같은 업로드를 <account>.blob.core.windows.net/<container>로 보내면 프라이빗 주소로 확인되어 통과했고, 우회 없이 프라이빗 경로에 머물렀습니다.

이 규칙은 브라우저와 App Service 모두에 적용됩니다. 인증서가 다루는 호스트 이름으로 연결하고 프라이빗 주소는 DNS가 공급하게 하세요. 유효성 검사를 우회하려 들지 마세요. 명명 실수가 보안 회귀로 바뀔 뿐입니다. ping 성공은 경로를 증명할 뿐 악수 안의 이름에 대해서는 아무것도 말하지 않으므로, 이것들은 별도의 점검으로 남습니다.

각 계층을 분리하는 네 단계 순서

1. VPN 클라이언트가 지점 및 사이트 간 풀에서 주소를 받았고 엔드포인트의 프라이빗 주소로 가는 경로가 있는지 확인합니다.
2. 애플리케이션이 쓰는 정확한 이름을 확인하고 그 응답을 엔드포인트 주소와 비교합니다.
3. 서비스 포트에서 엔드포인트로 TCP 연결을 열고, 그 연결에서 제시된 인증서 이름을 읽습니다.
4. 권한 부여는 이제서야 시험합니다. 경로가 동작하고 인증서가 유효해도 리소스 접근이 허용되지는 않습니다.

주소가 맞는데 연결이 거부되면 DNS가 아니라 네트워크 보안 그룹이나 프라이빗 엔드포인트 연결 상태를 가리키므로, 확인자 설정을 다시 편집하기 전에 그것들을 확인하세요. TLS 이름 불일치는 URL의 호스트 이름과 인증서 subject로 되돌아가게 합니다. 확인 출력과 인증서 이름, 정확한 URL을 함께 보관하세요. 이 세 값이 게이트웨이를 건드리지 않고 이런 사례 대부분을 설명합니다.

가상 네트워크 안의 VM을 대조군으로 쓰세요. 그곳에서는 프라이빗으로, 터널에서는 공용으로 확인된다면 영역과 레코드는 맞고 유일한 차이는 클라이언트의 확인자 경로이며, 이는 엔드포인트 구성을 다시 훑는 것보다 빨리 확인됩니다.

클라이언트도 캐시합니다. 십 분 전에 공용으로 응답한 레코드는 영역을 고친 뒤에도 계속 응답하므로 다시 시험하기 전에 캐시를 비우세요. Windows에서는 ipconfig /flushdns이 클라이언트 캐시를 지웁니다. 이름 확인 정책 규칙은 남아 어떤 접미사가 어느 서버로 가는지 정하며, 방금 교체한 확인자로 네임스페이스를 계속 보낼 수 있습니다.

hosts 항목이 있어야 할 자리

엔드포인트 주소를 hosts 파일에 추가하는 것은 좋은 진단이고 나쁜 설계입니다. 이름과 주소의 대응이 빠진 조각임을 증명하고 그 이후의 모든 것을 시험하게 해 주지만, 사용자에게는 보이지 않고, 엔드포인트 주소가 바뀌면 깨지며, 응답해야 할 영역을 가립니다.

남은 시험 항목은 오래된 캐시보다 나쁩니다. 오류의 방향에 따라 고친 경로가 깨진 것처럼, 깨진 경로가 고쳐진 것처럼 보이게 할 수 있습니다. 마지막 실행 전에 지우고 운영 확인자로만 확인하세요.

짧은 이름에는 검색 접미사가 필요하고 정규화된 이름에는 필요하지 않으므로, 먼저 정규화된 이름을 시험하고 그다음 워크플로에 클라이언트 프로필로 밀어 넣는 접미사가 필요한지 결정하세요. Microsoft는 프라이빗 엔드포인트 DNS 지침에서 서비스별 영역 이름과 레코드 형태를 문서화합니다. 다른 서비스에서 영역을 복사하지 말고 해당 서비스의 항목을 읽으세요.