Dela via

Trafikdirigering i virtuella nätverk

  • Artikel

I den här artikeln får du lära dig hur Azure dirigerar trafik mellan Azure, lokala resurser och Internetresurser. Azure skapar automatiskt en routningstabell för varje undernät inom ett virtuellt Azure-nätverk och lägger till systemstandardvägar i tabellen. Läs mer om virtuella nätverk och undernät i Översikt över virtuella nätverk. Du kan åsidosätta några av Azure-systemvägarna med anpassade vägar och lägga till fler anpassade vägar i routningstabeller. Azure dirigerar trafik från ett undernät baserat på vägar i routningstabellen för ett undernät.

Systemvägar

Azure skapar automatiskt systemvägar och tilldelar vägarna till varje undernät i ett virtuellt nätverk. Du kan inte skapa systemvägar och du kan inte ta bort systemvägar, men du kan åsidosätta vissa systemvägar med anpassade vägar. Azure skapar standardsystemvägar för varje undernät och lägger till fler valfria standardvägar till specifika undernät, eller varje undernät, när du använder specifika Azure-funktioner.

Standardvärde

Varje väg innehåller ett adressprefix och en nästa hopp-typ. När trafik som lämnar ett undernät skickas till en IP-adress inom adressprefixet för en väg är den väg som innehåller prefixet den väg som Azure använder. Läs mer om hur Azure väljer en väg när flera vägar innehåller samma prefix eller överlappande prefix. När ett virtuellt nätverk skapas skapar Azure automatiskt följande standardsystemvägar för varje undernät inom det virtuella nätverket:

Källa Adressprefix Nästa hopptyp
Standardvärde Unikt för det virtuella nätverket Virtuellt nätverk
Standardvärde 0.0.0.0/0 Internet
Standardvärde 10.0.0.0/8 Ingen
Standardvärde 172.16.0.0/12 Ingen
Standardvärde 192.168.0.0/16 Ingen
Standardvärde 100.64.0.0/10 Ingen

Nästa hopptyper som anges i föregående tabell representerar hur Azure dirigerar trafik till det angivna adressprefixet. Här följer förklaringar till nästa hopptyper:

  • Virtuellt nätverk: Dirigerar trafik mellan adressintervall inom det virtuella nätverkets adressutrymme. Azure skapar en väg med ett adressprefix som motsvarar varje adressintervall som definierats inom adressutrymmet för ett virtuellt nätverk. Om det virtuella nätverkets adressutrymme har flera definierade adressintervall skapar Azure en enskild väg för varje adressintervall. Som standard dirigerar Azure trafik mellan undernät. Du behöver inte definiera routningstabeller eller gatewayer för Azure för att dirigera trafik mellan undernät. Azure skapar inte standardvägar för undernätsadressintervall. Varje adressintervall för undernätet ligger inom ett adressintervall för adressutrymmet för ett virtuellt nätverk.

  • Internet: Dirigerar trafik som anges av adressprefixet till Internet. Systemstandardvägen anger adressprefixet 0.0.0.0/0. Om du inte åsidosätter Azures standardvägar dirigerar Azure trafik för alla adresser som inte anges av ett adressintervall inom ett virtuellt nätverk till Internet. Det finns ett undantag till den här routningen. Om måladressen är för en Azure-tjänst dirigerar Azure trafiken direkt till tjänsten via Azure-stamnätverket i stället för att dirigera trafiken till Internet. Trafik mellan Azure-tjänster passerar inte internet. Det spelar ingen roll vilken Azure-region det virtuella nätverket finns i eller vilken Azure-region en instans av Azure-tjänsten distribueras i. Du kan åsidosätta Azures standardsystemväg för adressprefixet 0.0.0.0/0 med en anpassad väg.

  • Ingen: Trafik som dirigeras till typen Ingen nästa hopp släpps i stället för att dirigeras utanför undernätet. Azure skapar automatiskt standardvägar för följande adressprefix:

    • 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16: Reserverat för privat användning i RFC 1918.
    • 100.64.0.0/10: Reserverad i RFC 6598.

    Om du tilldelar några av de föregående adressintervallerna inom adressutrymmet för ett virtuellt nätverk ändrar Azure automatiskt nästa hopptyp för vägen från None (Ingen) till Virtuellt nätverk. Om du tilldelar ett adressintervall till ett virtuellt nätverks adressområde som inkluderar, men inte är detsamma som, något av de fyra reserverade adressprefixen, tar Azure bort prefixets väg och lägger till vägen för adressprefixet du la till, med Virtuellt nätverk som nästa hopptyp.

Valfria standardvägar

