Azure VPN ప్రిఫిక్స్ జోడించడం వల్ల కనెక్షన్ ఎందుకు తెగిపోతుంది

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

మూడు ఆబ్జెక్ట్‌లు, వాటిలో ఒకటి ప్రిఫిక్స్‌ను ఉంచుతుంది

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

గుర్తుంచుకోవాల్సిన మూడవ షరతు కూడా ఉంది. GatewaySubnet నిర్వహించబడే గేట్‌వే ఇన్‌స్టాన్సులను హోస్ట్ చేస్తుంది, సరిగ్గా ఆ పేరును కలిగి ఉండాలి, మరియు Basic కాని SKUలకు కనీసం /27 ఉండాలని ఆశిస్తారు.

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

కనెక్షన్‌నే ఎందుకు తొలగిస్తారు

కనెక్షన్ ఆబ్జెక్ట్ చర్చించిన కాన్ఫిగరేషన్‌ను దాని పూర్తి జీవితకాలానికి స్థిరపరుస్తుంది. అందుకే డాక్యుమెంట్ చేసిన విధానం మొదట కనెక్షన్‌ను తొలగిస్తుంది, స్థానిక నెట్‌వర్క్ గేట్‌వేను నవీకరిస్తుంది, ఆపై అదే పంచుకున్న కీతో కనెక్షన్‌ను తిరిగి సృష్టిస్తుంది. ప్రిఫిక్స్ మార్పుకు మాత్రమే గేట్‌వే ఇన్‌స్టాన్సులు తిరిగి నిర్మించబడవు, ఇది అంతరాయాన్ని గేట్‌వే పునఃనియోగానికి బదులు కనెక్షన్ విచ్ఛిన్నానికి పరిమితం చేస్తుంది.

ఆ తొలగింపే అంతరాయం, కాబట్టి దాన్ని త్వరిత సవరణకు బదులు ప్రారంభం మరియు ఆశించిన ముగింపు ఉన్న ప్రణాళికాబద్ధ మార్పుగా పరిగణించండి. PowerShellలో క్రమం చిన్నది: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, ఆపై Set-AzLocalNetworkGateway కొత్త -AddressPrefix శ్రేణితో, ఆపై New-AzVirtualNetworkGatewayConnection అదే -SharedKey మరియు అదే గేట్‌వేలతో. కీని తిరిగి ఉపయోగించడం ముఖ్యం, ఎందుకంటే రిమోట్ వైపు తిరిగి కాన్ఫిగర్ చేయబడదు మరియు కొత్త కీ అంటే రిమోట్ పరికరాన్ని కలిగి ఉన్నవారితో సమన్వయం. ఆ పరికరాన్ని మరో జట్టు నడుపుతుంటే, ఏదైనా తొలగించే ముందు వారితో సమయ విండోను అంగీకరించండి.

గేట్‌వేను స్వయంగా ఎప్పుడు తిరిగి నిర్మించాలి

ఈ సమస్య చుట్టూ తిరిగే రెండవ సమాధానం గేట్‌వేను తిరిగి సృష్టించి కీని మళ్లీ మార్పిడి చేయాలని చెబుతుంది. అది వేరే కార్యకలాపాల సమితికి సరైనది: గేట్‌వే రకం లేదా SKU మార్చడం, పాయింట్-టు-సైట్ మరియు సైట్-టు-సైట్ మధ్య మారడం, లేదా తన స్వంత కాన్ఫిగరేషన్ తప్పుగా ఉన్న గేట్‌వేను మరమ్మతు చేయడం. అలాంటి మార్పులు గేట్‌వే వనరును నిజంగా మారుస్తాయి, కాబట్టి తిరిగి నిర్మించడం నిజంగా అవసరం.

పాయింట్-టు-సైట్ కోసం సృష్టించిన గేట్‌వేకు సైట్-టు-సైట్ కనెక్షన్‌ను సులభంగా ఇవ్వలేరు. పాయింట్-టు-సైట్ కాన్ఫిగరేషన్‌ను తొలగించి గేట్‌వేను తిరిగి సృష్టించాలి, ఇది కొత్త పంచుకున్న కీ మరియు కొత్త క్లయింట్ ప్యాకేజీని కూడా ఇస్తుంది.

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

స్థితిని చదవండి, పోర్టల్ బ్యాడ్జ్ కాదు

పోర్టల్‌లోని బ్యాడ్జ్‌కు బదులు వనరు నుండి స్థితిని చదవండి. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 తిరిగి ఇస్తుంది ConnectionStatus ఇన్‌గ్రెస్ మరియు ఎగ్రెస్ బైట్ కౌంటర్లతో పాటు, కనెక్ట్ అయినా ఏమీ మోయని టన్నెల్‌ను ఎప్పుడూ స్థాపించబడని టన్నెల్ నుండి వేరు చేసేది ఈ కౌంటర్లే.

బదిలీ మధ్యలో పెరుగుదల ఆపే కౌంటర్లు ప్రమాణీకరణను కాదు, మార్గాన్ని సూచిస్తాయి. అసలు కదలని కౌంటర్లు ప్రిఫిక్స్ సెట్ లేదా పంచుకున్న కీని సూచిస్తాయి.

VPNపై తప్పుగా ఆరోపించబడే ఒక రకమైన డిస్కనెక్ట్‌లను టైమర్లు వివరిస్తాయి. Azure లోడ్ బ్యాలెన్సర్ తన కాన్ఫిగర్ చేసిన సమయ పరిమితి తర్వాత నిష్క్రియ ప్రవాహాలను మూసివేస్తుంది, ఈ నోట్లు రాసినప్పుడు డిఫాల్ట్‌గా నాలుగు నిమిషాలు మరియు పైకి కాన్ఫిగర్ చేయవచ్చు, కాబట్టి keepalive లేని VMలో OpenVPN సర్వర్ కొన్ని నిమిషాలకు ఒకసారి పడిపోవచ్చు, మిగతావన్నీ ఆరోగ్యంగా కనిపిస్తున్నప్పుడు. ప్లాట్‌ఫారమ్ చక్రీయంగా పునఃప్రారంభించే గేట్‌వే కూడా VNet కనెక్షన్‌ను Web Appకు అంతరాయం కలిగించవచ్చు, మరియు ఆ వైఫల్యం క్లయింట్ కాన్ఫిగరేషన్‌లో కాదు, ప్లాట్‌ఫారమ్ వైపు ఉంది. సూచన ఏమిటంటే డిస్కనెక్ట్ స్థిర విరామాన్ని అనుసరిస్తుందా లేదా మీరు చేసిన మార్పును అనుసరిస్తుందా అనేది.

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

తర్వాత మీరు మార్చిన క్రమంలోనే ధృవీకరించండి: స్థానిక నెట్‌వర్క్ గేట్‌వే కొత్త ప్రిఫిక్స్ జాబితాను చూపిస్తుంది, కనెక్షన్ తిరిగి Connectedగా ఉంది, మరియు కొత్త పరిధిలోని హోస్ట్‌కు ట్రాఫిక్ పంపినప్పుడు కౌంటర్లు కదులుతాయి. మొదటి రెండు పాస్ అయినా మూడవ దశ విఫలమైతే, రిమోట్ వైపు కొత్త ట్రాఫిక్ ఎంపికదారును అంగీకరించలేదు మరియు రిమోట్ పరికరానికి సరిపోయే దశ 2 నమోదు అవసరం. అది టన్నెల్ మరో చివరతో జరిపే సంభాషణ, Azureలో మరో మార్పు కాదు.