Azure P2S VPN రిటర్న్ ట్రాఫిక్ ఒక దిశలో మాత్రమే పనిచేస్తుంది

టన్నెల్ చిహ్నం ఆకుపచ్చగా ఉంది, NSG అనుమతిస్తున్నట్లు కనిపిస్తోంది, ప్రభావవంతమైన మార్గాలు సరిగ్గా కనిపిస్తున్నాయి, అయినప్పటికీ VM కనెక్ట్ అయిన క్లయింట్కు తిరిగి కనెక్షన్ తెరవలేదు. సాధారణ ఊహ ఏమిటంటే, పనిచేసే point-to-site టన్నెల్ సమమితీయంగా ఉంటుంది: క్లయింట్ VM ను చేరుకుంటే, VM కూడా క్లయింట్ను చేరుకుంటుంది. ఆ ఊహే తార్కికంలోని తప్పు, కాన్ఫిగరేషన్లో కాదు. టన్నెల్ అభ్యర్థించని ప్రవాహం యొక్క ఒక దిశను తీసుకెళ్లి మరొకటి వదిలివేయగలదు, మరియు సరిదిద్దడం ఏ పొర దానిని వదిలివేస్తుంది అనే దానిపై ఆధారపడి ఉంటుంది.

అపోహ: కనెక్ట్ అయిన టన్నెల్ ద్విదిశా టన్నెల్

VPN టన్నెల్ అనేది విధాన మార్గం, తీగ కాదు. ప్రతి దిశ సెలెక్టర్లు, మార్గాలు మరియు ఫిల్టర్లతో సరిపోల్చబడుతుంది, వాటిలో ఏదైనా ఒక దిశను అనుమతించి మరొకదాన్ని నిరోధించగలదు.

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

చేరుకోగలిగే సామర్థ్యాన్ని పరీక్షించే ముందు దిశను పరీక్షించండి

ఒక క్లయింట్ చిరునామా, ఒక VM చిరునామా మరియు ఒక ప్రోటోకాల్ ఎంచుకోండి. క్లయింట్ నుండి కనెక్ట్ అయి ఫలితాన్ని నమోదు చేయండి; తర్వాత అదే పరీక్షను VM నుండి ప్రారంభించి దాన్ని కూడా నమోదు చేయండి. మొదటిది విజయవంతమై రెండవది విఫలమైతే, క్లయింట్ పూల్, గేట్వే అనుబంధం మరియు క్లయింట్ నుండి VNet వరకు మార్గం అన్నీ పనిచేస్తున్నాయి.

తదుపరి అడుగు సాక్ష్యం, మరిన్ని నియమాలు కాదు. VM సబ్నెట్లోని NSG ను రెండు దిశలలో తనిఖీ చేయండి, VM NIC పై ప్రభావవంతమైన మార్గాలను చదవండి, మరియు క్లయింట్ ట్రాఫిక్ పంపుతున్నప్పుడు VM పై ప్యాకెట్లను క్యాప్చర్ చేయండి. ప్రతిస్పందన లేకుండా వచ్చే అభ్యర్థన ఫిల్టర్ లేదా తిరిగి వచ్చే మార్గ సమస్య; ఎప్పటికీ రాని అభ్యర్థన మార్గ సమస్య. విఫలమైన ping ను VM చేరుకోలేని దానికి సాక్ష్యంగా పరిగణించవద్దు, ఎందుకంటే TCP పనిచేస్తున్నప్పుడు ICMP విధానం ప్రతిస్పందనను వదిలివేయగలదు.

IKEv2 point-to-site తిరిగి వచ్చే మార్గమే సాధారణ అనుమానితుడు

ఈ వ్యాసం వెనుక ఉన్న Azure నివేదికలో, ఒక క్లయింట్ IKEv2 ద్వారా VM లను చేరుకోగలిగింది, కానీ VM నుండి క్లయింట్కు వచ్చే ICMP, గేట్వే టన్నెల్ రకం OpenVPN కు మార్చే వరకు విఫలమైంది. నివేదిక రచయిత మైక్రోసాఫ్ట్ IKEv2 point-to-site మార్గంలో పరిమితిని ధృవీకరించిందని చెప్పారు: క్లయింట్ సెషన్ ప్రారంభించకపోతే VM నుండి క్లయింట్కు తిరిగి వచ్చే ట్రాఫిక్ సమమితీయంగా రూట్ చేయబడదు. IKEv2 ట్రాఫిక్ సెలెక్టర్లపై ఆధారపడి ఉంటుంది, మరియు ఆ సందర్భంలో గేట్వే తిరిగి వచ్చే దిశను గౌరవించలేదు.

