OpenVPN હજી જૂના રૂટ ધકેલે છે? તે શું લોડ કર્યું તે તપાસો

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

નીચેની સરખામણી પ્રક્રિયાથી બહાર તરફ જાય છે, કારણ કે કઈ ફાઇલ અમલમાં છે તેનો એકમાત્ર અધિકાર પ્રક્રિયા પાસે છે.

તમે સંપાદિત કરેલી ફાઇલ અને પ્રક્રિયા જે ફાઇલ વાંચે છે

unit અને તેનાથી બનેલી કમાન્ડ લાઇનથી શરૂ કરો. systemd હોસ્ટ પર systemctl cat openvpn@server ExecStart લાઇન છાપે છે, અને ઇન્સ્ટન્સ unit સામાન્ય રીતે તેનો કન્ફિગરેશન પાથ ઇન્સ્ટન્સના નામ પરથી લે છે, તેથી openvpn@office તરીકે શરૂ થયેલ ડીમન openvpn@server તરીકે શરૂ થયેલા કરતાં અલગ ફાઇલ વાંચે છે. આને ચાલતી પ્રક્રિયાના argv સાથે સરખાવો. કન્ફિગરેશન મેનેજમેન્ટ સાધન ફેરફાર ગુમાવવાની બીજી રીત ઉમેરે છે: તે સાચી ફાઇલ એવી જગ્યાએ લખી શકે છે જે unit કદી ઉલ્લેખ કરતું નથી, અને પછી સફળ ડિપ્લોય કંઈ ન કર્યા જેવું લાગે છે.

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

સર્વર શું ધકેલે છે અને ક્લાયન્ટ શું ઇન્સ્ટોલ કરે છે

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

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

ધકેલાયેલો પ્રીફિક્સ અને પરતનો રૂટ અલગ સમસ્યાઓ છે

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

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

બંને છેડે ટેબલ સરખાવો

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

ત્રણ ઓળખ એકસાથે રાખો: કન્ફિગરેશન પાથ, unit અથવા ઇન્સ્ટન્સનું નામ, અને જે ક્લાયન્ટ ઓળખ સાથે તમે પરીક્ષણ કર્યું.

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

રીસ્ટાર્ટ પછી ટકી રહેતી રૂટ સમસ્યા ઘણી વાર રૂટિંગ સમસ્યા જ નથી હોતી; ખામી તમે વારંવાર વાંચો છો તે ટેબલની ઉપરના સ્તરે હોય છે.