OpenVPN పంపిన DNS నిర్లక్ష్యం చేయబడుతోంది: ఏ భాగం దాన్ని వర్తింపజేస్తుంది

పంపిన DNS ఎంపిక క్లయింట్కు పర్యావరణ చరంగా మాత్రమే చేరుతుంది. Linux, Windows, macOS లలో పేర్ల పరిష్కారం ఎవరి వద్ద ఉందో తనిఖీ చేసి, తర్వాత మార్గాన్ని పరీక్షించండి.

లాగ్ సర్వర్ పంపిన ఎంపికను చూపుతుంది, సొరంగం నడుస్తోంది, లోపలి పేర్లు ఇంకా విఫలమవుతున్నాయి. రిజాల్వర్కు నేరుగా చేసిన క్వెరీ జవాబిస్తుంది, కాబట్టి సర్వర్ బాగానే ఉంది, కానీ ప్రతి అప్లికేషన్ స్థానిక రౌటర్ను అడుగుతూనే ఉంది. క్లయింట్కు చేరినది ప్రతిపాదన, రిజాల్వర్లో మార్పు కాదు, పేర్ల పరిష్కారాన్ని కలిగి ఉన్న భాగం Linux, Windows, macOS లలో భిన్నంగా ఉంటుంది. ఎంపికను దాని యజమాని నుండి వేరు చేసిన తర్వాత, నాలుగు లోపాలు దాదాపు ప్రతి నివేదికను కవర్ చేస్తాయి: హుక్ లేదు, రెండు పోటీ హుక్లు, విభజిత DNS రూపకల్పన ప్రకారం పనిచేస్తోంది, లేదా సర్వర్ కాకుండా సఫిక్స్ అవసరమయ్యే చిన్న పేరు.

పంపిన ఎంపిక ప్రతిపాదన, ఇన్స్టాలేషన్ కాదు

సర్వర్లో, రెండు సూచనలు ప్రభావాన్ని కాక, ఉద్దేశాన్ని వివరిస్తాయి:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

క్లయింట్కు కాన్ఫిగర్ చేసిన రిజాల్వర్ రాదు. దానికి పర్యావరణ చరాలు వస్తాయి, foreign_option_1 మరియు తర్వాతివి, పంపిన ప్రతి పంక్తికి ఒకటి, మరియు స్థానికంగా ఏదో వాటిని చదివి ఆపరేటింగ్ సిస్టమ్ రిజాల్వర్ స్థితిని తిరిగి రాయాలి. Linux లో అప్రయత్నంగా ఏదీ అలా చేయదు, అందుకే సరైన సర్వర్ మరియు కనెక్ట్ అయిన క్లయింట్ ఇంకా LAN ద్వారా పేర్లను పరిష్కరించగలవు.

రెండు చివరల మధ్య మూడు దశలు ఉన్నాయి: పుష్ చేరాలి, క్లయింట్ దాన్ని బహిర్గతం చేయాలి, మరియు ఒక హుక్ దాన్ని వర్తింపజేయాలి. మధ్య దశను క్లయింట్ లాగ్లో, చివరి దశను రిజాల్వర్ స్థితిలో చదవండి, ఎప్పుడూ వ్యతిరేకంగా కాదు, ఎందుకంటే ఒక లాగ్ పంక్తి మొదటి రెండింటిని మాత్రమే నిరూపిస్తుంది.

పుష్ చేరిందని నిర్ధారించి యజమానిని కనుగొనండి

ప్రారంభకుడిని పేర్కొనడంతో ప్రారంభించండి: ఒక బేర్ openvpn కమాండ్, systemd ఇన్స్టాన్స్, NetworkManager లేదా విక్రేత క్లయింట్. ఇది హుక్ ఎక్కడ నివసించగలదో నిర్ణయిస్తుంది. systemd-resolved ఉన్న హోస్ట్లో, resolvectl status ప్రతి లింక్ను అది నిజంగా ఉపయోగించే DNS సర్వర్లు మరియు శోధన డొమైన్లతో జాబితా చేస్తుంది, మరియు సొరంగం లింక్ పేరు ఎప్పుడూ tun0 అని ఉండదు.

