OpenVPN દ્વારા પુશ કરેલ DNS અવગણાય છે: કયો ઘટક તેને લાગુ કરે છે

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

પુશ કરેલ વિકલ્પ પ્રસ્તાવ છે, ઇન્સ્ટોલેશન નથી

સર્વર પર બે નિર્દેશ અસર નહીં, ઇરાદો વર્ણવે છે:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

ખાતરી કરો કે પુશ પહોંચ્યું અને માલિક શોધો

શરૂઆત લોન્ચરનું નામ આપીને કરો: એક નગ્ન openvpn કમાન્ડ, systemd ઇન્સ્ટન્સ, NetworkManager અથવા વેન્ડર ક્લાયન્ટ. આ નક્કી કરે છે કે હૂક ક્યાં રહી શકે. systemd-resolved વાળા હોસ્ટ પર, resolvectl status દરેક લિંકને તેના ખરેખર વપરાતા DNS સર્વરો અને શોધ ડોમેન સાથે સૂચિબદ્ધ કરે છે, અને ટનલ લિંકનું નામ હંમેશા tun0 હોતું નથી.

જો પુશ કરેલું સરનામું લોગમાં દેખાય પણ કોઈ લિંક પર નહીં, તો એકીકરણ ખૂટે છે. જો તે લિંક પર હોય અને ક્વેરીઓ હજી બીજે જતી હોય, તો સમસ્યા એ છે કે કઈ ક્વેરીઓ તે લિંક પસંદ કરે છે. NetworkManager dns=dnsmasq માં /etc/NetworkManager/NetworkManager.conf ફાઇલમાં સ્થાનિક ફોરવર્ડર ચલાવે છે જે વિભાજિત DNS જાણી જોઈને લાગુ કરે છે: VPN ડોમેનની અંદરનાં નામ VPN રિઝોલ્વર પર જાય છે, બાકીનું બધું પોતાનો અગાઉનો માર્ગ રાખે છે. આ વર્તન ખામી જેવું લાગે છે જ્યારે તમે ધાર્યું હતું કે બધો ટ્રાફિક ખસી જશે; પ્રતિ-કનેક્શન સેટિંગ્સ તપાસો nmcli connection show "My VPN" દ્વારા, જ્યાં ipv4.dns અને ipv4.dns-search ઉપકરણ જે જણાવે છે તેની પાછળનાં મૂલ્યો રાખે છે, તેને તૂટેલું કહેતા પહેલાં. જો દરેક ક્વેરીએ ખરેખર VPN રિઝોલ્વર સુધી પહોંચવું જોઈએ, તો દૂર કરો dns=dnsmasq ને NetworkManager.conf માંથી અને NetworkManager ફરી શરૂ કરો, જે નામ-ઉકેલ કનેક્શન સેટિંગ્સને પાછું આપે છે; અન્યથા વિભાજિત DNS રાખો અને પુશ કરેલી ડોમેન યાદી સુધારો.

Linux: વિકલ્પો રિઝોલ્વરને સોંપો

ડિસ્ટ્રિબ્યુશન પેકેજો આ માટે હૂક આપે છે, અને ક્લાયન્ટને તે ચલાવવાની પરવાનગી હોવી જોઈએ. systemd-resolved વગરના હોસ્ટ પર સામાન્ય ગોઠવણ:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved સાથે જૂની resolv.conf સ્ક્રિપ્ટ કદાચ કંઈ મહત્વનું ન બદલે, કારણ કે stub રિઝોલ્વર પ્રતિ લિંક સ્થિતિ રાખે છે. update-systemd-resolved સહાયક એક હૂક સ્વરૂપનું દસ્તાવેજીકરણ કરે છે જે up-restart અને down-pre નો ઉપયોગ કરે છે, જે ત્યારે મહત્વનું છે જ્યારે ઇન્ટરફેસ એક કનેક્શન પ્રયાસથી વધુ ટકે. તમે ગમે તે પસંદ કરો, એક ઘટક પાસે સ્થિતિની માલિકી હોવી જોઈએ. NetworkManagerની બાજુમાં અસંબંધિત હૂક ઉમેરવાથી એ જ લિંકને બે લેખક મળે છે, અને પરિણામ પછી તમારા રૂપરેખાંકનને બદલે ક્રમ પર આધાર રાખે છે.

એવો કિસ્સો પણ છે જ્યાં NetworkManager એ પુશ કરેલ વિકલ્પને સંપૂર્ણ અવગણ્યો જ્યાં સુધી સર્વર સરનામું કનેક્શનની IPv4 સેટિંગ્સમાં દાખલ ન થયું, અને પછી રિઝોલ્વર સ્થિતિએ તેને વપરાશમાં દર્શાવ્યું. સ્ક્રિપ્ટ ફરી લખતા પહેલાં તે અજમાવવા યોગ્ય છે, કારણ કે તે સમસ્યાને શેલ હૂકમાંથી તે કનેક્શન પ્રોફાઇલમાં ખસેડે છે જે પહેલેથી ટનલ વહન કરે છે.

Windows અને macOS અલગ ભાગો લાગુ કરે છે

Windows ક્લાયન્ટ VPN એડાપ્ટરના DNS સર્વર ખરેખર સેટ કરે છે, પણ Windows હજી મેટ્રિકથી ઇન્ટરફેસ પસંદ કરે છે અને ટૂંકા નામને વિસ્તારવા હજી સફિક્સ જોઈએ છે. પ્રોફાઇલ નહીં, એડાપ્ટરની સ્થિતિની ખાતરી કરો:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

