VPN sajt-në-sajt nga AWS në Azure: shkruani së pari rrugën e kthimit
Një tunel i lidhur mes dy reve nuk provon asgjë derisa çdo nënrrjet i ngarkesës të drejtojë kah prefiksi i largët. Ndjekni planin me radhë dhe pastaj provoni shërbimin.
Tuneli do të ngrihet. Zakonisht ndodh kështu, sepse IKE ka nevojë vetëm për propozime që përputhen dhe një adresë homologe të arritshme. Ajo që dështon më pas është rruga e kthimit: ngarkesa në AWS dërgon paketa në një tunel, por asgjë në anën e Azure nuk e di se si t’i përgjigjet 10.10.0.0/16, ose rruga e Azure ndodhet në një tabelë që nënrrjeti i ngarkesës nuk e përdor. Shkruani planin e rrugëve përpara se të prekni çdo konsolë, dhe tuneli bëhet pjesa më pak interesante e punës.
Hapi 1: ngrini planin e adresave
Punoni me vlera konkrete. Një ngarkesë në AWS është në 10.10.1.20 brenda 10.10.0.0/16 dhe ka nevojë për TCP 443 drejt një shërbimi Azure në 10.20.1.30 brenda 10.20.0.0/16. Dy intervalet nuk duhet të mbivendosen, dhe testi i pranimit është çifti i shërbimeve, jo tuneli.
Shkruani ato katër fakte para çdo gjëje tjetër, sepse çdo hap i mëpasshëm kontrollohet ndaj tyre.
Hapi 2: emërtoni portën që zotëron çdo skaj
AWS Site-to-Site VPN mund të përfundojë në një portë private virtuale ose në një portë tranziti, dhe këto janë pronarë të ndryshëm të rrugëtimit. Azure ofron VPN Gateway-in e vet të menaxhuar dhe, veçmas, pajisje të bazuara në VM që klientët i drejtojnë vetë. Shënoni cilin çift keni, sepse kërcimi i mëpasshëm ndryshon në çdo kombinim.
Për një portë të menaxhuar, mos kopjoni një rrugë që tregon drejt një adrese të supozuar pajisjeje private. Për një pajisje, mos supozoni se përhapja e rrugëve në re konfiguron sistemin operativ të mysafirit, sepse nuk e bën.
Gabimi këtu prodhon një plan që duket i plotë dhe dërgon paketa në një adresë që nuk përgjigjet kurrë.
Hapi 3: shkruani rrugën që çdo ngarkesë përdor vërtet
Çdo kufi më poshtë është një kërkim i veçantë, dhe një rrugë në një prej tyre nuk është rrugë për paketën. Plotësoni tabelën me vlerat tuaja përpara se tuneli të vihet në punë.
| 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 |
Në AWS, tabela e rrugëve të nënrrjetit të ngarkesës është e juaja për t’u përditësuar edhe pasi BGP ose tuneli të jenë të shëndetshëm; përmbledhja e rrugëtimit e konsideron atë pjesë të lidhjes. Në Azure, një tabelë rrugësh e përcaktuar nga përdoruesi lidhet me një nënrrjet dhe jo me rrjetin virtual, prandaj kontrolloni rrugën efektive në NIC-in e ngarkesës dhe jo në panelin VNet.
Një portë Azure e menaxhuar mund të mësojë prefiksin e largët përmes përhapjes së portës, dhe një UDR mund ta anulojë atë vendim. Shtoni UDR kur keni një arsye, jo si refleks. Nëse shtoni një, drejtojeni drejt kërcimit të mëpasshëm që porta publikon për rrugën VPN, në vend që të shpikni një adresë pajisjeje. Pastaj rilexoni rrugët efektive në NIC, sepse vendimi merret vërtet atje.
Hapi 4: pajtoni shtrirjen
Për BGP, krahasoni çfarë shpall secila anë me atë që ana tjetër ka mësuar vërtet, prefiks për prefiks. Për rrugëtimin statik, krahasoni intervalet e largëta të konfiguruara me rrugët e ngarkesës që shkruat në hapin 3.
Një marrëdhënie IKE që bie dakord për kriptografinë nuk është provë që ndonjë anë ka mësuar 10.10.0.0/16 ose 10.20.0.0/16. Dy tunele mund të jenë lart ndërsa njëra anë shpall një /24 të vetme në vend të /16 që planifikuat. Kontrolloni prefiksin në tabelën e rrugëtimit, jo në statusin e tunelit. Mospërputhja shfaqet më vonë si një nënrrjet që punon dhe një që nuk përgjigjet kurrë.
Hapi 5: provoni shërbimin, nga burimi i vërtetë
Lejoni rrjedhën e synuar në grupet e sigurisë dhe ACL-të e rrjetit të AWS, në NSG-të e Azure dhe në çdo filtër pajisjeje në rrugë. Pastaj hapni një lidhje nga 10.10.1.20 drejt adresës dhe portës së miratuar të shërbimit dhe konfirmoni që përgjigjja kthehet në të njëjtin burim.
Si grupet e sigurisë së resë ashtu edhe NSG-të janë stateful, prandaj një paketë kthimi e refuzuar është simptom i rrugëtimit, jo një rregull që harruat ta shkruanit në kahun e kundërt.
Një ping nga çdo portë nuk vendos asgjë. ICMP drejt adresës së një porte ushtron rrugën e planit të kontrollit, jo shërbimin TCP të përcjellë që i duhet ngarkesës.
Kthimi prapa dhe regjistrat
Regjistroni pronarët e rrugëve pranë identifikuesve të tunelit dhe ruani tabelat e rrugëve përpara ndryshimit. Nëse ndryshimi duhet të hiqet, fshini rrugët e ngarkesës përpara se të çmontoni tunelin, që asnjë nënrrjet të mos mbetet duke treguar drejt një kërcimi të mëpasshëm që nuk ekziston më.
Kështu, një zhvendosje e mëpasshme e nënrrjetit ose një lidhje spoke ka një vend të përcaktuar për t’u përditësuar, në vend të një tuneli që punon dhe mban fajin për një rrugë që nuk e zotëroi kurrë.