పంపిన చిరునామా లాగ్లో ఉన్నా ఏ లింక్లోనూ లేకపోతే, ఏకీకరణ లేదు. అది లింక్లో ఉన్నా క్వెరీలు ఇంకా వేరే చోటికి వెళ్తుంటే, సమస్య ఏ క్వెరీలు ఆ లింక్ను ఎంచుకుంటాయి అనేది. NetworkManager dns=dnsmasq ఫైల్లో /etc/NetworkManager/NetworkManager.conf స్థానిక ఫార్వర్డర్ను నడుపుతుంది, అది విభజిత DNS ను ఉద్దేశపూర్వకంగా అమలు చేస్తుంది: VPN డొమైన్ లోపలి పేర్లు VPN రిజాల్వర్కు వెళ్తాయి, మిగిలినవన్నీ తమ మునుపటి మార్గాన్ని ఉంచుకుంటాయి. మొత్తం ట్రాఫిక్ కదులుతుందని ఆశించినప్పుడు ఈ ప్రవర్తన లోపంలా కనిపిస్తుంది; కనెక్షన్ ప్రకారం సెట్టింగ్లను తనిఖీ చేయండి nmcli connection show "My VPN" తో, ఇక్కడ ipv4.dns మరియు ipv4.dns-search పరికరం నివేదించే దాని వెనుక ఉన్న విలువలను ఉంచుతాయి, దాన్ని పాడైనది అని పిలిచే ముందు. ప్రతి క్వెరీ నిజంగా VPN రిజాల్వర్ను చేరుకోవాలంటే, తీసివేయండి dns=dnsmasq ను NetworkManager.conf ఫైల్ నుండి మరియు NetworkManager ను పునఃప్రారంభించండి, అది పేర్ల పరిష్కారాన్ని కనెక్షన్ సెట్టింగ్లకు తిరిగి ఇస్తుంది; లేకపోతే విభజిత DNS ఉంచి పంపిన డొమైన్ జాబితాను సరిచేయండి.

Linux: ఎంపికలను రిజాల్వర్కు అప్పగించండి

పంపిణీ ప్యాకేజీలు దీనికి హుక్ ఇస్తాయి, క్లయింట్కు దాన్ని నడపడానికి అనుమతి ఉండాలి. systemd-resolved లేని హోస్ట్లో సాధారణ అమరిక:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved తో పాత resolv.conf స్క్రిప్ట్ ముఖ్యమైనది ఏదీ మార్చకపోవచ్చు, ఎందుకంటే stub రిజాల్వర్ ప్రతి లింక్కు స్థితిని ఉంచుతుంది. update-systemd-resolved సహాయకుడు ఉపయోగించే హుక్ రూపాన్ని డాక్యుమెంట్ చేస్తుంది up-restart మరియు down-pre, ఇది ఇంటర్ఫేస్ ఒక కనెక్షన్ ప్రయత్నం కంటే ఎక్కువ కాలం నిలిచినప్పుడు ముఖ్యం. మీరు ఏది ఎంచుకున్నా, స్థితి యాజమాన్యం ఒక భాగానికే ఉండాలి. NetworkManager పక్కన సంబంధం లేని హుక్ జోడిస్తే అదే లింక్కు ఇద్దరు రచయితలు అవుతారు, అప్పుడు ఫలితం మీ కాన్ఫిగరేషన్పై కాక, క్రమంపై ఆధారపడుతుంది.

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

Windows మరియు macOS వేర్వేరు భాగాలను వర్తింపజేస్తాయి

Windows క్లయింట్ VPN అడాప్టర్ DNS సర్వర్లను నిజంగా సెట్ చేస్తుంది, కానీ Windows ఇంకా మెట్రిక్ ద్వారా ఇంటర్ఫేస్ను ఎంచుకుంటుంది మరియు చిన్న పేరును విస్తరించడానికి ఇంకా సఫిక్స్ కావాలి. ప్రొఫైల్ కాక, అడాప్టర్ స్థితిని నిర్ధారించండి:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

చిరునామా లేకపోతే, దీనితో సెట్ చేయండి Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, తర్వాత అడాప్టర్ IPv4 లక్షణాలకు సఫిక్స్ జోడించండి, తద్వారా fileserver అవుతుంది fileserver.corp.example. యంత్రం వ్యాప్తంగా SearchList విలువ Tcpip\Parameters కింద అదే చేస్తుంది. పొడవైన పేరు పరిష్కారమై, బేర్ పేరు కాకపోయిన చోట, రిజాల్వర్ ఇప్పటికే సరైనది మరియు తప్పు శోధన జాబితాది. సరిదిద్దులు క్రమంగా: పంపండి DOMAIN క్లయింట్ సఫిక్స్ నేర్చుకోవడానికి, ఆ సఫిక్స్ను అడాప్టర్ లేదా కనెక్షన్ శోధన జాబితాకు జోడించండి, మరియు తాత్కాలిక చర్యగా పేరును ఇక్కడ స్థిరపరచండి hosts ఫైల్లో, లేదా LMHOSTS లో Windows లో; NetBIOS బ్రౌజింగ్ రౌటర్ను దాటదు, కాబట్టి కార్యాలయ LAN లో చిన్న పేరును కనుగొనే ప్రసారం ఎప్పుడూ సొరంగం క్లయింట్కు చేరదు.

