Planera IKEv2-inställningar som passar fler än en klient

En fungerande profil på ett skrivbord är ett lyckat test av en klient. Det är ingen plattformsöverskridande utrullning, och behandlar man den som det får man det välkända supportmönstret: Windows ansluter, telefonen misslyckas i identitetskontrollen och den hanterade bärbara datorn återansluter varje gång den vaknar. Skillnaderna är verkliga och till stor del förutsägbara, därför bör planen vara en matris och inte en skärmbild.

Bestäm identitetskontraktet först

Dokumentera serveridentiteten, certifikattilliten och metoden för klientautentisering innan ni diskuterar algoritmer. Dessa tre avgör om en klient alls kan autentisera sig, och det är delarna som plattformarna uttrycker olika.

Kontrollera hur varje plattform namnger den förväntade identifieraren och hur den hanterar alternativa subjektnamn. En profil som accepterar ett servernamn på en klient kan avvisa samma certifikat på en annan eftersom identifierarfältet fylls från ett annat värde.

Välj sedan det kryptografiska snittet

Jämför de förslag som varje stödd klient kan erbjuda och välj ett modernt snitt som gatewayen också tillåter. Aktivera inte en överdimensionerad gammal lista bara för att en gammal enhet ska ansluta, för den listan blir gatewayens standard för alla som följer. Skriv ner varför varje gammalt alternativ fortfarande finns. Om ingen kan namnge enheten som behöver det är det inte ett krav.

Håll IKE- och CHILD-inställningar åtskilda i planen. Ett förslag som är acceptabelt för IKE-utbytet är inte automatiskt acceptabelt för skyddad trafik, och de två förhandlas separat. En gateway som accepterar ett förslag i ett lager kan fortfarande avvisa det i det andra, och loggen visar ett fel som ser ut som om det första lagret lyckades.

Tillhandahåll autentiseringsuppgifter via en verifierad process och håll ett användarlösenord, en delad hemlighet och en privat klientnyckel i egna fält. Försök och misstag på liknande namngivna lådor är vägen som gör ett fungerande test till ett som inte går att återskapa.

Testa livscykeln, inte det stabila tillståndet

För varje klient, testa den första autentiseringen, den avsedda applikationen, DNS-uppslagning och täckning av adressfamiljer. Öva sedan delarna som bara dyker upp senare: förnyelse, sömn och en vanlig nätverksändring.

MOBIKE-stöd och beteende vid återautentisering kan skilja sig från det stabila resultatet du just mätte. Registrera händelsen och associationens tillstånd vid det tillfället, inte bara om gränssnittet till slut ser anslutet ut.

Definiera vad direkt trafik får göra medan VPN inte är tillgängligt. Det är ett policybeslut skilt från om klienten återansluter, och de flesta utrullningar svarar på den andra frågan medan de ignorerar den första. Skriv svaret i utrullningsanteckningarna bredvid profilnamnen. Någon kommer att behöva det under ett avbrott och har inte tid att rekonstruera det.

Använd serveridentitetskontroller när en plattform inte håller med

När en profil fungerar på en plattform och en annan avvisar dess namn, jämför den identifierare som klienten faktiskt skickade med de identifierare som certifikatet bär. Den jämförelsen löser de flesta av dessa fall snabbare än att ändra chifferslistor.

Behåll den testade matrisen tillsammans med konfigurationskällan och uppdateringsproceduren. När stödet för en gammal klient upphör, ta bort dess undantag medvetet i stället för att lämna svagare kompatibilitetsinställningar gömda i gatewayen för nästa revision. strongSwans IKEv2-dokumentation är en användbar referens för hur utbytena konfigureras.