Azure lägger till fler standardsystemvägar för olika Azure-funktioner, men bara om du aktiverar funktionerna. Beroende på funktionen lägger Azure till valfria standardvägar till antingen specifika undernät i det virtuella nätverket eller till alla undernät i ett virtuellt nätverk. I följande tabell visas de andra systemvägarna och nästa hopptyper som Azure kan lägga till när du aktiverar olika funktioner.

Källa Adressprefix Nästa hopptyp Undernät för virtuellt nätverk som vägen har lagts till i
Standardvärde Unikt för det virtuella nätverket, till exempel 10.1.0.0/16 Virtuell nätverkspeering Alla
Virtuell nätverksgateway Prefix som annonseras lokalt via Border Gateway Protocol (BGP) eller konfigureras i den lokala nätverksgatewayen Virtuell nätverksgateway Alla
Standardvärde Flera VirtualNetworkServiceEndpoint Endast det undernät som en tjänstslutpunkt är aktiverad för

  • Peering för virtuella nätverk: När du skapar en peering för virtuella nätverk mellan två virtuella nätverk lägger systemet till en väg för varje adressintervall inom adressutrymmet för varje virtuellt nätverk som ingår i peering. Läs mer om virtuell nätverkspeering.

  • Virtuell nätverksgateway: En eller flera vägar med virtuell nätverksgateway angiven som nästa hopptyp läggs till när en virtuell nätverksgateway läggs till för ett virtuellt nätverk. Källan är också virtuell nätverksgateway eftersom gatewayen lägger till vägarna i undernätet. Om din lokala nätverksgateway utbyter BGP-vägar med en virtuell nätverksgateway lägger systemet till en väg för varje väg. Dessa vägar sprids från den lokala nätverksgatewayen. Vi rekommenderar att du sammanfattar lokala vägar till det största möjliga adressintervallet så att du sprider det minsta antalet vägar till en virtuell Azure-nätverksgateway. Det finns begränsningar för hur många vägar du kan sprida till en virtuell nätverksgateway i Azure. Mer information finns i Azure-gränser.

  • VirtualNetworkServiceEndpoint: Offentliga IP-adresser för vissa tjänster läggs till i routningstabellen av Azure när du aktiverar en tjänstslutpunkt för tjänsten. Tjänstslutpunkter är aktiverade för enskilda undernät i ett virtuellt nätverk, så vägen läggs bara till i routningstabellen för ett undernät som en tjänstslutpunkt är aktiverad för. Azure-tjänsters offentliga IP-adresser ändras regelbundet. Azure hanterar adresserna i routningstabellen automatiskt när adresserna ändras. Läs mer om tjänstslutpunkter för virtuella nätverk och de tjänster som du kan skapa tjänstslutpunkter för.

    Kommentar

    Peering för virtuellt nätverk och VirtualNetworkServiceEndpoint nästa hopp-typer läggs bara till i routningstabeller för undernät i virtuella nätverk som skapats via Azure Resource Manager-distributionsmodellen. Nästa hopptyper läggs inte till i routningstabeller som är associerade med virtuella nätverksundernät som skapats via den klassiska distributionsmodellen. Läs mer om distributionsmodeller i Azure.

Anpassade vägar

Du skapar anpassade vägar genom att antingen skapa användardefinierade vägar (UDR) eller utbyta BGP-vägar mellan din lokala nätverksgateway och en virtuell Azure-nätverksgateway.

Användardefinierad

Om du vill anpassa dina trafikvägar bör du inte ändra standardvägarna. Du bör skapa anpassade eller användardefinierade (statiska) vägar som åsidosätter Azures standardsystemvägar. I Azure skapar du en routningstabell och associerar sedan routningstabellen till noll eller fler virtuella nätverksundernät. Varje undernät kan ha noll eller en associerad routningstabell. Information om det maximala antalet vägar som du kan lägga till i en routningstabell och det maximala antalet UDR-tabeller som du kan skapa per Azure-prenumeration finns i Azure-gränser.

Som standard kan en routningstabell innehålla upp till 400 UDR. Med Azure Virtual Network Manager-routningskonfigurationen kan det här antalet utökas till 1 000 UDR per routningstabell. Den här ökade gränsen stöder mer avancerade routningskonfigurationer. Ett exempel är att dirigera trafik från lokala datacenter via en brandvägg till varje virtuellt ekernätverk i en topologi med nav och eker när du har ett högre antal virtuella ekernätverk.

När du skapar en routningstabell och kopplar den till ett undernät kombineras tabellens vägar med undernätets standardvägar. Om det finns vägtilldelningar i konflikt åsidosätter UDR standardvägarna.

