Windows og strongSwan-chiffer: treff rett lag

Begge endar seier AES-128, og tunnelen nektar framleis å byggjast. CBC og GCM er ulike transformasjonar som tilfeldigvis deler same nøkkellengd, og ein klient som tilbyr den eine, tilfredsstiller ikkje ein gateway som berre godtek den andre. Ordet AES skildrar ein familie, ikkje ein avtale.

Det finst òg ein andre akse, og det er den som gir forvirrande feil.

To lag, to uavhengige lister

IKE vernar sjølve forhandlinga, medan den underordna assosiasjonen vernar trafikken du faktisk bryr deg om. Windows eksponerer den første som ein krypteringsmetode og ein integritetsmetode, og den andre som chiffer- og autentiseringstransformasjonskonstantar. Desse felta er ikkje alias for kvarandre, og ein verdi som er gyldig i den eine, kan vere meiningslaus eller feil i den andre. Å lese profilen med denne delinga i tankane fjernar det meste av forvirringa.

Den praktiske konsekvensen er at du kan ha ein heilt akseptabel nøkkelutvekslingspolitikk og ein datakanalpolitikk som motparten ikkje vil godta. Den eine lista forhandlar; den andre vernar pakkar. Å endre ein verdi i den første har ingen effekt på den andre, uansett kor like dei to ser ut i ein konfigurasjonsdialog.

Skriv ned begge listene før du samanliknar dei med gatewayen. Ei samanlikning frå minnet er korleis eitt felt blir redigert to gonger og det andre aldri. Hald gateway-konsollen open ved sida av profilen.

Les feilen ved sida av forslaga

Trinnet som feila, fortel deg kva liste du skal undersøkje. Ei avvising under den innleiande nøkkelutvekslinga er eit IKE-forslagsproblem, og det skjer før nokon underordna assosiasjon finst. Ein feil medan assosiasjonen for verna trafikk blir forhandla, er eit ESP-forslagsproblem, og nøkkelutvekslinga har alt lukkast. Ei generisk policytreffmelding frå klienten nemner ingen av trinna, difor er gatewayen sitt eige syn det nyttige.

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

Samanlikn forslaget som vart motteke, forslaget som er konfigurert og det som vart valt for det eine forsøket. Tre ulike lister betyr noko her, og berre den siste skildrar kva som faktisk vart brukt. Siter det ordrett i saka i staden for å oppsummere det.

Hald CBC og GCM som separate alternativ

Ein gateway som medvite er tillaten å godta kva som helst av familiane, treng to forslag, ikkje eitt. I strongSwan skil eit komma alternativ, og ein bindestrek knyter saman komponentane i eitt enkelt sett. Å kombinere begge familiane med bindestrekar gir eitt umogleg forslag i staden for to akseptable.

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

Det første alternativet ber autentisert kryptering og nemner framleis ein pseudorandomfunksjon, fordi nøkkelavleiing treng ein sjølv når integriteten kjem frå chifferen. Det andre alternativet er klassisk kryptering med ein separat integritetsalgoritme. Begge er framleis avhengige av kva den innlasta kryptoimplementasjonen støttar.

Eit ESP-forslag er ikkje eit omdøypt IKE-forslag

Chiffer-tokenet ser identisk ut i begge listene, og nesten ingenting anna blir overført. Eit ESP-forslag har ingen pseudorandomfunksjon for nøkkelutveksling, og krava til integritet og forward secrecy blir argumenterte mot Windows-politikken på den andre sida i staden for å bli kopierte frå IKE-linja. Å omsetje den eine lista mekanisk til den andre gir noko som validerer og aldri forhandlar.

Vel ein retning og bli i den. Anten held gatewayen ein politikk med berre GCM og klienten rullar ut ein fullstendig kompatibel politikk, eller så godtek gatewayen begge familiane og klienten held på settet sitt. Å slå på ein reserve som tryggingspolitikken forbyr, er ikkje ei retting, uansett kor raskt det fjernar feilen.

Stadfest begge setta, deretter ein nøkkelnygenerering

Stadfest det valde nøkkelutvekslingssettet og det valde trafikksettet kvar for seg, fordi dei kjem frå ulike lister og kan lukkast uavhengig. La deretter ein nøkkelnygenerering skje og stadfest den òg. Eit første handtrykk som verkar og ein nøkkelnygenerering som feilar, skildrar eit forslagssett som berre er delvis akseptabelt.

Oppbevar beviset saman med endringa. Ei tilbakevendande fråkobling treng si eiga registrering av mislukka utveksling før nokon klandrar ein timer eller ein plattformfeil.