NEGOTIATION_FAILURE на тунел Cloud VPN с Cisco ASA от отсрещната страна почти винаги е разминаване в предложението или в селекторите, и първият полезен факт е, че никаква редакция няма да го поправи. Cloud VPN фиксира предложението IKE при създаването на обекта на тунела. Няма поле за смяна на алгоритъм на място, затова поправката е изтриване и повторно създаване с записана начална точка. Третирайте го като преизграждане и работата се превръща в контролен списък, а не в следобед на догадки.

Прочетете отказа, преди да изтриете каквото и да е

Отказът при договаряне е проблем на фаза и журналът на партньора обикновено посочва фазата. Провал на фаза 1 означава, че страните не са се разбрали за предложение или не са се удостоверили взаимно. Провал на фаза 2 означава, че тунелът е вдигнат, а защитените селектори не съвпадат. Това са различни поправки и редът от журнала си струва да бъде изваден, преди някой да пипне конфигурация.

Отказът също така изключва неща. Това не е маршрут във VPC, не е правило на защитна стена на интерфейса на тунела и не е повреда в разрешаването на имена вътре в мрежата. Преследването им дава уверени промени, които не могат да променят резултата, и правят окончателната поправка по-трудна за приписване.

Запишете и двете конфигурации, докато още съществуват

Изтриването на тунел отнема половин минута и унищожава единственото доказателство, което сте имали. Преди това запишете локалните и отдалечените селектори, адреса на партньора, кой държи споделената тайна и crypto map или профила IKEv2 на ASA. ASA отговаря на два отделни въпроса: какво е конфигурирано и какво е вдигнато в момента:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

От страна на Google четете обекта на тунела, а не обобщението в конзолата, защото адресът на партньора и полетата на селекторите са стойностите, които трябва да възпроизведете точно:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

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

Алгоритмите, за които едната страна отказва да договаря

Cloud VPN не избира от набор алгоритми IKEv1 както традиционният партньор. Настройките на партньора, които очаква, са фиксирани: aes-cbc-128 за криптиране, sha1-96 за цялост и за PRF, Diffie-Hellman група 2, 36,600 секунди за фаза 1 и 10,800 секунди за фаза 2. Политиката на ASA трябва да предложи точно този набор. Второ предложение на ASA не вреди, стига съвпадащото също да е в списъка.

IKEv2 дава на двете страни повече свобода, но правилата запазват същата форма: включете PFS, изберете DH група, която тунелът поддържа, и дръжте списъка с предложения достатъчно кратък, за да е очевидно разминаването. Партньор ASA при Cloud VPN означава и статично маршрутизиране, затова защитените префикси трябва да се планират и изброят, а не да се оставят на BGP.

Време на живот, копирано от шаблон на друг доставчик, е обичайният грешен завой тук. Google публикува тези стойности като изискуеми настройки на партньора, затова ги задайте; по-кратка стойност не се договаря нагоре до това, което иска ASA.

Изтрийте, създайте отново и изчистете старото състояние

Изтрийте тунела, не шлюза, и запишете името, което Cloud VPN дава на замяната, защото имената се присвояват, а не се използват повторно. Създайте го отново със записаните стойности и същия адрес на партньора, после добавете съвпадащото предложение в списъка с политики на ASA.

Изчистете асоциациите за сигурност след промяната на ASA и преди да прочетете резултата. ASA може да продължи да предлага остаряла политика, докато текущата SA изтече, затова правилна конфигурация изглежда счупена за цялото време на стария живот и наблюдателят заключава, че преизграждането е неуспешно, докато то още не е започнало:

clear crypto ikev2 sa
clear crypto ipsec sa

Потвърдете, че фаза 1 се вдига, преди да гледате фаза 2. Докато фаза 1 е долу, предложението или предварително споделеният ключ е грешен и работата по селекторите няма да го промени.

Селекторите се съгласуват огледално, после решават броячите

Фаза 2 работи само когато двете страни са съгласни за защитаваните адреси, а съгласието е огледално, не общо. Локалният селектор на Google трябва да съвпада със селектора, който ASA нарича отдалечен, а отдалеченият селектор на Google — с това, което ASA нарича локално. Тунел с 0.0.0.0/0 от едната страна и една подмрежа от другата минава фаза 1 и после се проваля на фаза 2 със същата главна грешка. Никоя страна не може да разшири списъка на другата.

За селектори на базата на политики изброете всяка двойка префикси и пазете списъка в заявката. Подмрежа, добавена по-късно в локалната мрежа, изисква редакция от двете страни, защото нов маршрут на ASA не разширява селектор и резултатът е тунел, който е вдигнат и пропуска трафик само за префиксите, съществували в първия ден.

Завършете с един поток от хост до хост и прочетете броячите на байтове от двете страни. Броячи, които растат на ASA и стоят на Google, обикновено означават, че отговорът излиза през друг интерфейс или селекторът не покрива префикса за връщане. Запишете алгоритмите, времената на живот, селекторите и новото име на тунела, защото следващата промяна на предложението повтаря това преизграждане и тези стойности го превръщат в кратка задача.

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