Azure에서 아웃바운드 연결Outbound connections in Azure

Azure는 여러 메커니즘을 통해 고객 배포에 대한 아웃바운드 연결을 제공합니다.Azure provides outbound connectivity for customer deployments through several different mechanisms. 이 문서에서는 시나리오, 적용 시기, 작동 방식 및 관리 방법을 설명합니다.This article describes what the scenarios are, when they apply, how they work, and how to manage them.

참고

이 문서에서는 리소스 관리자 배포에 대해서만 설명합니다.This article covers Resource Manager deployments only. Azure의 모든 클래식 배포 시나리오는 아웃 바운드 연결(클래식)을 참조하세요.Review Outbound connections (Classic) for all Classic deployment scenarios in Azure.

Azure에 배포되는 솔루션은 공용 IP 주소 공간에 있는 Azure 외부의 엔드포인트와 통신할 수 있습니다.A deployment in Azure can communicate with endpoints outside Azure in the public IP address space. 인스턴스가 공용 IP 주소 공간에서 대상에 대한 아웃바운드 흐름을 시작하면 Azure는 개인 IP 주소를 공용 IP 주소에 동적으로 매핑합니다.When an instance initiates an outbound flow to a destination in the public IP address space, Azure dynamically maps the private IP address to a public IP address. 이 매핑이 생성되면 이 아웃바운드에서 시작된 흐름에 대한 반환 트래픽도 흐름이 시작된 개인 IP 주소에 연결할 수 있습니다.After this mapping is created, return traffic for this outbound originated flow can also reach the private IP address where the flow originated.

Azure에서는 SNAT(원본 네트워크 주소 변환)를 사용하여 이 기능을 수행합니다.Azure uses source network address translation (SNAT) to perform this function. 단일 공용 IP 주소 뒤에서 여러 개인 IP 주소가 가장하는 경우 Azure는 PAT(포트 주소 변환)를 사용하여 개인 IP 주소를 가장합니다.When multiple private IP addresses are masquerading behind a single public IP address, Azure uses port address translation (PAT) to masquerade private IP addresses. 삭제 포트는 PAT에 사용되고 풀 크기에 따라 미리 할당됩니다.Ephemeral ports are used for PAT and are preallocated based on pool size.

여러 개의 아웃바운드 시나리오가 있습니다.There are multiple outbound scenarios. 필요에 따라 이러한 시나리오를 결합할 수 있습니다.You can combine these scenarios as needed. 주의 깊게 살펴보고 배포 모델 및 애플리케이션 시나리오에 적용되는 기능, 제약 조건 및 패턴을 이해합니다.Review them carefully to understand the capabilities, constraints, and patterns as they apply to your deployment model and application scenario. 시나리오 관리 지침을 검토합니다.Review guidance for managing these scenarios.

중요

표준 Load Balancer 및 표준 공용 IP는 아웃바웃드 연결에 새로운 기능 및 서로 다른 동작을 도입합니다.Standard Load Balancer and Standard Public IP introduce new abilities and different behaviors to outbound connectivity. 이는 기본 SKU와 동일하지 않습니다.They are not the same as Basic SKUs. 표준 SKU로 작업하는 경우 아웃바운드 연결을 하려는 경우 표준 공용 IP 주소 또는 표준 공용 Load Balancer를 사용하여 명시적으로 정의해야 합니다.If you want outbound connectivity when working with Standard SKUs, you must explicitly define it either with Standard Public IP addresses or Standard public Load Balancer. 여기에는 내부 표준 Load Balancer를 사용 하는 경우 아웃 바운드 연결을 만드는 작업이 포함 됩니다.This includes creating outbound connectivity when using an internal Standard Load Balancer. 표준 공용 Load Balancer에서 항상 아웃바운드 규칙을 사용하는 것이 좋습니다.We recommend you always use outbound rules on a Standard public Load Balancer. 시나리오 3은 표준 SKU에서 사용할 수 없습니다.Scenario 3 is not available with Standard SKU. 즉, 내부 표준 Load Balancer를 사용하는 경우 아웃바운드 연결을 원하면 백 엔드 풀의 VM에 대한 아웃바운드 연결을 만드는 단계를 수행해야 합니다.That means when an internal Standard Load Balancer is used, you need to take steps to create outbound connectivity for the VMs in the backend pool if outbound connectivity is desired. 아웃바운드 연결, 단일 독립 실행형 VM, 가용성 세트의 모든 VM의 컨텍스트에서 VMSS의 모든 인스턴스는 그룹으로 작동합니다.In the context of outbound connectivity, a single standalone VM, all the VM's in an Availability Set, all the instances in a VMSS behave as a group. 즉, 가용성 세트의 단일 VM을 표준 SKU와 연결하면 개별 인스턴스가 직접 표준 SKU와 연결되지 않더라도 해당 가용성 세트 내의 모든 VM 인스턴스는 이제 표준 SKU에 연결된 것처럼 동일한 규칙에 따라 작동합니다.This means, if a single VM in an Availability Set is associated with a Standard SKU, all VM instances within this Availability Set now behave by the same rules as if they are associated with Standard SKU, even if an individual instance is not directly associated with it. 부하 분산 장치에 여러 네트워크 인터페이스 카드가 연결 된 독립 실행형 VM의 경우에도이 동작이 관찰 됩니다.This behavior is also observed in the case of a standalone VM with multiple network interface cards attached to a load balancer. 하나의 NIC를 독립 실행형으로 추가 하는 경우 동일한 동작이 발생 합니다.If one NIC is added as a standalone, it will have the same behavior. 전반적인 개념을 이해하고 SKU 간 차이점에 대해 표준 Load Balancer를 검토하고 아웃바운드 규칙을 검토하려면 이 전체 문서를 검토합니다.Carefully review this entire document to understand the overall concepts, review Standard Load Balancer for differences between SKUs, and review outbound rules. 아웃바운드 규칙을 사용하면 아웃바운드 연결의 모든 측면에 대해 정밀하게 제어할 수 있습니다.Using outbound rules allows you fine grained control over all aspects of outbound connectivity.

시나리오 개요Scenario overview

Azure Resource Manager를 사용하는 경우 Azure Load Balancer 및 관련 리소스가 명시적으로 정의됩니다.Azure Load Balancer and related resources are explicitly defined when you're using Azure Resource Manager. 현재 Azure는 Azure Resource Manager 리소스에 대한 아웃바운드 연결을 달성할 수 있는 세 가지 방법을 제공합니다.Azure currently provides three different methods to achieve outbound connectivity for Azure Resource Manager resources.

