OpenVPN દ્વારા DNS દબાણ કર્યા પછી સ્થાનિક Samba શેર અદૃશ્ય થઈ ગયું

Samba સ્થાનિક શેર ગુમાવે છે તે ક્ષણે જ OpenVPN કનેક્ટ થાય છે, અને ટનલ લગભગ ક્યારેય કારણ નથી. માઉન્ટ ઠીક છે, NAS ચાલુ છે, અને ટનલે ઇન્સ્ટોલ કરેલ રિઝોલ્વર એવા નામ વિશે પ્રશ્નોના જવાબ આપે છે જે તેને ક્યારેય જોયું નથી. Samba તેના લુકઅપ ક્રમની શરૂઆતમાં તે રિઝોલ્વરને પૂછે છે, જવાબ માને છે અને એવા સરનામે કનેક્ટ થાય છે જ્યાં કંઈ સાંભળતું નથી. શેર સુધારવાનો અર્થ માઉન્ટ નહીં, જવાબ સુધારવો છે.

પાંચ તપાસ, એ ક્રમમાં જે દરેક પગલે સૌથી વધુ શક્યતાઓ દૂર કરે છે.

ટૂંકા નામ માટે કોણ જવાબ આપે છે

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

જવાબ નકારાત્મક જવાબ હતો કે સરનામું તે તપાસો. નકારાત્મક જવાબનો અર્થ છે કે Samba એ બીજી પદ્ધતિ તરફ જવું જોઈતું હતું, અને ખામી બીજે જગ્યાએ છે. સરનામાનો અર્થ છે કે Samba કોઈ વાસ્તવિક જગ્યાએ કનેક્ટ થયું અને કંઈ પાછું ન મળ્યું.

Samba ખોટા જવાબને કેમ માને છે

Samba name resolve order દ્વારા નિર્ધારિત નિશ્ચિત ક્રમ દ્વારા નામો ઉકેલે છે. મોટાભાગના ડિસ્ટ્રિબ્યુશનમાં ડિફોલ્ટમાં host હોય છે, એટલે કે DNS, અને તે NetBIOS બ્રોડકાસ્ટ જેવી ફક્ત-લેન પદ્ધતિઓ પહેલાં ચાલે છે. તેથી રિઝોલ્વર દબાણ કરતી ટનલને દરેક શેર નામ પર પ્રથમ નકારનો અધિકાર મળે છે, જેમાં એક-લેબલ નામોનો પણ સમાવેશ થાય છે જે ક્યારેય ઇમારત છોડવાના ન હતા.

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

પરિણામ એ શેર છે જે ભૂલ સંવાદ વિના અદૃશ્ય થઈ જાય છે. તે ક્રમમાં કંઈ પણ VPN રૂટિંગ નિષ્ફળતા નથી, તેથી NAS ને ping કરવું હજી કામ કરે છે જ્યારે તેના પર બ્રાઉઝ કરવું કામ કરતું નથી.

અલગ અવકાશવાળી બે સમારકામ

સાંકડી સમારકામ દબાણ કરેલ રિઝોલ્વર રાખે છે અને Samba તેને શું પૂછી શકે તે બદલે છે. ડિમન ખરેખર વાંચે છે તે Samba કન્ફિગરેશનમાં બે લીટી ઉમેરો, પછી સેવા ફરી શરૂ કરો:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

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

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

એક જાણી જોઈને પસંદ કરો. રિઝોલ્વર ફેરફાર એકસાથે દરેક એપ્લિકેશન માટે નામ-ઉકેલ બદલે છે, જે ફેરફાર રેકોર્ડ છે, સપોર્ટ કૉલ માટેનું સંપાદન નથી.

સફિક્સ બધું સમજાવી શકે છે

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

અહીં ઉકેલ કાં તો સંપૂર્ણ લાયક સ્થાનિક નામ વાપરવો, અથવા સ્થાનિક સફિક્સની માલિકી ધરાવતો વિભાજિત-DNS નિયમ ઉમેરવો છે. બંનેમાંથી કંઈ પણ Samba ને સ્પર્શ કરવાની જરૂર નથી.

ફરી કનેક્ટ થયા પછી તે સાબિત કરો

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

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

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