એડગાર્ડ હોમ તમારા લેાન એડ્રેસમાંથી વાયરगार્ડ ક્લાયંટ્સને ઉત્તર આપે છે

સુંધો ખોલાયો છે, ફાયરવોલ પોર્ટ 53 ને મંજૂરી આપે છે, AdGuard હોમ ચાલી રહ્યું છે, અને તેમ છતાં WireGuard ક્લાઈન્ટ માટે નામ ન ઉકેલાય. ક્વેરી સામાન્ય રીતે પહોંચે છે અને જવાબ સામાન્ય રીતે જાય છે, તેથી રિઝોલ્વર પર પેકેટ કાઉન્ટર્સ સારી સ્થિતિમાં દેખાય છે અને સર્વિસ નિર્ભય લાગે છે. જે ખોટું થાય છે તે એ જવાબ પરના સ્રોત સરનામું છે: તે એવી સ્થાનિક એડ્રેસમાંથી જાય છે જેને ક્લાઈન્ટે ક્યારેય માંગ્યું ન હતું, અને ક્લાઈન્ટનું સ્ટબ રિઝોલ્વર તેને ફેંકી આપે છે. AdGuard હોમની કન્ફિગરેશનમાં એક સૂચિ આ નક્કી કરે છે, અને તેની સામાન્ય ડિફૉલ્ટ શક્યતા.kernelને આ નિર્ણય આપતી હોય છે.

ક્વેરી પહોંચે છે, જવાબ ક્યાંક બીજું સ્થાન છોડે છે

એક ક્લાયંટ જે 10.6.0.1 ને તેના રિઝોલ્વર તરીકે કોન્ફિગર કર્યું છે તે એક UDP ક્વેરી 10.6.0.1 પોર્ટ 53 પર મોકલે છે. તે પેકેટ ટનલને પાર કરીને હોસ્ટ પર પહોંચે છે, અને AdGuard હોમ તેનો જવાબ આપે છે. વાયર પર, તેમ છતાં, જવાબ નવો પેકેટ હોય છે જેના સ્ત્રોતએડ્રેસ હોસ્ટના સ્ટેક દ્વારા પસંદ કરવામાં આવે છે, ક્લાયંટની અપેક્ષાથી નહીં.

જ્યારે ક્લાયંટનો રિઝોલ્વર કનેક્ટ થયેલ સોકેટ હોય, જે સિસટમડ-રીઝોલ્વડ, dnsmasq અને મહત્તમ સ્ટબ રિઝોલ્વર્સ દ્વારા વપરાય છે, ત્યારે તે માત્ર એચ ત્યારક એડ્રેસમાંથી જ જવાબ સ્વીકારી લે છે જેના પર તે મોકલેલ હતું. 192.168.1.10 પરથી ક્વેરી 10.6.0.1 પર મોકલેલ જવાબ કોઈપણ પાર્સિંગ કરતા પહેલાં જ નકારી દેવામાં આવે છે. રિઝોલ્વર સફળ જવાબને લોગ કરે છે, ક્લાયંટ ટાઈમઆઉટ લોગ કરે છે, અને બંને સાચાઈ બતાવે છે.

તો ગણકો ખોટા નથી બોલતા અને ક્લાઈન્ટ પણ નથી. તમને જે સાબિતી જોઈએ તે ત્રણ જગ્યાએ છે, આ ક્રમમાં: તે સરનામું જેના માટે સાંભળનારો બાંધી રહ્યો છે, તે માર્ગ જે કર્નલ ક્લાઈન્ટ પર પાછો જશે, અને વાસ્તવિક reply પેકેટ પરનો સ્ત્રોત સરનામું.

કર્નલ કેવી રીતે જવાબ સ્ત્રોત પસંદ કરે છે

UDP સોકેટ જે બાંધી છે0.0.0.0તેનું પોતાનું સ્ત્રોત સરનામું નથી, તેથી દરેક બહાર જતી(reply) જવાબ માટે નેતાઓની લુકઅપ થાય છે. કર્નલ પછી તે માર્ગમાંથી સ્ત્રોત લે છે: માર્ગ દ્વારા નિશ્ચિત સરનામું, અથવા બહાર જતાં ઈન્ટરફેસનું મુખ્ય સરનામું. ક્વેરીના ગંતવ્ય સરનામા વિશે કોઇ યાદ રાખવામાં નથી.

