Vanliga frågor och svar om VPN Gateway
Den här artikeln besvarar vanliga frågor om anslutningar mellan lokala Azure VPN Gateway-anslutningar, hybridkonfigurationsanslutningar och virtuella nätverksgatewayer (VNet). Den innehåller omfattande information om konfigurationsinställningar för punkt-till-plats (P2S), plats-till-plats (S2S) och VNet-till-VNet-konfiguration, inklusive IPsec-protokoll (Internet Protocol Security) och IKE-protokoll (Internet Key Exchange).
Ansluta till virtuella nätverk
Kan jag ansluta till virtuella nätverk i olika Azure-regioner?
Ja. Det finns ingen regionbegränsning. Ett virtuellt nätverk kan ansluta till ett annat virtuellt nätverk i samma Azure-region eller i en annan region.
Kan jag ansluta till virtuella nätverk i olika prenumerationer?
Ja.
Kan jag ange privata DNS-servrar i mitt virtuella nätverk när jag konfigurerar en VPN-gateway?
Om du anger en DNS-server (Domain Name System) eller servrar när du skapar ditt virtuella nätverk använder den virtuella privata nätverksgatewayen (VPN) dessa DNS-servrar. Kontrollera att dina angivna DNS-servrar kan matcha de domännamn som behövs för Azure.
Kan jag ansluta till flera platser från en enda virtuellt nätverk?
Du kan ansluta till flera platser med hjälp av Windows PowerShell och Azure REST-API:er. Se avsnittet Vanliga frågor och svar om anslutning mellan flera platser och VNet-till-VNet.
Finns det en extra kostnad för att konfigurera en VPN-gateway som aktiv-aktiv?
Nej. Kostnader för eventuella ytterligare offentliga IP-adresser debiteras dock i enlighet med detta. Se prissättning för IP-adresser.
Vilka alternativ finns det för min anslutning till flera platser?
Azure VPN Gateway har stöd för följande anslutningar mellan lokala gatewayer:
- Plats-till-plats: VPN-anslutning via IPsec (IKEv1 och IKEv2). Den här typen av anslutning kräver en VPN-enhet eller Windows Server-routning och fjärråtkomst. Mer information finns i Skapa en PLATS-till-plats VPN-anslutning i Azure Portal.
- Punkt-till-plats: VPN-anslutning via SSTP (Secure Socket Tunneling Protocol) eller IKEv2. Den här anslutningen kräver ingen VPN-enhet. Mer information finns i Konfigurera serverinställningar för punkt-till-plats VPN Gateway-certifikatautentisering.
- VNet-till-VNet: Den här typen av anslutning är samma som en plats-till-plats-konfiguration. VNet-till-VNet är en VPN-anslutning via IPsec (IKEv1 och IKEv2). Det kräver ingen VPN-enhet. Mer information finns i Konfigurera en VPN-gatewayanslutning mellan virtuella nätverk.
- Azure ExpressRoute: ExpressRoute är en privat anslutning till Azure från ditt WAN (Wide Area Network), inte en VPN-anslutning via det offentliga Internet. Mer information finns i Den tekniska översikten för ExpressRoute och Vanliga frågor och svar om ExpressRoute.
Mer information om VPN-gatewayanslutningar finns i Vad är Azure VPN Gateway?.
Vad är skillnaden mellan plats-till-plats- och punkt-till-plats-anslutningar?
Konfigurationer för plats-till-plats (IPsec/IKE VPN-tunnel) finns mellan din lokala plats och Azure. Du kan ansluta från någon av dina datorer som finns lokalt till valfri virtuell dator (VM) eller rollinstans i ditt virtuella nätverk, beroende på hur du väljer att konfigurera routning och behörigheter. Det är ett bra alternativ för en alltid tillgänglig anslutning mellan platser och passar bra för hybridkonfigurationer.
Den här typen av anslutning förlitar sig på en IPsec VPN-installation (maskinvaruenhet eller mjuk installation). Installationen måste distribueras i utkanten av nätverket. Om du vill skapa den här typen av anslutning måste du ha en externT riktad IPv4-adress.
Med punkt-till-plats-konfigurationer (VPN via SSTP) kan du ansluta från en enda dator var som helst till allt som finns i ditt virtuella nätverk. Den använder den inbyggda VPN-klienten i Windows.
Som en del av punkt-till-plats-konfigurationen installerar du ett certifikat och ett VPN-klientkonfigurationspaket. Paketet innehåller de inställningar som gör att datorn kan ansluta till valfri virtuell dator eller rollinstans i det virtuella nätverket.
Den här konfigurationen är användbar när du vill ansluta till ett virtuellt nätverk men inte finns lokalt. Det är också ett bra alternativ när du inte har åtkomst till VPN-maskinvara eller en externT ansluten IPv4-adress, som båda krävs för en plats-till-plats-anslutning.
Du kan konfigurera ditt virtuella nätverk att använda både plats-till-plats och punkt-till-plats samtidigt, så länge du skapar din plats-till-plats-anslutning med hjälp av en routningsbaserad VPN-typ för din gateway. Routningsbaserade VPN-typer kallas dynamiska gatewayer i den klassiska distributionsmodellen.
Bryter en felkonfiguration av anpassad DNS den normala driften av en VPN-gateway?
För normal funktion måste VPN-gatewayen upprätta en säker anslutning med Azure-kontrollplanet, vilket underlättas via offentliga IP-adresser. Den här anslutningen förlitar sig på att matcha kommunikationsslutpunkter via offentliga URL:er. Som standard använder virtuella Azure-nätverk den inbyggda Azure DNS-tjänsten (168.63.129.16) för att lösa dessa offentliga URL:er. Det här standardbeteendet hjälper till att säkerställa sömlös kommunikation mellan VPN-gatewayen och Azure-kontrollplanet.
När du implementerar en anpassad DNS i ett virtuellt nätverk är det viktigt att konfigurera en DNS-vidarebefordrare som pekar på Azure DNS (168.63.129.16). Den här konfigurationen hjälper till att upprätthålla oavbruten kommunikation mellan VPN-gatewayen och kontrollplanet. Om du inte konfigurerar en DNS-vidarebefordrare till Azure DNS kan Microsoft inte utföra åtgärder och underhåll på VPN-gatewayen, vilket utgör en säkerhetsrisk.
För att säkerställa korrekt funktionalitet och felfritt tillstånd för vpn-gatewayen bör du överväga någon av följande DNS-konfigurationer i det virtuella nätverket:
- Återgå till Standard för Azure DNS genom att ta bort den anpassade DNS-koden i VNet-inställningarna (rekommenderad konfiguration).
- Lägg till en DNS-vidarebefordrare i din anpassade DNS-konfiguration som pekar på Azure DNS (168.63.129.16). Beroende på de specifika reglerna och arten av din anpassade DNS kanske den här konfigurationen inte löser problemet som förväntat.
Kan två VPN-klienter som är anslutna punkt-till-plats till samma VPN-gateway kommunicera?
Nej. VPN-klienter som är anslutna punkt-till-plats till samma VPN-gateway kan inte kommunicera med varandra.
När två VPN-klienter är anslutna till samma punkt-till-plats-VPN-gateway kan gatewayen automatiskt dirigera trafik mellan dem genom att fastställa DEN IP-adress som varje klient tilldelas från adresspoolen. Men om VPN-klienterna är anslutna till olika VPN-gatewayer går det inte att dirigera mellan VPN-klienterna eftersom varje VPN-gateway inte känner till IP-adressen som den andra gatewayen som tilldelats klienten.
Kan en potentiell sårbarhet som kallas "tunnelseende" påverka punkt-till-plats-VPN-anslutningar?
Microsoft känner till rapporter om en nätverksteknik som kringgår VPN-inkapsling. Detta är en branschomfattande fråga. Den påverkar alla operativsystem som implementerar en DHCP-klient (Dynamic Host Configuration Protocol) enligt RFC-specifikationen och har stöd för DHCP-alternativ 121 vägar, inklusive Windows.
Som forskningen noterar omfattar åtgärder att köra VPN i en virtuell dator som hämtar ett lån från en virtualiserad DHCP-server för att förhindra att det lokala nätverkets DHCP-server installerar vägar helt och hållet. Du hittar mer information om den här sårbarheten i NIST National Vulnerability Database.
Sekretess
Lagrar eller bearbetar VPN-tjänsten kunddata?
Nej.
Virtuella nätverksgatewayer
Är en VPN-gateway en virtuell nätverksgateway?
En VPN-gateway är en typ av virtuell nätverksgateway. En VPN-gateway skickar krypterad trafik mellan det virtuella nätverket och lokal plats via en offentlig anslutning. Du kan också använda en VPN-gateway för att skicka trafik mellan virtuella nätverk. När du skapar en VPN-gateway använder -GatewayType
du värdet Vpn
. Mer information finns i Om konfigurationsinställningar för VPN Gateway.
Varför kan jag inte ange principbaserade och routningsbaserade VPN-typer?
Från och med den 1 oktober 2023 kan du inte skapa en principbaserad VPN-gateway via Azure Portal. Alla nya VPN Gatewayer skapas automatiskt som routningsbaserade. Om du redan har en principbaserad gateway behöver du inte uppgradera din gateway till routningsbaserad. Du kan använda Azure PowerShell eller Azure CLI för att skapa de principbaserade gatewayerna.
Tidigare hade de äldre gatewayproduktnivåerna (SKU:er) inte stöd för IKEv1 för routningsbaserade gatewayer. Nu har de flesta av de aktuella gateway-SKU:erna stöd för både IKEv1 och IKEv2.
Gateway-VPN-typ | Gateway-SKU | IKE-versioner som stöds |
---|---|---|
Principbaserad gateway | Grundläggande | IKEv1 |
Routningsbaserad gateway | Grundläggande | IKEv2 |
Routningsbaserad gateway | VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 | IKEv1 och IKEv2 |
Routningsbaserad gateway | VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ | IKEv1 och IKEv2 |
Kan jag uppdatera min principbaserade VPN-gateway till routningsbaserad?
Nej. En gatewaytyp kan inte ändras från principbaserad till routningsbaserad eller från routningsbaserad till principbaserad. Om du vill ändra en gatewaytyp måste du ta bort och återskapa gatewayen genom att utföra följande steg. Den här processen tar cirka 60 minuter. När du skapar den nya gatewayen kan du inte behålla IP-adressen för den ursprungliga gatewayen.
Ta bort alla anslutningar som är associerade med gatewayen.
Ta bort gatewayen med någon av följande artiklar:
Skapa en ny gateway med den gatewaytyp du vill använda och slutför sedan VPN-konfigurationen. Anvisningar finns i självstudien plats-till-plats.
Kan jag ange mina egna principbaserade trafikväljare?
Ja, du kan definiera trafikväljare med hjälp trafficSelectorPolicies
av attributet på en anslutning via Kommandot New-AzIpsecTrafficSelectorPolicy Azure PowerShell. För att den angivna trafikväljaren ska börja gälla måste du aktivera principbaserade trafikväljare.
De anpassade konfigurerade trafikväljarna föreslås endast när en VPN-gateway initierar anslutningen. En VPN-gateway accepterar alla trafikväljare som föreslås av en fjärrgateway (lokal VPN-enhet). Det här beteendet är konsekvent mellan alla anslutningslägen (Default
, InitiatorOnly
och ResponderOnly
).
Behöver jag ett gateway-undernät?
Ja. Gatewayundernätet innehåller de IP-adresser som gatewaytjänsterna för virtuella nätverk använder. Du måste skapa ett gateway-undernät för ditt virtuella nätverk för att kunna konfigurera en virtuell nätverksgateway.
Alla gateway-undernät måste namnges GatewaySubnet
för att fungera korrekt. Ge inte något annat namn till gateway-undernätet. Och distribuera inte virtuella datorer eller något annat till gateway-undernätet.
När du skapar gatewayundernätet anger du det antal IP-adresser som undernätet innehåller. IP-adresserna i gatewayundernätet allokeras till gatewaytjänsten.
Vissa konfigurationer kräver att fler IP-adresser allokeras till gatewaytjänsterna än andra. Kontrollera att gatewayundernätet innehåller tillräckligt med IP-adresser för framtida tillväxt och eventuella nya anslutningskonfigurationer.
Även om du kan skapa ett gatewayundernät så litet som /29 rekommenderar vi att du skapar ett gateway-undernät på /27 eller större (/27, /26, /25 och så vidare). Kontrollera att ditt befintliga gatewayundernät uppfyller kraven för den konfiguration som du vill skapa.
Kan jag distribuera virtuella datorer eller rollinstanser till mitt gatewayundernät?
Nej.
Kan jag få min IP-adress för VPN-gatewayen innan jag skapar den?
Offentliga IP-resurser för Azure Standard SKU måste använda en statisk allokeringsmetod. Du har den offentliga IP-adressen för din VPN-gateway så snart du skapar den offentliga IP-resursen standard-SKU som du tänker använda för den.
Kan jag begära en statisk offentlig IP-adress för min VPN-gateway?
Offentliga IP-adressresurser för standard-SKU använder en statisk allokeringsmetod. Framöver måste du använda en offentlig IP-adress för Standard SKU när du skapar en ny VPN-gateway. Det här kravet gäller för alla gateway-SKU:er utom basic-SKU:n. Basic SKU stöder för närvarande endast offentliga IP-adresser för Basic SKU. Vi arbetar med att lägga till stöd för offentliga IP-adresser för Standard SKU för Basic SKU.
För icke-zonredundanta och icke-zonindelade gatewayer som tidigare har skapats (gateway-SKU:er som inte har AZ i namnet) stöds dynamisk IP-adresstilldelning men fasas ut. När du använder en dynamisk IP-adress ändras inte IP-adressen när den har tilldelats till din VPN-gateway. Den enda gången som VPN-gatewayens IP-adress ändras är när gatewayen tas bort och sedan återskapas. Den offentliga IP-adressen ändras inte när du ändrar storlek på, återställer eller slutför annat internt underhåll och uppgraderingar av vpn-gatewayen.
Hur påverkar tillbakadragandet av offentliga IP-adresser för Grundläggande SKU mina VPN-gatewayer?
Vi vidtar åtgärder för att säkerställa fortsatt drift av distribuerade VPN-gatewayer som använder offentliga IP-adresser för Basic SKU fram till tillbakadragandet av grundläggande IP-adress i september 2025. Innan den här tillbakadragningen kommer vi att ge kunderna en migreringsväg från Basic till Standard IP.
Grundläggande offentliga IP-adresser för SKU håller dock på att fasas ut. När du skapar en VPN-gateway måste du använda den offentliga IP-adressen för Standard SKU framöver. Du hittar information om tillbakadragandet av offentliga IP-adresser för Basic SKU i Azure Updates-meddelandet.
Hur autentiseras min VPN-tunnel?
Azure VPN Gateway använder autentisering med i förväg delad nyckel (PSK). Vi genererar en PSK när vi skapar VPN-tunneln. Du kan ändra den automatiskt genererade PSK:n till din egen med hjälp av REST API för fördelade nycklar eller PowerShell-cmdleten.
Kan jag använda REST-API:et Set Pre-Shared Key för att konfigurera min principbaserade gateway-VPN (statisk routning) ?
Ja. Du kan använda REST API för fördelade nycklar och PowerShell-cmdleten för att konfigurera både Azure-principbaserade (statiska) VPN:er och routningsbaserade (dynamiska) routnings-VPN:er.
Kan jag använda andra autentiseringsalternativ?
Du är begränsad till att använda i förväg delade nycklar för autentisering.
Hur anger jag vilken trafik som ska passera VPN-gatewayen?
För Azure Resource Manager-distributionsmodellen:
- Azure PowerShell: Används
AddressPrefix
för att ange trafik för den lokala nätverksgatewayen. - Azure Portal: Gå till konfigurationsadressutrymme> för lokal nätverksgateway.>
För den klassiska distributionsmodellen:
- Azure Portal: Gå till det klassiska virtuella nätverket och gå sedan till VPN-anslutningar Plats-till-plats VPN-anslutningar>lokal platsnamn>lokal plats>Klientadressutrymme.>
Kan jag använda NAT-T på mina VPN-anslutningar?
Ja, nat-T (network address translation traversal) stöds. Azure VPN Gateway utför inga NAT-liknande funktioner på de inre paketen till eller från IPsec-tunnlarna. I den här konfigurationen kontrollerar du att den lokala enheten initierar IPSec-tunneln.
Kan jag installera min egen VPN-server i Azure och använda den för att ansluta till mitt lokala nätverk?
Ja. Du kan distribuera dina egna VPN-gatewayer eller servrar i Azure från Azure Marketplace eller genom att skapa egna VPN-routrar. Du måste konfigurera användardefinierade vägar i det virtuella nätverket för att säkerställa att trafiken dirigeras korrekt mellan dina lokala nätverk och dina virtuella nätverksundernät.
Varför öppnas vissa portar på min virtuella nätverksgateway?
De krävs för azure-infrastrukturkommunikation. Azure-certifikat hjälper till att skydda dem genom att låsa dem. Utan rätt certifikat kan externa entiteter, inklusive kunderna för dessa gatewayer, inte orsaka någon effekt på dessa slutpunkter.
En virtuell nätverksgateway är i grunden en multihomed-enhet. Ett nätverkskort utnyttjar kundens privata nätverk och ett nätverkskort står inför det offentliga nätverket. Azure-infrastrukturentiteter kan inte utnyttja kundens privata nätverk av efterlevnadsskäl, så de måste använda offentliga slutpunkter för infrastrukturkommunikation. En Azure-säkerhetsgranskning söker regelbundet igenom de offentliga slutpunkterna.
Kan jag skapa en VPN-gateway med hjälp av Basic SKU i portalen?
Nej. Basic SKU är inte tillgängligt i portalen. Du kan skapa en Grundläggande SKU VPN-gateway med hjälp av Azure CLI eller Azure PowerShell-stegen .
Var hittar jag information om gatewaytyper, krav och dataflöde?
Mer information finns i följande artiklar:
Utfasning av äldre SKU:er
SKU:er för standard och höga prestanda kommer att vara inaktuella den 30 september 2025. Du kan visa meddelandet på Azure Updates-webbplatsen. Produktteamet kommer att göra en migreringssökväg tillgänglig för dessa SKU:er senast den 30 november 2024. Mer information finns i artikeln äldre SKU:er för VPN Gateway.
För närvarande finns det ingen åtgärd som du behöver vidta.
Kan jag skapa en ny gateway som använder en standard- eller högpresterande SKU efter utfasningsmeddelandet den 30 november 2023?
Nej. Från och med den 1 december 2023 kan du inte skapa gatewayer som använder SKU:er med standard eller höga prestanda. Du kan skapa gatewayer som använder VPNGw1- och VpnGw2-SKU:er till samma pris som SKU:er för standard- respektive högprestanda som anges på prissidan.
Hur länge kommer mina befintliga gatewayer att stödjas på SKU:er för standard och höga prestanda?
Alla befintliga gatewayer som använder SKU:n Standard eller High Performance stöds fram till den 30 september 2025.
Behöver jag migrera mina gatewayer från standard- eller högpresterande SKU:n just nu?
Nej, det krävs ingen åtgärd just nu. Du kan migrera dina gatewayer från och med december 2024. Vi skickar kommunikation med detaljerad dokumentation om migreringsstegen.
Vilken SKU kan jag migrera min gateway till?
När gateway-SKU-migrering blir tillgänglig kan SKU:er migreras på följande sätt:
- Standard till VpnGw1
- Höga prestanda för VpnGw2
Vad händer om jag vill migrera till en AZ SKU?
Du kan inte migrera din inaktuella SKU till en AZ SKU. Alla gatewayer som fortfarande använder SKU:n Standard eller High Performance efter den 30 september 2025 migreras och uppgraderas automatiskt till AZ SKU:er enligt följande:
- Standard till VpnGw1AZ
- Höga prestanda för VpnGw2AZ
Du kan använda den här strategin för att migrera och uppgradera dina SKU:er automatiskt till en AZ SKU. Du kan sedan ändra storlek på din SKU inom den SKU-familjen om det behövs. Priser för AZ SKU finns på prissidan. Information om dataflöde via SKU finns i Om gateway-SKU :er.
Kommer det att finnas någon prisskillnad för mina gatewayer efter migreringen?
Om du migrerar dina SKU:er senast den 30 september 2025 blir det ingen prisskillnad. VpnGw1- och VpnGw2-SKU:er erbjuds till samma pris som SKU:er för standard- respektive högpresterande SKU:er.
Om du inte migrerar vid det datumet migreras och uppgraderas dina SKU:er automatiskt till AZ-SKU:er. I så fall finns det en prisskillnad.
Kommer det att finnas någon prestandapåverkan på mina gatewayer med den här migreringen?
Ja. Du får bättre prestanda med VpnGw1 och VpnGw2. VpnGw1 på 650 Mbit/s ger för närvarande en prestandaförbättring på 6,5 x till samma pris som standard-SKU:n. VpnGw2 på 1 Gbit/s ger en prestandaförbättring på 5 x till samma pris som SKU:n med höga prestanda. Mer information om SKU-dataflöde finns i Om gateway-SKU:er.
Vad händer om jag inte migrerar senast den 30 september 2025?
Alla gatewayer som fortfarande använder SKU:n Standard eller High Performance migreras automatiskt och uppgraderas till följande AZ-SKU:er:
- Standard till VpnGw1AZ
- Höga prestanda för VpnGw2AZ
Vi skickar kommunikation innan du påbörjar migreringen på alla gatewayer.
Går VPN Gateway Basic SKU också tillbaka?
Nej, VPN Gateway Basic SKU dras inte tillbaka. Du kan skapa en VPN-gateway med hjälp av Basic SKU via Azure PowerShell eller Azure CLI.
För närvarande stöder VPN Gateway Basic SKU endast den offentliga IP-adressresursen Basic SKU (som är på väg att dras tillbaka). Vi arbetar med att lägga till stöd för den offentliga IP-adressresursen för Standard SKU till VPN Gateway Basic SKU.
Plats-till-plats-anslutningar och VPN-enheter
Vad bör jag tänka på när jag väljer en VPN-enhet?
Vi har verifierat en uppsättning standard-VPN-enheter för plats-till-plats i samarbete med enhetsleverantörer. Du hittar en lista över kända kompatibla VPN-enheter, deras motsvarande konfigurationsinstruktioner eller exempel och enhetsspecifikationer i artikeln Om VPN-enheter .
Alla enheter i de enhetsfamiljer som anges som kända kompatibla bör fungera med virtuella nätverk. Information om hur du konfigurerar VPN-enheten finns i exemplet på enhetskonfiguration eller länken som motsvarar rätt enhetsfamilj.
Var hittar jag konfigurationsinställningar för VPN-enheter?
Beroende på vilken VPN-enhet du har kanske du kan ladda ned ett konfigurationsskript för VPN-enheter. Mer information finns i Ladda ned konfigurationsskript för VPN-enheten.
Följande länkar innehåller mer konfigurationsinformation:
Information om kompatibla VPN-enheter finns i Om VPN-enheter.
Innan du konfigurerar VPN-enheten kontrollerar du om det finns några kända problem med enhetskompatibiliteten.
Länkar till enhetskonfigurationsinställningar finns i Verifierade VPN-enheter. Vi tillhandahåller länkar för enhetskonfiguration på bästa sätt, men det är alltid bäst att kontakta enhetstillverkaren för att få den senaste konfigurationsinformationen.
Listan visar de versioner som vi har testat. Om operativsystemets version för VPN-enheten inte finns med i listan kan den fortfarande vara kompatibel. Kontakta enhetstillverkaren.
Grundläggande information om VPN-enhetskonfiguration finns i Översikt över partner-VPN-enhetskonfigurationer.
Mer information om att redigera enhetens konfigurationsexempel finns i Redigera exempel.
Kryptografiska krav finns i Om kryptografiska krav och Azure VPN-gatewayer.
Information om parametrar som du behöver för att slutföra konfigurationen finns i Standardparametrar för IPsec/IKE. Informationen omfattar IKE-version, Diffie-Hellman-grupp (DH), autentiseringsmetod, krypterings- och hashalgoritmer, livslängd för säkerhetsassociation (SA), PFS (Perfect Forward Secrecy) och DPD (Dead Peer Detection).
Information om konfigurationssteg för IPsec/IKE-principer finns i Konfigurera anpassade IPsec/IKE-anslutningsprinciper för S2S VPN och VNet-till-VNet.
Information om hur du ansluter flera principbaserade VPN-enheter finns i Ansluta en VPN-gateway till flera lokala principbaserade VPN-enheter.
Hur redigerar jag konfigurationsexempel för VPN-enheter?
Se Redigera enhetskonfigurationsexempel.
Var hittar jag IPsec- och IKE-parametrar?
Se Standardparametrar för IPsec/IKE.
Varför stängs min principbaserade VPN-tunnel när trafiken är inaktiv?
Det här beteendet förväntas för principbaserade (även kallade statisk routning) VPN-gatewayer. När trafiken över tunneln är inaktiv i mer än fem minuter rivs tunneln. När trafiken börjar flöda i båda riktningarna återupprättas tunneln omedelbart.
Kan jag använda programvaru-VPN:er för att ansluta till Azure?
Vi stöder Routning och fjärråtkomstservrar för Windows Server 2012 för plats-till-plats-konfiguration mellan platser.
Andra VPN-lösningar för programvara bör fungera med gatewayen, så länge de överensstämmer med branschstandardimplementeringar av IPsec. Om du vill ha konfigurations- och supportinstruktioner kontaktar du leverantören av programvaran.
Kan jag ansluta till en VPN-gateway via punkt-till-plats när den finns på en plats som har en aktiv plats-till-plats-anslutning?
Ja, men de offentliga IP-adresserna för punkt-till-plats-klienten måste skilja sig från de offentliga IP-adresser som VPN-enheten använder för plats-till-plats, annars fungerar inte punkt-till-plats-anslutningen. Punkt-till-plats-anslutningar med IKEv2 kan inte initieras från samma offentliga IP-adresser där en plats-till-plats-VPN-anslutning konfigureras på samma VPN-gateway.
Punkt-till-plats-anslutningar
Hur många VPN-klientslutpunkter kan jag ha i min punkt-till-plats-konfiguration?
Det beror på gateway-SKU. Mer information om det antal anslutningar som stöds finns i Gateway-SKU:er.
Vilka klientoperativsystem kan jag använda med punkt-till-plats?
Följande klientoperativsystem stöds:
- Windows Server 2008 R2 (endast 64-bitars)
- Windows 8.1 (32-bitars och 64-bitars)
- Windows Server 2012 (endast 64-bitars)
- Windows Server 2012 R2 (endast 64-bitars)
- Windows Server 2016 (endast 64-bitars)
- Windows Server 2019 (endast 64-bitars)
- Windows Server 2022 (endast 64-bitars)
- Windows 10
- Windows 11
- macOS version 10.11 eller senare
- Linux (strongSwan)
- iOS
Kan jag gå igenom proxyservrar och brandväggar med hjälp av punkt-till-plats-funktioner?
Azure Support finns tre typer av punkt-till-plats-VPN-alternativ:
Secure Socket Tunneling Protocol (SSTP): En Microsoft-skyddad SSL-baserad lösning som kan penetrera brandväggar eftersom de flesta brandväggar öppnar den utgående TCP-porten som 443 SSL använder.
OpenVPN: En SSL-baserad lösning som kan tränga in i brandväggar eftersom de flesta brandväggar öppnar den utgående TCP-porten som 443 SSL använder.
IKEv2 VPN: En standardbaserad IPsec VPN-lösning som använder utgående UDP-portar 500 och 4500, tillsammans med IP-protokollnummer 50. Brandväggar öppnar inte alltid dessa portar, så det finns en möjlighet att IKEv2 VPN inte kan passera proxyservrar och brandväggar.
Kommer VPN automatiskt att återansluta om jag startar om en klientdator som jag har konfigurerat för punkt-till-plats?
Automatisk återanslutning är en funktion av den klient som du använder. Windows stöder automatisk återanslutning via funktionen AlwaysOn VPN-klient .
Stöder punkt-till-plats DDNS på VPN-klienterna?
Dynamisk DNS (DDNS) stöds för närvarande inte i punkt-till-plats-VPN.
Kan plats-till-plats- och punkt-till-plats-konfigurationer samexistera för samma virtuella nätverk?
Ja. För Resource Manager-distributionsmodellen måste du ha en routningsbaserad VPN-typ för din gateway. I den klassiska distributionsmodellen måste du ha en dynamisk gateway. Vi stöder inte punkt-till-plats för statisk routning av VPN-gatewayer eller principbaserade VPN-gatewayer.
Kan jag konfigurera en punkt-till-plats-klient för att ansluta till flera virtuella nätverksgatewayer samtidigt?
Beroende på vilken VPN-klientprogramvara du använder kanske du kan ansluta till flera virtuella nätverksgatewayer. Men så är det bara om de virtuella nätverk som du ansluter till inte har motstridiga adressutrymmen mellan dem eller med nätverket som klienten ansluter från. Även om Azure VPN-klienten stöder många VPN-anslutningar kan du bara ha en anslutning när som helst.
Kan jag konfigurera en punkt-till-plats-klient för att ansluta till flera virtuella nätverk samtidigt?
Ja. Punkt-till-plats-klientanslutningar till en VPN-gateway som distribueras i ett VNet som är peer-kopplat till andra virtuella nätverk kan ha åtkomst till de andra peerkopplade virtuella nätverken, så länge de uppfyller vissa konfigurationsvillkor. För att en punkt-till-plats-klient ska ha åtkomst till ett peer-kopplat VNet måste det peerkopplade virtuella nätverket (det virtuella nätverket utan gatewayen) konfigureras med attributet Använd fjärrgatewayer . Det virtuella nätverket med VPN-gatewayen måste konfigureras med Tillåt gatewayöverföring. Mer information finns i Om punkt-till-plats VPN-routning.
Hur mycket dataflöde kan jag förvänta mig via plats-till-plats- eller punkt-till-plats-anslutningar?
Det är svårt att bibehålla ett exakt dataflöde i VPN-tunnlarna. IPsec och SSTP är kryptografifrekventa VPN-protokoll. Svarstiden och bandbredden mellan din lokala plats och Internet kan också begränsa dataflödet.
För en VPN-gateway med endast IKEv2 punkt-till-plats VPN-anslutningar beror det totala dataflödet som du kan förvänta dig på gateway-SKU:n. Mer information om dataflödet finns i avsnittet om Gateway-SKU:er.
Kan jag använda en VPN-klient för programvara för punkt-till-plats som stöder SSTP eller IKEv2?
Nej. Du kan bara använda den interna VPN-klienten i Windows för SSTP och den interna VPN-klienten på Mac för IKEv2. Du kan dock använda OpenVPN-klienten på alla plattformar för att ansluta via OpenVPN-protokollet. Se listan över klientoperativsystem som stöds.
Kan jag ändra autentiseringstypen för en punkt-till-plats-anslutning?
Ja. I portalen går du till VPN-gatewayens>punkt-till-plats-konfiguration. Som Autentiseringstyp väljer du den autentiseringstyp som du vill använda.
När du har ändrat autentiseringstypen kanske de aktuella klienterna inte kan ansluta förrän du genererar en ny VPN-klientkonfigurationsprofil, laddar ned den och tillämpar den på varje VPN-klient.
När behöver jag generera ett nytt konfigurationspaket för VPN-klientprofilen?
När du gör ändringar i konfigurationsinställningarna för P2S VPN-gatewayen, till exempel lägga till en tunneltyp eller ändra en autentiseringstyp, måste du generera ett nytt konfigurationspaket för VPN-klientprofilen. Det nya paketet innehåller de uppdaterade inställningar som VPN-klienter behöver för att ansluta till P2S-gatewayen. När du har genererat paketet använder du inställningarna i filerna för att uppdatera VPN-klienterna.
Har Azure stöd för IKEv2 VPN-anslutningar i Windows?
IKEv2 stöds på Windows 10 och Windows Server 2016. Men om du vill använda IKEv2 i vissa os-versioner måste du installera uppdateringar och ange ett registernyckelvärde lokalt. Tidigare operativsystemversioner än Windows 10 stöds inte och kan endast använda SSTP eller OpenVPN-protokollet.
Kommentar
Windows OS bygger nyare än Windows 10 Version 1709 och Windows Server 2016 Version 1607 kräver inte dessa steg.
Förbereda Windows 10 eller Windows Server 2016 för IKEv2:
Installera uppdateringen baserat på din operativsystemversion:
OS-version Datum Antal/länk Windows Server 2016
Windows 10, version 160717 januari 2018 KB4057142 Windows 10, version 1703 17 januari 2018 KB4057144 Windows 10 version 1709 22 mars 2018 KB4089848 Ange registernyckelvärdet. Skapa eller ange
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload
REG_DWORD
nyckeln i registret till1
.
Vad är IKEv2-trafikväljarens gräns för punkt-till-plats-anslutningar?
Windows 10 version 2004 (släpptes september 2021) ökade trafikväljarens gräns till 255. Tidigare versioner av Windows har en trafikväljare på 25.
Trafikväljarens gräns i Windows avgör det maximala antalet adressutrymmen i det virtuella nätverket och den maximala summan av dina lokala nätverk, VNet-till-VNet-anslutningar och peer-kopplade virtuella nätverk som är anslutna till gatewayen. Windows-baserade punkt-till-plats-klienter kan inte ansluta via IKEv2 om de överskrider den här gränsen.
Vad är openVPN-trafikväljarens gräns för punkt-till-plats-anslutningar?
Trafikväljarens gräns för OpenVPN är 1 000 vägar.
Vad händer när jag konfigurerar både SSTP och IKEv2 för P2S VPN-anslutningar?
När du konfigurerar både SSTP och IKEv2 i en blandad miljö som består av Windows- och Mac-enheter, försöker Windows VPN-klienten alltid IKEv2-tunneln först. Klienten återgår till SSTP om IKEv2-anslutningen inte lyckas. MacOS ansluter endast via IKEv2.
När du har både SSTP och IKEv2 aktiverat på gatewayen delas punkt-till-plats-adresspoolen statiskt mellan de två, så klienter som använder olika protokoll är IP-adresser från båda underordnad ordning. Det maximala antalet SSTP-klienter är alltid 128, även om adressintervallet är större än /24. Resultatet är ett större antal adresser som är tillgängliga för IKEv2-klienter. För mindre intervall är poolen lika halverad. Trafikväljare som gatewayen använder kanske inte innehåller CIDR-blocket (Classless Inter-Domain Routing) för punkt-till-plats-adressintervallet, men inkluderar CIDR-blocket för de två underorganen.
Vilka plattformar Azure Support för P2S VPN?
Azure Support Windows, Mac och Linux för P2S VPN.
Jag har redan distribuerat en VPN-gateway. Kan jag aktivera RADIUS eller IKEv2 VPN på den?
Ja. Om gateway-SKU:n som du använder stöder RADIUS eller IKEv2 kan du aktivera dessa funktioner på gatewayer som du redan har distribuerat med hjälp av Azure PowerShell eller Azure Portal. Basic SKU stöder inte RADIUS eller IKEv2.
Varför kopplas jag från från min Azure VPN-klient? Vad kan jag göra för att minska frånkopplingsfrekvensen?
Du kan se något av följande meddelanden:
- I Azure VPN-klienten för Windows ver. 3.4.0.0: "Din autentisering med Microsoft Entra har upphört att gälla. Du måste autentisera igen i Entra för att hämta en ny token. Tidsgränsen för autentisering kan justeras av administratören."
- I Azure VPN-klienten för macOS ver. 2.7.101: "Din autentisering med Microsoft Entra har upphört att gälla så du måste autentisera igen för att hämta en ny token. Försök att ansluta igen. Autentiseringsprinciper och timeout konfigureras av administratören i Entra-klientorganisationen."
Punkt-till-plats-anslutningen kopplas från eftersom den aktuella uppdateringstoken i Azure VPN-klienten, som hämtats från Etttra-ID, har upphört att gälla eller blivit ogiltig. Denna token förnyas ungefär varje timme. Entra-klientadministratörer kan utöka inloggningsfrekvensen genom att lägga till principer för villkorlig åtkomst. Kontakta entra-klientadministratörerna för att utöka förfallointervallet för uppdateringstoken.
Mer information finns i: VPN-klientfel: Din autentisering med Microsoft Entra har upphört att gälla.
Hur tar jag bort konfigurationen av en P2S-anslutning?
Du kan ta bort en P2S-konfiguration med hjälp av följande Azure PowerShell- eller Azure CLI-kommandon:
$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`
$gw.VPNClientConfiguration = $null`
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`
az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"
Punkt-till-plats-anslutningar med certifikatautentisering
Vad ska jag göra om jag får ett felmatchat certifikat för en punkt-till-plats-anslutning för certifikatautentisering?
Avmarkera kryssrutan Verifiera serverns identitet genom att verifiera certifikatet . Du kan också lägga till serverns fullständigt kvalificerade domännamn (FQDN) tillsammans med certifikatet när du skapar en profil manuellt. Du kan göra detta genom att köra rasphone
från en kommandotolk och välja profilen i listrutan.
Vi rekommenderar inte att du kringgår verifieringen av serveridentiteten i allmänhet. Men med Azure-certifikatautentisering används samma certifikat för servervalidering i VPN-tunnelprotokollet (IKEv2 eller SSTP) och EAP (Extensible Authentication Protocol). Eftersom VPN-tunnelprotokollet redan verifierar servercertifikatet och FQDN är det redundant att verifiera dem igen i EAP.
Kan jag använda min egen interna PKI-rotcertifikatutfärdare för att generera certifikat för punkt-till-plats-anslutning?
Ja. Tidigare kunde du bara använda självsignerade rotcertifikat. Du kan fortfarande överföra 20 rotcertifikat.
Kan jag använda certifikat från Azure Key Vault?
Nej.
Vilka verktyg kan jag använda för att skapa certifikat?
Du kan använda din PKI-lösning (enterprise public key infrastructure) (din interna PKI), Azure PowerShell, MakeCert och OpenSSL.
Finns det anvisningar för certifikatinställningar och -parametrar?
Information om filformaten .cer och .pfx finns i:
Information om .pem-filformat finns i:
Punkt-till-plats-anslutningar med RADIUS-autentisering
Stöds RADIUS-autentisering med alla Azure VPN Gateway-SKU:er?
RADIUS-autentisering stöds för alla SKU:er utom Basic SKU.
För tidigare SKU:er stöds RADIUS-autentisering på SKU:er med standard- och högpresterande prestanda.
Stöds RADIUS-autentisering med den klassiska distributionsmodellen?
Nej.
Vad är tidsgränsen för RADIUS-begäranden som skickas till RADIUS-servern?
RADIUS-begäranden är inställda på tidsgräns efter 30 sekunder. Användardefinierade tidsgränsvärden stöds inte för närvarande.
Stöds RADIUS-servrar från tredje part?
Ja.
Vilka är anslutningskraven för att säkerställa att Azure-gatewayen kan nå en lokal RADIUS-server?
Du behöver en plats-till-plats VPN-anslutning till den lokala platsen, med rätt vägar konfigurerade.
Kan trafik till en lokal RADIUS-server (från VPN-gatewayen) dirigeras via en ExpressRoute-anslutning?
Nej. Den kan endast dirigeras via en plats-till-plats-anslutning.
Finns det en ändring i antalet SSTP-anslutningar som stöds med RADIUS-autentisering? Vad är det maximala antalet SSTP- och IKEv2-anslutningar som stöds?
Det finns ingen ändring i det maximala antalet SSTP-anslutningar som stöds på en gateway med RADIUS-autentisering. Det är fortfarande 128 för SSTP, men det beror på gateway-SKU:n för IKEv2. Mer information om antalet anslutningar som stöds finns i Om gateway-SKU:er.
Vad är skillnaden mellan certifikatautentisering via en RADIUS-server och azure-intern certifikatautentisering via uppladdning av ett betrott certifikat?
I RADIUS-certifikatautentisering vidarebefordras autentiseringsbegäran till en RADIUS-server som hanterar certifikatverifieringen. Det här alternativet är bra om du vill integrera med en infrastruktur för certifikatautentisering som du redan har via RADIUS.
När du använder Azure för certifikatautentisering utför VPN-gatewayen valideringen av certifikatet. Du måste ladda upp den offentliga nyckeln för ditt certifikat till gatewayen. Du kan också ange en lista över återkallade certifikat som inte ska tillåtas att ansluta.
Stöder RADIUS-autentisering nätverksprincipserverintegrering för multifaktorautentisering?
Om multifaktorautentiseringen är textbaserad (till exempel SMS eller en verifieringskod för mobilappar) och kräver att användaren anger en kod eller text i VPN-klientgränssnittet lyckas inte autentiseringen och är inte ett scenario som stöds. Se Integrera RADIUS-autentisering för Azure VPN-gateway med NPS-server för multifaktorautentisering.
Fungerar RADIUS-autentisering med både IKEv2 och SSTP VPN?
Ja, RADIUS-autentisering stöds för både IKEv2 och SSTP VPN.
Fungerar RADIUS-autentisering med OpenVPN-klienten?
RADIUS-autentisering stöds för OpenVPN-protokollet.
VNet-till-VNet- och anslutningar med flera platser
Informationen om VNet-till-VNet i det här avsnittet gäller vpn-gatewayanslutningar. Information om VNet-peering finns i Peering för virtuellt nätverk.
Tar Azure ut avgifter för trafik mellan virtuella nätverk?
VNet-till-VNet-trafik inom samma region är kostnadsfri för båda riktningarna när du använder en VPN-gatewayanslutning. Utgående trafik mellan regioner för VNet-till-VNet debiteras med utgående dataöverföringshastigheter mellan virtuella nätverk baserat på källregionerna. Mer information finns i Priser för Azure VPN Gateway. Om du ansluter dina virtuella nätverk med VNet-peering i stället för en VPN-gateway kan du läsa priser för Azure Virtual Network.
Reser VNet-till-VNet-trafik över Internet?
Nej. VNet-till-VNet-trafik färdas över Microsoft Azure-stamnätet, inte internet.
Kan jag upprätta en VNet-till-VNet-anslutning mellan Microsoft Entra-klienter?
Ja. VNet-till-VNet-anslutningar som använder VPN-gatewayer fungerar i Microsoft Entra-klienter.
Är trafiken mellan virtuella nätverk säker?
IPsec- och IKE-kryptering hjälper till att skydda VNet-till-VNet-trafik.
Behöver jag en VPN-enhet för att koppla ihop virtuella nätverk?
Nej. Att ansluta flera virtuella Azure-nätverk tillsammans kräver ingen VPN-enhet om du inte behöver anslutning mellan platser.
Behöver mina virtuella nätverk finnas inom samma region?
Nej. De virtuella nätverken kan finnas i samma eller olika Azure-regioner (platser).
Behöver prenumerationerna associeras med samma Microsoft Entra-klientorganisation om de inte finns i samma prenumeration?
Nej.
Kan jag använda VNet-till-VNet för att ansluta virtuella nätverk i separata Azure-instanser?
Nej. Du kan använda VNet-till-VNet för att ansluta virtuella nätverk inom samma Azure-instans. Du kan till exempel inte skapa en anslutning mellan globala Azure- och kinesiska, tyska eller amerikanska myndigheters Azure-instanser. Överväg att använda en PLATS-till-plats-VPN-anslutning för dessa scenarier.
Kan jag använda anslutningar mellan virtuella nätverk tillsammans med anslutningar mellan flera platser?
Ja. Du kan använda virtuella nätverksanslutningar samtidigt med vpn-nätverk med flera platser.
Hur många lokala platser och virtuella nätverk kan ett virtuellt nätverk ansluta till?
Se tabellen för gatewaykrav .
Kan jag använda VNet-till-VNet för att ansluta virtuella datorer eller molntjänster utanför ett virtuellt nätverk?
Nej. VNet-till-VNet stöder anslutning av virtuella nätverk. Den stöder inte anslutning av virtuella datorer eller molntjänster som inte finns i ett virtuellt nätverk.
Kan en molntjänst eller en belastningsutjämningsslutpunkt sträcka sig över virtuella nätverk?
Nej. En molntjänst eller en belastningsutjämningsslutpunkt kan inte sträcka sig över virtuella nätverk, även om de är anslutna tillsammans.
Kan jag använda en principbaserad VPN-typ för VNet-till-VNet eller anslutningar med flera platser?
Nej. VNet-till-VNet- och anslutningar med flera platser kräver VPN-gatewayer med routningsbaserade (tidigare kallade dynamisk routning) VPN-typer.
Kan jag ansluta ett virtuellt nätverk med en routningsbaserad VPN-typ till ett annat VNet med en principbaserad VPN-typ?
Nej. Båda de virtuella nätverken måste använda routningsbaserade (tidigare kallade dynamisk routning) VPN.
Delar VPN-tunnlar bandbredd?
Ja. Alla VPN-tunnlar i det virtuella nätverket delar den tillgängliga bandbredden på VPN-gatewayen och samma servicenivåavtal för VPN-gatewayens drifttid i Azure.
Finns det stöd för redundanta tunnlar?
Redundanta tunnlar mellan ett par med virtuella nätverk stöds när en virtuell nätverksgateway är konfigurerad som aktiv-aktiv.
Kan jag har överlappande adressutrymmen för konfigurationer mellan virtuella nätverk?
Nej. Du kan inte ha överlappande IP-adressintervall.
Får det finnas överlappande adressutrymmen i anslutna virtuella nätverk och på lokala platser?
Nej. Du kan inte ha överlappande IP-adressintervall.
Hur gör jag för att aktivera routning mellan min plats-till-plats VPN-anslutning och ExpressRoute?
Om du vill aktivera routning mellan din gren som är ansluten till ExpressRoute och din gren är ansluten till ett plats-till-plats-VPN måste du konfigurera Azure Route Server.
Kan jag använda en VPN-gateway för att skicka trafik mellan mina lokala platser eller till ett annat virtuellt nätverk?
Distributionsmodell för Resource Manager
Ja. Mer information finns i avsnittet BGP och routning .
Klassisk distributionsmodell
Det går att överföra trafik via en VPN-gateway när du använder den klassiska distributionsmodellen, men den förlitar sig på statiskt definierade adressutrymmen i nätverkskonfigurationsfilen. Border Gateway Protocol (BGP) stöds för närvarande inte med virtuella Azure-nätverk och VPN-gatewayer via den klassiska distributionsmodellen. Utan BGP är det felbenäget och rekommenderas inte att manuellt definiera adressutrymmen för överföring.
Genererar Azure samma IPsec/IKE-i förväg delade nyckel för alla mina VPN-anslutningar för samma virtuella nätverk?
Nej. Som standard genererar Azure olika i förväg delade nycklar för olika VPN-anslutningar. Du kan dock använda rest-API:et för VPN Gateway-nyckeln eller PowerShell-cmdleten för att ange det nyckelvärde som du föredrar. Nyckeln får endast innehålla utskrivbara ASCII-tecken, förutom blanksteg, bindestreck (-) eller tilde (~).
Får jag mer bandbredd med fler plats-till-plats-VPN än för ett enda virtuellt nätverk?
Nej. Alla VPN-tunnlar, inklusive punkt-till-plats-VPN, delar samma VPN-gateway och tillgänglig bandbredd.
Kan jag konfigurera flera tunnlar mellan mitt virtuella nätverk och min lokala plats med hjälp av VPN för flera platser?
Ja, men du måste konfigurera BGP för båda tunnlarna till samma plats.
Uppfyller Azure VPN Gateway as-sökvägen för att påverka routningsbeslut mellan flera anslutningar till mina lokala platser?
Ja, Azure VPN Gateway respekterar den autonoma systemsökvägen (AS) som väntar för att fatta routningsbeslut när BGP är aktiverat. En kortare AS-sökväg föredras i BGP-sökvägen.
Kan jag använda egenskapen RoutingWeight när jag skapar en ny VPN VirtualNetworkGateway-anslutning?
Nej. En sådan inställning är reserverad för ExpressRoute-gatewayanslutningar. Om du vill påverka routningsbeslut mellan flera anslutningar måste du använda väntande AS-sökväg.
Kan jag använda punkt-till-plats-VPN med mitt virtuella nätverk med flera VPN-tunnlar?
Ja. Du kan använda punkt-till-plats-VPN med VPN-gatewayer som ansluter till flera lokala platser och andra virtuella nätverk.
Kan jag ansluta ett virtuellt nätverk med IPsec-VPN:er till min ExpressRoute-krets?
Ja, det stöds. Mer information finns i Konfigurera ExpressRoute- och plats-till-plats-samexisterande anslutningar.
IPsec/IKE-princip
Stöds en anpassad IPsec/IKE-princip på alla Azure VPN Gateway-SKU:er?
En anpassad IPsec/IKE-princip stöds på alla Azure VPN Gateway-SKU:er utom basic-SKU:n.
Hur många principer kan jag ställa in för en anslutning?
Du kan bara ange en principkombination för en anslutning.
Kan jag ange en partiell princip för en anslutning (till exempel endast IKE-algoritmer men inte IPsec)?
Nej, du måste ange alla algoritmer och parametrar för både IKE (huvudläge) och IPsec (snabbläge). Partiell principspecifikation tillåts inte.
Vilka algoritmer och viktiga styrkor stöder den anpassade principen?
I följande tabell visas de kryptografiska algoritmer och nyckelstyrkor som du kan konfigurera. Du måste välja ett alternativ för varje fält.
IPsec/IKEv2 | Alternativ |
---|---|
IKEv2-kryptering | GCMAES256, GCMAES128, AES256, AES192, AES128 |
IKEv2-integritet | SHA384, SHA256, SHA1, MD5 |
DH-grupp | DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None |
IPsec-kryptering | GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None |
IPsec-integritet | GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5 |
PFS-grupp | PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None |
Sa-livslängd för snabbläge | (Valfritt, standardvärden om det inte anges) Sekunder (heltal, minst 300, standard 27 000) Kilobyte (heltal; minst 1 024, standard 10 2400 000) |
Trafikväljare | UsePolicyBasedTrafficSelectors ($True eller $False , men valfritt; standard $False om det inte anges) |
DPD-timeout | Sekunder (heltal; minst 9, max 3 600, standard 45) |
Din lokala VPN-enhetskonfiguration måste matcha eller innehålla följande algoritmer och parametrar som du anger i Azure IPsec- eller IKE-principen:
- IKE-krypteringsalgoritm (huvudläge, fas 1)
- IKE-integritetsalgoritm (huvudläge, fas 1)
- DH-grupp (huvudläge, fas 1)
- IPsec-krypteringsalgoritm (snabbläge, fas 2)
- IPsec-integritetsalgoritm (snabbläge, fas 2)
- PFS-grupp (snabbläge, fas 2)
- Trafikväljare (om du använder
UsePolicyBasedTrafficSelectors
) - SA-livslängd (lokala specifikationer som inte behöver matcha)
Om du använder GCMAES för IPsec-krypteringsalgoritmen måste du välja samma GCMAES-algoritm och nyckellängd för IPsec-integritet. Använd till exempel GCMAES128 för båda.
I tabellen med algoritmer och nycklar:
- IKE motsvarar huvudläget eller fas 1.
- IPsec motsvarar snabbläge eller fas 2.
- DH-gruppen anger den Diffie-Hellman-grupp som används i huvudläget eller fas 1.
- PFS-gruppen anger gruppen Diffie-Hellman som används i snabbläge eller fas 2.
IKE Main Mode SA-livslängden är fast i 28 800 sekunder på Azure VPN-gatewayerna.
UsePolicyBasedTrafficSelectors
är en valfri parameter för anslutningen. Om du angerUsePolicyBasedTrafficSelectors
för$True
en anslutning konfigureras VPN-gatewayen för att ansluta till en lokal principbaserad VPN-brandvägg.Om du aktiverar
UsePolicyBasedTrafficSelectors
kontrollerar du att VPN-enheten har de matchande trafikväljarna definierade med alla kombinationer av prefixen för ditt lokala nätverk (lokal nätverksgateway) till eller från prefixen för det virtuella Azure-nätverket i stället för alla-till-alla. VPN-gatewayen accepterar den trafikväljare som den fjärranslutna VPN-gatewayen föreslår, oavsett vad som är konfigurerat på VPN-gatewayen.Om ditt prefix för det lokala nätverket är 10.1.0.0/16 och 10.2.0.0/16 och ditt prefix för det virtuella nätverket är 192.168.0.0/16 och 172.16.0.0/16, måste du ange följande trafik väljare:
- 10.1.0.0/16 <====> 192.168.0.0/16
- 10.1.0.0/16 <====> 172.16.0.0/16
- 10.2.0.0/16 <====> 192.168.0.0/16
- 10.2.0.0/16 <====> 172.16.0.0/16
Mer information om principbaserade trafikväljare finns i Ansluta en VPN-gateway till flera lokala principbaserade VPN-enheter.
Om tidsgränsen anges till kortare perioder blir IKE mer aggressivt nyckelfärdigt. Anslutningen kan sedan verka vara frånkopplad i vissa instanser. Den här situationen kanske inte är önskvärd om dina lokala platser ligger längre bort från Azure-regionen där VPN-gatewayen finns, eller om det fysiska länkvillkoret kan medföra paketförlust. Vi rekommenderar vanligtvis att du anger tidsgränsen till mellan 30 och 45 sekunder.
Mer information finns i Ansluta en VPN-gateway till flera lokala principbaserade VPN-enheter.
Vilka Diffie-Hellman-grupper stöder den anpassade principen?
I följande tabell visas motsvarande Diffie-Hellman-grupper som den anpassade principen stöder:
Diffie-Hellman-grupp | DHGroup | PFSGroup | Nyckellängd |
---|---|---|---|
1 | DHGroup1 | PFS1 | 768-bitars MODP |
2 | DHGroup2 | PFS2 | 1024-bitars MODP |
14 | DHGroup14 DHGroup2048 |
PFS2048 | 2048-bitars MODP |
19 | ECP256 | ECP256 | 256-bitars ECP |
20 | ECP384 | ECP384 | 384-bitars ECP |
24 | DHGroup24 | PFS24 | 2048-bitars MODP |
Mer information finns i RFC3526 och RFC5114.
Ersätter den anpassade principen standard-IPsec/IKE-principuppsättningar för VPN-gatewayer?
Ja. När du har angett en anpassad princip för en anslutning använder Azure VPN Gateway endast den principen på anslutningen, både som IKE-initierare och IKE-svarare.
Om jag tar bort en anpassad princip för IPsec/IKE, blir anslutningen mindre säker?
Nej, IPsec/IKE skyddar fortfarande anslutningen. När du tar bort den anpassade principen från en anslutning återgår VPN-gatewayen till standardlistan över IPsec/IKE-förslag och startar om IKE-handskakningen med din lokala VPN-enhet.
Kan det störa VPN-anslutningen att lägga till eller uppdatera en IPsec/IKE-princip?
Ja. Det kan orsaka ett litet avbrott (några sekunder) när VPN-gatewayen river ner den befintliga anslutningen och startar om IKE-handskakningen för att återupprätta IPsec-tunneln med de nya kryptografiska algoritmerna och parametrarna. Se till att din lokala VPN-enhet också är konfigurerad med matchande algoritmer och viktiga styrkor för att minimera störningarna.
Kan jag använda olika principer för olika anslutningar?
Ja. En anpassad princip tillämpas per anslutning. Du kan skapa och tillämpa olika IPsec/IKE-principer på olika anslutningar.
Du kan också välja att använda anpassade principer för en delmängd av anslutningar. Övriga principer använder de fördefinierade IPsec/IKE-principuppsättningarna i Azure.
Kan jag använda en anpassad princip för VNet-till-VNet-anslutningar?
Ja. Du kan tillämpa en anpassad princip på både IPsec-anslutningar mellan platser och VNet-till-VNet-anslutningar.
Behöver jag ange samma princip på båda resurserna för VNet-till-VNet-anslutningen?
Ja. En VNet-till-VNet-tunnel består av två anslutningsresurser i Azure, en för varje riktning. Kontrollera att båda anslutningsresurserna har samma princip. Annars upprättas inte VNet-till-VNet-anslutningen.
Vad är standardvärdet för DPD-timeout? Kan jag ange en annan DPD-tidsgräns?
Standardtimeouten för DPD är 45 sekunder på VPN-gatewayer. Du kan ange ett annat DPD-timeoutvärde för varje IPsec- eller VNet-till-VNet-anslutning, från 9 sekunder till 3 600 sekunder.
Kommentar
Om tidsgränsen anges till kortare perioder blir IKE mer aggressivt nyckelfärdigt. Anslutningen kan sedan verka vara frånkopplad i vissa instanser. Den här situationen kanske inte är önskvärd om dina lokala platser ligger längre bort från Azure-regionen där VPN-gatewayen finns, eller om det fysiska länkvillkoret kan medföra paketförlust. Vi rekommenderar vanligtvis att du anger tidsgränsen till mellan 30 och 45 sekunder.
Fungerar en anpassad IPsec/IKE-princip på ExpressRoute-anslutningar?
Nej. En IPsec/IKE-princip fungerar endast på S2S VPN- och VNet-till-VNet-anslutningar via VPN-gatewayerna.
Hur gör jag för att skapa anslutningar med protokolltypen IKEv1 eller IKEv2?
Du kan skapa IKEv1-anslutningar på alla routningsbaserade SKU:er av VPN-typ, förutom Basic SKU, Standard SKU och andra tidigare SKU:er.
Du kan ange en anslutningsprotokolltyp för IKEv1 eller IKEv2 när du skapar anslutningar. Om du inte anger någon anslutningsprotokolltyp används IKEv2 som standardalternativ där så är tillämpligt. Mer information finns i dokumentationen för Azure PowerShell-cmdleten .
Information om SKU-typer och stöd för IKEv1 och IKEv2 finns i Ansluta en VPN-gateway till flera lokala principbaserade VPN-enheter.
Tillåts överföring mellan IKEv1- och IKEv2-anslutningar?
Ja.
Kan jag ha IKEv1 plats-till-plats-anslutningar på Basic SKU för den routningsbaserade VPN-typen?
Nej. Basic SKU stöder inte den här konfigurationen.
Kan jag ändra anslutningsprotokolltypen när anslutningen har skapats (IKEv1 till IKEv2 och vice versa)?
Nej. När du har skapat anslutningen kan du inte ändra IKEv1- och IKEv2-protokoll. Du måste ta bort och återskapa en ny anslutning med önskad protokolltyp.
Varför återansluter min IKEv1-anslutning ofta?
Om din statiska routning eller routningsbaserade IKEv1-anslutning kopplas från med rutinmässiga intervall beror det förmodligen på att VPN-gatewayerna inte stöder nyckelåternycklar på plats. När huvudläget nyckelas om kopplas IKEv1-tunnlarna från och det tar upp till 5 sekunder att återansluta. Tidsgränsvärdet för main mode-förhandlingen avgör frekvensen för nyckelåterställningar. Om du vill förhindra dessa återanslutningar kan du växla till att använda IKEv2, som stöder på plats-nycklar.
Om anslutningen återansluter slumpmässigt följer du felsökningsguiden.
Var hittar jag mer information och steg för konfiguration?
Mer information finns i följande artiklar:
- Konfigurera anpassade IPsec/IKE-anslutningsprinciper för S2S VPN och VNet-till-VNet: Azure Portal
- Konfigurera anpassade IPsec-/IKE-anslutningsprinciper för S2S VPN eller VNet-till-VNet: PowerShell
BGP och routning
Stöds BGP på alla Azure VPN Gateway-SKU:er?
BGP stöds på alla Azure VPN Gateway-SKU:er utom basic-SKU:n.
Kan jag använda BGP med Azure Policy VPN-gatewayer?
Nej, BGP stöds endast på routningsbaserade VPN-gatewayer.
Vilka ASN:er kan jag använda?
Du kan använda dina egna offentliga autonoma systemnummer (ASN) eller privata ASN:er för både dina lokala nätverk och virtuella Azure-nätverk.
Du kan inte använda följande reserverade ASN:er:
Reserverad av Azure:
- Offentliga ASN:er: 8074, 8075, 12076
- Privata ASN:er: 65515, 65517, 65518, 65519, 65520
-
- 23456, 64496-64511, 65535-65551, 429496729
Du kan inte ange dessa ASN:er för dina lokala VPN-enheter när du ansluter till VPN-gatewayer.
Kan jag använda 32-bitars (4 byte) ASN?
Ja, Azure VPN Gateway har nu stöd för 32-bitars (4 byte) ASN. Om du vill konfigurera med hjälp av ASN i decimalformat använder du Azure PowerShell, Azure CLI eller Azure SDK.
Vilka privata ASN:er kan jag använda?
De användbara intervallen för privata ASN:er är:
- 64512-65514 och 65521-65534
Varken IANA eller Azure reserverar dessa ASN:er, så du kan tilldela dem till din VPN-gateway.
Vilken adress använder Azure VPN Gateway för BGP-peer-IP?
Som standard allokerar Azure VPN Gateway en enda IP-adress från GatewaySubnet
intervallet för VPN-gatewayer med aktivt vänteläge eller två IP-adresser för aktiva och aktiva VPN-gatewayer. Dessa adresser allokeras automatiskt när du skapar VPN-gatewayen.
Du hittar den allokerade BGP IP-adressen med hjälp av Azure PowerShell eller Azure Portal. I PowerShell använder du Get-AzVirtualNetworkGateway
och letar bgpPeeringAddress
efter egenskapen. I Azure Portal går du till sidan Gatewaykonfiguration och tittar under egenskapen Konfigurera BGP ASN.
Om dina lokala VPN-routrar använder IP-adresser för automatisk privat IP-adresser (APIPA) (169.254.x.x) som BGP IP-adresser måste du ange en eller flera Azure APIPA BGP IP-adresser på din VPN-gateway. Azure VPN Gateway väljer de APIPA-adresser som ska användas med den lokala APIPA BGP-peer som anges i den lokala nätverksgatewayen eller den privata IP-adressen för en lokal BGP-peer som inte är APIPA. Mer information finns i Konfigurera BGP för Azure VPN Gateway.
Vilka är kraven för BGP-peer-IP-adresserna på min VPN-enhet?
Din lokala BGP-peeradress får inte vara samma som vpn-enhetens offentliga IP-adress eller från VPN-gatewayens VNet-adressutrymme. Använd en annan IP-adress som BGP-peeradress på VPN-enheten. Det kan vara en adress som tilldelats loopback-gränssnittet på enheten (antingen en vanlig IP-adress eller en APIPA-adress).
Om enheten använder en APIPA-adress för BGP måste du ange en eller flera APIPA BGP IP-adresser på din VPN-gateway enligt beskrivningen i Konfigurera BGP för Azure VPN Gateway. Ange dessa adresser i motsvarande lokala nätverksgateway som representerar platsen.
Vad ska jag ange som adressprefix för den lokala nätverksgatewayen när jag använder BGP?
Viktigt!
Detta är en ändring från det tidigare dokumenterade kravet.
Azure VPN Gateway lägger till en värdväg internt till den lokala BGP-peer-IP-adressen via IPsec-tunneln. Lägg inte till vägen /32 i fältet Adressutrymme eftersom den är redundant. Om du använder en APIPA-adress som den lokala VPN-enhetens BGP-IP kan du inte lägga till den i det här fältet.
Om du lägger till andra prefix i fältet Adressutrymme läggs de till som statiska vägar på Azure VPN-gatewayen, utöver de vägar som har lärts via BGP.
Kan jag använda samma ASN för både lokala VPN-nätverk och virtuella Azure-nätverk?
Nej. Du måste tilldela olika ASN mellan dina lokala nätverk och dina virtuella Azure-nätverk om du ansluter dem tillsammans med BGP.
Azure VPN-gatewayer har ett standard-ASN på 65515 tilldelat, oavsett om BGP är aktiverat eller inte för din lokala anslutning. Du kan åsidosätta den här standardinställningen genom att tilldela ett annat ASN när du skapar VPN-gatewayen, eller så kan du ändra ASN när gatewayen har skapats. Du måste tilldela dina lokala ASN:er till motsvarande lokala Azure-nätverksgatewayer.
Vilka adressprefix annonserar Azure VPN-gatewayer till mig?
Gatewayerna annonserar följande vägar till dina lokala BGP-enheter:
- Dina VNet-adressprefixer
- Adressprefix för varje lokal nätverksgateway som är ansluten till VPN-gatewayen
- Vägar som har lärts från andra BGP-peeringsessioner som är anslutna till VPN-gatewayen, förutom standardvägen eller vägarna som överlappar alla virtuella nätverksprefix
Hur många prefix kan jag annonsera till Azure VPN Gateway?
Azure VPN Gateway stöder upp till 4 000 prefix. BGP-sessionen kommer att tas bort om antalet prefix överskrider gränsen.
Kan jag annonsera standardvägen (0.0.0.0/0) till VPN-gatewayer?
Ja. Tänk på att annonsering av standardvägen tvingar all VNet-utgående trafik mot din lokala webbplats. Det förhindrar också att virtuella nätverksdatorer accepterar offentlig kommunikation direkt från Internet, till exempel RDP (Remote Desktop Protocol) eller Secure Shell (SSH) från Internet till de virtuella datorerna.
Kan jag annonsera de exakta prefixen som mitt virtuella nätverksprefix?
Nej. Azure blockerar eller filtrerar annonsering av samma prefix som något av dina VNet-adressprefix. Du kan dock annonsera ett prefix som är en superuppsättning av det du har i ditt virtuella nätverk.
Om ditt virtuella nätverk till exempel använder adressutrymmet 10.0.0.0/16 kan du annonsera 10.0.0.0/8. Men du kan inte annonsera 10.0.0.0/16 eller 10.0.0.0/24.
Kan jag använda BGP med mina anslutningar mellan virtuella nätverk?
Ja. Du kan använda BGP för både lokala anslutningar och anslutningar mellan virtuella nätverk.
Kan jag blanda BGP- med icke-BGP-anslutningar för mina Azure VPN- gatewayer?
Ja, du kan blanda både BGP- och icke-BGP-anslutningar för samma Azure VPN-gateway.
Har Azure VPN Gateway stöd för BGP-överföringsroutning?
Ja. BGP-överföringsroutning stöds, med undantag för att VPN-gatewayer inte annonserar standardvägar till andra BGP-peer-datorer. Om du vill aktivera överföringsroutning över flera VPN-gatewayer måste du aktivera BGP på alla mellanliggande anslutningar mellan virtuella nätverk. Mer information finns i Om BGP och VPN Gateway.
Kan jag ha mer än en tunnel mellan en VPN-gateway och mitt lokala nätverk?
Ja, du kan upprätta mer än en PLATS-till-plats VPN-tunnel mellan en VPN-gateway och ditt lokala nätverk. Alla dessa tunnlar räknas mot det totala antalet tunnlar för dina Azure VPN-gatewayer och du måste aktivera BGP i båda tunnlarna.
Om du till exempel har två redundanta tunnlar mellan vpn-gatewayen och ett av dina lokala nätverk förbrukar de två tunnlar av den totala kvoten för din VPN-gateway.
Kan jag ha flera tunnlar mellan två virtuella Azure-nätverk med BGP?
Ja, men minst en av de virtuella nätverksgatewayerna måste vara i en aktiv-aktiv konfiguration.
Kan jag använda BGP för ett S2S VPN i en samexistenskonfiguration för Azure ExpressRoute och S2S VPN?
Ja.
Vad bör jag lägga till på min lokala VPN-enhet för BGP-peeringsessionen?
Lägg till en värdväg för Azure BGP-peer-IP-adressen på vpn-enheten. Den här vägen pekar på IPsec S2S VPN-tunneln.
Om Azure VPN-peer-IP till exempel är 10.12.255.30 lägger du till en värdväg för 10.12.255.30 med ett nästa hopp-gränssnitt för det matchande IPsec-tunnelgränssnittet på VPN-enheten.
Stöder den virtuella nätverksgatewayen BFD för S2S-anslutningar med BGP?
Nej. Bidirectional Forwarding Detection (BFD) är ett protokoll som du kan använda med BGP för att identifiera närliggande stilleståndstid snabbare än du kan med hjälp av standardintervall för BGP keepalive. BFD använder tidsinställda undersekunder som är utformade för att fungera i LAN-miljöer, men inte över offentliga Internet- eller WAN-anslutningar.
För anslutningar via det offentliga Internet är det inte ovanligt att vissa paket fördröjs eller till och med tas bort, så att introducera dessa aggressiva timers kan öka instabiliteten. Den här instabiliteten kan orsaka att BGP dämpar vägarna.
Som ett alternativ kan du konfigurera din lokala enhet med timers som är lägre än standardintervallet på 60 sekunder eller lägre än 180-sekunders hold-timern. Den här konfigurationen resulterar i en snabbare konvergenstid. Timers under standardintervallet på 60 sekunder för keepalive eller under standardtidsgränsen på 180 sekunder är dock inte tillförlitliga. Vi rekommenderar att du behåller timers vid eller över standardvärdena.
Initierar VPN-gatewayer BGP-peeringsessioner eller anslutningar?
VPN-gatewayer initierar BGP-peeringsessioner till de lokala BGP-peer-IP-adresserna som anges i de lokala nätverksgatewayresurserna med hjälp av de privata IP-adresserna på VPN-gatewayerna. Den här processen är oberoende av om de lokala BGP IP-adresserna finns i APIPA-intervallet eller är vanliga privata IP-adresser. Om dina lokala VPN-enheter använder APIPA-adresser som BGP IP måste du konfigurera BGP-högtalaren för att initiera anslutningarna.
Kan jag konfigurera tvingad tunneltrafik?
Ja. Se Konfigurera tvingad tunneltrafik.
NAT
Stöds NAT på alla Azure VPN Gateway-SKU:er?
NAT stöds på VpnGw2 till VpnGw25 och på VpnGw2AZ till VpnGw5AZ.
Kan jag använda NAT på VNet-till-VNet- eller P2S-anslutningar?
Nej.
Hur många NAT-regler kan jag använda på en VPN-gateway?
Du kan skapa upp till 100 NAT-regler (ingress- och utgående regler tillsammans) på en VPN-gateway.
Kan jag använda ett snedstreck (/) i ett NAT-regelnamn?
Nej. Du får ett felmeddelande.
Tillämpas NAT på alla anslutningar på en VPN-gateway?
NAT tillämpas på de anslutningar som har NAT-regler. Om en anslutning inte har någon NAT-regel börjar NAT inte gälla för anslutningen. På samma VPN-gateway kan du ha vissa anslutningar med NAT och andra anslutningar utan att NAT fungerar tillsammans.
Vilka typer av NAT stöder VPN-gatewayer?
VPN-gatewayer stöder endast statisk 1:1 NAT och dynamisk NAT. De stöder inte NAT64.
Fungerar NAT på aktiv-aktiva VPN-gatewayer?
Ja. NAT fungerar på både aktiva och aktiva VPN-gatewayer i vänteläge. Varje NAT-regel tillämpas på en enda instans av VPN-gatewayen. I aktiva-aktiva gatewayer skapar du en separat NAT-regel för varje gatewayinstans via fältet IP-konfigurations-ID .
Fungerar NAT med BGP-anslutningar?
Ja, du kan använda BGP med NAT. Här följer några viktiga överväganden:
För att säkerställa att inlärda vägar och annonserade vägar översätts till prefix efter NAT-adress (externa mappningar) baserat på NAT-reglerna som är associerade med anslutningarna väljer du Aktivera BGP-vägöversättning på konfigurationssidan för NAT-regler. De lokala BGP-routrarna måste annonsera de exakta prefixen enligt definitionen i IngressSNAT-reglerna .
Om den lokala VPN-routern använder en vanlig, icke-APIPA-adress och den kolliderar med VNet-adressutrymmet eller andra lokala nätverksutrymmen kontrollerar du att IngressSNAT-regeln översätter BGP-peer-IP till en unik, icke-överlappande adress. Placera adressen efter NAT i fältet BGP-peer-IP-adress i den lokala nätverksgatewayen.
NAT stöds inte med BGP APIPA-adresser.
Behöver jag skapa matchande DNAT-regler för SNAT-regeln?
Nej. En SNAT-regel (single source network address translation) definierar översättningen för båda riktningarna i ett visst nätverk:
En IngressSNAT-regel definierar översättningen av käll-IP-adresserna som kommer till VPN-gatewayen från det lokala nätverket. Den hanterar även översättningen av mål-IP-adresserna som lämnar från det virtuella nätverket till samma lokala nätverk.
En EgressSNAT-regel definierar översättningen av IP-adresserna för VNet-källan som lämnar VPN-gatewayen till lokala nätverk. Den hanterar också översättningen av mål-IP-adresserna för paket som kommer till det virtuella nätverket via de anslutningar som har EgressSNAT-regeln .
I båda fallen behöver du inte dnat-regler (målnätverksadressöversättning).
Vad gör jag om adressutrymmet för mitt virtuella nätverk eller min lokala nätverksgateway har två eller flera prefix? Kan jag använda NAT för alla eller bara en delmängd?
Du måste skapa en NAT-regel för varje prefix, eftersom varje NAT-regel bara kan innehålla ett adressprefix för NAT. Om adressutrymmet för den lokala nätverksgatewayen till exempel består av 10.0.1.0/24 och 10.0.2.0/25 kan du skapa två regler:
- IngressSNAT-regel 1: Mappa 10.0.1.0/24 till 192.168.1.0/24.
- IngressSNAT-regel 2: Mappa 10.0.2.0/25 till 192.168.2.0/25.
De två reglerna måste matcha prefixlängderna för motsvarande adressprefix. Samma riktlinje gäller för EgressSNAT-regler för VNet-adressutrymmet .
Viktigt!
Om du bara länkar en regel till den föregående anslutningen översätts inte det andra adressutrymmet.
Vilka IP-intervall kan jag använda för extern mappning?
Du kan använda alla lämpliga IP-intervall som du vill för extern mappning, inklusive offentliga och privata IP-adresser.
Kan jag använda olika EgressSNAT-regler för att översätta mitt VNet-adressutrymme till olika prefix för lokala nätverk?
Ja. Du kan skapa flera EgressSNAT-regler för samma VNet-adressutrymme och sedan tillämpa EgressSNAT-reglerna på olika anslutningar.
Kan jag använda samma IngressSNAT-regel för olika anslutningar?
Ja. Du använder vanligtvis samma IngressSNAT-regel när anslutningarna är för samma lokala nätverk för att tillhandahålla redundans. Du kan inte använda samma ingressregel om anslutningarna gäller för olika lokala nätverk.
Behöver jag både regler för ingress och utgående trafik på en NAT-anslutning?
Du behöver både ingångsregler och utgående regler för samma anslutning när det lokala nätverksadressutrymmet överlappar det virtuella nätverkets adressutrymme. Om det virtuella nätverkets adressutrymme är unikt för alla anslutna nätverk behöver du inte EgressSNAT-regeln för dessa anslutningar. Du kan använda ingångsreglerna för att undvika adress överlappning mellan de lokala nätverken.
Vad väljer jag som IP-konfigurations-ID?
IP-konfigurations-ID är bara namnet på det IP-konfigurationsobjekt som du vill att NAT-regeln ska använda. Med den här inställningen väljer du helt enkelt vilken gateway offentlig IP-adress som gäller för NAT-regeln. Om du inte har angett något anpassat namn när gatewayen skapas tilldelas gatewayens primära IP-adress till standard-IP-konfigurationen och den sekundära IP-adressen tilldelas till activeActive IP-konfigurationen.
Anslutning på flera platser och virtuella datorer
Om min virtuella dator finns i ett virtuellt nätverk och jag har en anslutning mellan flera platser, hur ansluter jag då till den virtuella datorn?
Om du har aktiverat RDP för din virtuella dator kan du ansluta till den genom att använda den privata IP-adressen. I så fall anger du den privata IP-adressen och porten som du vill ansluta till (vanligtvis 3389). Du måste konfigurera porten på den virtuella datorn för trafiken.
Du kan också ansluta till den virtuella datorn med en privat IP-adress från en annan virtuell dator som finns i samma virtuella nätverk. Du kan inte använda RDP till den virtuella datorn med hjälp av den privata IP-adressen om du ansluter från en plats utanför det virtuella nätverket. Om du till exempel har konfigurerat ett virtuellt punkt-till-plats-nätverk och inte upprättar någon anslutning från datorn kan du inte ansluta till den virtuella datorn med en privat IP-adress.
Om min virtuella dator finns i ett virtuellt nätverk med flera platsanslutningar, går då all trafik från min virtuella dator via den anslutningen?
Nej. Endast den trafik som har en mål-IP som finns i det virtuella nätverkets lokala nätverks-IP-adressintervall som du har angett går via den virtuella nätverksgatewayen.
Trafik som har en mål-IP som finns i det virtuella nätverket stannar i det virtuella nätverket. Annan trafik skickas via lastbalanseraren till de offentliga nätverken. Eller om du använder tvingad tunneltrafik skickas trafiken via VPN-gatewayen.
Hur felsöker jag en RDP-anslutning till en virtuell dator
Om du har problem med att ansluta till en virtuell dator via VPN-anslutningen kontrollerar du följande:
- Kontrollera att VPN-anslutningen har genomförts.
- Kontrollera att du ansluter till den virtuella datorns privata IP-adress.
- Om du kan ansluta till den virtuella datorn med hjälp av den privata IP-adressen men inte datornamnet kontrollerar du att du har konfigurerat DNS korrekt. Mer information om hur namnmatchning fungerar för virtuella datorer finns i Namnmatchning för resurser i virtuella Azure-nätverk.
När du ansluter över punkt-till-plats kontrollerar du följande ytterligare objekt:
- Använd
ipconfig
för att kontrollera den IPv4-adress som tilldelats Ethernet-adaptern på datorn som du ansluter från. Om IP-adressen ligger inom adressintervallet för det virtuella nätverk som du ansluter till, eller inom adressintervallet för VPN-klientadresspoolen, är det ett överlappande adressutrymme. När adressutrymmet överlappar på det här sättet når inte nätverkstrafiken Azure. Den finns kvar i det lokala nätverket. - Kontrollera att VPN-klientkonfigurationspaketet genererades efter att du angett DNS-serverns IP-adresser för det virtuella nätverket. Om du uppdaterade IP-adresserna för DNS-servern skapar och installerar du ett nytt paket för VPN-klientkonfiguration.
Mer information om att felsöka en RDP-anslutning finns i Felsöka fjärrskrivbordsanslutningar till en virtuell dator.
Kundkontrollerat gatewayunderhåll
Vilka tjänster ingår i underhållskonfigurationen för network gateways-omfånget?
Omfånget Nätverksgatewayer innehåller gatewayresurser i nätverkstjänster. Det finns fyra typer av resurser i omfånget Nätverksgatewayer:
- Virtuell nätverksgateway i ExpressRoute-tjänsten
- Virtuell nätverksgateway i VPN Gateway-tjänsten
- VPN-gateway (plats-till-plats) i Azure Virtual WAN-tjänsten
- ExpressRoute-gateway i Virtual WAN-tjänsten
Vilket underhåll stöder kundkontrollerat underhåll?
Azure-tjänster genomgår regelbundna underhållsuppdateringar för att förbättra funktioner, tillförlitlighet, prestanda och säkerhet. När du har konfigurerat en underhållsperiod för dina resurser utförs underhåll av gästoperativsystem och serviceunderhåll under det fönstret. Kundkontrollerat underhåll omfattar inte värduppdateringar (utöver till exempel värduppdateringar för Power) och kritiska säkerhetsuppdateringar.
Kan jag få ett avancerat meddelande om underhållet?
För närvarande kan du inte få avancerade meddelanden om underhåll av Network Gateway-resurser.
Kan jag konfigurera en underhållsperiod som är kortare än fem timmar?
För närvarande måste du konfigurera minst ett femtimmarsfönster i önskad tidszon.
Kan jag konfigurera ett annat underhållsfönster än ett dagligt schema?
För närvarande måste du konfigurera ett dagligt underhållsperiod.
Finns det fall där jag inte kan kontrollera vissa uppdateringar?
Kundkontrollerat underhåll stöder uppdateringar av gästoperativsystem och tjänster. De här uppdateringarna står för de flesta underhållsobjekt som orsakar problem för kunderna. Vissa andra typer av uppdateringar, inklusive värduppdateringar, ligger utanför omfånget för kundkontrollerat underhåll.
Om ett säkerhetsproblem med hög allvarlighetsgrad kan äventyra kunderna kan Azure behöva åsidosätta kundkontroll över underhållsfönstret och push-överföra en ändring. Dessa ändringar är sällsynta förekomster som vi endast använder i extrema fall.
Måste underhållskonfigurationsresurser finnas i samma region som gatewayresursen?
Ja.
Vilka gateway-SKU:er kan jag konfigurera för att använda kundkontrollerat underhåll?
Alla Azure VPN Gateway-SKU:er (förutom Basic SKU) kan konfigureras för att använda kundkontrollerat underhåll.
Hur lång tid tar det innan en underhållskonfigurationsprincip börjar gälla när den har tilldelats till gatewayresursen?
Det kan ta upp till 24 timmar innan Nätverksgatewayer följer underhållsschemat när underhållsprincipen är associerad med gatewayresursen.
Finns det några begränsningar för att använda kundkontrollerat underhåll baserat på den offentliga IP-adressen för Basic SKU?
Ja. Kundkontrollerat underhåll fungerar inte för resurser som använder offentliga IP-adresser för Grundläggande SKU, förutom vid tjänstuppdateringar. För dessa gatewayer följer inte underhåll av gästoperativsystem det kundkontrollerade underhållsschemat på grund av infrastrukturbegränsningar.
Hur ska jag planera underhållsperioder när jag använder VPN och ExpressRoute i ett samexistensscenario?
När du arbetar med VPN och ExpressRoute i ett samexistensscenario eller när du har resurser som fungerar som säkerhetskopior rekommenderar vi att du konfigurerar separata underhållsperioder. Den här metoden säkerställer att underhåll inte påverkar dina säkerhetskopieringsresurser samtidigt.
Jag har schemalagt ett underhållsperiod för ett framtida datum för en av mina resurser. Pausas underhållsaktiviteter på den här resursen tills dess?
Nej, underhållsaktiviteter pausas inte på resursen under perioden före det schemalagda underhållsfönstret. Under de dagar som inte omfattas av underhållsschemat fortsätter underhållet som vanligt på resursen.
Hur gör jag för att ta reda på mer om kundkontrollerat gatewayunderhåll?
Mer information finns i artikeln Konfigurera kundkontrollerat gatewayunderhåll för VPN Gateway .
Relaterat innehåll
- Mer information om VPN Gateway finns i Vad är Azure VPN Gateway?.
- Mer information om konfigurationsinställningar för VPN Gateway finns i Om konfigurationsinställningar för VPN Gateway.
"OpenVPN" är ett varumärke som tillhör OpenVPN Inc.