Някой ви изпраща изискване, в което пише IKEv2, ESP и MODP3072, а в конзолата няма поле с такова име. Грешката е да тръгнете да търсите такова поле. IKEv2 е версия за договаряне, ESP е протоколът, който пренася защитения ви трафик, а MODP3072 е група за обмен на ключове, тоест група 15 на IANA. Тези три факта живеят на три различни места и групата се появява два пъти.

Фразата не е една единствена настройка

Превърнете изискването в списъци с опции, преди да пипате каквото и да е. Таблицата по-долу е цялото съответствие.

Agreed requirementAWS option to reviewStill a separate decision
IKEv2Allowed IKE versionsEncryption, integrity, key-exchange choices
MODP3072 for the IKE exchangePhase 1 DH groups, group 15Phase 2 key-exchange and PFS policy
MODP3072 for the protected-traffic exchangePhase 2 DH groups, group 15The initial IKE exchange group
A named encryption algorithmThat phase's encryption listIntegrity and DH-group agreement

MODP3072 е група 15 и AWS в момента приема 15 и в двата списъка с DH групи за Phase 1 и Phase 2. Приемането ѝ на двете места не е същото като изискването ѝ на двете места и със сигурност не означава, че партньорът ви е имал предвид и двете.

Phase 1 и Phase 2 договарят различни неща

Phase 1 изгражда асоциацията за сигурност на IKE: как двата шлюза се удостоверяват, се съгласяват за ключове и защитават собствения си разговор. Phase 2 изгражда CHILD SA, който пренася реалния ви трафик, и неговият обмен на ключове може да е нов, а не наследен.

Това разделение е причината думите на партньора за perfect forward secrecy да имат значение. PFS е свойство на Phase 2 и група в списъка на Phase 1 не го осигурява. Попитайте за кой обмен се отнася всяко изискване, както и за режима на криптиране, дали целостта се осигурява от AEAD шифър и какви са очакванията за подмяна на ключове от двете страни.

Не извеждайте пълен приемлив набор от думата AES или от едно число на DH. Политика, сглобена от две половини на два разговора, е начинът, по който един тунел започва да предлага нещо, за което нито един екип не се е съгласил.

Разрешеният списък не е резултат от договаряне

Списъците с опции описват какво е готова да приеме всяка страна. Те не съобщават какво е избрано. Прочетете действително избраните предложения за IKE и CHILD-SA за ново свързване, после потвърдете, че изискването е изпълнено, а не просто разрешено. Силна опция в списък доказва само, че е била налична.

Следете и подновяването. Първият CHILD SA на IKEv2 и по-късен CHILD обмен с PFS могат да покажат различни условия за съвместимост, защото вторият обмен създава нов ключов материал с участващата PFS група. Ако тестът ви за приемане покрива само първата минута от тунела, той не е тествал частта, която е важна за партньора ви.

Справочникът за опции на тунела в AWS изброява Phase 1 и Phase 2 независимо и точно тази структура си струва да се усвои, преди да пристигне следващото изискване.

Променете тунела, който наистина имате предвид

Връзката Site-to-Site VPN има два тунела със собствени опции и собствено състояние. Преди да прегледате или редактирате нещо, съпоставете външния адрес на тунела в AWS с партньора от страна на шлюза за клиента и не предполагайте, че едно запазване обновява и двете.

Одобрената промяна изисква страната на шлюза за клиента да е подготвена за същата политика и прозорец за прекъсването, което ще понесе избраният тунел. Ако партньорът не е готов за група 15 във фазата, която променяте, тунелът просто ще спре да се вдига и конзолата няма да ви каже коя страна е отказала.

Запишете договорената политика като фаза, версия на протокола, криптиране, цялост и DH група, после я потвърдете при обмените, които тя трябва да защитава. Маршрутизирането, селекторите за трафик и разрешенията на приложенията остават отделно; това съпоставяне не е пълна конфигурация на шлюза и не е препоръка да включвате допълнителни алгоритми за разнообразие.

Подобни статии