Azure P2S: VNet మార్పు తర్వాత ఒక Windows క్లయింట్‌కు మార్గాలు పోయాయి

రెండు ల్యాప్‌టాప్‌లు ఒకే Azure point-to-site గేట్‌వేకు ప్రామాణీకరణ చేస్తాయి, కొత్తగా కనెక్ట్ అయిన VNet-ను ఒకటి మాత్రమే చేరుకుంటుంది. రెండూ Connected చూపిస్తాయి, కాబట్టి ప్రామాణీకరణ భేదం కాదు; అవి ఉంచుకునే గమ్య మార్గాలే భేదం. విఫలమయ్యే క్లయింట్ నుండి ప్రారంభించండి, ఒక గమ్యాన్ని పోల్చండి, ఆ తర్వాతే లోటు గేట్‌వే ప్యాకేజీదా లేక స్థానిక మార్గ పట్టికదా అని నిర్ణయించండి.

గేట్‌వే నుండి కాదు, విఫలమయ్యే క్లయింట్ నుండి ప్రారంభించండి

ల్యాప్‌టాప్‌ను నిందించే ముందు టోపాలజీని నిర్ధారించండి. ఏ VNet-లు గేట్‌వే VNet-కు కనెక్ట్ అయ్యాయో, కొత్త నెట్‌వర్క్ నేరుగా పీర్ చేయబడిందో లేక వేరే site-to-site టన్నెల్ ద్వారా చేరుతుందో తనిఖీ చేయండి. కొత్త VNet గేట్‌వే VNet-కు అసలు కనెక్ట్ కాకపోతే, ఏ క్లయింట్ ప్యాకేజీ అక్కడికి మార్గనిర్దేశం చేయలేదు, పని చేస్తున్న ల్యాప్‌టాప్‌ే వివరించవలసిన అసాధారణత. సమాధానం రాయండి, ఎందుకంటే అది మీరు క్లయింట్‌ను డీబగ్ చేస్తున్నారా గేట్‌వేను అని నిర్ణయిస్తుంది.

టోపాలజీ సరిగ్గా ఉన్నప్పుడు రెండు ల్యాప్‌టాప్‌లను పక్కపక్కన ఉంచండి. ఒకే గేట్‌వే, ఒకే చిరునామా పూల్, ఒకే ప్రోటోకాల్ మరియు ఒకే క్లయింట్ బిల్డ్ మీకు కావలసిన పోలిక; మిగతావన్నీ తర్వాత తొలగించాల్సిన రెండవ చరరాశి.

route print తో ఒక గమ్యాన్ని పోల్చండి

అనుమతించిన వనరు IP ఎంచుకుని రెండు ల్యాప్‌టాప్‌లను రెండుసార్లు పోల్చండి: డిస్‌కనెక్ట్ స్థితిలో, ఆపై కనెక్ట్ స్థితిలో. Windows లో route print -4 IPv4 మార్గాలను గమ్య ప్రిఫిక్స్, ఇంటర్‌ఫేస్, తదుపరి హాప్ మరియు మెట్రిక్‌తో జాబితా చేస్తుంది. VPN అనే పదం ఉన్న ఎంట్రీలను లెక్కించడం బదులు ఆ గమ్యానికి నిజంగా గెలిచే వరుసను నమోదు చేయండి.

ఎంపిక మొదట పొడవైన ప్రిఫిక్స్, తర్వాత మెట్రిక్ ప్రకారం జరుగుతుంది, కాబట్టి మరింత నిర్దిష్ట స్థానిక మార్గం తప్పుగా కనిపించకుండా టన్నెల్ మార్గాన్ని ఓడించగలదు. ఉద్దేశించిన గమ్యం 10.24.0.0/16 లో ఉంటే, ఆరోగ్యకరమైన క్లయింట్ VPN ఇంటర్‌ఫేస్‌లో సరిపోయే మార్గాన్ని చూపిస్తుంది, విఫలమయ్యే క్లయింట్ అదే చిరునామాను తన డిఫాల్ట్ గేట్‌వేకు పంపుతుంది.

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

TTL expired మార్గ పంపిణీ బగ్ కాదు

