Կանխեք VPN հաճախորդների միմյանց հասնելը թունելում
Ծառայությանը հասնելը երթուղի է, մեկ այլ հաճախորդի հասնելը՝ քաղաքականություն։ Գտեք փոխանցման այն կետը, որը որոշում է գործընկերների երթևեկությունը, ապա ապացուցեք արգելքը հաճախորդից։
Երկու հաճախորդներ կարող են երկուսն էլ բացել ցատկման սերվերը և միևնույն է՝ գործ չունենալ բացելու միմյանց։ Ծառայությանը հասնելը փոխանցման որոշում է, մինչդեռ գործընկերոջը հասնելը քաղաքականության որոշում է, և VPN-ների մեծ մասը դրանք պահում է առանձին օբյեկտներում։ Առաջինի համար կարգավորված ոչինչ չի կիրառում երկրորդը։ Ուստի խնդիրը ոչ թե կանոն ավելացնելն է, այլ գտնել այն օբյեկտը, որն այս սերվերում որոշում է գործընկերների երթևեկությունը, այնտեղ գրել արգելքը և ապացուցել այն հաճախորդից։
Դեպի ընդհանուր ծառայություն երթուղին թույլտվություն չէ գործընկերների միջև
Հաճախորդների ենթացանցի հայտարարումը գործընկերոջն ասում է, թե ինչպես փաթեթը դնել լարի վրա դեպի մեկ այլ հաճախորդի հասցեն։ Թե այդ փաթեթը կհասցվի, որոշվում է ավելի ուշ՝ նրանով, ինչը փոխանցում է այն։ Linux դարպասում դա FORWARD շղթան է, օգտատիրոջ տարածության դեմոնում՝ թունելի սեփական նստաշրջանների աղյուսակը։ Երթուղին պատասխանում է հասանելիությանը և թույլտվությունը թողնում է անձեռնմխելի։
Այդ պատճառով միայն երթուղիներ կարդացող մեկուսացման ստուգումը ոչինչ չի ապացուցում։ /24-ը կարելի է ուղարկել յուրաքանչյուր հաճախորդի, մինչդեռ գործընկերների միջև յուրաքանչյուր փաթեթ նետվում է փոխանցման կեռիկի մոտ։ Վտանգավոր դեպքը հակառակն է՝ ոչ մի հստակ կանոն, թույլատրող լռելյայն և մեկուսացում, որ գոյություն ունի միայն այն պատճառով, որ ոչ ոք չի փորձարկել այն։
Պահանջը գրեք մեկ տողով՝ նախքան տերմինալ բացելը։ Հասեք ծառայության բլոկին և ցատկման սերվերին, հաճախորդների բլոկի ներսում ոչ այլ բանի չհասնեք։
Պարզեք, թե ով է իրականում փոխանցում գործընկերոջ փաթեթը
Սերվերի երկու վարքագիծ հաճախորդի կողմից նույնն են թվում և տարբեր կանոններ են պահանջում։ Կամ միջուկը փաթեթը կրկին փոխանցում է թունելի ինտերֆեյսից դուրս, կամ դեմոնը այն պատճենում է նստաշրջանների միջև, և միջուկը երբեք չի տեսնում այն։
WireGuard-ը առաջին խմբում է. այն գործընկերների միջև անջատիչ չունի, ուստի 10.8.0.4-ից 10.8.0.5 փաթեթը հասնում է wg0-ին, դիպչում է փոխանցման կեռիկին և նորից երթուղվում wg0-ից դուրս, երբ AllowedIPs-ը ծածկում է երկու հասցեները։ OpenVPN-ը երկրորդ խումբն է, հենց որ սերվերի կոնֆիգուրացիայում սահմանված է client-to-client-ը, քանի որ այդ հրահանգը փաթեթը փոխանցում է նստաշրջանների միջև օգտատիրոջ տարածությունում։ Նախքան որևէ բան գրելը՝ ստուգեք բեռնված կոնֆիգուրացիան այդ հրահանգի համար։ Միջուկի կանոնը, որը երբեք երթևեկություն չի տեսնում, չի տարբերվում աշխատող կանոնից, և հենց այդպես է տեղակայումը ավարտվում առանց որևէ մեկուսացման։
Կարդացեք գործող կոնֆիգուրացիան, ոչ թե այն ֆայլը, որը ենթադրում եք բեռնված, քանի որ դիստրիբուտիվ փաթեթները բերում են իրենց ներառումները։ Եթե դեմոնն է փոխանցում, արգելքը պատկանում է նրա սեփական՝ յուրաքանչյուր հաճախորդի կառավարմանը, և հոսթի firewall-ը զտում է միայն հոսթին ուղղված երթևեկությունը։ Եթե միջուկն է փոխանցում, փոխանցման կեռիկը միակ տեղն է, որ կարևոր է։
Երթուղավորված և թարգմանված տեղակայումները ևս մեկ ստուգում են պահանջում. հնարավոր է՝ հեռավոր հաճախորդի տեսած աղբյուրը այն չէ, ինչ սպասում եք։ Այդ դեպքում հաճախորդների ենթացանցին համապատասխանող կանոնը ոչնչի չի համապատասխանում։ Գրանցեք թարգմանությունից փրկված հասցեն նախքան համապատասխանությունը գրելը և նախընտրեք ինտերֆեյսների զույգը համապատասխանեցնել NAT հասցեները գուշակելու փոխարեն։
Տվեք յուրաքանչյուր հասցեի ինքնուրույն չեղարկվող ինքնություն
Մեկուսացումը փլուզվում է հենց որ երկու սարք կիսում են մեկ հավատարմագիր։ Այդ ինքնությանը կապված կանոնը չի կարող բաժանել նրանց, և կորած նոթբուքի չեղարկումը չեղարկում է ամբողջ խումբը։ Սարքով մեկ վկայականները կամ գործընկերոջով մեկ բանալիները չեղարկումը պահում են տեղային, իսկ քաղաքականությունը՝ ընթեռնելի, քանի որ յուրաքանչյուր հասցե համապատասխանում է ճիշտ մեկ մարդու կամ մեքենայի։ Երբ նախագիծը չի կարող դա անել, ասեք դա շահագործման ուղեցույցում՝ կանոնը նուրբ անվանելու փոխարեն։
Հասցեների բաշխումը պետք է համաձայնի քաղաքականության հետ։ Առանձնացրեք բլոկ ծառայությունների համար, բլոկ՝ հաճախորդների համար, և հաճախորդների հասցեները տվեք ձեր վերահսկած լողավազանից, ոչ թե առաջին եկողի տիրույթից։ Եթե սերվերը թարգմանում կամ կամուրջ է անում, քարտեզագրման աղյուսակը պահեք կոնֆիգուրացիայի կողքին, քանի որ հենց այդ աղյուսակն է պետք հաջորդ ընթերցողին կանոնը նորից բխեցնելու համար։
Արգելքը դրեք այնտեղ, որտեղ փաթեթը հատում է թունելը
WireGuard երթևեկությունը փոխանցող դարպասում դեպքը ծածկում են երկու կանոն՝ թույլատրեք ծառայության բլոկը, ապա դեն նետեք հաճախորդների բլոկի մնացածը։ Ինտերֆեյսների զույգը նույնքան կարևոր է, որքան հասցեները, քանի որ միայն նպատակակետով համապատասխանելը բռնում է նաև LAN-ից եկող երթևեկությունը։ Բեռնեք դրանք այդ հերթականությամբ, որպեսզի թույլտվությունը գնահատվի առաջինը։
nftables-ի դեպքում զույգը մտնում է գոյություն ունեցող inet filter աղյուսակ, նախ թույլտվություն, ապա դեն նետելը։ Երկու համապատասխանություններն էլ ամրացնում են ինտերֆեյսների զույգը և հասցեները։
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 dropԲեռնելուց հետո հետ կարդացեք շղթան՝ ելքի կարգավիճակին վստահելու փոխարեն, և հաստատեք, որ երկու կանոններն էլ ձեր ուզած հերթականությամբ են։ Ավելացրեք համապատասխան ip6 կանոններ IPv6 լողավազանի համար, այլապես v4 զույգը միայն զարդարանք է կրկնակի ստեկի թունելում։ Եթե սերվերն արդեն ունի թույլատրող փոխանցման քաղաքականություն, ավելացրեք դեն նետելը՝ շղթան ամբողջությամբ փոխարինելու փոխարեն։
Երբ OpenVPN-ում client-to-client-ը միացված է, այս փոխանցման կանոնները երբեք չեն համապատասխանում գործընկերների երթևեկությանը, և արգելքը պետք է ապրի դեմոնի սեփական կառավարման մեջ։ Պահեք միջուկի կանոնները հոսթին ուղղված երթևեկության համար, բայց մի հաշվեք դրանք որպես մեկուսացման կառավարում։
Ապացուցեք արգելքը հաճախորդից, ոչ թե սերվերից
Դարպասից փորձարկելը ոչինչ չի ապացուցում, քանի որ տեղում ստեղծված երթևեկությունը վերցնում է ելքի ուղին և երբեք չի հատում փոխանցման կեռիկը։ Օգտագործեք երկու իրական հաճախորդ՝ մեկը, որը պետք է հասնի ծառայությանը, և մեկը, որը պետք է մերժվի։ Սկզբում գործարկեք թույլատրված դեպքը, որպեսզի կոտրված թունելը չշփոթեն աշխատող քաղաքականության հետ։
Թույլատրված հաճախորդից համոզվեք, որ ծառայությունը պատասխանում է իր պորտին։ Նույն հաճախորդից փորձեք գործընկերոջ հասցեն և սպասեք լուռ դեն նետելու, ոչ թե մերժման՝
ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5Դեն նետված փաթեթը և անցանց գործընկերը երկուսն էլ ժամանակի սպառման տեսք ունեն, ուստի նախքան որևէ եզրակացություն անելը ստուգեք հաշվիչները։ Համոզվեք, որ դեն նետելու կանոնի հաշվիչը մեծանում է, մինչ գործընկերը ապացուցելիորեն միացված է։ Կրկնեք IPv6-ով, որտեղ բացակայող ip6 կանոնը v4 արգելքը թողնում է արդյունավետ երևալ։ Գրանցեք ընդունված և մերժված արդյունքները ուղեցույցում ամսաթվով, քանի որ հաջորդ միգրացիան նորից կբխեցնի կանոնը։