OpenVPN mssfix: મોટા સ્થાનાંતરણમાં એક ક્લાયન્ટ કેમ અટકી જાય છે

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

વિકલ્પ શું ફરીથી લખે છે

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

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

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

વ્યાપ્તિ ટનલની અંદરનું TCP છે

ફક્ત TCP ટ્રાફિક ફરીથી લખાય છે. QUIC સત્ર, રમત કે મોટા UDP ડેટાગ્રામ મોકલતી એપ્લિકેશન પોતાના પેકેટ કદ રાખશે, અને જો તે જ સ્થાનાંતરણો અટકતા હોય, તો ઉકેલ ટનલ કે પથના MTU પર આવે છે. TCP વિકલ્પ તરફ જતાં પહેલાં નિષ્ફળ સ્થાનાંતરણ કયો પ્રોટોકોલ વાપરે છે તે વાંચો, કારણ કે ખોટા સ્તરનો પોતાનો ઉકેલ હોય છે.

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

સંખ્યા અને કીવર્ડ પોર્ટેબલ નથી

OpenVPN 2.6 ની સમુદાય આવૃત્તિ મૂલ્ય પછી વૈકલ્પિક કીવર્ડ સ્વીકારે છે. mtu સાથે, સંખ્યા IP અને UDP હેડર સહિત બાહ્ય પેકેટ કદ વર્ણવે છે; તેના વિના, આર્ગ્યુમેન્ટ બીજી હિસાબી પ્રથા અનુસરે છે. તેથી આવૃત્તિઓ વચ્ચે કૉપિ કરેલી લાઇન એક જ પેકેટ બજેટ વર્ણવતી નથી. બીજી આવૃત્તિના ટ્યુટોરિયલને બદલે તમે ખરેખર ચલાવો છો તે બિલ્ડ સાથે આવતું મેન્યુઅલ પૃષ્ઠ જુઓ.

સિન્ટેક્સ આવો દેખાય છે:

mssfix 1400 mtu

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

પહેલા એક જ ક્લાયન્ટ પર ખાતરી કરો

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

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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