Bewerken

Delen via


Azure Well-Architected Framework-beoordeling van een Azure NAT-gateway

Azure Application Gateway
Azure Virtual Network
Azure Private Link

In dit artikel worden aanbevolen procedures voor een Azure NAT-gateway beschreven. De richtlijnen zijn gebaseerd op de vijf pijlers van architecturale uitmuntendheid: Kostenoptimalisatie, Operationele uitmuntendheid, Prestatie-efficiëntie, Betrouwbaarheid en Beveiliging.

Als vereiste voor deze richtlijnen moet u over een werkende kennis van Azure NAT Gateway beschikken en de respectieve functies ervan begrijpen. Zie de documentatie voor Azure NAT Gateway voor meer informatie.

Kostenoptimalisatie

Configureer toegang tot PaaS-oplossingen (Platform as a Service) via Azure Private Link of service-eindpunten, inclusief opslag, zodat u geen NAT-gateway hoeft te gebruiken. Voor Private Link en service-eindpunten is geen doorkruising van de NAT-gateway vereist voor toegang tot PaaS-services. Deze aanpak vermindert de kosten per gigabyte (GB) van verwerkte gegevens, vergeleken met de kosten van het gebruik van een NAT-gateway. Private Link en service-eindpunten bieden ook beveiligingsvoordelen.

Prestatie-efficiëntie

Elke NAT-gatewayresource biedt maximaal 50 gigabit per seconde (Gbps) aan doorvoer. U kunt uw implementaties splitsen in meerdere subnetten en vervolgens een NAT-gateway toewijzen aan elk subnet of elke groep subnetten om uit te schalen.

Elk openbaar IP-adres van de NAT-gateway biedt 64.512 SNAT-poorten (Source Network Address Translation). U kunt maximaal 16 IP-adressen toewijzen aan een NAT-gateway, inclusief afzonderlijke openbare IP-adressen, het openbare IP-voorvoegsel of beide. Voor elk toegewezen uitgaande IP-adres dat naar hetzelfde doeleindpunt gaat, kan de NAT-gateway respectievelijk ondersteuning bieden voor maximaal 50.000 gelijktijdige stromen voor Transmission Control Protocol (TCP) en User Datagram Protocol (UDP).

SNAT-uitputting

Houd rekening met de volgende richtlijnen om SNAT-uitputting te voorkomen:

  • NAT-gatewayresources hebben een standaard time-out voor TCP-inactiviteit van vier minuten. U kunt de time-out tot 120 minuten configureren. Als u deze instelling wijzigt in een hogere waarde dan de standaardwaarde, wordt de NAT-gateway langer op stromen vastgezet, waardoor de SNAT-poortinventaris onnodig wordt belast.

  • Atomische aanvragen (één aanvraag per verbinding) beperken schaal, prestaties verminderen en betrouwbaarheid verminderen. In plaats van atomische aanvragen kunt u HTTP- of HTTPS-verbindingen opnieuw gebruiken om het aantal verbindingen en bijbehorende SNAT-poorten te verminderen. Wanneer u verbindingen opnieuw gebruikt, kan de toepassing beter worden geschaald. De prestaties van toepassingen worden verbeterd vanwege verminderde handshakes, overhead en cryptografische bewerkingskosten wanneer u TLS (Transport Layer Security) gebruikt.

  • Als u de resultaten van dns-resolver niet in de cache opgeslagen, kunnen DNS-zoekacties (Domain Name System) veel afzonderlijke stromen op volume introduceren. Gebruik DNS-caching om het volume van stromen te verminderen en het aantal SNAT-poorten te verminderen. DNS is het naamgevingssysteem waarmee domeinnamen worden toegewezen aan IP-adressen voor resources die zijn verbonden met internet of met een particulier netwerk.

  • UDP-stromen, zoals DNS-zoekopdrachten, gebruiken SNAT-poorten tijdens de time-out voor inactiviteit. De time-outtimer voor inactiviteit van de UDP is vier minuten opgelost.

  • Gebruik verbindingspools om vorm te geven aan het volume van uw verbindingen.

  • Als u stromen wilt opschonen, laat u TCP-stromen niet op de achtergrond verlaten of vertrouwt u op TCP-timers. Als u TCP niet expliciet een verbinding laat sluiten, blijft de TCP-verbinding geopend. Tussenliggende systemen en eindpunten houden deze verbinding in gebruik, waardoor de SNAT-poort niet beschikbaar is voor andere verbindingen. Deze antipatroon kan toepassingsfouten en SNAT-uitputting activeren.

  • Wijzig geen tcp-gerelateerde timerwaarden op besturingssysteemniveau, tenzij u weet wat de gevolgen zijn. Als de eindpunten van een verbinding niet overeenkomen met de verwachtingen, kan de TCP-stack worden hersteld, maar dit kan een negatieve invloed hebben op de prestaties van uw toepassing. Doorgaans hebt u een onderliggend ontwerpprobleem als u timerwaarden wilt wijzigen. En als de onderliggende toepassing andere antipatronen heeft en u timerwaarden wijzigt, kunt u ook SNAT-uitputting versnellen.

