OpenVPN એ DNS સર્વર મોકલ્યું, પણ Linux તેને અવગણે છે

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

તપાસ એક: કનેક્શન કેવી રીતે શરૂ થાય છે

કનેક્શનનો માલિક નક્કી કરે છે કે કોણ રિઝોલ્વર સેટિંગ લાગુ કરી શકે. શેલમાંથી સીધો openvpn આદેશ પોતાની પ્રક્રિયા સિવાય કંઈ ધરાવતો નથી, જ્યારે systemd યુનિટ, NetworkManager અથવા વેન્ડર ક્લાયન્ટમાંથી દરેકની DNS પ્રકાશિત કરવાની પોતાની રીત છે. આમાંથી કોઈપણ ધારવા પહેલાં પ્રક્રિયા યાદી અને યુનિટનું નામ વાંચો.

કમાન્ડ-લાઇન પ્રક્રિયા આપોઆપ NetworkManager કનેક્શન નથી, અને NetworkManager કનેક્શન આપોઆપ તે વસ્તુ નથી જેણે resolv.conf લખ્યું. તે બે ધારણાઓ આ તપાસમાં બગડેલા મોટાભાગના કલાકો સમજાવે છે. પૂછો કે તમે ખરેખર જોઈ રહ્યા છો તે ઇન્ટરફેસ માટે કયો ઘટક DNS પ્રકાશિત કરશે.

આગળ વધતા પહેલાં માલિક લખી લો. પછીની દરેક તપાસ તેના પર આધાર રાખે છે.

તપાસ બે: રિઝોલ્વર લિંક ખરેખર શું રાખે છે

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

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

કોઈ નિષ્કર્ષ પર આવતા પહેલાં રિઝોલ્વર આઉટપુટમાંનું લિંક નામ VPN લોગમાંના ઇન્ટરફેસ નામ સાથે સરખાવો. ત્યાં અસંગતિ સામાન્ય રીતે એમ દર્શાવે છે કે લોગની લાઇન બીજી પ્રક્રિયામાંથી આવી છે.

તપાસ ત્રણ: નામસ્થાન તે લિંક પસંદ કરે છે કે નહીં

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

ડોમેન ફાળવણી તપાસો, ફક્ત સર્વર સરનામું નહીં. ~corp.example તરીકે લખાયેલું ડોમેન રૂટિંગ ડોમેન છે, અને ટિલ્ડ નિશાન નામ મેળવવાની રીત બદલે છે.

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

તપાસ ચાર: એક માલિક, બે નહીં

જો NetworkManager પહેલેથી VPN અને રિઝોલ્વરની સ્થિતિ સંભાળે છે, તો અસંબંધિત હૂક સ્ક્રિપ્ટ ઉમેરવાથી હરીફ લેખકો ઊભા થાય છે. પેકેજ systemd-resolved માટે આપતો હૂક સમર્થિત એકીકરણ છે, અને તે ચોક્કસ જીવનચક્રની અપેક્ષા રાખે છે: script-security 2, up માર્ગ, up-restart, down માર્ગ અને down-pre. તે વિકલ્પો નોંધણી અને દૂર કરવાને ફક્ત પ્રથમ કનેક્શન પર નહીં, યોગ્ય ક્ષણોએ થવા દે છે.

માર્ગદર્શિકામાંથી નકલ કરેલા ઉદાહરણને બદલે પેકેજમાંથી સ્થાપિત માર્ગ વાપરો. પરવાનગીઓ પણ મહત્વની છે, કારણ કે હૂક વિશેષાધિકારો ઘટ્યા પછી ચાલે છે.

તેના આઉટપુટ લક્ષ્યને બદલવા માટે ડિસ્ટ્રિબ્યુશન રિઝોલ્વર સ્ક્રિપ્ટ સંપાદિત કરવી એ એક હોસ્ટનો ઉપાય નોંધે છે. તે સામાન્ય સમારકામ નથી.

તપાસ પાંચ: ફરી કનેક્ટ થયા પછી એ જ પરિણામ

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

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