AWS నుండి Azure సైట్ VPN: మొదట తిరిగి వెళ్లే మార్గాన్ని రాయండి
రెండు క్లౌడ్ల మధ్య అనుసంధానించిన టన్నెల్, ప్రతి వర్క్‌లోడ్ సబ్‌నెట్ దూర ప్రిఫిక్స్‌కు రూట్ చేయనంత వరకు ఏదీ నిరూపించదు. ప్రణాళికను క్రమంగా చేయండి, తర్వాత సేవను పరీక్షించండి.
టన్నెల్ పైకి వస్తుంది. సాధారణంగా అలాగే జరుగుతుంది, ఎందుకంటే IKE కి సరిపోయే ప్రతిపాదనలు మరియు చేరుకోగల పీర్ చిరునామా మాత్రమే కావాలి. ఆ తర్వాత విఫలమయ్యేది తిరిగి వెళ్లే మార్గం: AWS వర్క్‌లోడ్ ప్యాకెట్లను టన్నెల్‌లోకి పంపుతుంది, కానీ Azure వైపు 10.10.0.0/16 కి ఎలా సమాధానం ఇవ్వాలో ఎవరికీ తెలియదు, లేదా Azure మార్గం వర్క్‌లోడ్ సబ్‌నెట్ ఉపయోగించని పట్టికలో ఉంది. ఏదైనా కన్సోల్‌ను తాకే ముందు మార్గ ప్రణాళిక రాయండి, టన్నెల్ పనిలో అతి తక్కువ ఆసక్తికరమైన భాగం అవుతుంది.
దశ 1: చిరునామా ప్రణాళికను స్థిరపరచండి
నిర్దిష్ట విలువలతో పని చేయండి. AWS వర్క్‌లోడ్ 10.10.0.0/16 లోపల 10.10.1.20 వద్ద ఉంది మరియు 10.20.0.0/16 లోపల 10.20.1.30 వద్ద ఉన్న Azure సేవకు TCP 443 కావాలి. రెండు పరిధులు ఒకదానిపై ఒకటి రాకూడదు, ఆమోద పరీక్ష సేవా జంట, టన్నెల్ కాదు.
మిగతా ఏదైనా చేసే ముందు ఆ నాలుగు వాస్తవాలను రాయండి, ఎందుకంటే ప్రతి తదుపరి దశ వాటికి వ్యతిరేకంగా తనిఖీ చేయబడుతుంది.
దశ 2: ప్రతి చివర యజమాని అయిన గేట్‌వేను పేర్కొనండి
AWS Site-to-Site VPN వర్చువల్ ప్రైవేట్ గేట్‌వే లేదా ట్రాన్సిట్ గేట్‌వేపై ముగియవచ్చు, ఇవి వేర్వేరు రూటింగ్ యజమానులు. Azure దాని నిర్వహిత VPN Gateway మరియు విడిగా వినియోగదారులు తామే నడిపే VM ఆధారిత పరికరాలను అందిస్తుంది. మీకు ఏ జంట ఉందో నమోదు చేయండి, ఎందుకంటే ప్రతి కలయికలో తదుపరి హాప్ భిన్నంగా ఉంటుంది.
నిర్వహిత గేట్‌వే కోసం, ఊహించిన ప్రైవేట్ పరికర చిరునామాను సూచించే మార్గాన్ని కాపీ చేయవద్దు. పరికరం కోసం, క్లౌడ్ మార్గ ప్రచారం అతిథి ఆపరేటింగ్ సిస్టమ్‌ను కాన్ఫిగర్ చేస్తుందని భావించవద్దు, ఎందుకంటే అది అలా చేయదు.
ఇక్కడ పొరపాటు చేస్తే పూర్తిగా కనిపించే ప్రణాళిక ఏర్పడి, ఎప్పుడూ సమాధానం ఇవ్వని చిరునామాకు ప్యాకెట్లను పంపుతుంది.
దశ 3: ప్రతి వర్క్‌లోడ్ నిజంగా ఉపయోగించే మార్గాన్ని రాయండి
క్రింది ప్రతి సరిహద్దు ప్రత్యేక శోధన, వాటిలో ఒకటి ఉన్న మార్గం ప్యాకెట్‌కు మార్గం కాదు. టన్నెల్ అమలులోకి రాకముందు పట్టికను మీ విలువలతో నింపండి.
| 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 |
AWS లో, BGP లేదా టన్నెల్ ఆరోగ్యంగా ఉన్న తర్వాత కూడా వర్క్‌లోడ్ సబ్‌నెట్ మార్గ పట్టికను మీరే నవీకరించాలి; రూటింగ్ అవలోకనం దాన్ని కనెక్షన్‌లో భాగంగా పరిగణిస్తుంది. Azure లో, వినియోగదారు నిర్వచించిన మార్గ పట్టిక వర్చువల్ నెట్‌వర్క్‌కు కాదు, సబ్‌నెట్‌కు అనుసంధానమవుతుంది, కాబట్టి ప్రభావవంతమైన మార్గాన్ని VNet బ్లేడ్‌లో కాదు, వర్క్‌లోడ్ NIC లో తనిఖీ చేయండి.
నిర్వహిత Azure గేట్‌వే గేట్‌వే ప్రచారం ద్వారా దూర ప్రిఫిక్స్‌ను నేర్చుకోగలదు, UDR ఆ నిర్ణయాన్ని రద్దు చేయగలదు. కారణం ఉన్నప్పుడు UDR జోడించండి, అలవాటుగా కాదు. జోడిస్తే, పరికర చిరునామాను కల్పించడం బదులు గేట్‌వే VPN మార్గానికి ప్రచురించే తదుపరి హాప్‌కు మళ్లించండి. తర్వాత NIC లోని ప్రభావవంతమైన మార్గాలను మళ్లీ చదవండి, ఎందుకంటే నిర్ణయం నిజంగా అక్కడే తీసుకోబడుతుంది.
దశ 4: పరిధిని సరిపోల్చండి
BGP కోసం, ప్రతి వైపు ప్రకటించేదాన్ని మరో వైపు నిజంగా నేర్చుకున్నదానితో ప్రిఫిక్స్ ప్రకారం పోల్చండి. స్థిర రూటింగ్ కోసం, కాన్ఫిగర్ చేసిన దూర పరిధులను దశ 3 లో రాసిన వర్క్‌లోడ్ మార్గాలతో పోల్చండి.
క్రిప్టోగ్రఫీపై ఏకీభవించిన IKE సంబంధం ఏ వైపు 10.10.0.0/16 లేదా 10.20.0.0/16 నేర్చుకుందని రుజువు కాదు. మీరు ప్రణాళిక చేసిన /16 కి బదులు ఒకే /24 ప్రకటిస్తూనే రెండు టన్నెల్లు పైన ఉండవచ్చు. ప్రిఫిక్స్‌ను రూటింగ్ పట్టికలో తనిఖీ చేయండి, టన్నెల్ స్థితిలో కాదు. అసమానత తర్వాత పనిచేసే ఒక సబ్‌నెట్ మరియు ఎప్పుడూ సమాధానం ఇవ్వని మరొకటి రూపంలో కనిపిస్తుంది.
దశ 5: నిజమైన మూలం నుండి సేవను పరీక్షించండి
AWS భద్రతా సమూహాలు మరియు నెట్‌వర్క్ ACL, Azure NSG, మరియు మార్గంలోని ఏదైనా పరికర ఫిల్టర్‌లో ఉద్దేశించిన ప్రవాహాన్ని అనుమతించండి. తర్వాత 10.10.1.20 నుండి ఆమోదించిన సేవా చిరునామా మరియు పోర్ట్‌కు ఒక కనెక్షన్ తెరిచి, సమాధానం అదే మూలానికి తిరిగి వస్తుందని నిర్ధారించండి.
క్లౌడ్ భద్రతా సమూహాలు మరియు NSG రెండూ stateful, కాబట్టి తిరస్కరించబడిన తిరిగి వచ్చే ప్యాకెట్ రూటింగ్ లక్షణం, వ్యతిరేక దిశలో రాయడం మరచిన నియమం కాదు.
ఏ గేట్‌వే నుండైనా ping ఏదీ నిర్ణయించదు. గేట్‌వే చిరునామాకు ICMP నియంత్రణ ప్లేన్ మార్గాన్ని సాధన చేస్తుంది, వర్క్‌లోడ్‌కు అవసరమైన ఫార్వర్డ్ చేసిన TCP సేవను కాదు.
రోల్‌బ్యాక్ మరియు రికార్డులు
టన్నెల్ గుర్తింపుల పక్కన మార్గ యజమానులను నమోదు చేయండి మరియు మార్పుకు ముందు మార్గ పట్టికలను భద్రపరచండి. మార్పును తీసివేయాల్సి వస్తే, టన్నెల్‌ను విచ్ఛిన్నం చేయకముందే వర్క్‌లోడ్ మార్గాలను తొలగించండి, ఇక లేని తదుపరి హాప్‌కు ఏ సబ్‌నెట్ చూపకుండా.
అప్పుడు తర్వాతి సబ్‌నెట్ బదిలీ లేదా spoke అనుసంధానానికి నవీకరించడానికి ఒక నిర్దిష్ట స్థలం ఉంటుంది, ఎప్పుడూ తన సొంతం కాని మార్గం దోషాన్ని మోసే నడుస్తున్న టన్నెల్‌కు బదులుగా.