다음을 통해 공유

Azure NAT Gateway 연결 문제 해결

  • 아티클

이 문서에서는 NAT 게이트웨이와 관련된 일반적인 아웃바운드 연결 문제를 해결하고 해결하는 방법에 대한 지침을 제공합니다. 또한 이 문서에서는 아웃바운드 연결을 효율적으로 사용하도록 애플리케이션을 디자인하는 방법에 대한 모범 사례도 제공합니다.

연결 오류가 발생한 NAT 게이트웨이의 데이터 경로 가용성 저하

시나리오

연결 실패와 일치하는 NAT 게이트웨이의 데이터 경로 가용성이 감소하는 것을 관찰합니다.

가능한 원인

  • 원본 SNAT(네트워크 주소 변환) 포트 고갈

  • 동시 SNAT 연결 제한

  • 커넥트온 시간 제한입니다.

문제 해결 단계

SNAT 포트 소모 또는 동시 연결 제한에 도달할 수 있는 솔루션

  • NAT 게이트웨이에 공용 IP 주소를 총 16개까지 추가하여 아웃바운드 연결을 확장합니다. 각 공용 IP는 64,512개의 SNAT 포트를 제공하며 NAT 게이트웨이에 대한 고유한 대상 엔드포인트당 최대 50,000개의 동시 연결을 지원합니다.

  • 애플리케이션 환경을 여러 서브넷에 분산하고, 각 서브넷에 대한 NAT 게이트웨이 리소스를 제공합니다.

  • TCP 유휴 시간 제한 타이머를 더 낮은 값으로 줄여 SNAT 포트 인벤토리를 확보합니다. TCP 유휴 시간 초과 타이머는 4분 미만으로 설정할 수 없습니다.

  • 다른 작업에 대한 연결 리소스를 확보하려면 비동기 폴링 패턴을 고려합니다.

  • Private Link를 사용하여 Azure 백본을 통해 Azure PaaS 서비스에 연결합니다. 프라이빗 링크는 인터넷에 대한 아웃바운드 연결을 위해 SNAT 포트를 해제합니다.

  • 조사가 결정적이지 않은 경우 지원 사례를 열어 추가 문제를 해결합니다.

참고 항목

SNAT 포트 고갈이 발생하는 이유를 이해하는 것이 중요합니다. 확장 가능하고 신뢰할 수 있는 시나리오에 적합한 패턴을 사용해야 합니다. 요구의 원인을 이해하지 않고 SNAT 포트를 시나리오에 추가하는 것은 최후의 수단이어야 합니다. 시나리오에서 SNAT 포트 인벤토리를 압박하는 이유를 이해할 수 없는 경우 더 많은 IP 주소를 추가하여 SNAT 포트를 추가하면 애플리케이션 크기 조정과 동일한 소진 오류가 지연될 뿐입니다. 다른 비효율성 및 안티패턴을 마스킹할 수 있습니다. 자세한 내용은 아웃바운드 연결을 효율적으로 사용하기 위한 모범 사례를 참조 하세요.

TCP 연결 시간 제한에 대한 가능한 솔루션

TCP keepalives 또는 애플리케이션 계층 keepalives를 사용하여 유휴 흐름을 새로 고치고 유휴 시간 제한 타이머를 다시 설정합니다. 예제는 .NET 예제를 참조 하세요.

TCP keepalive는 양쪽에서 연결을 유지하기 위해 연결의 한쪽에서만 사용하도록 설정하면 됩니다. 연결의 한쪽에서 TCP keepalive가 전송되면 다른 쪽은 자동으로 승인(ACK) 패킷을 보냅니다. 유휴 시간 초과 타이머는 연결 양쪽에서 다시 설정됩니다.

참고 항목

TCP 유휴 시간 제한을 늘리는 것은 최후의 수단이며 문제의 근본 원인을 해결하지 못할 수 있습니다. 시간이 오래 걸리면 시간 제한이 만료될 때 지연이 발생하고 불필요한 저금리 오류가 발생할 수 있습니다.

UDP(사용자 데이터그램 프로토콜) 연결 시간 제한에 대한 가능한 솔루션

