ગેટવે પર OpenVPN DNS: dnsmasq અને ફાયરવોલનો વ્યાપ

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

લિસનર બે દિશાવાળી સ્થાનિક સેવા છે

અંદરની દિશામાં ક્લાયન્ટ ગેટવેના ટનલ સરનામા પર પોર્ટ 53 પર ક્વેરી મોકલે છે. બહારની દિશામાં ડિમન તે ક્વેરીને તેના ગોઠવેલા અપસ્ટ્રીમ પર મોકલે છે. બંને અડધા ભાગે કામ કરવું પડે છે, અને તેઓ જુદી જુદી રીતે નિષ્ફળ જાય છે.

ક્લાયન્ટ જે ટાઇમઆઉટ જણાવે છે અને ગેટવે પર જે ટાઇમઆઉટ દેખાય છે તે એક જ ખામી નથી.

ટનલનું સરનામું બાંધો, દરેક સરનામું નહીં

આ કામ માટેની સમર્પિત dnsmasq ઇન્સ્ટન્સને સ્પષ્ટ લિસન સરનામું, શરૂ થયા પછી ટનલ દેખાવાને સહન કરતો બાઇન્ડ મોડ, અને એક સ્પષ્ટ અપસ્ટ્રીમ જોઈએ. આ હું વાપરું છું તે સૌથી નાની આવૃત્તિ છે:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic વ્યક્તિગત સરનામાં બાંધે છે અને tun0 પછી દેખાય ત્યારે સંભાળે છે, જે એવા હોસ્ટ પર મહત્ત્વનું છે જ્યાં VPN સેવા ફરી શરૂ થાય છે. loopback ની સૂચિ રાખવાથી જાહેર લિસનર ઉમેર્યા વિના સ્થાનિક સાધનો કામ કરતાં રહે છે. no-resolv ડિમનને હોસ્ટની રિઝોલ્વર ગોઠવણીમાંથી અપસ્ટ્રીમ વારસામાં લેતું અટકાવે છે, અને no-hosts આ ઇન્સ્ટન્સને ગેટવેની hosts ફાઇલ પ્રકાશિત કરતું અટકાવે છે. એ વિકલ્પોમાંથી કોઈ પણ કોઈને સેવાની ક્વેરી કરવાની પરવાનગી આપતું નથી.

બીજું ડિમન શરૂ કરતાં પહેલાં પોર્ટ 53 પર હાલનું લિસનર છે કે નહીં તે તપાસો, અને ખોટા ડિરેક્ટરીમાં પડેલી ભટકતી ફાઇલને બદલે ડિસ્ટ્રિબ્યુશનના ગોઠવણી-માલિકનો ઉપયોગ કરો.

DNS ઇનપુટને મંજૂરી આપો, ટનલ ટ્રાન્ઝિટને નહીં

આને કામ કરાવતા ફાયરવોલ નિયમો સ્થાનિક-ઇનપુટ નિયમો છે, જે ટનલ ઇન્ટરફેસ, ક્લાયન્ટ પૂલ, ગેટવે સરનામું અને પોર્ટ 53 સુધી મર્યાદિત છે. બે નિયમ, દરેક પ્રોટોકોલ માટે એક, પૂરતા છે:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP ઉપરાંત TCP પર પણ ચાલે છે, તેથી ફક્ત UDP માટેનો નિયમ મોટા જવાબોને એવી રીતે નિષ્ફળ જવા દે છે જે અવારનવાર લાગે છે. આ ufw route પરવાનગીઓ નથી, અને તે tun0 પર વિશાળ પરવાનગી બનવી ન જોઈએ. ક્રમનું મહત્ત્વ સામગ્રી જેટલું જ છે: બધું ઇનપુટ tun0 પરથી કાઢી નાખતો અગાઉનો નિયમ હજી જીતે છે, અને અંતિમ ડ્રોપ નીચે પરવાનગી ઉમેરવાથી કંઈ બનતું નથી.

જો ગેટવેનું DNS હવે ડિઝાઇનનો ભાગ છે, તો તે અગાઉની નીતિને ઇરાદાપૂર્વક સુધારો અને કારણ નોંધો.

અપસ્ટ્રીમ અડધો ભાગ અલગ માર્ગ છે

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

જવાબો કામ કરે તે માટે અમર્યાદિત ટનલ આઉટપુટ ઉમેરશો નહીં; ટ્રેક કરેલા જવાબોને તેની જરૂર નથી.

વિકલ્પ પુશ કરો, પછી હેન્ડઓફ તપાસો

સર્વર પુશ કરેલા વિકલ્પ દ્વારા ક્લાયન્ટને રિઝોલ્વરની જાહેરાત કરી શકે છે. તે વિકલ્પ છે, ઓપરેટિંગ સિસ્ટમે પાળવો પડે તેવી સૂચના નહીં:

push "dhcp-option DNS 10.90.0.1"

કમાન્ડ-લાઇન Linux ક્લાયન્ટને તેના કનેક્શન મેનેજરનું રિઝોલ્વર એકીકરણ જોઈએ શકે, અને મેનેજ કરેલા ઉપકરણને તેની મેનેજમેન્ટ પ્રોફાઇલ અપડેટ જોઈએ શકે. કનેક્ટ થયા પછી ક્લાયન્ટ પર સક્રિય રિઝોલ્વરની પુષ્ટિ કરો, પુશ લાગુ થયો છે એમ ધારવાને બદલે. જ્યારે બે પ્રક્રિયાઓ એક સાથે DNS સેટ કરવાનો પ્રયાસ કરે છે, ત્યારે એવી સ્પર્ધા થાય છે જે ફરતા રિઝોલ્યુશન જેવી દેખાય છે.

ક્લાયન્ટની રિઝોલ્વર ગોઠવણી માટે એક જ માલિક એ ધ્યેય છે, અને પુશ સામાન્ય રીતે તે માલિક ત્યારે જ હોય છે જ્યારે ક્લાયન્ટ પ્લેટફોર્મ સહમત હોય.

તમે ખરેખર શું બનાવ્યું તે ચકાસો

એક ખાનગી સંપૂર્ણ લાયક નામ અને એક મંજૂર બાહ્ય નામ સીધું ટનલ સરનામા સામે, UDP અને TCP બંને પર ક્વેરી કરો. પછી એપના સામાન્ય લુકઅપ માર્ગ દ્વારા પુનરાવર્તન કરો.

જો સીધી ક્વેરી કામ કરે અને એપ હજી નિષ્ફળ જાય, તો ખામી સર્વર પર નહીં, હેન્ડઓફમાં છે:

• ક્લાયન્ટે પુશ કરેલો વિકલ્પ ક્યારેય લાગુ કર્યો નહીં.
• પછી બીજું રિઝોલ્વર સેટ થયું અને સ્પર્ધા જીતી ગયું.
• એપ તેની પોતાની રિઝોલ્વર લાઇબ્રેરી અથવા કેશ કરેલો જવાબ વાપરે છે.

અંતે પુષ્ટિ કરો કે મંજૂર VPN માર્ગની બહારનો સ્રોત લિસનરનો ઉપયોગ જરાય કરી શકતો નથી. સફળ રિઝોલ્યુશન તે પરત કરેલા સરનામાને અધિકૃત કરતું નથી, તેથી એ બે પ્રશ્નો અલગ રાખો.