Windows og strongSwan IKE-forslag: at matche fire transformationer
En fælles cipher er ikke nok, når parterne er uenige om nøgleudvekslingsgruppen. Sammenlign alle fire transformationer, og anvend derefter én afgrænset profilpolitik.
To parter understøtter begge AES, accepterer begge SHA-256, og tunnelen kommer stadig ikke op. Forslaget fejlede på en komponent, som ingen sammenlignede, normalt nøgleudvekslingsgruppen. Denne kørebog læser den faktiske udveksling, før noget ændres, anvender én afgrænset politik og efterlader en tilbagerulning, der gendanner de tidligere parametre.
Læs fejlen, før du ændrer en gruppe
En »politikmatchfejl« er et resumé, ikke en diagnose. Den betyder, at der ikke blev fundet et gensidigt acceptabelt forslag, og den siger intet om, hvilken komponent der blev afvist. Behandl den som begyndelsen på undersøgelsen og ikke som bevis for en bestemt gruppe.
Svaret findes normalt på serversiden. En strongSwan-log på et passende niveau viser det forslag, den modtog fra klienten, og det forslag, den er konfigureret til at acceptere, og forskellen mellem de to lister navngiver den komponent, der fejlede.
Antag ikke, at klienten tilbyder det, et ældre forumindlæg siger, den tilbyder. Den aktive profil og dens installerede politik bestemmer den tilbudte liste, og et opdateret Windows-build kan tilbyde et andet sæt end det i det skærmbillede, du kopierer fra.
Skriv begge lister ned. Fire transformationspositioner og én gruppe er en kort liste, og at sammenligne den linje for linje tager kortere tid end ethvert eksperiment. Fire positioner er nemme at holde øje med. En logfil er ikke.
Sammenlign hver transformation, ikke ét velkendt navn
Et IKE-forslag er et sæt valg, som alle skal matche. Kryptering beskytter forhandlingen, integritet eller en PRF autentificerer den, og en Diffie-Hellman-gruppe etablerer friskt nøglemateriale. Et forslag, der matcher på de to første og afviger på den tredje, er stadig uacceptabelt for begge parter.
De to Windows-felter, der forveksles her, hører til forskellige faser. DHGroup gælder IKE-nøgleudveksling, mens PfsGroup gælder den underordnede association, der beskytter trafikken. At ændre det andet kan ikke reparere en fejl i det første.
Gruppenavne er forskellige mellem implementeringer, og det er en separat kilde til forvirring. strongSwan skriver modp2048 og ecp256, mens Windows bruger optællingsnavne som Group14 og ECP256, så en sammenligning skal oversætte, før den sammenligner. Hold en to-kolonne note med begge navne. Den næste uoverensstemmelse tager så sekunder at klassificere.
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
Anvend én komplet, afgrænset politik
Det understøttede værktøj til en indbygget IKEv2-profil er en IPsec-politik per forbindelse, sat som ét objekt i stedet for felt for felt. Se den først, anvend den derefter, og behold de tidligere parametre i ændringsregistret.
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIfSkifteren -WhatIf forhåndsviser den lokale ændring og anvender intet. Det er nyttigt og også en almindelig fælde, fordi en forhåndsvisning kun beviser, at parametrene er syntaktisk acceptable for den lokale cmdlet. Den siger intet om, hvorvidt gatewayen accepterer det resulterende forslag.
Tilpas også omfanget, mens du er i gang. En forbindelse i alle-bruger-lageret har brug for den tilsvarende alle-bruger-parameter, og redigering af profil-per-bruger med samme viste navn ændrer et andet objekt, som tunnelen ikke bruger.
Justér derefter strongSwan-siden til samme sæt, før du tester. En koordineret ændring i begge ender er den eneste version af dette, der konvergerer; at ændre den ene side og prøve igen og igen giver en log fuld af den samme afvisning.
Verificér udvekslingen og nøglefornyelsen hver for sig
En vellykket forbindelse er én observation, og nøglefornyelsen er en anden. Den indledende IKE-forhandling bruger ét sæt parametre, og den underordnede association, der bærer trafikken, kan senere genforhandles med sin egen politik. En opsætning, der forbinder og derefter falder efter et stykke tid, er normalt det andet tilfælde.
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *Den første kommando viser serverens syn på de etablerede associationer, inklusive den underordnede SA og dens resterende levetid. Den anden viser, hvad klientprofilen nu indeholder, og det er den eneste måde at bekræfte, at den politik, du satte, er den politik, der gælder.
Overvåg en fuld nøglefornyelse, før du erklærer succes. Det betyder at lade forbindelsen være oppe længe nok til, at den underordnede association udskiftes, og derefter bekræfte, at trafikken fortsætter. De fleste politikmismatch skjuler sig i det trin, fordi den indledende forhandling kan lykkes med et sæt, som fornyelsen ikke accepterer.
Tilbagerulning er det forrige parametersæt, ikke en eftergivende fallback. Hvis klienten kun tilbød en svag ældre gruppe, er svaret at forbedre den fælles politik for klient og server, ikke at føje den gruppe til gatewayen, hvor hver fremtidig part kan forhandle ned til den.
Noter de fire parametre, gruppen, forbindelsens omfang og resultatet af nøglefornyelsen. Det er en kort note, og det er forskellen mellem en kørebog og en historie om dengang, tunnelen kom op.