IPsec પર મોટા પેકેટ ગાયબ થાય છે જ્યારે નાના ping કામ કરે છે

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

પેકેટ વિભાજિત કરી શકાય તેવી બે જગ્યા

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

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

સાઇઝનો નિર્ણય ખરેખર ક્યાં લેવાય છે

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

પહેલાં ઇન્ટરફેસનું મૂલ્ય તપાસો, પછી બાહ્ય વર્તન. બે આંકડા, બે તબક્કા, અને સામાન્ય રીતે તેમાંથી ફક્ત એક જ જવાબદાર હોય છે.

બાહ્ય બજેટ આંતરિક બજેટ નથી

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

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

IPv6 વિકલ્પોમાંથી એક દૂર કરે છે

IPv6 રાઉટર ટ્રાન્ઝિટમાં ફ્રેગમેન્ટ કરતા નથી, તેથી બાહ્ય પેકેટ ક્યાં તો બંધ બેસે છે અથવા Packet Too Big સંદેશ સાથે અદૃશ્ય થાય છે. તે સંદેશ એકમાત્ર પ્રતિસાદ માર્ગ બની જાય છે, અને તેને અવરોધવાથી પછીના દરેક મોટા ટ્રાન્સફર માટે પથ-શોધ તૂટી જાય છે. IPv4 રાઉટર જ્યારે બિટ સ્પષ્ટ હોય ત્યારે મોટું પેકેટ ફ્રેગમેન્ટ કરી શકે છે, જે બીજું કંઈ તે બિટ સેટ ન કરે ત્યાં સુધી ખામી છુપાવે છે.

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

TCP સેગમેન્ટ નીતિ સામાન્ય જવાબ નથી

મહત્તમ સેગમેન્ટ સાઇઝ મર્યાદિત કરવી TCP પ્રવાહોને મદદ કરે છે, અને જ્યારે સમસ્યા તેમના સુધી જ મર્યાદિત હોય ત્યારે તે કાયદેસર નિયંત્રણ છે. તેની UDP પર કોઈ અસર નથી, જે DNS, કેટલાક વૉઇસ પ્રોટોકોલ અને વેબ ટ્રાફિકનો વધતો હિસ્સો વહન કરે છે.

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

કામ કરવાનો ક્રમ

ટકી રહેતું સૌથી મોટું પેલોડ નોંધો, પછી ઇન્ટરફેસ MTU, પછી બાહ્ય પેકેટ ડુ-નોટ-ફ્રેગમેન્ટ બિટ ધરાવે છે કે નહીં, અને અંતે ICMP પ્રતિસાદ પ્રેષક સુધી પહોંચે છે કે નહીં. તે ક્રમ અનુમાન કર્યા વગર ખામી સાંકડી કરે છે. દરેક નિરીક્ષણ સમય-છાપ અને અંતિમ બિંદુ સાથે રાખો, કારણ કે માર્ગ બદલાય ત્યારે ચારેય આંકડા ખસે છે.

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