Повратниот сообраќај на 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 размена по промена не кажува ништо за портата на услугата, нејзината автентикација или разрешувањето имиња. Повторете го тестот по повторно поврзување, бидејќи клиент што добива друга адреса од базенот може да го промени резултатот. Потоа повторете го уште еднаш откако клиентот ќе заспие и ќе се разбуди, бидејќи токму во продолжена сесија еднонасочното однесување често се појавува повторно.