Den här artikeln innehåller metodtips för en Azure NAT-gateway. Vägledningen baseras på de fem grundpelarna för arkitekturens utmärkthet: Kostnadsoptimering, driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.
Vi antar att du har en fungerande kunskap om Azure NAT Gateway och att du är väl insatt i respektive funktioner. Som uppdatering läser du den fullständiga uppsättningen azure NAT Gateway-dokumentation.
NAT står för översättning av nätverksadresser. Se En introduktion till översättning av nätverksadresser.
Kostnadsoptimering
Åtkomst till PaaS-tjänster bör ske via Azure Private Link eller tjänstslutpunkter (inklusive lagring) för att undvika att använda en NAT-gateway. Private Link- och tjänstslutpunkter kräver inte bläddering av NAT-gatewayen för åtkomst till PaaS-tjänster. Den här metoden minskar kostnaden per GB data som bearbetas när du jämför kostnaderna för en NAT-gateway med Private Link eller till tjänstslutpunkter. Det finns ytterligare säkerhetsfördelar med att använda Private Link eller tjänstslutpunkter.
Prestandaeffektivitet
Varje NAT-gatewayresurs ger upp till 50 Gbit/s dataflöde. Du kan dela upp dina distributioner i flera undernät och sedan kan du tilldela varje undernät eller grupper av undernät en NAT-gateway för att skala ut.
Varje offentlig IP-adress för NAT-gateway tillhandahåller 64 512 SNAT-portar. Upp till 16 IP-adresser kan tilldelas till en NAT-gateway. IP-adresserna kan vara enskilda offentliga STANDARD-IP-adresser, det offentliga IP-prefixet eller båda. För anslutningar som går till samma målslutpunkt kan NAT-gatewayen stödja upp till 50 000 samtidiga flöden för TCP respektive UDP per tilldelad utgående IP-adress. Mer information finns i följande avsnitt om SNAT (Source Network Address Translation). TCP står för Transmission Control Protocol och UDP står för User Datagram Protocol.
SNAT-uttömning
- NAT-gatewayresurser har en standardtidsgräns för TCP-inaktivitet på 4 minuter som kan konfigureras upp till 120 minuter. Om den här inställningen ändras till ett högre värde än standardinställningen kommer NAT-gatewayen att hålla fast vid flöden längre och kan orsaka onödigt tryck på SNAT-portinventeringen.
- Atomiska begäranden (en begäran per anslutning) är ett dåligt designval eftersom det begränsar skalning, minskar prestanda och minskar tillförlitligheten. Återanvänd i stället HTTP/S-anslutningar för att minska antalet anslutningar och associerade SNAT-portar. Anslut återanvändning gör att programmet kan skalas bättre. Programmets prestanda förbättras på grund av minskade kostnader för handskakningar, omkostnader och kryptografiska åtgärder vid användning av TLS.
- DNS-sökningar (Domain Name System) kan introducera många enskilda flöden på volymen, när klienten inte cachelagrar RESULTATET för DNS-matcharna. Använd DNS-cachelagring för att minska mängden flöden och minska antalet SNAT-portar. DNS är det namngivningssystem som mappar domännamn till IP-adresser för resurser som är anslutna till Internet eller till ett privat nätverk.
- UDP-flöden, till exempel DNS-sökningar, använder SNAT-portar under tidsgränsen för inaktivitet. Tidsgränsen för udp-inaktiviteten är fast vid 4 minuter och kan inte ändras.
- Använd anslutningspooler för att forma anslutningsvolymen.
- Överge aldrig tyst ett TCP-flöde och förlita dig på TCP-timers för att rensa flödet. Om du inte tillåter att TCP uttryckligen stänger anslutningen förblir TCP-anslutningen öppen. Mellanliggande system och slutpunkter håller anslutningen i bruk, vilket i sin tur gör SNAT-porten otillgänglig för andra anslutningar. Det här antimönstret kan utlösa programfel och SNAT-överbelastning.
- Ändra inte TCP-close-relaterade timervärden på OS-nivå utan expertkunskap om konsekvenserna. TCP-stacken återställs, men programmets prestanda kan påverkas negativt när slutpunkterna för en anslutning har felmatchade förväntningar. Att ändra tidsinställda värden är vanligtvis ett tecken på ett underliggande designproblem. Om det underliggande programmet har andra antimönster kan SNAT-överbelastning också förstärkas om timervärdena ändras.
Läs följande vägledning för att förbättra tjänstens skala och tillförlitlighet:
- Utforska effekten av att minska TCP-tidsgränsen för inaktivitet till lägre värden. En standardtimeout för inaktivitet på 4 minuter kan frigöra SNAT-portinventering tidigare.
- Överväg asynkrona avsökningsmönster för långvariga åtgärder för att frigöra anslutningsresurser för andra åtgärder.
- Långlivade flöden, till exempel återanvända TCP-anslutningar, bör använda TCP keepalives eller keepalives på programnivå för att undvika tidsgränsen för mellanliggande system. Du bör bara öka tidsgränsen för inaktivitet som en sista utväg och det kanske inte löser rotorsaken. En lång timeout kan orsaka fel med låg hastighet, när tidsgränsen upphör att gälla och det kan medföra en fördröjning och onödiga fel. TCP keepalives kan aktiveras från ena sidan av anslutningen för att hålla en anslutning vid liv från båda sidor.
- För långvariga flöden med UDP-trafik kan du aktivera UDP keepalives för att hålla anslutningarna vid liv. Tänk på att UDP keepalives aktiverade på ena sidan av anslutningen endast håller anslutningen aktiv från en sida. UDP keepalives måste vara aktiverat på båda sidor av en anslutning för att hålla en anslutning vid liv.
- Graciösa återförsöksmönster bör användas för att undvika aggressiva återförsök/bursts vid tillfälligt fel eller återställning av fel. Ett antimönster, som kallas atomiska anslutningar, är när du skapar en ny TCP-anslutning för varje HTTP-åtgärd. Atomiska anslutningar förhindrar att programmet skalar bra och slösar resurser. Rör alltid flera åtgärder till samma anslutning. Ditt program kommer att gynnas av transaktionshastighet och resurskostnader. När ditt program använder kryptering på transportnivå (till exempel TLS) finns det en betydande kostnad i samband med bearbetningen av nya anslutningar. Mer metodtips finns i Designmönster för Azure Cloud.
Driftsäkerhet
Även om NAT-gateway kan användas med Azure Kubernetes Service (AKS) hanteras den inte som en del av AKS. Om du tilldelar en NAT-gateway till CNI-undernätet (Container Networking Interface) gör du det möjligt för AKS-poddar att ta sig ut via NAT-gatewayen.
När du använder flera NAT-gatewayer mellan zoner eller mellan regioner ska du hålla den utgående IP-egendomen hanterbar med hjälp av Azures offentliga IP-prefix eller BYOIP-prefix. En IP-prefixstorlek som är större än 16 IP-adresser (/28 prefixstorlek) kan inte tilldelas till NAT-gatewayen.
Använd Azure Monitor-aviseringar för att övervaka och avisera om SNAT-portanvändning, paket som bearbetas eller tas bort och mängden data som överförs. Använd NSG-flödesloggar för att övervaka utgående trafikflöde från virtuella datorinstanser i en NAT-gateway konfigurerat undernät.
När ett undernät har konfigurerats med en NAT-gateway ersätter NAT-gatewayen alla andra utgående anslutningar till det offentliga Internet för alla virtuella datorer i undernätet. NAT-gatewayen har företräde framför en lastbalanserare med eller utan regler för utgående trafik och över offentliga IP-adresser som tilldelats direkt till virtuella datorer. Azure spårar flödets riktning och asymmetrisk routning sker inte. Inkommande trafik kommer att översättas korrekt, till exempel en ip-adress för lastbalanserarens klientdel, och den översätts separat från utgående trafik via en NAT-gateway. Den här separationen gör att inkommande och utgående tjänster kan samexistera sömlöst.
NAT-gateway rekommenderas som standard för att aktivera utgående anslutning för virtuella nätverk. NAT-gatewayen är mer effektiv och mindre driftskomplex än andra utgående anslutningstekniker i Azure. NAT-gatewayer allokerar SNAT-portar på begäran och använder en effektivare algoritm för att förhindra konflikter vid återanvändning av SNAT-portar. Förlita dig inte på standardanslutningar för utgående trafik (ett antimönster) för din egendom. Definiera den i stället uttryckligen med NAT-gatewayresurser.
Tillförlitlighet
NAT-gatewayresurser är mycket tillgängliga i en tillgänglighetszon och omfattar flera feldomäner. NAT-gatewayen kan distribueras till "ingen zon" där Azure automatiskt väljer en zon för att placera NAT-gateway. NAT-gateway kan också isoleras till en specifik zon av en användare.
Det går inte att tillhandahålla isolering av tillgänglighetszoner, såvida inte varje undernät bara har resurser inom en viss zon. Distribuera i stället ett undernät för var och en av tillgänglighetszonerna där virtuella datorer distribueras, justera de zonindelade virtuella datorerna med matchande zonindelade NAT-gatewayer och skapa separata zonstackar. Till exempel finns en virtuell dator i tillgänglighetszon 1 i ett undernät med andra resurser som också bara finns i tillgänglighetszon 1. En NAT-gateway konfigureras i tillgänglighetszon 1 för att betjäna undernätet. Se följande diagram.
Virtuella nätverk och undernät omfattar alla tillgänglighetszoner i en region. Du behöver inte dela upp dem efter tillgänglighetszoner för att hantera zonindeliga resurser.
Säkerhet
Med NAT-gateway behöver enskilda virtuella datorer (eller andra beräkningsresurser) inte offentliga IP-adresser och kan förbli helt privata. Resurser utan en offentlig IP-adress kan fortfarande nå externa källor utanför det virtuella nätverket. Du kan associera ett offentligt IP-prefix för att säkerställa att en sammanhängande uppsättning IP-adresser används för utgående anslutning. Målbrandväggsregler kan konfigureras baserat på den här förutsägbara IP-listan.
En vanlig metod är att utforma ett scenario med utgående virtuell nätverksinstallation (NVA) med brandväggar från tredje part eller med proxyservrar. När en NAT-gateway distribueras till ett undernät med en VM-skalningsuppsättning med NVA:er använder dessa NVA:er NAT-gatewayadressen (es) för utgående anslutning, i motsats till IP-adressen för en lastbalanserare eller enskilda IP-adresser. Information om hur du använder det här scenariot med Azure Firewall finns i Integrera Azure Firewall med Azure Standard Load Balancer.
Microsoft Defender för molnet kan övervaka misstänkta utgående anslutningar via en NAT-gateway. Det här är en aviseringsfunktion i Microsoft Defender för molnet.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Ethan Haslett | Senior Cloud Solution Architect
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.