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

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

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

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

  1. દૂરસ્થ ક્લાયન્ટ: વપરાશકર્તાનું ઉપકરણ જે ટનલ બનાવે છે.
  2. એજ નીતિ: નિયમસમૂહ જે બાહ્ય ટ્રાન્સપોર્ટને જાહેર લિસનરમાં સ્વીકારે છે.
  3. સમાપ્ત કરતું ઉપકરણ: VPN એન્ડપોઇન્ટ જે ડિકેપ્સ્યુલેટ કરે છે અને પેકેટ સામાન્ય IPને સોંપે છે.
  4. આંતરિક ફિલ્ટર: ફોરવર્ડિંગ અથવા સિક્યુરિટી-ગ્રુપ નિયમસમૂહ જે ક્લાયન્ટથી સેવા સુધીની ટ્રાફિક મર્યાદિત કરે છે.
  5. એપ્લિકેશન હોસ્ટ: સેવા જે ડિક્રિપ્ટ થયેલી વિનંતી મેળવે છે.

બે નીતિઓ, બે માલિકો

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

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

સ્થાન નક્કી કરે છે કે વિનંતી કઈ સીમા પસાર કરે છે

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

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

ત્રીજું સ્થાન એ છે જે ચુપચાપ અમલ દૂર કરે છે, કારણ કે સુરક્ષિત સેગમેન્ટ પરનો પગ ઉપકરણને સીધો માર્ગ આપે છે જે ડાયાગ્રામ કદાચ ન બતાવે. ચિત્રને બદલે ઇન્ટરફેસ અને રૂટ તપાસો: ip route get 10.20.5.10 જણાવે છે કે પેકેટ કયા ઇન્ટરફેસ દ્વારા નીકળશે, અને જવાબ ઘણી વાર એ નથી જે રચનાએ ધાર્યો હતો. પોસ્ચરો વચ્ચેની ટ્રાફિક નિયંત્રિત કરવાની ફાયરવોલની પરંપરાગત ભૂમિકા, જેમ કે વર્ણવેલ છેNIST SP 800-41માં, અહીં ઉપયોગી કસોટી છે, કારણ કે સુરક્ષિત નેટવર્ક સુધી અમર્યાદિત પગ ધરાવતું ઉપકરણ વધારે કંઈ નિયંત્રિત કરતું નથી. રૂટ શોધ એ પ્રેઝન્ટેશનના ડાયાગ્રામ કરતાં વધુ પ્રામાણિક ડાયાગ્રામ છે.

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

અનુવાદ બદલે છે કે નીચેના નિયમો શું જોઈ શકે

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

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

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

એક માન્ય અને એક નકારાયેલી કામગીરી સ્વીકારો

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

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

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

સંબંધિત લેખો