Սահմանափակել OpenVPN դարպասը մեկ LAN-ով UFW կանոններով

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

Նախ գրի առեք տոպոլոգիան և թույլտվությունը

Օրինակն օգտագործում է Community OpenVPN սերվեր՝ օգտատիրոջ տարածության TUN սարքով, որը կոչվում է tun0, հաճախորդների լողավազանով՝ 10.77.0.0/24, և մեկ միացված ենթացանցով՝ 192.168.60.0/24 lan0 ի վրա։ IPv4 փոխանցումն արդեն աշխատում է, և LAN-ն արդեն ունի վերադարձի երթուղի դեպի լողավազան, ուստի այստեղ ոչինչ կախված չէ նրանց միջև թարգմանությունից։

Այս հոսթի հրահրիչ պատը պատկանում է UFW-ին, և ոչ մի կոնտեյների կանոնակարգ կամ առանձին nftables աղյուսակ չի կարող ավելի վաղ ընդունման ուղի տեղադրել։ Զտիչը շրջանցող հոսքի թեթևացման կարճուղին պաշտպանական շղթաները կդարձնի զուտ դեկորատիվ, ուստի հաստատեք, որ ոչ մեկն ակտիվ չէ։ Թողեք OpenVPN-ի սեփական client-to-client փոխանցումն անջատված, որովհետև հավասարը հավասարին երթևեկությունը, որը երբեք չի հատում օպերացիոն համակարգի զտիչը հնարավոր չէ սահմանափակել դրանով։ Արտաքին լսողը և կառավարման կանոնները մնում են ինչպես կան, քանի որ այս փոփոխությունը կարգավորում է ապակոդավորված թունելային երթևեկությունը՝ փոխարենը չփոխարինելով հրահրիչ պատը։

Տեղադրեք պահակներին UFW-ի վաղ ընդունումներից առաջ

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

*filter բաժնում /etc/ufw/before.rules ֆայլում հայտարարեք երկու շղթա գոյություն ունեցող հայտարարությունների կողքին և ցանկացած կանոնի տողից առաջ։

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Հայտարարություններից անմիջապես հետո, և մուտքի ու փոխանցման թույլտվություններից առաջ, ցատկեք նրանց մեջ և սահմանեք, թե ինչ են նրանք թույլ տալիս։

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

Կարդացեք, թե ինչ է թույլ տալիս և մերժում յուրաքանչյուր պահակ

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

Հավասարը հավասարին փաթեթը մտնում և դուրս է գալիս tun0-ից, ուստի այն ձախողվում է LAN ինտերֆեյսի թեստում նույնիսկ նպատակակետի ստուգմանը հասնելուց առաջ։ LAN-ից դեպի հաճախորդներ նոր կապերը նույնպես ձախողվում են պատասխանի ուղղության թեստում, ինչը լռելյայն փակում է հակադարձ հետկանչի ուղին։

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

Լիազորեք ենթացանցը և փակեք կողային դռները

Նախ նախադիտեք երթուղու թույլտվությունը, ապա հանեք նախադիտման դրոշակը՝ այն կիրառելու համար. sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24։ Դրանից հետո վերանայեք օգտատիրոջ կանոնների հերթականությունը, քանի որ ավելի վաղ մերժումը դեռ հաղթում է ուշ թույլտվությանը։ Ամբողջ ենթացանցի թույլտվությունը նույնպես սխալ ձև է, երբ պետք է հասանելի լինի միայն մեկ հոսթի HTTPS նավահանգիստը։

Ուշադրություն դարձրեք, թե ինչ է անում մուտքի դեն նետումը. թունելի հաճախորդները չեն կարող հասնել դարպասի վրա գտնվող ոչ մի ծառայության, ներառյալ նրա LAN հասցեին կապված DNS լսողը։ Այնտեղ DNS հոսթինգը պահանջում է դիտավորյալ բացառություն դեն նետելուց առաջ և վերանայված թույլտվության պայմանագիր։ Եթե UFW-ն կառավարում է IPv6, ավելացրեք համապատասխան դեն նետումներ tun0-ի համար before6.rules ֆայլում նույնպես, որովհետև IPv4 նպատակակետերի ցանկը ոչինչ չի ասում IPv6 փաթեթների մասին։

Ստուգեք բեռնված քաղաքականությունը, ոչ թե նախադիտումը

Նախադիտեք վերաբեռնումը, կիրառեք այն սպասարկման պատուհանում և կարդացեք կենդանի կանոնների հավաքածուն։

sudo ufw --dry-run reload
sudo ufw show raw

Հաստատեք, որ թունելի պահակները հայտնվում են լռելյայն վիճակի և ICMP թույլտվություններից առաջ։ Սովորական ufw status չի ցուցադրում ձեռքով խմբագրված before կանոնները, դրա համար օպերատորները եզրակացնում են, որ կանոնը բացակայում է, մինչդեռ այն իրականում բեռնված է։ Կարդացեք հում ցանկը վերևից ներքև՝ փոխարենը չփնտրելով հատված։ Եթե պահակները հայտնվում են վիճակի թույլտվությունից հետո, սահմանը չի անում այն, ինչ ֆայլը հուշում է։

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

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