WireGuard DNS ను పుష్ చేయదు: ఒక ప్రైవేట్ BIND జోన్‌ను అందించడం

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

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

టన్నెల్ మరియు రిజాల్వర్ వేర్వేరు ఒప్పందాలు

WireGuard ఉద్దేశపూర్వకంగా చిన్నది. మీరు జాబితా చేసిన చిరునామాలకు ప్యాకెట్లను కదిలిస్తుంది మరియు పీర్లను ధృవీకరిస్తుంది; ఆ పొర పైన ఉన్నదంతా మీ రూపకల్పన. OpenVPN dhcp-option DNS పుష్ చేయగలదు ఎందుకంటే దాని నియంత్రణ ఛానెల్ కాన్ఫిగరేషన్‌ను మోస్తుంది, మరియు ఆ భేదం రెండింటి మధ్య తిరిగేవారిని తడబడేలా చేస్తుంది.

కాబట్టి పనిచేసే టన్నెల్ పేరు పరిష్కారం గురించి ఏమీ చెప్పదు. క్లయింట్‌కు 10.90.0.1 వరకు పరిపూర్ణ మార్గం ఉండి కూడా తన ప్రశ్నలను పబ్లిక్ రిజాల్వర్‌కు పంపవచ్చు, అందుకే లక్షణం “VPN DNS ను పాడుచేసింది” లాగా కనిపిస్తుంది, కానీ DNS ఎప్పుడూ VPN వైపు చూపబడలేదు.

పునరావృత రిజాల్వర్ కాకుండా జోన్‌ను అందించండి

సర్వర్ వైపు ఒక చిన్న అధికారిక జోన్, సాధారణ రిజాల్వర్ కాదు. ఈ ఉదాహరణలో గేట్‌వే 10.90.0.1, క్లయింట్లు 10.90.0.0/24, మరియు మీకు ముఖ్యమైన అప్లికేషన్ 10.60.0.20 వద్ద సమాధానం ఇస్తుంది.

రెండవ బ్లాక్ సృష్టించే బదులు ఈ సెట్టింగ్‌లను ఇప్పటికే ఉన్న options బ్లాక్‌లో విలీనం చేయండి:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

తర్వాత జోన్ మరియు దాని ఫైల్‌ను ప్రకటించండి:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

మళ్లీ లోడ్ చేయడానికి ముందు ధృవీకరించండి, ఎందుకంటే లోడ్ సమయంలో వాక్యనిర్మాణ లోపం అది అందించే ప్రతి జోన్‌కు మొత్తం సర్వర్‌ను కిందికి దింపుతుంది:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP మరియు TCP 53 ను VPN ఇంటర్‌ఫేస్‌లో మాత్రమే తెరవండి. పబ్లిక్ ఇంటర్‌ఫేస్‌లో ప్రైవేట్ అధికారాన్ని ప్రచురించడం ప్రశ్నలు మరియు గణన రెండింటినీ ఆహ్వానిస్తుంది, మరియు సెకండరీకి నిజంగా అవసరం లేకపోతే allow-transfer మూసి ఉండాలి.

క్లయింట్‌ను దాని వైపు మళ్లించండి, ప్రతి లింక్‌కు

కనెక్షన్ NetworkManager స్వంతం అని మరియు రిజాల్వర్ systemd-resolved అని ఊహించండి. మొదట ఉన్న విధానాన్ని చదవండి, ముఖ్యంగా ఏదైనా మూల రూటింగ్ డొమైన్, ఎందుకంటే ~. ఎంట్రీ మీరు జోడించబోయే దానిని మించిపోతుంది.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

టిల్డే ముఖ్యమైన అక్షరం. అది డొమైన్‌ను మార్గం-మాత్రమే అని గుర్తిస్తుంది: corp.example కింద ఉన్న పేర్లు ఈ లింక్ DNS సర్వర్‌కు వెళ్తాయి, మరియు డొమైన్ పొట్టి పేరు శోధన ప్రత్యయంగా జోడించబడదు. అది లేకుండా, portal టైప్ చేయడం portal.corp.example ను పరిష్కరించడం ప్రారంభిస్తుంది, ఇది మీకు సౌకర్యం మరియు మిగిలిన అందరికీ ఆశ్చర్యం. టిల్డేను కోట్స్ లోపల ఉంచండి, ఎందుకంటే కోట్స్ లేనిది మీ హోమ్ డైరెక్టరీని చూపించడానికి ఎదురుచూస్తున్న షెల్ విస్తరణ.

