VPN MTU ના ભ્રમ: તમારા પેકેટ કેમ સંકોચાય છે અને જગ્યા ક્યાં જાય છે

કોઈ તમને કહે છે કે VPN "MTU ને કારણે પેકેટ ગુમાવે છે", તમે ટનલને 1400 પર સેટ કરો છો, અને ટ્રાન્સફર ફરી કામ કરે છે. એ પરિણામ નિદાન જેવું લાગે છે. સામાન્ય રીતે તે ગણિતનો સંયોગ છે: તમે એટલી નાની સંખ્યા પસંદ કરી છે જે એવી મર્યાદા હેઠળ બેસે જે તમે ક્યારેય ઓળખી નથી, અને આગલા નેટવર્ક પર અલગ બજેટ સાથે તમે ફરી એ જ મર્યાદા મળશો.

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

પ્રથમ ભ્રમ: ટનલનું MTU એ પાથનું MTU છે

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

પાથ-MTU શોધ બંનેને સુમેળ કરવા માટે છે, અને તે પ્રતિસાદ પર આધાર રાખે છે. IPv4 માં, જે રાઉટર પૂર્ણ કદનું પેકેટ આગળ મોકલી શકતું નથી તેણે ICMP "fragmentation needed" સંદેશ મોકલવો જોઈએ, અને પ્રેષક તેનો અંદાજ ઘટાડે છે. IPv6 માં સમકક્ષ Packet Too Big સંદેશ છે, અને રાઉટર ટ્રાન્ઝિટમાં જ ફ્રેગમેન્ટ કરતા નથી. જ્યારે એ પ્રતિસાદ ફિલ્ટર થાય, ત્યારે પ્રેષક એવા પેકેટ બનાવવાનું ચાલુ રાખે છે જે પાથ વહન કરી શકતો નથી, અને કંઈ તેને કેમ કહેતું નથી.

બીજો ભ્રમ: એન્કેપ્સ્યુલેશનનો ખર્ચ એક હેડર છે

બહારના સ્તરો પ્રામાણિકપણે ગણો. બહારનું IP હેડર IPv4 માં 20 બાઇટ અથવા IPv6 માં 40 છે. NAT પાર કરવા માટે UDP એન્કેપ્સ્યુલેશન 8 ઉમેરે છે. ટનલ પ્રોટોકોલ પોતાનું હેડર ઉમેરે છે, ઇનિશિયલાઇઝેશન વેક્ટર અથવા નોન્સ, સાઇફરના બ્લોક અથવા સંરેખણ સીમા સુધી પેડિંગ, ટ્રેઇલર અને ઇન્ટિગ્રિટી ચેક મૂલ્ય. પ્રોટોકોલ અને સાઇફર પ્રમાણે, અંદરનું પેકેટ શરૂ થાય તે પહેલાં જ કુલ આરામથી ડઝનબંધ બાઇટમાં આવી જાય છે.

પછી અંદરના પેકેટના પોતાના હેડરો માટે ફરી બાદ કરો. ટનલની અંદરનું TCP સેગમેન્ટ પોતાનું 20 બાઇટનું IP હેડર અને 20 બાઇટનું TCP હેડર વહન કરે છે, અને TCP નું MSS MTU પરથી લેવાય છે, ટનલના નામમાત્ર પેલોડ પરથી નહીં. તેથી ping નાના પેલોડ સાથે સફળ થઈ શકે છે જ્યારે ફાઇલ ટ્રાન્સફર અટકી જાય છે: સાધનો જુદી જુદી વસ્તુઓ ચકાસે છે, અને તેમાંથી ફક્ત એક જ પૂર્ણ કદના TCP સેગમેન્ટનો ઉપયોગ કરે છે.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

પ્રથમ આદેશ સેટ કરેલું ટનલ MTU જણાવે છે. બે પ્રોબ 1472 બાઇટનો પેલોડ મોકલે છે, જે IPv4 અને ICMP હેડરોના 28 બાઇટ સાથે 1500 બાઇટનું પેકેટ છે, પછી નાનું. જો મોટો પ્રોબ સંપૂર્ણ નિષ્ફળ જાય અને નાનો સફળ થાય, તો તમારી પાસે કદ-આધારિત ખામી છે, સામાન્ય રૂટિંગ સમસ્યા નહીં.

ત્રીજો ભ્રમ: PPPoE હજી તમને સ્વચ્છ 1500 આપે છે

પરંપરાગત PPPoE એક્સેસ લિંક 1500 બાઇટનું IP પેકેટ વહન કરતી નથી. PPPoE હેડર અને PPP પ્રોટોકોલ ક્ષેત્ર ઇથરનેટ ફ્રેમની અંદર 8 બાઇટ લે છે, જે IP પેકેટ માટે 1492 છોડે છે. આ RFC 2516 માં વર્ણવેલી પરંપરાગત મર્યાદા છે. જો તમે આવી લિંક પર VPN ચલાવો, તો ટનલનો ઓવરહેડ એ 1492 માંથી આવે છે, 1500 માંથી નહીં.

RFC 4638 મોટા PPP પેલોડ પર વાટાઘાટ કરવાની રીત વ્યાખ્યાયિત કરે છે જ્યારે એક્સેસ કોન્સન્ટ્રેટર અને ગ્રાહકના સાધનો બંને તેને સમર્થન આપે, તેથી "આ કનેક્શન PPPoE વાપરે છે" એકલું કોઈ ચોક્કસ સંખ્યા સાબિત કરતું નથી. સ્થાનિક સેટિંગ મધ્યવર્તી ઉપકરણને એવું પેકેટ સ્વીકારવા મજબૂર કરી શકતું નથી જેના માટે તે ક્યારેય ગોઠવાયું નથી, તેથી ઉપયોગી પ્રશ્ન એ છે કે લિંકે ખરેખર શું વાટાઘાટ કરી, લેબલ શું કહે છે તે નહીં.

નિષ્ફળતા કેમ પસંદગીની લાગે છે

નાની વિનંતીઓ સફળ થાય અને મોટા ટ્રાન્સફર અટકી જાય એ પાથ-MTU બ્લેક હોલની ઉત્તમ ઓળખ છે. હેન્ડશેક, DNS ક્વેરી અને API કૉલ બધા ફિટ થાય છે; બલ્ક ટ્રાન્સફર પૂર્ણ કદના સેગમેન્ટ બનાવે છે જે એક કડી પર મરી જાય છે, અને સમસ્યા જણાવવાનો હતો તે ICMP સંદેશ ક્યારેય આવતો નથી. કનેક્શન ઠીક દેખાય છે અને ડાઉનલોડ લટકી જાય છે, જે લોકોને પાથને બદલે સર્વર તરફ જોવા મોકલે છે.

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

શું બદલવું, અને કયા ક્રમમાં

પુરાવાથી શરૂ કરો. ઉપરના પ્રોબથી ખાતરી કરો કે ખામી કદ-આધારિત છે, પછી સૌથી નાનું કદ જે પસાર થાય છે અને સૌથી મોટું જે નિષ્ફળ જાય છે તે શોધો. ટનલને દોષ આપતા પહેલાં એક્સેસ લિંકનું વાસ્તવિક MTU તપાસો; PPPoE લિંક તમારા VPN તેને અડે તે પહેલાં બજેટ મર્યાદિત કરે છે. મૂળ મૂલ્યોની નોંધ રાખો જેથી ફેરફાર પાછો ફેરવી શકાય.

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