VPN દ્વારા પાથ MTU શોધ: કદ અને ICMP ગેપ

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

પાથ MTU ખરેખર શું માપે છે

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

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

ટનલ વપરાયોગ્ય પેકેટને કેમ નાનું કરે છે

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

વ્યવહારુ પરિણામ એ કદ છે જે હેન્ડશેકમાં ફિટ થાય અને પેલોડમાં નહીં. TLS ClientHello કે DNS ક્વેરી નાની પૂરતી હોય છે કે નાના થયેલા પાથને અડ્યા વિના પાર કરે, જ્યારે મોટું ટ્રાન્સફર નહીં. તેથી લક્ષણો ચોક્કસ હોસ્ટની આસપાસ નહીં, ચોક્કસ ક્રિયાઓની આસપાસ ભેગાં થાય છે.

શોધ ત્યારે જ કામ કરે છે જ્યારે પ્રતિસાદ આવે

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

જે ફાયરવોલ echo request અને echo reply ને મંજૂરી આપે છે તેણે જરૂરી નથી કે એ ભૂલ પ્રકારોને પણ મંજૂરી આપી હોય. ICMP એક પરિવાર છે, અને અહીં મહત્વના સભ્યો ભૂલો છે, ઇકો જોડી નહીં. ટનલના બંને છેડે અને તેમની વચ્ચેના માર્ગ પર નિયંત્રણ-ટ્રાફિક નીતિ તપાસો, અને દરેક જગ્યાએ દરેક ICMP પ્રકારને મંજૂરી આપવાને બદલે પ્લેટફોર્મના સમર્થિત માર્ગદર્શનને અનુસરો.

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

આંકડાનું અનુમાન કરવાને બદલે પાથને પ્રોબ કરો

ગંતવ્ય, એક્સેસ નેટવર્ક અને ટનલ સ્થિર રાખો, પછી ફક્ત પેકેટનું કદ બદલો. MTU સંકેત સાથે નિષ્ફળ જતો don't-fragment પ્રોબ તમને આગલા હોપની મર્યાદા આપે છે; કદ પસાર થાય ત્યાં સુધી પુનરાવર્તન કરો, અને કદ તથા સરનામા પરિવાર બંને નોંધો.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

PLPMTUD, RFC 4821 માં વર્ણવેલું, ઉપર તરફ પ્રોબ કરે છે અને પહોંચાડેલી ભૂલો પર ભરોસો કરવાને બદલે ટ્રાન્સપોર્ટ સ્વીકૃતિઓ વાપરે છે. તે ICMP ફિલ્ટર કરતા પાથ પર મદદ કરે છે, પણ સમર્થન સ્ટેક અને એપ્લિકેશન પ્રમાણે બદલાય છે. TCP ફ્લો જાતે સુધરી શકે છે જ્યારે નિશ્ચિત ડેટાગ્રામ કદવાળી UDP એપ્લિકેશન નિષ્ફળ થતી રહે છે.

મૂલ્ય પસંદ કરો અને કારણ નોંધો

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

IPv4 મિકેનિઝમ RFC 1191 માં અને IPv6 પેકેટાઇઝેશન માર્ગદર્શન RFC 8201 માં વર્ણવેલું છે; બંનેનું નામ લેવાથી આગલો ઇજનેર ધારણાને ફરી તારવતો નથી. જો તમે પસંદ કરેલા કદ પર ટ્રાન્સફર હજી અટકે, તો આંકડો ઘટાડવાનું બંધ કરો અને આગલા સ્તર તરફ જુઓ. દરેક કદ પર નિષ્ફળ જતો પાથ MTU સમસ્યા નથી.