VPN ટનલમાં traceroute એક જ દિશામાં કેમ મરે છે

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

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

તારો એ ખૂટતો જવાબ છે, ખૂટતો હોપ નહીં

traceroute દરેક રાઉન્ડમાં એવા પ્રોબ મોકલીને બહાર તરફ આગળ વધે છે જેમનું TTL એક રાઉટર વધુ દૂર સમાપ્ત થાય છે. સમાપ્ત થયેલો પ્રોબ ફેંકી દેતા રાઉટરે પોતાનું નામ દર્શાવતો ICMP Time Exceeded સંદેશ પાછો આપવો જોઈએ, અને સાધન તે નામ છાપે છે. સાધન ખરેખર જેની રાહ જુએ છે તે એ છે કે તે સંદેશ સમયમર્યાદામાં આવે. જો રાઉટર બીજા સ્રોત સરનામેથી જવાબ આપે, ભૂલો ઉત્પન્ન કરવાની આવૃત્તિ મર્યાદિત કરે અથવા પ્રોબને શબ્દ વિના પડતો મૂકે, તો રાઉન્ડ છાપવા જેવું કંઈ આપતું નથી.

આમાંનું કોઈ પરિણામ એમ નથી કહેતું કે આગળનો માર્ગ તૂટેલો છે. તારો એ અનુત્તરિત ટપાલનો અહેવાલ છે, ખાલી રસ્તાનો નહીં.

પ્રોબ પદ્ધતિ નક્કી કરે છે કે તમે કયા ફિલ્ટરને મળશો

Linux પર ડિફોલ્ટ પદ્ધતિ સામાન્ય રીતે ઊંચા નંબરનો UDP ગંતવ્ય પોર્ટ હોય છે, Windowsનું tracert ICMP પડઘા મોકલે છે, અને Linuxને તેના બદલે ICMP કે TCP વાપરવાનું કહી શકાય છે. આમાંથી દરેક સ્ટેટફુલ ફાયરવોલ કે ક્લાઉડ સુરક્ષા જૂથ માટે અલગ પ્રકારની ટ્રાફિક જેવું દેખાય છે. એક બાજુના UDP ટ્રેસની બીજી બાજુના ICMP ટ્રેસ સાથે સરખામણી બે અલગ પ્રયોગોની સરખામણી છે. પરિણામોને તફાવત કહેતા પહેલા પદ્ધતિ, સરનામા કુટુંબ, સ્રોત સરનામું અને સમયમર્યાદા નિશ્ચિત કરો.

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

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

પરત માર્ગ પોતાનો એક રૂટ છે

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

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

વાસ્તવિક વિનંતીથી ટનલની પુષ્ટિ કરો

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

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

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

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