TTL expired in transit తిరిగి ఇచ్చే ping ప్యాకెట్ తన హాప్ కోటాను ఖర్చు చేసిందని చెబుతుంది, దీని అర్థం సాధారణంగా ఫార్వార్డింగ్ లూప్, పాడైన VPN డ్రైవర్ కాదు. Windows ping 255 వరకు TTL అంగీకరిస్తుంది, విలువ పెంచడం లూప్‌ను సరిచేయదు; అదే లోపాన్ని ఆలస్యం చేస్తుంది. సందేశాన్ని మార్గం యొక్క లక్షణంగా పరిగణించండి, మార్గ పంపిణీపై సాక్ష్యంగా కాదు.

మార్గం ఎక్కడ పునరావృతమవుతుందో చూడటానికి tracert -4 10.24.1.10 ఉపయోగించండి. అదే రెండు హాప్‌లు పదేపదే కనిపిస్తే, టన్నెల్ వైపు వెళ్లే ట్రాఫిక్‌ను తిరిగి టన్నెల్‌లోకి లేక దాన్ని తిరిగి పంపే స్థానిక రౌటర్‌లోకి పంపే మార్గాన్ని వెతకండి.

ప్యాకేజీని దాని యజమాని అయిన గేట్‌వేలో మళ్లీ సృష్టించండి

సంబంధిత టోపాలజీ మార్పుల తర్వాత Windows క్లయింట్ ప్యాకేజీలను మళ్లీ డౌన్‌లోడ్ చేసి ఇన్‌స్టాల్ చేయాలని Microsoft నమోదు చేస్తుంది. ఈ ప్రొఫైల్‌కు సేవ చేసే Azure గేట్‌వే నుండి ప్రస్తుత ప్యాకేజీని తీసుకుని, ఆ క్లయింట్ కోసం మద్దతు ఉన్న ప్రక్రియతో వర్తించండి. సంబంధం లేని VPN అప్లికేషన్ ఎగ్జిక్యూటబుల్‌ను భర్తీ చేయడం గేట్‌వే-నిర్దిష్ట సెట్టింగ్‌లను మళ్లీ సృష్టించడంతో సమానమైన పని కాదు. ప్యాకేజీని మళ్లీ డౌన్‌లోడ్ చేయడం చవక; స్థానిక మార్గాలను ఊహించడం కాదు.

మళ్లీ కనెక్ట్ అయి అసలు గమ్యం మార్గాన్ని మళ్లీ చదవండి. మార్పు రికార్డుతో పాటు ముందు మరియు తర్వాత వరుసలను ఉంచండి, దానివల్ల ఫలితం క్లయింట్‌ను మళ్లీ ఇన్‌స్టాల్ చేశాను అనే దానికంటే ఖచ్చితంగా ఉంటుంది.

Azure P2S రూటింగ్ సందర్భాలు నేరుగా పీర్ చేయబడిన VNet-లను ఇతర టన్నెల్‌ల ద్వారా చేరే నెట్‌వర్క్‌ల నుండి వేరు చేస్తాయి, కొత్త ప్యాకేజీ పీరింగ్‌ను అనువర్తనీయం చేయలేదు. కొన్ని Windows site-to-site లేక BGP సందర్భాలకు చేతితో కాన్ఫిగర్ చేసిన రిమోట్ మార్గాలు కూడా అవసరం, కాబట్టి ప్యాకేజీ రిఫ్రెష్ సార్వత్రిక మార్గ పంపిణీ విధానం కాదు.

తాత్కాలిక మార్గాన్ని తాత్కాలికంగా ఉంచండి

మాన్యువల్ మార్గం తప్పిపోయిన క్లయింట్ మార్గాన్ని వేరుచేయగలదు, కానీ దాన్ని నిజమైన డిజైన్ నుండి నిర్మించండి: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, శాశ్వత ఫ్లాగ్ లేకుండా, తద్వారా రీబూట్‌లో అది మాయమవుతుంది. ఇంటర్‌ఫేస్ ఇండెక్స్ మరియు తదుపరి హాప్‌ను కనెక్ట్ అయిన VPN అడాప్టర్ నుండి ఎంచుకోండి, ఊహ నుండి కాదు.

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

సరైన మార్గం సక్రియమైన తర్వాత ping కాదు, లక్ష్య అప్లికేషన్‌ను పరీక్షించండి. ప్యాకెట్‌లు Azure చేరినా సేవ ఇంకా విఫలమైతే, నెట్‌వర్క్ భద్రతా సమూహాన్ని మరియు తిరిగి వచ్చే మార్గాన్ని తనిఖీ చేయండి, ఎందుకంటే అవి ల్యాప్‌టాప్ ప్రిఫిక్స్ నేర్చుకున్నదా లేదా అనే దానికి భిన్నంగా ఉంటాయి.