SKUSKUs 시나리오Scenario 메서드Method IP 프로토콜IP protocols DescriptionDescription
표준, 기본Standard, Basic 1. 인스턴스 수준 공용 IP 주소를 사용 하는 VM (Load Balancer 포함 또는 포함 안 함)1. VM with an Instance Level Public IP address (with or without Load Balancer) SNAT, 포트 가장 사용 안 함SNAT, port masquerading not used TCP, UDP, ICMP, ESPTCP, UDP, ICMP, ESP Azure는 인스턴스 NIC의 IP 구성에 할당된 공용 IP를 사용합니다.Azure uses the public IP assigned to the IP configuration of the instance's NIC. 인스턴스에 있는 모든 삭제 포트를 사용할 수 있습니다.The instance has all ephemeral ports available. 표준 Load Balancer 사용 하는 경우 공용 IP가 가상 컴퓨터에 할당 되 면 아웃 바운드 규칙이 지원 되지 않습니다.When using Standard Load Balancer, outbound rules are not supported if a public IP is assigned to the Virtual Machine.
표준, 기본Standard, Basic 2. VM과 연결 된 공용 Load Balancer (인스턴스에 공용 IP 주소 없음)2. Public Load Balancer associated with a VM (no Public IP address on the instance) Load Balancer 프런트 엔드를 사용하여 포트를 가장하는(PAT) SNATSNAT with port masquerading (PAT) using the Load Balancer frontends TCP, UDPTCP, UDP Azure는 공용 Load Balancer 프런트 엔드의 공용 IP 주소를 여러 개인 IP 주소와 공유합니다.Azure shares the public IP address of the public Load Balancer frontends with multiple private IP addresses. Azure는 프런트 엔드의 삭제 포트를 PAT에 사용합니다.Azure uses ephemeral ports of the frontends to PAT. 아웃 바운드 연결을 명시적으로 정의 하려면 아웃 바운드 규칙 을 사용 해야 합니다.You should use outbound rules to explicitly define outbound connectivity.
없음 또는 기본none or Basic 3. 독립 실행형 VM (Load Balancer 안 함, 공용 IP 주소 없음)3. Standalone VM (no Load Balancer, no Public IP address) 포트를 가장하는(PAT) SNATSNAT with port masquerading (PAT) TCP, UDPTCP, UDP Azure는 자동으로 SNAT에 대한 공용 IP 주소를 지정하고, 이 공용 IP 주소를 가용성 집합의 여러 개인 IP 주소와 공유하고, 이 공용 IP 주소의 삭제 포트를 사용합니다.Azure automatically designates a public IP address for SNAT, shares this public IP address with multiple private IP addresses of the availability set, and uses ephemeral ports of this public IP address. 이 시나리오는 이전 시나리오의 대체 시나리오입니다.This scenario is a fallback for the preceding scenarios. 가시성 및 제어 기능이 필요한 경우에는 권장되지 않습니다.We don't recommend it if you need visibility and control.

VM이 공용 IP 주소 공간에 있는 Azure 외부에서 엔드포인트와 통신하지 않게 하려면 NSG(네트워크 보안 그룹)를 사용하여 필요에 따라 액세스를 차단할 수 있습니다.If you don't want a VM to communicate with endpoints outside Azure in public IP address space, you can use network security groups (NSGs) to block access as needed. NSG 사용에 대한 자세한 내용은 아웃바운드 연결 방지에서 다룹니다.The section Preventing outbound connectivity discusses NSGs in more detail. 아웃바운드 액세스 없이 가상 네트워크를 설계, 구현 및 관리하는 방법은 이 문서의 범위를 벗어납니다.Guidance on designing, implementing, and managing a virtual network without any outbound access is outside the scope of this article.

시나리오 1: 공용 IP 주소가 있는 VMScenario 1: VM with Public IP address

이 시나리오에서 VM에는 할당 된 공용 IP가 있습니다.In this scenario, the VM has a Public IP assigned to it. 아웃바운드 연결에 있어서는 VM이 부하 분산되었는지 여부는 중요하지 않습니다.As far as outbound connections are concerned, it doesn't matter whether the VM is load balanced or not. 이 시나리오는 다른 시나리오에 우선합니다.This scenario takes precedence over the others. 공용 IP 주소를 사용 하는 경우 VM은 모든 아웃 바운드 흐름에 대해 공용 IP 주소를 사용 합니다.When a Public IP address is used, the VM uses the Public IP address for all outbound flows.

VM에 할당된 공용 IP는 1:다가 아닌 1:1 관계이며 상태 비저장 1:1 NAT로 구현됩니다.A public IP assigned to a VM is a 1:1 relationship (rather than 1: many) and implemented as a stateless 1:1 NAT. 포트 가장(PAT)은 사용되지 않으며 VM에는 사용 가능한 모든 삭제 포트가 있습니다.Port masquerading (PAT) is not used, and the VM has all ephemeral ports available for use.

응용 프로그램에서 많은 아웃 바운드 흐름을 시작 하 고 SNAT 포트 소모가 발생 하는 경우 snat 제약 조건을 완화 하기 위해 공용 IP 주소를 할당 하는 것이 좋습니다.If your application initiates many outbound flows and you experience SNAT port exhaustion, consider assigning a Public IP address to mitigate SNAT constraints. SNAT 고갈 관리를 전체적으로 검토합니다.Review Managing SNAT exhaustion in its entirety.

시나리오 2: 공용 IP 주소가 없는 부하 분산 VMScenario 2: Load-balanced VM without a Public IP address

이 시나리오에서 VM은 공용 Load Balancer 백 엔드 풀의 일부입니다.In this scenario, the VM is part of a public Load Balancer backend pool. VM에는 할당된 공용 IP 주소가 없습니다.The VM does not have a public IP address assigned to it. 부하 분산 장치 리소스는 공용 IP 프런트 엔드와 백 엔드 풀 간의 연결을 만드는 부하 분산 장치 규칙으로 구성해야 합니다.The Load Balancer resource must be configured with a load balancer rule to create a link between the public IP frontend with the backend pool.

이 규칙 구성을 완료 하지 않으면 동작은 공용 IP가 없는 독립 실행형 VM에 대 한 시나리오에 설명 된 것과 같습니다.If you do not complete this rule configuration, the behavior is as described in the scenario for Standalone VM with no Public IP. 백 엔드 풀 또는 상태 프로브에 작업 수신기가 있어야만 규칙이 성공하는 것은 아닙니다.It is not necessary for the rule to have a working listener in the backend pool for the health probe to succeed.

부하 분산 VM이 아웃바운드 흐름을 만든 경우 Azure에서는 아웃바운드 흐름의 프라이빗 원본 IP 주소를 공용 부하 분산 장치 프론트 엔드의 공용 IP 주소로 변환합니다.When the load-balanced VM creates an outbound flow, Azure translates the private source IP address of the outbound flow to the public IP address of the public Load Balancer frontend. Azure는 SNAT을 사용하여 이 기능을 수행합니다.Azure uses SNAT to perform this function. 또한 Azure는 PAT를 사용하여 공용 IP 주소 뒤에서 여러 개인 IP 주소를 가장합니다.Azure also uses PAT to masquerade multiple private IP addresses behind a public IP address.

Load Balancer의 공용 IP 주소 프런트 엔드에 있는 삭제 포트는 VM에서 발생하는 개별 흐름을 구별하는 데 사용됩니다.Ephemeral ports of the load balancer's public IP address frontend are used to distinguish individual flows originated by the VM. SNAT은 아웃바운드 흐름이 생성될 때 동적으로 삭제 포트를 미리 할당합니다.SNAT dynamically uses preallocated ephemeral ports when outbound flows are created. 이 컨텍스트에서 SNAT에 사용되는 임시 포트를 SNAT 포트라고 부릅니다.In this context, the ephemeral ports used for SNAT are called SNAT ports.

