Om kryptografiska krav och Azure VPN-gatewayer
I den här artikeln beskrivs hur du kan konfigurera Azure VPN-gatewayer för att uppfylla dina kryptografiska krav för både lokala S2S VPN-tunnlar och VNet-till-VNet-anslutningar i Azure.
Om IKEv1- och IKEv2 för Azure VPN-anslutningar
Traditionellt tillät vi endast IKEv1-anslutningar för Grundläggande SKU:er och tillåtna IKEv2-anslutningar för alla VPN-gateway-SKU:er förutom Grundläggande SKU:er. De grundläggande SKU:erna tillåter endast 1 anslutning och tillsammans med andra begränsningar, till exempel prestanda, hade kunder som använder äldre enheter som endast stöder IKEv1-protokoll begränsad erfarenhet. För att förbättra upplevelsen för kunder som använder IKEv1-protokoll tillåter vi nu IKEv1-anslutningar för alla VPN-gateway-SKU:er, förutom Basic SKU. Mer information finns i VPN Gateway-SKU:er. Observera att VPN-gatewayer som använder IKEv1 kan uppleva tunnelåteranslutningar under huvudlägesnycklar.
När IKEv1- och IKEv2-anslutningar tillämpas på samma VPN-gateway kan överföringen mellan dessa två anslutningar aktiveras automatiskt.
Om IPsec- och IKE-principparametrar för Azure VPN-gatewayer
IPsec- och IKE-protokollstandarden stöder en mängd olika kryptografiska algoritmer i olika kombinationer. Om du inte begär en specifik kombination av kryptografiska algoritmer och parametrar använder Azure VPN-gatewayer en uppsättning standardförslag. Standardprincipuppsättningarna valdes för att maximera samverkan med ett brett utbud av VPN-enheter från tredje part i standardkonfigurationer. Därför kan principerna och antalet förslag inte omfatta alla möjliga kombinationer av tillgängliga kryptografiska algoritmer och viktiga styrkor.
Standardprincip
Standardprincipuppsättningen för Azure VPN-gateway visas i artikeln: Om VPN-enheter och IPsec/IKE-parametrar för VPN Gateway-anslutningar från plats till plats.
Krav för kryptografi
För kommunikation som kräver specifika kryptografiska algoritmer eller parametrar, vanligtvis på grund av efterlevnads- eller säkerhetskrav, kan du nu konfigurera deras Azure VPN-gatewayer så att de använder en anpassad IPsec/IKE-princip med specifika kryptografiska algoritmer och viktiga styrkor, i stället för Azures standardprincipuppsättningar.
IKEv2-huvudlägesprinciperna för Azure VPN-gatewayer använder till exempel endast Diffie-Hellman Group 2 (1 024 bitar), medan du kan behöva ange starkare grupper som ska användas i IKE. till exempel Grupp 14 (2048-bitars), Grupp 24 (2048-bitars MODP-grupp) eller ECP (elliptiska kurvgrupper) 256 eller 384 bitar (grupp 19 och grupp 20, respektive). Liknande krav gäller även för IPsec-snabblägesprinciper.
Anpassad IPsec/IKE-princip med Azure VPN-gatewayer
Azure VPN-gatewayer stöder nu en anpassad IPsec/IKE-princip per anslutning. För en plats-till-plats- eller VNet-till-VNet-anslutning kan du välja en specifik kombination av kryptografiska algoritmer för IPsec och IKE med önskad nyckelstyrka, som du ser i följande exempel:
Du kan skapa en IPsec/IKE-princip och tillämpa på en ny eller befintlig anslutning.
Arbetsflöde
- Skapa virtuella nätverk, VPN-gatewayer eller lokala nätverksgatewayer för din anslutningstopologi enligt beskrivningen i andra instruktioner.
- Skapa en IPsec/IKE-princip.
- Du kan tillämpa principen när du skapar en S2S- eller VNet-till-VNet-anslutning.
- Om anslutningen redan har skapats kan du tillämpa eller uppdatera principen till en befintlig anslutning.
Vanliga frågor och svar om IPsec/IKE-principer
Stöds anpassade IPsec/IKE-principer på alla Azure VPN Gateway-SKU: er?
Anpassad IPsec/IKE-princip stöds på alla Azure-SKU:er utom Basic SKU.
Hur många principer kan jag ställa in för en anslutning?
Du kan bara ange en principkombination för en viss anslutning.
Kan jag ange en partiell princip på 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 är de algoritmer och viktiga fördelar som stöds i 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 Integrity | 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 Integrity | GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5 |
| PFS-grupp | PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None |
| QM SA-livstid | (Valfritt: standardvärden används om de inte anges) Sekunder (heltal. min. 300/standard 27 000 sekunder) Kilobyte (heltal. min. 1024/standard 102400000 kilobyte) |
| Trafikväljare | UsePolicyBasedTrafficSelectors** ($True/$False; Valfritt, standard $False om det inte anges) |
| DPD-timeout | Sekunder (heltal: min. 9/max. 3600; standard 45 sekunder) |
Din lokala konfiguration för VPN-enheten måste stämma överens med eller innehålla följande algoritmer och parametrar som du anger på Azure IPsec/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 UsePolicyBasedTrafficSelectors används)
- SA-livslängden är endast lokala specifikationer och behöver inte matchas.
Om GCMAES används som för IPsec Encryption-algoritmen måste du välja samma GCMAES-algoritm och nyckellängd för IPsec-integritet. till exempel att använda GCMAES128 för båda.
I tabellen 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 angav den Diffie-Hellman-grupp 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 ställer in UsePolicyBasedTrafficSelectors på $True på en anslutning konfigureras Azure VPN-gatewayen så att den ansluter till en principbaserad VPN-brandvägg lokalt. Om du aktiverar PolicyBasedTrafficSelectors måste du se till att VPN-enheten har de matchande trafikväljarna definierade med alla kombinationer av dina lokala nätverksprefix (lokal nätverksgateway) till/från prefixen för virtuella Azure-nätverk i stället för valfria. Azure VPN-gatewayen accepterar den trafikväljare som föreslås av den fjärranslutna VPN-gatewayen oavsett vad som är konfigurerat på Azure 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 Anslut flera lokala principbaserade VPN-enheter.
DPD-timeout – standardvärdet är 45 sekunder på Azure VPN-gatewayer. Om tidsgränsen anges till kortare perioder blir IKE mer aggressivt nyckelfärdigt, vilket gör att anslutningen verkar vara frånkopplad i vissa instanser. Detta kanske inte är önskvärt om dina lokala platser ligger längre bort från Den Azure-region där VPN-gatewayen finns, eller om det fysiska länkvillkoret kan medföra paketförlust. Den allmänna rekommendationen är att ange tidsgränsen mellan 30 och 45 sekunder.
Mer information finns i avsnittet Connect multiple on-premises policy-based VPN devices (Ansluta flera lokala principbaserade VPN-enheter).
Vilka Diffie-Hellman-grupper stöds?
I följande tabell visas motsvarande Diffie-Hellman-grupper som stöds av den anpassade principen:
| 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 |
Se RFC3526 och RFC5114 för mer information.
Ersätter den anpassade principen standardprincipuppsättningar för IPsec/IKE för Azure VPN-gatewayer?
Ja, när en anpassad princip har angetts på en anslutning kommer Azure VPN-gatewayen bara använda principen på anslutningen, både som IKE-initierare och IKE-responder.
Om jag tar bort en anpassad princip för IPsec/IKE, blir anslutningen mindre säker?
Nej, anslutningen kommer att skyddas av IPsec/IKE. När du tar bort den anpassade principen från en anslutning återgår Azure VPN-gatewayen till standardlistan med 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 uppstå ett kort avbrott (några sekunder) när Azure VPN-gatewayen bryter den befintliga anslutningen och startar om IKE-handskakningen för att återupprätta IPsec-tunneln med de nya krypteringsalgoritmerna och parametrarna. Kontrollera att din lokala VPN-enhet har konfigurerats med matchande algoritmer och nyckellängder för att minimera avbrottet.
Kan jag använda olika principer för olika anslutningar?
Ja. Anpassade principer tillämpats på per-anslutningbasis. 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 den anpassade principen på VNet-till-VNet-anslutningen?
Ja, du kan använda anpassade principen på både IPSec-anslutningar mellan lokala anslutningar eller 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 anslutningen mellan de virtuella nätverken.
Vad är standardvärdet för DPD-timeout? Kan jag ange en annan DPD-tidsgräns?
Standardtidsgränsen för DPD är 45 sekunder. 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
Standardvärdet är 45 sekunder på Azure VPN-gatewayer. Om tidsgränsen anges till kortare perioder blir IKE mer aggressivt nyckelfärdigt, vilket gör att anslutningen verkar vara frånkopplad i vissa instanser. Detta kanske inte är önskvärt om dina lokala platser ligger längre bort från Den Azure-region där VPN-gatewayen finns, eller när det fysiska länkvillkoret kan medföra paketförlust. Den allmänna rekommendationen är att ange tidsgränsen mellan 30 och 45 sekunder.
Fungerar en anpassad IPsec/IKE-princip på ExpressRoute-anslutningen?
Nej. IPSec-/ princip fungerar bara på S2S VPN- och VNet-till-VNet-anslutningar via Azure VPN-gatewayer.
Hur gör jag för att skapa anslutningar med protokolltypen IKEv1 eller IKEv2?
IKEv1-anslutningar kan skapas på alla RouteBased VPN-typ-SKU:er, förutom Basic SKU, Standard SKU och andra äldre 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 PowerShell-cmdlet-dokumentationen. För SKU-typer och IKEv1/IKEv2-stöd, se Anslut gatewayer till principbaserade VPN-enheter.
Tillåts överföring mellan IKEv1- och IKEv2-anslutningar?
Ja. Överföring mellan IKEv1- och IKEv2-anslutningar stöds.
Kan jag ha IKEv1-plats-till-plats-anslutningar på grundläggande SKU:er av routningsbaserad VPN-typ?
Nej. Basic SKU stöder inte detta.
Kan jag ändra anslutningsprotokolltypen när anslutningen har skapats (IKEv1 till IKEv2 och vice versa)?
Nej. När anslutningen har skapats kan inte IKEv1/IKEv2-protokoll ändras. Du måste ta bort och återskapa en ny anslutning med önskad protokolltyp.
Varför återansluter min IKEv1-anslutning ofta?
Om din statiska routnings- eller routningsbaserade IKEv1-anslutning kopplas från med rutinintervall beror det sannolikt på att VPN-gatewayer inte stöder på plats-nycklar. När huvudläget är på nytt anslutet kopplas IKEv1-tunnlarna från och det tar upp till 5 sekunder att återansluta. Tidsgränsvärdet för förhandling i huvudläget 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 återansluts slumpmässigt följer du vår felsökningsguide.
Var hittar jag konfigurationsinformation och -steg?
Mer information och konfigurationssteg finns i följande artiklar.
- Konfigurera IPsec/IKE-princip för S2S- eller VNet-till-VNet-anslutningar – Azure-portalen
- Konfigurera IPsec/IKE-princip för S2S- eller VNet-till-VNet-anslutningar – Azure PowerShell
Nästa steg
Mer information om alternativet UsePolicyBasedTrafficSelectors finns i Anslut flera principbaserade VPN-enheter.