VPN հաճախորդները և LAN-ը. երբ օգտագործել առանձին գոտի

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

Գոտու անունը ոչինչ չի գաղտնագրում և չի նույնականացնում օգտատիրոջը։ Այն միայն խմբավորում է ինտերֆեյսները ֆայրվոլի քաղաքականության մոդելի համար։

Ինչ է իրականում կառավարում գոտի անդամակցությունը

Գոտին խմբավորում է ինտերֆեյսները կամ երթևեկությունը ֆայրվոլի մոդելում։ Դրա մուտքի, ելքի և փոխանցման կարգավորումները հետո կառավարում են տարբեր դերեր։ Մուտքը երթևեկությունն է դեպի հենց երթուղիչը, իսկ փոխանցումը՝ դրա միջով դեպի այլ հոսթ գնացող երթևեկությունը։ OpenWrt-ի գոտիների փաստաթղթերը մուտքը, ելքը և փոխանցումը դիտարկում են որպես առանձին կարգավորումներ հենց այդ պատճառով։

VPN գոտուց LAN գոտի տրված թույլտվությունը ինքնաբերաբար հակառակ թույլտվություն չէ։ Փոխանցման կանոններն ուղղորդված են, և հաճախորդից սերվեր երթևեկությունը թույլ տվող կանոնը չի թույլ տալիս սերվերից հաճախորդ սեսիաներ։ Հաճախորդը, որը կարող է կապ բացել դեպի սերվեր, այն հաճախորդը չէ, որին սերվերը կարող է հետադարձ կապ բացել։

Այդ տարբերությունն է առանձին գոտու օգտակարության պատճառը՝ կարող եք հստակ նշել յուրաքանչյուր ուղղություն և յուրաքանչյուր դեր։ Յուրաքանչյուր կանոնի կողքին գրեք ուղղությունը։

Առաջին որոշումը՝ մուտք, փոխանցում, թե երկուսը

Եթե հեռավոր հաճախորդներին DNS է պետք երթուղիչից, թույլատրեք մուտքը միայն այդ ծառայության համար։ Եթե նրանք պետք է հասնեն ֆայլային սերվերին, թույլատրեք փոխանցումը դեպի այդ նպատակակետը։ VPN-ի նախագծերի մեծ մասին երկուսն էլ պետք են, բայց տարբեր ծառայությունների համար։

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

Երկրորդ որոշումը՝ ինչ ռեսուրսներ են պետք հեռավոր հաճախորդներին

Կանոններ գրելուց առաջ թվարկեք հաճախորդների միջակայքերը, նպատակակետերը և այն ծառայությունները, որոնք VPN-ը պետք է տրամադրի։ Նպատակակետերի ցանկն ավելի օգտակար է, քան վստահության պիտակը, որովհետև այն վերապրում է ֆայրվոլի միգրացիան։

Կառավարման ինտերֆեյսները պահեք առանձին սովորական հավելվածային հասանելիությունից։ Վիքի հասնող հեռավոր հաճախորդը դրանով պարտավոր չէ ունենալ երթուղիչի ադմինիստրատորի էջը կամ հիպերվիզորի կոնսոլը։

Եթե թույլատրված նպատակակետը կարող է առաջ փոխանցել, գոտու սահմանը կանգ է առնում ֆայրվոլի մոտ, ոչ թե նրանում, ինչ նպատակակետն անում է հետո։

Երրորդ որոշումը՝ ինչպես կապացուցեք սահմանը

Յուրաքանչյուր փոփոխությունից հետո փորձարկեք թույլատրված հոսք և դիտավորյալ մերժված հոսք։ Ապացուցելը, որ մեկ կայք բեռնվում է, չի բացահայտում ակամա լայն թույլտվություն։ Փորձարկեք VPN հաճախորդի հասցեների միջակայքից, ոչ թե LAN-ից, և ներառեք այն ուղղությունը, որտեղ ձախողում եք ակնկալում։ Երկու արդյունքներն էլ գրանցեք կանոնի կողքին։

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

Երբ ցանցը մեծանում է, փաստագրեք անդամակցությունը և կանոնների նպատակը։ Նոր միացված ինտերֆեյսը չպետք է ժառանգի արտոնություններ միայն այն պատճառով, որ ինչ-որ մեկը նրան հարմար գոտու անուն է տվել։