Uitgaande verbindingen (klassiek)

  • Artikel

Azure biedt uitgaande connectiviteit voor klantimplementaties via verschillende mechanismen. In dit artikel wordt beschreven wat de scenario's zijn, wanneer ze van toepassing zijn, hoe ze werken en hoe u deze kunt beheren.

Notitie

In dit artikel worden alleen klassieke implementaties behandeld. Bekijk uitgaande verbindingen voor alle Resource Manager implementatiescenario's in Azure.

Een implementatie in Azure kan communiceren met eindpunten buiten Azure in de openbare IP-adresruimte. Wanneer een exemplaar een uitgaande stroom naar een bestemming in de openbare IP-adresruimte initieert, wijst Azure het privé-IP-adres dynamisch toe aan een openbaar IP-adres. Nadat deze toewijzing is gemaakt, kan retourverkeer voor deze uitgaande stroom ook het privé-IP-adres bereiken waarvan de stroom afkomstig is.

Azure gebruikt SNAT (Source Network Address Translation) om deze functie uit te voeren. Wanneer meerdere privé-IP-adressen zich voordoen achter één openbaar IP-adres, gebruikt Azure PORT Address Translation (PAT) om privé-IP-adressen te maskeren. Tijdelijke poorten worden gebruikt voor PAT en worden vooraf toegewezen op basis van de grootte van de groep.

Er zijn meerdere uitgaande scenario's. U kunt deze scenario's zo nodig combineren. Bekijk deze zorgvuldig om inzicht te hebben in de mogelijkheden, beperkingen en patronen die van toepassing zijn op uw implementatiemodel en toepassingsscenario. Bekijk de richtlijnen voor het beheren van deze scenario's.

Overzicht van scenario's

Azure biedt drie verschillende methoden om klassieke implementaties voor uitgaande connectiviteit te realiseren. Niet alle klassieke implementaties hebben alle drie de scenario's:

Scenario Methode IP-protocollen Description Webwerkrol IaaS
1. VM met een openbaar IP-adres op exemplaarniveau SNAT, poortvermoeding niet gebruikt TCP, UDP, ICMP, ESP Azure maakt gebruik van de aan het openbare IP toegewezen virtuele machine. Voor het exemplaar zijn alle tijdelijke poorten beschikbaar. Nee Ja
2. openbaar eindpunt met gelijke taakverdeling SNAT met poortmaskering (PAT) naar het openbare eindpunt TCP, UDP Azure deelt het openbare IP-adreseindpunt met meerdere privé-eindpunten. Azure maakt gebruik van tijdelijke poorten van het openbare eindpunt voor PAT. Ja Ja
3. Zelfstandige VM SNAT met poortmaskering (PAT) TCP, UDP Azure wijst automatisch een openbaar IP-adres aan voor SNAT, deelt dit openbare IP-adres met de hele implementatie en gebruikt tijdelijke poorten van het IP-adres van het openbare eindpunt voor PAT. Dit is een terugvalscenario voor de voorgaande scenario's. Dit wordt niet aanbevolen als u zichtbaarheid en controle nodig hebt. Ja Ja

Dit is een subset van de functionaliteit voor uitgaande verbindingen die beschikbaar is voor Resource Manager-implementaties in Azure.

Verschillende implementaties in de klassieke versie hebben verschillende functionaliteit:

Klassieke implementatie Beschikbare functionaliteit
Virtuele machine scenario 1, 2 of 3
Webwerkrol alleen scenario 2, 3

Risicobeperkingsstrategieën hebben ook dezelfde verschillen.

Het algoritme dat wordt gebruikt voor het vooraf toewijzen van tijdelijke poorten voor PAT voor klassieke implementaties, is hetzelfde als voor implementaties van Azure Resource Manager-resources.

Scenario 1: VM met een openbaar IP-adres op exemplaarniveau

In dit scenario is aan de VM een openbaar IP-adres (ILPIP) op exemplaarniveau toegewezen. Wat uitgaande verbindingen betreft, maakt het niet uit of de VM een eindpunt met taakverdeling heeft of niet. Dit scenario heeft voorrang op de andere scenario's. Wanneer een ILPIP wordt gebruikt, gebruikt de VM de ILPIP voor alle uitgaande stromen.

