Azure провера IP тока каже дозвољено, али VPN и даље не ради

Тунел од локације до локације је повезан, VM је здрав, али локални клијент не добија ништа. Отворите Network Watcher, покренете проверу IP тока и она каже Access allowed, па се тикет затвара као проблем са VPN-ом. Тај резултат не значи оно како изгледа, јер провера IP тока оцењује безбедносна правила за ток који сте описали и никада не проверава има ли Azure руту до вашег локалног префикса.

Питање филтрирања и питање усмеравања су одвојени, а Network Watcher на њих одговара различитим алатима. Знати које сте питали је највећи део дијагностике.

Шта провера IP тока заправо одлучује

Провера IP тока узима VM, мрежни интерфејс, смер, вредности петице и протокол, а затим пријављује одлуку NSG правила и безбедносног администратора за тај ток. Ради на TCP и UDP, па није тестер ICMP правила и блокиран ping ништа не доказује о вашој услузи. Дајте јој прави ток, а не претпоставку. Долазећа веза са локалне стране на порт базе података другачији је опис од одлазне везе коју VM иницира.

Ако гејтвеј преводи адресе, користите изворну адресу која стиже на границу коју оцењујете, а не ону из конфигурације клијента. Читајте резултат и онаквим какав јесте. Access allowed значи да би слој филтрирања пропустио пакет да стигне, и ништа више.

Оно што вам не може рећи јесте рута коју је Azure изабрао, да ли гостујући firewall дозвољава порт или да ли нешто слуша. То живи на другим слојевима.

Шта додају следећи скок и ефективне руте

Следећи скок одговара на питање прослеђивања: за ово одредиште који тип следећег скока Azure бира, на којој адреси, из које табеле рута. Ефективне руте наводе шта NIC заправо има. Покрените обоје и добијате пут на страни Azure-а који зелена провера IP тока оставља празним.

Преглед провере IP тока од Microsoft-а директно наводи обим филтрирања, док странице о следећем скоку и дијагностици рута покривају страну прослеђивања. Цитирајте праву страницу када записујете налаз.

Команде су довољно кратке да се покрену из љуске. az network nic show-effective-route-table наводи руте примењене на интерфејс. az network watcher show-next-hop са извором и одредиштем враћа изабрани скок. Упоредите префикс који вам је важан са том табелом, па потврдите који унос побеђује.

Прођите повратни пут са NIC-а VM-а

Радите то са NIC-а циљног VM-а, за префикс локалног клијента, не за интернет. Повратни пут је место где се крију кварови од локације до локације, јер провера стања тунела само пријављује да су безбедносне асоцијације подигнуте.

Ако очекивана рута недостаје, проверите удаљене префиксе које даје конфигурација гејтвеја, дизајн повезивања VNet-а и било које подешавање ширења рута. Објекат локалног мрежног гејтвеја описује локалну страну; његово постојање не доказује да је сваки потребан префикс присутан и префериран на NIC-у. То су различите чињенице, а само једна од њих се појављује у резимеу портала.

Читајте тип следећег скока уместо да копирате пример

Пут кроз управљани VPN гејтвеј обично приказује VirtualNetworkGateway као тип следећег скока. VirtualAppliance описује другачији дизајн прослеђивања, обично firewall или мрежни виртуелни уређај.

Не стварајте руту уређаја ка претпостављеној VPN крајњој тачки само зато што је стари одговор са форума користио тај тип. Ако рута коју је дефинисао корисник надјачава предвиђени пут, пронађите њеног власника и сврху пре него што је промените. Други NIC такође може променити који интерфејс гост користи, а његово уклањање може покварити другу услугу уместо да поправи ову руту.

Пређите на границу која и даље не ради

Када се филтрирање и усмеравање обоје подударају са дизајном, квар је негде другде. Проверите сопствену табелу рута госта, његов firewall и да ли је слушалац везан на очекивану адресу. Затим проверите заштићене селекторе саобраћаја VPN-а и локални пут одговора. Свака од њих је засебан тест са засебним резултатом.

Завршите дозвољеним захтевом апликације и запажањима са оба краја. Резултат allow и исправан следећи скок су два дела доказа, а не доказ да је веза успела.