అది OpenVPN ను సాధారణంగా మెరుగైన టన్నెల్ రకంగా మార్చదు. అది ఈ పనిభారానికి పరీక్ష మాత్రికలో టన్నెల్ రకాన్ని చరంగా మారుస్తుంది.

టన్నెల్ రకాన్ని మార్చడం సేవా మార్పు, టోగుల్ కాదు. ప్రతి క్లయింట్కు సరిపోయే ప్రొఫైల్ అవసరం, మరియు గేట్వేకు వేరే సర్టిఫికెట్ లేదా ప్రామాణీకరణ సెటప్ అవసరం కావచ్చు. ఒక పరీక్ష క్లయింట్ మరియు ఒక పరీక్ష VM తో ఏకదిశా ప్రవర్తనను తిరిగి ఉత్పత్తి చేయండి, ఆమోదించిన షెడ్యూల్ ప్రకారం రకాన్ని మార్చండి, ఆపై అదే దిశా పరీక్షలను పునరావృతం చేయండి. మార్పు తర్వాత కూడా ప్రవర్తన కొనసాగితే, టన్నెల్ రకం కారణం కాదు మరియు ఉత్పత్తిని తాకకుండా సమస్యను సంకుచితం చేసారు.

అపోహ: బ్రాడ్కాస్ట్ అన్వేషణ VNet అంచును దాటుతుంది

రెండవ ఊహ సంబంధం లేని కారణంతో విఫలమవుతుంది. Azure వర్చువల్ నెట్వర్క్ బ్రాడ్కాస్ట్ ట్రాఫిక్ను తీసుకెళ్లదు, కాబట్టి VM site-to-site లేదా point-to-site కనెక్షన్ ద్వారా ఆన్-ప్రిమైస్ నెట్వర్క్ నుండి బ్రాడ్కాస్ట్ ఫ్రేమ్లను స్వీకరించలేదు. బ్రాడ్కాస్ట్ ద్వారా తోటివారిని కనుగొనే అప్లికేషన్లు, ఉదాహరణకు పాత ఫైల్ బ్రౌజింగ్ లేదా కొన్ని పరికర-అన్వేషణ ప్రోటోకాల్లు, మార్గాలు ఎలా రాసినా దూరపు వైపును ఎప్పటికీ చూడవు.

బ్రాడ్కాస్ట్ అన్వేషణను DNS పేర్లు, డైరెక్టరీ సేవ లేదా స్పష్టమైన తోటివారి జాబితాతో భర్తీ చేయండి. అప్లికేషన్కు unicast ప్రత్యామ్నాయం లేకపోతే, డిజైన్కు విస్తృత టన్నెల్ కాదు, వేరే అన్వేషణ యంత్రాంగం అవసరం.

ఏమి మార్చాలి, దాన్ని ఎలా నిరూపించాలి

దిశా పరీక్ష IKEv2 పై మాత్రమే విఫలమైతే, గేట్వే టన్నెల్ రకం, క్లయింట్ చిరునామా పూల్ మరియు ఖచ్చితమైన ICMP లేదా TCP పరీక్షను నమోదు చేయండి, తర్వాత ప్రభావిత క్లయింట్ల కోసం ఆమోదించిన OpenVPN ప్రొఫైల్ను అంచనా వేయండి. ప్రతి టన్నెల్ రకంలో విఫలమైతే, తిరిగి వచ్చే మార్గంపై పని చేయండి: క్లయింట్ చిరునామా VM సబ్నెట్ నుండి రూట్ చేయదగినదిగా ఉండాలి, వినియోగదారు నిర్వచించిన ఏదైనా మార్గం చెల్లుబాటు అయ్యే తదుపరి హాప్ వైపు చూపాలి, మరియు క్లయింట్ ఫైర్వాల్ లోపలికి వచ్చే ప్రవాహాన్ని అంగీకరించాలి. NSG మరియు మార్గాల సాక్ష్యాలను టికెట్కు జోడించండి.

ping తో కాదు, అప్లికేషన్తో ధృవీకరించండి. మార్పు తర్వాత విజయవంతమైన ICMP మార్పిడి సేవా పోర్ట్, దాని ప్రామాణీకరణ లేదా పేరు పరిష్కారం గురించి ఏమీ చెప్పదు. మళ్లీ కనెక్ట్ అయిన తర్వాత పరీక్షను పునరావృతం చేయండి, ఎందుకంటే పూల్ నుండి వేరే చిరునామా పొందిన క్లయింట్ ఫలితాన్ని మార్చగలదు. తర్వాత క్లయింట్ నిద్రపోయి మేల్కొన్న తర్వాత మరోసారి పునరావృతం చేయండి, ఎందుకంటే పునఃప్రారంభమైన సెషన్లోనే ఏకదిశా ప్రవర్తన తరచుగా మళ్లీ కనిపిస్తుంది.