Snat 포트는 snat 및 PAT 이해 섹션에 설명 된 대로 미리 할당 됩니다.SNAT ports are pre-allocated as described in the Understanding SNAT and PAT section. 고갈될 수 있는 한정된 리소스입니다.They're a finite resource that can be exhausted. 어떻게 소비되는지 이해하는 것이 중요합니다.It's important to understand how they are consumed. 이 소비를 설계하고 필요에 따라 완화하는 방법을 알아보려면 SNAT 고갈 관리를 검토하세요.To understand how to design for this consumption and mitigate as necessary, review Managing SNAT exhaustion.

여러 공용 ip 주소가 Load Balancer 기본에 연결된 경우 이러한 공용 ip 주소는 아웃 바운드 흐름의 후보가 되며 하나는 임의로 선택 됩니다.When multiple public IP addresses are associated with Load Balancer Basic, any of these public IP addresses are a candidate for outbound flows, and one is selected at random.

Load Balancer Basic을 사용 하 여 아웃 바운드 연결의 상태를 모니터링 하려면 Load Balancer에 대해 Azure Monitor 로그 를 사용 하 고 SNAT 포트 소모 메시지를 모니터링 하는 경고 이벤트 로그 를 사용할 수 있습니다.To monitor the health of outbound connections with Load Balancer Basic, you can use Azure Monitor logs for Load Balancer and alert event logs to monitor for SNAT port exhaustion messages.

시나리오 3: 공용 IP 주소가 없는 독립 실행형 VMScenario 3: Standalone VM without a Public IP address

이 시나리오에서 VM은 내부 표준 Load Balancer 풀의 일부가 아닌 공용 Load Balancer 풀에 속하지 않으며, 할당 된 공용 IP 주소가 없습니다.In this scenario, the VM is not part of a public Load Balancer pool (and not part of an internal Standard Load Balancer pool) and does not have a Public IP address assigned to it. VM이 아웃바운드 흐름을 만든 경우 Azure에서는 아웃바운드 흐름의 프라이빗 원본 IP 주소를 공용 원본 IP 주소로 변환합니다.When the VM creates an outbound flow, Azure translates the private source IP address of the outbound flow to a public source IP address. 이 아웃바운드 흐름에 사용된 공용 IP 주소는 구성할 수 없으며 구독의 공용 IP 리소스 제한에 불리하게 작용하지 않습니다.The public IP address used for this outbound flow is not configurable and does not count against the subscription's public IP resource limit. 이 공용 IP 주소는 사용자의 소유가 아니며 예약할 수 없습니다.This public IP address does not belong to you and cannot be reserved. VM 또는 가용성 집합이나 가상 머신 확장 집합을 재배포하는 경우에는 이 공용 IP 주소가 해제되고 새 공용 IP 주소가 요청됩니다.If you redeploy the VM or Availability Set or virtual machine scale set, this public IP address will be released and a new public IP address requested. IP 주소를 허용 목록에 추가할 때는 이 시나리오를 사용하지 말고,Do not use this scenario for whitelisting IP addresses. 아웃바운드 시나리오와 아웃바운드 연결에 사용할 공용 IP 주소를 명시적으로 선언하는 두 시나리오 중 하나를 사용하세요.Instead, use one of the other two scenarios where you explicitly declare the outbound scenario and the public IP address to be used for outbound connectivity.

중요

또한 이 시나리오는 내부 기본 Load Balancer가 연결된 경우에__만__ 적용됩니다.This scenario also applies when only an internal Basic Load Balancer is attached. 시나리오 3은 내부 표준 Load Balancer가 VM에 연결된 경우에는 사용할 수 없습니다.Scenario 3 is not available when an internal Standard Load Balancer is attached to a VM. 내부 표준 Load Balancer를 사용하는 것 외에도 명시적으로 시나리오 1 또는 시나리오 2를 만들어야 합니다.You must explicitly create scenario 1 or scenario 2 in addition to using an internal Standard Load Balancer.

Azure는 포트 가장(PAT)과 함께 SNAT을 사용하여 이 기능을 수행합니다.Azure uses SNAT with port masquerading (PAT) to perform this function. 이 시나리오는 사용 되는 IP 주소에 대 한 제어가 없다는 점을 제외 하 고 시나리오 2와 유사 합니다.This scenario is similar to scenario 2, except there is no control over the IP address used. 시나리오 1 및 2가 없을 때를 대비한 시나리오입니다.This is a fallback scenario for when scenarios 1 and 2 do not exist. 아웃바운드 주소를 제어해야 하는 경우에는 이 시나리오를 사용하지 않는 것이 좋습니다.We don't recommend this scenario if you want control over the outbound address. 아웃바운드 연결이 애플리케이션의 중요한 부분인 경우 다른 시나리오를 선택해야 합니다.If outbound connections are a critical part of your application, you should choose another scenario.

SNAT 포트는 SNAT 및 PAT 이해 섹션에 설명된 대로 미리 할당되며SNAT ports are preallocated as described in the Understanding SNAT and PAT section. 가용성 집합을 공유하는 VM의 수는 미리 할당 계층이 적용되는 것을 결정합니다.The number of VMs sharing an Availability Set determines which preallocation tier applies. 가용성 집합이 없는 독립 실행형 VM은 사전 할당의 결정을 위한 1의 효과적인 풀입니다(1024 SNAT 포트).A standalone VM without an Availability Set is effectively a pool of 1 for the purposes of determining preallocation (1024 SNAT ports). SNAT 포트는 소진될 수 있는 한정된 리소스입니다.SNAT ports are a finite resource that can be exhausted. 어떻게 소비되는지 이해하는 것이 중요합니다.It's important to understand how they are consumed. 이 소비를 설계하고 필요에 따라 완화하는 방법을 알아보려면 SNAT 고갈 관리를 검토하세요.To understand how to design for this consumption and mitigate as necessary, review Managing SNAT exhaustion.

여러 결합 시나리오Multiple, combined scenarios

이전 섹션에서 설명한 시나리오를 결합하여 특정 결과를 달성할 수 있습니다.You can combine the scenarios described in the preceding sections to achieve a particular outcome. 여러 시나리오가 있는 경우 우선 순위가 적용됩니다. 시나리오 1시나리오 23보다 우선합니다.When multiple scenarios are present, an order of precedence applies: scenario 1 takes precedence over scenario 2 and 3. 시나리오 2시나리오 3을 재정의합니다.Scenario 2 overrides scenario 3.

애플리케이션이 제한된 수의 대상에 대한 아웃바운드 연결에 크게 의존하지만 Load Balancer 프런트 엔드를 통해 인바운드 흐름을 수신하는 Azure Resource Manager 배포를 예로 들 수 있습니다.An example is an Azure Resource Manager deployment where the application relies heavily on outbound connections to a limited number of destinations but also receives inbound flows over a Load Balancer frontend. 이 경우 시나리오 1과 2를 결합하면 안심할 수 있습니다.In this case, you can combine scenarios 1 and 2 for relief. 추가 패턴은 SNAT 고갈 관리를 검토하세요.For additional patterns, review Managing SNAT exhaustion.

아웃바운드 흐름에 대한 여러 프런트 엔드Multiple frontends for outbound flows

표준 Load BalancerStandard Load Balancer

표준 Load Balancer는 여러 (공개) IP 프런트 엔드가 있을 때 동시에 아웃바운드 흐름에 대한 모든 후보를 사용합니다.Standard Load Balancer uses all candidates for outbound flows at the same time when multiple (public) IP frontends is present. 각 프런트 엔드는 부하 분산 규칙이 아웃바운드 연결에 대해 활성화된 경우 미리 할당된 사용 가능한 SNAT 포트 수를 곱합니다.Each frontend multiplies the number of available preallocated SNAT ports if a load balancing rule is enabled for outbound connections.

