Rutahin ang trapiko sa pagitan ng dalawang sangay sa pamamagitan ng Azure VPN gateway

Maaaring magpalitan ng trapiko ang dalawang sangay sa pamamagitan ng Azure VPN gateway nang walang direktang tunnel sa pagitan nila. Bumubukas ang bawat sangay ng Site-to-Site na koneksyon sa parehong gateway, at ipinapasa ng gateway ang mga natutunang prefix sa pagitan ng dalawang koneksyon. Ang nagpapagana nito ay hindi ang pangalawang tunnel kundi ang palitan ng ruta: kailangang matutunan ng sangay A ang prefix ng sangay B, at ng B ang sa A. Sundan ang mga pagsusuri sa ibaba nang sunod-sunod at huminto sa unang mabibigo, dahil nakadepende rito ang bawat susunod na hakbang.

Mga paunang kundisyon, bago mag-configure ng kahit ano

Apat na kundisyon ang nagtatakda kung gagana man ito. Dapat route-based ang gateway at nasa SKU na sumusuporta sa BGP, dapat naka-enable ang BGP sa dalawang koneksyon, hindi dapat mag-overlap ang mga address space ng mga sangay, at wala sa dalawang panig ang maaaring umasa sa NAT para itago ang tunay na prefix.

Planuhin ang ASN nang sadya. Ang dokumentadong default ng Azure ay 65515, at kailangan ng bawat router ng sangay ang sariling pribadong ASN na hindi bumabangga sa gateway o sa isa pang sangay. Ang muling paggamit ng default nang hindi sinusuri ang umiiral na configuration ng gateway ang paraan para matanggihan ang isang AS path mamaya.

Tiyakin din na hindi ka umaasa sa pag-uugali ng VNet peering. Ipinapalitan ng gateway ang mga ruta sa pagitan ng dalawang koneksyong ini-configure mo; hindi nito ginagawang transitive ang mga arbitrary na peering. Kung kailangang maabot ng ikatlong network ang dalawang sangay, kailangan nito ang sariling koneksyon o sariling ruta, hindi ang palagay na ipapamahagi ng gateway ang trapiko. Isulat ang hangganang iyon bago ang unang change window, dahil iyon ang desisyong pandisenyo na binabalikan ng mga tao kapag may idinagdag na site mamaya.

I-configure sa ganitong pagkakasunod-sunod

May napapansing resulta ang bawat hakbang, kaya huwag magpatuloy hanggang hindi ito lumilitaw.

1. I-enable ang BGP sa virtual network gateway at itala ang ASN at peer address nito.
2. Gumawa ng local network gateway para sa bawat sangay gamit ang tunay na address space ng sangay na iyon, ang ASN nito at ang BGP peer address nito.
3. Gawin ang bawat Site-to-Site na koneksyon at i-enable ang BGP sa koneksyon mismo.
4. I-configure ang router ng sangay na mag-peer sa address ng gateway na itinalaga ng Azure, hindi sa pampublikong IKE endpoint ng gateway batay sa palagay.

Ang ikaapat na hakbang ang lugar kung saan natigil ang karamihan ng pagtatangka. Ang BGP peer address na iniuulat ng Azure ang dapat gamitin ng router ng sangay bilang kapitbahay, at hindi laging ito ang address na inaasahan ng mga tao mula sa diagram ng tunnel.

I-anunsyo ang prefix ng sangay mismo, halimbawa 10.10.0.0/16 mula sa A at 10.20.0.0/16 mula sa B. Huwag mag-anunsyo ng default route o malawak na aggregate para sakupin ang nawawalang partikular na network; bumabalik ang puwang mamaya bilang tahimik na black hole.

I-verify ang palitan ng ruta sa dalawang dulo

Ang status ng koneksyon ay hindi ang pagsusuri. Maaaring aktibo ang IPsec sa dalawang koneksyon habang walang prefix na tumatawid sa pagitan nila. Basahin ang mga BGP peer ng gateway at ang mga natutunang ruta, pagkatapos ay tiyakin na lumilitaw ang ruta patungo sa isa pang sangay bilang magagamit na landas.

Ang prefix na nasa BGP table ay maaari pa ring matalo sa desisyon ng pagpapasa sa isang static na ruta o mas partikular na prefix. Suriin ang napiling ruta, hindi lang ang natanggap.

Sundan ang return path sa gilid ng LAN

Ito ang bahaging mukhang tama sa Azure at nabibigo sa site. Ang host sa sangay A ay nagpapadala ng packet sa VPN router ng A lamang kung ang router na iyon ang default gateway nito, o kung ang host o ang gateway nito ay may ruta para sa prefix ng B. Ganito rin dapat sa kabilang direksyon.

Kung ang hiwalay na core switch ang default gateway ng LAN, kailangan nito ang ruta patungo sa isa pang sangay na nakaturo sa VPN router. Kung wala iyon, dumarating ang kahilingan at lumalabas ang sagot sa landas ng internet, at nakikita ng user ang koneksyong bumubukas at pagkatapos ay nag-hang.

Huwag umasa sa isang network security group sa gateway subnet para ayusin ito. May sariling mga pangangailangan ang subnet na iyon at ang NSG doon ay hindi suportadong kapalit ng patakaran sa gilid ng sangay. Ang pag-filter ay dapat nasa mga firewall ng sangay at sa mga workload mismo, kung saan masusuri ng mga may-ari ang mga patakaran. Ang ilipat ang mga patakarang iyon sa NSG ng subnet ay nagtatago rin sa kanila mula sa team na magde-debug ng susunod na pagkaabala.

Payagan ang operasyon, pagkatapos ay patunayan ito sa isang tinanggihang pagsubok

Ang natutunang ruta ay hindi pahintulot. Payagan ang source, destinasyon at serbisyo na kailangan mo talaga sa pamamagitan ng mga firewall ng sangay at ng patakaran ng endpoint, at iwanang tinanggihan ang iba.

Subukan mula sa ordinaryong workload sa sangay A patungo sa tunay na serbisyo sa sangay B, tiyakin ang sagot, pagkatapos ay subukan ang operasyong dapat manatiling ipinagbabawal. Ang trapikong nililikha ng VPN appliance mismo ay maaaring gumamit ng ibang source address at laktawan ang yugto ng LAN routing, kaya ang matagumpay na ping mula sa router ay nagpapatunay ng mas mababa kaysa sa tila.

Tapusin sa pamamagitan ng pagsulat ng apat na katotohanan: ang mga prefix na ipinalitan, ang mga ginamit na ASN, ang LAN return path ng bawat panig at ang patakarang pumapayag sa serbisyo. Kung may kulang sa mga ito, gumagana ang setup hanggang sa unang pagbabago, at pagkatapos ay walang makapagpapaliwanag kung bakit.