UDP 유휴 시간 제한 타이머는 4분으로 설정되며 구성할 수 없습니다. 연결 흐름의 양방향에 UDP keepalives를 사용하도록 설정하여 긴 연결을 기본. UDP 유지를 사용하도록 설정하면 연결의 한 방향에 대해서만 활성화됩니다. 연결은 여전히 유휴 상태로 전환되고 연결의 다른 쪽에서 시간이 초과할 수 있습니다. UDP 연결이 유휴 상태로 시간이 초과되는 것을 방지하려면 연결 흐름의 양방향에 대해 UDP keepalive를 사용하도록 설정해야 합니다.

애플리케이션 계층 keepalive는 유휴 흐름을 새로 고치고 유휴 시간 제한을 다시 설정하는 데 사용할 수도 있습니다. 서버 쪽에서 사용 가능한 애플리케이션 관련 Keepalive 옵션을 확인합니다.

NAT 게이트웨이에서 데이터 경로 가용성이 떨어지지만 연결 실패는 없습니다.

시나리오

NAT 게이트웨이의 데이터 경로 가용성은 떨어지지만 실패한 연결은 관찰되지 않습니다.

가능한 원인

데이터 경로의 노이즈로 인한 데이터 경로 가용성의 일시적인 감소입니다.

문제 해결 단계

아웃바운드 연결에 영향을 주지 않고 데이터 경로 가용성이 저하되는 것을 발견하면 NAT 게이트웨이가 데이터 경로에서 일시적인 노이즈를 선택하기 때문일 수 있습니다.

데이터 경로 가용성 저하에 대한 경고를 설정하거나 Azure Resource Health를 사용하여 NAT 게이트웨이 상태 이벤트에 대해 경고합니다.

인터넷에 대한 아웃바운드 연결 없음

시나리오

NAT 게이트웨이에서 아웃바운드 연결이 관찰되지 않습니다.

가능한 원인

  • NAT 게이트웨이가 잘못 구성되었습니다.

  • 인터넷 트래픽은 NAT 게이트웨이에서 멀리 리디렉션되고 가상 어플라이언스 또는 VPN 또는 ExpressRoute가 있는 온-프레미스 대상으로 강제 터널됩니다.

  • NSG(네트워크 보안 그룹) 규칙은 인터넷 트래픽을 차단하는 구성됩니다.

  • NAT 게이트웨이 데이터 경로 가용성이 저하되었습니다.

  • 수행기본 이름 시스템(DNS) 구성이 잘못되었습니다.

문제 해결 단계

  • NAT 게이트웨이가 하나 이상의 공용 IP 주소 또는 접두사로 구성되고 서브넷에 연결되어 있는지 확인합니다. NAT 게이트웨이는 공용 IP 및 서브넷이 연결될 때까지 작동하지 않습니다. 자세한 내용은 NAT 게이트웨이 구성 기본 사항을 참조 하세요.

  • NAT 게이트웨이에 연결된 서브넷의 라우팅 테이블을 확인합니다. NVA(네트워크 가상 어플라이언스), ExpressRoute 또는 VPN Gateway로 강제 터널되는 0.0.0.0/0 트래픽은 NAT 게이트웨이보다 우선합니다. 자세한 내용은 Azure에서 경로를 선택하는 방법을 참조하세요.

  • 인터넷 액세스를 차단하는 가상 머신의 네트워크 인터페이스에 대해 구성된 NSG 규칙이 있는지 확인합니다.

  • NAT 게이트웨이의 데이터 경로 가용성이 저하된 상태인지 확인합니다. NAT 게이트웨이가 성능이 저하된 경우 연결 실패 문제 해결 지침을 참조하세요.

  • DNS가 제대로 확인되지 않는 경우 DNS 설정을 확인합니다.

아웃바운드 연결 손실에 대한 가능한 솔루션

NAT 게이트웨이 공용 IP는 아웃바운드에 연결하는 데 사용되지 않습니다.

시나리오

NAT 게이트웨이는 Azure 가상 네트워크에 배포되지만 예기치 않은 IP 주소는 아웃바운드 연결에 사용됩니다.

