Azure 지점 및 사이트 간 연결은 되지만 프라이빗 리소스가 응답하지 않음
연결됨은 터널이 올라왔다는 뜻일 뿐입니다. 게이트웨이가 무엇을 실어 나를 수 있는지 확인하고, 주소 공간을 비교한 뒤, 이름을 확인하고 서비스 자체를 테스트하세요.
연결됨은 터널의 상태이지 도달 가능성에 대한 진술이 아닙니다. 지점 및 사이트 간 클라이언트는 IKE를 마치고 주소를 받고도 아무것에도 닿지 못할 수 있습니다. 게이트웨이는 VNet이 이미 아는 네트워크의 트래픽만 전달하기 때문입니다. 이 다섯 가지 점검을 순서대로 수행하고 첫 실패에서 멈추세요. 건너뛰는 것은 DNS 문제를 한 시간 동안 방화벽 문제로 다루는 방식입니다.
순서가 목록보다 중요합니다.
점검 1: 터널이 무엇을 실어야 하는지 정하세요
Azure VPN Gateway는 터널을 종료하고 VNet에 속한 트래픽을 전달합니다. 이것은일반적인 인터넷 출구가 아닙니다. 사용자가 자신의 브라우징이 Azure를 통해 나가기를 기대한다면, 어떤 클라이언트 설정이 등장하기 전에 이미 설계가 잘못된 것입니다. 분할 터널링을 켜서 로컬 인터넷이 로컬 경로를 계속 쓰게 하고, 고정된 송신 주소가 정말 필요할 때는 NAT 인스턴스나 사이트 간 터널을 사용하세요.
무엇이든 테스트하기 전에 클라이언트가 어디에 도달해야 하는지 적어 두세요. 그 목록이 없으면 모든 부분 결과가 진전처럼 보입니다.
점검 2: 인증서보다 먼저 주소 공간을 비교하세요
겹침은 더 넓은 범위로 판정되므로, 서브넷 수준에서 달라 보이는 두 네트워크도 상위 블록이 겹치면 충돌합니다. 게이트웨이 서브넷은 전용이어야 하고 SKU에 충분히 커야 하며, 클라이언트 주소 풀은 VNet이나 피어링을 통해 닿는 무엇과도 충돌해서는 안 됩니다. 계획을 바꾸고 다시 배포하세요. 보상하려고 경로를 추가하면 일부 목적지에서는 동작하고 다른 목적지에서는 설명 없이 동작하지 않는 터널이 만들어집니다. 여기서는 프로비저닝이 크게 실패하는데, 그것이 좋은 경우입니다.
인증이 다음 관문입니다. 인증서, RADIUS, Entra ID 프로필은 서로 바꿀 수 없고, 클라이언트 패키지도 각각 다릅니다.
점검 3: 내부에서 프라이빗 이름을 확인하세요
클라이언트는 내려받은 프로필이 VNet의 DNS 서버를 담지 않는 한 자체 확인자를 유지하며, 그 목록은 내려받는 시점에 포함됩니다. VNet 안에 포워더를 추가하고 VNet의 DNS 서버로 설정한 뒤 클라이언트 패키지를 다시 내려받아 가져오세요. 오래된 패키지를 재사용하면 오래된 확인자 목록만 테스트하게 됩니다.
먼저 주소를 테스트하세요. 그러면 라우팅과 이름 지정이 한 단계에서 분리됩니다: Test-NetConnection 10.20.1.4 -Port 3389.
주소는 응답하고 이름이 응답하지 않으면 확인자에게 직접 물으세요: Resolve-DnsName files.corp.example -Server 10.20.0.4. 둘 다 실패하면 결함은 DNS가 아니며 DNS 설정 편집을 멈춰야 합니다. 168.63.129.16의 Azure 플랫폼 DNS는 VNet 내부에서만 응답하므로, 바깥의 클라이언트는 그 주소를 확인자로 쓸 수 없습니다.
점검 4: 터널 뒤의 서비스를 테스트하세요
건강한 터널과 닫힌 포트는 클라이언트 쪽에서 똑같이 보입니다. 게스트 방화벽을 확인하고, 다음으로 서브넷이나 NIC의 네트워크 보안 그룹을, 다음으로 서비스가 루프백만이 아니라 프라이빗 주소에서 수신하는지 확인하세요. 인터넷으로 규칙을 여는 대신 클라이언트 풀을 원본으로 허용하고, Azure Files로 가는 SMB는 프라이빗 엔드포인트 경로가 터널을 지나야 한다는 점을 기억하세요. 리소스가 IP로는 응답하지만 이름으로는 응답하지 않으면, 게이트웨이를 건드리지 말고 점검 3으로 돌아가세요.
작업하는 동안 하나의 표가 계층을 분리해 줍니다:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
점검 5: 에스컬레이션 전에 프로필을 기록하세요
티켓에 게이트웨이 유형, 터널 유형, 인증 방법, 클라이언트 운영 체제를 적으세요. 인증서 IKEv2 프로필과 RADIUS 프로필은 서로 다른 이유로 실패하고, 다른 터널 유형용으로 만든 클라이언트는 게이트웨이가 호환 프로토콜을 제공할 때만 연결됩니다.
작은 팀에게 오래가는 설계는 VNet 하나, DNS 포워더 하나, 문서화된 분할 터널 클라이언트입니다. 요구 사항이 고정된 공용 송신이라면, 직접 관리하는 방화벽에서 사이트 간 터널을 종료하고 인터넷 트래픽을 그곳으로 보내세요. 지점 및 사이트 간 게이트웨이에 애초에 만들어진 적 없는 일을 요구하는 대신에.