S2S VPN в Azure е свързан, но няма трафик: прочетете IKE лога

Порталът пише Connected, тунелът има брояч на времето за работа, а трасирането от вашата виртуална машина умира на втория хоп. Състоянието на връзката описва преговорите по IKE и IPsec, а не дали един пакет оцелява през слоя на политиките от двете страни. Две повреди обясняват повечето такива заявки и нито една от тях не се поправя със смяна на маршрут в Azure. И двете вече са записани в лога, който шлюзът е създал, затова започвам оттам, а не от таблицата с маршрути.

Какво всъщност удостоверява Connected

Свързана връзка site-to-site означава, че фази 1 и 2 са завършени и асоциациите за сигурност са вдигнати. Това е твърдение за преговорите: двете страни са се съгласили за предложение, разменили са ключове и са инсталирали двойката SA. То не казва нищо за това дали селекторите на трафик съвпадат с подмрежите, които смятате за защитени, нито дали далечната страна ще маршрутизира пакета някъде, след като го дешифрира. Тунелът може да стои седмици, докато изхвърля всеки интересен поток, и точно този модел кара хората да престрояват здрав шлюз.

Двете повреди, които си струва да проверите първо, са партньор, който предлага AH вместо ESP, и виртуална мрежа, номерирана в пространство, което шлюзът няма да третира като вътрешно.

Отворете експортирания лог, преди да пипате маршрути

В портала отворете шлюза на виртуалната мрежа и стартирайте операцията VPN troubleshoot върху връзката, след което изтеглете създадения пакет и го разархивирайте. Вътре има IKE лог с размените на фази 1 и 2, с времеви отпечатъци и четим като обикновен текст. Търсете в него реда transform, вместо да четете отгоре надолу, защото интересният запис обикновено е след няколкостотин реда. Ако нямате достъп до портала, същата диагностика се появява в дестинацията за логове на шлюза, когато са включени диагностичните настройки.

Два записа носят основната стойност. Първият гласи приблизително expected ESP with combined authentication and cipher, received AH. Вторият е грешка за невалиден payload по време на IKE размяната, което обикновено означава неправилно оформено или неподдържано поле на предложението.

И двата описват какво е предложило локалното устройство, тоест и двата са настройки от страната на партньора. Пресъздаването на страната на Azure не променя предложението, което вашата защитна стена изпраща, и да го правите все пак е най-често прахосаният час в този процес. На партньора задайте фаза 2 на ESP с комбинирано удостоверяване и шифър и го оставете да договори алгоритъма, после проверете дали отметка на доставчика с име като combined mode не избира тихомълком предложение AH.

Потвърдете адресното пространство на виртуалната мрежа

Шлюзът очаква виртуалната мрежа да е в частни диапазони. Мрежа, номерирана в публичен блок, например започваща с 111.x, може да вдигне тунела, докато Azure отказва да третира това пространство като вътрешно, така че връзката изглежда здрава и не се приема нито един поток. Потвърдете адресното пространство, преди да прекарате следобеда върху селекторите. Ако номерацията е твърдо изискване от по-старо разпределение, поправката е промяна на адресния план, а не друг шлюз.

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

Проверете префиксите в двете посоки

Ресурсът за шлюз на локалната мрежа държи локалните префикси и те трябва да съвпадат с подмрежите, които отдалеченото устройство наистина защитава. Обобщение, което включва адреси, които устройството изхвърля, ще пропусне едни потоци и ще се провали на други, което изглежда като периодична повреда в маршрутизацията, а не като несъответствие в конфигурацията. Проверете и далечната страна: единият край дава /16, а другият изброява три /24 вътре в него — това е класическият частичен провал. Нито един списък не е авторитетен сам по себе си, затова ги сравнете един до друг, вместо да вярвате на този, който виждате.

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

Тествайте път, не ping

Трасировката, която разграничава работещ тунел от работещ маршрут, изглежда така: първият хоп е локалният шлюз, после няколко хопа без отговор, после отдалеченият хост отговаря. Ако трасировката никога не стигне до хоста, тествайте TCP порта, който приложението наистина използва, защото ICMP се филтрира достатъчно често, че неуспешният ping доказва много малко. Пуснете същата трасировка от отдалечен хост към виртуална машина в Azure. Асиметрията между двата резултата е най-бързият начин да намерите липсващ обратен маршрут или правило, което позволява само една посока.

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

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