Windows og strongSwan-chifre: match det rigtige lag

Begge ender siger AES-128, og tunnelen nægter stadig at blive opbygget. CBC og GCM er forskellige transformationer, som tilfældigvis deler samme nøglelængde, og en klient, der tilbyder den ene, opfylder ikke en gateway, der kun accepterer den anden. Ordet AES beskriver en familie, ikke en aftale.

Der er også en anden akse, og det er den, der giver forvirrende fejl.

To lag, to uafhængige lister

IKE beskytter selve forhandlingen, mens den underordnede association beskytter den trafik, du faktisk bekymrer dig om. Windows eksponerer den første som en krypteringsmetode og en integritetsmetode, og den anden som chiffer- og autentificeringstransformationskonstanter. De felter er ikke aliaser for hinanden, og en værdi, der er gyldig i den ene, kan være meningsløs eller forkert i den anden. At læse profilen med den opdeling i tankerne fjerner det meste af forvirringen.

Den praktiske konsekvens er, at du kan have en helt acceptabel nøgleudvekslingspolitik og en datakanalpolitik, som modparten ikke vil acceptere. Den ene liste forhandler; den anden beskytter pakker. Ændring af en værdi i den første har ingen effekt på den anden, hvor ens de to end måtte se ud i en konfigurationsdialog.

Skriv begge lister ned, før du sammenligner dem med gatewayen. En sammenligning udført fra hukommelsen er, hvordan ét felt bliver redigeret to gange, og det andet aldrig. Hold gateway-konsollen åben ved siden af profilen.

Læs fejlen ved siden af forslagene

Det trin, der fejlede, fortæller dig, hvilken liste du skal undersøge. En afvisning under den indledende nøgleudveksling er et IKE-forslagsproblem, og det sker, før der findes nogen underordnet association. En fejl, mens den beskyttede trafikassociation forhandles, er et ESP-forslagsproblem, og nøgleudvekslingen er allerede lykkedes. En generisk politikmatch-meddelelse fra klienten navngiver ingen af trinnene, og derfor er gatewayens eget syn det nyttige.

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

Sammenlign det modtagne forslag, det konfigurerede forslag og det valgte for det ene forsøg. Tre forskellige lister betyder noget her, og kun den sidste beskriver, hvad der faktisk blev brugt. Citér den ordret i billetten i stedet for at opsummere den.

Hold CBC og GCM som separate alternativer

En gateway, der bevidst har lov til at acceptere hvilken som helst af familierne, har brug for to forslag, ikke ét. I strongSwan adskiller et komma alternativer, og en bindestreg forbinder komponenterne i et enkelt sæt. At kombinere begge familier med bindestreger giver ét umuligt forslag i stedet for to acceptable.

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

Det første alternativ bærer autentificeret kryptering og navngiver stadig en pseudorandomfunktion, fordi nøgleafledning har brug for en, selv når integriteten kommer fra chifferen. Det andet alternativ er klassisk kryptering med en separat integritetsalgoritme. Begge er fortsat underlagt, hvad den indlæste kryptoimplementering understøtter.

Et ESP-forslag er ikke et omdøbt IKE-forslag

Chiffer-tokenet ser identisk ud i begge lister, og næsten intet andet overføres. Et ESP-forslag har ingen pseudorandomfunktion til nøgleudveksling, og dets integritets- og forward-secrecy-krav argumenteres mod Windows-politikken på den anden side i stedet for at blive kopieret fra IKE-linjen. At oversætte den ene liste mekanisk til den anden giver noget, der validerer og aldrig forhandler.

Vælg en retning, og bliv i den. Enten beholder gatewayen en politik med kun GCM, og klienten udruller en komplet kompatibel politik, eller også accepterer gatewayen begge familier, og klienten beholder sit eksisterende sæt. At aktivere et fallback, som sikkerhedspolitikken forbyder, er ikke en rettelse, hvor hurtigt det end rydder fejlen.

Bekræft begge sæt, derefter en nøglefornyelse

Bekræft det valgte nøgleudvekslingssæt og det valgte trafiksæt hver for sig, fordi de kommer fra forskellige lister og kan lykkes uafhængigt. Lad derefter en nøglefornyelse finde sted, og bekræft den også. Et første håndtryk, der virker, og en nøglefornyelse, der fejler, beskriver et forslagssæt, der kun er delvist acceptabelt.

Opbevar det bevis sammen med ændringen. En tilbagevendende afbrydelse har brug for sin egen registrering af mislykket udveksling, før nogen bebrejder en timer eller en platformfejl.