VPN ક્લાયન્ટ ટ્રાફિક અને ફાયરવોલ સ્થિતિ: બહારનો અને અંદરનો પ્રવાહ
ટનલનો પ્રવાહ અને ડિકેપ્સ્યુલેટેડ કનેક્શન અલગ પેકેટ છે. નક્કી કરો કે તમે કયાને મંજૂરી આપો છો, અને દરેક સીમા સ્થિતિ ટ્રેક કરે છે કે નહીં.
VPN હેન્ડશેક પૂર્ણ થાય છે, ક્લાયન્ટને સરનામું મળે છે, અને ગેટવે પાછળની સેવા હજી પણ કનેક્શન નકારે છે. ફાયરવોલ ઘણી વાર તેને જે કહેવામાં આવ્યું હોય તે જ કરે છે. તેણે બહારના ટનલ પ્રવાહને મંજૂરી આપી, જે ડિકેપ્સ્યુલેટેડ એપ્લિકેશન કનેક્શનથી અલગ પેકેટ છે. ત્યારબાદ બે નિર્ણય આવે છે: તમે કયા પ્રવાહને મંજૂરી આપો છો, અને સીમા બિલકુલ સ્થિતિ ટ્રેક કરે છે કે નહીં.
જ્યાં સુધી તમે આ બેને અલગ ન કરો, દરેક નિયમ ફેરફાર એક અનુમાન છે.
ફાયરવોલ બે અલગ પેકેટ જુએ છે
ડિકેપ્સ્યુલેશન પહેલાં, ફાયરવોલ VPN એન્ડપોઇન્ટને સંબોધિત ટ્રાફિક જુએ છે: શ્રોતા તરફ બહારનો UDP પ્રવાહ. ડિકેપ્સ્યુલેશન પછી, ફોરવર્ડ કરેલું પેકેટ ક્લાયન્ટનું અંદરનું સરનામું અને સેવાનું લક્ષ્ય વહન કરે છે.
બહારના પ્રવાહ માટેની મંજૂરી ફોરવર્ડ કરેલા TCP કનેક્શનને અધિકૃત કરતી નથી. તેમનું મૂલ્યાંકન અલગ ચેઇનમાં, અલગ ઇન્ટરફેસ સામે અને અનુવાદ પછી અલગ સરનામાંઓ સાથે થઈ શકે છે.
બંને બાજુના સમાન સ્થાનોની કેપ્ચર્સની સરખામણી કરો. ટનલની ધાર પરનું કેપ્ચર અને સર્વર પરનું કેપ્ચર એક જ સત્ર માટે અલગ ટ્યુપલ દર્શાવે છે.
પ્રથમ નિર્ણય: ટનલ કે સેવાને મંજૂરી
જો ક્લાયન્ટને ફક્ત VPN એન્ડપોઇન્ટની જ જરૂર હોય, તો બહારની મંજૂરી પૂરતી હોઈ શકે. જો તેને ગેટવેની બહાર સેવાની જરૂર હોય, તો તે લક્ષ્ય અને પોર્ટ માટે ફોરવર્ડિંગ મંજૂરીની જરૂર છે. જે ટનલ નિયમ સેવાને પણ મંજૂરી આપે છે તે એક ડિઝાઇન પસંદગી છે જેને તમારે નામ આપવું જોઈએ, અકસ્માત નહીં.
ક્લાયન્ટ શ્રેણી અને સેવાનો વ્યાપ સાંકડો રાખો. ટનલ સબનેટથી આખા LAN સુધીની મંજૂરી દરેક હોસ્ટ પર ભરોસો કરવાનો નિર્ણય છે, એક એપ્લિકેશન માટેનો શોર્ટકટ નહીં.
બંને નિયમો અલગથી લખો. ટનલ નિયમ અને સેવા નિયમ અલગ રીતે નિષ્ફળ જાય છે અને અલગ પુરાવાઓ સાથે ડિબગ થાય છે. જ્યારે એક નિષ્ફળ જાય, ત્યારે તમે જાણો છો કે પહેલા કયો સ્તર તપાસવો.
બીજો નિર્ણય: દરેક સીમા પર સ્થિતિ સાથે કે સ્થિતિ વિના
સ્થાપિત-પ્રવાહ નિયમ મંજૂર કરાયેલા વિનિમય માટે જવાબોને પ્રવેશ આપી શકે છે, પરંતુ તેનું વર્તન ઉત્પાદન પર આધાર રાખે છે. ક્લાઉડ સુરક્ષા જૂથ સામાન્ય રીતે સ્થિતિ રાખે છે; સબનેટ ACL ઘણી વાર સ્થિતિ રાખતું નથી અને બંને દિશામાં સ્પષ્ટ હેન્ડલિંગની જરૂર પડે છે. એવું ન માનો કે માર્ગની દરેક સીમા સ્થિતિને એક જ રીતે જુએ છે. નિયમો ડિઝાઇન કરતા પહેલાં દરેક સીમાની યાદી બનાવો અને તેને સ્થિતિ સાથે કે વિના ચિહ્નિત કરો.
જો નિયમ બદલાય, તો હાલના ટ્રેક કરેલા પ્રવાહો કામ ચાલુ રાખી શકે છે જ્યારે નવા નિષ્ફળ જાય, અથવા ઊલટું. તે તફાવત ઉપયોગી સંકેત છે, જીવંત ગેટવે પર બધી કનેક્શન સ્થિતિ ખાલી કરવાનું કારણ નહીં.
નવી નિયંત્રિત વિનંતી સાથે પરીક્ષણ કરો અને સંબંધિત કાઉન્ટર્સ તપાસો. સ્વચ્છ પરીક્ષણ વિક્ષેપક રીસેટ કરતાં સારું છે. ફેરફારના રેકોર્ડમાં કાઉન્ટરનું નામ નોંધો જેથી આગલું પરીક્ષણ એ જ પુરાવો વાપરે.
એ જ નીતિ હેઠળ પરત માર્ગ ચકાસો
ક્લાયન્ટથી સેવા સુધી નવી વિનંતી મોકલો, પછી દરેક સીમા પર ફોરવર્ડ અને પરત કાઉન્ટર્સ તપાસો. ખાતરી કરો કે જવાબ તમે અપેક્ષા રાખો તે માર્ગ વાપરે છે, ખાસ કરીને જો અનુવાદ સંકળાયેલો હોય.
ઇચ્છિત ક્લાયન્ટ શ્રેણી અને સેવાનો વ્યાપ સાંકડો રાખો, અને જે નિયમસેટે વિનંતીને મંજૂરી આપી તે જ હેઠળ પરત માર્ગ ચકાસો. જે નિયમ ફક્ત એટલા માટે કામ કરે કે જૂનો પ્રવાહ હજી ખુલ્લો છે તે કામ કરતો નિયમ નથી.