Linux પર Kerio: kvnet ને સર્વર જે MAC ની અપેક્ષા રાખે છે તે આપવી

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

સરનામું કેમ વારંવાર પાછું આવે છે

kvnet એ વર્ચ્યુઅલ એડેપ્ટર છે જે ક્લાયન્ટ કનેક્શન શરૂ થાય ત્યારે બનાવે છે અને સમાપ્ત થાય ત્યારે દૂર કરે છે. તેથી મેન્યુઅલ ip link set બરાબર તેટલું જ ટકે છે જેટલું તે સત્ર ટકે છે જેના પર તે લાગુ કરવામાં આવ્યું હતું, અને આગળનું કનેક્શન ક્લાયન્ટ જે ફાળવે તેનાથી શરૂ થાય છે. જે મશીન પર ક્લાયન્ટ અપેક્ષિત સરનામું લાગુ કરવામાં નિષ્ફળ જાય છે, ત્યાં દરેક પુનઃકનેક્શન એ જ અસંગતિ ફરી લાવે છે, અને લીઝ કે ઍક્સેસ નિયમ ઉપકરણને ફરી નકારે છે.

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

કિંમત ઇન્ટરફેસ પરથી નહીં, ક્લાયન્ટ પાસેથી વાંચો

Linux ક્લાયન્ટ વાટાઘાટની વિગતો તેના ડિબગ લોગમાં લખે છે, અને તે જે સરનામું વાપરવાનો ઇરાદો ધરાવે છે તે કનેક્શન ક્રમના છેલ્લા સરનામા-આકારના ટોકન તરીકે ત્યાં દેખાય છે. તેની સરખામણી કર્નલ ખરેખર જે ધરાવે છે તેની સાથે કરો, જે એક readlink દૂર છે: cat /sys/class/net/kvnet/address.

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

ઇન્ટરફેસ અસ્તિત્વમાં આવ્યા પછી તેને લાગુ કરો

NetworkManager ના વપરાશકર્તાઓ તેની ડિસ્પેચર ડિરેક્ટરીમાં સ્ક્રિપ્ટ મૂકી શકે છે અને ફક્ત ત્યારે જ કાર્ય કરી શકે છે જ્યારે VPN ઇન્ટરફેસ ઉપર આવે. systemd દ્વારા સંચાલિત ક્લાયન્ટને વધુ કાળજીની જરૂર છે: સેવા શરૂ થાય ત્યારે ચાલતું drop-in સામાન્ય રીતે એડેપ્ટર અસ્તિત્વમાં આવે તે પહેલાં સક્રિય થાય છે, તેથી હૂકે એડેપ્ટર ધારવાને બદલે ઇન્ટરફેસની રાહ જોવી જોઈએ. ત્યારે સરનામું સેટ કરો, અને જો લિંક ઉપર હોય ત્યારે કર્નલ ઇનકાર કરે, તો તેને નીચે ઉતારો, સરનામું સેટ કરો અને ફરી ઉપર લાવો. કાઢેલા ટોકનને ip link ને આપતા પહેલાં MAC પેટર્ન દ્વારા ફરી વાંચો, જેથી અણધારી લોગ લાઇન આર્ગ્યુમેન્ટ ન બની શકે.

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

લિંકને બદલે લીઝ ચકાસો

ip -4 -o addr show dev kvnet એ અપેક્ષિત શ્રેણીમાં સરનામું દર્શાવવું જોઈએ, ip neigh show dev kvnet એ ગેટવે દર્શાવવો જોઈએ, અને VPN પાછળની એક સેવાએ જવાબ આપવો જોઈએ. પછી એક વાર ડિસ્કનેક્ટ કરીને ફરી કનેક્ટ કરો; જો સરનામું પાછું આવે, તો હૂક ખોટી ઘટનાએ ચાલી રહ્યો છે અથવા બિલકુલ ચાલતો નથી.

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

અપગ્રેડ પછી વર્કઅરાઉન્ડ ફરી તપાસો

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

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