VPN દ્વારા ping: પ્રતિધ્વનિ જવાબના નિયમો પરત માર્ગ કેમ ચૂકે છે

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

પેકેટ પોર્ટ નહીં, પ્રકાર બદલે છે

પ્રતિધ્વનિ વિનંતી ICMP પ્રકાર 8, કોડ 0 છે, અને ઓળખકર્તા તથા ક્રમ નંબર ધરાવે છે. જવાબ પ્રકાર 0, કોડ 0 છે, તે જ ઓળખકર્તા અને ક્રમ સાથે, અને IP છેડા અદલાબદલી થયેલા છે. RFC 792 તે ક્ષેત્રો વ્યાખ્યાયિત કરે છે, અને ઓળખકર્તા જ મોકલનારને જવાબોને પોતાની વિનંતીઓ સાથે મેળવવા દે છે.

જે ખૂટે છે તે પણ એટલું જ મહત્વનું છે: કોઈ TCP કે UDP હેડર નથી, તેથી પરવાનગી આપવા જેવો કોઈ પોર્ટ નથી. પ્રતિધ્વનિ જવાબ માટે પોર્ટનું નામ લેતો નિયમ એવા પેકેટનું વર્ણન કરે છે જે ક્યારેય અસ્તિત્વમાં નહીં આવે. VPN ping ટિકિટમાં આ સૌથી સામાન્ય ભૂલ છે. નિયમ ચોક્કસ લાગે છે, કંઈને લાગુ પડતો નથી, અને નિષ્ફળતાને બરાબર જ્યાં હતી ત્યાં જ રહેવા દે છે.

ત્રણ સંદર્ભો પેકેટ નક્કી કરે છે

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

આ ત્રણ સંદર્ભોમાં નિયમ-શૃંખલાઓ અને કાઉન્ટરો અલગ છે, અને તેમને એક ગણવા એ જ કારણ છે કે «ફાયરવોલ ICMPને પરવાનગી આપે છે» છતાં ping નિષ્ફળ આવી શકે. બાહ્ય ટનલ ચોથો સંદર્ભ છે: VPN શ્રોતાને પરવાનગી આપવાથી ડિકેપ્સ્યુલેટ થયેલી અંદરની વિનંતી આપોઆપ પરવાનગી નથી મળતી, અને અંદરની પરવાનગી બાહ્ય ટનલ ચાલુ છે કે નહીં તે વિશે કંઈ કહેતી નથી.

સ્ટેટફુલ અને સ્ટેટલેસ ફિલ્ટરો જવાબને અલગ રીતે સંભાળે છે

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

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

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

અનુવાદ ઓળખકર્તા પણ બદલે છે

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

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

ICMP ભૂલોને પ્રતિધ્વનિ નીતિમાં ભેળવશો નહીં

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

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

જ્યારે પ્રતિધ્વનિ આદાનપ્રદાન કામ કરે, ત્યારે વાસ્તવિક એપ્લિકેશન અલગથી ચકાસો. સફળ ping એક પ્રોટોકોલની એક કદમાં એક લક્ષ્ય સુધીની આવ-જા સાબિત કરે છે, અને HTTPS, SMB કે બીજો કોઈ પ્રવાહ પરવાનગીપ્રાપ્ત છે એમ ધારી લેવાનું લાઇસન્સ નથી.