Azure UDR నుండి VPN గేట్‌వే వరకు: ఒక గమ్యం, మొత్తం నిష్క్రమణ కాదు

మీరు ఒక బాహ్య ప్రిఫిక్స్ కోసం వినియోగదారు-నిర్వచించిన మార్గాన్ని జోడించి, దాన్ని VPN గేట్‌వేకి చూపిస్తారు, ట్రాఫిక్ ఇప్పటికీ Azure ఇంటర్నెట్ మార్గం ద్వారా బయటకు వెళ్తుంది. లేదా అది సరిగ్గా బయటకు వెళ్తుంది, సమాధానం మాత్రం ఎప్పటికీ తిరిగి రాదు. రెండు ఫలితాలు ఒకే తప్పు నుండి వస్తాయి: Azure తదుపరి హాప్‌ను మొత్తం డిజైన్‌గా భావించడం. రూట్ పట్టిక Azure లోపల ప్యాకెట్ ఏ నిష్క్రమణ తీసుకుంటుందో మాత్రమే నిర్ణయిస్తుంది. సొరంగం తర్వాత దానికి ఏమి జరుగుతుంది, సమాధానం ఎలా తిరిగి వస్తుంది అనేది మీరు నిర్మించాల్సిన రెండవ సగం.

తదుపరి హాప్ ఒక గేట్‌వే, పరికరం యొక్క IP కాదు

UDR సరిపోయే ప్రిఫిక్స్‌ను తదుపరి-హాప్ రకానికి పంపుతుంది, VirtualNetworkGateway ఒక రకం, చిరునామా కాదు. ప్రజలు గేట్‌వే యొక్క ప్రైవేట్ IP ను VirtualAppliance మార్గంలో అతికించి, ఏదీ ఎందుకు సరిపోలడం లేదని ఆశ్చర్యపోతారు, ఎందుకంటే ఆ రకం దానికి బదులుగా NIC లేదా అంతర్గత లోడ్ బ్యాలెన్సర్‌ను ఆశిస్తుంది. Microsoft రూటింగ్ డాక్యుమెంటేషన్ కూడా గేట్‌వే తదుపరి హాప్‌ను గేట్‌వే VPN గేట్‌వేగా ఉన్న వర్చువల్ నెట్‌వర్క్‌కు పరిమితం చేస్తుంది. ExpressRoute, Route Server మరియు Virtual WAN హబ్ ఆ ఎంపికతో చిరునామా చేయబడవు.

మార్గం రాయడానికి ముందు వర్చువల్ నెట్‌వర్క్ వాస్తవానికి ఏమి కలిగి ఉందో తనిఖీ చేయండి. డిజైన్ హబ్ ద్వారా రూట్ చేస్తే, మార్గం మీరు సవరిస్తున్న స్పోక్‌ది కాదు, హబ్ యొక్క రూటింగ్ యజమానిది.

ఏదైనా మార్చడానికి ముందు ప్రభావవంతమైన మార్గాన్ని చదవండి

Azure సిస్టమ్ మార్గాలు, BGP ద్వారా నేర్చుకున్న ప్రిఫిక్స్‌లు మరియు UDR లను ప్రతి NIC కి ప్రభావవంతమైన రూట్ పట్టికలో కలుపుతుంది, మరియు పొడవైన సరిపోయే ప్రిఫిక్స్ ఎక్కడి నుండి వచ్చినా గెలుస్తుంది. ఒకే ప్రిఫిక్స్ కోసం, UDR BGP మార్గాన్ని ఓడిస్తుంది. ఈ క్రమమే మునుపటి ప్రయోగం నుండి పాత UDR, మీరు ఇప్పుడే సొరంగం ద్వారా నేర్చుకున్న ప్రిఫిక్స్‌ను నిశ్శబ్దంగా అధిగమించగల కారణం.

మొదట ప్రభావవంతమైన పట్టికను చూడండి, తర్వాత మీరు మార్గాన్ని జోడిస్తున్నారా లేదా భర్తీ చేస్తున్నారా నిర్ణయించుకోండి:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

ప్రిఫిక్స్‌తో పాటు మూల నిలువు వరుసను కూడా చదవండి. సరైన ప్రిఫిక్స్ మరియు తప్పు మూలం ఉన్న మార్గం ఏ వస్తువును సవరించాలో చెబుతుంది, మరియు మొదటి దానికి ఓడిపోయే రెండవ మార్గాన్ని జోడించకుండా కాపాడుతుంది.

వాస్తవ ప్రిఫిక్స్ మరియు సబ్‌నెట్ ప్రకారం మార్గాన్ని రాయండి

ఫోరమ్ పోస్ట్ నుండి కాపీ చేసిన పబ్లిక్ పరిధికి బదులుగా మీరు నిజంగా చేరుకునే సేవ నుండి తీసుకున్న గమ్యస్థానం యొక్క వాస్తవ ప్రిఫిక్స్‌ను ఉపయోగించండి. మొత్తం నిష్క్రమణను కదిలించే డిఫాల్ట్ మార్గాన్ని పరిగణించే ముందు ఒక ఆమోదించిన సేవతో ప్రారంభించండి. తర్వాత రూట్ పట్టికను పనిభారం సబ్‌నెట్‌కు జోడించండి. గేట్‌వే సబ్‌నెట్‌కు దాని స్వంత అవసరాలు ఉన్నాయి, అక్కడ మీ పట్టికను జోడించడం పనిభారాన్ని దర్శకత్వం చేయడం బదులు గేట్‌వేను విరుస్తుంది.

