VPN-లో అంతర్గత పేర్లు విఫలమవుతాయి, పబ్లిక్ సైట్లు సాధారణంగా పరిష్కరించబడతాయి

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

ఒకే లోపం కాని రెండు లక్షణాలు

అంతర్గత పేరును పరిష్కరించలేకపోవడం అంటే ప్రశ్నకు సమాధానం లేని చోటికి అది వెళ్ళిందని. ప్రశ్నలు టన్నెల్ నుండి బయటకు వెళ్ళడం అంటే సమాధానం అందుబాటులో ఉన్నప్పటికీ ప్రశ్న తప్పు చోటికి వెళ్ళిందని. ఇవి వ్యతిరేక లోపాలు: ఒకటి తప్పిపోయిన సమాధానం, మరొకటి అదనపు గమ్యం.

ఉచ్చు ఏమిటంటే, కార్యాలయ రిజాల్వర్ను ప్రతిచోటా జోడించడం మొదటి దాన్ని సరిచేస్తుంది మరియు రెండవ దాన్ని హామీ చేస్తుంది. పబ్లిక్ రిజాల్వర్ను ప్రతిచోటా జోడించడం దానికి వ్యతిరేకంగా చేస్తుంది.

రెండు పరిశీలనలను సమయ ముద్రతో రాయండి, ఆపై క్రింద ఉన్న నాలుగు తనిఖీలను వరుసగా చేయండి.

ఏ అడాప్టర్ రిజాల్వర్ ప్రశ్నను పొందుతుంది

Windows-లో, DNS క్లయింట్ అడాప్టర్ బైండింగ్ క్రమం ప్రకారం సర్వర్లను ఎంచుకుంటుంది, టన్నెల్ అడాప్టర్ స్వయంచాలకంగా మొదటిది కాదు. అడాప్టర్ యొక్క అధునాతన సెట్టింగ్లను తెరిచి, రిమోట్ యాక్సెస్ కనెక్షన్ను భౌతిక అడాప్టర్ పైకి తరలించి, తిరిగి కనెక్ట్ చేయండి, అప్పుడు మార్పు కొత్త సెషన్కు వర్తిస్తుంది.

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

పని చేసే మెషీన్ యొక్క ipconfig /all ను ల్యాప్టాప్ యొక్క దాని పక్కన ఉంచండి, రెండూ టన్నెల్ పనిచేస్తున్నప్పుడు తీసుకున్నవి. పని చేసే మెషీన్ తన కార్యాలయ అడాప్టర్పై కనెక్షన్-నిర్దిష్ట DNS సఫిక్స్ను చూపుతుంది, ల్యాప్టాప్ టన్నెల్పై ఏదీ చూపకపోవచ్చు. ఆ వ్యత్యాసం "సర్వర్ అక్కడే ఉంది, పేరు ఇప్పటికీ విఫలమవుతుంది" అనే నివేదికల మొత్తం తరగతిని వివరిస్తుంది, ఎందుకంటే సఫిక్స్ లేకుండా చిన్న పేరు కార్యాలయ రిజాల్వర్ అందించే జోన్లోకి ఎప్పటికీ పూర్తి చేయబడదు.

చిన్న పేరుకు మార్గానికి ముందు సఫిక్స్ అవసరం

అర్హత లేని హోస్ట్నేమ్ టైప్ చేయడం రిజాల్వర్ను ఒక డొమైన్ను ఊహించమని అడుగుతుంది. ఊహ కనెక్షన్కు జోడించిన సఫిక్స్ జాబితా నుండి వస్తుంది, ఆ జాబితా ఖాళీగా ఉంటే, ఏ ప్రైవేట్ జోన్ సరిపోలని ఒకే లేబుల్గా ప్రశ్న బయటకు వెళ్తుంది.

పని చేసే మెషీన్ యొక్క సఫిక్స్ను DNS ట్యాబ్లో VPN అడాప్టర్ యొక్క IPv4 లక్షణాలలోకి కాపీ చేసి, తర్వాత తిరిగి కనెక్ట్ చేయండి. Linux-లో దీనికి సమానమైనది టన్నెల్ లింక్పై ఉన్న సెర్చ్ డొమైన్, దాన్ని systemd-resolved ప్రపంచవ్యాప్తంగా కాకుండా లింక్ వారీగా బహిర్గతం చేస్తుంది.

