మొబైల్ నెట్వర్క్ నుండి ప్రతిస్పందించినా సోఫా నుండి విఫలమయ్యే VPN సర్వర్ సాధారణంగా ధృవపత్రం సమస్య కాదు. LAN లోపల ఉన్న క్లయింట్, గమ్యం రౌటర్ స్వంత పబ్లిక్ చిరునామా అయిన ప్యాకెట్ను అనువదించమని రౌటర్ను అడుగుతుంది, అంటే ప్యాకెట్ బయటకు వెళ్లి వెంటనే తిరిగి లోపలికి రావాలి. ఈ యుక్తిని హెయిర్పిన్నింగ్ అంటారు, మరియు చాలా రౌటర్లు దాన్ని అమలు చేయవు లేదా చెక్బాక్స్ ప్రారంభించినప్పుడు మాత్రమే చేస్తాయి. బయటి పరీక్ష పాస్ కావడమే గందరగోళానికి కారణం, ఎందుకంటే అది శ్రోత మరియు ఫార్వార్డింగ్ నియమం సరిగ్గా ఉన్నాయని నిరూపిస్తుంది.

ప్యాకెట్ బయటకు వెళ్లి తిరిగి లోపలికి వస్తుంది

ప్యాకెట్ను అనుసరించండి. క్లయింట్ పబ్లిక్ పేరును పరిష్కరిస్తుంది, పబ్లిక్ చిరునామాకు కనెక్ట్ అవుతుంది, మరియు రౌటర్ గమ్య NAT గమ్యాన్ని అంతర్గత సర్వర్కు తిరిగి రాస్తుంది. సర్వర్ ప్రతిస్పందన క్లయింట్ LAN చిరునామాకు చిరునామా చేయబడింది, కాబట్టి మూలాన్ని తిరిగి అనువదించే NAT నియమాన్ని ఎప్పుడూ దాటకుండా రౌటర్ LAN ఇంటర్ఫేస్ ద్వారా తిరిగి వెళ్తుంది.

ఇప్పుడు క్లయింట్ తాను ఎప్పుడూ ఏమీ పంపని చిరునామా నుండి ప్యాకెట్ను స్వీకరించి దాన్ని విసిరేస్తుంది. ఆ అసమానత్వమే మొత్తం లోపం.

RFC 4787 ఈ సందర్భంలో NAT నుండి ఆశించే ప్రవర్తనను వివరిస్తుంది, మరియు సంక్షిప్త రూపం ఏమిటంటే సిద్ధాంతంలో నిర్దేశించబడిన చోట కూడా ఆచరణలో ఇది ఐచ్ఛికం. కొన్ని రౌటర్లు ఈ సెట్టింగ్ను NAT loopback అంటారు, మరికొన్ని హెయిర్పిన్ NAT లేదా NAT reflection అంటారు, కొన్ని ఏమీ చూపవు. ఇది లేని రౌటర్ తప్పుగా కాన్ఫిగర్ చేయబడలేదు; అది సాధారణ పని చేస్తోంది, పరిష్కారం మరెక్కడో ఉంది. స్థానిక పరీక్ష విఫలమైందని పబ్లిక్ ఫార్వార్డింగ్ నియమం తప్పు అని నిర్ధారించవద్దు.

తనిఖీ 1: రెండు మార్గాలను విడివిడిగా పరీక్షించండి

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

ఖచ్చితమైన స్థానిక పరీక్ష హోస్ట్నేమ్ను ఉంచి చిరునామాన్ని మాత్రమే భర్తీ చేస్తుంది: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ సరైన సర్వర్ పేరును ప్రదర్శిస్తూనే అభ్యర్థనను పబ్లిక్ చిరునామాకు పంపుతుంది. ఇది పేరు పరిష్కార సమస్యను అనువాద సమస్య నుండి వేరు చేస్తుంది, అదే పేరు కెఫే నుండి పనిచేసినప్పుడు రెండూ సులభంగా గందరగోళానికి గురవుతాయి. క్లయింట్ TCP కనెక్షన్లో విఫలమవుతుందా లేదా తర్వాత TLSలో అని గమనించండి, ఎందుకంటే మొదటిది అనువాదాన్ని, రెండవది గుర్తింపును సూచిస్తుంది.