మార్గాన్ని సృష్టించండి, తర్వాత పట్టికను పనిభారాన్ని హోస్ట్ చేసే సబ్‌నెట్‌కు కట్టండి:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

ప్రచారం కూడా ముఖ్యం. ఆ పట్టికలో BGP ప్రచారం ప్రారంభించి ఉంటే, నేర్చుకున్న ప్రిఫిక్స్‌లు మీరు రాసిన వాటి పక్కన కనిపిస్తాయి, మరియు మరింత నిర్దిష్ట నేర్చుకున్న ప్రిఫిక్స్ విశాలమైన UDR ను ఓడించగలదు. ఆ సబ్‌నెట్‌కు UDR సమితి అధికారం కలిగి ఉండాలని మీరు కోరుకున్నప్పుడు మాత్రమే ప్రచారాన్ని నిలిపివేయండి.

ఆన్-ప్రిమైస్ సగం పూర్తి చేయండి, లేకుంటే ప్రవాహం అక్కడే మరణిస్తుంది

ఆన్-ప్రిమైస్ గేట్‌వే Azure మూలాన్ని అంగీకరించాలి, దాన్ని గమ్యస్థానానికి పంపాలి మరియు అప్లికేషన్‌ను అనుమతించాలి. దాని తదుపరి మార్గం ఇంటర్నెట్ నిష్క్రమణ లేదా మరొక ప్రైవేట్ హాప్ కావచ్చు, కానీ ఆ నిర్ణయం ప్రణాళికలో ఉంది, Azure రూట్ పట్టికలో కాదు. సాధారణ వైఫల్యం తిరిగి వెళ్లే మార్గం. ఇంటర్నెట్ గమ్యస్థానం ప్రైవేట్ Azure మూలాన్ని మీ వైపు తిరిగి రూట్ చేయదు, కాబట్టి సమాధానం దాని స్వంత డిఫాల్ట్ గేట్‌వేకి వెళ్లి మరణిస్తుంది, లేదా బయటకే వెళ్లదు.

రెండు డిజైన్‌లు దీన్ని పరిష్కరిస్తాయి, అవి పరస్పరం మార్పిడి చేయలేనివి. నిష్క్రమణలో మూలాన్ని అనువదించండి, తద్వారా గమ్యస్థానం ఆన్-ప్రిమైస్ నెట్‌వర్క్ కలిగి ఉన్న పబ్లిక్ చిరునామాకు సమాధానం ఇస్తుంది. లేదా మూలాన్ని కాపాడి, సమాధానాలు సొరంగం ద్వారా తిరిగి వచ్చేలా రూట్ చేయబడిన తిరిగి వచ్చే సంబంధాన్ని నిర్మించండి. ఒకదాన్ని ఎంచుకోండి మరియు అప్లికేషన్ ఏ చిరునామాను చూస్తుందో రాయండి.

సెలెక్టర్లు మరియు అనుమతి జాబితాలు ఇవన్నీ నుండి వేరుగా ఉంటాయి. Azure తదుపరి హాప్‌ను ఎంచుకోవడం VPN ట్రాఫిక్ సెలెక్టర్లను విస్తరించదు, మరియు బాహ్య సేవ యొక్క మూల అనుమతి జాబితాను మార్చదు.

గమ్యస్థానం చూసే మూలంతో ధృవీకరించండి

అభ్యర్థనను మరొక సబ్‌నెట్‌లోని జంప్ హోస్ట్ నుండి కాకుండా వాస్తవ పనిభారం నుండి పంపండి, తర్వాత గమ్యస్థానం చూసిన మూల చిరునామాను చదవండి. ఆ ఒక్క విలువ రెండు తిరిగి వచ్చే డిజైన్‌లలో ఏది అమలులో ఉందో చెబుతుంది. తర్వాత సమాధాన మార్గాన్ని తనిఖీ చేయండి, మరియు VM కి సాధారణ నిర్వహణ ట్రాఫిక్ ఇప్పటికీ పని చేస్తుందని నిర్ధారించండి, ఎందుకంటే ప్రమాదవశాత్తు జోడించిన డిఫాల్ట్ మార్గం అప్లికేషన్ విరిగిపోవడానికి చాలా ముందే విరిగిన SSH సెషన్‌గా కనిపిస్తుంది.

ఎంచుకున్న ప్రిఫిక్స్ ద్వారా ప్రయాణం బలవంతపు సొరంగం కంటే చాలా ఇరుకైన మార్పు. దాన్ని ఇరుకుగా ఉంచండి, వెనక్కి తిరగడం అంటే ఒక మార్గాన్ని తొలగించడం.