Windows och strongSwan: att matcha de fyra transforms som ingår i ett IKE-förslag

Båda parterna stöder AES, båda accepterar SHA-256, och tunneln kommer ändå inte upp. Förslaget misslyckades på en komponent som ingen jämförde, vanligtvis nyckelutbytesgruppen. Den här runbooken läser det faktiska utbytet innan något ändras, tillämpar en enda avgränsad policy och lämnar en återställning som återställer de tidigare parametrarna.

Läs felet innan du ändrar en grupp

Ett »policy-matchningsfel« är en sammanfattning, inte en diagnos. Det betyder att inget ömsesidigt godtagbart förslag hittades, och det säger ingenting om vilken komponent som avvisades. Behandla det som början på utredningen och inte som bevis om en viss grupp.

Svaret finns oftast på serversidan. En strongSwan-logg på rätt nivå listar förslaget den tog emot från klienten och förslaget den är konfigurerad att acceptera, och skillnaden mellan de två listorna namnger komponenten som misslyckades.

Anta inte att klienten erbjuder det ett äldre foruminlägg säger. Den aktiva profilen och dess installerade policy avgör listan som erbjuds, och en uppdaterad Windows-build kan erbjuda en annan uppsättning än den i skärmbilden du kopierar från.

Skriv ned båda listorna. Fyra transformpositioner och en grupp är en kort lista, och att jämföra den rad för rad tar kortare tid än något experiment. Fyra positioner är lätta att hålla i sikte. En loggfil är det inte.

Jämför varje transform, inte ett enda välbekant namn

Ett IKE-förslag är en uppsättning val som alla måste stämma. Kryptering skyddar förhandlingen, integritet eller en PRF autentiserar den, och en Diffie-Hellman-grupp etablerar färskt nyckelmaterial. Ett förslag som stämmer på de två första och avviker på den tredje är fortfarande oacceptabelt för båda parterna.

De två Windows-fält som förväxlas här hör till olika faser. DHGroup gäller IKE-nyckelutbytet, medan PfsGroup gäller den underordnade association som skyddar trafiken. Att ändra det andra kan inte reparera ett fel i det första.

Gruppnamnen skiljer sig mellan implementationer, och det är en separat källa till förvirring. strongSwan skriver modp2048 och ecp256, medan Windows använder uppräkningsnamn som Group14 och ECP256, så en jämförelse måste översätta innan den jämför. Håll en tvåkolumnsanteckning med båda namnen. Nästa avvikelse klassas då på sekunder.

Tillämpa en enda fullständig och avgränsad policy

Det stödda verktyget för en inbyggd IKEv2-profil är en IPsec-policy per anslutning, satt som ett enda objekt i stället för fält för fält. Förhandsgranska den först, tillämpa den sedan, och behåll de tidigare parametrarna i ändringsregistret.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

Bytet -WhatIf förhandsgranskar den lokala ändringen och tillämpar ingenting. Det är användbart och samtidigt en vanlig fälla, eftersom en förhandsgranskning bara bevisar att parametrarna är syntaktiskt acceptabla för den lokala cmdleten. Den säger ingenting om huruvida gatewayen accepterar det resulterande förslaget.

Justera också omfattningen medan du är där. En anslutning i lagret för alla användare behöver motsvarande parameter för alla användare, och att redigera profilen per användare med samma visningsnamn ändrar ett annat objekt som tunneln inte använder.

Ställ sedan in strongSwan-sidan på samma uppsättning före testet. En samordnad ändring i båda ändar är den enda versionen av detta som konvergerar; att ändra en sida och försöka igen och igen ger en logg full av samma avvisning.

Verifiera utbytet och nyckelförnyelsen var för sig

En lyckad anslutning är en observation, och nyckelförnyelsen är en annan. Den inledande IKE-förhandlingen använder en uppsättning parametrar, och den underordnade association som bär trafiken kan senare förhandlas om med sin egen policy. En uppsättning som ansluter och sedan faller efter ett tag är vanligtvis det andra fallet.

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

Det första kommandot visar serverns syn på de etablerade associationerna, inklusive den underordnade SA och dess återstående livstid. Det andra visar vad klientprofilen nu innehåller, och det är det enda sättet att bekräfta att policyn du satte är den policy som gäller.

Följ en fullständig nyckelförnyelse innan du förklarar framgång. Det betyder att låta anslutningen vara uppe tillräckligt länge för att den underordnade associationen ska bytas ut, och sedan bekräfta att trafiken fortsätter. De flesta policyavvikelser gömmer sig i det steget, eftersom den inledande förhandlingen kan lyckas med en uppsättning som förnyelsen inte accepterar.

Återställning är den tidigare parameteruppsättningen, inte ett eftergivligt reservval. Om klienten bara erbjöd en svag gammal grupp är svaret att förbättra den gemensamma policyn för klient och server, inte att lägga till den gruppen på gatewayen där varje framtida part kan förhandla ned sig till den.

Notera de fyra parametrarna, gruppen, anslutningens omfattning och resultatet av nyckelförnyelsen. Det är en kort anteckning, och den är skillnaden mellan en runbook och en historia om den gången tunneln kom upp.