VPN પિંગ કામ કરે છે પણ વેબસાઇટ અટકી જાય છે: કદ તપાસો

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

સૌથી નાના પ્રશ્નથી સૌથી મોટા પ્રશ્ન સુધી જાઓ, અને દરેક પગલાએ ખરેખર શું સાબિત કર્યું તે લખો.

ઇકો પ્રતિભાવ ઘણા નાના પ્રશ્નનો જવાબ આપે છે

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

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

જોડાણ શરૂ થયું કે નહીં તે શોધો

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

કહેલી સંખ્યા સાથે કદ માપો

જ્યારે ભાર હેઠળ અટકવાનું દેખાય, ત્યારે ફ્રેગમેન્ટ ન કરવાનો બિટ સેટ કરીને એક પેકેટ કદની કસોટી કરો અને ગણતરી જણાવો જેથી પરિણામનો અર્થ થાય. iputils સાથે Linux પર, 1392 બાઇટનો પેલોડ વત્તા 8 બાઇટનું ICMP હેડર અને 20 બાઇટનું IPv4 હેડર બરાબર 1420 બાઇટનું આંતરિક પેકેટ બનાવે છે. ટિકિટમાં તે ગણતરી લખો, કારણ કે ગેટવે સુધી પહોંચતું નક્કર ping એપ્લિકેશન વિશે કંઈ સાબિત કરતું નથી.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

બહારના માર્ગનો હિસાબ કરો

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

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

એક સંખ્યા બદલો અને એપ્લિકેશન ફરી તપાસો

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

બદલાવના રેકોર્ડમાં ગણતરી રાખો: માપેલું કદ, તમે ધારેલો વધારાનો ભાર, અને તમે સેટ કરેલું મૂલ્ય. પછીથી તેની સમીક્ષા કરનાર કોઈપણ ધારણાને ચકાસી શકે છે, ping ના સ્ક્રીનશોટમાંથી ફરી કાઢવાને બદલે.

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