OpenVPN નું "File exists" રૂટ પર ફાઇલ સમસ્યા નથી

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

ક્લાયન્ટના પોતાના ક્રમને અનુસરો: તેણે શું માંગ્યું, કોષ્ટકમાં પહેલેથી શું હતું, તે એન્ટ્રી ત્યાં કોણે મૂકી, અને પછી જ શું બદલવું. દરેક પગલું એક સંભવિત માલિકને દૂર કરે છે.

ક્લાયન્ટ ખરેખર શું માંગી રહ્યો હતો

નિષ્ફળતા પહેલાં, ક્લાયન્ટ જે રૂટ ઉમેરવા માંગે છે તેની નોંધ કરે છે, સામાન્ય રીતે ગંતવ્ય, નેટમાસ્ક, ગેટવે અને ક્યારેક મેટ્રિક કે કોષ્ટક તરીકે. તે લાઇન જ વિનંતી છે. તેના પછીની ભૂલ કર્નલનો જવાબ છે, અને બંનેને સાથે વાંચવા જોઈએ.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

હાલનો રૂટ વાંચો, ફક્ત સરનામું નહીં

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

પ્રીફિક્સના ચાર માલિક હોઈ શકે

જોડાયેલા રૂટ સોંપાયેલા સરનામાંમાંથી આવે છે અને તે સરનામું હાજર હોય ત્યારે સિસ્ટમ તેમને ફરી બનાવે છે. DHCP ક્લાયન્ટ કે કનેક્શન મેનેજર પોતાના જીવનચક્રના ભાગ રૂપે રૂટ ઇન્સ્ટોલ કરે છે. બીજો VPN ક્લાયન્ટ પહેલેથી એ જ પ્રીફિક્સ લઈ જતું હોઈ શકે. અને સ્થાનિક હૂક કે સ્ક્રિપ્ટ એવું એક ઉમેરી શકે છે જે બીજું કંઈ જાણતું નથી.

દરેક માલિકને અલગ સુધારો જોઈએ. જોડાયેલો રૂટ ભૂંસવાનો તમારો નથી; તેને દૂર કરવાથી ટનલ વાપરી શકાય તે પહેલાં સ્થાનિક ઍક્સેસ તૂટી શકે છે, અને કર્નલ તેને પાછો મૂકશે. મેનેજરના માલિકીના રૂટને તે મેનેજર દ્વારા બદલવો જોઈએ, આગલા ફરી-જોડાણ દ્વારા રદ થતા હાથે લખેલા ip route del થી નહીં.

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

block-local અલગ પ્રશ્નનો જવાબ આપે છે

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

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

તેને કયા ગંતવ્યો સ્થાનિક રહે છે તે અંગેનો નિર્ણય ગણો, જે જાણી જોઈને લેવાયો અને લખાયો છે. લોગ ચિંતાજનક દેખાય ત્યારે તે અજમાવવાનું સ્વિચ નથી.

ચક્ર બંધ કરો: નકલને તેના સ્રોત પરથી દૂર કરો

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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