Kuelekeza trafiki kati ya matawi mawili kupitia lango la VPN la Azure
Miunganisho miwili ya Site-to-Site kwenye lango moja la VPN la Azure inaweza kupitisha trafiki ya matawi, lakini tu wakati ncha zote mbili zinajifunza kiambishi awali na njia ya kurudi ya LAN ipo.
Matawi mawili yanaweza kubadilishana trafiki kupitia lango la VPN la Azure bila handaki lolote la moja kwa moja kati yao. Kila tawi hufungua muunganisho wa Site-to-Site kuelekea lango hilo hilo, na lango hupitisha viambishi awali vilivyojifunzwa kati ya miunganisho hiyo miwili. Kinachofanya hii kufanya kazi si handaki la pili, bali ubadilishanaji wa njia: tawi A linapaswa kujifunza kiambishi awali cha tawi B, na B kile cha A. Pitia ukaguzi ulio hapa chini kwa mpangilio na uache kwenye ule wa kwanza unaoshindikana, kwa sababu kila hatua inayofuata inategemea huo.
Masharti ya awali, kabla ya kusanidi kitu chochote
Masharti manne huamua kama muundo huu unaweza kufanya kazi kabisa. Lango linapaswa kuwa la msingi wa njia na liwe kwenye SKU inayotumia BGP, miunganisho yote miwili iwe na BGP imewezeshwa, nafasi za anwani za matawi zisigongane, na upande wowote usitegemee NAT kuficha kiambishi awali chake halisi.
Panga ASN kwa makusudi. Thamani ya chaguo-msingi iliyoandikwa ya Azure ni 65515, na kila kipanga njia cha tawi linahitaji ASN yake ya faragha ambayo haigongani na lango au tawi lingine. Kutumia tena thamani ya chaguo-msingi bila kukagua usanidi uliopo wa lango ndiyo njia ambayo njia ya AS inakataliwa baadaye.
Pia hakikisha hutarajii tabia ya peering ya VNet. Lango hubadilishana njia kati ya miunganisho miwili uliyoisanidi; halifanyi peering za kiholela kuwa zinazopitika. Ikiwa mtandao wa tatu unapaswa kufikia matawi yote mawili, unahitaji muunganisho wake au njia yake mwenyewe, si dhana kwamba lango litasambaza trafiki. Andika mpaka huo kabla ya dirisha la kwanza la mabadiliko, kwa sababu ni uamuzi wa muundo ambao watu hurudi kwake wakati tovuti ya baadaye inaongezwa.
Sanidi kwa mpangilio huu
Kila hatua ina matokeo yanayoweza kuonekana, kwa hiyo usiendelee hadi yatokee.
- Washa BGP kwenye lango la mtandao pepe na uandike ASN yake na anwani ya peer.
- Unda lango la mtandao wa ndani kwa kila tawi likiwa na nafasi halisi ya anwani ya tawi hilo, ASN yake na anwani yake ya BGP peer.
- Unda kila muunganisho wa Site-to-Site na uwashe BGP kwenye muunganisho wenyewe.
- Sanidi kipanga njia cha tawi ili kiwe peer na anwani ya lango iliyotolewa na Azure, si na kituo cha mwisho cha IKE cha umma cha lango kwa kudhania.
Hatua ya nne ndipo juhudi nyingi zinakwama. Anwani ya BGP peer ambayo Azure huripoti ni ile ambayo kipanga njia cha tawi linapaswa kutumia kama jirani, na si kila mara ndiyo anwani ambayo watu hutegemea kutoka kwenye mchoro wa handaki.
Tangaza kiambishi awali cha tawi chenyewe, kwa mfano 10.10.0.0/16 kutoka A na 10.20.0.0/16 kutoka B. Usitangaze njia ya chaguo-msingi au mkusanyiko mpana kufunika mtandao maalum uliokosekana; pengo hurudi baadaye kama shimo jeusi tulivu.
Thibitisha ubadilishanaji wa njia kwenye ncha zote mbili
Hali ya muunganisho siyo ukaguzi. IPsec inaweza kuwa juu kwenye miunganisho yote miwili wakati hakuna kiambishi awali kinachovuka kati yao. Soma peer za BGP za lango na njia zilizojifunzwa, kisha thibitisha kwamba njia kuelekea tawi lingine inaonekana kama njia inayoweza kutumika.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Kiambishi awali kilichopo kwenye jedwali la BGP bado kinaweza kupoteza uamuzi wa usambazaji kwa njia tuli au kiambishi awali maalum zaidi. Kagua njia iliyochaguliwa, siyo ile iliyopokelewa tu.
Fuata njia ya kurudi upande wa LAN
Hii ni sehemu inayoonekana sahihi katika Azure na inashindikana papo hapo. Mwenyeji katika tawi A hutuma pakiti yake kwa kipanga njia cha VPN cha A tu ikiwa kipanga njia hicho ni lango lake la chaguo-msingi, au ikiwa mwenyeji au lango lake lina njia ya kiambishi awali cha B. Vilevile lazima iwe kweli upande mwingine.
Ikiwa swichi ya msingi tofauti ni lango la chaguo-msingi la LAN, inahitaji njia kuelekea tawi lingine inayoelekeza kwenye kipanga njia cha VPN. Bila hiyo ombi hufika na jibu hutoka kupitia njia ya mtandao, na mtumiaji huona muunganisho unaofunguka kisha unaning'inia.
Usikimbilie kikundi cha usalama cha mtandao kwenye subnet ya lango kurekebisha hili. Subnet hiyo ina mahitaji yake, na NSG hapo si mbadala unaotumika wa sera ya upande wa tawi. Uchujaji unapaswa kuwa kwenye firewalls za matawi na kwenye mizigo ya kazi yenyewe, ambapo sheria zinaweza kukaguliwa na wamiliki wake. Kuhamisha sheria hizo kwenye NSG ya subnet pia huzificha kutoka kwa timu itakayotatua hitilafu inayofuata.
Ruhusu operesheni, kisha ithibitishe kwa jaribio lililokataliwa
Njia iliyojifunzwa siyo ruhusa. Ruhusu chanzo, lengwa na huduma unayohitaji kweli kupitia firewalls za matawi na sera ya kituo cha mwisho, na uache mengine yakiwa yamekataliwa.
Jaribu kutoka mzigo wa kazi wa kawaida katika tawi A hadi huduma halisi katika tawi B, thibitisha jibu, kisha jaribu operesheni ambayo inapaswa kubaki imepigwa marufuku. Trafiki inayozalishwa na kifaa cha VPN chenyewe inaweza kutumia anwani nyingine ya chanzo na kuruka hatua ya uelekezaji wa LAN, kwa hiyo ping iliyofanikiwa kutoka kwa kipanga njia inathibitisha kidogo kuliko inavyoonekana.
Maliza kwa kuandika mambo manne: viambishi awali vilivyobadilishwa, ASN zinazotumika, njia ya kurudi ya LAN kwa kila upande, na sera inayoruhusu huduma. Ikiwa kimoja hakipo, usanidi hufanya kazi hadi mabadiliko ya kwanza, na kisha hakuna anayeweza kueleza kwa nini.