Förhindra IPv4-överbelastning i Azure

Den här artikeln beskriver hur du minimerar förbrukningen av privat adressutrymme när du skapar stora nätverk i Azure. Du kan behöva minimera förbrukningen av adressutrymme om rätt allokeringsprinciper inte upprättas och du får slut på privata IP-adresser som ska tilldelas till virtuella Azure-nätverk. I den här artikeln beskrivs två metoder för korrekt IP-adresshantering i Azure.

Information om scenario

Företagsnätverk använder vanligtvis adressutrymmen som finns i de privata IPv4-adressintervallen som definieras i RFC 1918. Adressintervallen är 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16. I lokala miljöer ger dessa intervall tillräckligt med IP-adresser för att uppfylla kraven för även de största nätverken. Därför utvecklar många organisationer metoder för adresshantering som prioriterar enkla routningskonfigurationer och agila processer för IP-allokering. Effektiv användning av adressutrymmet är inte en prioritet.

I molnet är stora hybridnätverk enkla att bygga, och vissa vanliga arkitekturmönster, till exempel mikrotjänster eller containerisering, kan leda till ökad IP-adressförbrukning. Därför är det viktigt att justera dessa metoder för adresshantering. I en molnmiljö behandlar du privata IPv4-adresser som en begränsad resurs.

IP-adressintervall för Azure Virtual Network

I dina virtuella Azure-nätverk rekommenderar vi att du använder adressblocken som definieras av RFC 1918. Dessa adressblock är för allmänna privata nätverk och kan inte användas på det offentliga Internet.

Du kan använda andra intervall, men innan du använder dessa intervall i ditt virtuella nätverk läser du dokumentationen om IANA (Internet Assigned Numbers Authority) för att förstå de potentiella konsekvenserna för din miljö. Du kan använda följande intervall:

• Delat adressutrymme som definieras av RFC 6598 för nätverksadressöversättning i transportföretagsklass (NAT) som behandlas som privat adressutrymme i Azure Virtual Network. Adressblocket är 100.64.0.0/10.
• Offentliga, internetrouterbara IP-adresser som din organisation inte äger. Den här metoden rekommenderas inte eftersom resurser i det virtuella nätverket inte kan komma åt Internetslutpunkter som exponeras via de offentliga IP-adresserna.
• Adressblock för särskilda ändamål som definieras av IANA, till exempel 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 och 233.252.0.0/24.

Du kan inte använda följande IP-adressintervall i virtuella Azure-nätverk:

• 224.0.0.0/4 (Multicast)
• 255.255.255.255/32 (sändning)
• 127.0.0.0/8 (Loopback)
• 169.254.0.0/16 (Länklokal)
• 168.63.129.16/32 (intern DNS)

Justering av Azure-landningszon

Rekommendationerna i den här artikeln gäller scenarier som baseras på Arkitekturen för Azure-landningszoner. Vägledningen förutsätter att:

• Varje region har en topologi med nav och eker.
• Hub-and-spoke-nätverk som finns i olika regioner är anslutna till varandra via global peering för virtuella nätverk eller anslutningar till samma Azure ExpressRoute-krets eller -kretsar.
• Hub-and-spoke-nätverk är anslutna till lokala platser via en kombination av ExpressRoute-kretsar och plats-till-plats-VPN.

Följande diagram visar en exempelarkitektur. Rekommendationerna gäller även för nätverk som bygger på Azure Virtual WAN, som också har nav- och ekernätverk i varje region.

Ladda ned en PowerPoint-fil med den här arkitekturen.

I ett scenario som baseras på Arkitekturen för Azure-landningszoner distribueras program i sin egen landningszon. Varje landningszon innehåller ett virtuellt ekernätverk som är peer-kopplat till en regional hubb. Virtuella ekernätverk är en integrerad del av företagsnätverket och tilldelas dirigerbara IPv4-adresser. Dessa adresser är unika i hela företagsnätverket. Därför förbrukar alla arkitekturkomponenter som distribueras i Azure Virtual Network IPv4-adresser i företagsnätverkets adressutrymme, även om bara några få komponenter exponerar slutpunkter som måste kunna nås från hela företagsnätverket. Dessa arkitektoniska komponenter kan vara virtuella datorer, virtuella nätverksinstallationer från första part eller virtuella nätverksinstallationer från tredje part (NVA) eller paaS-tjänster (virtual network-injected platform-as-a-service).

