Թույլ տվեք ip rule կանոնին վերապրել վերամիացումը systemd-networkd-ի հետ

Ավելացրեք քաղաքականության կանոն ip rule-ով, և այն աշխատում է այնքան ժամանակ, քանի դեռ կապը չի անհետացել; այդ պահին այն պարզապես չկա։ Ոչինչ բարձր ձայնով չձախողվեց․ միջուկի վիճակը փոխվեց, և ոչ մի կազմաձևման սեփականատեր չգիտեր, որ կանոնը պետք է գոյություն ունենա։ Սա է ամբողջ տարբերությունը գոյատևող և չգոյատևող կանոնի միջև։ systemd-networkd ունեցող հոսթում լուծումը կանոնին սեփականատեր տալն է, այլ ոչ թե հրամանը նորից գործարկելը յուրաքանչյուր վերամիացումից հետո։

Կանոնը գոյություն ունի միայն այն դեպքում, երբ ինչ-որ մեկը տիրապետում է այն։

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

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

Այդ տարբերությունն անուն ունի networkd-ում, և արժե կարդալ այն նախքան որևէ բան միացնելը։ Վերջին տարբերակներում օտար կանոնները հեռացվում են լռելյայն, ինչը զարմացնում է նրանց, ովքեր սպասում էին, որ իրենց ձեռքով արված գրառումները կմնան։

Կարդացեք տարբերակը նախքան պարամետրին վստահելը։

Սեփականության վարքագիծը կառավարվում է networkd.conf-ի պարամետրով, և այդ պարամետրը չկա systemd-ի հին թողարկումներում։ Ստուգեք տեղադրված տարբերակը նախքան դրա շուրջ նախագծելը, որովհետև հին հոսթն այլ կերպ է վարվում, քան ձեր կարդացած փաստաթղթերը։

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

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

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

Հայտարարեք կանոնը և այն աղյուսակը, որի վրա այն ցույց է տալիս։

.network ֆայլում կանոնը անվանում է աղյուսակ, և անվանումն այսքանն է անում։ Այն չի ստեղծում այդ աղյուսակի ներսի երթուղիները և չի ստուգում, թե արդյոք դրանք իմաստ ունեն։ Կանոնը առանց երթուղիների հայտարարելը տալիս է քաղաքականություն, որը համապատասխանեցնում է երթևեկությունը, ապա գցում այն։

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

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

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

Ընտրեք մեկ սեփականատեր ինտերֆեյսի համար։

Երկու կառավարիչ մեկ թունելի վրա ստեղծում են պայքար, որը երկուսում էլ սխալի տեսք ունի։ Գոյություն ունեցող wg-quick կարգավորումը networkd ներմուծելը միգրացիա է, ոչ թե հավելում, և երկուսն էլ աշխատեցնելը ինտերֆեյսն ու նրա կանոնները թողնում է երկու սեփականատիրոջ ներքո։

Կատարեք միգրացիան մեկ անցումով․ կանգնեցրեք հին միավորը, անջատեք այն, հայտարարեք ինտերֆեյսը և նրա երթուղիները networkd-ում, ապա նորից բեռնեք։ Ստուգեք, որ հին միավորը չի կարող վերադառնալ բեռնման ժամանակ։ Մնացած միավորը, որը վերագործարկումից հետո նորից ակտիվանում է, վերագրում է այն վիճակը, որը հենց նոր հայտարարեցիք։ Պահեք հին կազմաձևման ֆայլը այնքան, մինչև նորը վերապրի վերամիացումը, ապա դուրս բերեք այն գործածությունից։

Նշանի սեփականությունը նույն խնամքն է արժանի․ եթե կանոնը համընկնում է հրակայուն նշանի հետ, ինչ-որ բան պետք է դնի այդ նշանը։ Կանոնը, որը հղում է անում նշանի, որը ոչ ոք չի դնում, մեռած կազմաձևում է, որը միտումնավոր է թվում։

Փորձեք կյանքի ցիկլի իրադարձությունները։

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

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

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