새 부하 분산 규칙 옵션으로 프런트 엔드 IP 주소를 아웃바운드 연결에 사용되지 않도록 선택할 수 있습니다.You can choose to suppress a frontend IP address from being used for outbound connections with a new load balancing rule option:

      "loadBalancingRules": [
        {
          "disableOutboundSnat": false
        }
      ]

일반적으로 disableOutboundSnat 옵션의 기본값은 _false_이며 이 규칙 프로그램이 부하 분산 규칙의 백 엔드 풀에 연결된 VM에 대한 SNAT를 아웃바운드하는 것을 의미합니다.Normally, the disableOutboundSnat option defaults to false and signifies that this rule programs outbound SNAT for the associated VMs in the backend pool of the load balancing rule. disableOutboundSnat을 _true_로 변경하여 Load Balancer가 이 부하 분산 규칙의 백 엔드 풀에서 VM에 대한 아웃바운드 연결에 연결된 프런트 엔드 IP 주소를 사용하지 못하게 할 수 있습니다.The disableOutboundSnat can be changed to true to prevent Load Balancer from using the associated frontend IP address for outbound connections for the VMs in the backend pool of this load balancing rule. 또한 여러 결합 시나리오에 설명된 대로 아웃바운드 흐름에 대한 특정 IP 주소를 지정할 수도 있습니다.And you can also still designate a specific IP address for outbound flows as described in Multiple, combined scenarios as well.

Load Balancer 기본Load Balancer Basic

여러(공개) IP 프런트 엔드가 아웃바운드 흐름의 후보인 경우 Load Balancer 기본은 아웃바운드 흐름에 단일 프런트 엔드를 사용하기로 선택합니다.Load Balancer Basic chooses a single frontend to be used for outbound flows when multiple (public) IP frontends are candidates for outbound flows. 이 선택은 구성할 수 없으며 선택 알고리즘은 임의로 결정된다고 보면 됩니다.This selection is not configurable, and you should consider the selection algorithm to be random. 여러 결합 시나리오에 설명된 대로 아웃바운드 흐름에 대한 특정 IP 주소를 지정할 수 있습니다.You can designate a specific IP address for outbound flows as described in Multiple, combined scenarios.

가용성 영역Availability Zones

가용성 영역이 있는 표준 Load Balancer를 사용하는 경우 영역 중복 프런트 엔드는 영역 중복 아웃바운드 SNAT 연결을 제공할 수 있으며 SNAT 프로그래밍은 영역 실패를 유지합니다.When using Standard Load Balancer with Availability Zones, zone-redundant frontends can provide zone-redundant outbound SNAT connections and SNAT programming survives zone failure. 영역 프런트 엔드가 사용되는 경우 아웃바운드 SNAT 연결은 자신이 속한 영역을 공유합니다.When zonal frontends are used, outbound SNAT connections share fate with the zone they belong to.

SNAT 및 PAT 이해Understanding SNAT and PAT

포트 가장 SNAT(PAT)Port masquerading SNAT (PAT)

공용 Load Balancer 리소스가 전용 공용 IP 주소가 없는 VM 인스턴스와 연결 된 경우 각 아웃 바운드 연결 원본이 다시 작성 됩니다.When a public Load Balancer resource is associated with VM instances, which do not have dedicated Public IP addresses, each outbound connection source is rewritten. 원본은 가상 네트워크 개인 IP 주소 공간에서 부하 분산 장치의 프런트 엔드 공용 IP 주소로 다시 작성됩니다.The source is rewritten from the virtual network private IP address space to the frontend Public IP address of the load balancer. 공용 IP 주소 공간에서 흐름의 5튜플(원본 IP 주소, 원본 포트, IP 전송 프로토콜, 대상 IP 주소, 대상 포트)은 고유해야 합니다.In the public IP address space, the 5-tuple of the flow (source IP address, source port, IP transport protocol, destination IP address, destination port) must be unique. 포트 가장 SNAT는 TCP 또는 UDP IP 프로토콜과 함께 사용할 수 있습니다.Port masquerading SNAT can be used with either TCP or UDP IP protocols.

여러 흐름이 단일 공용 IP 주소에서 시작되므로 삭제 포트(SNAT 포트)는 프라이빗 원본 IP 주소를 다시 작성한 후 이 목적에 사용됩니다.Ephemeral ports (SNAT ports) are used to achieve this after rewriting the private source IP address, because multiple flows originate from a single public IP address. 포트 위장 SNAT 알고리즘은 UDP와 TCP의 SNAT 포트를 다르게 할당합니다.The port masquerading SNAT algorithm allocates SNAT ports differently for UDP versus TCP.

TCP SNAT 포트TCP SNAT Ports

단일 대상 IP 주소, 포트에 대한 흐름당 하나의 SNAT 포트가 사용됩니다.One SNAT port is consumed per flow to a single destination IP address, port. 동일한 대상 IP 주소, 포트 및 프로토콜에 대한 여러 TCP 흐름의 경우 각 TCP 흐름은 단일 SNAT 포트를 사용합니다.For multiple TCP flows to the same destination IP address, port, and protocol, each TCP flow consumes a single SNAT port. 이렇게 하면 흐름이 동일한 대상 IP 주소에서 시작하여 동일한 대상 IP 주소, 포트 및 프로토콜로 이동하는 경우 흐름의 고유성이 보장됩니다.This ensures that the flows are unique when they originate from the same public IP address and go to the same destination IP address, port, and protocol.

서로 다른 대상 IP 주소, 포트 및 프로토콜에 대한 여러 흐름은 단일 SNAT 포트를 공유합니다.Multiple flows, each to a different destination IP address, port, and protocol, share a single SNAT port. 대상 IP 주소, 포트 및 프로토콜은 공용 IP 주소 공간에서 흐름을 구분하는 추가 원본 포트를 사용하지 않고도 흐름을 고유하게 만들어줍니다.The destination IP address, port, and protocol make flows unique without the need for additional source ports to distinguish flows in the public IP address space.

UDP SNAT 포트UDP SNAT Ports

UDP SNAT 포트는 TCP SNAT 포트와는 다른 알고리즘을 통해 관리됩니다.UDP SNAT ports are managed by a different algorithm than TCP SNAT ports. 부하 분산 장치는 UDP에 "포트 제한 원뿔형 NAT"이라고 하는 알고리즘을 사용합니다.Load Balancer uses an algorithm known as "port-restricted cone NAT" for UDP. 대상 IP 주소, 포트에 관계없이 각 흐름당 하나의 SNAT 포트가 사용됩니다.One SNAT port is consumed for each flow, irrespective of destination IP address, port.

SNAT 포트 다시 사용SNAT port reuse

포트를 해제 한 후에는 필요에 따라 포트를 재사용할 수 있습니다.Once a port has been released, the port is available for reuse as needed. SNAT 포트는 지정 된 시나리오에서 사용 가능한 최하위에서 가장 높은 시퀀스로 간주할 수 있으며, 첫 번째 사용 가능한 SNAT 포트는 새 연결에 사용 됩니다.You can think of SNAT ports as a sequence from lowest to highest available for a given scenario, and the first available SNAT port is used for new connections.

고갈Exhaustion

