ડિક્રિપ્શન પછી: કઈ નીતિ તમારા VPN ટ્રાફિકને પહેલા જુએ છે

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

પોર્ટ પ્રમાણે નહીં, નીતિના હૂક પ્રમાણે નિર્ણય લો

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

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

બે માર્ગ, બે અલગ અમલીકરણની વાર્તાઓ

બે આકાર સામાન્ય છે, અને દરેક અલગ જરૂરિયાત માટે યોગ્ય હોઈ શકે છે.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

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

ચિત્રની જગ્યાએ રૂટ લુકઅપથી ચકાસો. પેકેટ જે ઇન્ટરફેસથી નીકળે છે અને જે આગળનું હોપ પસંદ કરે છે તે નક્કી કરે છે કે બીજો આકાર ડિઝાઇન મુજબ વર્તે છે કે નહીં.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

ટોપોલોજીને અલગતાથી અલગ રાખો

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

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

દરેક સ્થાન માટે નિષ્ફળતા અને વ્યવસ્થાપન તપાસો

દરેક સ્થાનની નિષ્ફળતાની રીત છે, અને ઉપયોગી પ્રશ્ન એ છે કે ઘટક અટકે ત્યારે શું હજી કામ કરે છે. એક મૃત ઉપકરણ પર ઘણા લોજિકલ ઇન્ટરફેસ સ્વતંત્ર પુનઃપ્રાપ્તિ આપતા નથી, અને સમાન પાવર સપ્લાય કે સમાન વ્યવસ્થાપક શેર કરતો નીચેનો ફાયરવોલ બીજી સીમા નથી. પૂછો કે વ્યવસ્થાપન માર્ગ ક્યાં થઈને જાય છે, કારણ કે ફક્ત ટનલ દ્વારા પહોંચતું કન્સોલ કોઈ પુનઃપ્રાપ્તિ માર્ગ નથી; ssh [email protected] true ટનલની બહારથી ચલાવવું એ સાબિત કરવાનો સૌથી સસ્તો રસ્તો છે કે કન્સોલ તેના પર આધારિત નથી. એક પ્લેટફોર્મના જૂથ નીતિ દસ્તાવેજ તેનું ફિલ્ટર ડિક્રિપ્શન પછીના અને એન્ક્રિપ્શન પહેલાના ટ્રાફિક પર મૂકે છે, જે કોઈ પણ ઉત્પાદનમાં શોધવા જેવો નામવાળો હૂક છે.

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

મંજૂર અને નકારેલા ફ્લો સાથે સ્વીકારો

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

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