తనిఖీ 2: సర్వర్ ఏమి చూస్తుందో చదవండి

అత్యంత ఉపయోగకరమైన పరిశీలన సర్వర్ దృష్టికోణం. VPN హోస్ట్లో క్లయింట్ LAN చిరునామా మరియు రౌటర్ LAN చిరునామాకు ఫిల్టర్ చేసిన క్యాప్చర్ను అమలు చేసి, తర్వాత స్థానిక ప్రయత్నాన్ని పునరావృతం చేయండి. ఏమీ రాకపోతే, ప్యాకెట్ అనువాదాన్ని తట్టుకోలేదు.

కనెక్షన్ క్లయింట్ చిరునామా నుండి కాకుండా రౌటర్ LAN చిరునామా నుండి వస్తే, హెయిర్పిన్నింగ్ జరుగుతోంది మరియు మూలం తిరిగి రాయబడింది. ఇది పనిచేసే కాన్ఫిగరేషన్, లోపం కాదు.

తనిఖీ 3: బయటి మార్గాన్ని తాకకుండా సరిదిద్దండి

మూడు మద్దతు ఉన్న రూపాలు ఉన్నాయి, ప్రభావ వ్యాసార్థం పెరిగే క్రమంలో. అత్యంత సన్నటి విభజిత DNS: అంతర్గత రికార్డును ప్రచురించి అదే సర్వర్ పేరు LAN లోని క్లయింట్లకు అంతర్గత చిరునామాకు పరిష్కరించబడేలా చేయండి, ఇది పబ్లిక్ మార్గాన్ని పూర్తిగా నివారిస్తుంది. తర్వాతది రౌటర్ యొక్క డాక్యుమెంట్ చేసిన loopback లేదా reflection ఎంపికను ప్రారంభించి దాన్ని ఈ సేవకు మాత్రమే వర్తింపజేయడం. అత్యంత విస్తృతమైనది రౌటర్పై source-NAT నియమం, అది LAN నుండి వచ్చే ట్రాఫిక్ను సర్వర్కు తిరిగి రాసి ప్రతిస్పందన రౌటర్ ద్వారా తిరిగి వచ్చేలా చేస్తుంది; Linux రౌటర్లో అది సర్వర్ చిరునామా మరియు పోర్ట్కు సరిపోయే MASQUERADE నియమం POSTROUTING అవుతుంది. మూడూ బయటి మార్గాన్ని తాకకుండా ఉంచుతాయి, సంరక్షించవలసిన లక్షణం అదే.

స్థానిక మార్గాన్ని బయటి మార్గంలా చేయడానికి సంబంధం లేని పోర్ట్ ఫార్వార్డింగ్ను విస్తరించవద్దు, సమస్యను తప్పించుకోవడానికి సేవను మరో పోర్ట్కు తరలించవద్దు. రెండు మార్పులూ లోపలి ప్రపంచం మాత్రమే చూసేదాన్ని సరిచేయడానికి బయటి ప్రపంచం చేరగలిగేదాన్ని మారుస్తాయి.

విభజిత DNSలో పేర్కొనదగిన ఒక ఉచ్చు ఉంది. హోస్ట్నేమ్ను ఏకపక్ష IPతో భర్తీ చేయడం క్లయింట్ ఏమి ధృవీకరిస్తుందో మారుస్తుంది, కాబట్టి అంతర్గత రికార్డు ఇప్పటికీ ధృవపత్రంలోని పేరుతో సరిపోలాలి.

తనిఖీ 4: తర్వాత రెండు మార్గాలను ధృవీకరించండి

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

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

సంబంధిత వ్యాసాలు