VPN થી VLAN એક્સેસ: નિયમો પહેલાં મેટ્રિક્સ બનાવો
એક બાજુ ભૂમિકાઓ, બીજી બાજુ સેવાઓ. પાંચ ચકાસણીઓ અસ્પષ્ટ VPN થી VLAN ડિઝાઇનને એવા કોષ્ટકમાં ફેરવે છે જે ફાયરવોલ માલિક અમલમાં મૂકી શકે.
ફાયરવોલ સિન્ટેક્સથી નહીં, મેટ્રિક્સથી શરૂ કરો. જે કોષ્ટકમાં એક બાજુ ભૂમિકાઓ અને બીજી બાજુ સેવાઓ હોય તેને એપ્લિકેશન માલિક સમીક્ષા કરી શકે, સુરક્ષા માલિક ચર્ચા કરી શકે અને ગેટવે જેની પાસે છે તે અમલમાં મૂકી શકે. કોઈએ સહમત ન કરેલા નિયમો ડિબગ કરવા કરતાં તે સમીક્ષા સસ્તી છે.
એક કલાકનું લેખન પછી એક અઠવાડિયાની નિયમ-પુરાતત્વવિદ્યા બચાવે છે. ડિઝાઇન કહે છે કે કોણ કઈ સેવા સુધી પહોંચે છે, અને પુનઃક્રમાંકન પછી ટકી રહેતો ભાગ એ જ છે.
પગલું 1: નેટવર્ક પહેલાં ભૂમિકાઓના નામ આપો
સ્વિચથી નહીં, લોકોથી શરૂ કરો. દૂરથી જોડાતા દરેક જૂથને અને તે જૂથ શું કરે તે વર્ણવતું એક જ વાક્ય લખો, જેમ કે સ્ટોક સ્તર વાંચતા વેરહાઉસ કર્મચારીઓ અથવા એક એકીકરણ જાળવતો કોન્ટ્રાક્ટર. જો બે જૂથોને સમાન એક્સેસ મળે, તો આ હેતુ માટે તે એક ભૂમિકા છે.
જો ભૂમિકા ફક્ત સંસ્થા-ચાર્ટને કારણે હોય તો અહીં થોભો. જેની પાસે અલગ સેવા જરૂરિયાત નથી એવી ભૂમિકા સમાન કોષોની પંક્તિ બની જાય છે, અને સમાન પંક્તિઓ પછી અનુકૂળતા માટે આખું સબનેટ આપવાનું લલચાવે છે. લોકો શું કરે તેના આધારે વિભાજન કરો, તેમના ખર્ચ પર કોણ સહી કરે તેના આધારે નહીં. નાની ઓફિસ માટે છ ભૂમિકાઓ સામાન્ય રીતે વધારે છે અને ત્રણ ઘણી વાર યોગ્ય હોય છે.
પગલું 2: દરેક કોષને સેવા-નિવેદનમાં ફેરવો
જે કોષમાં «એપ્લિકેશન્સ» લખ્યું છે તે ચકાસી શકાય તેવું નથી. જે કોષમાં «સ્ટાફ પૂલમાંથી 443 પર ERP હોસ્ટને HTTPS» લખ્યું છે તે ચકાસી શકાય છે. દરેક નેટવર્ક નામને ગંતવ્ય, પ્રોટોકોલ અને પોર્ટથી બદલો, પછી જે નિર્ભરતા વિના સેવા ચાલી શકતી નથી તે ઉમેરો, જેમ કે આંતરિક રિઝોલ્વર અથવા ઓળખ પ્રદાતા.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
દિશા કૉલમ સૌથી ખર્ચાળ ભૂલો પકડે છે. કર્મચારીઓને એપ્લિકેશન ખોલવાની પરવાનગીનો અર્થ એપ્લિકેશન સર્વરોને કર્મચારીઓના લેપટોપ તરફ પાછા કનેક્શન ખોલવાની પરવાનગી નથી, અને પ્રથમ દિશાને મંજૂરી આપતો સ્થિતિપૂર્ણ નિયમ ઘણી વાર બીજી દિશાની મંજૂરી તરીકે વંચાય છે.
પગલું 3: ઓળખ ક્યાં નીતિ બને છે તે નક્કી કરો
કોઈએ પ્રમાણિત સત્રને ગેટવે લાગુ કરી શકે તેવી ભૂમિકામાં ફેરવવું પડે. સમર્થિત વિકલ્પોમાં ઓથેન્ટિકેશન બેકએન્ડ દ્વારા અપાયેલ જૂથ નીતિ, વિશ્વસનીય સત્ર લક્ષણો, અથવા દરેક ભૂમિકા માટે અલગ સરનામાં પૂલનો સમાવેશ થાય છે. ત્રણેય કામ કરે છે; ક્લાયન્ટ મોકલે તે લેબલ કામ કરતું નથી. તમારો ગેટવે જે પદ્ધતિનું દસ્તાવેજીકરણ કરે છે તે પસંદ કરો, ફોરમ પોસ્ટ વર્ણવે છે તે નહીં.
ફક્ત VLANનું લાગે તેવું સરનામું આપવું એ બીજા પોશાકમાં એ જ જવાબ-ન હોવું છે. OpenVPN ફાયરવોલ નિયમો પરની Netgate માર્ગદર્શિકા આ અલગતા સ્પષ્ટ કરે છે: ટનલને ઉપર આવવા દેવું એ તેમાંથી ટ્રાફિક પસાર થવા દેવાથી અલગ નિર્ણય છે.
તમે કઈ પદ્ધતિ પસંદ કરી અને તે ક્યાં રૂપરેખાંકિત છે તે લખો. જ્યારે ભૂમિકા બદલાય, ત્યારે તે નોંધ એક ફેરફાર અને ત્રણ ઇન્ટરફેસમાં શોધ વચ્ચેનો ફરક છે. તે ઓડિટરને પણ કહે છે કે પહેલાં ક્યાં જોવું.
પગલું 4: ગંતવ્ય જે સ્રોત સરનામું જુએ તેનું ધ્યાન રાખો
સીમા પર ફોરવર્ડિંગ નીતિ વાસ્તવિક સ્રોત સાથે મેળ ખાવી જોઈએ. જો ગેટવે VPN ક્લાયન્ટ્સને પોતાના સરનામામાં અનુવાદિત કરે છે, તો નીચેનો દરેક ફાયરવોલ એક જ સ્રોત જુએ છે અને ભૂમિકા પ્રમાણે નિર્ણય લેવાની ક્ષમતા ગુમાવે છે. જો તે ક્લાયન્ટનું સરનામું જાળવે છે, તો તે પૂલ માટે પરત માર્ગ હોવો જોઈએ.
અંતિમ નિયમો લખતાં પહેલાં બંને દિશાઓની ચકાસણી કરો, પછી દરેક કોષની બાજુમાં અવલોકિત સ્રોત નોંધો. એ જ ચકાસણી બે અલગ ભૂમિકાઓથી ચલાવો અને પરિણામ સરખાવો. જો બંને ગેટવેનું સરનામું બતાવે, તો ભૂમિકાનો ભેદ પહેલેથી ગુમાવાઈ ગયો છે. જે મેટ્રિક્સ જાળવેલાં સરનામાં ધારે છે જ્યારે ગેટવે સ્રોત અનુવાદ કરે છે, તે પહેલા નીચેના ACL પર નિષ્ફળ જાય છે.
પગલું 5: રિલીઝ પહેલાં દરેક કોષની ચકાસણી કરો
દરેક મંજૂર કોષને એક પ્રતિનિધિ ક્રિયામાં અને દરેક નકારેલ કોષને નકારાત્મક કિસ્સામાં ફેરવો. બંનેને વાસ્તવિક ભૂમિકાના ક્લાયન્ટથી ચલાવો, ગેટવે કન્સોલથી નહીં, કારણ કે કન્સોલ તમે ચકાસી રહ્યા છો તે માર્ગને ટાળે છે.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'જોડાય તેવો નકારાત્મક કિસ્સો એ શોધ છે, સંયોગ નહીં, અને નિયમ સુધરે ત્યાં સુધી તે મેટ્રિક્સમાં નિષ્ફળ કોષ તરીકે રહેવો જોઈએ. પરીક્ષણ આદેશો કોષ્ટકની બાજુમાં રાખો જેથી આગામી સમીક્ષક તર્ક ફરી બનાવવાને બદલે તેમને ફરી ચલાવે.
પૂર્ણ થયેલું કોષ્ટક જે ગેટવે માટે લખાયું તેના કરતાં વધુ ટકે છે. નિયમો ફર્મવેર અને વેન્ડર સાથે બદલાય છે, જ્યારે કોન્ટ્રાક્ટર એક પ્રોજેક્ટ સેવા સુધી પહોંચે છે એમ કહેતી પંક્તિ તે કામ બદલાય ત્યાં સુધી સાચી રહે છે.