VPN-ից VLAN մուտք. սկզբում կառուցեք մատրիցը, հետո՝ կանոնները
Դերերը մի կողմում, ծառայությունները՝ մյուսում։ Հինգ ստուգում վերածում են VPN-ից VLAN մուտքի անորոշ նախագիծը աղյուսակի, որը firewall-ի պատասխանատուն կարող է ներդնել։
Սկսեք մատրիցից, ոչ թե firewall-ի շարահյուսությունից։ Աղյուսակը, որտեղ դերերը մի կողմում են, իսկ ծառայությունները՝ մյուսում, կարող է վերանայել հավելվածի պատասխանատուն, քննարկել անվտանգության պատասխանատուն և ներդնել նա, ով տնօրինում է gateway-ը։ Այդ վերանայումն ավելի էժան է, քան կանոնների վրիպազերծումը, որոնց շուրջ ոչ ոք չի համաձայնվել։
Մեկ ժամ գրելը խնայում է մեկ շաբաթ կանոնների հնագիտություն ավելի ուշ։ Նախագիծը խոսում է այն մասին, թե ով որ ծառայությունն է հասնում, և դա է այն մասը, որը վերապրում է վերահամարակալումը։
Քայլ 1. անվանեք դերերը ցանցերից առաջ
Սկսեք մարդկանցից, ոչ թե կոմուտատորից։ Գրեք յուրաքանչյուր խմբին, որը հեռակա միանում է, և այն մեկ նախադասությունը, որը նկարագրում է, թե ինչ է անում այդ խումբը, օրինակ՝ պահեստի աշխատակիցներ, որոնք կարդում են պաշարների մակարդակը, կամ կապալառու, որը պահպանում է մեկ ինտեգրացիա։ Եթե երկու խումբ ստանային նույն մուտքը, այս նպատակով նրանք մեկ դեր են։
Կանգ առեք այստեղ, եթե դերը գոյություն ունի միայն կազմակերպչական սխեմայի պատճառով։ Առանձին ծառայության կարիք չունեցող դերը դառնում է նույնական բջիջների շարք, և նույնական շարքերը գայթակղում են ինչ-որ մեկին ավելի ուշ հարմարության համար տրամադրել ամբողջ ենթացանց։ Բաժանեք ըստ այն բանի, ինչ մարդիկ են անում, ոչ թե ըստ նրա, թե ով է ստորագրում նրանց ծախսերը։ Վեց դերերը սովորաբար չափազանց շատ են փոքր գրասենյակի համար, իսկ երեքը հաճախ ճիշտ է։
Քայլ 2. յուրաքանչյուր բջիջ դարձրեք ծառայության հայտարարություն
«Հավելվածներ» գրող բջիջը ստուգելի չէ։ «HTTPS դեպի ERP հոսթ 443 պորտով, աշխատակազմի pool-ից» գրող բջիջը ստուգելի է։ Փոխարինեք յուրաքանչյուր ցանցի անուն նպատակակետով, արձանագրությամբ և պորտով, ապա ավելացրեք այն կախվածությունը, առանց որի ծառայությունը չի աշխատում, օրինակ՝ ներքին լուծիչը կամ ինքնության մատակարարը։
| 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. որոշեք, թե որտեղ ինքնությունը դառնում է քաղաքականություն
Ինչ-որ մեկը պետք է նույնականացված սեսիան վերածի դերի, որը gateway-ը կարող է պարտադրել։ Աջակցվող տարբերակները ներառում են նույնականացման backend-ի տրամադրած խմբային քաղաքականությունը, վստահելի սեսիայի հատկանիշները կամ յուրաքանչյուր դերի համար առանձին հասցեների pool-եր։ Երեքն էլ աշխատում են. հաճախորդի ուղարկած պիտակը՝ ոչ։ Ընտրեք այն մեխանիզմը, որը փաստաթղթավորում է ձեր gateway-ը, ոչ թե այն, ինչը նկարագրում է ֆորումի գրառումը։
Հասցե տրամադրելը, որը միայն թվում է, թե պատկանում է VLAN-ին, նույն չպատասխանն է այլ զգեստով։ Netgate-ի ուղեցույցը OpenVPN-ի firewall-ի կանոնների մասին պարզ է դարձնում տարանջատումը. թույլ տալ, որ թունելը բարձրանա, այլ որոշում է, քան թույլ տալ, որ երթևեկությունն անցնի դրա միջով։
Գրեք, թե որ մեխանիզմն եք ընտրել և որտեղ է այն կարգավորված։ Երբ դերը փոխվում է, այդ նշումը տարբերությունն է մեկ խմբագրության և երեք ինտերֆեյսով որոնման միջև։ Այն նաև ասում է աուդիտորին, թե որտեղ նայել առաջինը։
Քայլ 4. ուշադրություն դարձրեք աղբյուրի հասցեին, որը տեսնում է նպատակակետը
Փոխանցման քաղաքականությունը պետք է համապատասխանի սահմանին իրական աղբյուրին։ Եթե gateway-ը VPN հաճախորդներին թարգմանում է իր իսկ հասցեին, ապա ներքևի յուրաքանչյուր firewall տեսնում է մեկ աղբյուր և կորցնում է ըստ դերի որոշումներ կայացնելու ունակությունը։ Եթե այն պահպանում է հաճախորդի հասցեն, ապա այդ pool-ի համար վերադարձի ուղին պետք է գոյություն ունենա։
Ստուգեք երկու ուղղությունները նախքան վերջնական կանոնները գրելը, ապա գրանցեք դիտարկված աղբյուրը յուրաքանչյուր բջջի կողքին։ Գործարկեք նույն ստուգումը երկու տարբեր դերերից և համեմատեք արդյունքը։ Եթե երկուսն էլ ցույց են տալիս gateway-ի հասցեն, դերերի տարբերակումն արդեն կորել է։ Մատրիցը, որը ենթադրում է պահպանված հասցեներ, մինչ gateway-ը կատարում է աղբյուրի թարգմանություն, ձախողվում է առաջին ներքևի ACL-ում։
Քայլ 5. ստուգեք յուրաքանչյուր բջիջ նախքան թողարկելը
Յուրաքանչյուր թույլատրված բջիջ դարձրեք մեկ ներկայացուցչական գործողություն, իսկ յուրաքանչյուր մերժված բջիջ՝ բացասական դեպք։ Գործարկեք երկուսն էլ իրական դերում գտնվող հաճախորդից, ոչ թե gateway-ի կոնսոլից, որովհետև կոնսոլը շրջանցում է ձեր ստուգվող ուղին։
# 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'Միացող բացասական դեպքը հայտնաբերում է, ոչ պատահականություն, և նրա տեղը մատրիցում ձախողված բջիջն է, քանի դեռ կանոնը չի ուղղվել։ Պահեք փորձարկման հրահանգները աղյուսակի կողքին, որպեսզի հաջորդ գրաքննիչը դրանք նորից գործարկի՝ փոխարենը նորից կառուցելու պատճառաբանությունը։
Ավարտված աղյուսակը ապրում է ավելի երկար, քան այն gateway-ը, որի համար գրվել է։ Կանոնները փոխվում են firmware-ի և մատակարարի հետ, մինչդեռ այն տողը, որն ասում է, թե կապալառուն հասնում է մեկ նախագծային ծառայության, ճշմարիտ է մնում մինչև այդ աշխատանքը չփոխվի։