IPv6 પેકેટ ખૂબ મોટું: મોટા VPN ટ્રાન્સફર કેમ અટકે છે

પિંગ કામ કરે છે, બ્રાઉઝર નાનું પૃષ્ઠ લોડ કરે છે અને ફાઇલ ટ્રાન્સફર અટકી જાય છે, આ બધું એક જ ટનલમાંથી IPv6 પર. આ પેટર્ન સામાન્ય રીતે એર્થ છે કે મોકલનારે પાથનું ખરું કદ ક્યારેય જાણ્યું નહીં, એવું નહીં કે ટનલ ધીમી છે. IPv6 અપેક્ષા રાખે છે કે રાઉટર Packet Too Big સંદેશ સાથે સમસ્યા જણાવે, અને એન્કેપ્સ્યુલેશન પેકેટ બહારના નેટવર્ક સુધી પહોંચે તે પહેલાં વધારાનો ભાર ઉમેરે છે. જો એ સંદેશ ફિલ્ટર થાય, તો મોકલનાર એવું કદ વારંવાર પુનરાવર્તિત કરે છે જે પસાર થઈ શકતું નથી.

નાની વિનંતીઓ, મોટા અટકાવ

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

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

Packet Too Big ફીડબેક છે, ટ્રાફિક નહીં

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

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

બંને સરનામા પરિવારો અલગથી ચકાસો

IPv6 ને અલગથી ચકાસો, કારણ કે સફળ IPv4 ટ્રાન્સફર IPv6 પાથ વિશે કંઈ પણ સાબિત કરતું નથી. પછી મોટું ટ્રાન્સફર અટકી હોય ત્યારે નિયંત્રણ સંદેશા કેપ્ચર કરો. બંને રેકોર્ડ સાથે મળીને કાં તો ફીડબેક જતું હોવાનું બતાવે છે, અથવા સાબિત કરે છે કે તે ક્યારેય પહોંચ્યું નહીં.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

પ્રોબ do-not-fragment બિટ સેટ કરીને પેકેટ મોકલે છે અને જે કદ પર તે નિષ્ફળ જાય તે જણાવે છે, એ જ સંખ્યા જે ટનલે સમાવવી પડે. રૂટ ક્વેરી એ ઇન્ટરફેસનું નામ આપે છે જે લક્ષ્યને લઈ જશે, તેથી તમે જાણો છો કે કઈ કડીનું MTU લાગુ પડે છે. કેપ્ચર ICMPv6 પ્રકાર 2, એટલે કે Packet Too Big સંદેશ, ફિલ્ટર કરે છે અને બતાવે છે કે તે આ હોસ્ટ સુધી પહોંચે છે કે નહીં. જો સંદેશ કેપ્ચરમાં દેખાય અને ટ્રાન્સફર હજી અટકે, તો મોકલનાર તેને અવગણે છે, જે તપાસને નેટવર્કને બદલે સ્ટેકમાં લઈ જાય છે.

પુરાવા પછી જ ટનલનું કદ બદલો

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

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