가능한 원인

  • NAT 게이트웨이가 잘못 구성되었습니다.

  • 가상 머신에서 Azure Load Balancer 또는 인스턴스 수준 공용 IP와 같은 다른 Azure 아웃바운드 연결 방법을 사용하여 활성 연결합니다. 활성 연결 흐름은 연결이 설정되었을 때 할당된 이전 공용 IP 주소를 계속 사용합니다. NAT 게이트웨이가 배포되면 새 연결이 NAT 게이트웨이를 즉시 사용하기 시작합니다.

  • 프라이빗 IP는 서비스 엔드포인트 또는 Private Link를 통해 Azure 서비스에 연결하는 데 사용됩니다.

  • 스토리지 계정에 대한 커넥트 연결하려는 가상 머신과 동일한 지역에서 제공됩니다.

  • 인터넷 트래픽은 NAT 게이트웨이에서 멀리 리디렉션되고 NVA 또는 방화벽으로 강제 터널됩니다.

문제 해결 방법

  • NAT 게이트웨이에 하나 이상의 공용 IP 주소 또는 접두사 및 하나 이상의 서브넷이 연결되어 있는지 확인합니다.

  • NAT 게이트웨이를 배포한 후에도 공용 부하 분산 장치와 같은 이전 아웃바운드 연결 방법이 여전히 활성 상태인지 확인합니다.

  • 다른 Azure 서비스에 대한 연결이 Azure 가상 네트워크의 개인 IP 주소에서 오는지 확인합니다.

  • 다른 Azure 서비스에 연결할 수 있도록 Private Link 또는 서비스 엔드포인트가 설정되어 있는지 확인합니다.

  • 스토리지 연결을 만들 때 가상 머신이 Azure Storage와 동일한 지역에 있는지 확인합니다.

  • 연결에 사용되는 공용 IP 주소가 NVA(네트워크 가상 어플라이언스)와 같은 Azure 가상 네트워크 내의 다른 Azure 서비스에서 시작되었는지 확인합니다.

아웃바운드 연결에 사용되지 않는 NAT 게이트웨이 공용 IP에 대한 가능한 솔루션

  • NAT 게이트웨이에 공용 IP 주소 또는 접두사를 연결합니다. NAT 게이트웨이가 동일한 가상 네트워크의 서브넷에 연결되어 있는지 확인합니다. NAT 게이트웨이가 아웃바운드에 연결할 수 있는지 확인합니다.

  • 다음을 통해 다른 아웃바운드 연결 방법에서 이전 SNAT IP 주소를 유지하는 VM과 관련된 문제를 테스트하고 해결합니다.

    • 새 연결을 설정하고 기존 연결이 OS에서 다시 사용되지 않거나 브라우저에서 연결을 캐싱하는지 확인합니다. 예를 들어 PowerShell에서 curl을 사용하는 경우 새 연결을 적용하려면 -DisableKeepalive 매개 변수를 지정해야 합니다. 브라우저를 사용하는 경우 연결을 풀로 설정할 수도 있습니다.

    • NAT 게이트웨이로 구성된 서브넷에서 가상 머신을 다시 부팅할 필요가 없습니다. 그러나 가상 머신이 다시 부팅되면 연결 상태가 플러시됩니다. 연결 상태가 플러시되면 모든 연결이 NAT 게이트웨이 리소스의 IP 주소 또는 주소를 사용하기 시작합니다. 이 동작은 가상 머신이 다시 부팅될 때의 부작용이므로, 다시 부팅이 필수라는 뜻은 아닙니다.

    • 여전히 문제가 있는 경우 추가 문제 해결을 위한 지원 사례를 엽니다.

  • 0.0.0.0/0 트래픽을 NVA로 전송하는 사용자 지정 경로는 인터넷으로 트래픽을 라우팅하기 위해 NAT 게이트웨이보다 우선합니다. NAT 게이트웨이가 NVA 대신 인터넷으로 트래픽을 라우팅하도록 하려면 가상 어플라이언스 가는 0.0.0.0/0 트래픽에 대한 사용자 지정 경로를 제거합니다. 0.0.0.0/0 트래픽은 인터넷에 대한 기본 경로를 사용하여 다시 시작되고 NAT 게이트웨이가 대신 사용됩니다.