Een openbaar IP-adres dat is toegewezen aan een VM is een 1:1-relatie (in plaats van 1:veel) en geïmplementeerd als een staatloze 1:1 NAT. Poortmaskering (PAT) wordt niet gebruikt en de VM heeft alle tijdelijke poorten die beschikbaar zijn voor gebruik.

Als uw toepassing veel uitgaande stromen initieert en u last hebt van uitputting van de SNAT-poort, kunt u overwegen om een ILPIP toe te wijzen om SNAT-beperkingen te beperken. Bekijk SNAT-uitputting in zijn geheel beheren.

Scenario 2: Openbaar eindpunt met gelijke taakverdeling

In dit scenario wordt de VM of webwerkrol gekoppeld aan een openbaar IP-adres via het eindpunt met gelijke taakverdeling. Aan de VM is geen openbaar IP-adres toegewezen.

Wanneer de VM met taakverdeling een uitgaande stroom maakt, vertaalt Azure het privébron-IP-adres van de uitgaande stroom naar het openbare IP-adres van het openbare eindpunt met gelijke taakverdeling. Azure gebruikt SNAT om deze functie uit te voeren. Azure maakt ook gebruik van PAT om meerdere privé-IP-adressen achter een openbaar IP-adres te maskeren.

Tijdelijke poorten van de front-end van het openbare IP-adres van de load balancer worden gebruikt om afzonderlijke stromen te onderscheiden die afkomstig zijn van de VM. SNAT maakt dynamisch gebruik van vooraf toegewezen tijdelijke poorten wanneer uitgaande stromen worden gemaakt. In deze context worden de tijdelijke poorten die voor SNAT worden gebruikt, SNAT-poorten genoemd.

SNAT-poorten zijn vooraf toegewezen, zoals beschreven in de sectie Inzicht in SNAT en PAT . Ze zijn een eindige resource die kan worden uitgeput. Het is belangrijk om te begrijpen hoe ze worden gebruikt. Raadpleeg SNAT-uitputting beheren om te begrijpen hoe u ontwerpt voor dit verbruik en hoe u deze zo nodig kunt beperken.

Wanneer er meerdere openbare eindpunten met gelijke taakverdeling bestaan, zijn deze openbare IP-adressen een kandidaat voor uitgaande stromen en wordt er een willekeurig geselecteerd.

Scenario 3: Er is geen openbaar IP-adres gekoppeld

In dit scenario maakt de VM of webwerkrol-ROle geen deel uit van een openbaar eindpunt met gelijke taakverdeling. En in het geval van een VM is er geen ILPIP-adres aan toegewezen. Wanneer de VM een uitgaande stroom maakt, vertaalt Azure het privébron-IP-adres van de uitgaande stroom naar een openbaar bron-IP-adres. Het openbare IP-adres dat voor deze uitgaande stroom wordt gebruikt, kan niet worden geconfigureerd en telt niet mee voor de openbare IP-resourcelimiet van het abonnement. Azure wijst dit adres automatisch toe.

Azure maakt gebruik van SNAT met pat (port masquerading) om deze functie uit te voeren. Dit scenario is vergelijkbaar met scenario 2, behalve dat er geen controle is over het gebruikte IP-adres. Dit is een terugvalscenario voor wanneer scenario 1 en 2 niet bestaan. We raden dit scenario niet aan als u controle wilt over het uitgaande adres. Als uitgaande verbindingen een essentieel onderdeel van uw toepassing zijn, moet u een ander scenario kiezen.

SNAT-poorten zijn vooraf toegewezen, zoals beschreven in de sectie Inzicht in SNAT en PAT . Het aantal VM's of webwerkrollen dat het openbare IP-adres deelt, bepaalt het aantal vooraf toegewezen tijdelijke poorten. Het is belangrijk om te begrijpen hoe ze worden gebruikt. Raadpleeg SNAT-uitputting beheren om te begrijpen hoe u ontwerpt voor dit verbruik en hoe u deze zo nodig kunt beperken.

Inzicht in SNAT en PAT

