MTU કે MSS? VPN નો ફેરફાર ખરેખર શું સુધારે છે
MTU નક્કી કરે છે કે લિંક શું વહન કરે; MSS તેની અંદરનો TCP પેલોડ મર્યાદિત કરે છે. સાચો મર્યાદિત કરો અને જાણો કે કયા પ્રોટોકોલ બંનેમાંથી કોઈ આવરી લેતું નથી.
પિંગ સફળ થાય છે, મોટા ટ્રાન્સફર અટકી જાય છે, અને ટનલ પોતાને સ્વસ્થ જાહેર કરે છે. કોઈ ઇન્ટરફેસની MTU ઘટાડે છે, બીજું MSS મર્યાદિત કરે છે, અને કેટલીકવાર સમસ્યા એવા કારણોસર જતી રહે છે જે કોઈ નોંધતું નથી. બે સંખ્યાઓ બે અલગ વસ્તુઓનું વર્ણન કરે છે, તેથી ખોટી બદલવાથી એવો ઉપાય મળે છે જે નસીબ જેવો લાગે. આ રીત છે: સ્તર ઓળખો, અનુરૂપ ગોઠવણ લાગુ કરો, પછી નવા કનેક્શન પર પરીક્ષણ કરો.
બે સંખ્યા, બે વસ્તુ
MTU લિંક અથવા ઇન્ટરફેસનું છે: તે સૌથી મોટું પેકેટ છે જેને ન તોડીને પસાર કરી શકાય. MSS TCPનું છે: તે સેગમેન્ટ વહન કરી શકે તેવો સૌથી મોટો TCP પેલોડ છે, અને તે TCP તથા IP હેડર બંનેને બાદ કરે છે. IPv4 ચાલતી સામાન્ય ઇથરનેટ લિંક પર 1500 બાઇટની MTU જાણીતી 1460 બાઇટની MSS આપે છે. આ સંખ્યાઓ અલગ સ્તરોનું વર્ણન કરે છે અને અલગ પ્રણાલીઓ દ્વારા અદલાબદલી થાય છે. તેમને ભેળવી દેવું સરળ છે કારણ કે બંને બાઇટમાં માપવામાં આવે છે અને બંને 1500ની નજીક છે.
એક ઇન્ટરફેસ સેટિંગ તરીકે આવે છે. બીજો SYN સેગમેન્ટની અંદર વિકલ્પ તરીકે આવે છે, જે એવા છેડાઓ વચ્ચે વાટાઘાટ થાય છે જે તમારો ઇન્ટરફેસ કદી જોતા નથી.
બહારનું વધારાનું ભાર ક્યાં પડે છે
VPN અંદરના પેકેટને બીજામાં મૂકે છે, અને બહારના પેકેટને ભૌતિક માર્ગમાં ફિટ થવું પડે છે. એન્કેપ્સ્યુલેશન હેડર, બહારનું IP હેડર, ટ્રાન્સપોર્ટ હેડર અને કોઈપણ પ્રમાણીકરણ ટેગ એ બધા એવા બાઇટ વાપરે છે જે અંદરનું પેકેટ વાપરી શકતું નથી. ટનલ ઇન્ટરફેસ 1500 પર રાખો તો બહારનું પેકેટ નિયમિતપણે માર્ગ વહન કરી શકે તેનાથી વધી જાય છે. 'ફ્રેગમેન્ટ ન કરો' બિટ સેટ હોય તો રાઉટર તેને ફેંકી દે છે અને ICMP ભૂલ પાછી મોકલવી જોઈએ; તે ભૂલ ફિલ્ટર થાય તો મોકલનારને કદી ખબર પડતી નથી.
તેથી નિષ્ફળતા પસંદગીયુક્ત લાગે છે. નાની વિનંતીઓ પૂરી થાય છે અને સેગમેન્ટ ભરે તેવું કંઈપણ અટકી જાય છે, કારણ કે ફક્ત મોટા પેકેટ જ ફેંકાય છે. પિંગ પસાર કરતી ટનલ એ ડેટા વહન કરતી ટનલ નથી.
MSS મર્યાદિત કરવું, અને તે ક્યાં લાગુ પડે
MSS ક્લેમ્પિંગ પસંદ કરેલા બિંદુને પસાર કરતી વખતે SYN સેગમેન્ટનું મૂલ્ય ફરીથી લખે છે, જેથી બંને છેડા કારણ જાણ્યા વિના નાનો પેલોડ પસંદ કરે. Linux પર તે mangle ટેબલનું લક્ષ્ય છે જે સ્પષ્ટ નિયમ દ્વારા લાગુ થાય છે, અને તેણે તમે ઇચ્છો તે દિશામાં SYN પેકેટને અથડાવવા જોઈએ. તેને ટનલ ઇન્ટરફેસ અને સરનામા શ્રેણી સુધી મર્યાદિત કરો, કારણ કે પહોળો નિયમ એવા ટ્રાફિકનું વર્તન બદલે છે જે કદી ટનલમાં પ્રવેશતું નથી.
અસર ફક્ત TCP પર છે. UDP એપ્લિકેશન, QUIC સત્ર અને પોતાના ડેટાગ્રામ બનાવતો કોઈપણ પ્રોટોકોલ તેનાથી અસ્પૃષ્ટ રહે છે.
સ્થિર માર્ગ સાથે નિદાન કરો
એક સમયે એક ચલ રાખો. તમે પસંદ કરો તેવા કદના પેકેટ સાથે પરીક્ષણ કરો, અને 'ફ્રેગમેન્ટ ન કરો' ફ્લેગ સેટ કરો જેથી કર્નલ પરિણામ છુપાવવાને બદલે જાહેર કરે.
નિષ્ફળતા ક્યાં શરૂ થાય છે તે નોંધો: ટનલની અંદર, ટનલ ઇન્ટરફેસ પર, અથવા એન્કેપ્સ્યુલેશન પછીના ભૌતિક માર્ગ પર. પછી એક સંખ્યા બદલો અને બીજું નહીં, એ જ પરીક્ષણ ફરીથી કરો. હાલના કનેક્શન જે MSS વાટાઘાટ કર્યો છે તે રાખે છે, તેથી નીતિ પરિવર્તન ફક્ત નવા કનેક્શન પર દેખાય છે, અને તેથી કેશ કરેલું પૃષ્ઠ કોઈપણ દિશામાં કંઈ સાબિત કરતું નથી. જો એક મોટું અપલોડ કામ કરવા લાગે, તો તમે તે માર્ગ વિશે શીખ્યા, તેના પરના દરેક પ્રોટોકોલ વિશે નહીં.
દરેક ફેરફાર શું સુધારતો નથી
ઇન્ટરફેસની MTU ઘટાડવાથી પહેલેથી સ્થપાયેલા સત્રની MSS બદલાતી નથી. MSS મર્યાદિત કરવાથી UDP પ્રવાહને મદદ મળતી નથી, અને જ્યાં ICMP ભૂલો ફક્ત એક દિશામાં ફિલ્ટર થાય છે તેવો માર્ગ સુધરતો નથી. દરેક ફેરફાર સમસ્યાનો એક વર્ગ સુધારે છે અને બાકીનું બરાબર જેમ હતું તેમ છોડી દે છે.
તમે કઈ ગોઠવણ લાગુ કરી, ક્યાં, અને કયા પરીક્ષણે તફાવત બતાવ્યો તે લખો, નહીં તો આગલો ઇજનેર બંને લાગુ કરે છે અને કયું મહત્ત્વનું હતું તે કહેવાની ક્ષમતા ગુમાવે છે. જો મર્યાદા વાસ્તવિક અને કાયમી હોય, તો તેને છુપાવતા ક્લેમ્પને બદલે તેને પ્રતિબિંબિત કરતી ટનલ MTU પસંદ કરો. જો મર્યાદિત કરવું જ પડે, તો નિયમને મર્યાદિત અને ટિપ્પણી સાથે રાખો, કારણ કે અસ્પષ્ટ mangle નિયમ મૂળભૂત રીતે કાયમી બની જાય છે.