Microsoft Azure의 가상 네트워크 연결 문제 해결

  • 7분

피어 간에 트래픽이 허용되는지 여부 확인

피어링을 사용하면 Azure에서 둘 이상의 가상 네트워크를 연결할 수 있습니다. 가상 네트워크 간의 트래픽은 게이트웨이나 공용 인터넷을 통해서가 아니라 Microsoft 백본 인프라를 통해 라우팅됩니다. Azure에는 두 가지 유형의 피어링이 있습니다.

  • 가상 네트워크 피어링 - 동일한 Azure 지역 내에서 가상 네트워크를 연결합니다.

  • 글로벌 가상 네트워크 피어링 - 서로 다른 Azure 지역에 있는 가상 네트워크를 연결합니다.

글로벌 가상 네트워크 피어링에는 다음과 같은 제약 조건이 있습니다.

  • 하나의 가상 네트워크에 있는 리소스는 전역적으로 피어링된 가상 네트워크에 있는 기본 ILB(내부 Load Balancer)의 프런트 엔드 IP 주소와 통신할 수 없습니다.

  • 기본 Load Balancer를 사용하는 일부 서비스는 글로벌 가상 네트워크 피어링을 통해 작동하지 않습니다.

  • 클라우드를 통해 피어링할 수 없습니다.

  • 피어링하는 가상 네트워크에 겹치지 않는 IP 주소 공간이 있어야 합니다.

  • 두 가상 네트워크가 피어링되면 한 가상 네트워크의 주소 공간에서 주소 범위를 추가하거나 삭제할 수 없습니다. 주소 범위를 추가 또는 제거하려면 피어링을 삭제하고 주소 범위를 추가하거나 제거한 다음 피어링을 다시 만듭니다.

  • 클래식 배포 모델을 통해 만들어진 두 개의 가상 네트워크는 피어링할 수 없습니다.

  • Azure 기본 제공 이름 확인은 피어링된 가상 네트워크의 이름을 확인하지 않습니다. 다른 가상 네트워크의 이름을 확인하려면 Azure 프라이빗 영역 또는 사용자 지정 DNS 서버를 사용해야 합니다.

  • 가상 네트워크를 다른 가상 네트워크에 피어링할 수 있으며, Azure 가상 네트워크 게이트웨이를 통해 다른 가상 네트워크에 연결할 수도 있습니다. 가상 네트워크가 피어링 및 게이트웨이를 통해 연결된 경우 가상 네트워크 간 트래픽은 게이트웨이가 아니라 피어링 구성을 통해 흐릅니다.

  • 가상 네트워크 피어링이 성공적으로 구성된 후 지점 및 사이트 간 VPN 클라이언트를 다시 다운로드하여 새 경로가 클라이언트에 다운로드되는지 확인해야 합니다.

피어 간의 연결 문제를 해결하려면 다음을 수행합니다.

  1. 피어링 연결의 상태를 확인합니다.

    • 시작됨은 양방향 링크가 없음을 나타냅니다. 예를 들어 VNetA를 VNetB로 피어링하려면 VNetA에서 VNetB로의 링크와 VNetB에서 VNetA로의 링크를 하나씩 만들어야 합니다. 두 연결을 만들면 상태가 연결됨으로 바뀝니다.

    • 연결 끊김은 링크 중 하나가 삭제되었음을 나타냅니다. 피어링 연결을 다시 설정하려면 두 링크를 모두 삭제하고 다시 만들어야 합니다.

  2. 두 VNet에서 주소 범위가 일치하거나 겹치지 않는지 확인합니다.

VPN 게이트웨이 전송 문제 해결

게이트웨이 전송은 VNet 간 연결을 위해 피어링된 가상 네트워크에서 VPN 게이트웨이를 사용하도록 하나의 가상 네트워크를 사용하도록 하는 피어링 속성입니다. 다음 다이어그램에서는 가상 네트워크 피어링에서 게이트웨이 전송이 작동하는 방식을 확인할 수 있습니다.

Diagram of gateway transit with virtual network peering.

가상 네트워크가 전역적으로 피어링될 때 다음 제약 조건이 적용됩니다.

  • 한 가상 네트워크의 리소스는 글로벌 피어링된 가상 네트워크에 있는 기본 ILB의 프런트 엔드 IP 주소와 통신할 수 없습니다.

  • 기본 Load Balancer를 사용하는 일부 서비스는 글로벌 가상 네트워크 피어링을 통해 작동하지 않습니다. 자세한 내용은 글로벌 VNet 피어링 및 부하 분산 장치와 관련된 제약 조건을 참조하세요.