Bekijk de volgende richtlijnen om de schaal en betrouwbaarheid van uw service te verbeteren:

  • Overweeg de gevolgen van het verminderen van de time-out voor inactiviteit van TCP tot een lagere waarde. Een standaard time-out voor inactiviteit van vier minuten kan vooraf SNAT-poortinventaris vrijmaken.

  • Overweeg asynchrone pollingpatronen voor langlopende bewerkingen om uw verbindingsresources vrij te maken voor andere bewerkingen.

  • Overweeg het gebruik van TCP-keepalives of application-layer-keepalives voor langdurige TCP-stromen, zoals hergebruikte TCP-verbindingen, om te voorkomen dat tussenliggende systemen een time-out optreedt. U moet alleen de time-out voor inactiviteit verhogen als laatste redmiddel en de hoofdoorzaak wordt mogelijk niet opgelost. Een lange time-out kan fouten met een lage snelheid veroorzaken wanneer de time-out verloopt. Het kan ook leiden tot een vertraging en onnodige fouten. U kunt TCP-keepalives van de ene kant van een verbinding inschakelen om een verbinding van beide zijden actief te houden.

  • Overweeg om UDP-keepalives te gebruiken voor UDP-stromen met een lange levensduur om te voorkomen dat tussenliggende systemen een time-out optreedt. Wanneer u UDP-keepalives aan één zijde van de verbinding inschakelt, blijft slechts één kant van de verbinding actief. U moet UDP-keepalives aan beide zijden van een verbinding inschakelen om een verbinding actief te houden.

  • Houd rekening met respijtieve patronen voor nieuwe pogingen om agressieve nieuwe pogingen en bursts te voorkomen tijdens tijdelijke fout- of foutherstel. Voor de antipatroon atomische verbindingen maakt u een nieuwe TCP-verbinding voor elke HTTP-bewerking. Atomische verbindingen verspillen resources en voorkomen dat uw toepassing goed kan worden geschaald.

    Als u de transactiesnelheid wilt verhogen en de resourcekosten voor uw toepassing wilt verlagen, moet u altijd meerdere bewerkingen in dezelfde verbinding uitvoeren. Wanneer uw toepassing transportlaagversleuteling gebruikt, bijvoorbeeld TLS, verhoogt de nieuwe verbindingsverwerking de kosten. Zie Ontwerppatronen in de Azure-cloud voor meer best practice-patronen.

Operationele uitmuntendheid

U kunt een NAT-gateway gebruiken met Azure Kubernetes Service (AKS), maar NAT-gatewaybeheer is niet opgenomen in AKS. Als u een NAT-gateway toewijst aan het CNI-subnet (Container Networking Interface), schakelt u AKS-pods in voor uitgaand verkeer via de NAT-gateway.

Wanneer u meerdere NAT-gateways in meerdere zones of regio's gebruikt, houdt u het uitgaande IP-domein beheerbaar met behulp van openbare IP-voorvoegsels of BYOIP-voorvoegsels (Bring-Your-Own IP). U kunt geen IP-voorvoegselgrootte toewijzen die groter is dan 16 IP-adressen (/28 voorvoegselgrootte) aan een NAT-gateway.

Gebruik Azure Monitor-waarschuwingen om het gebruik van SNAT-poorten, verwerkte of verwijderde pakketten en de hoeveelheid verzonden gegevens te bewaken en te waarschuwen. Gebruik NSG-stroomlogboeken (netwerkbeveiligingsgroep) om de uitgaande verkeersstroom van VM-exemplaren (virtual machine) te bewaken in een nat-gateway geconfigureerd subnet.

