openfortivpn నిరంతరం DNS ను తిరిగి రాస్తోందా? నిజమైన యజమానిని కనుగొనండి

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

క్రింది క్రమం క్లయింట్ను బయటికి అనుసరిస్తుంది: కనెక్షన్ ఏమి మార్చింది, ఏ స్విచ్ ఏ రచయితను అణచివేస్తుంది, ఎవరు బాధ్యత తీసుకోవాలి, మరియు ఫలితం తిరిగి కనెక్ట్ అయినప్పుడు నిలిచి ఉంటుందని ఎలా ధృవీకరించాలి. ప్రతి దశ వేరే జాడను వదిలిస్తుంది, ఆ జాడే బదిలీ నిజంగా జరిగిందా లేదా అని మీకు చెబుతుంది.

కనెక్షన్ నిజంగా ఏమి మార్చిందో దానితో ప్రారంభించండి

మీ సాధారణ ఆదేశంతో ఒకసారి కనెక్ట్ అయి ముందు మరియు తర్వాత పరిష్కారాన్ని పోల్చండి. systemd-resolved నడిపే Linux హోస్ట్పై, resolvectl status ప్రతి లింక్కు DNS సర్వర్లు మరియు శోధన డొమైన్లను ముద్రిస్తుంది, మరియు తన సొంత సర్వర్లను మోసుకెళ్ళే కొత్త tun లేదా ppp లింక్ క్లయింట్ వైపు నవీకరణ యొక్క వేలిముద్ర. macOS లో, scutil --dns రిజాల్వర్ కాన్ఫిగరేషన్ను అనువర్తనాలు దానిని సంప్రదించే క్రమంలో చూపిస్తుంది.

దానిని మీరు మారుతుందని ఆశించిన ఫైల్తో పోల్చండి. ప్రతి లింక్ వీక్షణలోని కనెక్షన్-బద్ధమైన నమోదు మరియు తిరిగి రాయబడిన /etc/resolv.conf రెండు వేర్వేరు ఫలితాలు, మరియు రెండవది పూర్తిగా వేరే ఏదో నిర్వహించే సింబాలిక్ లింక్ కావచ్చు. రిజాల్వర్ చిరునామా, శోధన డొమైన్లు మరియు ఇంటర్ఫేస్ పేరును అదే క్షణంలో నమోదు చేయండి; వాటిలో ఏదైనా మారితే వేరే రచయితను సూచిస్తుంది. ఆ ఆధార రేఖ లేకుండా, ప్రతి తదుపరి సవరణ మూడు భాగాలలో ఏది కదిలిందో అనే ఊహ మాత్రమే.

రెండు స్విచ్లు మరియు ప్రతి ఒక్కటి అణచివేసే రచయిత

openfortivpn తాను నియంత్రించగల రెండు రచయితలను ఆఫ్ చేసే ఎంపిక శకలాన్ని డాక్యుమెంట్ చేస్తుంది, మరియు ప్రతి స్విచ్కు మాన్యువల్ అదే సెట్టింగ్గా పరిగణించే పూర్తిగా రాసిన సమానమైనది ఉంది.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns క్లయింట్ గేట్వే నుండి నేర్చుకున్న DNS సర్వర్లను వర్తింపజేయడాన్ని ఆపుతుంది, అయితే --pppd-no-peerdns pppd సహచరుడి DNS ను సిస్టమ్లోకి తోసేయడాన్ని ఆపుతుంది. upstream మాన్యువల్ PPP ద్వారా DNS నవీకరణలు క్లయింట్ యొక్క స్వంత DNS నవీకరణలతో పోటీపడవచ్చని హెచ్చరిస్తుంది, కాబట్టి రెండింటిలో ఒకటి సరిపోతుందని భావించడం బదులు రెండు స్విచ్లు శకలంలో ఉండాలి.

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

ఏదైనా నిలిపివేయడానికి ముందు యజమానిని ఎంచుకోండి

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

మార్గ యాజమాన్యం ఉద్దేశపూర్వకంగా విడిగా ఉంటుంది. DNS మార్చినందున మార్గ ఎంపికలు అవసరం లేదు, మరియు ప్రత్యామ్నాయాన్ని ఇన్స్టాల్ చేయకుండా మార్గ సంస్థాపనను నిలిపివేయడం మీరు ఇప్పుడే ఎంచుకున్న రిజాల్వర్ను చేరుకోలేనిదిగా చేయవచ్చు. రూటింగ్ పట్టికలో ప్రత్యేకంగా రిజాల్వర్ చిరునామా కోసం చూడండి, మీరు యాదృచ్ఛికంగా పరీక్షించిన అనువర్తన సబ్నెట్ కోసం మాత్రమే కాదు.

పరిష్కారాన్ని ప్రతి ఫైల్కు కాదు, ప్రతి లింక్కు తనిఖీ చేయండి

పరిమిత లేదా డొమైన్ వారీ పరిష్కారం ఉన్న హోస్ట్పై అనువర్తనాలు నిజంగా ఏమి ఉపయోగిస్తాయనే జాబితా ఒక /etc/resolv.conf కాదు, కాబట్టి ప్లాట్ఫారమ్ రిజాల్వర్ స్థితిని బహిర్గతం చేసే విధంగానే చదవండి.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

మళ్ళీ కనెక్ట్ అయి డిస్కనెక్ట్ స్థితిని ధృవీకరించండి

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

తర్వాత మళ్ళీ కనెక్ట్ అయి అదే మూడు విలువలను చదవండి: రిజాల్వర్ చిరునామా, శోధన డొమైన్లు, ఇంటర్ఫేస్.

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