Azure VPN NAT అతివ్యాప్తి చెందే VNet చిరునామాలను పరిష్కరించదు
ఒకే ప్రైవేట్ పరిధి ఉన్న రెండు VNet లు NAT ఉన్నందున మాత్రమే కనెక్ట్ కావు. మొదట కనెక్షన్ రకాన్ని చూడండి, ఆపై మళ్లీ నంబర్ చేయండి లేదా అనువాద మారుపేరును కలిగి ఉండండి.
రెండు VNet లు 10.40.1.0/24 ఉపయోగిస్తాయి, టన్నెళ్లు పైకి వస్తాయి, ఏమీ పని చేయదు. రెండవ VPN గేట్‌వే జోడించడం దాన్ని మార్చదు, తక్కువ రూట్ మెట్రిక్ కూడా మార్చదు, ఎందుకంటే సమస్య మార్గ ఎంపికలో లేదు. ఒకే ప్రైవేట్ చిరునామాకు సమాధానమిచ్చే రెండు వర్క్‌లోడ్‌లు ప్రతి ప్యాకెట్‌ను అస్పష్ట గమ్యం మరియు ధృవీకరించలేని తిరిగి వచ్చే మార్గంతో వదిలివేస్తాయి. ఏదైనా అనువాదాన్ని ప్లాన్ చేయడానికి ముందు మీరు నిజంగా ఏ కనెక్షన్ రకాన్ని సృష్టించారో కనుగొనండి, ఎందుకంటే ఆ ఒక్క ఎంపిక Azure యొక్క NAT సౌకర్యం అసలు అందుబాటులో ఉందా లేదా అని నిర్ణయిస్తుంది.
ఈ లక్షణం నిజంగా మీకు ఏమి చెబుతోంది
VNet A లోని హోస్ట్ 10.40.1.10 కు పంపినప్పుడు, రౌటింగ్ పట్టిక దాన్ని ఎక్కడో ఒక చోటికి మాత్రమే సూచించగలదు. VNet B లో కూడా 10.40.1.10 ఉంటే, ఆ చిరునామా మార్గం వేరు చేయగల గమ్యం కాదు; అది ఇద్దరు యజమానులతో ఉన్న ఒకే చిరునామా.
ప్రజలు సాధారణంగా ఉంచే రెండవ గేట్‌వే సహాయం చేయదు. అది మరో టన్నెల్ ఇస్తుంది, మరో చిరునామా కాదు, మరియు నకిలీ పరిధి టన్నెల్ లోపల మార్పు లేకుండా ప్రయాణిస్తుంది. మీరు స్థిరంగా ఉంచాల్సిన కాన్ఫిగరేషన్‌ను కూడా అది రెట్టింపు చేస్తుంది. అది చేయలేనిది ఒక చిరునామా రెండు హోస్ట్‌లు అని అర్థం చేయడం.
VPN పీర్ల పబ్లిక్ చిరునామాలను మార్చడం కూడా ఏమీ చేయదు. ఆ చిరునామాలు టన్నెల్ చివరి బిందువులను గుర్తిస్తాయి, కానీ ఘర్షణ లోపల మోయబడే ప్రైవేట్ పరిధిలో ఉంది.
NAT అందుబాటులో ఉందా లేదా అని కనెక్షన్ రకం నిర్ణయిస్తుంది
Azure VPN Gateway కు నిజంగా NAT సామర్థ్యం ఉంది, మరియు నిర్దిష్ట గేట్‌వే SKU లపై రూట్ ఆధారిత IPsec ఇంటర్-సైట్ కనెక్షన్‌లకు అది డాక్యుమెంట్ చేయబడింది. అదే డాక్యుమెంట్ VNet-to-VNet మరియు point-to-site కనెక్షన్‌లను మినహాయిస్తుంది, కాబట్టి ఈ సౌకర్యం ప్రతి గేట్‌వే సంబంధంలో కనిపించే చెక్‌బాక్స్ కాదు.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
స్థానిక VNet-to-VNet కు కూడా మొదటి నుండి VNet మరియు స్థానిక నెట్‌వర్క్ పరిధులు అతివ్యాప్తి చెందకూడదు, ఇది ఈ మినహాయింపుతో సరిపోతుంది. అదే కారణంతో VNet పీరింగ్ కూడా అతివ్యాప్తికి పరిష్కారం కాదు.
ప్రజలు స్థానిక రకంతో గందరగోళపరచుకునే మద్దతు ఉన్న ప్రత్యామ్నాయం ఉంది: మరో VNet ను స్థానిక నెట్‌వర్క్‌గా రూపొందించి దాన్ని సైట్-టు-సైట్ కనెక్షన్‌గా కనెక్ట్ చేయండి. అది వేరే వనరు మరియు వేరే డిజైన్, కాబట్టి పేరు మార్చిన కనెక్షన్‌ను కేవలం పేరు మార్పు కాదు, ధృవీకరించవలసిన మార్పుగా పరిగణించండి.
మళ్లీ నంబర్ చేయండి, లేదా మారుపేరును కలిగి ఉన్న దానితో అనువదించండి
రెండు VNet లు మీవి అయితే, ప్రణాళికాబద్ధమైన పునర్నంబరింగ్‌ను అనువాదం యొక్క నిరంతర ఖర్చుతో పోల్చండి. పునర్నంబరింగ్ అప్లికేషన్ కాన్ఫిగరేషన్, DNS రికార్డులు, భద్రతా నియమాలు మరియు ప్రతి ఇప్పటికే ఉన్న కనెక్షన్‌ను తాకుతుంది, కానీ తర్వాత సాధారణంగా చదవగలిగే నెట్‌వర్క్‌ను మిగులుస్తుంది. ఒకసారి ఒక సబ్‌నెట్ చేయండి, DNS మార్పు చివరిగా. సగం పునర్నంబర్ చేసిన పరిధి ఏ ఎంపిక కంటే చెడ్డది, ఎందుకంటే అప్పుడు రెండు ప్రిఫిక్స్‌లు తదుపరిసారి పట్టిక చదివేవారికి అధికారికంగా కనిపిస్తాయి.
పునర్నంబరింగ్ ఆచరణాత్మకం కాని చోట, మారుపేరుకు నిజమైన యజమాని ఉన్న అనువదించిన డిజైన్‌ను ఉపయోగించండి. VNet A లోని కాలర్లు VNet B యొక్క 10.40.1.10 ను 10.140.1.10 గా చేరుకోవచ్చు, కానీ ఆ మారుపేరుకు అనువదించే పరికరం, దాని వైపు మార్గం మరియు ప్రతిస్పందనకు సరిపోయే ప్రవర్తన అవసరం. DNS లో మాత్రమే జోడించిన చిరునామా అనువాదం కాదు.
రెండు పరిధులను రెండు దిశల్లోనూ నమోదు చేయండి: కాలర్ ఏమి డయల్ చేస్తాడు, గమ్యం మూలంగా ఏమి చూస్తుంది, మరియు ఏ వైపు ప్రారంభించగలదు. Azure యొక్క స్వంత NAT నియమాలు వాటి SNAT మ్యాపింగ్‌లకు విలోమ అనువాదాన్ని కలిగి ఉంటాయి, కాబట్టి మీరు సరిపోయే DNAT నియమాన్ని చేతితో రాయరు, కానీ ఆ సౌలభ్యం ఈ సౌకర్యం మద్దతిచ్చే కనెక్షన్ రకాలతో ముగుస్తుంది.
ఏమి పని చేయదు
వినియోగదారు నిర్వచించిన మార్గం లేదా రూట్ మెట్రిక్ తప్పిపోయిన చిరునామా భేదాన్ని సృష్టించలేవు. రెండూ ఇంకా అస్పష్టమైన గమ్యంపై పని చేస్తాయి, ప్యాకెట్ పట్టికకు ఇష్టమైన తదుపరి హాప్‌కు చేరుతుంది.
నకిలీ పరిధిని మరింత నిర్దిష్ట ప్రిఫిక్స్‌గా రూట్ పట్టికలో జోడించడం అస్పష్టతను ఒక అడుగు మాత్రమే కదిలిస్తుంది. ఇది ఎదురుగా ఉన్న దిశను కూడా బద్దలు కొట్టే పోకడను కలిగి ఉంటుంది, అక్కడ ప్రతిస్పందనకు ఇప్పుడు రెండు ఆమోదయోగ్యమైన మూలాలు ఉన్నాయి.
రెండు దిశల్లోనూ ట్రాఫిక్‌తో డిజైన్‌ను అంగీకరించండి
టన్నెల్ స్థితితో కాదు, ప్రతి వైపు నుండి కొత్త అనుమతించిన కార్యకలాపంతో డిజైన్‌ను నిరూపించండి. కనెక్ట్ చేయబడిన IPsec టన్నెల్ పీర్లు క్రిప్టోగ్రఫీపై అంగీకరిస్తున్నారని చెబుతుంది; గమ్యాలు వేరు చేయగలిగేవి అయ్యాయా అని ఏమీ చెప్పదు.
తర్వాత తిరస్కరించిన మార్గాలను అమలు చేయండి: చేరుకోలేనిదిగా ఉండాల్సిన చిరునామా, మరియు విధానం నిరోధించాల్సిన సేవ. రెండూ ఇంకా విజయవంతమైతే, అనువాదం డిజైన్ ఉద్దేశించిన దానికంటే విస్తృతమైనది.
తర్వాత ఈ సెటప్‌ను వివరించే వాస్తవాలతో ముగించండి: అసలు పరిధి, అందించిన పరిధి, అనువదించే పరికరం, మరియు ప్రతి వైపు ప్రారంభించగల దిశ. వీటిలో ఏదైనా లేకుంటే, తదుపరి ఇంజనీర్ రెండు హోస్ట్‌లు ఒకే పేరును పంచుకునే మరియు వాటిలో ఒకటి ఎందుకు సమాధానమిస్తుందో ఎవరికీ గుర్తు లేని నెట్‌వర్క్‌ను వారసత్వంగా పొందుతారు.