macOS પર OpenVPN TAP: ડિબગ કરતા પહેલા ક્લાયન્ટ તપાસો

જૂનું પ્રોફાઇલ આધુનિક Mac પર આવે છે, ક્લાયન્ટ તેને કોઈ ફરિયાદ વિના આયાત કરે છે, અને જોડાણ તૂટી જાય છે અથવા ક્યારેય ટ્રાફિક પસાર થતો નથી. સર્ટિફિકેટ પર આખી બપોર ખર્ચતા પહેલા પ્રોફાઇલમાં ઉપકરણની લાઇન વાંચો. જો ત્યાં dev tap લખ્યું હોય, તો તમે ક્લાયન્ટને Ethernet જેવું ઇન્ટરફેસ માંગી રહ્યા છો, અને macOS પર આવી મોટાભાગની સત્રો આ જ વિનંતી પર પૂરી થાય છે.

પગલું 1: પુષ્ટિ કરો કે પ્રોફાઇલ ખરેખર TAP માંગે છે

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

જો ફાઇલમાં dev tap અથવા dev tap0 હોય, તો ક્લાયન્ટે TAP ઇન્ટરફેસ લાગુ કરવું પડશે. જો તેમાં dev tun હોય, તો આ લેખનો બાકીનો ભાગ લાગુ પડતો નથી અને નિષ્ફળતા બીજે ક્યાંક છે.

ક્લાયન્ટનું નામ અને આવૃત્તિ, macOS આવૃત્તિ અને પ્રોફાઇલ ક્યાંથી આવ્યું તે લખી રાખો. એ ત્રણ હકીકતો નક્કી કરે છે કે નીચેના બે માર્ગોમાંથી કયો માર્ગ બિલકુલ શક્ય છે.

પગલું 2: ઉપકરણ મોડ ખરેખર શું બદલે છે તે જાણો

TUN ઇન્ટરફેસ IP પેકેટો વહન કરે છે. ક્લાયન્ટ IP સાથીને સંબોધિત પેકેટો વાંચે છે અને લખે છે, અને ઓપરેટિંગ સિસ્ટમ તેમને અન્ય કોઈપણ ઇન્ટરફેસની જેમ રૂટ કરે છે.

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

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

પગલું 3: સુસંગત ક્લાયન્ટ અને માઇગ્રેશન વચ્ચે પસંદ કરો

બે પ્રામાણિક માર્ગો છે. પ્રથમ એવો ક્લાયન્ટ છે જેનો પ્રકાશક તમારી macOS આવૃત્તિ અને હાર્ડવેર માટે જાહેર કરે છે કે તે તમને જરૂરી TAP ગોઠવણીને સમર્થન આપે છે. ચાર વર્ષ જૂની ફોરમ પોસ્ટ નહીં, અને આર્કાઇવ કરેલ ઇન્સ્ટોલર નહીં: વર્તમાન જાહેરાત સાથે પરીક્ષણ જોડાણ.

બીજું એ છે કે સેવાને TUN પર ખસેડવી, જે ક્લાયન્ટ ફેરફાર જેટલો જ સર્વર ફેરફાર છે. તેને રૂટેડ ટોપોલોજી, સરનામાં પૂલ, દૂરના નેટવર્ક માટે ધકેલાયેલ રૂટ્સ અને તે નેટવર્કથી પૂલ સુધી પરત માર્ગની જરૂર છે.

જે કામ કરતું નથી તે તમારી સ્થાનિક નકલમાં tap ને tun બનાવવું અને આશા રાખવી. સર્વર હજી બ્રિજ કરે છે, ક્લાયન્ટ હવે IP બોલે છે, અને કંઈ મળતું નથી.

પગલું 4: કાર્યરત સેવા બદલતા પહેલા હકીકતો એકઠી કરો

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

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

એ પ્રશ્નોના જવાબ નક્કી કરે છે કે તમે આજે બપોરે ક્લાયન્ટની સમસ્યા હલ કરો છો કે આવતા અઠવાડિયે નેટવર્ક ફેરફારનું આયોજન કરો છો.

પગલું 5: બંને છેડેથી માઇગ્રેશન ચકાસો

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

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

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

છતાં નિષ્ફળ જાય ત્યારે પહેલી ભૂલ વાંચો

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

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