SNAT 포트 리소스가 고갈되면 기존 흐름에서 SNAT 포트를 릴리스할 때까지 아웃바운드 흐름이 실패합니다.When SNAT port resources are exhausted, outbound flows fail until existing flows release SNAT ports. Load Balancer는 흐름이 닫히면 SNAT 포트를 회수하고 유휴 흐름에서 SNAT 포트를 회수하기 위해 4분 유휴 시간 제한을 사용합니다.Load Balancer reclaims SNAT ports when the flow closes and uses a 4-minute idle timeout for reclaiming SNAT ports from idle flows.

사용되는 알고리즘의 차이로 인해 일반적으로 UDP SNAT 포트가 TCP SNAT 포트보다 훨씬 빠르게 고갈됩니다.UDP SNAT ports generally exhaust much faster than TCP SNAT ports due to the difference in algorithm used. 이러한 차이를 염두에 두고 테스트를 설계하고 규모를 결정해야 합니다.You must design and scale test with this difference in mind.

흔히 SNAT 포트 고갈로 이어지는 조건을 완화하는 패턴은 SNAT 관리 섹션을 검토하세요.For patterns to mitigate conditions that commonly lead to SNAT port exhaustion, review the Managing SNAT section.

포트 가장 SNAT(PAT)에 대한 삭제 포트 미리 할당Ephemeral port preallocation for port masquerading SNAT (PAT)

Azure는 포트 가장 SNAT(PAT)을 사용할 때 백 엔드 풀의 크기에 따라 사용 가능한 미리 할당 SNAT 포트 수를 결정하는 알고리즘을 사용합니다.Azure uses an algorithm to determine the number of preallocated SNAT ports available based on the size of the backend pool when using port masquerading SNAT (PAT). SNAT 포트는 특정 공용 IP 원본 주소에 사용할 수 있는 삭제 포트입니다.SNAT ports are ephemeral ports available for a particular public IP source address. 부하 분산 장치와 연결 된 각 공용 IP 주소에 대해 각 IP 전송 프로토콜에 대 한 SNAT 포트로 사용할 수 있는 64000 포트가 있습니다.For each Public IP address associated with a load balancer there are 64,000 ports available as SNAT ports for each IP transport protocol.

동일한 수의 SNAT 포트가 UDP 및 TCP에 대해 각각 미리 할당되고 IP 전송 프로토콜별로 독립적으로 사용됩니다.The same number of SNAT ports are preallocated for UDP and TCP respectively and consumed independently per IP transport protocol. 그러나 SNAT 포트 사용은 흐름이 UDP인지 아니면 TCP인지에 따라 다릅니다.However, the SNAT port usage is different depending on whether the flow is UDP or TCP.

중요

표준 SKU SNAT 프로그래밍은 IP 전송 프로토콜별로 사용되며 부하 분산 규칙에서 파생됩니다.Standard SKU SNAT programming is per IP transport protocol and derived from the load balancing rule. TCP 부하 분산 규칙만 존재하는 경우, TCP에만 SNAT를 사용할 수 있습니다.If only a TCP load balancing rule exists, SNAT is only available for TCP. TCP 부하 분산 규칙만 있고 UDP에 대한 아웃바운드 SNAT가 필요한 경우, 동일한 프런트 엔드 풀에서 동일한 백 엔드 풀로의 UDP 부하 분산 규칙을 만듭니다.If you have only a TCP load balancing rule and need outbound SNAT for UDP, create a UDP load balancing rule from the same frontend to the same backend pool. 이렇게 하면 UDP에 대한 SNAT 프로그래밍이 트리거됩니다.This will trigger SNAT programming for UDP. 작업 규칙 또는 상태 프로브는 필요하지 않습니다.A working rule or health probe is not required. 기본 SKU SNAT는 부하 분산 규칙에 지정된 전송 프로토콜과 관계없이 항상 IP 전송 프로토콜 둘 다에 대해 SNAT를 프로그래밍합니다.Basic SKU SNAT always programs SNAT for both IP transport protocol, irrespective of the transport protocol specified in the load balancing rule.

Azure는 각 VM NIC의 IP 구성에 SNAT 포트를 미리 할당합니다.Azure preallocates SNAT ports to the IP configuration of the NIC of each VM. 풀에 IP 구성이 추가되면 백 엔드 풀 크기에 따라 이 IP 구성에 대한 SNAT 포트가 미리 할당됩니다.When an IP configuration is added to the pool, the SNAT ports are preallocated for this IP configuration based on the backend pool size. 아웃바운드 흐름이 생성되면 PAT는 흐름이 닫히거나 유휴 제한 시간에 도달하는 경우 이러한 포트를 동적으로 소비(미리 할당된 제한까지)하거나 해제합니다.When outbound flows are created, PAT dynamically consumes (up to the preallocated limit) and releases these ports when the flow closes or idle timeouts happen.

다음 표는 백 엔드 풀 크기 계층의 SNAT 포트 미리 할당을 보여줍니다.The following table shows the SNAT port preallocations for tiers of backend pool sizes:

풀 크기(VM 인스턴스)Pool size (VM instances) IP 구성별로 미리 할당된 SNAT 포트Preallocated SNAT ports per IP configuration
1-501-50 1,0241,024
51-10051-100 512512
101-200101-200 256256
201-400201-400 128128
401-800401-800 6464
801-1,000801-1,000 3232

참고

여러 프런트 엔드를 사용 하는 표준 Load Balancer를 사용 하는 경우 각 프런트 엔드 IP 주소는 이전 테이블에서 사용 가능한 SNAT 포트 수를 곱합니다.When using Standard Load Balancer with multiple frontends, each frontend IP address multiplies the number of available SNAT ports in the previous table. 예를 들어 각각 별도의 프런트 엔드 IP 주소를 사용 하는 2 개의 부하 분산 규칙을 가진 50 VM의 백 엔드 풀은 규칙 당 2048 (2x 1024) SNAT 포트를 사용 합니다.For example, a backend pool of 50 VM's with 2 load balancing rules, each with a separate frontend IP address, will use 2048 (2x 1024) SNAT ports per rule. 여러 프런트 엔드에 대한 자세한 내용을 참조하세요.See details for multiple frontends.

사용 가능한 SNAT 포트 수는 연결 수에 직접 반영되지 않습니다.Remember that the number of SNAT ports available does not translate directly to number of flows. 여러 고유한 대상에 단일 SNAT 포트를 재사용할 수 있습니다.A single SNAT port can be reused for multiple unique destinations. 포트는 흐름을 고유하게 만드는 데 필요한 경우에만 사용됩니다.Ports are consumed only if it's necessary to make flows unique. 디자인 및 완화 지침은 고갈 가능한 리소스를 관리하는 방법에 대한 섹션과 PAT에 대해 설명하는 섹션을 참조하세요.For design and mitigation guidance, refer to the section about how to manage this exhaustible resource and the section that describes PAT.

백 엔드 풀의 크기를 변경하면 설정된 흐름에 영향을 줄 수 있습니다.Changing the size of your backend pool might affect some of your established flows. 백 엔드 풀 크기가 증가하여 그 다음 계층으로 전환되면 그 다음으로 큰 백 앤드 풀 계층으로 전환되는 동안 미리 할당된 SNAT 포트의 절반이 회수됩니다.If the backend pool size increases and transitions into the next tier, half of your preallocated SNAT ports are reclaimed during the transition to the next larger backend pool tier. 회수된 SNAT 포트와 연결된 흐름은 시간이 초과되며 다시 설정해야 합니다.Flows that are associated with a reclaimed SNAT port will time out and must be reestablished. 미리 할당된 포트를 사용할 수 있는 한, 새 흐름이 즉시 성공합니다.If a new flow is attempted, the flow will succeed immediately as long as preallocated ports are available.