VPN 게이트웨이 전송 문제를 해결하려면 다음을 시도해 보세요.

  • 스포크 가상 네트워크에 이미 VPN 게이트웨이가 있는 경우 원격 게이트웨이 사용 옵션은 피어링 제한 사항 때문에 스포크 가상 네트워크에서 지원되지 않습니다.

  • 동일한 지역에 있는 스포크 가상 네트워크 간의 허브 스포크 네트워크 연결 문제의 경우 허브 네트워크에 NVA가 포함되어야 합니다. 스포크에서 다음 홉으로 NVA가 있는 UDR을 구성하고, 허브 가상 네트워크에서 전달된 트래픽 허용을 사용하도록 설정합니다.

피어 간 전이성 문제 해결

전이적 피어링은 다음과 같은 경우입니다.

  • VNetA를 VNetB로 피어링합니다.

  • VNetB를 VNetC로 피어링합니다.

  • 기본적으로 VNetA는 VNetC와 피어링되지 않습니다.

VNetA와 VNetC 간 피어링을 구현하려면 둘을 함께 피어링해야 합니다. 또는 허브 스포크 구성을 사용하고 허브에서 NVA를 통과합니다.

Screenshot showing all v nets peered to each other.

허브 스포크 VNet 구성 문제 해결

허브 스포크 구성에서 허브 가상 네트워크는 많은 스포크 가상 네트워크에 대한 연결의 중심점 역할을 합니다. 허브는 온-프레미스 데이터 센터에 대한 연결 지점으로 사용될 수도 있습니다. 스포크 가상 네트워크는 허브와 피어링하며 워크로드를 격리하는 데 사용할 수 있습니다.

Screenshot showing Hub-and-spoke configuration.

허브 스포크 가상 네트워크와 온-프레미스 리소스 간의 연결 문제를 해결하는 방법은 다음과 같습니다.

네트워크에서 타사 NVA를 사용하는 경우 다음을 확인합니다.

  • 소프트웨어 업데이트.

  • 서비스 계정 설정 및 기능.

  • 트래픽을 NVA로 보내는 가상 네트워크 서브넷의 UDR(사용자 정의 경로).

  • NVA의 트래픽을 보내는 가상 네트워크 서브넷의 UDR.

  • NVA 내의 라우팅 테이블 및 NVA(예를 들어 NIC1에서 NIC2로).

  • NVA NIC를 추적하여 네트워크 트래픽 수신 및 전송 확인.

  • 표준 SKU 및 공용 IP를 사용하는 경우 NSG가 생성되어야 하고 트래픽이 NVA로 라우팅되도록 허용하는 명시적 규칙이 있어야 합니다.

  • Azure에서 NVA의 최소 구성.

네트워크에서 VPN 게이트웨이를 사용하는 경우 다음을 확인합니다.

  • 게이트웨이는 Resource Manager 모델의 가상 네트워크에 있어야 합니다.

네트워크에서 타사 NVA 또는 VPN 게이트웨이를 사용하지 않는 경우 허브 가상 네트워크와 스포크 가상 네트워크에 VPN 게이트웨이가 있나요? 스포크 가상 네트워크에 이미 VPN 게이트웨이가 있는 경우 원격 게이트웨이 사용 옵션은 스포크 가상 네트워크에서 지원되지 않습니다. 이는 가상 네트워크 피어링 제한 때문입니다.

사이트 간 또는 Azure ExpressRoute 연결의 경우 온-프레미스에서 원격 가상 네트워크로 연결할 때 발생하는 연결 문제의 다음과 같은 원인을 확인합니다.

  • 가상 네트워크에 게이트웨이가 있는 경우 전달된 트래픽 허용 확인란을 선택했는지 확인합니다.

  • 가상 네트워크에 게이트웨이가 없는 경우 원격 게이트웨이 사용 확인란을 선택했는지 확인합니다.

  • 네트워크 관리자에게 온-프레미스 디바이스를 검사하여 모든 디바이스에 원격 가상 네트워크 주소 공간이 추가되었는지 확인하라고 요청합니다.

지점 및 사이트 간 연결:

  • 게이트웨이가 있는 가상 네트워크에서 전달된 트래픽 허용 확인란을 선택했는지 확인합니다.

  • 게이트웨이가 없는 가상 네트워크에서 전달된 트래픽 허용 확인란을 선택했는지 확인합니다.

  • 지점 및 사이트 간 클라이언트 패키지를 다운로드하여 다시 설치합니다. 새로 피어링된 가상 네트워크 경로는 자동으로 지점 및 사이트 간 클라이언트에 경로를 추가하지 않습니다.

