Ինչպես սահմանափակել մուտքը VPN-ով միացված երկու գրասենյակների միջև

Կայք-կայք թունելը պատասխանում է մեկ հարցի՝ կարող են արդյոք երկու գրասենյակները փոխանակել փաթեթներ, և բաց է թողնում կարևորը՝ որ մասնաճյուղի սարքը որ կենտրոնական ծառայությանը կարող է հասնել։ Թունելը որպես փոխադարձ վստահություն դիտելը այն ուղին է, որով հյուրի նոթբուքը հայտնվում է ֆինանսական սերվերի նույն երթուղու վրա։ Լուծումը ոչ թե ավելի լավ թունելն է, այլ վերծանումից հետո կիրառվող բացահայտ թույլտվությունների ցանկը։ Այս ուղեցույցը այդ ցանկը տանում է սահմանումից մինչև ապացուցված մերժում։

Աշխատեք այս հերթականությամբ և չընդարձակեք թունելի երթուղին, մինչև ներքևի քաղաքականության քայլերը չանցնեն։

Գրեք մատրիցան նախքան դարպասին դիպչելը

Օգտակար տողը նշում է երեք բան՝ աղբյուրի խումբ, նպատակակետ հոսթ կամ ծառայության ցանց, և այն արձանագրությունն ու պորտը, որն իրականում օգտագործում է հավելվածը։ Մասնաճյուղը և տվյալների կենտրոնը գրառումներ չեն։ Մասնավոր DNS-ը և նույնականացման ծառայությունները սեփական տողեր են վաստակում միայն այն ժամանակ, երբ հավելվածը չի կարող աշխատել առանց դրանց։

Խմբավորեք աղբյուրները ըստ դերի, այլ ոչ ըստ ենթացանցի հարմարության՝ աշխատակազմ, հյուրեր, վարչարարություն։ Երբ բոլոր երեքը կիսում են մեկ հարթ LAN, դարպասը չի կարող տարբերել նրանց ցանցային մակարդակում, ուստի ինքնության վերահսկումը կամ սեգմենտավորումը պետք է առաջինը գան։ Այնուհետև մատրիցան գրի առեք յուրաքանչյուր տողում սեփականատիրոջ և վերանայման ամսաթվի հետ։

Կիրառեք այնտեղ, որտեղ փաթեթները վերծանվում են

IKE-ին և ESP-ին թույլ տվող կանոնները կառուցում են միայն արտաքին թունելը։ Ներքին թրաֆիկը բացահայտ հասնում է թունելի ինտերֆեյս, և հենց այնտեղ է թույլտվությունների ցանկի տեղը՝ փոխանցման շղթա վերծանող սարքի վրա, լռելյայն անկում, մեկ կանոն մատրիցայի յուրաքանչյուր տողի համար։ Linux դարպասների վրա դա նշանակում է միացված փոխանցում և զտիչ կանոններ թունելի սարքի վրա, ոչ թե ֆիզիկական կապուղու, ինչպես բացատրում է strongSwan-ի փոխանցման ուղեցույցը։

Թրաֆիկի ընտրիչները երթուղավորման որոշում են, ոչ լիազորման որոշում։ Երկու ենթացանցերն էլ ընդգրկող լայն ընտրիչը կարող է ճիշտ լինել երթուղավորման համար, մինչ դարպասը դեռ թույլ է տալիս միայն TCP 443-ը մեկ հոսթի։ Ընտրիչը բանակցվում է թունելի համար և նկարագրում է, թե ինչ կարող է մտնել դրա մեջ, ոչ թե ինչ կարող է օգտագործել տվյալ սարքը։ Երբեք մի ընդարձակեք firewall-ի կանոնը, որովհետև ընտրիչը լայն է։

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, չեն կարող նկարագրվել մեկ քաղաքականության աղյուսակում առանց մի կողմի քարտեզագրման, և քարտեզագրումը չի փոխարինում չհատվող հասցեավորմանը։ Ուղղեք պլանը նախքան կանոններ գրելը, որոնք ստիպված կլինեք արձակել ավելի ուշ։

Ապացուցեք մերժում, ոչ միայն հաջողություն

Միայն թույլատրված հավելվածի փորձարկումը շատ քիչ բան է ապացուցում, որովհետև վերևում ինչ-որ տեղ թույլ տվող կանոնը տալիս է նույն արդյունքը։

Սովորական մասնաճյուղի սարքից հասեք նախատեսված ծառայությանը և հաստատեք, որ ամբողջ սեսիան աշխատում է։ Ապա փորձեք նպատակակետ, որը պետք է փակ մնա, օրինակ՝ վարչական պորտ այնպիսի սերվերի վրա, որի հետ մասնաճյուղը գործ չունի, և կարդացեք այն հաշվիչը կամ մատյանի գրառումը, որը մերժել է այն։ Կանոնների հավաքածուն անջատելը՝ ստուգելու համար, թե արդյոք այն աշխատում է, անվավեր է դարձնում թեստը և բաց է թողնում դարպասը, քանի դեռ նայում եք։

Թույլտվությունների ցանկը կենդանի պահեք

Հավելվածները տեղաշարժվում են, և իր հավելվածից ավելի երկար ապրող կանոնը դառնում է անցք, որը ոչ ոք չի տիրապետում։ Կցեք վերանայման ամսաթիվը տողին և փոխեք ընտրիչի ծավալը և firewall-ի կանոնը նույն սպասարկման քայլում, երբ ծառայությունը փոխում է հասցեն։

Հոսթի մակարդակի սահմանափակումները դեռ կարևոր են թունելի հետևում՝ սերվերի սեփական firewall-ը պետք է ընդունի մասնաճյուղի տիրույթը միայն այն ծառայության համար, որը հրապարակում է։ Երկու շերտ, որոնք համաձայն են, ավելի հեշտ են աուդիտի ենթարկվում, քան մեկ շերտը, որին լիովին վստահում են։