Azure site-to-site VPN na may peer sa likod ng NAT: checklist

Gawin ang mga pagsusuring ito nang sunud-sunod at huminto sa unang mabibigo. Karamihan ng ulat na hindi sinusuportahan ng Azure ang device sa likod ng NAT ay lumalabas na address ng peer na hindi maabot ng Azure, o tunnel na hindi kailanman nagsisimula mula sa tamang panig. Magkaibang problema ang panlabas na transport at ang panloob na routing, at ang paghahalo sa kanila ay nag-aaksaya ng isang hapon. Bawat hakbang sa ibaba ay gumagawa ng obserbasyong maaari mong ibigay sa iba.

Hakbang 1: kumpirmahin na ang peer ay nasa likod ng NAT

Ihambing ang address sa WAN interface ng device sa address na nakikita ng Azure para dito. Kung magkaiba, may nagsasalin, at ang tagasaling iyon ay bahagi na ngayon ng disenyo ng iyong VPN. Tanungin ang provider kung ang mapping ay static o shared, dahil binabago ng shared mapping ang maaasahan mo. Ang device na may pribadong WAN address at walang forwarding ay ibang kaso kaysa sa isang nasa likod ng carrier-grade NAT na may stable na pampublikong mapping.

Kung magkatugma ang dalawang address, huminto dito: hindi NAT ang problema mo at hindi makakatulong ang natitirang bahagi ng listahang ito.

Itala ang dalawang address at ang modelo ng tagasalin sa ticket. Ang isang linyang iyon ay pumipigil sa susunod na pag-ikot ng mga tanong kung bakit hindi tumutugon ang naka-configure na peer.

Hakbang 2: magkasundo kung sino ang magsisimula

Sinasabi ng FAQ ng Azure VPN Gateway ang suporta sa NAT-T at idinadagdag na dapat simulan ng on-premises na device ang IPsec tunnel kapag nasa likod ito ng NAT. Tumutugma iyon sa kung paano gumagana ang stateful na pagsasalin, dahil nagtatago ang tagasalin ng mapping dahil ang panloob na device ang nagpadala ng unang packet. Kung inaasahang Azure ang magsisimula at walang dumarating upang gawin ang mapping na iyon, hindi kailanman nagsisimula ang tunnel.

I-configure ang peer upang halata ang pagkakamaling responder-only, at tingnan kung ang device ay nagtatangkang muli nang mag-isa o kailangan ng trigger. Ang ilang device ay nag-aangat lamang ng tunnel kapag may lumitaw na kawili-wiling trapiko, na ayos lamang hanggang ang kawili-wiling trapiko ay isang health probe na hindi dumarating.

Panoorin ang IKE exchange sa device habang manu-manong nagsisimula; ang katahimikan doon ay sagot ng routing o firewall, hindi sagot ng Azure.

Hakbang 3: gawing tama ang address ng peer

Kailangan ng Azure ng maabot na pampublikong address para sa peer sa object ng local network gateway nito, karaniwang ang pampublikong address ng tagasalin sa halip na ang panloob na address ng device. Ang pagkakakilanlang ginagamit ng device sa pagpapatunay ay hiwalay na field at maaaring lehitimong naiiba sa address na dinidisk ang Azure. Panatilihing hiwalay ang dalawa, dahil ang pagpapalit sa kanila ay gumagawa ng kabiguan sa pagpapatunay na eksaktong mukhang problema sa NAT.

Kung magbabago ang pampublikong address, dapat ding magbago ang object na iyon kasama nito. Ang pangalang nagre-resolve sa lumang address ay mas masahol pa kaysa sa static na address na kailangan mong i-update nang manu-mano.

Isulat ang tatlong halaga: lokal na address ng device, isinaling pampublikong address, at naka-configure na pagkakakilanlan ng peer.

Hakbang 4: buksan lamang ang mga port na kailangan ng NAT-T

Dinadala ng NAT-T ang ESP sa loob ng UDP, at inilalarawan ng RFC 3948 ang encapsulation na iyon gamit ang port 4500 na ginagamit pagkatapos ng paunang negosasyon sa port 500. Ang firewall mo at ang tagasalin ay dapat parehong payagan ang palitan at ang pabalik na trapiko nito. Ang pagpayag sa walang kaugnayang TCP port ay walang pinapatunayan tungkol sa landas na ito, at ang panuntunang nagpapahintulot sa palabas ngunit hindi sa sagot ay mabibigo pa rin.

Ang static na inbound port forwarding ay hindi awtomatikong kailangan kapag ang peer ang nagsisimula at ang tagasalin ay nagtatago ng estado. Nagiging kailangan ito kapag hindi matatag ang mapping o kapag may nag-expire ng estado nang agresibo sa landas.

Kunin ang capture sa magkabilang panig ng tagasalin nang isang beses; agad na makikita ang pagkakaiba sa encapsulation.

Hakbang 5: ihiwalay ang panlabas na transport sa panloob na routing

Ang tunnel na nabuo at walang dinadala ay problema sa routing, hindi problema sa NAT-T. Kailangan pa rin ng mga site ng tugmang traffic selector, pantay na address space, mga panuntunan sa access at pabalik na landas para sa mga application network. Wala sa mga ito ang ibinibigay ng matagumpay na IKE exchange.

Kung ang dalawang site ay gumagamit ng magkapatong na pribadong saklaw, ang pagsasalin sa loob ng tunnel ay hiwalay na disenyo na may sariling mga panuntunan. Huwag muling bilangin ang subnet dahil lang sa ang panlabas na gateway ay nasa likod ng home router.

Uriin ang kabiguan ayon sa yugto bago ka magbago ng anuman, at itago ang pag-uuring iyon sa ticket upang ang susunod na tao ay magsimula kung saan ka huminto.