రెండు సెట్టింగ్లను మీ నోట్స్లో వేరుగా ఉంచండి. సఫిక్స్ ఏమి అడగబడుతుందో మారుస్తుంది; రిజాల్వర్ చిరునామా ఎవరిని అడగబడుతుందో మారుస్తుంది. ఒకటి తప్పుగా ఉన్నప్పుడు మరొకటి సరిచేయడం యాదృచ్ఛికంగా అనిపించే ఫలితాన్ని ఇస్తుంది.

రిజాల్వర్ను నేరుగా అడగండి, తర్వాత పేరును

కార్యాలయ రిజాల్వర్కు నేరుగా ప్రశ్న పేరు సమస్యను మార్గ సమస్య నుండి వేరు చేస్తుంది, ఎందుకంటే ఇది క్లయింట్ యొక్క రిజాల్వర్ ఎంపికను పూర్తిగా దాటవేస్తుంది.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

మొదటి ఆదేశం నిర్దిష్ట సర్వర్ను పూర్తిగా అర్హత కలిగిన పేరు గురించి అడుగుతుంది. అది సమాధానమిస్తే, రిజాల్వర్ మరియు దానికి మార్గం సరిగ్గా ఉన్నాయి, లోపం ఎంపికలో లేదా సఫిక్స్లో ఉంది. సమయం ముగిస్తే, చిరునామా తప్పు లేదా చేరుకోలేనిది మరియు సమస్య DNS కాదు, రూటింగ్. రెండవ ఆదేశం చిన్న పేరుతో ఏమి జరుగుతుందో చూపుతుంది, మూడవది systemd హోస్ట్పై లింక్ వారీగా రిజాల్వర్ కాన్ఫిగరేషన్ను ముద్రిస్తుంది.

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

Linux-లో, తిరిగి రాసే VPN క్లయింట్ /etc/resolv.conf స్థానిక రిజాల్వర్లను పూర్తిగా భర్తీ చేస్తుంది. దాన్ని ఆపడానికి vpnc DNSUpdate no ను బహిర్గతం చేస్తుంది, మరియు systemd-resolved జాబితా చేసిన డొమైన్లను మాత్రమే టన్నెల్ లింక్కు మార్గనిర్దేశం చేయగలదు. రెండు విధానాలు పబ్లిక్ పేర్లను స్థానిక రిజాల్వర్ వద్ద ఉంచుతూ అంతర్గత పేర్లను కార్యాలయానికి పంపుతాయి.

లీక్లు ఒక నియమం, చెక్బాక్స్ కాదు

పేరు పరిష్కారం అనేది పోర్ట్ 53కి UDP మార్పిడి, కాబట్టి వెబ్ ట్రాఫిక్ను మోస్తుంది కానీ UDPని కాదు అనే టన్నెల్ ప్రశ్నను భౌతిక మార్గంలో వదిలివేస్తుంది. పబ్లిక్ పేరు పరిష్కరించబడుతున్నప్పుడు భౌతిక NICపై క్యాప్చర్ చేయడం ద్వారా నిరూపించండి. ఆ ఇంటర్ఫేస్పై చదవగల రూపంలో కనిపించే ప్రశ్న అంటే టన్నెల్ దాన్ని మోసుకెళ్లడం లేదు.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

ప్రశ్న ఆ ఇంటర్ఫేస్పై చదవగల రూపంలో కనిపిస్తే, టన్నెల్ దాన్ని మోసుకెళ్లడం లేదు. VPN పుష్ చేసిన రిజాల్వర్కు మాత్రమే పోర్ట్ 53ని అనుమతించి ఇతర గమ్యాలను వదిలించే నియమం, పుష్ చేసిన ఎంపికను నిశ్శబ్దంగా విస్మరించని క్లయింట్ కాన్ఫిగరేషన్ కలిసి మరమ్మత్తు.

చివరి భాగం కనిపించే దాని కంటే ముఖ్యం. OpenVPNను route-nopull తో ప్రారంభిస్తే, పుష్ చేసిన DNS ఎంపిక మార్గాలతో పాటు అదృశ్యమవుతుంది, పుల్ ఫిల్టర్ దాన్ని ఉంచడానికి విస్తరించకపోతే. మరియు dhcp-option DNS ను విస్మరించే క్లయింట్ మునుపు ఉన్నదాన్ని ఉపయోగించడం కొనసాగిస్తుంది. సర్వర్ వైపు ఏ మార్పు అయినా అమలులోకి రావడానికి కొత్త సెషన్ అవసరం, ఎందుకంటే రిజాల్వర్ జాబితా టన్నెల్ లేచినప్పుడు ఇవ్వబడుతుంది మరియు పాత సెషన్ పాత స్థితినే చూపుతూనే ఉంటుంది.

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