För resten av den här artikeln refererar klientdelskomponenten till en programkomponent som kan nås från hela företagsnätverket eller utanför komponentens landningszon. Backend-komponenten refererar till en programkomponent som inte exponerar slutpunkter i företagsnätverket och som bara behöver nås inifrån sin egen landningszon. Ett webbprogram som exponerar en slutpunkt är till exempel en klientdelskomponent, och en databas som inte exponerar en slutpunkt är en serverdelskomponent.

I följande avsnitt beskrivs två metoder för att minimera förbrukningen av privat adressutrymme när du skapar stora nätverk i Azure.

Metod 1: Icke-utfällbara virtuella nätverk för landningszoner

RFC 1918 skär IP-adressen blockerar från IPv4 32-bitars adressutrymmet och gör dem icke-utfällbara på det offentliga Internet, så att du kan återanvända dem i flera privata nätverk för intern kommunikation. Den här metoden baseras på samma princip som gäller för privat adressutrymme. Ett eller flera adressintervall är utskurna från hela det privata adressutrymme som används av din organisation och som inte kan nås i organisationens företagsnätverk. Adressintervallen återanvänds i flera landningszoner. Det innebär att varje landningszon:

• Tilldelas ett dirigerbart adressutrymme som består av ett eller flera adressintervall. Din organisation hanterar adressintervallen centralt och tilldelar dem unikt till en landningszon för kommunikation med företagsnätverket. Adresser i det dirigerbara utrymmet tilldelas till klientdelskomponenter.
• Kan använda det icke-utfällbara adressutrymmet, vilket är de adressintervall som din organisation deklarerar som icke-utfällbara i företagsnätverket. Du kan använda dessa reserverade intervall för intern kommunikation i alla landningszoner. Adresser i det icke-utfällbara utrymmet tilldelas till serverdelskomponenter.

I ett Azure Hub-and-spoke-nätverk som är kundhanterat eller baserat på Virtual WAN kan två eller flera virtuella ekernätverk inte ha överlappande IP-adressutrymmen. Icke-utfällbara adressblock kan inte tilldelas till en eker i landningszonen. Peering för virtuella nätverk är intetransitivt, så ett virtuellt nätverk i landningszonen kan peerkopplas med ett virtuellt ekernätverk på andra nivån som har ett icke-utfällbart adressutrymme. Följande diagram visar topologin för dubbla virtuella nätverk för landningszoner.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Varje programlandningszon innehåller två peer-kopplade virtuella nätverk. Ett virtuellt nätverk har dirigerbara IP-adresser och är värd för klientdelskomponenter. Det andra virtuella nätverket har icke-utfällbara IP-adresser och är värd för serverdelskomponenter. Den dirigerbara landningszonen ekrar med den regionala hubben. Den icke-utfällbara landningszonen ekrar med den dirigerbara landningszonen eker. Peering för virtuella nätverk är intetransitivt, så icke-utfällbara prefix är inte synliga för den regionala hubben eller resten av företagsnätverket. De routbara virtuella nätverken kan inte använda de icke-utgående adressintervallen. Vissa organisationer har fragmenterat adressutrymme som redan har tilldelats till dirigerbara nätverk. Det kan vara svårt att identifiera oanvända stora adressblock och deklarera dem som icke-utfällbara. I så fall bör du överväga oanvända adresser som inte ingår i RFC 1918-adressutrymmet. Det föregående diagrammet innehåller ett exempel på NAT-adresser i bärarklass, till exempel RFC 6598, i icke-utfällbara virtuella ekernätverk.

Migrering av landningszon för ett virtuellt nätverk

Peering för virtuella nätverk ger fullständig layer-3-anslutning mellan två peer-kopplade virtuella nätverk. Programkomponenter som distribueras i traditionella landningszoner för ett virtuellt nätverk som kommunicerar med varandra via IP kan flyttas fritt mellan routbara och icke-utfällbara virtuella ekernätverk i en landningszon. I det här avsnittet beskrivs två typiska migreringsmönster.

Följande program exponeras via layer-7-programleveranskontrollanter:

Ladda ned en PowerPoint-fil med den här arkitekturen.

Program som exponeras via layer-7-programleveranskontrollanter kan flyttas till den icke-utfällbara ekern. Programleveranskontrollanten är den enda klientdelskomponenten som måste finnas i den dirigerbara landningszonens eker.

Följande program exponeras via en Azure-lastbalanserare:

Ladda ned en PowerPoint-fil med den här arkitekturen.

Om ett program exponerar sina slutpunkter via en Azure-lastbalanserare måste beräkningsinstanserna som ingår i lastbalanserarens serverdelspool finnas kvar i samma virtuella nätverk. Azure-lastbalanserare stöder endast serverdelsinstanser i sitt eget virtuella nätverk.