글로벌 피어링 연결 문제 해결

피어링된 가상 네트워크 간의 연결 문제를 해결하려면 다음을 수행합니다.

  1. 필요한 역할 및 권한이 있는 계정으로 Azure Portal에 로그인합니다.

  2. 가상 네트워크를 선택하고 피어링을 선택한 다음, 상태 필드를 확인합니다.

  3. 상태가 연결 끊김인 경우 두 가상 네트워크에서 피어링을 삭제하고 다시 만듭니다.

  4. 상태가 연결됨인 경우 네트워크 트래픽 흐름을 확인합니다.

연결 문제 해결 및 원본 VM에서 대상 VM으로의 IP 흐름 확인를 사용하여 트래픽 흐름에 간섭을 일으키는 NSG 또는 UDR이 있는지 확인합니다.

방화벽 또는 NVA를 사용하는 경우:

  1. 이 단계가 완료된 후 복원할 수 있도록 UDR 매개 변수를 문서화합니다.

  2. 다음 홉으로 NVA를 가리키는 원본 VM 서브넷 또는 NIC에서 UDR을 제거합니다. NVA를 우회하는 원본 VM에서 대상으로의 직접 연결을 확인합니다.

  3. 네트워크 추적:

  • 대상 VM에서 네트워크 추적을 시작합니다. Windows는 Netsh를 사용합니다. Linux는 TCPDump를 사용합니다. - 원본에서 대상 IP로 TcpPing 또는 PsPing을 실행합니다. TcpPing 명령의 예:
tcping64.exe -t <destination VM address> 3389

TcpPing이 완료되면 대상에서 네트워크 추적을 중지합니다. 원본의 패킷이 도착하면 네트워킹 문제가 없는 것입니다. VM 방화벽과 해당 포트에서 수신 대기하는 애플리케이션을 모두 검사하여 구성 문제를 찾습니다.

참고

다음 종류의 리소스는 글로벌 가상 네트워크 피어링(서로 다른 지역의 가상 네트워크)을 통해 연결할 수 없습니다.

  • 기본 ILB SKU 뒤의 VM

  • Redis Cache(기본 ILB SKU 사용)

  • 애플리케이션 게이트웨이(기본 ILB SKU 사용)

  • 확장 집합(기본 ILB SKU 사용)

  • Service Fabric 클러스터(기본 ILB SKU 사용)

  • SQL Server Always On(기본 ILB SKU 사용)

  • App Service Environment(기본 ILB SKU 사용)

  • API Management(기본 ILB SKU 사용)

  • Microsoft Entra Domain Services(기본 ILB SKU 사용)

자세한 내용은 글로벌 피어링의 요구 사항 및 제약 조건을 참조하세요.

VNet 간 연결 문제 해결

다음을 수행합니다.

  • 게이트웨이가 정적 라우팅이 아닌 동적 라우팅을 사용하여 구성되었는지 확인합니다. 정적 라우팅은 지원되지 않습니다.

  • VPN 연결 수를 확인합니다. 기본 및 표준 동적 라우팅 게이트웨이의 경우 특정 VNet이 연결할 수 있는 최대 VPN 연결 및 VNet 수는 현재 10개입니다. 고성능 게이트웨이의 경우에는 30입니다.

  • 두 VNet의 주소 접두사에서 두 VNet 간에 주소 공간이 겹치지 않는지 확인합니다.

서비스 체이닝 문제 해결

서비스 체이닝은 사용자 정의 경로를 통해 피어링된 네트워크의 한 가상 네트워크에서 NVA로 트래픽을 전송하는 기능입니다. 피어링된 가상 네트워크에서 가상 머신을 다음 홉 IP 주소로 가리키는 사용자 정의 경로를 구성합니다. 경로 테이블을 설정하고 서브넷과 연결해야 합니다. 네트워크 트래픽 라우팅에 대한 단계별 지침은 자습서: Azure Portal을 사용하여 경로 테이블로 네트워크 트래픽 라우팅을 참조하세요.

PowerShell을 사용하면 tracert를 사용하여 네트워크 트래픽 라우팅을 테스트할 수 있습니다.

tracert myvmprivate

그러면 추적 경로가 표시되어 트래픽이 예상 경로를 사용하고 있는지 확인할 수 있습니다. Tracert의 응답은 다음과 비슷합니다.

Tracing route to myvmprivate.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net [10.0.1.4] over a maximum of 30 hops:

1     1 ms     *        2 ms  myvmnva.internal.cloudapp.net [10.0.2.4]

2     2 ms     1 ms     1 ms  myvmprivate.internal.cloudapp.net [10.0.1.4]

Trace complete.