બધા ICMP બ્લોક કરવાથી કાર્યરત VPN માર્ગ કેમ તૂટે છે
માપ-આધારિત ફીડબેક સંદેશા ping ના જવાબો નથી. જ્યારે તે ક્યારેય આવતા નથી, નાના પેકેટ પસાર થાય છે, મોટા અદૃશ્ય થાય છે, અને ટનલ ધ્રૂજતી હોય તેમ લાગે છે.
જે ટનલ પ્રમાણીકરણ પસાર કરે છે, ping વહન કરે છે અને પછી પ્રથમ મોટા સ્થાનાંતરણ પર અટકી જાય છે, તે તૂટેલા VPN નહીં પણ ખોવાયેલા ICMP સંદેશની ઉત્તમ નિશાની છે. પ્રેષકને ક્યારેય ખબર પડતી નથી કે પેકેટ ખૂબ મોટું હતું, તે જ માપ ફરી પ્રયત્ન કરે છે, અને એપ્લિકેશન રાહ જુએ છે. આ સુધારવું ફાયરવોલ નીતિનો નિર્ણય છે, ક્લાયન્ટ ફરી ઇન્સ્ટોલ કરવાનો નહીં. ક્રમ મહત્વપૂર્ણ છે: માપની સીમા ક્યાં છે તે માપો, પછી જે નિયમે અહેવાલ ગળી લીધો તે સાંકડો કરો.
આ માર્ગ પર ICMP ખરેખર શું વહન કરે છે
IPv4 માર્ગ MTU શોધ એના પર આધાર રાખે છે કે રાઉટર જાણ કરે કે don't-fragment બિટ સેટ ધરાવતું પેકેટ આગળ મોકલી શકાયું નહીં. તે અહેવાલ ICMP Fragmentation Needed સંદેશ છે, અને તેના વિના પ્રેષક પાસે તેના સેગમેન્ટનું માપ ઘટાડવાનું કોઈ કારણ નથી. IPv6 વધુ કડક છે: રાઉટર ટ્રાન્ઝિટમાં ટુકડા કરતા નથી, તેથી ICMPv6 Packet Too Big સંદેશ એ જ એકમાત્ર સંકેત છે જે પ્રેષકને સંકોચવા મજબૂર કરે છે.
બંને સંદેશા નિયંત્રણ-સ્તરનો ફીડબેક છે, અને એક પણ નિદાનાત્મક પડઘો નથી. ping બ્લોક કરતી નીતિ અને બધા ICMP બ્લોક કરતી નીતિ નિયમોની યાદીમાં સમાન લાગે છે પણ નેટવર્ક પર ખૂબ જ અલગ વર્તે છે. બીજી સાચા માપની ટનલને સાંકળની સૌથી નાની કડી કરતાં મોટા કોઈપણ વસ્તુ માટે એકતરફી માર્ગમાં ફેરવી શકે છે.
કેટલાક પરિવહન પોતાની શોધ પ્રોબ પેકેટ સાથે લાગુ કરે છે, જેમ RFC 4821 વર્ણવે છે, અને તે આ ફીડબેક પર ઓછા આધાર રાખે છે. આ કયું પરિવહન ચલાવો છો તે તપાસવાની દલીલ છે, દરેક ટનલ પ્રતિરક્ષિત છે એમ માનવાની નહીં.
| સંદેશ | માર્ગ પર હેતુ | બ્લોક કરેલું હોય તો |
|---|---|---|
| ICMPv4 પ્રકાર 3 કોડ 4 | પેકેટ આગલી કડી માટે ખૂબ મોટું હતું | પ્રેષક ફરી પ્રયત્ન કરે છે અને અટકી જાય છે |
| ICMPv6 પ્રકાર 2 | Packet Too Big, IPv6 સમકક્ષ | એ જ અટકાવ, ટુકડા કરવાના કોઈ વિકલ્પ વિના |
| ICMP પ્રકાર 11 | સમય વીતી ગયો, traceroute વાપરે છે | નિદાન હોપ ગુમાવે છે, ટ્રાફિક તો વહેતો રહે છે |
| ICMP ઇકો વિનંતી અને જવાબ | પહોંચ પરીક્ષણ | ping નિષ્ફળ જાય, માર્ગ ઠીક હોઈ શકે |
નિષ્ફળતા માપ પર આધારિત છે
પૂછો કે નિષ્ફળતા પેકેટના માપ સાથે સહસંબંધ ધરાવે છે કે નહીં. લોગિન પૃષ્ઠ, DNS પ્રશ્ન અને ટૂંકો API કૉલ સફળ થાય છે, જ્યારે ફાઇલ અપલોડ, મોટો જવાબ કે ઇમેજ ડાઉનલોડ અટકી જાય છે. આ પેટર્ન બે છેડા વચ્ચે ક્યાંક માપની મર્યાદા તરફ ઇશારો કરે છે, પ્રમાણીકરણ કે રૂટિંગ તરફ નહીં. સફળ નાનું ping એ સીમા ક્યાં છે તે વિશે લગભગ કંઈ જ કહેતું નથી.
ટનલની અંદર બે સ્તર ધ્યાનમાં લેવા પડે: પેલોડ પેકેટ અને બહારનું એન્કેપ્સ્યુલેટેડ પેકેટ. અંદરનો પ્રેષક યોગ્ય રીતે વર્તી શકે છે જ્યારે બહારનો માર્ગ ટનલ ધારે છે તેના કરતાં નાનો હોય, અને તેથી ટનલનું પોતાનું MTU સેટિંગ અને તેની નીચેની ભૌતિક કડી બંને મહત્વપૂર્ણ છે.
નિયમો સંપાદિત કરતા પહેલા માપો
don't-fragment બિટ અને તમે પસંદ કરો તે પેલોડ માપ સાથે પ્રોબ કરો, નિષ્ફળ ક્લાયન્ટથી સુરક્ષિત સરનામા તરફ:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7
1472 બાઇટનો પેલોડ વત્તા 28 બાઇટ હેડર 1500 બાઇટનું પેકેટ બનાવે છે. જો મોટો પ્રોબ ટુકડા થવાની ભૂલ સાથે નિષ્ફળ જાય અને નાનો પસાર થાય, તો તમે સીમા શોધી કાઢી છે; ટનલના વધારાના ભાર માટે ગોઠવો અને કાર્યક્ષમ માપ સ્થિર થાય ત્યાં સુધી પુનરાવર્તન કરો.
પછી ખાતરી કરો કે ખાલી જગ્યા અહેવાલ પોતે જ છે. જો પ્રોબ શાંતિથી નિષ્ફળ જાય, કોઈ ભૂલ અને જવાબ વિના, તો સંદેશ કદાચ પહોંચાડવાને બદલે ફેંકી દેવાય છે, અને શંકાસ્પદ નિયમ છે.
નિયમ સાંકડો કરો, પછી કાર્ય ફરી ચકાસો
સુધારો ચોક્કસ નિયંત્રણ સંદેશાઓને મંજૂરી આપવો જોઈએ, આખું પ્રોટોકોલ નહીં. iptables યજમાન પર સ્વરૂપ પ્રકાર-વિશિષ્ટ સ્વીકાર છે; તમારા પ્લેટફોર્મ પર ફાયરવોલનું સંચાલન જે કરે તે મુજબ સિન્ટેક્સ ગોઠવો:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
જો તે સ્થાનિક નીતિ હોય તો ઇકો જવાબો બ્લોક રાખો, કારણ કે માર્ગને તેની જરૂર નથી. પછી મૂળ નિષ્ફળ ગયેલું સ્થાનાંતરણ નવા કનેક્શનથી ફરી ચકાસો, અને ખાતરી કરો કે નિયમના કાઉન્ટર સંદેશા આવતા દર્શાવે છે.
સંદેશાઓને મંજૂરી આપ્યા પછી પણ મોટું સ્થાનાંતરણ અટકે છે તો બાકીની મર્યાદા બીજે છે: ખૂબ ઊંચું સેટ કરેલું ટનલ MTU, પેકેટ ફરી લખતું પ્રોક્સી, અથવા જાણ કરવાને બદલે ફેંકી દેતું મધ્ય બોક્સ. ICMP નિયમ જરૂરી હતો, પર્યાપ્ત નહીં.