Utgående beroenden

Ett programs serverdelskomponenter behöver inte vara nåbara eller ta emot inkommande anslutningar från företagsnätverket, men de har ofta utgående beroenden. Serverdelskomponenter kan behöva ansluta till slutpunkter som ligger utanför deras landningszoner i instanser som DNS-matchning, Usluge domena aktivnog direktorijuma domänkontrollanter, åtkomst till programslutpunkter som exponeras av andra landningszoner eller åtkomst till loggnings- eller säkerhetskopieringsanläggningar.

När tjänster initierar anslutningar i icke-utfällbara virtuella ekernätverk måste du implementera käll-NAT (SNAT) för anslutningar bakom en dirigerbar IP-adress. Om du vill implementera SNAT distribuerar du en NAT-kompatibel enhet i det routbara virtuella ekernätverket. Varje landningszon kör sin egen dedikerade NAT NVA. Det finns två alternativ för att implementera SNAT i en landningszon: Azure Firewall eller nva:er från tredje part. I båda fallen måste alla undernät i den icke-utfällbara ekern associeras med en anpassad routningstabell. Som du ser i följande diagram vidarebefordrar routningstabellen trafik till mål utanför landningszonen till SNAT-enheten. Azure NAT Gateway stöder inte SNAT för trafik som är avsedd för privat IP-adressutrymme, till exempel RFC 1918-utrymme.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Implementera SNAT via Azure Firewall

Azure Firewall:

• Ger hög tillgänglighet.
• Ger inbyggd skalbarhet och tre olika SKU:er. SNAT är inte en resursintensiv uppgift, så tänk på den grundläggande SKU:n först. Använd standard-SKU:n för landningszoner som kräver stora mängder utgående trafik från det icke-utgående adressutrymmet.
• Utför SNAT för trafik bakom de privata IP-adresserna för någon av dess instanser. Varje instans kan använda alla portar som inte är privilegierade.

Följande diagram visar layouten för landningszonen för att implementera SNAT i en nätverkstopologi med nav och eker med hjälp av Azure Firewall.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Du måste associera alla undernät i den icke-utfällbara ekern med en anpassad routningstabell för att skicka trafik till mål utanför landningszonen till Azure Firewall.

Följande diagram visar landningszonens layout för att implementera SNAT i ett Virtual WAN-baserat hub-and-spoke-nätverk med hjälp av Azure Firewall.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Du måste associera alla undernät i den icke-utfällbara ekern, eller ekrarna som inte är anslutna till Virtual WAN, med en anpassad routningstabell för att skicka trafik till mål utanför landningszonen till Azure Firewall.

För båda layouterna måste du distribuera Azure Firewall med alternativet Utför SNAT inställt på Alltid i varje landningszons dirigerbara eker för att tillhandahålla resurser i den icke-utfällbara ekeråtkomsten till dirigerbara IP-adresser utanför landningszonen. Du hittar instruktioner om hur du konfigurerar Azure Firewall för att implementera SNAT på alla mottagna anslutningar i offentlig dokumentation. Följande skärmbild visar den konfiguration som krävs för att använda Azure Firewall som en NAT-enhet för anslutningar som initieras av resurser i icke-utfällbara virtuella ekernätverk.

Implementera SNAT via nva från tredje part

Nva:er från tredje part med NAT-funktioner är tillgängliga på Azure Marketplace. De tillhandahåller:

• Detaljerad kontroll över in- och utskalning.
• Detaljerad kontroll över NAT-poolen.
• Anpassade NAT-principer, till exempel att använda olika NAT-adresser beroende på egenskaperna för den inkommande anslutningen, till exempel källans eller målets IP-adress.

Överväg följande rekommendationer:

• Distribuera kluster med minst två NVA:er för hög tillgänglighet. Använd en Azure-lastbalanserare för att distribuera inkommande anslutningar från det icke-utgående virtuella ekernätverket till NVA:erna. En regel för portbelastningsutjämning med hög tillgänglighet krävs eftersom klustret implementerar SNAT på alla anslutningar som lämnar landningszonen. Azure Standard Load Balancer stöder regler för portbelastningsutjämning med hög tillgänglighet.
• Azure SDN-stacken stöder nva:er med en arm och dubbla armar. Enarmade NVA:er föredras eftersom de minskar förbrukningen av adressutrymme i de routbara virtuella ekernätverken.

