OpenVPN DHCP નવીકરણ પછી ડ્રોપ થાય છે: એન્ડપોઇન્ટ રૂટ રાખો

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

લક્ષણને અડધા-ડિફોલ્ટ રૂટ સામે તપાસો

redirect-gateway def1 સાથે, OpenVPN ડિફોલ્ટ રૂટ બદલવાને બદલે 0.0.0.0/1 અને 128.0.0.0/1 સ્થાપિત કરે છે. બંને મળીને આખું સરનામું અવકાશ આવરી લે છે, અને તેઓ ફક્ત પ્રીફિક્સ લંબાઈથી 0.0.0.0/0 ને હરાવે છે. તેથી વધુ ચોક્કસ મેળ વગરનું કોઈપણ ગંતવ્ય ટનલમાં પ્રવેશે છે.

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

બીજું કંઈ સ્પર્શતા પહેલાં ટેબલનો આકાર ખાતરી કરો. ip route show એ બંને અડધા અને સર્વર સરનામા માટે હોસ્ટ રૂટ સૂચિબદ્ધ કરવો જોઈએ; હોસ્ટ રૂટ ખૂટે તો તપાસના બાકીના ભાગને સ્પષ્ટ શરૂઆત બિંદુ મળે છે.

મેટ્રિક બદલ્યા વગર અડધા-ડિફોલ્ટ કેમ જીતે છે

નીચી મેટ્રિક લાંબા પ્રીફિક્સને હરાવતી નથી. /1 રૂટ જીતે છે કારણ કે કર્નલ પહેલાં સૌથી ચોક્કસ રૂટ મેળવે છે, તેથી ડિફોલ્ટ રૂટ પર મેટ્રિક વધારવાથી ટનલ તરફ જતા ટ્રાફિકની દિશામાં કંઈ બદલાતું નથી. મેટ્રિક પાછળ દોડવું આ નિદાનમાં સૌથી સામાન્ય ખોટો વળાંક છે.

ip route get 203.0.113.10 સાથે પસંદગી તપાસો, તેમાં સર્વરનું વાસ્તવિક સરનામું મૂકો. જવાબ એ ઇન્ટરફેસ અને આગલા હોપનું નામ આપે છે જે કર્નલ ખરેખર વાપરે, અને તે ટેબલ વાંચીને તેના પર વિચાર કરવા કરતાં વધુ માહિતીપ્રદ છે.

ટનલ શરૂ થાય તે પહેલાં, ચાલુ હોય ત્યારે અને લીઝ ઘટના પછી એ આદેશ ચલાવો. એક આદેશમાંથી ત્રણ જવાબ, અને વિચલન બિંદુ દૃશ્યમાન બને છે.

એક નહીં, ત્રણ સ્નેપશોટ લો

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

સ્નેપશોટને ટાઇમસ્ટેમ્પ સાથે એક ફાઇલમાં રાખો, કારણ કે પછીનો રસપ્રદ પ્રશ્ન ક્રમ છે. DHCP ઘટના OpenVPN એ તેનો રૂટ તાજો કર્યા પહેલાં આવી હતી કે પછી? જવાબ નક્કી કરે છે કે કોણે તેને સુધારવું છે. ખોટી ઘડિયાળનો ટાઇમસ્ટેમ્પ ન હોવા કરતાં ખરાબ છે, તેથી તે રૂટિંગ ટેબલ ધરાવતા હોસ્ટ પાસેથી લો.

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

કયો ઘટક અપવાદ તાજો કરે છે તે નક્કી કરો

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

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

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

ફક્ત ફરીથી જોડાણ નહીં, જીવનચક્રની કસોટી કરો

dhcpcd -n eth0 થી અથવા લીઝ છોડીને ફરી લઈને નવીકરણ ફરજિયાત કરો, પછી એન્ડપોઇન્ટ માટે ફરી ip route get તપાસો. તે બે વાર કરો, કારણ કે બીજી ફેરી ડુપ્લિકેટ રૂટ ઉમેરતા હૂક પકડે છે. પછી રીબૂટ કરો, કારણ કે સ્થિરતા શુદ્ધતાથી અલગ ગુણ છે.

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