જો સરનામું ખૂટે, તો તેને આનાથી સેટ કરો Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, પછી સફિક્સ એડાપ્ટરના IPv4 ગુણધર્મોમાં ઉમેરો જેથી fileserver બને fileserver.corp.example. મશીન-વ્યાપી SearchList હેઠળનું મૂલ્ય Tcpip\Parameters એ જ કરે છે. જ્યાં લાંબું નામ ઉકેલાય છે અને નગ્ન નામ નહીં, ત્યાં રિઝોલ્વર પહેલેથી સાચું છે અને દોષ શોધ યાદીનો છે. સુધારા ક્રમમાં: પુશ કરો એક DOMAIN જેથી ક્લાયન્ટ સફિક્સ શીખે, તે સફિક્સ એડાપ્ટર અથવા કનેક્શનની શોધ યાદીમાં ઉમેરો, અને કામચલાઉ પગલા તરીકે નામને અહીં સ્થિર કરો hosts, અથવા LMHOSTS Windows પર; NetBIOS બ્રાઉઝિંગ રાઉટર પાર કરતું નથી, તેથી ઓફિસ LAN પર ટૂંકું નામ શોધતું બ્રોડકાસ્ટ કદી ટનલ ક્લાયન્ટ સુધી પહોંચતું નથી.

block-outside-dns block-outside-dns એ Windows ક્લાયન્ટનું વર્તન છે, પોર્ટેબલ પ્રોફાઇલ લાઇન નથી, અને તેને Linux કે macOS પ્રોફાઇલમાં કૉપિ કરવાથી તે ત્યાં પુનઃઉત્પાદિત થતું નથી. જો Windows પર જાહેર નામો કામ કરે અને આંતરિક નિષ્ફળ જાય, તો અદ્યતન સેટિંગ્સ હેઠળ એડાપ્ટર ક્રમની સરખામણી કરો ipconfig /all સાથે. macOS પર પ્રતિ-સેવા રિઝોલ્વર ક્રમ સિસ્ટમનો છે, તેથી વાપરો scutil --dns એ જોવા માટે કે કયા ડોમેન માટે કયો રિઝોલ્વર પૂછાય છે, અને કોઈપણ એકલ રિપોર્ટ થયેલ પ્રોફાઇલ સુધારાને સામાન્ય નહીં, ક્લાયન્ટ-આધારિત ગણો.

એ જ લેપટોપ પરની વર્ચ્યુઅલ મશીન આમાંથી કંઈ વારસામાં પામતી નથી. અતિથિને આંતરિક ડોમેન માટે પોતાની રિઝોલ્વર એન્ટ્રી આપો, અથવા હાઇપરવાઇઝરના NATને તેની ક્વેરીઓ હોસ્ટ દ્વારા મોકલવા દો, જે ફક્ત ત્યારે સાચું છે જ્યારે હોસ્ટની ટનલ ચાલુ હોય.

ઇતિહાસ ત્રીજું કારણ છે. અગાઉના પ્રોફાઇલના DNS સર્વરો અથવા સફિક્સ સેટિંગ્સ પુનઃ કનેક્શન પર ટકી શકે છે, તેથી જ્યારે એડાપ્ટર સાચું દેખાય અને લુકઅપ હજી નિષ્ફળ થાય, ત્યારે જીવંત એડાપ્ટરની સરખામણી કરો Get-VpnConnection સાથે અને સર્વરને અડકતા પહેલાં જૂની એન્ટ્રી ભૂંસો અથવા ફરી લખો.

સાબિત કરો કે ક્વેરી ક્યાં ગઈ

એક લુકઅપ દરમિયાન કેપ્ચર વિવાદ ઉકેલે છે: tcpdump -ni eth0 port 53 ભૌતિક ઇન્ટરફેસ પર ક્વેરીઓ દર્શાવે છે, એટલે તે ટનલની બહાર જાય છે અને રિઝોલ્વર કદી બદલાયું નથી. dig @10.8.0.1 name.corp.example પછી બાકીના બે કિસ્સા અલગ કરે છે. જો સીધી ક્વેરી જવાબ આપે, રિઝોલ્વર કામ કરે છે અને ક્લાયન્ટ તેનો ઉપયોગ કરતું નથી; જો સમય પૂરો થાય, રિઝોલ્વર ટનલ દ્વારા અગમ્ય છે અને કોઈ સ્થાનિક ફેરફાર મદદ નહીં કરે.

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

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

એક માલિક રાખો અને ક્રમમાં ચકાસો

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

ચાર ચકાસણીથી ચક્ર બંધ કરો: પુશ કરેલું સરનામું ટનલ લિંક પર હાજર, આંતરિક નામ સંપૂર્ણ લાયક નામ તરીકે ઉકેલાય છે, એ જ નામ સફિક્સ વગર ઉકેલાય છે, અને એક પુનઃ કનેક્શન પછી પણ બંને સાચાં. એક કેપ્ચર કહે છે કે ચારમાંથી કઈ નિષ્ફળ ગઈ. OpenVPN 2.6 મેન્યુઅલ સૂચિબદ્ધ કરે છે dhcp-option અને સ્ક્રિપ્ટ નિર્દેશોને તેમના પ્લેટફોર્મ નોંધ સાથે.