Шифри на Windows и strongSwan: усогласете го вистинскиот слој
Истата должина на клучот не е компатибилен сет. Одделете ја IKE политиката од ESP трансформациите и држете ги CBC и GCM во различни предлози.
Двете страни велат AES-128, а тунелот и понатаму одбива да се изгради. CBC и GCM се различни трансформации што случајно делат иста должина на клуч, а клиент што нуди едната не задоволува портал што прифаќа само другата. Зборот AES опишува семејство, а не договор.
Има и втора оска, и токму таа ги создава збунувачките грешки.
Два слоја, две независни листи
IKE ја штити самата преговарачка постапка, додека детската асоцијација го штити сообраќајот што навистина ви е важен. Windows првата ја изложува како метод за шифрирање и метод за интегритет, а втората како константи за трансформација на шифра и автентикација. Тие полиња не се прекари едно на друго, и вредност валидна во едното може да биде бесмислена или погрешна во другото. Читањето на профилот со оваа поделба на ум го отстранува најголемиот дел од збунетоста.
Практичната последица е што можете да имате сосема прифатлива политика за размена на клучеви и политика за податочен канал што партнерот нема да ја прифати. Едната листа преговара; другата штити пакети. Промената на вредност во првата нема ефект врз втората, колку и да изгледаат слично двете во дијалог за конфигурација.
Запишете ги двете листи пред да ги споредите со порталот. Споредбата од меморија е начинот на кој едно поле се уредува двапати, а другото никогаш. Држете ја конзолата на порталот отворена до профилот.
Прочитајте ја грешката до предлозите
Фазата што не успеа ви кажува која листа да ја проверите. Одбивање за време на почетната размена на клучеви е проблем со IKE предлог, и се случува пред да постои каква било детска асоцијација. Неуспех додека се преговара асоцијацијата за заштитен сообраќај е проблем со ESP предлог, а размената на клучеви веќе успеа. Општата порака за совпаѓање на политиката од клиентот не именува ниту една од двете фази, затоа сопствениот поглед на порталот е корисниот.
swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager
Споредете го примениот предлог, конфигурираниот предлог и избраниот за тој единствен обид. Овде се важни три различни листи, и само последната опишува што навистина се користело. Цитирајте го во билетот дословно наместо да го сумирате.
Држете ги CBC и GCM како одделни алтернативи
Портал на кој намерно му е дозволено да прифати кое било семејство бара два предлога, а не еден. Во strongSwan запирката ги одделува алтернативите, а цртичката ги поврзува компонентите на еден сет. Комбинирањето на двете семејства со цртички дава еден невозможен предлог наместо два прифатливи.
proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256
Првата алтернатива носи автентифицирано шифрирање и понатаму именува псевдослучајна функција, бидејќи изведувањето на клучот бара една дури и кога интегритетот доаѓа од шифрата. Втората алтернатива е класично шифрирање со одделен алгоритам за интегритет. Двете остануваат зависни од тоа што го поддржува вчитаната крипто имплементација.
ESP предлогот не е преименуван IKE предлог
Токенот за шифра изгледа идентично во двете листи, и речиси ништо друго не се пренесува. ESP предлогот нема псевдослучајна функција за размена на клучеви, а неговите барања за интегритет и идна тајност се аргументираат против политиката на Windows од другата страна наместо да се копираат од линијата IKE. Механичкото преведување на едната листа во другата создава нешто што се валидира и никогаш не преговара.
Изберете насока и останете во неа. Или порталот задржува политика само со GCM и клиентот распоредува целосна компатибилна политика, или порталот ги прифаќа двете семејства и клиентот го задржува својот постоечки сет. Вклучувањето резервна опција што ја забранува безбедносната политика не е поправка, колку и брзо да ја отстрани грешката.
Проверете ги двата сета, потоа обнова на клучот
Потврдете го избраниот сет за размена на клучеви и избраниот сет за сообраќај одделно, бидејќи доаѓаат од различни листи и можат да успеат независно. Потоа оставете да се случи обнова на клучот и потврдете ја и неа. Првото ракување што работи и обновата на клучот што не успева опишуваат сет од предлози што е само делумно прифатлив.
Зачувајте го тој доказ со промената. Повторливото прекинување на врската бара свој запис за неуспешна размена пред некој да обвини тајмер или дефект на платформата.