ક્લાયન્ટ પ્રમાણીકરણ કરે છે, લોગ કહે છે જોડાયેલ છે, અને કોઈ પેકેટ ટનલ પાર કરતું નથી. સર્વર write to TUN/TAP: Invalid argument (code=22) સાથે પ્રયાસ સમાપ્ત કરે છે, જે ડ્રાઇવરની ખામી જેવું લાગે છે અને સામાન્ય રીતે નથી. રાઉટર અને નાના Linux સર્વર પર, તે લાઇનનો અર્થ ઘણી વાર એ થાય છે કે બંને બાજુઓ ડેટા-પેકેટ કેવી રીતે ફ્રેમ થાય તે અંગે સહમત નથી, તેથી કર્નલ તેને આપવામાં આવેલ ડિક્રિપ્ટ થયેલ બફર નકારે છે. તે સમયે રાઉટિંગની કસોટી થઈ નથી.

સાચું રાઉટિંગ ટેબલ અને તૂટેલું ફ્રેમિંગ કરાર ક્લાયન્ટની બાજુથી સરખા દેખાય છે: જોડાયેલું, અને કંઈ કામ કરતું નથી.

ટનલ ઉપર આવે છે અને કંઈ તેને પાર કરતું નથી

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

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

કમ્પ્રેશન એ ફ્રેમિંગ છે, બેન્ડવિડ્થ નહીં

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

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

બંને છેડા સુસંગત કરો અથવા બંનેમાંથી દૂર કરો

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

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

પુશ અને ઉપકરણનો પ્રકાર તપાસો

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

બ્રિજવાળી TAP જમાવટ માટે સર્વર પર ખરેખર બ્રિજ જરૂરી છે, ફક્ત અલગ ઉપકરણ નામ નહીં. ઇન્ટરફેસને બ્રિજમાં ઉમેર્યા વિના tap0 નામ આપવાથી એવું ઉપકરણ બને છે જે લખાણ સ્વીકારે છે અને ક્યાંય જતું નથી.

પછી એક ક્લાયન્ટ અને એક ગંતવ્ય સાથે ચકાસો: સર્વરના ટનલ સરનામે પિંગ કરો, પછી તેના LAN પરના હોસ્ટ પર. પહેલું ડેટા-ચેનલ સાબિત કરે છે અને બીજું ફોરવર્ડિંગ.

સંબંધિત લેખો