Linux-ի մեկ հաշիվը OpenVPN-ով ուղղորդել UID-ի կանոնով

Հաշվի վրա հիմնված երթուղավորումը հարմար է, երբ մեկ Linux օգտատիրոջ պատկանող յուրաքանչյուր IPv4 սոկետ պետք է դուրս գա գոյություն ունեցող թունելով, և հարմար չէ, երբ ձեզ անհրաժեշտ է մեկուսացում ծրագրի մակարդակում։ Այն ընտրում է ըստ UID-ի, ուստի այդ հաշվով աշխատող ամեն ինչ ընկնում է տիրույթի մեջ, ներառյալ ձեր մոռացած փաթեթային աշխատանքը։ Լուծեք այդ հարցը նախքան մեկ ip rule-ին դիպչելը։

Ստորև բերված օրինակը ենթադրում է UID 1500-ում առանձին զննարկիչի հաշիվ, 10.80.0.11 տեղական հասցեն կրող tun-office թունելային սարք և VPN, որը թույլատրում է խնդրո առարկա նպատակակետերը։ Դեմոնն ինքը աշխատում է այդ UID-ից դուրս։

Երեք պայման, որոնք ընտրում են մեխանիզմը

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

Խուսափելի սխալն այն ենթադրությունն է, թե գործարկիչը սահմանում է սեփականատիրոջը։ Զննարկիչը, որին URL է փոխանցվել այլ օգտատիրոջ նստաշրջանից, UID 1500-ի տակ սոկետներ չի ստեղծել, և ոչ մի կանոն չի տեղափոխի նրա գեներացրած երթևեկությունը։

Աղյուսակը, կանոնը և պահապանը

Գոյություն ունեցող կանոնները ստուգելուց և չօգտագործված աղյուսակի ու առաջնահերթության համարներ ընտրելուց հետո դասավորությունը կարճ է. առանձին աղյուսակում լռելյայն երթուղի, որը կրում է թունելի աղբյուրի հասցեն, կանոն, որը հաշվի որոնումները ուղարկում է այդ աղյուսակ, և ավարտող կանոն, որը արգելափակում է պահեստային ուղին։ Գրավոր ձևով սա idempotent երթուղու փոխարինում է՝ ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, որին հաջորդում է ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820։

Պահապանը ip -4 rule add priority 12101 uidrange 1500-1500 unreachable-ն է, և այն ավելի կարևոր է, քան հուշում է իր երկարությունը։ Առանց դրա՝ 51820 աղյուսակում բացակայող երթուղին ընկնում է սովորական վերին կապուղի, և հաշիվը լուռ արտահոսում է այն երթևեկությունը, որը քաղաքականությունը պիտի որսար։ Դրա հետ նույն խափանումը դառնում է ժամկետանցություն, այսինքն՝ արգելափակում, ոչ թե պահեստային ուղի։

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

Ինչ է բաց թողնում UID-ի երթուղավորումը՝ DNS

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

loopback հարցումը տեղական stub-ին ապացույց չէ, որ վերին հարցումն օգտագործել է զննարկիչի ուղին, և քեշից հաջող էջի բեռնումը նույնպես ապացույց չէ։

IPv6-ը ձևավորման մեջ իր նախադասությունն է պահանջում

Վերոնշյալ կանոնները ծածկում են միայն IPv4-ը։ Եթե պահանջը այս հաշվից ուղիղ IPv6-ի բացակայությամբ IPv4 թունել է, ավելացրեք վերանայված ավարտող կանոն, օրինակ՝ ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, ապա ստուգեք ավելի վաղ IPv6 կանոնները և այն loopback բացառությունները, որոնք ցանկանում եք պահել։

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

Ստուգեք իրական հաշվով, ապա վերցրեք կյանքի ցիկլը

Համեմատեք որոնումները. ip -4 route get 198.51.100.25 uid 1500 նույն նպատակակետի հետ սովորական UID-ով։ Ապա թույլատրված հարցում կատարեք առանձին հաշվի տակ և ստուգեք աղբյուրի այն հասցեն, որը տեսնում է հեռավոր կողմը։ Նախընտրելի աղբյուրի հասցեն source NAT չէ, և այն չի գերազանցի հավելվածին, որը կապում է այլ բան։ Եթե երկու որոնումներն էլ նույն ուղին են վերադարձնում, կանոնը չի անում այն, ինչ դուք կարծում եք։

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