పీర్ చేసిన Azure VNet కి దాని సొంత VPN గేట్వే అవసరమా?
పీర్ చేసిన VNet మద్దతు ఉన్న SKU మరియు ప్రతి పీరింగ్ దిశలో ఒక సెట్టింగ్తో హబ్ యొక్క VPN గేట్వేను ఉపయోగించవచ్చు. పీరింగ్ స్థితి కాదు, ప్రభావవంతమైన మార్గాలను తనిఖీ చేయండి.
కొత్త spoke VNet కనిపిస్తుంది, hub కు ఇప్పటికే పనిచేస్తున్న site-to-site గేట్వే ఉంది, మరియు స్పష్టమైన ప్రశ్న ఏమిటంటే రెండవ గేట్వే కోసం మీరు చెల్లించాలా. సాధారణంగా లేదు: గేట్వే ట్రాన్సిట్ spoke కు peering ద్వారా hub యొక్క గేట్వేను ఉపయోగించడానికి అనుమతిస్తుంది. ఇది పనిచేస్తుందా అనేది మూడు షరతులు నిర్ణయిస్తాయి, మరియు వాటిలో ఏదీ peering స్థితి బ్యాడ్జ్ నుండి కనిపించదు. peering కనెక్టివిటీ మరియు మరొకరి గేట్వేను ఉపయోగించే అనుమతి వేర్వేరు సెట్టింగ్లు, కాబట్టి ఇప్పటికే ఒకరినొకరు ping చేయగల రెండు VM VPN మార్గం గురించి ఏమీ నిరూపించవు.
మొదటి షరతు: గేట్వే, మరియు spoke లో అది లేకపోవడం
Azure, Basic కాకుండా ఇతర VPN Gateway SKU లకు గేట్వే ట్రాన్సిట్ను మద్దతు ఇస్తుంది, మరియు ప్రాంతీయ మరియు ప్రపంచ peering రెండూ దాన్ని మోయగలవు. spoke తనకు సొంతం కాని గేట్వేను ఉపయోగిస్తుంది, కాబట్టి దానికి సొంత గేట్వే ఉండలేదు: spoke లో ఇప్పటికే గేట్వే ఉంటే, లేదా రిమోట్ గేట్వే ఎంపిక ఇప్పటికే ఎంచుకోబడి ఉంటే, మీరు కోరుకునే ట్రాన్సిట్ సెట్టింగ్ అందుబాటులో ఉండదు లేదా ప్రభావవంతంగా ఉండదు. ఏదైనా డీబగ్ చేయడానికి ముందు దీన్ని తనిఖీ చేయండి, ఎందుకంటే నిష్క్రియ చెక్బాక్స్ లక్షణం, లోపం కాదు. మొదట SKU మరియు ఉన్న గేట్వేను చదవండి, తర్వాత peering సెట్టింగ్లను చూడండి.
ఎంపిక కనిపించడానికి ఉన్న spoke గేట్వేను దానిపై ఏది ఆధారపడి ఉందో తెలిసే వరకు తొలగించవద్దు. స్థానభ్రంశ క్రమం చెక్బాక్స్ కంటే ముఖ్యం.
రెండవ షరతు: ప్రతి peering దిశలో ఒక సెట్టింగ్
peering రెండు వస్తువులు, ప్రతి VNet పై ఒకటి, మరియు ట్రాన్సిట్ సెట్టింగ్లు ఆ జోడీ వేర్వేరు వైపులా ఉంటాయి. hub నుండి spoke వైపు peering, hub గేట్వే spoke కు సేవ చేయడానికి అనుమతించాలి; spoke నుండి hub వైపు peering, hub యొక్క గేట్వేను అంగీకరించాలి. Microsoft యొక్క గేట్వే-ట్రాన్సిట్ మార్గదర్శిని దిశ ప్రకారం వాటికి పేర్లు పెడుతుంది, మరియు వాటిని సరిగ్గా ఉంచడానికి ఇదే ఏకైక మార్గం:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote అని లేబుల్ చేసిన నియంత్రణ మీరు ఏ VNet యొక్క peering ను సవరిస్తున్నారనే దానిపై అర్థాన్ని మారుస్తుంది, కాబట్టి పదం కాదు, దిశను చదవండి. రెండు వైపులా సెట్ చేయండి, సేవ్ చేయండి మరియు peering రెండు ప్రదేశాలలో కనెక్ట్ అయినట్లు నివేదిస్తుందని నిర్ధారించండి.
మూడవ షరతు: చిరునామా స్థలం మరియు అనుమతి సరిహద్దులు
ఒకే గమ్యస్థాన ప్రిఫిక్స్ రెండు నెట్వర్క్లను సూచించేలా ట్రాన్సిట్ చేయలేదు, కాబట్టి hub, spoke మరియు స్థానిక నెట్వర్క్ పరిధులు ఇవి ఏదైనా పనిచేయడానికి ముందు వేరుగా ఉండాలి. VNet లు వేర్వేరు సబ్స్క్రిప్షన్లు లేదా వేర్వేరు టెనెంట్లలో కూడా ఉండవచ్చు; అది నిషేధం కాదు, కానీ ప్రతి peering ను సృష్టించే లేదా నవీకరించే గుర్తింపుకు ఆ నెట్వర్క్లో అవసరమైన అనుమతులు ఉండాలి. సబ్స్క్రిప్షన్ల మధ్య మార్పులు తరచుగా అనుమతిపై విఫలమవుతాయి, మరియు లోపాన్ని టోపోలజీ సమస్యగా తప్పుగా చదవడం సులభం.
మార్పు ముందు పరిధులు మరియు యజమానులను రాయండి. వాటిలో ఏదైనా ఊహించడం కనెక్ట్ అయ్యే కానీ ఏదీ రూట్ చేయని peering ను సృష్టిస్తుంది.
peering స్థితితో కాదు, ప్రభావవంతమైన మార్గాలతో ధృవీకరించండి
spoke వర్క్లోడ్ నెట్వర్క్ ఇంటర్ఫేస్పై ప్రభావవంతమైన మార్గాలను చూసి అసలైన స్థానిక ప్రిఫిక్స్ను కనుగొనండి. సబ్నెట్ రూట్ పట్టిక మరియు గేట్వే రూట్ ప్రచారం నిష్క్రియంగా ఉందో లేదో తనిఖీ చేయండి, ఎందుకంటే వినియోగదారు నిర్వచించిన మార్గం లేదా తనిఖీ పరికరం peering ఫ్లాగ్లు సూచించే మార్గాన్ని అధిగమించవచ్చు. తర్వాత మరో దిశను నిర్ధారించండి: స్థానిక నెట్వర్క్ site-to-site కనెక్షన్ ద్వారా spoke ప్రిఫిక్స్ను చేరుకోవడం ఎలా అనేది తెలిసి ఉండాలి, అది నేర్చుకున్న ప్రకటనల ద్వారా లేదా స్పష్టమైన మార్గం మరియు కస్టమర్ పరికరంలో సరిపోలే రక్షిత-నెట్వర్క్ నమోదు ద్వారా కావచ్చు. ప్రిఫిక్స్ ఏ వైపు లేకపోయినా, మార్చవలసినది peering ఫ్లాగ్లు కాదు.
spoke వర్క్లోడ్ నుండి ఒక సేవను పరీక్షించి ప్రతిస్పందనను అనుసరించండి. VPN గేట్వే లేదా hub VM నుండి పరీక్ష వేరే మూల ప్రిఫిక్స్ మరియు వేరే మార్గాన్ని ఉపయోగిస్తుంది.
టోపోలజీ point-to-site క్లయింట్లకు కూడా సేవ చేస్తే, వారి ఇన్స్టాల్ చేసిన మార్గాలను విడిగా ధృవీకరించండి. టోపోలజీ మార్పు తర్వాత Windows క్లయింట్ ప్యాకేజీలు తిరిగి ఉత్పత్తి చేయవలసి రావచ్చు, మరియు అది గేట్వే భాగస్వామ్యం విఫలమైందని రుజువు కాదు, క్లయింట్ రూటింగ్ పని.
గేట్వే పంచుకోవడం ఏమి ఇవ్వదు
గేట్వే ట్రాన్సిట్ అనేది రూటింగ్ సౌలభ్యం, అధికారం కాదు. నెట్వర్క్ భద్రతా సమూహాలు, స్థానిక ఫిల్టర్లు మరియు సేవా-స్థాయి నియమాలు ఇంకా spoke వర్క్లోడ్ ఎక్కడికి చేరుకోగలదో నిర్ణయిస్తాయి, కాబట్టి పంచుకున్న సొరంగం దాని వెనుక ఉన్న అన్నింటినీ అనుమతిస్తుందని ఊహించడానికి బదులు నిర్దిష్ట మూలం-నుండి-గమ్యం సేవను ప్రారంభించండి.
peering కూడా ప్రజలు ఆశించిన విధంగా ప్రసారమయ్యేది కాదు. మరో spoke లేదా ప్రైవేట్ ఎండ్పాయింట్ను జోడించడం ప్రస్తుత ట్రాన్సిట్ సెట్టింగ్ కవర్ చేయని దాని సొంత రూటింగ్ మరియు యాక్సెస్ అవసరాలను తీసుకొస్తుంది.