Du kan ange följande nästa hopptyper när du skapar en UDR:

  • Virtuell installation: En virtuell installation är en virtuell dator som vanligtvis kör ett nätverksprogram som en brandvägg. Information om olika förkonfigurerade virtuella nätverksinstallationer som du kan distribuera i ett virtuellt nätverk finns i Azure Marketplace. När du skapar en väg med hopptypen Virtuell installation anger du även en IP-adress för nästa hopp. IP-adressen kan vara:

    • Ett nätverksgränssnitts privata IP-adress som är kopplad till en virtuell dator. Ett nätverksgränssnitt som är kopplat till en virtuell dator som vidarebefordrar nätverkstrafik till en annan adress än sin egen måste ha Azure-alternativet Enable IP forwarding (Aktivera IP-vidarebefordring) aktiverat. Inställningen inaktiverar kontrollen av källan och målet för ett nätverksgränssnitt av Azure. Läs mer om att aktivera IP-vidarekoppling för ett nätverksgränssnitt. Aktivera IP-vidarebefordran är en Azure-inställning.

      Du kan behöva aktivera IP-vidarebefordran i den virtuella datorns operativsystem för att enheten ska kunna vidarebefordra trafik mellan privata IP-adresser som tilldelats till Azure-nätverksgränssnitt. Om installationen behöver dirigera trafik till en offentlig IP-adress måste den antingen proxyservern trafik eller utföra nätverksadressöversättning (NAT) från källans privata IP-adress till sin egen privata IP-adress. Azure utför sedan NAT till en offentlig IP-adress innan trafiken skickas till Internet. Information om att fastställa nödvändiga inställningar på den virtuella datorn finns i dokumentationen för operativsystemet eller nätverksprogrammet. Läs mer om utgående anslutningar i Azure i Förstå utgående anslutningar.

      Kommentar

      Distribuera en virtuell installation till ett annat undernät än de resurser som dirigeras via den virtuella installationen. Att distribuera den virtuella installationen till samma undernät och sedan tillämpa en routningstabell på undernätet som dirigerar trafik genom den virtuella installationen kan resultera i routningsloopar där trafiken aldrig lämnar undernätet.

      En privat IP-adress för nästa hopp måste ha direktanslutning utan att behöva dirigeras via en Azure ExpressRoute-gateway eller via Azure Virtual WAN. Om du ställer in nästa hopp till en IP-adress utan direkt anslutning resulterar det i en ogiltig UDR-konfiguration.

    • Den privata IP-adressen till en intern lastbalanserare i Azure. En lastbalanserare används ofta som en del av en strategi för hög tillgänglighet för virtuella nätverksinstallationer.

    Du kan definiera en väg med 0.0.0.0/0 som adressprefix och en nästa hopp-typ av virtuell installation. Med den här konfigurationen kan enheten inspektera trafiken och avgöra om trafiken ska vidarebefordras eller släppas. Om du tänker skapa en UDR som innehåller adressprefixet 0.0.0.0/0 läser du först adressprefixet 0.0.0.0/0.

  • Virtuell nätverksgateway: Ange när du vill att trafik till specifika adressprefix dirigeras till en virtuell nätverksgateway. Den virtuella nätverksgatewayen måste skapas med typen VPN. Du kan inte ange en virtuell nätverksgateway som skapats som typen ExpressRoute i en UDR eftersom du med ExpressRoute måste använda BGP för anpassade vägar. Du kan inte ange virtuella nätverksgatewayer om du har virtuella privata nätverk (VPN) och ExpressRoute-samexisterande anslutningar heller. Du kan definiera en väg som dirigerar trafik som är avsedd för adressprefixet 0.0.0.0/0 till en vägbaserad virtuell nätverksgateway.

    Lokalt kan du ha en enhet som inspekterar trafiken och avgör om den ska vidarebefordras eller tas bort. Om du tänker skapa en UDR för adressprefixet 0.0.0.0/0 läser du först adressprefixet 0.0.0.0/0. I stället för att konfigurera en UDR för adressprefixet 0.0.0.0/0 kan du annonsera en väg med prefixet 0.0.0.0/0 via BGP om BGP för en virtuell VPN-nätverksgateway är aktiverad.

  • None (Ingen): Ange när du vill ta bort trafik till ett adressprefix, istället för att vidarebefordra trafiken till en destination. Azure kan visa Ingen för några av de valfria systemvägarna om en funktion inte har konfigurerats. Om du till exempel ser att Next hop IP-adressen visar Ingen och Nästa hopp-typen visar Virtuell nätverksgateway eller Virtuell installation kan det bero på att enheten inte körs eller inte är helt konfigurerad. Azure skapar systemstandardvägar för reserverade adressprefix med None (Ingen) som nästa hopptyp.

  • Virtuellt nätverk: Ange alternativet Virtuellt nätverk när du vill åsidosätta standardroutningen i ett virtuellt nätverk. Ett exempel på varför du kan skapa en väg med hopptypen Virtuellt nätverk finns i Routningsexempel.

  • Internet: Ange internetalternativet när du uttryckligen vill dirigera trafik som är avsedd för ett adressprefix till Internet. Du kan också använda den om du vill ha trafik som är avsedd för Azure-tjänster med offentliga IP-adresser i Azure-stamnätverket.

