openfortivpn વારંવાર DNS ઓવરરાઇટ કરે છે? સાચો માલિક શોધો

કનેક્શન ઉપર આવે તે ક્ષણથી અનુસરો: ક્લાયન્ટ પ્રમાણીકરણ કરે છે, pppd વાટાઘાટ કરે છે, અને પછી કંઈક ઓપરેટિંગ સિસ્ટમમાં DNS સેટિંગ્સ લખે છે. જો તમે ફક્ત એટલું જાણો છો કે VPN એ તમારું રિઝોલ્વર બદલ્યું, તો તમે હજી જાણતા નથી કે તેમાંથી કયો તબક્કો તે કર્યું. તેમાંથી બે કરી શકે છે, અને દસ્તાવેજીકૃત pppd એકીકરણ વાપરતા ક્લાયન્ટ પર તે એકબીજાની એટલી નજીક ચાલે છે કે એક જ ભાગીદાર જેવા લાગે. લેખકનું નામ આપવું પ્રથમ પગલું છે; તેની બદલી પસંદ કરવી બીજું છે, અને તે પોતાની નિષ્ફળતાની રીતો સાથેનો અલગ નિર્ણય છે.

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

કનેક્શને ખરેખર શું બદલ્યું તેનાથી શરૂ કરો

તમારા સામાન્ય આદેશ સાથે એક વાર કનેક્ટ કરો અને પહેલાં અને પછીના રિઝોલ્યુશનની તુલના કરો. systemd-resolved ચલાવતા Linux હોસ્ટ પર, resolvectl status દરેક લિંક માટે DNS સર્વર અને શોધ ડોમેન છાપે છે, અને પોતાના સર્વર ધરાવતી નવી tun અથવા ppp લિંક ક્લાયન્ટ-બાજુની અપડેટની આંગળીની છાપ છે. macOS પર, scutil --dns રિઝોલ્વર રૂપરેખા તે ક્રમમાં બતાવે છે જેમાં એપ્લિકેશનો તેની સલાહ લે છે.

તેની તુલના તે ફાઇલ સાથે કરો જે તમે બદલાય તેવી અપેક્ષા રાખી હતી. દરેક લિંકના દૃશ્યમાં કનેક્શન-બદ્ધ એન્ટ્રી અને ફરીથી લખાયેલ /etc/resolv.conf બે અલગ પરિણામો છે, અને બીજું કંઈક બીજું સંપૂર્ણપણે સંભાળતું સિમ્બોલિક લિંક હોઈ શકે. રિઝોલ્વરનું સરનામું, શોધ ડોમેન અને ઇન્ટરફેસનું નામ એક જ ક્ષણે નોંધો; તેમાંથી કોઈપણમાં ફેરફાર બીજા લેખક તરફ ઇશારો કરે છે. તે પાયા વિના, પછીનું દરેક સુધારણા એ અનુમાન છે કે ત્રણ ઘટકોમાંથી કયું ખસ્યું.

બે સ્વિચ અને દરેક જે લેખકને શાંત કરે છે

openfortivpn એક વિકલ્પ-ટુકડાનું દસ્તાવેજીકરણ કરે છે જે તે નિયંત્રિત કરી શકે તેવા બંને લેખકોને બંધ કરે છે, અને દરેક સ્વિચનું સંપૂર્ણ લખાયેલ સમકક્ષ છે જેને મેન્યુઅલ એ જ સેટિંગ તરીકે ગણે છે.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ક્લાયન્ટને ગેટવેથી શીખેલા DNS સર્વર લાગુ કરતા અટકાવે છે, જ્યારે --pppd-no-peerdns pppd ને પીઅર DNS સિસ્ટમમાં ધકેલતા અટકાવે છે. upstream મેન્યુઅલ ચેતવણી આપે છે કે PPP દ્વારા DNS અપડેટ ક્લાયન્ટના પોતાના DNS અપડેટ સાથે સ્પર્ધા કરી શકે છે, તેથી બંને સ્વિચ ટુકડામાં હોવા જોઈએ, બેમાંથી કોઈને પૂરતું ગણવાને બદલે.

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

કંઈપણ નિષ્ક્રિય કરતા પહેલા માલિક પસંદ કરો

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

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

દરેક લિંક માટે રિઝોલ્યુશન તપાસો, દરેક ફાઇલ માટે નહીં

મર્યાદિત અથવા દરેક-ડોમેન રિઝોલ્યુશન ધરાવતા હોસ્ટ પર એપ્લિકેશનો ખરેખર શું વાપરે છે તેની યાદી એક /etc/resolv.conf નથી, તેથી પ્લેટફોર્મ જે રીતે રિઝોલ્વરની સ્થિતિ દર્શાવે તે રીતે વાંચો.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

ફરીથી કનેક્ટ કરો અને ડિસ્કનેક્ટ થયેલી સ્થિતિની ખાતરી કરો

કનેક્શન નીચે ઉતારો અને બંને પૂછપરછનું પુનરાવર્તન કરો. પસંદ કરેલા માલિકે જે સ્થાપિત કર્યું છે તે તે માલિકે જ દૂર કરવું કે પુનઃસ્થાપિત કરવું જોઈએ, તમે શાંત કરેલા ક્લાયન્ટે પાછળ છોડવું નહીં. ટનલ કરતાં વધુ ટકતી જૂની દરેક-લિંક એન્ટ્રી ખાનગી પૂછપરછ એવા સરનામે મોકલવાનું ચાલુ રાખે છે જે હવે પહોંચી શકાય તેવું નથી.

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

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