Azure VPN паміж сайтамі з партнёрам за NAT: кантрольны спіс

Выконвайце гэтыя праверкі па парадку і спыніцеся на першай, якая не пройдзе. Большасць паведамленняў пра тое, што Azure не падтрымлівае прыладу за NAT, насамрэч зводзяцца да адраса партнёра, да якога Azure не можа дазваніцца, або да тунеля, які ніколі не ініцыюецца з правільнага боку. Знешні транспарт і ўнутраная маршрутызацыя - дзве розныя праблемы, і змешванне іх марнуе паўдня. Кожны крок ніжэй дае назіранне, якое можна перадаць камусьці іншаму.

Крок 1: пераканайцеся, што партнёр наогул за NAT

Параўнайце адрас на WAN-інтэрфейсе прылады з адрасам, які Azure бачыць для яе. Калі яны розныя, нешта займаецца трансляцыяй, і гэты транслятар цяпер частка вашай схемы VPN. Спытайце ў правайдара, ці адлюстраванне статычнае або агульнае, бо агульнае адлюстраванне змяняе тое, на што можна разлічваць. Прылада з прыватным WAN-адрасам і без перасылкі - іншы выпадак, чым прылада за NAT аператарскага ўзроўню са стабільным публічным адлюстраваннем.

Калі адрасы супадаюць, спыніцеся тут: NAT - не ваша праблема, і астатняе са спіса не дапаможа.

Запішыце абодва адрасы і мадэль транслятара ў заяўку. Гэты адзін радок прадухіляе наступны круг пытанняў пра тое, чаму наладжаны партнёр не адказвае.

Крок 2: дамовіцеся, хто ініцыюе

Артыкул Azure VPN Gateway FAQ паказвае падтрымку NAT-T і дадае, што лакальная прылада павінна ініцыяваць тунель IPsec, калі яна знаходзіцца за NAT. Гэта адпавядае таму, як працуе трансляцыя са станам, бо транслятар захоўвае адлюстраванне, паколькі ўнутраная прылада адправіла першы пакет. Калі чакаецца, што ініцыюе Azure, а нічога не прыходзіць, каб стварыць гэтае адлюстраванне, тунель не пачнецца.

Наладзьце партнёра так, каб памылка толькі адказвальніка была відавочнай, і праверце, ці прылада паўтарае спробу сама або патрабуе запуску. Некаторыя прылады ўздымаюць тунель толькі пры з'яўленні цікавага трафіку, і гэта нармальна, пакуль цікавым трафікам не акажацца праверка стану, якая ніколі не прыйдзе.

Назірайце за абменам IKE на прыладзе падчас ручной ініцыяцыі; цішыня там - гэта адказ маршрутызацыі або фаервала, а не адказ Azure.

Крок 3: правільна задайце адрас партнёра

Azure патрэбен дасяжны публічны адрас партнёра ў аб'екце лакальнага сеткавага шлюза, звычайна публічны адрас транслятара, а не ўнутраны адрас прылады. Ідэнтычнасць, якой прылада аўтэнтыфікуецца - асобнае поле і можа цалкам законна адрознівацца ад адраса, на які тэлефануе Azure. Трымайце іх адрознымі, бо іх перастаноўка дае памылку аўтэнтыфікацыі, якая выглядае дакладна як праблема NAT.

Калі публічны адрас змяняецца, гэты аб'ект павінен змяніцца разам з ім. Імя, якое разрозніваецца ў састарэлы адрас, горш за статычны адрас, які даводзіцца абнаўляць уручную.

Запішыце ўсе тры значэнні: лакальны адрас прылады, трансляваны публічны адрас, наладжаная ідэнтычнасць партнёра.

Крок 4: адкрыйце толькі тыя парты, якія патрэбныя NAT-T

NAT-T пераносіць ESP унутры UDP, і RFC 3948 апісвае гэтае інкапсуляванне з портам 4500, які выкарыстоўваецца пасля пачатковых перамоваў на порце 500. Ваш фаервал і транслятар павінны дазваляць абмен і зваротны трафік. Дазвол несутнаснага TCP-порта нічога не даказвае пра гэты шлях, а правіла, якое дазваляе выходны трафік, але не адказ, усё роўна не спрацуе.

Статычная перасылка ўваходнага порта не патрабуецца аўтаматычна, калі партнёр ініцыюе, а транслятар захоўвае стан. Яна становіцца неабходнай, калі адлюстраванне няўстойлівае або калі нешта на шляху агрэсіўна скончвае стан.

Зрабіце здымак з абодвух бакоў транслятара адзін раз; розніца ў інкапсуляванні адразу бачная.

Крок 5: аддзяліце знешні транспарт ад унутранай маршрутызацыі

Тунель, які ўсталёўваецца і нічога не пераносіць, - гэта праблема маршрутызацыі, а не NAT-T. Сайтам па-ранейшаму патрэбныя сумяшчальныя селектары трафіку, супадальныя адрасныя прасторы, правілы доступу і зваротны шлях для сетак прыкладанняў. Нічога з гэтага паспяховы абмен IKE не дае.

Калі два сайты выкарыстоўваюць перакрыжаваныя прыватныя дыяпазоны, трансляцыя ўнутры тунеля - асобная схема са сваімі правіламі. Не перанумароўвайце падсетку толькі таму, што знешні шлюз апынуўся за хатнім роўтарам.

Класіфікуйце збой па этапе, перш чым нешта змяняць, і захавайце гэтую класіфікацыю ў заяўцы, каб наступны чалавек пачаў там, дзе вы спыніліся.