백 엔드 풀 크기가 줄고 더 낮은 계층으로 전환되면 사용 가능한 SNAT 포트 수가 증가합니다.If the backend pool size decreases and transitions into a lower tier, the number of available SNAT ports increases. 이 경우 기존에 할당된 SNAT 포트와 각각의 흐름은 영향을 받지 않습니다.In this case, existing allocated SNAT ports and their respective flows are not affected.

SNAT 포트 할당은 IP 전송 프로토콜과 관련이 있으며(TCP 및 UDP가 별도로 유지 관리됨), 다음 조건에서 해제됩니다.SNAT ports allocations are IP transport protocol specific (TCP and UDP are maintained separately) and are released under the following conditions:

TCP SNAT 포트 해제TCP SNAT port release

  • 서버/클라이언트에서 FINACK를 보내는 경우 240 초 후 SNAT 포트가 해제 됩니다.If either server/client sends FINACK, SNAT port will be released after 240 seconds.
  • RST가 표시되는 경우 15초 후에 SNAT 포트가 해제됩니다.If a RST is seen, SNAT port will be released after 15 seconds.
  • 유휴 시간 제한에 도달 하면 포트가 해제 됩니다.If idle timeout has been reached, port is released.

UDP SNAT 포트 해제UDP SNAT port release

  • 유휴 시간 제한에 도달 하면 포트가 해제 됩니다.If idle timeout has been reached, port is released.

문제 해결Problem solving

이 섹션은 Azure의 아웃바운드 연결에서 발생할 수 있는 SNAT 고갈을 완화하는 데 도움을 주고자 합니다.This section is intended to help mitigate SNAT exhaustion and that can occur with outbound connections in Azure.

SNAT(PAT) 포트 고갈 관리Managing SNAT (PAT) port exhaustion

PAT 에 사용 되는 사용 후 삭제 포트 는 공용 Ip 주소가 없는 독립 실행형 vm공용 ip 주소가 없는 부하 분산 vm에 설명 된 대로 소모 성 리소스입니다. 사용 후 삭제 포트의 사용량을 모니터링 하 고 현재 할당을 비교 하 여의 위험을 확인 하거나 가이드를 사용 하 여 SNAT 소모를 확인할 수 있습니다.Ephemeral ports used for PAT are an exhaustible resource, as described in Standalone VM without a Public IP address and Load-balanced VM without a Public IP address.You can monitor your usage of ephemeral ports and compare with your current allocation to determine the risk of or to confirm SNAT exhaustion using this guide.

동일한 대상 IP 주소 및 포트에 대해 많은 아웃바운드 TCP 또는 UDP 연결을 시작할 것인지 알고 있는 경우 실패하는 아웃바운드 연결을 확인하고, 지원 서비스에서 SNAT 포트(PAT에서 사용하는 미리 할당된 삭제 포트)가 고갈될 것이라는 알림을 받는 경우 몇 가지 일반적인 완화 옵션을 사용할 수 있습니다.If you know that you're initiating many outbound TCP or UDP connections to the same destination IP address and port, and you observe failing outbound connections or are advised by support that you're exhausting SNAT ports (preallocated ephemeral ports used by PAT), you have several general mitigation options. 다음 옵션을 검토하고 시나리오에 가장 적합한 옵션을 결정합니다.Review these options and decide what is available and best for your scenario. 한 가지 이상의 옵션이 이 시나리오를 관리하는 데 도움이 될 수 있습니다.It's possible that one or more can help manage this scenario.

아웃바운드 연결 동작을 이해하는 데 어려움이 있는 경우 IP 스택 통계(netstat)를 사용할 수 있습니다.If you are having trouble understanding the outbound connection behavior, you can use IP stack statistics (netstat). 또는 패킷 캡처를 사용하여 연결 동작을 관찰하면 도움이 될 수 있습니다.Or it can be helpful to observe connection behaviors by using packet captures. 이러한 패킷 캡처는 인스턴스의 게스트 OS에서 수행할 수도 있고 패킷 캡처용 Network Watcher를 사용할 수도 있습니다.You can perform these packet captures in the guest OS of your instance or use Network Watcher for packet capture.

수동으로 SNAT 포트를 할당 하 여 VM 당 SNAT 포트 최대화Manually allocate SNAT ports to maximize SNAT ports per VM

미리 할당 된 포트에 정의 된 대로 부하 분산 장치는 백 엔드의 vm 수에 따라 포트를 자동으로 할당 합니다.As defined in preallocated ports, the load balancer will automatically allocate ports based on the number of VMs in the backend. 기본적으로이 작업은 확장성을 보장 하기 위해 신중 하 게 수행 됩니다.By default this is done conservatively to ensure scalability. 백 엔드에 포함할 최대 Vm 수를 알고 있는 경우 각 아웃 바운드 규칙에서이를 구성 하 여 SNAT 포트를 수동으로 할당할 수 있습니다.If you know the maximum number of VMs you will have in the backend you can manually allocate SNAT ports by configuring this in each outbound rule. 예를 들어, 최대 10 개의 Vm이 있는 경우 기본 1024이 아닌 VM 당 6400 SNAT 포트를 할당할 수 있습니다.For example, if you know you will have a maximum of 10 VMs you can allocate 6,400 SNAT ports per VM rather than the default 1,024.

연결을 다시 사용하도록 애플리케이션 수정Modify the application to reuse connections

애플리케이션에서 연결을 다시 사용하여 SNAT에서 사용되는 사용 후 삭제 포트에 대한 수요를 줄일 수 있습니다.You can reduce demand for ephemeral ports that are used for SNAT by reusing connections in your application. 이러한 효과는 연결 재사용이 기본 옵션인 HTTP/1.1 같은 프로토콜에서 특히 두드러집니다.This is especially true for protocols like HTTP/1.1, where connection reuse is the default. 또한 전송으로 HTTP를 사용하는 다른 프로토콜(예: REST)도 이점을 얻을 수 있습니다.And other protocols that use HTTP as their transport (for example, REST) can benefit in turn.

재사용은 언제나 각 요청에 대한 개별 원자성 TCP 연결보다 좋은 방법입니다.Reuse is always better than individual, atomic TCP connections for each request. 재사용은 TCP 트랜잭션의 성능과 효율성을 높입니다.Reuse results in more performant, very efficient TCP transactions.

연결 풀링을 사용하도록 애플리케이션 수정Modify the application to use connection pooling

애플리케이션에서 연결 풀링 체계를 사용할 수 있습니다. 이 경우 요청이 고정된 연결 집합에서 내부적으로 분산됩니다(가능한 경우 각 연결이다 시 사용됨).You can employ a connection pooling scheme in your application, where requests are internally distributed across a fixed set of connections (each reusing where possible). 이 체계는 사용 중인 삭제 포트의 수를 제한하고 보다 예측 가능한 환경을 구축합니다.This scheme constrains the number of ephemeral ports in use and creates a more predictable environment. 또한 단일 연결이 작업에 회신하느라 사용 가능하지 않을 때 여러 동시 작업을 허용하여 요청 처리량을 늘릴 수 있습니다.This scheme can also increase the throughput of requests by allowing multiple simultaneous operations when a single connection is blocking on the reply of an operation.

