Site-to-Site VPN frá AWS til Azure: skrifaðu afturleiðina fyrst

Göngin munu rísa. Það gerist venjulega, því IKE þarf bara samsvarandi tillögur og aðgengilegt jafningjafang. Það sem bregst svo er afturleiðin: vinnslan í AWS sendir pakka inn í göng, en ekkert á Azure-hliðinni veit hvernig á að svara 10.10.0.0/16, eða Azure-leiðin er í töflu sem vinnsluundirnetið notar ekki. Skrifaðu leiðaráætlunina áður en þú snertir nokkra stjórnborð, og göngin verða óspennandi hluti verksins.

Skref 1: frystu fangáætlunina

Vinna með áþreifanleg gildi. Vinnsla í AWS er á 10.10.1.20 innan 10.10.0.0/16 og þarf TCP 443 til Azure-þjónustu á 10.20.1.30 innan 10.20.0.0/16. Sviðin tvö mega ekki skarast, og samþykktarprófið er þjónustuparið, ekki göngin.

Skrifaðu þessi fjögur staðreyndaratriði niður fyrir allt annað, því hvert síðara skref er athugað á móti þeim.

Skref 2: nefndu gáttina sem á sitt hvorn endann

AWS Site-to-Site VPN getur endað á sýndareinkagátt eða milligátt, og þær eru ólíkir leiðareigendur. Azure býður upp á stýrðu VPN Gateway og, aðskilið, VM-tæki sem viðskiptavinir reka sjálfir. Skráðu hvaða par þú hefur, því næsta stökk er ólíkt í hverri samsetningu.

Fyrir stýrða gátt, ekki afrita leið sem bendir á ágiskað fang einkatækis. Fyrir tæki, ekki gera ráð fyrir að leiðaútbreiðsla í skýinu stilli gestastýrikerfið, því hún gerir það ekki.

Að gera þetta vitlaust gefur áætlun sem virðist fullkomin og sendir pakka á fang sem svarar aldrei.

Skref 3: skrifaðu leiðina sem hver vinnsla notar í raun

Hvert mörk hér að neðan er sérstök uppfletting, og leið í einu þeirra er ekki leið fyrir pakkann. Fylltu töfluna með þínum eigin gildum áður en göngin fara í gagnið.

Í AWS er leiðatafla vinnsluundirnetsins þín til að uppfæra, jafnvel eftir að BGP eða göng eru heilbrigð; yfirlit leiðarstýringar telur það hluta tengingarinnar. Í Azure er notandaskilgreind leiðatafla tengd undirneti frekar en sýndarnetinu, svo athugaðu virku leiðina á NIC vinnslunnar, ekki í VNet-hnappinum.

Stýrð Azure-gátt getur lært fjarlæga forskeytið með útbreiðslu gáttarinnar, og UDR getur hnekkt þeirri ákvörðun. Bættu UDR við þegar þú hefur ástæðu, ekki af vana. Ef þú bætir við, beindu henni að næsta stökki sem gáttin birtir fyrir VPN-leiðina í stað þess að finna upp tækjafang. Lestu svo virku leiðirnar á NIC aftur, því ákvörðunin er í raun tekin þar.

Skref 4: samræmdu umfangið

Fyrir BGP, berðu saman það sem sitt hvor hliðin auglýsir við það sem hin lærði í raun, forskeyti fyrir forskeyti. Fyrir kyrrstæða leiðarstýringu, berðu saman stilltu fjarlægu sviðin við vinnsluleiðirnar sem þú skrifaðir í skrefi 3.

IKE-samband sem sammælist um dulritun er ekki sönnun þess að önnur hliðin hafi lært 10.10.0.0/16 eða 10.20.0.0/16. Tvö göng geta verið uppi á meðan önnur hliðin auglýsir eitt /24 í stað /16 sem þú áætlaðir. Athugaðu forskeytið í leiðatöflunni, ekki í stöðu ganganna. Misræmið kemur síðar í ljós sem eitt undirnet sem virkar og annað sem svarar aldrei.

Skref 5: prófaðu þjónustuna frá raunverulegri uppsprettu

Leyfðu fyrirhugaða flæðið í öryggishópum og net-ACL AWS, í NSG Azure og í hvaða tækjasiu sem er á leiðinni. Opnaðu svo eina tengingu frá 10.10.1.20 á samþykkt þjónustufang og port og staðfestu að svarið komi til baka á sama uppsprettu.

Bæði öryggishópar skýsins og NSG eru stöðufull, svo hafnað afturpakkinn er einkenni leiðarstýringar, ekki regla sem þú gleymdir að skrifa öfugt.

Ping frá hvaða gátt sem er sker ekki úr neinu. ICMP á gáttarfang æfir stjórnsléttu leiðarinnar, ekki áframsendu TCP-þjónustuna sem vinnslan þarf.

Afturköllun og skrár

Skráðu leiðareigendurna við hlið gangaauðkennanna og geymdu leiðatöflurnar frá því fyrir breytinguna. Ef breytingin þarf að fara út, fjarlægðu vinnsluleiðirnar áður en göngin eru rifin, svo ekkert undirnet sitji eftir að benda á næsta stökk sem er ekki lengur til.

Þá hefur síðari undirnetsflutningur eða spoke-tenging einn skilgreindan stað til að uppfæra, í stað ganga sem virka og bera sökina fyrir leið sem þau áttu aldrei.