프라이빗 엔드포인트가 여전히 공용 주소로 응답하는 이유

노트북이 연결되고 터널이 작동 중이라고 보고하지만 스토리지 계정은 여전히 모든 요청을 거부합니다. 프라이빗 엔드포인트는 존재하고, 해당 서브넷으로 가는 경로도 존재하며, 이름은 공용 주소로 응답하거나 아예 확인되지 않습니다. 터널에는 문제가 없는 것은, 그 이름에 어떤 서버가 응답해야 하는지 클라이언트가 한 번도 안내받지 못했기 때문입니다. 쿼리를 바깥쪽으로 따라가면 빈틈이 분명해집니다.

클라이언트의 확인자에서 시작하세요

터널이 작동하는 동안 클라이언트가 어느 서버에 쿼리하는지 물어보세요. 지점 및 사이트 프로필이 해당 주소를 제공하며, 아무것도 제공하지 않는 프로필은 운영 체제가 어댑터 기본값으로 돌아가게 합니다.

공용 확인자는 프라이빗 영역을 볼 수 없으므로 인터넷에서 응답하며, 그것이 바로 그들의 역할입니다. 따라서 첫 점검은 터널도 엔드포인트도 아니라 사용 중인 확인자 주소입니다.

응답이 실제로 무엇인지 읽으세요

서비스 이름을 확인하고 돌아오는 주소를 읽으세요. 공용 응답이라면 쿼리가 영역을 볼 수 없는 서버에 도달한 것입니다. 응답이 없다면 이름이 프라이빗으로만 존재하고 클라이언트가 닿을 수 있는 어떤 것도 그것을 보유하지 않는다는 뜻입니다.

이 두 결과는 비슷한 애플리케이션 오류를 만들지만 담당이 다릅니다. 하나는 확인자 선택 문제이고, 다른 하나는 빠진 영역 링크입니다.

hosts 항목은 경로를 증명하고 나서 거짓말을 합니다

엔드포인트 주소를 로컬 hosts 파일에 넣는 것은 터널과 서비스 방화벽이 이미 작동함을 증명하는 가장 빠른 방법입니다. 그 항목으로 요청이 성공하면 이름 확인만 깨진 것입니다. 이것은 또한 정확히 하나의 이름만 다루는 머신별 변경입니다.

두 번째 계정, 두 번째 엔드포인트, 동료에게는 도움이 되지 않으며, 엔드포인트가 새 주소로 다시 만들어지면 경고 없이 깨집니다.

더 나쁜 것은 여러분의 머신만 다르게 동작하게 만들어, 확인자 결함이 일주일간의 조사를 견디게 한다는 점입니다. 경로를 확인하는 데 쓰고, 그다음 제거하고 원인을 고치세요.

영역을 연결하고 확인자를 배포하세요

두 조건이 동시에 성립해야 합니다. 프라이빗 영역이 엔드포인트가 있는 가상 네트워크에 연결되어야 하고, 클라이언트는 그 영역을 읽을 수 있는 서버로 쿼리를 보내야 합니다. DNS Private Resolver의 인바운드 엔드포인트는 네트워크 내부에 그러한 주소를 제공하고 터널로 들어오는 쿼리에 응답합니다. 그 주소를 VPN 프로필에 넣고 클라이언트가 적용해야 하는 프라이빗 접미사를 추가하세요.

이미 있는 온프레미스 확인자도 영역을 대상으로 하는 조건부 전달자를 통해 같은 결과를 얻을 수 있습니다.

확인자의 네트워크 규칙은 라우팅만큼 중요합니다. 인바운드 규칙이 VPN 클라이언트 범위를 제외하면 쿼리는 잘못된 답을 돌려주는 대신 시간 초과됩니다. 바로 그 시간 초과 때문에 사람들이 아무 문제 없는 라우팅 테이블로 되돌아갑니다.

이름, 포트, ID를 순서대로 확인하세요

순서대로 진행하라는 말은 이름을 확인하고, 응답이 프라이빗인지 확인하고, 포트를 연 뒤 인증된 요청을 보내라는 뜻입니다. 각 단계에는 담당과 고유한 실패 징후가 있습니다.

프라이빗 응답 뒤에 시간 초과가 오면 경로나 방화벽을 가리킵니다. 공용 응답은 확인자를 가리킵니다. ID 오류를 반환하는 완료된 연결은 서비스 쪽 문제입니다.

이 목록에 속하는 실패가 하나 더 있습니다. 클라이언트 주소를 허용하는 서비스 방화벽은 재연결 후 풀이 그 주소를 다른 세션에 넘기면 더 이상 일치하지 않습니다. 클라이언트가 가지고 있다고 믿는 주소가 아니라 서비스가 기록한 호출자 주소를 읽으세요. 둘은 사람들이 생각하는 것보다 자주 어긋납니다. Azure DNS Private Resolver 지침은 영역 링크와 전달 구성을 다룹니다.