OpenConnect પૃષ્ઠો ટનલનું MTU ન ઘટાડો ત્યાં સુધી કેમ અટકી જાય છે

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

કદની સમસ્યાને નીતિની સમસ્યાથી અલગ કરો

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

આ પ્રક્રિયા એન્કેપ્સ્યુલેશન છે. દરેક અંદરના પેકેટને ટનલ હેડર મળે છે, તેથી જે પેલોડ ભૌતિક લિંકમાં ફિટ થતું હતું તે હવે ન ફિટ થતું બહારનું પેકેટ બને છે, અને do-not-fragment બિટ ધરાવતું કંઈ પણ બ્રાઉઝર સમજી શકે તેવા જવાબ વિના ફેંકી દેવાય છે.

do-not-fragment પ્રોબ વડે મર્યાદા માપો

અંદાજ લગાવવાને બદલે મર્યાદા માપો. એવા પ્રોબ મોકલો જે ફ્રેગમેન્ટેશન નકારે અને જવાબ પાછો ન આવે ત્યાં સુધી પેલોડ ડગલે ડગલે ઘટાડો, જેમ કે ping -M do -s 1472 host જેવા આદેશથી શરૂ કરો. DF સેટ હોય ત્યારે ફ્રેગમેન્ટેશનની જરૂર હોવાની ફરિયાદ કરતો જવાબ એટલે મૂલ્ય હજી ઘણું ઊંચું છે. 1462 પર, પછી 1452 પર પુનરાવર્તન કરો, અને જે પ્રથમ કદ જવાબ આપે ત્યાં થોભો. સંખ્યા તમે પ્રોબ કરેલા હોસ્ટ સાથે લખી રાખો, કારણ કે જવાબ તે માર્ગનો છે, સામાન્ય રીતે પ્રોટોકોલનો નહીં.

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

મૂલ્ય ટનલ ઉપકરણ પર લાગુ કરો

પરિણામ ક્લાયન્ટે બનાવેલા ઇન્ટરફેસ પર લાગુ કરો, Wi-Fi એડેપ્ટર પર નહીં. Linux ક્લાયન્ટ પર તે ip link set dev tun0 mtu 1300 અને પછી ip link show tun0 છે, મૂલ્ય સ્વીકારાયું છે તેની ખાતરી કરવા. ક્લાયન્ટ જે પણ ઉપકરણનું નામ જણાવે તે વાપરો, કારણ કે તે અમલીકરણ અને ટનલ કેવી રીતે બની તેના આધારે બદલાય છે.

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

પહેલા ક્લાયન્ટની પોતાની MTU વિનંતીઓ વાપરો

જ્યારે કૉલ તમે નિયંત્રિત કરો છો, ત્યારે ક્લાયન્ટ પછી પેચ થવાને બદલે કદ માંગી શકે છે. --mtu સર્વર પાસેથી ટનલ MTU માંગે છે, અને --base-mtu અંતર્ગત માર્ગનું MTU જાહેર કરે છે જેથી ગેટવે ટનલનો આંકડો કાઢી શકે. બંને વિનંતીઓ છે, અને ક્લાયન્ટનું મેન્યુઅલ ગેટવે બંમાંથી એક પણ માનશે તેવું વચન આપતું નથી.

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

જે ટ્રાન્સફર નિષ્ફળ ગયું તેનાથી ચકાસો, પછી તેને કાયમી બનાવો

સ્થાનિક ip link ફેરફાર ક્લાયન્ટ ટનલ ફરી બનાવે ત્યાં સુધી ટકે છે, જે આગલા ફરી કનેક્શન કે ફરી શરૂ કરવા પર થાય છે. મૂલ્ય ત્યાં મૂકો જ્યાં કનેક્શન શરૂ થાય છે: એક રેપર જે ક્લાયન્ટ ચલાવે અને પછી ઉપકરણ સમાયોજિત કરે, ExecStartPost પગલા સાથેનું systemd યુનિટ, અથવા ગેટવે સ્વીકારે ત્યારે ક્લાયન્ટ વિકલ્પ. પ્રોફાઇલની બાજુમાં વર્ઝન કંટ્રોલમાં રાખો જેથી આગલી વ્યક્તિ જોઈ શકે કે સંખ્યા કેમ ત્યાં છે.

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

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