એક સિંગલ-હોમડ હોસ્ટ પર આ અદૃશ્ય છે, કેમ કે માત્ર એક મંજુર જેવા જવાબ હોઈ શકે છે. એક મશીન જેમાં LAN સરનામું, WireGuard સરનામું અને મેનેજમેન્ટ સરનામું હોય છે, ત્યાં અનેક જવાબો મંજુર હોઈ શકે છે, અને વિજેતા તે સમયનો રાઉટિંગ ટેબલ પર આધાર રાખે છે. એક વધારાનો રૂટ ઉમેરો, સમાન ઇન્ટરફેસ પર બીજું સરનામું ઉમેરો, રિઝોલ્વરના આગળ NAT રીડાયરેક્ટ કરો, અથવા AdGuard ને તેના પોતાના નAMESPACE સાથે કન્ટેનરમાં ચલાવો, અને પસંદ કરાયેલ સ્ત્રોત તેમાંથી અલગ હોઈ શકે છે જે ક્લાયન્ટે પૂછ્યું હતું.

ss -lunp | grep :53બતાવે છે કે તમે કઈ ગેમમાં છો.0.0.0.0:53પર લિસનર હોવું એ વાઇલ્ડકાર્ડ કેસ છે;10.6.0.1:53પર લિસનર પહેલાથી જ જવાબને પિન કરી ચૂક્યું છે. સોકટ વાંચવું YAML વાંચવાને કરતા ઝડપથી છે, અને તે સાચું ચલતું શું છે તેનું પ્રતિબિંબ આપે છે, કે છેલ્લે શું સેવ થયેલું હતું તે નહીં.

bind_hosts πραγματικά નિયંત્રિત કરે છે

AdGuard Home'sdns.bind_hostsસ્થાનિક સરનામાઓની સૂચિ છે જે DNS લિસનર ઉપયોગ કરે છે. મોકલાયેલ ડિફોલ્ટ વર્ઇલ્ડકાર્ડ છે, જેનો અર્થ છે દરેક સ્થાનીક સરનામા પર સ્વીકાર કરો અને પ્રત્યેક જવાબ પર સૂત્ર સરનામું પસંદ કરવા માટે કર્નેલને દો. વર્ઇલ્ડકાર્ડને ક્લાઈન્ટો જે સરનામા પૂછે તે સરનામાંથી બદલી આપવાથી સોકેટ બદલાય છે, અને 每 જવાબ પર સૂત્ર સરનામું પણ સાથે બદલાય છે.

સૂચિમાં એક કરતાં વધુ એન્ટ્રી લેવાય છે, જે બે નેટવર્કને સેવા આપતા રિઝોલ્વર પર મહત્વપૂર્ણ છે. સૂચિબદ્ધ કરવું10.6.0.1અને192.168.1.10બે બાઉન્ડ સોકેટ આપે છે, અને એમાંના કોઈ એક પર આવે તેવા ક્વેરીને તે એડ્રેસ પરથી જવાબ આપવામાં આવે છે જ્યાંથી તે આવ્યું હતું. તે એ વર્તન છે જે મોટાભાગના લોકો માનતા છે કે વાઇલ્ડકાર્ડ પહેલેથી જ પ્રદાન કરે છે.

YAML સરળ છે, અને તેમાંનો સરનામું તે છે જે તમારા ટનલ ક્લાઈન્ટસને ઉપયોગ કરવા માટે કહેવામાં આવ્યું હતું, હોસ્ટનું મુખ્ય સરનામું નહિ:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

એક જ રિઝોલ્વરનાં બે ઇન્સ્ટોલેશનોમાં મતભેદ કેમ છે

આ સંદર્ભમાં પ્લગઇન-પ્રબંધિતનો અર્થ એ છે કે રિઝોલ્વર અન્ય પેકેજ દ્વારા સ્થાપિત અને નિરીક્ષણમાં છે: રાઉટર ફર્મવેર પેકેજ, NAS પેકેજ, અથવા હોમ-ઓટોમેશન એડ-ઓન. તે પેકેજ સામાન્ય રીતે AdGuard Home ના YAML ની પોતાની નકલ મોકલે છે અને પોતાની સમયસૂચિ પર પ્રક્રિયાને પુનઃપ્રારંભ કરે છે, જ્યારે એક સ્ટેન્ડઅલોન ઇન્સ્ટાન્સ તે વેન્ડર બાયનરી અથવા કન્ટેનર છે જેને તમે پاڻ કન્ફિગર કરો છો. કોઈપણ રીતે તમે બે સ્વતંત્ર પ્રક્રિયાઓ જુઓ છો જેની અલગ કન્ફિગરેશન ફાઇલો અને અલગ બાઈન્ડ પસંદગીઓ છે, ભલે બંને એ samme upstream લિસ્ટ અને એ samme ફિલ્ટર લિસ્ટ વાંચે. એક ચોક્કસ ટનલ સરનામું બાંધે શકે છે જ્યારે બીજું વાઇલ્ડકાર્ડ વારસાગત કરે છે, અને વેબ ઇન્ટરફેસ બંને બાજુએ એક સરખો નજર પડે છે.

