Linux પર Kerio VPN ક્લાયન્ટ: ક્રમમાં પાંચ ચકાસણી

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

ખાતરી કરો કે બિલ્ડ મશીન સાથે મેળ ખાય છે

શરૂ કરો dpkg મશીન શું છે અને પેકેજ શેના માટે બન્યું છે તે દર્શાવે છે. સામાન્ય 64-બિટ સિસ્ટમમાં dpkg --print-architecture છાપે છે amd64, અને વેન્ડરનું પૃષ્ઠ સામાન્ય Debian પેકેજની બાજુમાં amd64 પેકેજની યાદી આપે છે. તમે ખરેખર ઇન્સ્ટોલ કરેલી ફાઇલના નામમાંની રિલીઝ શબ્દમાળા વાંચો, બંને મળે છે એમ ધારવાને બદલે.

2013 નું i386 માટે બનેલું આર્કાઇવ ફક્ત એટલા માટે 64-બિટ બનતું નથી કે તમે --force-architecture પાસ કર્યું. તેને ફરજિયાત ઇન્સ્ટોલ કરવાથી વિદેશી બાઇનરીઓ બેસે છે, હજી ચાલુ થતા લોન્ચર પાછળ નિર્ભરતાની નિષ્ફળતા છુપાય છે, અને ડેમન ખોટી લાઇબ્રેરીઓ લોડ કરી શકે છે. જો તમારી રિલીઝ ફક્ત 32-બિટ હોય, તો તેને 32-બિટ પર્યાવરણમાં ચલાવો અથવા ગેટવે માલિકને વર્તમાન બિલ્ડ માટે પૂછો.

નિર્ભરતા લાઇન પણ તપાસો. dpkg -s kerio-control-vpnclient | grep -i depends પેકેજ શું અપેક્ષા રાખે છે તે બતાવે છે, અને અપૂર્ણ વર્ઝન પિન અથવા ગુમ થયેલી રનટાઇમ લાઇબ્રેરી અહીં દેખાય છે, ક્લાયન્ટ લોગમાં નહીં.

પેકેજ વિઝાર્ડ દ્વારા તેને ગોઠવો

ડિઝાઇન મુજબ ક્લાયન્ટની એપ ડ્રોઅરમાં કોઈ એન્ટ્રી નથી, તેથી ગુમ થયેલું આઇકન કોન્ફિગરેશન સફળ થયું કે નહીં તે વિશે કંઈ કહેતું નથી. વિઝાર્ડ ફરી ખોલવા માટે sudo dpkg-reconfigure kerio-control-vpnclient ચલાવો અને તેના પ્રશ્નોના જવાબ આપો: VPN એન્ડપોઇન્ટ, ખાતાની વિગતો અને સર્વર પ્રમાણપત્રની ફિંગરપ્રિન્ટ.

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

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

વિઝાર્ડ જે ફાઇલ લખે છે તેને જાણો

કોન્ફિગરેશન આમાં રહે છે: /etc/kerio-kvc.conf અને તે ખાતું અને પિન કરેલી ફિંગરપ્રિન્ટ બંને ધરાવે છે. તેને ગોપનીય સામગ્રી ગણો. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf તેને બધા માટે વાંચી શકાય તેમ દર્શાવવું જોઈએ નહીં.

અધિકૃત હસ્તચાલિત ફેરફાર પછી, નેટવર્ક સ્ટેક ફરી શરૂ કરવાને બદલે ફાઇલ ધરાવતા ડેમનને ફરી લોડ કરો: sudo /etc/init.d/kerio-kvc reload. ફરી લોડ કરવાથી કોન્ફિગરેશન ફરી વંચાય છે અને વર્તમાન સેશન છૂટી જાય છે, તેથી જીવંત જોડાણ પર તે નિષ્ક્રિય કાર્ય નથી.

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

જીવંત સેશનને બૂટ વર્તનથી અલગ કરો

સેવા સ્ક્રિપ્ટ વર્તમાન જોડાણને નિયંત્રિત કરે છે: sudo /etc/init.d/kerio-kvc stop હવે ટનલ સમાપ્ત કરે છે અને start તેને પાછી લાવે છે. બંનેમાંથી કોઈ આદેશ નક્કી કરતો નથી કે આગલા બૂટ પર શું થશે, અને દૂરથી સંચાલિત મશીન પર તે તફાવત મહત્વનો છે.

લિંક દૂર કરતા કે કંઈક માસ્ક કરતા પહેલાં કોનું સ્ટાર્ટઅપ છે તે તપાસો. પેકેજ પોતાની init સ્ક્રિપ્ટ ઇન્સ્ટોલ કરી શકે, unit બનાવી શકે, અથવા બંને કરે, અને ખોટું નામ નિષ્ક્રિય કરવાથી રીબૂટ પછી ક્લાયન્ટ પાછો આવે છે. systemctl status kerio-kvc ને પેકેજ દસ્તાવેજીકરણમાં વપરાતા નામ સામે ચકાસો, પછી બૂટ પ્રક્રિયા ખરેખર જે પાથ વાંચે છે તે નિષ્ક્રિય કરો.

કોન્ફિગરેશન સરખું દેખાય છે એટલે OpenVPN unit બદલશો નહીં. આ ક્લાયન્ટ Kerio ગેટવે સાથે પોતાના પ્રોટોકોલમાં વાત કરે છે, તેથી એ જ ફાઇલ તરફ નિર્દેશિત બીજો ડેમન પ્રમાણીકરણ કરશે નહીં, અને વધારાની નિષ્ફળતા પુરાવા વાંચવાનું મુશ્કેલ બનાવે છે. GFI નો Linux ક્લાયન્ટ પણ એક સમયે ફક્ત એક VPN જોડાણ રાખે છે; તે મર્યાદા ક્લાયન્ટને લાગુ પડે છે, ગેટવેની વપરાશકર્તા ક્ષમતાને નહીં.

લોગ વાંચો, પછી સંસાધન ચકાસો

ત્રણ ફાઇલો /var/log/kerio-kvc ડેમનની વાર્તા કહે છે: init.log જીવનચક્રની ઘટનાઓ માટે, error.log ગંભીર નિષ્ફળતાઓ માટે અને debug.log વિગતો માટે. તમારા પ્રશ્નનો જવાબ આપતો સૌથી નાનો અંશ વાંચો, અને ક્યાંય પણ પેસ્ટ કરતા પહેલાં એન્ડપોઇન્ટ અને વપરાશકર્તાનામો દૂર કરો. init.log માં વિઝાર્ડ ચલાવ્યાના સમયની આસપાસ ખાલી જગ્યા હોય તો ખબર પડે કે ડેમન ક્યારેય ફરી શરૂ થયો નથી.

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

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