Azure VPN између локација са партнером иза NAT-а: контролна листа

Прођите ове провере редом и зауставите се на првој која не успе. Већина пријава да Azure не подржава уређај иза NAT-а заправо су адреса партнера до које Azure не може да дође или тунел који никада не почиње са праве стране. Спољашњи транспорт и унутрашње рутирање су два различита проблема, а њихово мешање троши поподне. Сваки корак испод даје запажање које можете предати неком другом.

Корак 1: потврдите да је партнер уопште иза NAT-а

Упоредите адресу на WAN интерфејсу уређаја са адресом коју Azure види за њега. Ако се разликују, нешто преводи, и тај преводилац је сада део вашег VPN дизајна. Питајте добављача да ли је мапирање статичко или дељено, јер дељено мапирање мења оно на шта можете да се ослоните. Уређај са приватном WAN адресом и без прослеђивања је други случај од оног иза NAT-а на оператерском нивоу са стабилним јавним мапирањем.

Ако се две адресе поклапају, зауставите се овде: NAT није ваш проблем и остатак ове листе неће помоћи.

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

Корак 2: договорите ко иницира

Честа питања о Azure VPN Gateway наводе подршку за 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 размена.

Ако две локације користе преклапајуће приватне опсеге, превод унутар тунела је засебан дизајн са својим правилима. Не пренумеришите подмрежу само зато што се спољашњи пролаз налази иза кућног рутера.

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