Poort vermomd SNAT (PAT)

Wanneer een implementatie een uitgaande verbinding maakt, wordt elke uitgaande verbindingsbron herschreven. De bron wordt herschreven van de privé-IP-adresruimte naar het openbare IP-adres dat is gekoppeld aan de implementatie (op basis van de hierboven beschreven scenario's). In de openbare IP-adresruimte moet de 5 tuple van de stroom (bron-IP-adres, bronpoort, IP-transportprotocol, doel-IP-adres, doelpoort) uniek zijn.

Tijdelijke poorten (SNAT-poorten) worden gebruikt om dit te bereiken na het herschrijven van het privébron-IP-adres, omdat meerdere stromen afkomstig zijn van één openbaar IP-adres.

Er wordt één SNAT-poort per stroom gebruikt naar één doel-IP-adres, poort en protocol. Voor meerdere stromen naar hetzelfde doel-IP-adres, dezelfde poort en hetzelfde protocol gebruikt elke stroom één SNAT-poort. Dit zorgt ervoor dat de stromen uniek zijn wanneer ze afkomstig zijn van hetzelfde openbare IP-adres en naar hetzelfde doel-IP-adres, dezelfde poort en hetzelfde protocol gaan.

Meerdere stromen, elk naar een ander DOEL-IP-adres, poort en protocol, delen één SNAT-poort. Het doel-IP-adres, de poort en het protocol maken stromen uniek zonder dat er extra bronpoorten nodig zijn om stromen in de openbare IP-adresruimte te onderscheiden.

Wanneer SNAT-poortresources zijn uitgeput, mislukken uitgaande stromen totdat bestaande stromen SNAT-poorten vrijgeven. Load Balancer maakt SNAT-poorten vrij wanneer de stroom wordt gesloten en een time-out van vier minuten voor inactiviteit gebruikt voor het vrijmaken van SNAT-poorten van niet-actieve stromen.

Raadpleeg de sectie SNAT beheren voor patronen om omstandigheden te beperken die vaak leiden tot uitputting van de SNAT-poort .

Tijdelijke poortvoorbezetting voor poortmaskering SNAT (PAT)

Azure gebruikt een algoritme om het aantal vooraf toegewezen SNAT-poorten te bepalen dat beschikbaar is op basis van de grootte van de back-endpool bij gebruik van poortmaskering SNAT (PAT). SNAT-poorten zijn tijdelijke poorten die beschikbaar zijn voor een bepaald openbaar IP-bronadres.

Azure verwijst vooraf naar SNAT-poorten wanneer een exemplaar wordt geïmplementeerd op basis van het aantal VM- of webwerkrolinstanties die een bepaald openbaar IP-adres delen. Wanneer uitgaande stromen worden gemaakt, verbruikt PAT dynamisch (tot de vooraf toegewezen limiet) en worden deze poorten vrijgegeven wanneer de stroom wordt gesloten of time-outs voor inactiviteit optreden.

In de volgende tabel ziet u de SNAT-poortvoorbezettingen voor lagen van back-endpoolgrootten:

exemplaren Vooraf toegewezen SNAT-poorten per exemplaar
1-50 1\.024
51-100 512
101-200 256
201-400 128

Houd er rekening mee dat het aantal beschikbare SNAT-poorten niet rechtstreeks wordt omgezet in het aantal stromen. Eén SNAT-poort kan opnieuw worden gebruikt voor meerdere unieke bestemmingen. Poorten worden alleen gebruikt als dit nodig is om stromen uniek te maken. Raadpleeg voor ontwerp- en risicobeperkingsrichtlijnen de sectie over het beheren van deze uitputtbare resource en de sectie waarin PAT wordt beschreven.

Als u de grootte van uw implementatie wijzigt, kan dit van invloed zijn op een aantal van de bestaande stromen. Als de grootte van de back-endpool toeneemt en overgaat naar de volgende laag, wordt de helft van de vooraf toegewezen SNAT-poorten opnieuw vrijgemaakt tijdens de overgang naar de volgende grotere back-endpoollaag. Stromen die zijn gekoppeld aan een teruggewonnen SNAT-poort, krijgen een time-out en moeten opnieuw worden hersteld. Als een nieuwe stroom wordt geprobeerd, slaagt de stroom onmiddellijk zolang er vooraf toegewezen poorten beschikbaar zijn.

Als de implementatiegrootte afneemt en overgaat naar een lagere laag, neemt het aantal beschikbare SNAT-poorten toe. In dit geval worden bestaande toegewezen SNAT-poorten en hun respectieve stromen niet beïnvloed.

Als een cloudservice opnieuw wordt geïmplementeerd of gewijzigd, kan de infrastructuur tijdelijk rapporteren dat de back-endpool maximaal twee keer zo groot is als de werkelijke pool. Azure zal op zijn beurt minder SNAT-poorten per exemplaar toewijzen dan verwacht. Dit kan tijdelijk de kans op uitputting van SNAT-poorten vergroten. Uiteindelijk wordt de poolgrootte overgezet naar de werkelijke grootte en wordt de vooraf toegewezen SNAT-poorten automatisch verhoogd naar het verwachte aantal volgens de bovenstaande tabel. Dit gedrag is standaard en kan niet worden geconfigureerd.

Toewijzingen van SNAT-poorten zijn specifiek voor het IP-transportprotocol (TCP en UDP worden afzonderlijk onderhouden) en worden vrijgegeven onder de volgende voorwaarden:

Tcp SNAT-poortrelease

  • Als beide server/client FIN/ACK verzendt, wordt de SNAT-poort na 240 seconden vrijgegeven.
  • Als er een RST wordt gezien, wordt de SNAT-poort na 15 seconden vrijgegeven.
  • Time-out voor inactiviteit is bereikt

Release van UDP SNAT-poort

  • Time-out voor inactiviteit is bereikt

Probleemoplossing

Deze sectie is bedoeld om SNAT-uitputting en andere scenario's te beperken die kunnen optreden met uitgaande verbindingen in Azure.

Uitputting van SNAT-poorten (PAT) beheren

Tijdelijke poorten die voor PAT worden gebruikt, zijn een uitputtbare resource, zoals beschreven in geen openbaar IP-gekoppeld en openbaar eindpunt met gelijke taakverdeling.

Als u weet dat u veel uitgaande TCP- of UDP-verbindingen naar hetzelfde doel-IP-adres en dezelfde poort initieert en u ziet dat uitgaande verbindingen mislukken of door de ondersteuning wordt geadviseerd dat u SNAT-poorten verbruikt (vooraf toegewezen tijdelijke poorten die door PAT worden gebruikt), hebt u verschillende algemene oplossingsopties. Bekijk deze opties en bepaal wat beschikbaar en het beste is voor uw scenario. Het is mogelijk dat een of meer kunnen helpen bij het beheren van dit scenario.

Als u problemen ondervindt met het begrijpen van het gedrag van uitgaande verbindingen, kunt u IP-stackstatistieken (netstat) gebruiken. Het kan ook handig zijn om verbindingsgedrag te observeren met behulp van pakketopnamen.

Pas de toepassing aan om verbindingen opnieuw te gebruiken

U kunt de vraag naar tijdelijke poorten die worden gebruikt voor SNAT verminderen door verbindingen in uw toepassing opnieuw te gebruiken. Dit geldt met name voor protocollen zoals HTTP/1.1, waarbij hergebruik van verbindingen de standaardinstelling is. En andere protocollen die HTTP als transport gebruiken (bijvoorbeeld REST) kunnen op hun beurt profiteren.

Hergebruik is altijd beter dan afzonderlijke atomische TCP-verbindingen voor elke aanvraag. Hergebruik resulteert in beter presterende, zeer efficiënte TCP-transacties.

Pas de toepassing zo aan dat deze verbindingsgroepen gebruikt

U kunt een groepsschema voor verbindingen in uw toepassing gebruiken, waarbij aanvragen intern worden verdeeld over een vaste set verbindingen (elke wordt waar mogelijk hergebruikt). Dit schema beperkt het aantal tijdelijke poorten dat wordt gebruikt en creëert een meer voorspelbare omgeving. Dit schema kan ook de doorvoer van aanvragen verhogen door meerdere gelijktijdige bewerkingen toe te staan wanneer één verbinding het antwoord van een bewerking blokkeert.

Groepsgewijze verbindingen bestaan mogelijk al binnen het framework dat u gebruikt voor het ontwikkelen van uw toepassing of de configuratie-instellingen voor uw toepassing. U kunt groepsgewijze verbindingen combineren met het opnieuw gebruiken van de verbinding. Uw meerdere aanvragen verbruiken vervolgens een vast, voorspelbaar aantal poorten naar hetzelfde doel-IP-adres en dezelfde poort. De aanvragen profiteren ook van efficiënt gebruik van TCP-transacties die latentie en resourcegebruik verminderen. UDP-transacties kunnen ook profiteren, omdat het beheren van het aantal UDP-stromen op zijn beurt uitlaatgassen kan voorkomen en het gebruik van de SNAT-poort kan worden beheerd.

Pas de toepassing zo aan dat deze minder agressieve logica voor opnieuw proberen gebruikt

Wanneer vooraf toegewezen tijdelijke poorten die voor PAT worden gebruikt, uitgeput raken of toepassingsfouten optreden, leiden agressieve of brute force-pogingen zonder verval- en uitstellogica tot uitputting of persistentie. U kunt de vraag naar tijdelijke poorten verminderen door een minder agressieve logica voor opnieuw proberen te gebruiken.

Tijdelijke poorten hebben een time-out van 4 minuten voor inactiviteit (niet instelbaar). Als de nieuwe pogingen te agressief zijn, heeft de uitputting geen kans om vanzelf op te ruimen. Daarom is het overwegen van hoe en hoe vaak uw toepassing transacties opnieuw probeert, een essentieel onderdeel van het ontwerp.

Een openbaar IP-adres op exemplaarniveau toewijzen aan elke VM

Als u een ILPIP toewijst, wordt uw scenario gewijzigd in Openbaar IP-adres op exemplaarniveau naar een VM. Alle tijdelijke poorten van het openbare IP-adres die voor elke VM worden gebruikt, zijn beschikbaar voor de VM. (In tegenstelling tot scenario's waarin tijdelijke poorten van een openbaar IP-adres worden gedeeld met alle VM's die zijn gekoppeld aan de respectieve implementatie.) Er zijn compromissen om rekening mee te houden, zoals de mogelijke impact van het toestaan van een groot aantal afzonderlijke IP-adressen.

Notitie

Deze optie is niet beschikbaar voor webwerkrollen.

Keep-alives gebruiken om de time-out voor uitgaande inactiviteit opnieuw in te stellen

Uitgaande verbindingen hebben een time-out van 4 minuten voor inactiviteit. Deze time-out is niet aanpasbaar. U kunt echter transport (bijvoorbeeld TCP-keepalives) of toepassingslaag-keepalives gebruiken om een niet-actieve stroom te vernieuwen en deze time-out voor inactiviteit zo nodig opnieuw in te stellen. Neem contact op met de leverancier van verpakte software of dit wordt ondersteund of hoe u deze kunt inschakelen. Over het algemeen hoeft slechts één kant keepalives te genereren om de time-out voor inactiviteit opnieuw in te stellen.

Het openbare IP-adres detecteren dat door een VM wordt gebruikt

Er zijn veel manieren om het openbare bron-IP-adres van een uitgaande verbinding te bepalen. OpenDNS biedt een service waarmee u het openbare IP-adres van uw VM kunt weergeven.

Met behulp van de opdracht nslookup kunt u een DNS-query voor de naam myip.opendns.com verzenden naar de OpenDNS-resolver. De service retourneert het bron-IP-adres dat is gebruikt om de query te verzenden. Wanneer u de volgende query uitvoert vanaf uw VM, is het antwoord het openbare IP-adres dat voor die VM wordt gebruikt:

nslookup myip.opendns.com resolver1.opendns.com

Volgende stappen

  • Meer informatie over Load Balancer die worden gebruikt in Resource Manager-implementaties.
  • Meer informatie over de modus voor uitgaande verbindingen die beschikbaar zijn in Resource Manager-implementaties.