Обратният трафик на Azure P2S VPN работи само в една посока

Иконата на тунела е зелена, NSG изглежда разрешаващ, ефективните маршрути изглеждат правилни, а VM все още не може да отвори връзка обратно към свързания клиент. Обичайното предположение е, че работещият point-to-site тунел е симетричен: щом клиентът стига до VM, и VM стига до клиента. Това предположение е грешката в разсъждението, не в конфигурацията. Тунелът може да пренася една посока на непоискан поток и да изхвърля другата, а поправката зависи от това кой слой я изхвърля.

Мит: свързаният тунел е двупосочен тунел

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

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

Проверете посоката, преди да проверявате достъпността

Изберете един адрес на клиент, един адрес на VM и един протокол. Свържете се от клиента и запишете резултата; след това стартирайте същия тест от VM и запишете и него. Ако първият успее, а вторият се провали, пулът от клиенти, асоциацията на шлюза и пътят клиент–VNet работят.

Следващата стъпка е доказателство, не още правила. Проверете NSG на подмрежата на VM в двете посоки, прочетете ефективните маршрути на NIC на VM и уловете пакети на VM, докато клиентът изпраща трафик. Заявка, която пристига без отговор, е проблем с филтър или обратен маршрут; заявка, която никога не пристига, е проблем с пътя. Не приемайте неуспешен ping като доказателство, че VM е недостъпна, защото политика на ICMP може да изхвърли отговора, докато TCP работи.

Обратният път на IKEv2 point-to-site е обичайният заподозрян

В отчета за Azure, който стои зад тази статия, клиент достигаше до VM през IKEv2, но входящият ICMP от VM към клиента се проваляше, докато типът тунел на шлюза не беше превключен на OpenVPN. Авторът на отчета твърди, че Microsoft е потвърдила ограничение в пътя IKEv2 point-to-site, при което обратният трафик от VM към клиента не се маршрутизира симетрично, освен ако клиентът не е започнал сесията. IKEv2 разчита на селектори на трафик и шлюзът не зачете обратната посока в този случай.

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

Смяната на типа тунел е промяна на услуга, не превключвател. Всеки клиент се нуждае от съвместим профил, а шлюзът може да се нуждае от друг сертификат или настройка за удостоверяване. Възпроизведете еднопосочното поведение с един тестов клиент и една тестова VM, сменете типа по одобрен график и след това повторете същите тестове за посока. Ако поведението оцелее след смяната, типът тунел не е бил причината и сте стеснили проблема, без да пипате продукцията.

Мит: откриването чрез broadcast пресича границата на VNet

Второ предположение се проваля по несвързана причина. Виртуалната мрежа на Azure не пренася broadcast трафик, така че VM не може да получава broadcast кадри от локална мрежа през site-to-site или point-to-site връзка. Приложения, които намират партньори чрез broadcast, като по-старото разглеждане на файлове или някои протоколи за откриване на устройства, никога няма да видят отдалечената страна, независимо как са написани маршрутите.

Заменете откриването чрез broadcast с DNS имена, директорска услуга или изричен списък с партньори. Ако приложението няма unicast алтернатива, дизайнът се нуждае от различен механизъм за откриване, а не от по-широк тунел.

Какво да промените и как да го докажете

Ако тестът за посока се проваля само на IKEv2, запишете типа тунел на шлюза, пула от адреси на клиенти и точния тест ICMP или TCP, след което оценете одобрен профил OpenVPN за засегнатите клиенти. Ако се проваля при всеки тип тунел, работете по обратния път: адресът на клиента трябва да е маршрутизируем от подмрежата на VM, всеки дефиниран от потребителя маршрут трябва да сочи към валиден следващ хоп, а защитната стена на клиента трябва да приема входящия поток. Прикачете доказателствата от NSG и маршрутите към тикета.

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