OpenVPN પર SSH અટકી જાય છે? પહેલાં પાથ MTU માપો

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

પ્રોફાઇલને સ્પર્શતા પહેલાં નિષ્ફળતાનો આકાર વાંચો

નાના પેકેટ પસાર થાય છે અને ભરેલા નહીં. પ્રોમ્પ્ટ, બેનર કે એક કી-દબાણ સરળતાથી બેસે છે; ડિરેક્ટરી યાદી, ડાઉનલોડ કે પેસ્ટ કરેલો બ્લોક બેસતો નથી. જે કદ પર વર્તન બદલાય છે તે સંકેત છે, એ નહીં કે SSH સંબંધિત પ્રોગ્રામ છે.

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

બંને બાજુથી મર્યાદા માપો

બંનેમાંથી કોઈ પણ બદલતા પહેલાં ટનલની MTUની ભૌતિક કડી સાથે તુલના કરો. ભૌતિક મૂલ્ય નકલ કરેલી ટનલ પહેલેથી જ કહી દે છે કે અસંગતિ ક્યાં છે.

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

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix અને fragment જુદાં કામ કરે છે

mssfix ટનલની અંદરના TCP જોડાણો તેમના હેન્ડશેક દરમિયાન જાહેર કરે તે સેગમેન્ટ કદ મર્યાદિત કરે છે. SSH, HTTPS અને ફાઇલ નકલ માટે તે યોગ્ય લિવર છે, તેથી તે સેટ થતાં જ અટકી જવું ઘણી વાર મટી જાય છે. તે UDP પેલોડને બિલકુલ સ્પર્શતું નથી.

UDP સેવા પણ વહન કરતી ટનલ SSH ઠીક થયા પછી પણ નિષ્ફળ થઈ શકે છે, અને એ પરિણામ એવા દરેકને મૂંઝવે છે જે માને છે કે એક જ વિકલ્પ બધું આવરી લે છે.

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

ઇન્ટરફેસ MTU ઘટાડવું એ જાડું વિકલ્પ છે

બંને છેડે ઇન્ટરફેસ MTU ઘટાડવું એ જાડું સાધન છે. તે દરેક અંદરના મોકલનારને નાનો આંકડો કહે છે, જે કામ કરે છે, અને એ ખર્ચ જરૂરી TCP પ્રવાહોને બદલે બધા ટ્રાફિક પર નાખે છે.

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

જે સ્થાનાંતરણ અટકી ગયું તેની સાથે ફરી પરીક્ષણ કરો

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

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