block-outside-dns block-outside-dns అనేది Windows క్లయింట్ ప్రవర్తన, తరలించగల ప్రొఫైల్ పంక్తి కాదు, దాన్ని Linux లేదా macOS ప్రొఫైల్కు కాపీ చేయడం అక్కడ దాన్ని పునరుత్పత్తి చేయదు. Windows లో పబ్లిక్ పేర్లు పనిచేసి అంతర్గత పేర్లు విఫలమైతే, ఆధునిక సెట్టింగ్ల కింద అడాప్టర్ క్రమాన్ని దీనితో పోల్చండి ipconfig /all. macOS లో సేవకు రిజాల్వర్ క్రమం సిస్టమ్కు చెందుతుంది, కాబట్టి ఉపయోగించండి scutil --dns ఏ డొమైన్కు ఏ రిజాల్వర్ అడగబడుతుందో చూడటానికి, మరియు నివేదించిన ఏ ఒక్క ప్రొఫైల్ సరిదిద్దును సాధారణం కాక, క్లయింట్ ఆధారితంగా పరిగణించండి.

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

చరిత్ర మూడవ కారణం. మునుపటి ప్రొఫైల్ DNS సర్వర్లు లేదా సఫిక్స్ సెట్టింగ్లు పునఃకనెక్షన్లను తట్టుకోగలవు, కాబట్టి అడాప్టర్ సరిగ్గా కనిపిస్తున్నా శోధనలు ఇంకా విఫలమైతే, సజీవ అడాప్టర్ను దీనితో పోల్చండి Get-VpnConnection మరియు సర్వర్ను తాకే ముందు పాత నమోదును తొలగించండి లేదా తిరిగి రాయండి.

క్వెరీ ఎక్కడికి వెళ్ళిందో నిరూపించండి

ఒక శోధన సమయంలో చేసిన క్యాప్చర్ వాదాన్ని తీరుస్తుంది: tcpdump -ni eth0 port 53 భౌతిక ఇంటర్ఫేస్పై క్వెరీలను చూపుతుంది, అంటే అవి సొరంగం వెలుపలికి వెళ్తున్నాయి మరియు రిజాల్వర్ ఎప్పుడూ మార్చబడలేదు. dig @10.8.0.1 name.corp.example తర్వాత మిగిలిన రెండు సందర్భాలను వేరు చేస్తుంది. నేరుగా క్వెరీ జవాబిస్తే, రిజాల్వర్ పనిచేస్తోంది మరియు క్లయింట్ దాన్ని వాడటం లేదు; సమయం ముగిస్తే, రిజాల్వర్ సొరంగం ద్వారా అందుబాటులో లేదు మరియు ఏ స్థానిక మార్పూ సహాయపడదు.

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

అందుబాటులో VPN హోస్ట్ ఫైర్వాల్ కూడా ఉంటుంది, అది పూల్ నుండి UDP మరియు TCP 53 కి అనుమతి ఇవ్వాలి. మూసిన పోర్ట్ సరిగ్గా పాడైన పుష్లా కనిపిస్తుంది, సొరంగం నెట్వర్క్ లోపలి నుండి మాత్రమే జవాబిచ్చే రిజాల్వర్ కూడా అలాగే. ఒకసారి డిస్కనెక్ట్ చేసి మళ్లీ కనెక్ట్ చేసిన తర్వాత క్యాప్చర్ను పునరావృతం చేయండి, ఎందుకంటే మొదటి కనెక్షన్లో కనిపించి రెండవదానిలో మాయమయ్యే సెట్టింగ్లు హుక్లోని జీవితకాల లోపం, తప్పిపోయిన ఎంపిక కాదు.

ఒక యజమానిని ఉంచి క్రమంగా ధృవీకరించండి

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

నాలుగు తనిఖీలతో చక్రాన్ని మూసివేయండి: పంపిన చిరునామా సొరంగం లింక్పై ఉంది, అంతర్గత పేరు పూర్తి అర్హత పేరుగా పరిష్కారమవుతోంది, అదే పేరు సఫిక్స్ లేకుండా పరిష్కారమవుతోంది, మరియు ఒక పునఃకనెక్షన్ తర్వాత కూడా రెండూ నిజం. ఒక క్యాప్చర్ నాలుగింటిలో ఏది విఫలమైందో చెబుతుంది. OpenVPN 2.6 చేతిపుస్తకం జాబితా చేస్తుంది dhcp-option మరియు స్క్రిప్ట్ సూచనలను వాటి ప్లాట్ఫారం గమనికలతో.

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