Planera för IP-adressering

  • Artikel

Det är viktigt att din organisation planerar IP-adressering i Azure. Planering säkerställer att IP-adressutrymmet inte överlappar varandra på lokala platser och Azure-regioner.

Designöverväganden:

  • Överlappande IP-adressutrymmen i lokala regioner och Azure-regioner skapar stora konkurrensutmaningar.

  • Azure VPN Gateway kan ansluta överlappande, lokala platser med överlappande IP-adressutrymmen via nat-funktionen (network address translation). Den här funktionen är allmänt tillgänglig i Azure Virtual WAN och fristående Azure VPN Gateway.

    {Diagram som visar hur NAT fungerar med VPN Gateway.}

  • Du kan lägga till adressutrymme när du har skapat ett virtuellt nätverk. Den här processen behöver inget avbrott om det virtuella nätverket redan är anslutet till ett annat virtuellt nätverk via peering för virtuella nätverk. I stället behöver varje fjärrpeering en omsynkroniseringsåtgärd som utförs när nätverksutrymmet har ändrats.

  • Azure reserverar fem IP-adresser i varje undernät. Ta hänsyn till dessa adresser när du ändrar storlek på virtuella nätverk och omfattar undernät.

  • Vissa Azure-tjänster kräver dedikerade undernät. Dessa tjänster omfattar Azure Firewall och Azure VPN Gateway.

  • Du kan delegera undernät till vissa tjänster för att skapa instanser av en tjänst i undernätet.

Designrekommendationer:

  • Planera för ip-adressutrymmen som inte överlappar varandra i Azure-regioner och lokala platser i förväg.

  • Använd IP-adresser från adressallokeringen för privat Internet, så kallade RFC 1918-adresser.

  • Använd inte följande adressintervall:

    • 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)

  • Överväg att använda IPv6 för miljöer med begränsad tillgänglighet för privata IP-adresser. Virtuella nätverk kan vara IPv4-only eller IPv4+IPv6 med dubbla staplar.

    Diagram som visar dubbel stack i IPv4 och IPv6.

  • Skapa inte stora virtuella nätverk som /16. Det säkerställer att IP-adressutrymmet inte slösas bort. Det minsta IPv4-undernät som stöds är /29, och det största är /2 när du använder CIDR-undernätsdefinitioner (classless inter-domain routing). IPv6-undernät måste vara exakt /64 i storlek.

  • Skapa inte virtuella nätverk utan att planera det nödvändiga adressutrymmet i förväg.

  • Använd inte offentliga IP-adresser för virtuella nätverk, särskilt om de offentliga IP-adresserna inte tillhör din organisation.

  • Ta hänsyn till de tjänster som du ska använda, det finns vissa tjänster med reserverade IP-adresser (IP-adresser), till exempel AKS med CNI-nätverk

  • Använd icke-utfällbara virtuella nätverk för landningszoner och Azure Private Link-tjänsten för att förhindra IPv4-överbelastning.

Överväganden för IPv6

Allt fler organisationer använder IPv6 i sina miljöer. Den här implementeringen drivs av den offentliga IPv4-utrymmesöverbelastningen, den privata IPv4-bristen, särskilt i storskaliga nätverk, och behovet av att tillhandahålla anslutning till klienter med endast IPv6. Det finns ingen universell metod för att införa IPv6. Det finns dock metodtips som du kan följa när du planerar för IPv6 och implementerar det i dina befintliga Azure-nätverk.

Microsoft Cloud Adoption Framework för Azure hjälper dig att förstå vad du bör tänka på när du skapar system i molnet. Mer information om metodtips för arkitektur för att utforma hållbara system finns i Designprinciper för Azure-landningszoner. Detaljerade rekommendationer och metodtips för din molnarkitektur, inklusive distributioner av referensarkitektur, diagram och guider, finns i Arkitekturcenter-guiden för IPv6.

