VPN na rukunin yanar gizo daga AWS zuwa Azure: fara rubuta hanyar dawowa
Haɗaɗɗen tunnel tsakanin gizagizai ba ya tabbatar da komai har sai kowane subnet ɗin aiki ya bi hanyar zuwa prefix ɗin nesa. Yi tsarin a jere, sannan gwada sabis ɗin.
Tunnel ɗin zai tashi. Yawanci haka yake faruwa, domin IKE yana bukatar kawai shawarwari masu dacewa da adireshin abokin da za a iya isa. Abin da ke gazawa bayan haka ita ce hanyar dawowa: aikin AWS yana aika fakiti cikin tunnel, amma babu abin da ke sashin Azure ya san yadda za a amsa 10.10.0.0/16, ko kuma hanyar Azure tana cikin tebur da subnet ɗin aikin ba ya amfani da shi. Rubuta shirin hanyoyi kafin ka taɓa kowace console, kuma tunnel ɗin zai zama mafi ƙarancin sha’awa a aikin.
Mataki 1: daskare shirin adireshi
Yi aiki da ƙididdiga tabbatattu. Aikin AWS yana kan 10.10.1.20 cikin 10.10.0.0/16 kuma yana bukatar TCP 443 zuwa sabis ɗin Azure a 10.20.1.30 cikin 10.20.0.0/16. Rukunin biyu kada su haɗu, kuma gwajin karɓa shine nau’in sabis ɗin, ba tunnel ɗin ba.
Rubuta waɗannan gaskiya huɗu kafin komai, domin kowane mataki na gaba ana duba shi da su.
Mataki 2: ambaci gateway ɗin da ke da kowane ƙarshen
AWS Site-to-Site VPN na iya ƙarewa a kan virtual private gateway ko transit gateway, kuma waɗannan masu hanyoyi ne daban-daban. Azure yana ba da VPN Gateway ɗinsa mai sarrafawa da, daban, na’urori na VM da abokan ciniki ke tafiyar da su da kansu. Rubuta wane nau’i ke da ku, domin tsalle na gaba ya bambanta a kowane haɗi.
Don gateway mai sarrafawa, kada ka kwafi hanyar da ke nuni ga adireshin na’urar sirri da aka yi hasashe. Don na’ura, kada ka ɗauka cewa yaduwar hanyoyi a cikin girgije tana saita tsarin aiki na baƙo, domin ba ya yin haka.
Kuskure a nan yana samar da shirin da ya yi kama da cikakke kuma yana tura fakiti zuwa adireshin da ba ya amsawa har abada.
Mataki 3: rubuta hanyar da kowane aiki ke amfani da ita da gaske
Kowane iyaka da ke ƙasa bincike ne daban, kuma hanya a ɗaya daga cikinsu ba hanya ce ga fakitin ba. Cika tebur ɗin da naka ƙididdiga kafin tunnel ɗin ya fara aiki.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
A AWS, tebur ɗin hanyoyi na subnet ɗin aiki naka ne don sabuntawa koda bayan BGP ko tunnel ya yi lafiya; bayani kan hanyoyi yana ɗaukar hakan a matsayin ɓangare na haɗin. A Azure, tebur ɗin hanyoyin da mai amfani ya ayyana yana haɗa da subnet maimakon cibiyar sadarwa ta kama-da-wane, don haka duba hanyar da ke aiki a kan NIC ɗin aikin ba a cikin blade ɗin VNet ba.
Gateway ɗin Azure mai sarrafawa na iya koyan prefix ɗin nesa ta yaduwar gateway, kuma UDR na iya soke wannan shawarar. Ƙara UDR lokacin da kake da dalili, ba da gangan ba. Idan ka ƙara, nuna shi ga tsalle na gaba da gateway ke wallafawa don hanyar VPN maimakon ƙirƙirar adireshin na’ura. Sannan sake karanta hanyoyin da ke aiki a kan NIC, domin a can ne ake yanke shawara da gaske.
Mataki 4: daidaita iyaka
Don BGP, kwatanta abin da kowane ɓangare ke sanarwa da abin da ɗayan ya koya da gaske, prefix da prefix. Don hanyoyi na tsaye, kwatanta rukunin nesa da aka saita da hanyoyin aikin da ka rubuta a mataki 3.
Dangantakar IKE da ta yarda kan boye-boye ba hujja ba ce cewa kowane ɓangare ya koyi 10.10.0.0/16 ko 10.20.0.0/16. Tunnels biyu na iya kasancewa suna aiki yayin da ɓangare ɗaya ke sanar da /24 ɗaya maimakon /16 da ka shirya. Duba prefix ɗin a cikin tebur ɗin hanyoyi, ba a cikin matsayin tunnel ba. Rashin daidaituwa yana bayyana daga baya a matsayin subnet ɗaya mai aiki da ɗaya da ba ya amsawa har abada.
Mataki 5: gwada sabis ɗin daga ainihin tushe
Ba da izini ga kwararar da aka nufa a cikin ƙungiyoyin tsaro da ACL ɗin cibiyar sadarwa na AWS, a cikin NSG ɗin Azure, da kowane matatar na’ura a kan hanyar. Sannan buɗe haɗi ɗaya daga 10.10.1.20 zuwa adireshin da tashar sabis ɗin da aka amince da su kuma tabbatar da cewa amsar ta dawo ga wannan tushe ɗin.
Duk ƙungiyoyin tsaro na girgije da NSG ɗin suna da hali, don haka fakitin dawowa da aka ƙi alama ce ta hanyoyi, ba ƙa’idar da ka manta rubuta a akasin hanya ba.
Ping daga kowane gateway ba ya warware komai. ICMP zuwa adireshin gateway yana gwada hanyar control plane, ba sabis ɗin TCP da aka tura wanda aikin yake bukata ba.
Koma baya da rikodi
Rubuta masu hanyoyi kusa da bayanan tunnel, kuma ka adana tebur ɗin hanyoyi na kafin canjin. Idan canjin dole ya fita, cire hanyoyin aikin kafin ka rushe tunnel ɗin, don kada wani subnet ya kasance yana nuni ga tsalle na gaba da babu shi.
Sa’an nan motsi na subnet ko haɗin spoke daga baya yana da wuri ɗaya da aka ayyana don sabuntawa, maimakon tunnel mai aiki da ke ɗaukar laifin hanyar da bai taɓa mallaka ba.