OpenVPN ఒక DNS సర్వర్ను పంపింది, కానీ Linux దానిని విస్మరిస్తుంది

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

తనిఖీ ఒకటి: కనెక్షన్ ఎలా ప్రారంభమవుతుంది

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

కమాండ్-లైన్ ప్రక్రియ తనంతట తానే NetworkManager కనెక్షన్ కాదు, మరియు NetworkManager కనెక్షన్ తనంతట తానే resolv.conf రాసినది కాదు. ఆ రెండు ఊహలే ఈ దర్యాప్తులో వృథా అయిన చాలావరకు గంటలను వివరిస్తాయి. మీరు నిజంగా చూస్తున్న ఇంటర్ఫేస్ కోసం ఏ భాగం DNS ప్రచురిస్తుందో అడగండి.

కొనసాగించే ముందు యజమానిని రాసుకోండి. తర్వాతి ప్రతి తనిఖీ దానిపై ఆధారపడి ఉంటుంది.

తనిఖీ రెండు: రిజాల్వర్ లింక్ నిజంగా ఏమి కలిగి ఉంది

systemd-resolved హోస్ట్లో, resolvectl status ప్రతి లింక్ను దాని DNS సర్వర్లు మరియు డొమైన్లతో జాబితా చేస్తుంది. టన్నెల్ లింక్ను కనుగొని దాని నమోదులను చదవండి, మరియు ఇంటర్ఫేస్ పేరు tun0 అని ఊహించవద్దు, ఎందుకంటే సంఖ్యాకరణం సృష్టి క్రమాన్ని అనుసరిస్తుంది. పంపిన చిరునామా లింక్లో లేకపోతే, విఫలమైనది క్వెరీ కాదు, బదిలీ.

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

ఏ నిర్ణయానికైనా రాకముందు రిజాల్వర్ అవుట్పుట్లోని లింక్ పేరును VPN లాగ్లోని ఇంటర్ఫేస్ పేరుతో పోల్చండి. అక్కడ అసమానత సాధారణంగా లాగ్ లైన్ మరో ప్రక్రియ నుండి వచ్చిందని అర్థం.

తనిఖీ మూడు: పేర్ల స్థలం ఆ లింక్ను ఎంచుకుంటుందా

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

డొమైన్ కేటాయింపును తనిఖీ చేయండి, సర్వర్ చిరునామా మాత్రమే కాదు. ~corp.example గా రాసిన డొమైన్ రూటింగ్ డొమైన్, మరియు టిల్డే గుర్తు పేరు ఎలా సరిపోలుతుందో మారుస్తుంది.

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

తనిఖీ నాలుగు: ఒక యజమాని, ఇద్దరు కాదు

NetworkManager ఇప్పటికే VPN మరియు రిజాల్వర్ స్థితిని నిర్వహిస్తుంటే, సంబంధం లేని హుక్ స్క్రిప్ట్ను జోడించడం పోటీ పడే రచయితలను సృష్టిస్తుంది. ప్యాకేజీ systemd-resolved కోసం అందించే హుక్ మద్దతు ఉన్న ఇంటిగ్రేషన్, మరియు అది నిర్దిష్ట జీవిత చక్రాన్ని ఆశిస్తుంది: script-security 2, up మార్గం, up-restart, down మార్గం మరియు down-pre. ఆ ఎంపికలు నమోదు మరియు తొలగింపు మొదటి కనెక్షన్లో మాత్రమే కాకుండా సరైన క్షణాలలో జరిగేలా చేస్తాయి.

గైడ్ నుండి కాపీ చేసిన ఉదాహరణకు బదులు ప్యాకేజీ నుండి ఇన్స్టాల్ చేసిన మార్గాన్ని ఉపయోగించండి. అనుమతులు కూడా ముఖ్యం, ఎందుకంటే హుక్ అధికారాలు తగ్గిన తర్వాత అమలవుతుంది.

దాని అవుట్పుట్ లక్ష్యాన్ని మార్చడానికి పంపిణీ రిజాల్వర్ స్క్రిప్ట్ను సవరించడం ఒక హోస్ట్ యొక్క పరిష్కారాన్ని నమోదు చేస్తుంది. అది సాధారణ మరమ్మతు కాదు.

తనిఖీ ఐదు: మళ్లీ కనెక్ట్ చేసిన తర్వాత అదే ఫలితం

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

మళ్లీ కనెక్షన్లో ఐదు తనిఖీలు దాటినప్పుడే పంపిన సెట్టింగ్లు వాడుకలో ఉన్నాయని మీరు చెప్పగలరు. అంతకు ముందు ఏదైనా అదృష్ట క్షణపు స్నాప్షాట్ మాత్రమే.