ટનલ ઉપર આવ્યા પછી, છેલ્લું પગલું સામાન્ય રીતે એક નામ હોય છે જે બુકમાર્કમાં પેસ્ટ કરેલા સરનામાને બદલે કામ કરે છે. dnsmasq હોસ્ટ રેકોર્ડ અને ક્લાયંટ પહોંચી શકે એવું resolver સરનામું બે ફાઇલો અને multicast વગર આ કરે છે. જે નિર્ણયને ખરેખર વિચાર જોઈએ છે તે વધુ સાંકડો છે: ક્લાયંટ બધું DNS હોમ resolver દ્વારા મોકલે છે, કે ફક્ત home.arpa હેઠળનાં નામો? નીચેનું બધું Linux ક્લાયંટ અને હોમ એડમિનિસ્ટ્રેટર પહેલેથી સંભાળતા લેબ resolver સાથે મંજૂર કરેલા WireGuard સેટઅપને ધારે છે.

ક્લાયંટને resolver આપવાની ત્રણ રીતો

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

જે લેપટોપ ક્યારેક ટનલમાં જોડાય છે તેના માટે split-DNS સારો ડિફોલ્ટ છે: તે સામાન્ય ઇન્ટરનેટ નામોને મશીન પહેલેથી વિશ્વાસ કરતા resolver પર રાખે છે. જે મશીન હોમ સેવાઓ સુધી પહોંચવા માટે જ છે તેના માટે resolver ધકેલવો સરળ છે અને વ્યાપની કિંમત મહત્વની નથી.

ઝોન ધરાવતા resolver પર રેકોર્ડ પ્રકાશિત કરો

રૂપરેખા લખતા પહેલાં ભૂમિકાઓ અલગ રાખો: VPN ક્લાયંટ સરનામું, resolver અને સેવા ત્રણ અલગ કામો સાથેનાં ત્રણ અલગ હોસ્ટ છે. આ લેબમાં તે ક્લાયંટ માટે 10.77.0.2, dnsmasq માટે 192.168.50.53 અને NAS માટે 192.168.50.20 છે, અને ટનલ હોમ LAN ને રૂટ કરે છે.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

host-record લીટી સરનામું આપે છે અને local= લીટી અજાણ્યા home.arpa પ્રશ્નોને ઉપર મોકલવાને બદલે આ resolver ની અંદર રાખે છે. પહેલાં તમારી હાલની રૂપરેખા વાંચો અને જે પહેલેથી સર્વર, ઇન્ટરફેસ કે એ જ સ્થાનિક ડોમેન વ્યાખ્યાયિત કરે છે તે બધું સુસંગત કરો; વિરોધાભાસી ટુકડા પર બીજો ટુકડો ચઢાવવાથી એવો resolver બને છે જે આનંદથી લોડ થાય અને ખોટો જવાબ આપે. dnsmasq મેન્યુઅલ બંને નિર્દેશો અને સાંભળવાના નિયંત્રણો વ્યાખ્યાયિત કરે છે.

પછી ફાઇલ નહીં, ચાલતી સેવા ચકાસો. રૂપરેખા પરીક્ષણ અને રીસ્ટાર્ટ લઘુત્તમ છે, અને અસરકારક જવાબ એ છે જે ક્વેરી પરત આપે છે.

resolver ને રૂટ કરો, ફક્ત વેબ પેજ નહીં

WireGuard નું AllowedIPs નક્કી કરે છે કે કયા લક્ષ્યો ટનલમાં પ્રવેશે. જો resolver સરનામું તેની બહાર પડે, તો ક્વેરી સામાન્ય માર્ગે નીકળી જાય છે અને dnsmasq સુધી ક્યારેય પહોંચતી નથી, જોકે NAS પોતે પહોંચી શકાય એવું છે. resolver નું સરનામું કે તેને સમાવતું LAN પ્રીફિક્સ ઉમેરો, અને બીજી બાજુ ગેટવેની ફોરવર્ડિંગ નીતિ ચકાસો.

અધિકૃત ટનલ શ્રેણીમાંથી પોર્ટ 53 પર UDP અને TCP ને મંજૂરી આપો, ક્લાયંટના ટનલ સરનામા સુધી પરત માર્ગ સાથે. પરીક્ષણ સરળ બનાવવા WAN થી પોર્ટ 53 ફોરવર્ડ કરશો નહીં: ઘરના કનેક્શન પર ખુલ્લું રિકર્સિવ resolver કલાકોમાં મળી જાય છે. ઇન્ટરફેસ સાથે બાંધવું એ પોતે જ એક્સેસ નીતિ નથી.

એપ્લિકેશન પહેલાં જવાબ ચકાસો

પહેલાં સીધા resolver ને પૂછો, પછી સિસ્ટમને, પછી એપ્લિકેશનને. દરેક પગલું સાંકળની એક કડી અલગ કરે છે, અને તેમની વચ્ચેનો તફાવત જ નિદાન છે.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

TCP ક્વેરી ચલાવવી યોગ્ય છે, કારણ કે કપાયેલો UDP જવાબ ફરી પ્રયાસ કરવાની ફરજ પાડે છે, અને TCP 53 ફેંકી દેતી નીતિ એવી નિષ્ફળતાઓ ઉત્પન્ન કરે છે જે વારાફરતી દેખાય છે. getent પગલું બતાવે છે કે મશીનની resolver રૂપરેખા ખરેખર શું કરે છે, જે હંમેશા તમે ધકેલ્યું હોય તે નથી.

ટનલ બંધ હોય ત્યારે શું થાય તે નક્કી કરો

જો ક્લાયંટનું સામાન્ય DNS 192.168.50.53 તરફ ઇશારો કરે, તો ટનલ ઉપર ન હોય ત્યારે દરેક નામ રિઝોલ્યુશન કામ કરવાનું બંધ કરે છે. આ એવા મશીન પર સ્વીકાર્ય છે જે ફક્ત ટનલ સાથે ઉપયોગી છે, અને એવા લેપટોપ પર અસ્વીકાર્ય છે જે કાફેનું Wi-Fi પણ વાપરે છે. Split-DNS પ્રશ્નને સંપૂર્ણપણે ટાળે છે, કારણ કે ફક્ત home.arpa લુકઅપ હોમ resolver પર આધાર રાખે છે.

યાદ રાખો કે નામ શું છે: home.arpa રહેણાંક નેટવર્ક માટે અનામત છે અને વૈશ્વિક રીતે અનન્ય નથી, તેથી બીજું નેટવર્ક કાયદેસર રીતે એ જ નામ વાપરી શકે છે. તે સ્થાનિક સુવિધા છે, વિશ્વસનીય ઓળખકર્તા નહીં. સેવા ખસે ત્યારે રેકોર્ડ અદ્યતન રાખો, અને લેબ નિવૃત્ત થાય ત્યારે resolver નીતિ દૂર કરો, એવા લેપટોપને છોડવાને બદલે જે એવા સરનામા તરફ ઇશારો કરે છે જ્યાં તે ફક્ત એવી ટનલ દ્વારા પહોંચી શકે છે જે હવે અસ્તિત્વમાં નથી.

સંબંધિત લેખો