Important

트래픽 경로 방식을 변경하기 전에 클라우드 아키텍처의 라우팅 요구 사항을 신중하게 고려합니다.

  • Azure Storage 계정과 동일한 지역에 배포된 서비스는 통신에 프라이빗 Azure IP 주소를 사용합니다. 공용 아웃바운드 IP 주소 범위에 따라 특정 Azure 서비스에 대한 액세스를 제한할 수 없습니다. 자세한 내용은 IP 네트워크 규칙에 대한 제한을 참조 하세요.
  • Private Link 및 서비스 엔드포인트는 가상 네트워크에 있는 가상 머신 인스턴스의 개인 IP 주소를 사용하여 NAT 게이트웨이의 공용 IP 대신 Azure 플랫폼 서비스에 연결합니다. Private Link를 사용하여 NAT 게이트웨이를 사용하여 인터넷을 사용하는 대신 Azure 백본을 통해 다른 Azure 서비스에 연결합니다.

참고 항목

Private Link는 Azure 호스팅 서비스에 대한 프라이빗 액세스를 위해 서비스 엔드포인트보다 권장되는 옵션입니다.

공용 인터넷 대상의 연결 오류

시나리오

인터넷 대상에 대한 NAT 게이트웨이 연결이 실패하거나 시간이 초과됩니다.

가능한 원인

  • 대상의 방화벽 또는 기타 트래픽 관리 구성 요소

  • 대상 쪽에서 적용한 API 속도 제한

  • 대규모 DDoS 완화 또는 전송 계층 트래픽 셰이핑

  • 대상 엔드포인트는 조각화된 패킷으로 응답합니다.

문제 해결 방법

  • 동일한 지역 또는 다른 지역의 엔드포인트에 대한 연결의 유효성을 검사하여 비교합니다.

  • 원본 및 대상 측에서 패킷 캡처를 수행합니다.

  • 원본 및 대상(사용 가능한 경우)에서 패킷 수를 확인 하여 연결 시도 횟수를 확인합니다.

  • 삭제된 패킷을 확인하여 NAT 게이트웨이에서 삭제한 패킷 수를 확인합니다.

  • 패킷을 분석합니다. 조각화된 IP 프로토콜 패킷이 있는 TCP 패킷은 IP 조각화를 나타냅니다. NAT 게이트웨이는 IP 조각화를 지원하지 않으므로 조각화된 패킷을 사용한 연결이 실패합니다.

  • NAT 게이트웨이 공용 IP가 방화벽 또는 기타 트래픽 관리 구성 요소를 사용하여 파트너 대상에서 허용된 대로 나열되는지 확인합니다.

인터넷 대상에서 연결 실패에 대한 가능한 솔루션

  • NAT 게이트웨이 공용 IP가 대상에서 허용된 대로 나열되는지 확인합니다.

  • 대량 또는 트랜잭션 속도 테스트를 만드는 경우 속도를 낮추면 실패 발생 빈도가 줄어드는지 살펴봅니다.

  • 연결 속도를 줄이면 실패 발생이 감소하는 경우 대상에서 API 속도 제한 또는 기타 제약 조건에 도달했는지 검사.

활성 또는 수동 모드에 대한 FTP 서버의 커넥트ion 오류

시나리오

활성 또는 수동 FTP 모드로 NAT 게이트웨이를 사용하는 경우 FTP 서버에서 연결 오류가 표시됩니다.

가능한 원인

  • 활성 FTP 모드를 사용할 수 있습니다.

  • 수동 FTP 모드가 활성화되고 NAT 게이트웨이가 둘 이상의 공용 IP 주소를 사용하고 있습니다.

활성 FTP 모드에 대한 가능한 솔루션

