Դուք կանոն եք ավելացնում VPN թրաֆիկի համար FORWARD շղթայում, հարցումը գործարկում եք նույն Linux մեքենայից, և հաշվիչը մնում է զրոյի վրա։ Կանոնը հավանաբար ճիշտ է։ Փաթեթը երբեք այդ ուղով չի գնացել, որովհետև մեքենայի վրա ծնված հարցումը դրա կողմից չի փոխանցվում։ Փաթեթի կյանքի հետևումը սոքեթից մինչև լար բացատրում է, թե ինչու և որտեղ պետք է լինի կանոնը։

Գտեք, թե որտեղ է ծնվել փաթեթը

Netfilter-ի կեռիկների հերթականությունը բաժանում է երեք դեպք, և դրանցից միայն մեկն է ներառում FORWARD:

OriginPathHook that sees it
Local processOUTPUT then POSTROUTINGOUTPUT, POSTROUTING
Addressed to a local servicePREROUTING then INPUTPREROUTING, INPUT
Received for another hostPREROUTING, FORWARD, POSTROUTINGFORWARD

Տեղական հավելվածը սկսվում է OUTPUT ուղուց, որովհետև միջուկն արդեն հաստատել է, որ փաթեթը ծագում է այստեղ և երբեք փոխանցման թեկնածու չէ։ Թունել ստեղծելը չի փոխում այդ դասակարգումը՝ թունելը սարք է, որով փաթեթը կարող է դուրս գալ, ոչ թե փուլ, որը տեղական ելքը դարձնում է տրանզիտ։

Երկու փաթեթ, մեկ պատմություն

Երբ թունելը բարձրացված է, հավելվածի ներքին փաթեթը և գաղտնագրված արտաքին փաթեթը տարբեր օբյեկտներ են։ Ներքին փաթեթը կրում է այն նպատակակետը և բեռը, որն ընտրել է հավելվածը։ Արտաքին փաթեթը գաղտնատեքստը տանում է զուգընկերոջ հասցեին և պորտին, և հենց այն է, որ իրականում անցնում է ֆիզիկական միջերեսով։

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

Անվանատարածքները տեղափոխում են սահմանը

Կոնտեյները դա դժվարացնում է՝ չփոխելով սկզբունքը։ Հավելվածի հարցումը տեղական ելք է կոնտեյների ցանցային անվանատարածքի ներսում։ Հոսթը այդ թրաֆիկը ստանում է վիրտուալ Ethernet միջերեսի վրա և կարող է այն փոխանցել, ուստի հոսթի վրա FORWARD կանոնը կարող է իմաստալից լինել, թեև հարցումը ծնած պրոցեսը երբեք չի դիպչել հոսթի OUTPUT շղթային։

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

Հարցրեք՝ արդյոք ընդհանրապես նշում է պետք

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

Դասակարգում է պետք, երբ որոշումը կախված է մի բանից, որ երթուղին չի կարող արտահայտել՝ օրինակ աղբյուրից, օգտատիրոջից կամ պրոցեսից։ Ստացվող թրաֆիկի համար նշումը PREROUTING-ում աշխատում է։ Տեղական թրաֆիկի համար նշումը պետք է կատարվի ելքի փուլում, որը նշումը դնելուց հետո կարող է նոր երթուղու որոնում սկսել։ nftables-ում դա route տիպի շղթա է ելքի կեռիկի վրա՝ սովորական ելքի զտիչ շղթան կդնի արժեքը և երթուղին կթողնի անփոփոխ։

iptables-ում համարժեքը ապրում է mangle OUTPUT դասավորության մեջ, և նույն պահանջը գործում է՝ երթուղային որոշումը պետք է վերանայվի այն բանից հետո, երբ նշումը գոյություն ունի։ Այնուհետև քաղաքականության կանոնը պետք է սպառի նշումը և մատնանշի աղյուսակ, որը պարունակում է օգտագործելի երթուղի։ conntrack նշումը դնելը երրորդ, առանձին գործողություն է՝ այն արժեք է պահում հոսքի վրա և ինքնին այդ արժեքը չի դնում ընթացիկ փաթեթի վրա, որպեսզի երթուղավորումը կարդա այն։

Ստուգեք որոնումը և հաշվիչը միասին

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

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

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

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

Առնչվող հոդվածներ