આ કારણને લીધે 'માઈગ્રેશન પહેલા તે જ રિઝોલ્વર કાર્યરત હતું' તે વર્તમાન બાઇન્ડિંગ વિશે કંઈ સાબિત નથી કરતું. સૉકેટ તપાસો, પછી કોનફિગરેશન ફાઈલ તપાસો જે રન થઈ રહેલો પ્રોસેસ πραγμα में લોડ કરવામાં આવી છે. અન્ય ડિરેક્ટરીમાં ગેસેલું નકલો એ સામાન્ય કારણ છે કે એડિટનો کوئی અસર નહોતી જણાતી.

તેને પિન કરો, પછી ટનલ બાજુથી પરીક્ષણ કરો

બદલોbind_hostsટનલ સરનામે, સર્વિસને ફરી શરૂ કરો, અને પકાસો કે સૉકેટ સરી ચુક્યું છે:ss -lunp | grep :53હવે10.6.0.1:53અને કોઈ વાઈલ્ડકાર્ડ એન્ટ્રી દેખાવા જોઈએ નહીં. જો હજુ પણ0.0.0.0દેખાય ત્યારેય,, રન થઈ રહેલ પ્રોસેસ એ ફાઇલ જે તમે એડિટ કરી હતી તે વાંચી રહી નથી.

પછી ક્લાયંટ તરફથી પરીક્ષણ કરો, કારણ કે તે જ બાજુ મહત્વપૂર્ણ છે.dig @10.6.0.1 example.comસાથે ક્વેરી એ જે માર્ગ યૂઝર દ્વારા વપરાય છે તેને પરિક્ષણ કરે છે, અને હોસ્ટ પર કૅપ્ચર સાથે.tcpdump -ni wg0 udp port 53હવે વાયર પર રિપ્લાયનું સ્ત્રોત સરનામું બતાવે છે. તે ક્લાઈન્ટના રિઝોલ્વર સેટિંગમાં સરનામા સાથે સરખાવો; જ્યારે તે સમાન હોય, ત્યારે ટાઈમઆઉટ રહસ્ય નથી રહેતું.

ip route get 10.6.0.2બાકી રહેલી કોઈપણ અજાયબીની وضاحت કરે છે, કારણ કે તે ઈન્ટરફેસ અને સ્ત્રોત છાપે છે જે હોસ્ટ ક્લાઈન્ટ તરફ પાછું ઉપયોગ કરશે. જો આ আઉટપુટ લૅન ઈન્ટરફેસનું નામ આપે, તો બાઈન્ડ ફેરફાર આખું ઉકેલ નથી અને પછી રાઉટિંગ ટેબલ વાંચવાની જરૂર છે.

જે બાબતો બાઈન્ડ સેટિંગ સુધારી શકતું નથી

લિસનર પિન કરવાથી તે એક્સેસ લિસ્ટને સુધારતું નથી જે ટનલ સબનેટને અવગણે છે, ફાયરવಾಲ್ નિયમ જે ક્વેરી મંજૂર કરે છે પણ રિપ્લાય નથી, અથવા WireGuard પુલ પર પાછો લાગતો કોઈ રસ્તો ન હોવો. તે સ્ત્રોત સરનામાની સામે પહેલા અથવા બાદમાં નિષ્ફળ થાય છે, અને દરેકનો પોતાનું માલિક હોય છે.

તે બદલતું નથીકે રિઝોલ્વર કઈ અપસ્ટ્રીમને આગળ મોકલે છે, ભલે રીબાઈન્ડિંગ રક્ષણ ખાનગી નામ માટે ખાનગી જવાબ નકારી આપે, અથવા ક્લાયન્ટ તેના પોતાના સર્ચ ડોમેઇનને કેવી રીતે લાગુ કરે છે. તે અલગ નિયંત્રણો છે. જ્યારે પ્રત્યાઘાત સ્ત્રોત ખોટો હોય ત્યારે બાઈન્ડ એડ્રેસ બદલો, અને જ્યારે તે ખોટું ન હોય ત્યારે કંઈક બીજું બદલાવો.