Մեկ պորտը VPN-ից դուրս բերելու համար պետք է քաղաքականությամբ երթուղավորում

Հարցումը միշտ նույն նախադասության տարբերակն է՝ թող VPN-ը մնա զննարկման համար, բայց թող SSH-ը կամ պահուստային աշխատանքը օգտագործի սովորական կապը։ Այս մասին շրջանառվող խորհուրդը՝ պորտը iptables NAT կանոններով փոխանցելը, դա չի անում։ NAT կանոնը վերագրում է հասցեներ և պորտեր հոսքի ներսում, այն երբեք չի ընտրում, թե որ ինտերֆեյսով է փաթեթը դուրս գալիս։ Այդ որոշումը պատկանում է երթուղու որոնմանը, իսկ երթուղու որոնմանը օգնություն է պետք պորտ տեսնելու համար։

Ինչու սովորական երթուղին չի կարող համընկնել պորտի հետ

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

Ժամանակակից iproute2-ը և միջուկները լայնացնում են կանոնի ընտրիչը՝ ipproto՝ sport և dport ընդունվում են, ուստի ip rule add ipproto tcp dport 22 table 100 մտադրությունը արտահայտում է մեկ տողում։ Գործարկեք ip rule add help իրական հոսթում՝ տեսնելու, թե արդյոք ձեր կառուցվածքը թվարկում է dport։ Եթե այո, մեկ հրամանով ավարտված է, եթե ոչ՝ ներքևի նշանի ուղին համարժեք է։

Ինչպես էլ լինի, կանոնը միայն ցուցիչ է։ Աղյուսակ 100-ին դեռ երթուղի է պետք, և հենց այդ մասն են մարդիկ մոռանում։

Երեք մաս, թե մեկ

Ժամանակակից ձևը վերևի միակ կանոնն է՝ գումարած երթուղի այլընտրանքային աղյուսակում։ Դասական ձևը մեջտեղում ավելացնում է netfilter՝ նշեք փաթեթը, ապա կանոնում համընկնեք նշանին։ Երկուսն էլ ավարտվում են նույն որոնմամբ, տարբերվում են նրանով, թե որտեղ է կարդացվում պորտը։

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

Երեք մասերը հերթականությամբ

Նախ նշեք այն հոսքերը, որոնք ուզում եք շեղել, այնպիսի շղթայում, որը բավական վաղ է աշխատում, որպեսզի նշանը գոյություն ունենա երթուղու որոշումից առաջ՝

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

Երկրորդ՝ ուղարկեք նշված փաթեթները առանձին աղյուսակ՝

ip rule add fwmark 0x1/0x1 table 100

Երրորդ՝ տվեք այդ աղյուսակին կանխադրված երթուղի ֆիզիկական կապով։ Հասցեները օրինակ են, դրեք ձերը՝

ip route add default via 192.168.1.1 dev wlan0 table 100

Բաց թողեք երրորդ քայլը, և նշված փաթեթը 100 աղյուսակում երթուղի չի գտնի, ուստի կձախողվի։ Ախտանիշը կարծես կանոնը կոտրել է ցանցը, մինչդեռ իրականում հեռացրել է միակ ուղին, որ փաթեթին մնացել էր։

Ինչն է այն աշխատեցնում առաջին փաթեթից հետո

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

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

Չնշեք թունելի սեփական տրանսպորտը։ WireGuard կամ UDP OpenVPN թունելը TCP 22 չէ, ուստի վերևի բաղադրատոմսը անվտանգ է, բայց ամեն ինչ, բացի թունելի նպատակակետից ձևով գրված բացառությունը կարող է բռնել գաղտնագրված փաթեթները և կոտրել թունելն այնպես, որ երթուղային օղակ թվա։

Ստուգեք՝ փոխարենը չենթադրելու

Հարցրեք միջուկին, թե որ ուղին կընտրի՝ նպատակակետի և պորտի համար, ապա գործարկեք իրական փոխանցումը՝

ip route get 203.0.113.10
ip rule show
nft list ruleset

Եթե նշանը կա, բայց հաշվիչները երբեք չեն շարժվում, կանոնը չի համընկնում։ Հաշվիչները տարբերությունն են ձեր գրած կարգավորումի և միջուկի կիրառած քաղաքականության միջև։

Երբ սա սխալ գործիք է

Պորտի վրա հիմնված բացառությունները բնույթով փխրուն են։ Ծառայությունները փոխում են պորտերը, HTTP/3-ը գալիս է որպես UDP 443, և մեկ ծրագիր կարող է բացել տարբեր տեսակի մի քանի հոսք։ Եթե իրական պահանջն այն է, որ այս ծրագիրը օգտագործի սովորական կապը, երթուղավորման շերտը սխալ տեղ է, ցանցային անվանատարածքը կամ յուրաքանչյուր ծրագրի համար պրոքսին ավելի հարմար են։

Եթե պահանջն այն է, որ այս ենթացանցը օգտագործի սովորական կապը, ամբողջությամբ բաց թողեք նշանները և ավելացրեք ավելի կոնկրետ երթուղի։ Դա ավելի պարզ է, երևում է մեկ աղյուսակում, և հաջորդ մարդը կարող է ստուգել այն՝ առանց կանոնների հավաքածու կարդալու։

Գրեք, թե երեք պահանջներից որն է իրականում ձերը, նախքան firewall-ին դիպչելը։ Վերևի մեխանիզմը ճշգրիտ է, իսկ սխալ շերտի վրա կիրառված ճշգրտությունը ընդամենը ավելի երկար ընդհատում է։