Följande diagram visar layouten för landningszonen för att implementera SNAT i en nätverkstopologi med nav och eker med hjälp av nva:er från tredje part.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Följande diagram visar layouten för landningszonen för att implementera SNAT i en Virtual WAN-baserad nätverkstopologi med nav och eker med hjälp av nva från tredje part.

Ladda ned en PowerPoint-fil med den här arkitekturen.

För båda NVA-layouterna från tredje part måste du distribuera flera instanser bakom en Azure-lastbalanserare för att ge hög tillgänglighet. Azure Load Balancer Standard SKU krävs.

Metod 2: Azure Private Link-tjänster

Private Link ger åtkomst till program som distribueras i ett virtuellt nätverk som inte är anslutet till ditt virtuella nätverk. I det virtuella nätverket på serversidan eller programmet distribueras en Private Link-tjänst och associeras med en programslutpunkt som exponeras på klientdelens IP-adress för en intern Azure Standard SKU-lastbalanserare. I det virtuella nätverket på klientsidan distribueras en privat slutpunktsresurs och associeras med Private Link-tjänsten. Den privata slutpunkten exponerar programslutpunkten i dina virtuella nätverk. Private Link tillhandahåller tunneltrafik och NAT-logik för att dirigera trafik mellan klientsidan och serversidan. Mer information finns i Vad är Azure Private Link?

Private Link kräver ingen layer-3-anslutning mellan det virtuella nätverket på klientsidan och det virtuella nätverket på serversidan. De två virtuella nätverken kan ha överlappande IP-adressutrymmen. Private Link tillåter distribution av program i dedikerade, isolerade virtuella nätverk, som alla använder samma icke-utfällbara adressutrymme. Programmen exponeras som Private Link-tjänster i företagsnätverket, som använder ett dirigerbart adressutrymme. I kontexten för Azure-landningszonens arkitektur har den resulterande topologin för landningszonen följande:

• Ett isolerat virtuellt nätverk som är värd för hela programmet och Private Link-tjänsten som är associerad med programmets slutpunkter. Programteamet definierar adressutrymmet för det virtuella nätverket.
• Ett virtuellt ekernätverk med ett dirigerbart adressutrymme som är värd för den privata slutpunkten som är associerad med Private Link-tjänsten. Det virtuella ekernätverket är direkt peer-kopplat till den regionala hubben.

Följande diagram visar topologin private link-aktiverad landningszon.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Använda en Private Link-tjänst för utgående beroenden

När du distribuerar program i isolerade virtuella ekernätverk använder du en Private Link-tjänst för utgående beroenden. Definiera privata slutpunkter i det isolerade virtuella ekernätverket och associera dem med en Private Link-tjänst i routbara virtuella nätverk. Följande diagram visar den konceptuella metoden.

Ladda ned en PowerPoint-fil med den här arkitekturen.

I verkliga storskaliga implementeringar kanske private link-metoden inte gäller:

• Om programmen som distribueras i det isolerade virtuella nätverket har flera utgående beroenden. När du distribuerar en Private Link-tjänst och en privat slutpunkt för vart och ett av de utgående beroendena ökar komplexiteten och hanteringsbehoven.
• Om det utgående beroendet innehåller slutpunkter i det routbara nätverket som inte kan ingå i en Azure Load Balancer-serverdelspool är Private Link inte tillämpligt.

Du kan lösa dessa två begränsningar genom att distribuera en proxy-/NAT-lösning i den dirigerbara ekern och göra den tillgänglig från det isolerade virtuella nätverket med hjälp av Private Link.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Använd en enskild privat slutpunkt eller Private Link-tjänst för att exponera en proxy-/NAT-lösning som distribueras i det dirigerbara nätverket. Regler för portöversättning och adressöversättning definieras på NVA:erna. Dessa regler tillåter användning av en enskild privat slutpunkt i det isolerade virtuella nätverket för att få åtkomst till flera beroenden i det dirigerbara nätverket.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Federico Guerrini | EMEA Technical Lead
• Khush Kaviraj | Molnlösningsarkitekt
• Jack Tracey | Senior Cloud Solution Architect

Övriga medarbetare:

• Jodi Martis | Teknisk författare

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Distribuera Azure Firewall i ett virtuellt nätverk
• Konfigurera SNAT i Azure Firewall
• IP-adresser som stöds i Azure Virtual Network
• Azure Private Link
• Azure Load Balancer
• Peering för virtuella nätverk

Relaterade resurser

• Design av nätverksarkitektur
• Arkitekturmetoder för nätverk i lösningar för flera klientorganisationer
• Nätverkstopologi för nav och eker