Designöverväganden:

  • Fasa din IPv6-implementering. Baserat på dina affärsbehov implementerar du IPv6 där det behövs. Kom ihåg att IPv4 och IPv6 kan samexistera så länge som det behövs.

  • I scenarier där program förlitar sig på IaaS-tjänster (infrastruktur som en tjänst) som har fullständigt IPv6-stöd, till exempel virtuella datorer (VM), är intern användning från slutpunkt till slutpunkt av IPv4 och IPv6 möjlig. Den här konfigurationen undviker översättningskomplikationer och ger mest information till servern och programmet.

    Du kan distribuera Internetuppkopplade Azure-lastbalanserare med Basic-SKU med en IPv6-adress. Den här konfigurationen möjliggör intern IPv6-anslutning från slutpunkt till slutpunkt mellan offentliga internet och virtuella Azure-datorer via lastbalanseraren. Den här metoden underlättar också interna utgående anslutningar från slutpunkt till slutpunkt mellan virtuella datorer och IPv6-aktiverade klienter på det offentliga Internet. Observera att den här metoden kräver varje enhet i sökvägen för att hantera IPv6-trafik.

    Den interna metoden från slutpunkt till slutpunkt är mest användbar för direkt kommunikation från server till server eller från klient till server. Det är inte användbart för de flesta webbtjänster och program, som vanligtvis skyddas av brandväggar, brandväggar för webbprogram eller omvända proxyservrar.

  • Vissa komplexa distributioner och program som använder en kombination av tjänster från tredje part, PaaS-tjänster (plattform som en tjänst) och serverdelslösningar kanske inte stöder intern IPv6. I dessa fall måste du använda NAT/NAT64 eller en IPv6-proxylösning för att aktivera kommunikation mellan IPv6 och IPv4.

  • När komplexiteten i programarkitekturen eller andra faktorer som träningskostnader anses vara betydande, kanske du vill fortsätta att använda IPv4-infrastruktur på serverdelen och distribuera en virtuell nätverksinstallation från tredje part (NVA) dubbelstackad IPv4/IPv6-gateway för tjänstleverans.

    En typisk distribution som använder en NVA kan se ut så här:

    Diagram som visar en IPv4/IPv6-gateway med dubbla staplar som ger åtkomst till en IPv4-serverdel.

Designrekommendationer:

Här är en närmare titt på hur en typisk arkitektur kan se ut:

Diagram som visar en IPv4/IPv6-lastbalanserare som ger åtkomst till en endast IPv4-serverdel.

  • Distribuera NVA i vm-skalningsuppsättningar med flexibel orkestrering (VMSS Flex) för återhämtning och exponera dem för Internet via Azure Load-Balancer, som har en offentlig IP-adressklientdel.

    NVA:erna accepterar IPv4- och IPv6-trafik och översätter den till endast IPv4-trafik för att få åtkomst till programmet i programmets undernät. Metoden minskar komplexiteten för programteamet och minskar attackytan.

  • Distribuera Azure Front Door för att tillhandahålla global routning för webbtrafik.

    Azure Front Door-funktionerna omfattar proxykörning av IPv6-klientbegäranden och trafik till en IPv4-serverdel, som du ser här:

    Diagram som visar Azure Front Door som ger åtkomst till en IPv4-serverdel.

Det här är de största skillnaderna mellan NVA-metoden och Azure Front Door-metoden:

  • NVA:er är kundhanterade, fungerar på Layer 4 i OSI-modellen och kan distribueras i samma virtuella Azure-nätverk som programmet med ett privat och offentligt gränssnitt.
  • Azure Front Door är en global Azure PaaS-tjänst och fungerar på Layer 7 (HTTP/HTTPS). Programmets serverdel är en internetuppkopplad tjänst som kan låsas för att endast acceptera trafik från Azure Front Door.

I komplexa miljöer kan du använda en kombination av båda. NVA:er används i en regional distribution. Azure Front Door används för att dirigera trafik till en eller flera regionala distributioner i olika Azure-regioner eller andra Internetuppkopplade platser. För att fastställa den bästa lösningen rekommenderar vi att du granskar funktionerna i Azure Front Door och produktdokumentationen.

CIDR-block för virtuella IPv6-nätverk:

  • Du kan associera ett enda IPv6 CIDR-block (Classless Inter-Domain Routing) när du skapar ett nytt virtuellt nätverk i en befintlig Azure-distribution i din prenumeration. Storleken på undernätet för IPv6 måste vara /64. Om du använder den här storleken säkerställs framtida kompatibilitet om du bestämmer dig för att aktivera routning av undernätet till ett lokalt nätverk. Vissa routrar kan bara acceptera /64 IPv6-vägar.
  • Om du har ett befintligt virtuellt nätverk som endast stöder IPv4 och resurser i ditt undernät som är konfigurerade att endast använda IPv4, kan du aktivera IPv6-stöd för ditt virtuella nätverk och dina resurser. Ditt virtuella nätverk kan fungera i läget med dubbla staplar, vilket gör att dina resurser kan kommunicera via IPv4, IPv6 eller båda. IPv4- och IPv6-kommunikation är oberoende av varandra.
  • Du kan inte inaktivera IPv4-stöd för ditt virtuella nätverk och undernät. IPv4 är standard-IP-adresssystemet för virtuella Azure-nätverk.
  • Associera ett IPv6 CIDR-block med ditt virtuella nätverk och undernät eller BYOIP IPv6. CIDR-notation är en metod för att representera en IP-adress och dess nätverksmask. Formaten för dessa adresser är följande:
    • En enskild IPv4-adress är 32 bitar, med fyra grupper med så många som tre decimaler. Exempel: 10.0.1.0
    • Ett IPv4 CIDR-block har fyra grupper med så många som tre decimaler, från 0 till 255, avgränsade med perioder och följt av ett snedstreck och ett tal från 0 till 32. Exempel: 10.0.0.0/16
    • En enskild IPv6-adress är 128 bitar. Den har åtta grupper med fyra hexadecimala siffror. Exempel: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
    • Ett IPv6 CIDR-block har fyra grupper med så många som fyra hexadecimala siffror, avgränsade med kolon, följt av ett dubbelt kolon och sedan ett snedstreck och ett tal från 1 till 128. Exempel: 2001:db8:1234:1a00::/64
  • Uppdatera routningstabellerna för att dirigera IPv6-trafik. För offentlig trafik skapar du en väg som dirigerar all IPv6-trafik från undernätet till VPN Gateway eller en Azure ExpressRoute-gateway.
  • Uppdatera säkerhetsgruppens regler så att de innehåller regler för IPv6-adresser. På så sätt kan IPv6-trafik flöda till och från dina instanser. Om du har regler för nätverkssäkerhetsgrupp för att styra trafikflödet till och från undernätet måste du inkludera regler för IPv6-trafik.
  • Om din instanstyp inte stöder IPv6 använder du dubbel stack eller distribuerar en NVA, som tidigare beskrivits, som översätts från IPv4 till IPv6.