연결 풀링은 애플리케이션을 개발하는 데 사용하는 프레임워크 또는 애플리케이션에 대한 구성 설정에 이미 존재할 수 있습니다.Connection pooling might already exist within the framework that you're using to develop your application or the configuration settings for your application. 연결 풀링을 연결 재사용과 결합할 수 있습니다.You can combine connection pooling with connection reuse. 그러면 여러 요청이 동일한 대상 IP 주소 및 포트에 고정되고 예측 가능한 수의 포트를 사용합니다.Your multiple requests then consume a fixed, predictable number of ports to the same destination IP address and port. 또한 TCP 트랜잭션을 효율적으로 사용하여 대기 시간 및 리소스 사용량이 감소하기 때문에 요청에도 이득입니다.The requests also benefit from efficient use of TCP transactions reducing latency and resource utilization. 여러 UDP 흐름을 관리하면 고갈 조건을 피하고 SNAT 포트 활용도를 관리할 수 있으므로 UDP 트랜잭션이 도움이 될 수 있습니다.UDP transactions can also benefit, because managing the number of UDP flows can in turn avoid exhaust conditions and manage the SNAT port utilization.

덜 적극적인 재시도 논리를 사용하도록 애플리케이션 수정Modify the application to use less aggressive retry logic

PAT에 사용되는 미리 할당된 삭제 포트가 고갈되거나 애플리케이션 오류가 발생하면 지연 및 백오프 논리 없는 적극적인 또는 무차별 대입 재시도로 인해 고갈 상태가 발생하거나 지속됩니다.When preallocated ephemeral ports used for PAT are exhausted or application failures occur, aggressive or brute force retries without decay and backoff logic cause exhaustion to occur or persist. 덜 적극적인 재시도 논리를 사용하여 사용 후 삭제 포트에 대한 수요를 줄일 수 있습니다.You can reduce demand for ephemeral ports by using a less aggressive retry logic.

삭제 포트의 유휴 시간 제한은 4분입니다(조정 불가능).Ephemeral ports have a 4-minute idle timeout (not adjustable). 다시 시도 횟수가 너무 엄격하면 고갈이 스스로 지울 수 있는 기회가 없습니다.If the retries are too aggressive, the exhaustion has no opportunity to clear up on its own. 따라서 디자인할 때 애플리케이션이 트랜잭션을 어떤 방식으로 얼마나 자주 다시 시도하는지 고려하는 것이 중요합니다.Therefore, considering how--and how often--your application retries transactions is a critical part of the design.

각 VM에 공용 IP 할당Assign a Public IP to each VM

공용 IP 주소를 할당 하면 시나리오가 VM에 대 한 공용 ip로 변경 됩니다.Assigning a Public IP address changes your scenario to Public IP to a VM. 각 VM에 사용되는 공용 IP의 모든 삭제 포트를 VM에 사용할 수 있습니다.All ephemeral ports of the public IP that are used for each VM are available to the VM. (공용 IP의 삭제 포트가 해당 백 엔드 풀과 연결 된 모든 Vm과 공유 되는 시나리오와는 반대) 공용 IP 주소의 추가 비용 및 많은 수의 개별 IP 주소를 허용 목록의 잠재적 영향 등을 고려해 야 합니다.(As opposed to scenarios where ephemeral ports of a public IP are shared with all the VMs associated with the respective backend pool.) There are trade-offs to consider, such as the additional cost of public IP addresses and the potential impact of whitelisting a large number of individual IP addresses.

참고

이 옵션은 웹 작업자 역할에는 사용할 수 없습니다.This option is not available for web worker roles.

여러 프런트 엔드 사용Use multiple frontends

공용 표준 Load Balancer를 사용하는 경우 아웃바운드 연결에 대한 여러 프런트 엔드 IP 주소를 할당하고 사용 가능한 SNAT 포트의 수를 곱합니다.When using public Standard Load Balancer, you assign multiple frontend IP addresses for outbound connections and multiply the number of SNAT ports available. 프런트 엔드의 공용 IP에 대한 SNAT의 프로그래밍을 트리거하려면 프런트 엔드 IP 구성, 규칙 및 백 엔드 풀을 만듭니다.Create a frontend IP configuration, rule, and backend pool to trigger the programming of SNAT to the public IP of the frontend. 규칙은 작동할 필요가 없으며 상태 프로브는 성공할 필요가 없습니다.The rule does not need to function and a health probe does not need to succeed. 인바운드에 대해서도 여러 프런트 엔드를 사용하는 경우(아웃바운드 외에) 안정성을 유지하기 위해 사용자 지정 상태 프로브를 사용해야 합니다.If you do use multiple frontends for inbound as well (rather than just for outbound), you should use custom health probes well to ensure reliability.

참고

대부분의 경우에서 SNAT 포트 소모는 잘못된 디자인의 징후입니다.In most cases, exhaustion of SNAT ports is a sign of bad design. 더 많은 프런트 엔드를 사용하기 전에 SNAT 포트를 추가하기 위해 포트를 소진하는 이유를 이해해야 합니다.Make sure you understand why you are exhausting ports before using more frontends to add SNAT ports. 나중에 오류가 발생할 수 있는 문제를 감출 수 있습니다.You may be masking a problem which can lead to failure later.

규모 확장Scale out

미리 할당된 포트는 백 엔드 풀 크기를 기준으로 할당되며, 그다음으로 큰 백 엔드 풀 크기 계층을 수용하기 위해 일부 포트를 다시 할당해야 하는 경우, 중단 시간을 최소화하기 위해 계층으로 그룹화됩니다.Preallocated ports are assigned based on the backend pool size and grouped into tiers to minimize disruption when some of the ports have to be reallocated to accommodate the next larger backend pool size tier. 지정된 계층의 최대 크기까지 백 엔드 풀을 확장하여 지정된 프런트 엔드에 대한 SNAT 포트 사용률 강도를 늘릴 수도 있습니다.You may have an option to increase the intensity of SNAT port utilization for a given frontend by scaling your backend pool to the maximum size for a given tier. 이 경우 애플리케이션이 효율적으로 확장되어야 합니다.This requires for the application to scale out efficiently.

예를 들어 백 엔드 풀에 있는 2개의 가상 머신에서는 IP 구성당 1024개의 SNAT 포트를 사용할 수 있어 총 2048개의 SNAT 포트를 배포할 수 있습니다.For example, two virtual machines in the backend pool would have 1024 SNAT ports available per IP configuration, allowing a total of 2048 SNAT ports for the deployment. 배포를 50개 가상 머신으로 늘리는 경우, 가상 머신당 미리 할당된 포트 수가 일정한 경우에도 총 51,200(50x1024)개의 SNAT 포트를 사용할 수 있습니다.If the deployment were to be increased to 50 virtual machines, even though the number of preallocated ports remains constant per virtual machine, a total of 51,200 (50 x 1024) SNAT ports can be used by the deployment. 배포를 확장하려는 경우, 계층당 미리 할당된 포트 수를 확인하여 해당 계층의 최댓값까지 확장되도록 합니다.If you wish to scale out your deployment, check the number of preallocated ports per tier to make sure you shape your scale out to the maximum for the respective tier. 앞의 예제에서 50개가 아닌 51개의 인스턴스로 확장하도록 선택한 경우, 다음 계층으로 진행하며 합계뿐 아니라 VM당 SNAT 포트 수도 줄어듭니다.In the preceding example, if you had chosen to scale out to 51 instead of 50 instances, you would progress to the next tier and end up with fewer SNAT ports per VM as well as in total.