Du kan inte ange peering för virtuellt nätverk eller VirtualNetworkServiceEndpoint som nästa hopptyp i UDR: er. Azure skapar vägar med peering av virtuella nätverk eller VirtualNetworkServiceEndpoint nästa hopp-typer endast när du konfigurerar en peering för virtuellt nätverk eller en tjänstslutpunkt.

Tjänsttaggar för användardefinierade vägar

Nu kan du ange en tjänsttagg som adressprefix för en UDR i stället för ett explicit IP-intervall. En tjänsttagg representerar en grupp IP-adressprefix från en specifik Azure-tjänst. Microsoft hanterar adressprefixen som omfattas av tjänsttaggen och uppdaterar automatiskt tjänsttaggen när adresserna ändras. Det här stödet minimerar komplexiteten i frekventa uppdateringar av UDR och minskar antalet vägar som du behöver skapa. Du kan för närvarande skapa 25 eller färre vägar med tjänsttaggar i varje routningstabell. Med den här versionen stöds även användning av tjänsttaggar i routningsscenarier för containrar.

Exakt matchning

Systemet föredrar vägen med det explicita prefixet när det finns en exakt prefixmatchning mellan en väg med ett explicit IP-prefix och en väg med en tjänsttagg. När flera vägar med tjänsttaggar har matchande IP-prefix utvärderas vägar i följande ordning:

  1. Regionala taggar (till exempel Storage.EastUS eller AppService.AustraliaCentral)

  2. Taggar på toppnivå (till exempel Storage eller AppService)

  3. AzureCloud regionala taggar (till exempel AzureCloud.canadacentral eller AzureCloud.eastasia)

  4. Taggen AzureCloud

Om du vill använda den här funktionen anger du ett tjänsttaggnamn för adressprefixparametern i routningstabellkommandon. I PowerShell kan du till exempel skapa en ny väg för att dirigera trafik som skickas till ett AZURE Storage IP-prefix till en virtuell installation med hjälp av det här kommandot:

