От strongSwan към AWS Site-to-Site: защо Child SA не избира нищо

IKE тунелът може да е вдигнат, докато дъщерната асоциация изключва вашите подмрежи. Първо сравнете локалния и отдалечения CIDR в AWS с leftsubnet и rightsubnet.

Конзолата показва състояние up, strongSwan отчита установена IKE асоциация, а пакетите все още не пристигат. Следващото, което трябва да сравните, не е предварително споделеният ключ, а двойката префикси, които всяка страна смята, че тунелът защитава. Преминете проверките по-долу по ред, защото първите две решават дали тунелът изобщо може да носи вашия трафик.

Преведете имената на AWS на езика на strongSwan

AWS описва връзката от страната на клиента: адресът на клиентския шлюз и локалният CIDR са ваши, а отдалеченият CIDR принадлежи на VPC. strongSwan нарича двата края left и right, като вашият префикс е в leftsubnet, а префиксът на VPC — в rightsubnet. Обръщането на една двойка създава тунел, който договаря и избира грешния трафик.

Изтеглете конфигурацията, която AWS генерира за връзката, и я използвайте като образец точно за тази връзка, включително адресите на тунела и префиксите. Ако оставите и двете CIDR полета празни при създаването, услугата използва стойност по подразбиране 0.0.0.0/0 от всяка страна. Маршрутизатор, конфигуриран с тесен префикс, тогава никога няма да съвпадне, затова или попълнете полетата, или умишлено разширете селектора.

Несъответствието тук изглежда като отказ на маршрутизацията, но не е.

Фиксирайте адреса, който AWS действително вижда

Маршрутизатор зад NAT може да изпраща IKE от интерфейс, за който отсрещната страна никога не е научила. Адресът на шлюза, записан в AWS, трябва да е този, който AWS наблюдава в мрежата, и маршрутизаторът трябва да бъде фиксиран към същия локален адрес, вместо да следва маршрута си по подразбиране.

conn %default
    local_addrs = 203.0.113.10

В strongSwan local_addrs избира адреса на източника за IKE, а по-старите конфигурации на OpenSwan изписват същата идея като left. Насочете го към интерфейса с публичния адрес, след което проверете на самото NAT устройство, че UDP 500 и 4500 достигат до този хост, защото правило, останало от предишен маршрутизатор, ги отхвърля безшумно. Правилната двойка селектори с грешен адрес на източника пак се проваля, а журналът ще обвини предложението. Това подвеждане е причината адресът на източника да заслужава отделна проверка.

Потвърдете правилото за препращане, вместо да го предполагате, защото правило, което е било правилно за предишния маршрутизатор, често остава.

Разглеждайте фаза 1 и фаза 2 поотделно

AWS показва опциите за IKE и ESP като отделни списъци. Набор IKE, който и двете страни приемат, не казва нищо за предложението за ESP, защото двата списъка са независими. Прочетете и двата от генерираната конфигурация и ги сравнете един по един.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Синтаксисът не се пренася между реализациите. Двойка, която работи в OpenSwan, например phase2alg=aes_gcm с ike=aes256-sha1;modp1024, трябва да се преведе във формата esp= и ike= на strongSwan, а имената на алгоритмите се различават. Тъй като GCM удостоверява, докато криптира, той не се нуждае от отделна трансформация за цялост, за разлика от набор CBC, сдвоен със SHA. Ред за фаза 2, поставен от един демон в друг без превод, дава отказ, който изглежда като несъответствие на селекторите.

Проверявайте дъщерната асоциация, а не индикатора на тунела

Ако връзката се зареди, но дъщерна асоциация не се появи, значи предложението или селекторите са отхвърлени. Ако дъщерна асоциация се появи, но селекторите ѝ изключват вашите префикси, пакетите се филтрират, преди да стигнат до тунела. Индикаторът на конзолата покрива само нивото IKE, така че не може да ви каже кое от двете се е случило.

ipsec statusall

Потърсете дъщерната асоциация за сигурност и прочетете селекторите за трафик, отпечатани до нея, след което ги сравнете с префиксите от генерираната конфигурация.

Тествайте от хост в локалния префикс към хост в префикса на VPC и проверете обратния път, както и всяка група за сигурност или мрежов ACL от страната на AWS. Правилните селектори не предпазват пакета от по-късно отхвърляне.

Когато все още не работи след съвпадение на селекторите

Потвърдете, че маршрутът от двете страни сочи към тунела, след което потвърдете, че NAT устройството не пренаписва трафика по начин, който политиката не очаква. Тунелът, базиран на политика, съпоставя адресите на пакетите, така че транслация, приложена след решението на политиката, променя резултата.

Запишете един пакет на входа и един на изхода от всяка страна, преди да промените друго предложение.

Запишете селекторите, предложенията за фаза 1 и фаза 2 и адреса на източника в тикета. Тези четири стойности обясняват повечето откази site-to-site без обаждане.

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