그다음으로 큰 백 엔드 풀 크기 계층으로 확장하는 경우, 할당된 포트를 다시 할당해야 하면 잠재적으로 일부 아웃바운드 연결이 시간 초과될 수 있습니다.If you scale out to the next larger backend pool size tier, there is potential for some of your outbound connections to time out if allocated ports have to be reallocated. SNAT 포트 중 일부만 사용하는 경우 그다음으로 큰 백 엔드 풀 크기로 확장하는 것이 중요하지 않습니다.If you are only using some of your SNAT ports, scaling out across the next larger backend pool size is inconsequential. 기존 포트 절반은 다음 백 앤드 풀 계층으로 이동할 때마다 다시 할당됩니다.Half the existing ports will be reallocated each time you move to the next backend pool tier. 이러한 경우를 방지하려면 배포를 계층 크기에 맞게 조정해야 합니다.If you don't want this to take place, you need to shape your deployment to the tier size. 또는 애플리케이션이 필요에 따라 검색하고 다시 시도할 수 있게 합니다.Or make sure your application can detect and retry as necessary. TCP Keepalive는 다시 할당되어 SNAT 포트가 더 이상 작동하지 않는 경우의 검색을 지원할 수 있습니다.TCP keepalives can assist in detect when SNAT ports no longer function due to being reallocated.

keepalive를 사용하여 아웃바운드 유휴 시간 제한 다시 설정Use keepalives to reset the outbound idle timeout

아웃바운드 연결에는 4분의 유휴 시간 제한이 적용됩니다.Outbound connections have a 4-minute idle timeout. 아웃 바운드 규칙을 통해이 시간 제한을 조정할 수 있습니다.This timeout is adjustable via Outbound rules. 전송 (예: TCP keepalive) 또는 응용 프로그램 계층 keepalive을 사용 하 여 유휴 흐름을 새로 고치고 필요한 경우이 유휴 시간 제한을 다시 설정할 수도 있습니다.You can also use transport (for example, TCP keepalives) or application-layer keepalives to refresh an idle flow and reset this idle timeout if necessary.

TCP Keepalive를 사용하는 경우 연결의 한 쪽에서 사용하도록 설정하는 것으로 충분합니다.When using TCP keepalives, it is sufficient to enable them on one side of the connection. 예를 들어 서버 쪽에서만 사용하도록 설정해도 흐름의 유휴 타이머가 다시 설정되며 양쪽에서 TCP Keepalive를 시작하지 않아도 됩니다.For example, it is sufficient to enable them on the server side only to reset the idle timer of the flow and it is not necessary for both sides to initiated TCP keepalives. 데이터베이스 클라이언트 서버 구성을 포함하여 애플리케이션 계층에 대한 유사한 개념이 있습니다.Similar concepts exist for application layer, including database client-server configurations. 서버 쪽에서 사용 가능한 애플리케이션 관련 Keepalive 옵션을 확인합니다.Check the server side for what options exist for application specific keepalives.

VM에서 사용하는 공용 IP 검색Discovering the public IP that a VM uses

여러 가지 방법으로 아웃바운드 연결의 공용 원본 IP 주소를 확인할 수 있습니다.There are many ways to determine the public source IP address of an outbound connection. OpenDNS는 VM의 공용 IP 주소를 표시할 수 있는 서비스를 제공합니다.OpenDNS provides a service that can show you the public IP address of your VM.

nslookup 명령을 사용하여 OpenDNS 확인자에 myip.opendns.com이라는 이름에 대한 DNS 쿼리를 전송할 수 있습니다.By using the nslookup command, you can send a DNS query for the name myip.opendns.com to the OpenDNS resolver. 서비스는 쿼리를 보내는 데 사용된 원본 IP 주소를 반환합니다.The service returns the source IP address that was used to send the query. VM에서 다음 쿼리를 실행하는 경우 응답은 해당 VM에 사용되는 공용 IP입니다.When you run the following query from your VM, the response is the public IP used for that VM:

nslookup myip.opendns.com resolver1.opendns.com

아웃바운드 연결 방지Preventing outbound connectivity

VM이 아웃바운드 흐름을 만들도록 허용하는 것이 바람직하지 않은 경우가 있습니다.Sometimes it's undesirable for a VM to be allowed to create an outbound flow. 또는 아웃바운드 흐름으로 연결할 수 있는 대상 또는 인바운드 흐름을 시작할 수 있는 대상을 관리하기 위한 요구 사항이 있을 수도 있습니다.Or there might be a requirement to manage which destinations can be reached with outbound flows, or which destinations can begin inbound flows. 이 경우에 네트워크 보안 그룹을 사용하여 VM에서 도달할 수 있는 대상을 관리합니다.In this case, you can use network security groups to manage the destinations that the VM can reach. 또한 NSG를 사용하여 인바운드 흐름을 시작할 수 있는 공용 대상을 관리할 수 있습니다.You can also use NSGs to manage which public destination can initiate inbound flows.

부하 분산 VM에 NSG를 적용할 때 서비스 태그기본 보안 규칙에 주의해야 합니다.When you apply an NSG to a load-balanced VM, pay attention to the service tags and default security rules. VM에서 Azure Load Balancer의 상태 프로브 요청을 수신할 수 있는지 확인해야 합니다.You must ensure that the VM can receive health probe requests from Azure Load Balancer.

NSG가 AZURE_LOADBALANCER 기본 태그의 상태 프로브 요청을 차단할 경우 VM 상태 프로브에 실패하고 VM가 표시됩니다.If an NSG blocks health probe requests from the AZURE_LOADBALANCER default tag, your VM health probe fails and the VM is marked down. 부하 분산 장치는 해당 VM에 새 흐름을 보내는 작업을 중지합니다.Load Balancer stops sending new flows to that VM.

제한 사항Limitations

  • VNet 및 기타 Microsoft 플랫폼 서비스가 없는 웹 작업자 역할은 사전 VNet 서비스 및 다른 플랫폼 서비스 작동 방식의 부작용으로 인해 내부 표준 Load Balancer만 사용할 때 액세스할 수 있습니다.Web Worker Roles without a VNet and other Microsoft platform services can be accessible when only an internal Standard Load Balancer is used due to a side effect from how pre-VNet services and other platform services function. 각 서비스 자체 또는 기본 플랫폼은 사전 통보 없이 변경될 수 있으므로 이 부작용을 사용하지 마세요.Do not rely on this side effect as the respective service itself or the underlying platform may change without notice. 내부 표준 Load Balancer만 사용하는 경우 원하면 명시적으로 아웃 바운드 연결을 만들어야 한다고 항상 가정해야 합니다.You must always assume you need to create outbound connectivity explicitly if desired when using an internal Standard Load Balancer only. 이 문서에 설명된 기본 SNAT 시나리오 3은 사용할 수 없습니다.The default SNAT scenario 3 described in this article is not available.

다음 단계Next steps