Wanneer u een subnet configureert met een NAT-gateway, vervangt de NAT-gateway alle andere uitgaande connectiviteit met het openbare internet voor alle VM's in dat subnet. De NAT-gateway heeft voorrang op een load balancer, ongeacht de regels voor uitgaand verkeer. De gateway heeft ook voorrang op openbare IP-adressen die rechtstreeks aan VM's zijn toegewezen. Azure houdt de richting van een stroom bij en voorkomt asymmetrische routering. Binnenkomend verkeer, zoals een front-end-IP van een load balancer, wordt correct vertaald en wordt afzonderlijk vertaald van uitgaand verkeer via een NAT-gateway. Dankzij deze scheiding kunnen binnenkomende en uitgaande services naadloos naast elkaar bestaan.

We raden een NAT-gateway aan als de standaardinstelling voor het inschakelen van uitgaande connectiviteit voor virtuele netwerken. Een NAT-gateway biedt efficiëntie en operationele eenvoud in vergelijking met andere uitgaande connectiviteitstechnieken in Azure. NAT-gateways wijzen SNAT-poorten op aanvraag toe en gebruiken een efficiënter algoritme om conflicten met het hergebruik van SNAT-poorten te voorkomen. Vertrouw niet op de standaard antipatroon voor uitgaande connectiviteit voor uw omgeving. Definieer in plaats daarvan uw configuratie expliciet met NAT-gatewaybronnen.

Betrouwbaarheid

NAT-gatewaybronnen zijn maximaal beschikbaar in één beschikbaarheidszone en omvatten meerdere foutdomeinen. U kunt een NAT-gateway implementeren in een geen zone waarin Azure automatisch een zone selecteert om de NAT-gateway te plaatsen of de NAT-gateway te isoleren naar een specifieke beschikbaarheidszone.

Om isolatie van beschikbaarheidszones te bieden, moet elk subnet alleen resources binnen een specifieke zone hebben. Als u deze aanpak wilt implementeren, kunt u het volgende doen:

  • Implementeer een subnet voor elk van de beschikbaarheidszones waar VM's worden geïmplementeerd.
  • Lijn de zonegebonden VM's uit met overeenkomende zonegebonden NAT-gateways.
  • Bouw afzonderlijke zonegebonden stacks.

In het volgende diagram bevindt een VM in beschikbaarheidszone 1 zich op een subnet met andere resources die zich ook alleen in beschikbaarheidszone 1 bevinden. Een NAT-gateway is geconfigureerd in beschikbaarheidszone 1 om dat subnet te bedienen.

Diagram dat de richtingsstroom van een zonegebonden stack laat zien.

Virtuele netwerken en subnetten omvatten alle beschikbaarheidszones in een regio. U hoeft ze niet te verdelen door beschikbaarheidszones om ruimte te bieden aan zonegebonden resources.

Beveiliging

Met een NAT-gateway hebben afzonderlijke VM's of andere rekenresources geen openbare IP-adressen nodig en kunnen ze volledig privé blijven. Resources zonder een openbaar IP-adres kunnen nog steeds externe bronnen buiten het virtuele netwerk bereiken. U kunt een openbaar IP-voorvoegsel koppelen om ervoor te zorgen dat u een aaneengesloten set IP-adressen gebruikt voor uitgaande connectiviteit. U kunt doelfirewallregels configureren op basis van deze voorspelbare IP-lijst.

Een algemene benadering is het ontwerpen van een nvA-scenario (virtueel netwerkapparaat) met niet-Microsoft-firewalls of met proxyservers. Wanneer u een NAT-gateway implementeert in een subnet met een virtuele-machineschaalset met NVA's, gebruiken deze NVA's een of meer NAT-gatewayadressen voor uitgaande connectiviteit in plaats van een IP-adres van een load balancer of de afzonderlijke IP-adressen. Zie Azure Firewall integreren met Azure Standard Load Balancer als u dit scenario wilt gebruiken met Azure Firewall.

Diagram met firewalls met een load balancer sandwich en NAT-gateway.

U kunt de waarschuwingsfunctie Microsoft Defender voor Cloud gebruiken om te controleren op verdachte uitgaande connectiviteit in een NAT-gateway.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen