પૃષ્ઠો લોડ થાય છે પણ VPN પર અપલોડ અટકી જાય છે: કયું કારણ જીતે છે
કદ પર આધારિત અટકવું પાથ MTU ખામી સાથે મેળ ખાય છે, અને DNS, એપ્લિકેશન મર્યાદા કે અસ્થિર ટનલ સાથે પણ મેળ ખાય છે. ચાર અવલોકનો નક્કી કરે છે કે કયું.
પૃષ્ઠો લોડ થાય છે, VPN જોડાયેલ હોવાનું જણાવે છે, અને ફાઇલ અપલોડ દર વખતે એ જ જગ્યાએ થીજી જાય છે. આ વર્ણન સાથે ચાર સમજૂતી મેળ ખાય છે: પેકેટ કદની સમસ્યા, નામ-ઉકેલની સમસ્યા, એપ્લિકેશન મર્યાદા અને સતત રીસેટ થતી ટનલ. તેમાંથી દરેકને અલગ અવલોકન દ્વારા સાબિત કે નકારી શકાય છે, તેથી નિર્ણય કારણ અનુમાન કરવાને બદલે યોગ્ય પરીક્ષણ પસંદ કરવાનો છે.
ચાર ઉમેદવાર અને એક આકાર
નિષ્ફળતાના આકારથી શરૂ કરો, કારણ કે કોઈ પણ સાધન ખોલતાં પહેલાં તે યાદીનો મોટો ભાગ દૂર કરે છે. સ્થિર કદ પર થતું અટકવું વિપરીત સાબિત ન થાય ત્યાં સુધી કદની સમસ્યા છે. અવ્યવસ્થિત જગ્યાઓ પર થતું અટકવું નુકસાન કે સ્થિરતાની સમસ્યા છે. જોડાણ ખૂલતાં પહેલાંની નિષ્ફળતા નામની સમસ્યા છે.
ચોથો ઉમેદવાર એપ્લિકેશન છે. અપલોડ મર્યાદા, વિનંતીના સમયગાળા અને પ્રોક્સીના બોડી-કદની ટોચમર્યાદા એવી નિષ્ફળતાઓ બનાવે છે જે બ્રાઉઝરથી નેટવર્ક ખામી જેવી લાગે છે, અને તે સામાન્ય રીતે અટકી જવાને બદલે અસ્વીકાર તરીકે આવે છે.
કંઈપણ પરીક્ષણ કરતાં પહેલાં અવલોકિત આકાર લખી લો. "લગભગ એ જ બાઇટ સંખ્યા પર, દર વખતે, ટનલ ચાલુ હોય ત્યારે અટકે છે" — "અપલોડ કામ કરતા નથી" કરતાં ઘણું મજબૂત પ્રારંભ બિંદુ છે.
પછી પરીક્ષણ દરમિયાન પાથ સ્થિર રાખો. એક્ઝિટ, પ્રોટોકોલ અને સર્વર એકસાથે બદલવાથી એવું પરિણામ આવે છે જે તમે તેમાંથી કોઈને આભારી શકતા નથી. દરેક રનમાં એક ચલ, અને તે લખી લો.
નીતિને સ્પર્શ કરતાં પહેલાં કદને ભાગો
સૌથી સસ્તું ભેદક એ એક સંખ્યા બદલતી પ્રોબ છે. ગંતવ્ય પર વધતા કદના, ફ્રેગમેન્ટેશન-પ્રતિબંધિત પિંગ મોકલો, અને તમે નિયંત્રિત કરો તે ફાઇલ તે જ સેવા પર અપલોડ કરો, પછી દરેક ક્યાં અટકે છે તેની સરખામણી કરો.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadપ્રથમ આદેશ જણાવે છે કે પૂર્ણ-કદનું પેકેટ પાથ પરથી પસાર થાય છે કે નહીં. 1500 બાઇટના MTU પર, જે ICMP પેલોડ ફ્રેગમેન્ટ થતું નથી તેનું મહત્તમ કદ 1472 બાઇટ છે, અને અંદરનું પેકેટ શરૂ થાય તે પહેલાં ટનલ તે બજેટમાંથી વધુ લઈ લે છે. બીજો એપ્લિકેશન-સ્તરના સ્થાનાંતરણ માટે કદ અને સમયગાળો આપે છે, અને તે જ ખરેખર મહત્ત્વની સંખ્યા છે.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
બંનેને સાથે વાંચો. થ્રેશોલ્ડ ઉપર નિષ્ફળ થતી પ્રોબ અને તે જ થ્રેશોલ્ડ નજીક અટકતું અપલોડ — આ સુસંગત વાર્તા છે. બધી પ્રોબ સફળ થાય પણ અપલોડ એવી બાઇટ સંખ્યા પર અટકે જે પાથ સ્પષ્ટપણે વહન કરે છે, તો તે એપ્લિકેશન કે સર્વર તરફ ઇશારો કરે છે, અને MTUનું કેટલું પણ કામ તેને બદલશે નહીં. તે નકારાત્મક પરિણામ સકારાત્મક જેટલું જ મૂલ્યવાન છે. તે તપાસની સૌથી ખર્ચાળ શાખા દૂર કરે છે.
પછી સ્થાનાંતરણ દરમિયાન સ્થિરતા તપાસો, કારણ કે મોટા અપલોડની વચ્ચે કી નવીકરણ કરતી ટનલ એવી નિષ્ફળતા બનાવે છે જે કદ-આધારિત લાગે છે પણ હોતી નથી. અપટાઇમ વાંચન તેને સાબિત કરવાનો સૌથી સસ્તો રસ્તો છે.
સમારકામ અને વૈકલ્પિક ઉપાય વચ્ચે નિર્ણય લો
જો પુરાવા કદ તરફ ઇશારો કરે, તો બે પ્રામાણિક જવાબ અને એક અપ્રામાણિક જવાબ છે. પ્રામાણિક એ છે કે જરૂરી ICMP પ્રતિસાદને મંજૂરી આપીને પાથ-MTU શોધ પુનઃસ્થાપિત કરવી, અથવા જાહેર કરેલ સેગમેન્ટ કદ મર્યાદિત કરવું જેથી સાથીઓ નાના સેગમેન્ટ મોકલે. અપ્રામાણિક એ છે કે ઇન્ટરફેસ MTUને ફોરમમાંથી નકલ કરેલા મૂલ્ય સુધી ઘટાડવું અને તે શું બદલ્યું તે કદી ચકાસવું નહીં.
પસંદગી તમે શું નિયંત્રિત કરો છો તેના પર આધાર રાખે છે. તમે ચલાવો તે નેટવર્ક પર, ICMP સંદેશાઓને મંજૂરી આપવી તે વધુ સ્વચ્છ સુધારો છે કારણ કે તે દરેક પ્રોટોકોલ માટે ક્રિયાતંત્ર ચાલુ રાખે છે. જે પાથ તમે નિયંત્રિત કરતા નથી, ત્યાં મર્યાદિત કરવું વ્યવહારુ વિકલ્પ છે, અને તે સમગ્ર સર્વર પર નહીં પણ સાંકડી રીતે લાગુ થવું જોઈએ.
જો પુરાવા એપ્લિકેશન તરફ ઇશારો કરે, તો એપ્લિકેશન કે તેનું પ્રોક્સી રૂપરેખાંકન સુધારો. 413 પ્રતિસાદ અને લટકતું જોડાણ જુદી જુદી નિષ્ફળતાઓ છે, અને બીજી સામાન્ય રીતે પોતાની મર્યાદાઓ ધરાવતી પ્રોક્સી સહિતની શૃંખલામાં ક્યાંક સમયમર્યાદા હોય છે.
ગમે તે રીતે, મૂળ મૂલ્યો રાખો અને પાછું ફેરવ્યા પછી ફરી પરીક્ષણ કરો. સફળ સ્થાનાંતરણ સાથે એકસાથે થતો ફેરફાર એ પુરાવો નથી કે તેને કારણે જ થયું, અને પાછું ફેરવવાની ક્ષમતા જ નિદાનને સંજોગથી અલગ પાડે છે.
નિર્ણય નોંધો જેથી આગલી ઘટના સુધી ટકે
ચાર હકીકતો પૂરતી છે: અવલોકિત નિષ્ફળતાનો આકાર, પ્રોબના પરિણામો, તમે કરેલો ફેરફાર અને પુનઃપરીક્ષણનું પરિણામ. તેનાથી આગળની વ્યક્તિ કહી શકે કે સમસ્યા એ જ છે કે એ જ લક્ષણવાળી નવી.
પાથનો સંદર્ભ પણ નોંધો, કારણ કે MTU સંબંધિત શોધ ચોક્કસ લિંક માટે જ છે. ઘરે કામ કરતો અને હોટેલમાં નિષ્ફળ જતો લેપટોપ બે પાથ ધરાવે છે, અને એક પર લાગુ કરેલો સુધારો બીજા વિશે કંઈ કહેતો નથી.
છેવટે, "VPNએ અપલોડ તોડી નાખ્યા" એવા સારાંશ સામે ઊભા રહો. ટનલ કામ કરતા અને નિષ્ફળ બન્ને કિસ્સામાં હાજર હતી; જે બદલાયું તે પાથે વહન કરવાનું હતું તે પેકેટનું કદ, અથવા જ્યાં સ્થાનાંતરણ અટકાવાયું તે સ્થળ. વાસ્તવિક ક્રિયાતંત્રનું નામ આપવું જ નોંધને ઉપયોગી બનાવે છે.