VPN દ્વારા જોડાયેલી બે ઓફિસ વચ્ચેની ઍક્સેસ કેવી રીતે મર્યાદિત કરવી

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

આ ક્રમમાં કામ કરો, અને નીચેના નીતિ પગલાં પસાર ન થાય ત્યાં સુધી ટનલ માર્ગ પહોળો ન કરો।

ગેટવેને સ્પર્શ કરતા પહેલા મેટ્રિક્સ લખો

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

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

જ્યાં પેકેટ ડિક્રિપ્ટ થાય છે ત્યાં લાગુ કરો

IKE અને ESP ને મંજૂરી આપતા નિયમો ફક્ત બાહ્ય ટનલ બનાવે છે। આંતરિક ટ્રાફિક ટનલ ઇન્ટરફેસ પર ખુલ્લો આવે છે, અને ત્યાં જ પરવાનગી સૂચિનું સ્થાન છે: ડિક્રિપ્ટ કરતા ઉપકરણ પર ફોરવર્ડ ચેઇન, ડિફોલ્ટ ડ્રોપ, મેટ્રિક્સની દરેક પંક્તિ માટે એક નિયમ। Linux ગેટવે પર તેનો અર્થ છે ફોરવર્ડિંગ સક્ષમ અને ફિલ્ટર નિયમો ટનલ ઉપકરણ પર, ભૌતિક અપલિંક પર નહીં, જેમ strongSwan ફોરવર્ડિંગ માર્ગદર્શિકા સમજાવે છે।

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT અને ઓવરલેપિંગ સબનેટ નિયમો બદલે છે

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

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

ઇનકાર સાબિત કરો, ફક્ત સફળતા નહીં

ફક્ત મંજૂર એપ્લિકેશનનું પરીક્ષણ ઘણું ઓછું સાબિત કરે છે, કારણ કે ઉપર ક્યાંક એક છૂટછાટ આપતો નિયમ એ જ પરિણામ આપે છે।

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

સૂચિને જીવંત રાખો

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

ટનલ પાછળ પણ હોસ્ટ-સ્તરીય પ્રતિબંધો મહત્ત્વના છે: સર્વરની પોતાની ફાયરવોલ શાખાની શ્રેણીને ફક્ત તે જ સેવા માટે સ્વીકારવી જોઈએ જે તે પ્રકાશિત કરે છે। જે બે સ્તર સહમત થાય છે તે સંપૂર્ણ વિશ્વાસ કરાયેલા એક સ્તર કરતાં ઓડિટ કરવા સરળ છે।