ఇంటర్‌ఫేస్‌ను కలిగి ఉన్న మేనేజర్ ద్వారా మార్పును వర్తింపజేయండి, తర్వాత కనెక్షన్‌ను మళ్లీ కలపండి. అదే ఇంటర్‌ఫేస్‌కు రెండవ wg-quick ఇన్‌స్టాన్స్ ప్రారంభించవద్దు; ఇద్దరు యజమానులు మార్గాల కోసం పోరాడతారు మరియు వారిలో ఒకరు అత్యంత చెడ్డ క్షణంలో గెలుస్తారు.

పేరు కంటే ముందు మార్గాన్ని ధృవీకరించండి

క్లయింట్ నుండి పేరును ప్రశ్నించి, సమాధానం మరియు దాన్ని ఉత్పత్తి చేసిన సర్వర్ రెండింటినీ నిర్ధారించండి:

resolvectl query portal.corp.example

అది 10.60.0.20 ఇస్తే, DNS ఒప్పందం పూర్తయింది. సమయం ముగిస్తే, మొదట 10.90.0.1కి మార్గం, తర్వాత ఫైర్‌వాల్ నియమం, తర్వాత సర్వర్‌లో allow-query తనిఖీ చేయండి. ఈ సెటప్‌లో పేరు పరిష్కార వైఫల్యాలు దాదాపు ఎప్పుడూ చేరుకోగల సామర్థ్యం లేదా ACL, జోన్ ఫైల్ కాదు. క్లయింట్ నుండి బయటకు పని చేయండి, ఎందుకంటే ప్రశ్న ఎందుకు ఎప్పుడూ రాలేదో సర్వర్ మీకు చెప్పలేదు.

అప్లికేషన్‌కు ఇంకా దాని స్వంత మార్గం మరియు దాని స్వంత సేవా అనుమతి అవసరం అని గుర్తుంచుకోండి. చేరుకోలేని చిరునామాను చూపించే పరిష్కరించిన పేరు అదే దుస్తులలో మరో వైఫల్యం.

ఇంకా స్వయంచాలకం కానివి

తమ స్వంత రిజాల్వర్ తర్కం ఉన్న అప్లికేషన్లు సిస్టమ్ రిజాల్వర్‌ను పూర్తిగా విస్మరిస్తాయి, ఎంత nmcli ఉన్నా అది మార్చదు. DNSSEC ధృవీకరించే డిప్లాయ్‌మెంట్‌లకు ప్రైవేట్ జోన్ కోసం స్పష్టమైన నమ్మకపు యాంకర్ రూపకల్పన అవసరం; ధృవీకరణను ఆపివేయమని చెప్పే సర్వవ్యాప్త సూచన సమాధానం కాదు. మీ వినియోగదారులు నడిపే అదే క్లయింట్ సాఫ్ట్‌వేర్‌తో పరీక్షించండి, యాదృచ్ఛికంగా సిస్టమ్ రిజాల్వర్‌ను ఉపయోగించే సాధనంతో కాదు. ఆ రెండింటి మధ్య ఉన్న గ్యాప్ మొత్తం బగ్ నివేదిక.

ఫ్లీట్లు తమ ప్రొవిజనింగ్ సిస్టమ్ ద్వారా ఈ క్లయింట్ విధానాన్ని స్వయంచాలకం చేయగలవు, కానీ విధానం యజమాని కలిగిన ప్రత్యేక వస్తువుగానే ఉంటుంది. BIND 9 సూచన పైన ఉపయోగించిన వినడం మరియు ప్రశ్న నియంత్రణలను కవర్ చేస్తుంది, మరియు మీరు ఇన్‌స్టాల్ చేసిన సంస్కరణకు ప్రవర్తనను నిర్ధారించడానికి సరైన స్థలం అదే.

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

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