$param = @{
    Name = 'StorageRoute'
    AddressPrefix = 'Storage'
    NextHopType = 'VirtualAppliance'
    NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

Samma kommando för Azure CLI är:

az network route-table route create \
    --resource-group MyResourceGroup \
    --route-table-name MyRouteTable \
    --name StorageRoute \
    --address-prefix Storage \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

Nästa hopptyper i Azure-verktyg

Namnet som visas och refereras till för nästa hopptyper skiljer sig mellan Azure Portal- och kommandoradsverktygen och Resource Manager och klassiska distributionsmodeller. I följande tabell visas de namn som används för att referera till varje nästa hopptyp med de olika verktygen och distributionsmodellerna.

Nästa hopptyp Azure CLI och PowerShell (Resource Manager) Azures klassiska CLI och PowerShell (klassisk)
Virtuell nätverksgateway VirtualNetworkGateway VPNGateway
Virtuellt nätverk VNetLocal VNETLocal (inte tillgängligt i det klassiska CLI i klassiskt distributionsmodellläge)
Internet Internet Internet (inte tillgängligt i det klassiska CLI i klassiskt distributionsmodellläge)
Virtuell installation VirtualAppliance VirtualAppliance
Ingen Ingen Null (inte tillgängligt i det klassiska CLI i klassiskt distributionsmodellläge)
Virtuell nätverkspeering Virtuell nätverkspeering Inte tillämpligt
Tjänstslutpunkt för virtuellt nätverk VirtualNetworkServiceEndpoint Inte tillämpligt

Border Gateway Protocol

En lokal nätverksgateway kan utbyta vägar med en virtuell Azure-nätverksgateway med hjälp av BGP. Att använda BGP med en virtuell Azure-nätverksgateway är beroende av vilken typ du valde när du skapade gatewayen:

  • ExpressRoute: Du måste använda BGP för att annonsera lokala vägar till Microsoft Edge-routern. Du kan inte skapa UDR:er för att tvinga trafik till den virtuella ExpressRoute-nätverksgatewayen om du distribuerar en virtuell nätverksgateway som distribueras som typen ExpressRoute. Du kan använda UDR för att tvinga trafik från expressvägen till till exempel en virtuell nätverksinstallation.
  • VPN: Du kan också använda BGP. Mer information finns i BGP med PLATS-till-plats-VPN-anslutningar.

När du byter vägar med Azure med BGP läggs en separat väg till i routningstabellen för alla undernät i ett virtuellt nätverk för varje annonserat prefix. Vägen läggs till med Virtuell nätverksgateway angiven som källa och nästa hopptyp.

Du kan inaktivera spridning av ExpressRoute- och Azure VPN Gateway-routning i ett undernät med hjälp av en egenskap i en routningstabell. När du inaktiverar spridning av vägar lägger systemet inte till vägar i routningstabellen för undernät med inaktiverad spridning av vägar för virtuell nätverksgateway. Den här processen gäller både statiska vägar och BGP-vägar. Anslutning med VPN-anslutningar uppnås genom att använda anpassade vägar med en nästa hopp-typ av virtuell nätverksgateway. Mer information finns i Inaktivera spridning av routning för virtuell nätverksgateway.

Kommentar

Routningsspridning bör inte inaktiveras på GatewaySubnet. Gatewayen fungerar inte om den här inställningen är inaktiverad.

Hur Azure väljer en väg

När utgående trafik skickas från ett undernät väljer Azure en väg baserat på målets IP-adress med hjälp av den längsta prefixmatchningsalgoritmen. En routningstabell har till exempel två vägar. En väg anger adressprefixet 10.0.0.0/24 och den andra vägen anger adressprefixet 10.0.0.0/16.

Azure dirigerar trafik som är avsedd för 10.0.0.5 till nästa hopptyp som anges i vägen med adressprefixet 10.0.0.0/24. Den här processen beror på att 10.0.0.0/24 är ett längre prefix än 10.0.0.0/16, även om 10.0.0.5 ligger inom båda adressprefixen.

Azure dirigerar trafik som är avsedd för 10.0.1.5 till nästa hopptyp som anges i vägen med adressprefixet 10.0.0.0/16. Den här processen beror på att adressprefixet 10.0.1.5 inte ingår i adressprefixet 10.0.0.0/24, vilket gör vägen med adressprefixet 10.0.0.0/16 till det längsta matchande prefixet.

Om flera vägar innehåller samma adressprefix väljer Azure vägtypen baserat på följande prioritet:

  1. Användardefinierad väg

  2. BGP-väg

  3. Systemväg

Kommentar

Systemvägar för trafik som rör virtuella nätverk, peerings för virtuella nätverk eller tjänstslutpunkter för virtuella nätverk är prioriterade vägar. De är att föredra, även om BGP-vägar är mer specifika. Vägar med en tjänstslutpunkt för virtuellt nätverk som nästa hopptyp kan inte åsidosättas, även när du använder en routningstabell.

Till exempel innehåller en routningstabell följande vägar:

Källa Adressprefix Nästa hopptyp
Standardvärde 0.0.0.0/0 Internet
User 0.0.0.0/0 Virtuell nätverksgateway

När trafik är avsedd för en IP-adress utanför adressprefixen för andra vägar i routningstabellen väljer Azure vägen med användarkällan . Azure gör det här valet eftersom UDR:er har högre prioritet än systemets standardvägar.

En omfattande routningstabell med förklaringar av vägarna i tabellen finns i Routningsexempel.

0.0.0.0/0 adressprefix

En väg med adressprefixet 0.0.0.0/0 ger instruktioner till Azure. Azure använder dessa instruktioner för att dirigera trafik som är avsedd för en IP-adress som inte faller inom adressprefixet för någon annan väg i ett undernäts routningstabell. När ett undernät skapas, skapar Azure en standardväg till adressprefixet 0.0.0.0/0 med Internet som nästa hopptyp. Om du inte åsidosätter den här vägen dirigerar Azure all trafik till IP-adresser som inte ingår i adressprefixet för någon annan väg till Internet.

Undantaget är att trafik till de offentliga IP-adresserna för Azure-tjänster förblir i Azure-stamnätverket och inte dirigeras till Internet. När du åsidosätter den här vägen med en anpassad väg dirigeras trafik som är avsedd för adresser som inte ligger inom adressprefixen för någon annan väg i routningstabellen. Målet beror på om du anger en virtuell nätverksinstallation eller en virtuell nätverksgateway i den anpassade vägen.

När du åsidosätter adressprefixet 0.0.0.0/0 flödar utgående trafik från undernätet via den virtuella nätverksgatewayen eller den virtuella installationen. Följande ändringar sker också med Azures standardroutning:

  • Azure skickar all trafik till nästa hopptyp som anges i vägen, inklusive trafik till offentliga IP-adresser för Azure-tjänster.

    När nästa hopptyp för vägen med adressprefixet 0.0.0.0/0 är Internet, lämnar trafik från undernätet som är avsett för de offentliga IP-adresserna för Azure-tjänster aldrig Azure-stamnätverket, oavsett i vilken Azure-region det virtuella nätverket eller Azure-tjänstresursen finns.

    När du skapar en UDR eller en BGP-väg med en virtuell nätverksgateway eller virtuell installation nästa hopptyp skickas all trafik till nästa hopptyp som anges i vägen. Detta inkluderar trafik som skickas till offentliga IP-adresser för Azure-tjänster som du inte har aktiverat tjänstslutpunkter för.

    När du aktiverar en tjänstslutpunkt för en tjänst skapar Azure en väg med adressprefix för tjänsten. Trafik till tjänsten dirigeras inte till nästa hopptyp i en väg med adressprefixet 0.0.0.0/0. Adressprefixen för tjänsten är längre än 0.0.0.0/0.

  • Du kan inte längre komma åt resurser direkt i undernätet från Internet. Du kan komma åt resurser i undernätet indirekt från Internet. Enheten som anges av nästa hopptyp för en väg med adressprefixet 0.0.0.0/0 måste bearbeta inkommande trafik. När trafiken passerar enheten når trafiken resursen i det virtuella nätverket. Om vägen innehåller följande värden för nästa hopptyp:

    • Virtuell installation: Enheten måste:

      • Vara tillgänglig från Internet.
      • Ha en offentlig IP-adress tilldelad till den.
      • Det finns ingen associerad regel för nätverkssäkerhetsgrupp som förhindrar kommunikation till enheten.
      • Neka inte kommunikationen.
      • Kunna översätta och vidarebefordra nätverksadressen eller proxytrafik till målresursen i undernätet och returnera trafiken tillbaka till Internet.

    • Virtuell nätverksgateway: Om gatewayen är en virtuell ExpressRoute-nätverksgateway kan en internetansluten enhet lokalt ansluta till nätverksadressen översätta och vidarebefordra eller skicka trafik till målresursen i undernätet via expressroute-privat peering.

Om ditt virtuella nätverk är anslutet till en Azure VPN-gateway ska du inte associera en routningstabell till gatewayundernätet som innehåller en väg med målet 0.0.0.0/0. Om du gör det så förhindrar du gatewayen från att fungera korrekt. Mer information finns i Varför öppnas vissa portar på min VPN-gateway?.

Information om implementering när du använder virtuella nätverksgatewayer mellan Internet och Azure finns i DMZ mellan Azure och ditt lokala datacenter.

Exempel på dirigering

För att illustrera begreppen i den här artikeln beskriver följande avsnitt:

  • Ett scenario med krav.
  • De anpassade vägar som krävs för att uppfylla kraven.
  • Routningstabellen som finns för ett undernät som innehåller de standardvägar och anpassade vägar som krävs för att uppfylla kraven.

Kommentar

Det här exemplet är inte avsett att vara en rekommenderad implementering eller metodtips. Den tillhandahålls endast för att illustrera begrepp i den här artikeln.

Krav

  1. Implementera två virtuella nätverk i samma Azure-region och aktivera resurser för att kommunicera mellan virtuella nätverk.

  2. Aktivera ett lokalt nätverk för att kommunicera säkert med båda de virtuella nätverken via en VPN-tunnel via Internet. Du kan också använda en ExpressRoute-anslutning, men i det här exemplet används en VPN-anslutning.

  3. För ett undernät i ett virtuellt nätverk:

    • Dirigera all utgående trafik från undernätet via en virtuell nätverksinstallation för inspektion och loggning. Undanta trafik till Azure Storage och i undernätet från den här routningen.
    • Inspektera inte trafik mellan privata IP-adresser i undernätet. Tillåt att trafik flödar direkt mellan alla resurser.
    • Ta bort all utgående trafik som var avsedd för det virtuella nätverket.
    • Aktivera utgående trafik till Azure Storage för att flöda direkt till lagring, utan att tvinga den via en virtuell nätverksinstallation.

  4. Tillåt all trafik mellan alla andra undernät och virtuella nätverk.

Implementering

Följande diagram visar en implementering via Resource Manager-distributionsmodellen som uppfyller de tidigare kraven.

Diagram som visar en nätverksimplementering.

Pilarna visar trafikflödet.

Routningstabeller

Här är routningstabellerna för föregående routningsexempel.

Subnet1

Routningstabellen för Subnet1 i föregående diagram innehåller följande vägar:

ID Källa Tillstånd Adressprefix Nästa hopptyp Nästa hopp-IP-adress UDR-namn
1 Standardvärde Ogiltig 10.0.0.0/16 Virtuellt nätverk
2 User Aktiv 10.0.0.0/16 Virtuell installation 10.0.100.4 Inom-VNet1
3 User Aktiv 10.0.0.0/24 Virtuellt nätverk Inom-Subnet1
4 Standardvärde Ogiltig 10.1.0.0/16 Virtuell nätverkspeering
5 Standardvärde Ogiltig 10.2.0.0/16 Virtuell nätverkspeering
6 User Aktiv 10.1.0.0/16 Ingen ToVNet2-1-Drop
7 User Aktiv 10.2.0.0/16 Ingen ToVNet2-2-Drop
8 Standardvärde Ogiltig 10.10.0.0/16 Virtuell nätverksgateway [X.X.X.X]
9 User Aktiv 10.10.0.0/16 Virtuell installation 10.0.100.4 Till lokalt
10 Standardvärde Aktiv [X.X.X.X] VirtualNetworkServiceEndpoint
11 Standardvärde Ogiltig 0.0.0.0/0 Internet
12 User Aktiv 0.0.0.0/0 Virtuell installation 10.0.100.4 Standard-NVA

Här är en förklaring av varje väg-ID:

  • ID1: Azure lade automatiskt till den här vägen för alla undernät i Virtual-network-1 eftersom 10.0.0.0/16 är det enda adressintervall som definierats i adressutrymmet för det virtuella nätverket. Om du inte skapar UDR i väg-ID2 dirigeras trafik som skickas till någon adress mellan 10.0.0.1 och 10.0.255.254 i det virtuella nätverket. Den här processen beror på att prefixet är längre än 0.0.0.0/0 och inte faller inom adressprefixen för andra vägar.

    Azure ändrade automatiskt tillståndet från Aktiv till Ogiltig, när ID2, en UDR, lades till. Den har samma prefix som standardvägen och UDR åsidosätter standardvägar. Tillståndet för den här vägen är fortfarande Aktivt för undernät2 eftersom routningstabellen som UDR, ID2, finns i inte är associerad med Undernät2.

  • ID2: Azure lade till den här vägen när en UDR för adressprefixet 10.0.0.0/16 associerades till subnet1-undernätet i det virtuella nätverket Virtual-network-1 . UDR anger 10.0.100.4 som IP-adress för den virtuella installationen eftersom adressen är den privata IP-adress som tilldelats den virtuella datorn för den virtuella installationen. Routningstabellen där den här vägen finns är inte associerad med Undernät2, så vägen visas inte i routningstabellen för Undernät2.

    Den här vägen åsidosätter standardvägen för prefixet 10.0.0.0/16 (ID1), som automatiskt dirigerade trafik adresserad till 10.0.0.1 och 10.0.255.254 i det virtuella nätverket via det virtuella nätverkets nästa hopptyp. Den här vägen finns för att uppfylla krav 3, vilket är att tvinga all utgående trafik via en virtuell installation.

  • ID3: Azure lade till den här vägen när en UDR för adressprefixet 10.0.0.0/24 associerades till subnet1-undernätet . Trafik som är avsedd för adresser mellan 10.0.0.1 och 10.0.0.254 finns kvar i undernätet. Trafiken dirigeras inte till den virtuella installationen som angavs i föregående regel (ID2) eftersom den har ett längre prefix än ID2-vägen.

    Den här vägen var inte associerad med Undernät2, så vägen visas inte i routningstabellen för Undernät2. Den här vägen åsidosätter effektivt ID2-vägen för trafik i Subnet1. Den här vägen finns för att uppfylla krav 3.

  • ID4: Azure lade automatiskt till vägarna i ID:n 4 och 5 för alla undernät i Virtual-network-1 när det virtuella nätverket peerkopplades med Virtual-network-2. Virtual-network-2 har två adressintervall i sitt adressutrymme, 10.1.0.0/16 och 10.2.0.0/16, så Azure lade till en väg för varje intervall. Om du inte skapar UDR i routnings-ID:n 6 och 7 dirigeras trafik som skickas till någon adress mellan 10.1.0.1-10.1.255.254 och 10.2.0.1-10.2.255.254 till det peerkopplade virtuella nätverket. Den här processen beror på att prefixet är längre än 0.0.0.0/0 och inte faller inom adressprefixen för andra vägar.

    När du lade till vägarna i ID 6 och 7 ändrade Azure automatiskt tillståndet från Aktiv till Ogiltig. Den här processen beror på att de har samma prefix som vägarna i ID 4 och 5, och UDR åsidosätter standardvägar. Tillståndet för vägarna i ID:erna 4 och 5 är fortfarande aktiva för undernät2 eftersom routningstabellen där UDR:erna i ID 6 och 7 inte är associerade med Undernät2. En virtuell nätverkspeering har skapats för att uppfylla krav 1.

  • ID5: Samma förklaring som ID4.

  • ID6: Azure lade till den här vägen och vägen i ID7 när UDR:er för adressprefixen 10.1.0.0/16 och 10.2.0.0/16 var associerade till undernätet Subnet1 . Azure släpper trafik som är avsedd för adresser mellan 10.1.0.1-10.1.255.254 och 10.2.0.1-10.2.255.254, i stället för att dirigeras till det peerkopplade virtuella nätverket, eftersom UDR åsidosätter standardvägar. Vägarna är inte kopplade till Undernät2, så vägarna visas inte i routningstabellen för Undernät2. Vägarna åsidosätter vägarna ID4 och ID5 för trafik som lämnar Subnet1. Vägarna ID6 och ID7 finns för att uppfylla krav 3 för att ta bort trafik som är avsedd för det andra virtuella nätverket.

  • ID7: Samma förklaring som ID6.

  • ID8: Azure lade automatiskt till den här vägen för alla undernät i Virtual-network-1 när en virtuell nätverksgateway av VPN-typ skapades i det virtuella nätverket. Azure la till den offentliga IP-adressen till den virtuella nätverksgatewayen till routningstabellen. Trafik som skickas till alla adresser mellan 10.10.0.1 och 10.10.255.254 dirigeras till den virtuella nätverksgatewayen. Prefixet är längre än 0.0.0.0/0 och är inte inom adressprefixet för någon av de andra vägarna. En virtuell nätverksgateway har skapats för att uppfylla krav 2.

  • ID9: Azure lade till den här vägen när en UDR för adressprefixet 10.10.0.0/16 lades till i routningstabellen som är associerad med Subnet1. Den här vägen åsidosätter ID8. Vägen skickar all trafik som är avsedd för det lokala nätverket till en virtuell nätverksinstallation för inspektion, i stället för att dirigera trafik direkt lokalt. Den här vägen har skapats för att uppfylla krav 3.

  • ID10: Azure lade automatiskt till den här vägen i undernätet när en tjänstslutpunkt till en Azure-tjänst aktiverades för undernätet. Azure dirigerar trafik från undernätet till en offentlig IP-adress för tjänsten via nätverket i Azure-infrastrukturen. Prefixet är längre än 0.0.0.0/0 och är inte inom adressprefixet för någon av de andra vägarna. En tjänstslutpunkt skapades för att uppfylla krav 3 för att göra det möjligt för trafik som är avsedd för Azure Storage att flöda direkt till Azure Storage.

  • ID11: Azure lade automatiskt till den här vägen i routningstabellen för alla undernät i Virtual-network-1 och Virtual-network-2. Adressprefixet 0.0.0.0/0 är det kortaste prefixet. All trafik som skickas till adresser inom ett längre adressprefix dirigeras baserat på andra vägar.

    Som standard dirigerar Azure all trafik som är avsedd för andra adresser än de adresser som anges i någon av de andra vägarna till Internet. Azure ändrade automatiskt tillståndet från Aktiv till Ogiltigt för undernätet Undernät1 när en UDR för adressprefixet 0.0.0.0/0 (ID12) associerades till undernätet. Tillståndet för den här vägen är fortfarande Aktivt för alla andra undernät i båda de virtuella nätverken eftersom vägen inte är associerad med andra undernät i andra virtuella nätverk.

  • ID12: Azure lade till den här vägen när en UDR för adressprefixet 0.0.0.0/0 associerades till subnet1-undernätet . UDR anger 10.0.100.4 som IP-adress för den virtuella installationen. Den här vägen är inte associerad med Undernät2, så vägen visas inte i routningstabellen för Undernät2. All trafik för adresser som inte ingår i adressprefixen för någon av de andra vägarna skickas till den virtuella installationen.

    Tillägget av den här vägen ändrade tillståndet för standardvägen för adressprefixet 0.0.0.0/0 (ID11) från Aktiv till Ogiltig för undernät1 eftersom en UDR åsidosätter en standardväg. Den här vägen finns för att uppfylla krav 3.

Subnet2

Routningstabellen för Subnet2 i föregående diagram innehåller följande vägar:

Källa Tillstånd Adressprefix Nästa hopptyp Nästa hopp-IP-adress
Standardvärde Aktiv 10.0.0.0/16 Virtuellt nätverk
Standardvärde Aktiv 10.1.0.0/16 Virtuell nätverkspeering
Standardvärde Aktiv 10.2.0.0/16 Virtuell nätverkspeering
Standardvärde Aktiv 10.10.0.0/16 Virtuell nätverksgateway [X.X.X.X]
Standardvärde Aktiv 0.0.0.0/0 Internet
Standardvärde Aktiv 10.0.0.0/8 Ingen
Standardvärde Aktiv 100.64.0.0/10 Ingen
Standardvärde Aktiv 192.168.0.0/16 Ingen

Routningstabellen för Subnet2 innehåller alla Azure-skapade standardvägar och valfri peering för virtuella nätverk och valfria vägar för virtuell nätverksgateway. Azure la till de valfria vägarna till alla undernät i det virtuella nätverket när gatewayen och peeringen lades till i det virtuella nätverket.

Azure tog bort vägarna för adressprefixen 10.0.0.0/8, 192.168.0.0/16 och 100.64.0.0/10 från routningstabellen Subnet1 när UDR för adressprefixet 0.0.0.0/0 lades till i Subnet1.

Relaterat innehåll