FTP는 클라이언트와 서버, 명령 및 데이터 채널 간에 별도의 두 채널을 사용합니다. 각 채널은 별도의 TCP 연결에서 통신하며, 하나는 명령을 전송하고 다른 하나는 데이터 전송을 위해 통신합니다.

활성 FTP 모드에서 클라이언트는 명령 채널을 설정하고 서버는 데이터 채널을 설정합니다.

NAT 게이트웨이는 활성 FTP 모드와 호환되지 않습니다. 활성 FTP는 FTP 클라이언트의 PORT 명령을 사용하여 클라이언트에 다시 연결하기 위해 데이터 채널에서 사용할 서버의 IP 주소와 포트를 FTP 서버에 알려줍니다. PORT 명령은 변경할 수 없는 클라이언트의 개인 주소를 사용합니다. 클라이언트 쪽 트래픽은 인터넷 기반 통신을 위해 NAT 게이트웨이에 의해 SNATed되므로 FTP 서버에서 PORT 명령이 유효하지 않은 것으로 표시됩니다.

활성 FTP 모드에 대한 대체 솔루션은 수동 FTP 모드를 대신 사용하는 것입니다. 그러나 수동 FTP 모드 에서 NAT 게이트웨이를 사용하려면 몇 가지 사항을 고려해야 합니다.

수동 FTP 모드에 대한 가능한 솔루션

수동 FTP 모드에서 클라이언트는 명령 및 데이터 채널 모두에서 연결을 설정합니다. 클라이언트는 클라이언트에 대한 연결을 다시 설정하는 대신 서버가 포트에 응답하도록 요청합니다.

아웃바운드 수동 FTP는 FTP 서버 구성에 따라 여러 공용 IP 주소가 있는 NAT 게이트웨이에서 작동하지 않습니다. 여러 공용 IP 주소가 있는 NAT 게이트웨이가 아웃바운드로 트래픽을 보낼 때 원본 IP 주소에 대한 공용 IP 주소 중 하나를 임의로 선택합니다. 데이터 및 제어 채널이 FTP 서버 구성에 따라 다른 원본 IP 주소를 사용하는 경우 FTP가 실패합니다.

가능한 수동 FTP 연결 오류를 방지하려면 다음 단계를 수행합니다.

  1. NAT 게이트웨이가 여러 IP 주소 또는 접두사 대신 단일 공용 IP 주소에 연결되어 있는지 확인합니다.

  2. NAT 게이트웨이의 수동 포트 범위가 대상 엔드포인트에서 방화벽을 전달할 수 있는지 확인합니다.

참고 항목

NAT 게이트웨이에서 공용 IP 주소의 양을 줄이면 아웃바운드 연결을 만드는 데 사용할 수 있는 SNAT 포트 인벤토리가 줄어들고 SNAT 포트 소모 위험이 증가할 수 있습니다. NAT 게이트웨이에서 공용 IP 주소를 제거하기 전에 SNAT 연결 요구 사항을 고려합니다. 다른 원본 IP 주소의 제어 및 데이터 평면 트래픽을 허용하도록 FTP 서버 설정을 변경하지 않는 것이 좋습니다.

포트 25의 아웃바운드 연결이 차단됨

시나리오

SMTP(Simple Mail Transfer Protocol) 트래픽에 대해 포트 25에서 NAT 게이트웨이를 사용하여 아웃바운드에 연결할 수 없습니다.

원인

Azure 플랫폼은 배포된 VM에 대한 TCP 포트 25에서 아웃바운드 SMTP 연결을 차단합니다. 이 블록은 Microsoft 파트너 및 고객의 보안을 향상시키고, Microsoft의 Azure 플랫폼을 보호하며, 업계 표준을 준수하기 위한 것입니다.

인증된 SMTP 릴레이 서비스를 사용하여 Azure VM 또는 Azure 앱 Service에서 전자 메일을 보냅니다. 자세한 내용은 아웃바운드 SMTP 연결 문제 해결을 참조 하세요.

추가 문제 해결 지침

추가 네트워크 캡처

