S2S VPN у Azure-у повезан, али нема саобраћаја: прочитајте IKE дневник

Портал приказује Connected, тунел има бројач времена рада, а trace са ваше виртуелне машине умире на другом хопу. Стање везе описује IKE и IPsec преговоре, а не да ли један пакет преживљава слој политика на било којој страни. Две грешке објашњавају већину оваквих тикета и ниједна се не отклања променом Azure руте. Обе су већ записане у дневнику који је произвео gateway, зато почињем одатле, а не из табеле рута.

Шта Connected заиста потврђује

Повезана site-to-site веза значи да су фаза 1 и фаза 2 завршене и да су безбедносне асоцијације активне. То је тврдња о преговорима: обе стране су се сагласиле о предлогу, размениле кључеве и инсталирале пар SA. Не говори ништа о томе да ли се селектори саобраћаја поклапају са подмрежама које сматрате заштићеним, нити о томе да ли ће даља страна усмерити пакет негде након дешифровања. Тунел може стајати недељама док одбацује сваки занимљив ток, а то је управо образац због којег људи поново граде здрав gateway.

Две грешке које прво треба проверити су peer који предлаже AH уместо ESP и виртуелна мрежа нумерисана у простору који gateway неће третирати као интерни.

Отворите извезени дневник пре него што дирнете руте

У порталу отворите gateway виртуелне мреже и покрените VPN troubleshoot операцију над везом, затим преузмите пакет који се створи и распакујте га. Унутра је IKE дневник са разменама фазе 1 и фазе 2, са временским ознакама и читљив као обичан текст. Тражите у њему линију transform уместо да читате одозго надоле, јер занимљив унос обично долази након неколико стотина редова. Ако немате приступ порталу, иста дијагностика се појављује у одредишту дневника gateway-а када су укључена дијагностичка подешавања.

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

Оба описују шта је предложио on-premises уређај, па су оба подешавања на страни peer-а. Поновно генерисање Azure стране везе не мења предлог који ваш firewall шаље, а радити то ипак је најчешће изгубљен сат у овом послу. На peer-у поставите фазу 2 на ESP са комбинованом аутентификацијом и шифром и пустите га да преговара алгоритам, затим проверите да ли поље за потврду добављача названо нешто као combined mode тихо бира AH предлог испод.

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

Gateway очекује да виртуелна мрежа буде у приватним опсезима. Мрежа нумерисана у јавном блоку, на пример она која почиње са 111.x, може подићи тунел док Azure одбија да тај простор третира као интерни, па веза изгледа здраво и ниједан ток није прихваћен. Потврдите адресни простор пре него што потрошите поподне на селекторе. Ако је нумерација тврд захтев из старије доделе, поправка је промена адресног плана, а не други gateway.

Забележите преклапање са on-premises опсезима док сте у оштрици адресног простора, јер преклапајући префикси производе другачији квар који са клијента изгледа слично.

Проверите префиксе у оба смера

Ресурс gateway-а локалне мреже држи on-premises префиксе и они морају одговарати подмрежама које удаљени уређај заиста штити. Сажетак који укључује адресе које уређај одбацује пропустиће неке токове, а на другима пасти, што се чита као повремени квар рутирања, а не као неслагање у конфигурацији. Проверите и даљу страну: један крај наводи /16 док други наводи три /24 унутар њега — то је класичан делимични неуспех. Ниједна листа није сама по себи меродавна, зато их упоредите једну уз другу уместо да верујете оној коју видите.

Промена префикса се не преузима увек сама, зато планирајте поновно чување или поновно креирање објекта везе и затим потврдите да се нови префикси појављују на обе стране.

Тестирајте пут, а не ping

Trace који раздваја тунел који ради од руте која ради изгледа овако: први хоп је on-premises gateway, затим неколико хопова без одговора, затим удаљени host одговара. Ако trace никада не стигне до host-а, тестирајте TCP порт који апликација заиста користи, јер се ICMP филтрира довољно често да неуспели ping доказује врло мало. Покрените исти trace са удаљеног host-а према виртуелној машини у Azure-у. Асиметрија између два резултата најбржи је начин да пронађете повратну руту која недостаје или правило које дозвољава само један смер.

Запишите peer предлог, оба адресна простора и време креирања везе у тикет, да следећи инжењер зна које су вредности поново изграђене, а које никада нису диране.

Ако се дневник врати празан, gateway можда уопште не терминира вашу везу. Потврдите да се peer адреса на gateway-у локалне мреже поклапа са уређајем са којег читате дневник, јер је два gateway-а у једној претплати лако заменити током поновне изградње. Та грешка кошта један дан и не оставља траг ни у једном дневнику.