WireGuard DNS પુશ કરતું નથી: ખાનગી BIND ઝોનની સેવા

તમે 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 સંદર્ભ ઉપર વપરાયેલા સાંભળવા અને ક્વેરી નિયંત્રણોને આવરી લે છે, અને તમારા સ્થાપિત સંસ્કરણ માટે વર્તનની પુષ્ટિ કરવાનું આ જ યોગ્ય સ્થાન છે.

આગળનું પગલું: ઝોનની સીરિયલ વૃદ્ધિ અને તપાસ આદેશો તમારી ફેરફાર પ્રક્રિયામાં ઉમેરો, જેથી કોઈ રેકોર્ડ સંપાદન તપાસ્યા વિના ઉત્પાદન સુધી ન પહોંચે.