조사가 결론에 이르지 못하면 추가 문제 해결을 위해 지원 사례를 열고 보다 신속한 해결을 위해 다음 정보를 수집합니다. NAT 게이트웨이 구성 서브넷에서 단일 가상 머신을 선택하고 다음 테스트를 수행합니다.

  • 가상 네트워크 내의 백 엔드 VM 중 하나를 사용하여 ps ping 프로브 포트 응답을 테스트하고 결과를 기록합니다(예: ps ping 10.0.0.4:3389).

  • 이러한 ping 테스트에서 응답을 받지 못하면 백 엔드 가상 머신에서 동시 netsh 추적을 실행하고 PsPing을 실행하는 동안 가상 네트워크 테스트 가상 머신을 실행한 다음 추적을 netsh 중지합니다.

아웃바운드 연결 모범 사례

Azure는 인프라를 모니터링하면서 매우 세심하게 운영합니다. 그러나 배포된 애플리케이션에서 일시적인 오류가 발생할 수 있으며 무손실 전송은 보장되지 않습니다. NAT 게이트웨이는 Azure 배포에서 매우 안정적이고 복원력 있는 아웃바운드 연결을 설정하기 위한 기본 옵션입니다. 애플리케이션 연결 효율성을 최적화하려면 문서의 뒷부분에 있는 지침을 참조하세요.

연결 풀링 사용

연결을 풀링할 때 동일한 주소 및 포트 호출에 대한 새 네트워크 연결을 열지 않습니다. 요청이 고정된 연결 집합에 내부적으로 분산되고 가능한 경우 다시 사용되는 연결 풀링 체계를 애플리케이션에 구현할 수 있습니다. 이 설정은 사용 중인 SNAT 포트의 수를 제한하고 예측 가능한 환경을 만듭니다. 연결 풀링을 사용하면 대기 시간 및 리소스 사용률을 줄이고 궁극적으로 애플리케이션의 성능을 향상시키는 데 도움이 됩니다.

HTTP 연결 풀링에 대한 자세한 내용은 HttpClientFactory를 사용한 HTTP 연결 풀링을 참조하세요.

연결 다시 사용

각 요청에 대해 개별적인 원자성 TCP 연결을 생성하는 대신 연결을 다시 사용하도록 애플리케이션을 구성합니다. 연결 다시 사용은 TCP 트랜잭션의 성능을 높이고, 연결 다시 사용이 기본값인 HTTP/1.1과 같은 프로토콜과 특히 관련이 있습니다. 이 다시 사용은 REST와 같이 HTTP를 전송으로 사용하는 다른 프로토콜에 적용됩니다.

덜 공격적인 재시도 논리 사용

SNAT 포트가 소진되거나 애플리케이션 오류가 발생하면 지연 및 백오프 논리 없는 공격적 또는 무차별 암호 대입 다시 시도로 인해 소진이 발생하거나 지속됩니다. SNAT 포트에 대한 수요는 덜 공격적인 다시 시도 논리를 사용하여 줄일 수 있습니다.

구성된 유휴 시간 제한에 따라 재시도가 너무 공격적이면 연결을 닫고 다시 사용하기 위해 SNAT 포트를 해제할 시간이 부족합니다.

추가 지침 및 예는 다시 시도 패턴을 참조하세요.

Keepalive를 사용하여 아웃바운드 유휴 시간 초과 재설정

keepalives에 대한 자세한 내용은 TCP 유휴 시간 제한을 참조하세요.

SNAT 포트에 대한 수요를 줄이려면 가능한 경우 Private Link를 사용하여 가상 네트워크에서 Azure 플랫폼 서비스로 직접 연결해야 합니다. SNAT 포트에 대한 수요를 줄이면 SNAT 포트 소진의 위험을 줄이는 데 도움이 될 수 있습니다.

Private Link를 만들려면 다음 빠른 시작 가이드를 참조하여 시작합니다.

다음 단계

항상 고객의 환경을 향상시키기 위해 노력합니다. 이 문서에서 해결되지 않은 NAT 게이트웨이 문제가 발생하는 경우 이 페이지 하단의 GitHub를 통해 피드백을 제공합니다.

NAT Gateway에 대해 자세히 알아보려면 다음을 참조하세요.