NetworkManager թե wg-quick. ո՞վ է տիրում ձեր WireGuard երթուղիներին

Փոխում եք AllowedIPs-ը WireGuard ֆայլում, վերագործարկում թունելը, և երթուղային աղյուսակը նույնն է, ինչ նախկինում։ Սովորական արձագանքը խնդրահարույց երթուղին ջնջելն ու առաջ գնալն է, ինչը աշխատում է մինչև հաջորդ վերամիացումը այն հետ բերի։ Ձեր խմբագրած ֆայլը պարտադիր չէ, որ այն օբյեկտն է, որը ստեղծել է ձեր տեսած վիճակը։ Երկու կառավարիչ կարող են նույն արձանագրությունը վարել մեկ մեքենայում, և ամեն պահի միջերեսին տիրում է դրանցից միայն մեկը։

Առասպել. մեքենայում կա WireGuard-ի մեկ կարգավորում

wg-quick-ը ֆայլ է կարդում /etc/wireguard/ պանակում և կառուցում է միջերեսը, երբ բարձրացնում եք այն։ NetworkManager-ը պահում է միացման պրոֆիլը իր keyfile ձևաչափով և ներկայացնում այն ակտիվացման պահին, և wg-quick ֆայլի ներմուծումը արժեքները պատճենում է այդ պրոֆիլի մեջ՝ դրան կապվելու փոխարեն։ Դրանից հետո բնագրի խմբագրումը ոչինչ չի փոխում, որովհետև պրոֆիլը այլևս այն չի կարդում։ Այսպիսով՝ նույն հասակակիցների և բանալիների ցանկը կարող է երկու անգամ գոյություն ունենալ, ընդ որում ուժի մեջ է երկրորդ պատճենը։

Հիշելարժեք նշան. փոփոխությունները, որոնք դիմանում են վերագործարկմանը, բայց ոչ վերաներմուծմանը, եկել են մի պահոցից, իսկ վերագործարկման ժամանակ անհետացող փոփոխությունները՝ մյուսից։

Մեկ գործնական օրինակ բաժանումը ակնհայտ է դարձնում։ Համեմատե՛ք nmcli connection show հետ՝ systemctl status wg-quick@wg0, ապա ստուգե՛ք, թե որ միջերեսից են իրականում կախված երթուղիները։ Եթե ծառայությունը մեռած է, իսկ միջերեսը՝ բարձրացված, աշխատանքը կատարում է պրոֆիլը, ինչ էլ որ ասի ֆայլը։

Առասպել. երթուղային կանոնները WireGuard-ի մասն են

Միջուկի WireGuard սարքը ճանաչում է հասակակիցներին և բանալիներին, և ոչինչ չգիտի քաղաքականությամբ պայմանավորված երթուղավորումից։ Ինչ ip rule գրառումներ և լրացուցիչ աղյուսակներ էլ տեսնեք, դրանք տեղադրել է այն գործիքը, որը բարձրացրել է միջերեսը։ wg-quick-ը կարող է ավելացնել fwmark և առանձին աղյուսակ, ինչպես նաև դրան ուղղված կանոններ, մինչդեռ NetworkManager-ը երթուղիները տեղադրում է իր ipv4 կարգավորումների միջոցով և DNS-ը թողնում է այն լուծիչ հետնաշերտին, որն օգտագործում է համակարգը։ Նույն թունելը, տարբեր կողմնակի ազդեցություններ։

Կարդացե՛ք ip rule և ip route show table all նախքան որևէ բան փոխելը, և նշե՛ք, թե որ աղյուսակում է ապրում յուրաքանչյուր երթուղի։ Աղյուսակի այն համարը, որը դուք չեք կարգավորել, ուժեղ ակնարկ է այն գործիքի մասին, որը ստեղծել է այն։

Առասպել. երթուղին ջնջելը լուծում է

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

Վերամիացումը և համապատասխան ծառայության վերագործարկումը այն փորձն է, որը տարբերում է իրական ուղղումը կոկիկ տեսք ունեցողից։

Ընտրե՛ք մեկ տեր և հեռացրե՛ք մյուսին

Ընտրե՛ք այն կառավարիչը, որին աջակցում է ձեր տեղակայումը, ապա անջատե՛ք մրցակցող ակտիվացումը դրա փաստագրված կառավարման միջոցով՝ հուսալու փոխարեն, որ այն անգործ կմնա։ Քողարկված wg-quick ծառայությունը կամ ջնջված NetworkManager պրոֆիլը բացահայտ է. երկուսն էլ միացված թողնելն ու նրանց մրցավազք թույլ տալը՝ ոչ։ Պահպանե՛ք աշխատող հասանելիությունը նախքան որևէ բան անջատելը, որովհետև ձեր հեռավոր նստաշրջանը կրող միջերեսը կարող է հենց այն լինել, որը պատրաստվում եք հեռացնել։

Փոփոխությունից հետո ստուգե՛ք ներառված և բացառված երթևեկությունը, ապա DNS-ը, ապա մեկ անգամ վերագործարկե՛ք։ Եթե վիճակը դիմանում է վերագործարկմանը մեկ կառավարչով, դուք ունեք տեր, այլ ոչ թե պատահականություն։

Ընդհանուր կանոնը արժե պահել նաև WireGuard-ից դուրս. երբ կարգավորումը շարունակաբար վերադառնում է, դադարեցրե՛ք արդյունքը ջնջելը և գտե՛ք այն գործընթացը, որը շարունակաբար արտադրում է այն։