Windows és strongSwan titkosítások: a megfelelő réteget illessze

Mindkét vég AES-128-at mond, és az alagút mégsem hajlandó felépülni. A CBC és a GCM különböző transzformációk, amelyek véletlenül ugyanazt a kulcshosszt osztják, és az egyiket kínáló kliens nem elégíti ki azt az átjárót, amely csak a másikat fogadja el. Az AES szó egy családot ír le, nem megállapodást.

Van egy második tengely is, és éppen az okozza a zavaró hibákat.

Két réteg, két független lista

Az IKE magát a tárgyalást védi, míg a gyermek-asszociáció az Ön számára igazán fontos forgalmat védi. A Windows az elsőt titkosítási módszerként és integritási módszerként, a másodikat titkosítási és hitelesítési transzformációs konstansként teszi elérhetővé. Ezek a mezők nem egymás álnevei, és az egyikben érvényes érték a másikban értelmetlen vagy hibás lehet. Ha ezzel a felosztással olvassa a profilt, a zavar nagy része eltűnik.

A gyakorlati következmény az, hogy lehet teljesen elfogadható kulcscsere-szabályzata és olyan adatcsatorna-szabályzata, amelyet a partner nem fogad el. Az egyik lista tárgyal; a másik csomagokat véd. Az elsőben egy érték megváltoztatása nincs hatással a másodikra, bármennyire hasonlónak is tűnik a kettő egy konfigurációs párbeszédablakban.

Írja le mindkét listát, mielőtt összehasonlítja őket az átjáróval. A memóriából végzett összehasonlítás az, amikor egy mezőt kétszer szerkesztenek, a másikat pedig soha. Tartsa nyitva az átjáró konzolját a profil mellett.

Olvassa el a hibát a javaslatok mellett

A sikertelen szakasz megmondja, melyik listát kell vizsgálni. A kezdeti kulcscsere során történő elutasítás IKE-javaslati probléma, és még azelőtt történik, hogy bármilyen gyermek-asszociáció létezne. A védett forgalom asszociációjának tárgyalása közbeni hiba ESP-javaslati probléma, és a kulcscsere már sikerült. Az ügyfél általános szabályzat-egyezési üzenete egyik szakaszt sem nevezi meg, ezért az átjáró saját nézete a hasznos.

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

Hasonlítsa össze a kapott javaslatot, a konfigurált javaslatot és a kiválasztottat ehhez az egyetlen kísérlethez. Itt három különböző lista számít, és csak az utolsó írja le, hogy valójában mit használtak. Idézze szó szerint a jegyben, ahelyett hogy összefoglalná.

Tartsa a CBC-t és a GCM-et külön alternatívaként

Annak az átjárónak, amelynek szándékosan engedélyezett bármelyik család elfogadása, két javaslatra van szüksége, nem egyre. A strongSwanban vessző választja el az alternatívákat, és kötőjel kapcsolja össze egyetlen készlet összetevőit. Mindkét család kötőjelekkel való kombinálása egyetlen lehetetlen javaslatot eredményez két elfogadható helyett.

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

Az első alternatíva hitelesített titkosítást hordoz, és továbbra is megnevez egy pszeudovéletlen függvényt, mert a kulcslevezetésnek szüksége van egyre akkor is, ha az integritás a titkosításból származik. A második alternatíva klasszikus titkosítás külön integritás-algoritmussal. Mindkettő attól függ, mit támogat a betöltött kripto-implementáció.

Az ESP-javaslat nem átnevezett IKE-javaslat

A titkosítási token mindkét listában azonosnak tűnik, és szinte semmi más nem öröklődik. Az ESP-javaslatnak nincs kulcscsere-pszeudovéletlen függvénye, integritási és előremeneti titoktartási követelményeit pedig a másik oldali Windows-szabályzattal szemben indokolják, nem az IKE-sorból másolják. Egyik lista mechanikus átfordítása a másikba olyat eredményez, ami érvényesül, de soha nem tárgyal.

Válasszon egy irányt, és maradjon benne. Vagy az átjáró csak GCM-szabályzatot tart, és az ügyfél teljes kompatibilis szabályzatot telepít, vagy az átjáró mindkét családot elfogadja, és az ügyfél megtartja a meglévő készletét. A biztonsági szabályzat által tiltott tartalék engedélyezése nem javítás, bármilyen gyorsan is tünteti el a hibát.

Ellenőrizze mindkét készletet, majd egy kulcsfrissítést

Erősítse meg külön a kiválasztott kulcscsere-készletet és a kiválasztott forgalmi készletet, mert különböző listákból származnak, és egymástól függetlenül is sikerülhetnek. Ezután engedjen végbemenni egy kulcsfrissítést, és azt is erősítse meg. Egy működő első kézfogás és egy sikertelen kulcsfrissítés olyan javaslatkészletet ír le, amely csak részben elfogadható.

Őrizze meg ezt a bizonyítékot a változtatással együtt. Az ismétlődő kapcsolatbontáshoz saját sikertelen csere-rekord kell, mielőtt bárki egy időzítőt vagy platformhibát okolna.