Windows- och strongSwan-chiffer: matcha rätt lager

Båda ändarna säger AES-128 och tunneln vägrar fortfarande att byggas. CBC och GCM är olika transformationer som råkar dela samma nyckellängd, och en klient som erbjuder den ena uppfyller inte en gateway som bara accepterar den andra. Ordet AES beskriver en familj, inte en överenskommelse.

Det finns också en andra axel, och det är den som ger de förvirrande felen.

Två lager, två oberoende listor

IKE skyddar själva förhandlingen, medan den underordnade associationen skyddar trafiken du faktiskt bryr dig om. Windows exponerar den första som en krypteringsmetod och en integritetsmetod, och den andra som chiffer- och autentiseringstransformationskonstanter. Fälten är inte alias för varandra, och ett värde som är giltigt i det ena kan vara meningslöst eller fel i det andra. Att läsa profilen med den uppdelningen i tankarna tar bort det mesta av förvirringen.

Den praktiska konsekvensen är att du kan ha en helt acceptabel nyckelutbytespolicy och en datakanalpolicy som motparten inte accepterar. En lista förhandlar; den andra skyddar paket. Att ändra ett värde i den första har ingen effekt på den andra, hur lika de två än ser ut i en konfigurationsdialog.

Skriv ner båda listorna innan du jämför dem med gatewayen. En jämförelse ur minnet är hur ett fält redigeras två gånger och det andra aldrig. Håll gateway-konsolen öppen bredvid profilen.

Läs felet bredvid förslagen

Steget som misslyckades berättar vilken lista du ska undersöka. En avvisning under det inledande nyckelutbytet är ett IKE-förslagsproblem, och det inträffar innan någon underordnad association finns. Ett fel medan associationen för skyddad trafik förhandlas är ett ESP-förslagsproblem, och nyckelutbytet har redan lyckats. Ett generiskt policymatchmeddelande från klienten namnger ingen av stegen, därför är gatewayens egen bild den användbara.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Jämför förslaget som togs emot, förslaget som konfigurerats och det som valdes för det enda försöket. Tre olika listor spelar roll här, och bara den sista beskriver vad som faktiskt användes. Citera det ordagrant i ärendet i stället för att sammanfatta det.

Håll CBC och GCM som separata alternativ

En gateway som medvetet tillåts acceptera vilken som helst av familjerna behöver två förslag, inte ett. I strongSwan skiljer ett kommatecken alternativ, och ett bindestreck binder samman komponenterna i ett enda set. Att kombinera båda familjerna med bindestreck ger ett omöjligt förslag i stället för två acceptabla.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

Det första alternativet bär autentiserad kryptering och namnger fortfarande en pseudoslumpfunktion, eftersom nyckelhärledning behöver en även när integriteten kommer från chiffret. Det andra alternativet är klassisk kryptering med en separat integritetsalgoritm. Båda är fortfarande beroende av vad den inlästa kryptoimplementeringen stöder.

Ett ESP-förslag är inte ett omdöpt IKE-förslag

Chiffer-token ser identisk ut i båda listorna, och nästan inget annat överförs. Ett ESP-förslag har ingen pseudoslumpfunktion för nyckelutbyte, och dess krav på integritet och framåtsekretess argumenteras mot Windows-policyn på andra sidan i stället för att kopieras från IKE-raden. Att mekaniskt översätta den ena listan till den andra ger något som validerar och aldrig förhandlar.

Välj en riktning och håll dig till den. Antingen behåller gatewayen en policy med bara GCM och klienten distribuerar en fullständigt kompatibel policy, eller så accepterar gatewayen båda familjerna och klienten behåller sitt befintliga set. Att aktivera en reserv som säkerhetspolicyn förbjuder är ingen åtgärd, hur snabbt det än rensar felet.

Verifiera båda seten, sedan en nyckelförnyelse

Bekräfta det valda nyckelutbytessetet och det valda trafiksetet separat, eftersom de kommer från olika listor och kan lyckas oberoende. Låt sedan en nyckelförnyelse ske och bekräfta den också. Ett första handskakning som fungerar och en nyckelförnyelse som misslyckas beskriver ett förslagsset som bara är delvis acceptabelt.

Spara beviset tillsammans med ändringen. En återkommande frånkoppling behöver sin egen registrering av misslyckat utbyte innan någon skyller på en timer eller ett plattformsfel.