IPAM-verktyg (IP Address Management)

Att använda ett IPAM-verktyg kan hjälpa dig med IP-adressplanering i Azure eftersom det ger centraliserad hantering och synlighet, vilket förhindrar överlappningar och konflikter i IP-adressutrymmen. Det här avsnittet vägleder dig genom viktiga överväganden och rekommendationer när du använder ett IPAM-verktyg.

Designöverväganden:

Många IPAM-verktyg är tillgängliga för dig, beroende på dina krav och organisationens storlek. Alternativen sträcker sig från att ha en grundläggande Excel-baserad inventering till communitydriven lösning med öppen källkod eller omfattande företagsprodukter med avancerade funktioner och support.

  • Tänk på dessa faktorer när du utvärderar vilket IPAM-verktyg som ska implementeras:

    • Minsta antal funktioner som krävs av din organisation
    • Total ägandekostnad (TCO), inklusive licensiering och löpande underhåll
    • Granskningsspår, loggning och rollbaserade åtkomstkontroller
    • Autentisering och auktorisering via Microsoft Entra-ID
    • Tillgänglig via API
    • Integreringar med andra verktyg och system för nätverkshantering
    • Aktivt communitystöd eller supportnivå från programvaruleverantören

  • Överväg att utvärdera ett IPAM-verktyg med öppen källkod som Azure IPAM. Azure IPAM är en enkel lösning som bygger på Azure-plattformen. Den identifierar automatiskt IP-adressanvändningen i din Azure-klientorganisation och gör att du kan hantera allt från ett centraliserat användargränssnitt eller via ett RESTful-API.

  • Överväg organisationens driftsmodell och ägarskapet för IPAM-verktyget. Målet med att implementera ett IPAM-verktyg är att effektivisera processen med att begära nya IP-adressutrymmen för programteam utan beroenden och flaskhalsar.

  • En viktig del av IPAM-verktygsfunktionen är att inventera IP-adressutrymmesanvändningen och organisera den logiskt.

Designrekommendationer:

  • Processen för att reservera icke-överlappande IP-adressutrymmen bör ha stöd för att begära olika storlekar baserat på behoven hos de enskilda programlandningszonerna.

    • Du kan till exempel använda T-shirtstorlek för att göra det enkelt för programteam att beskriva sina behov:
      • Liten – /24 – 256 IP-adresser
      • Medel – /22 1 024 IP-adresser
      • Stora – /20 – 4 096 IP-adresser

  • Ditt IPAM-verktyg bör ha ett API för att reservera icke-överlappande IP-adressutrymmen för att stödja en IaC-metod (Infrastruktur som kod). Den här funktionen är också avgörande för sömlös integrering av IPAM i din prenumerationsförsäljning process, vilket minskar risken för fel och behovet av manuella åtgärder.

    • Ett exempel på en IaC-metod är Bicep med dess funktioner för distributionsskript eller Terraform-datakällor för att dynamiskt hämta data från IPAM-API:et.

  • Skapa ett systematiskt arrangemang för dina IP-adressutrymmen genom att strukturera dem enligt Azure-regioner och arketyper för arbetsbelastningar, vilket säkerställer en ren och spårbar nätverksinventering.

  • Avvecklingsprocessen för arbetsbelastningar bör omfatta borttagning av IP-adressutrymmen som inte längre används, som senare kan återanvändas för kommande nya arbetsbelastningar, vilket främjar effektiv resursanvändning.