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