WireGuard AllowedIPs՝ այն երթուղին, որը NetworkManager-ը երբեք չավելացրեց

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

wg-quick-ը կատարում է երկուսն էլ առանց խնդրելու։ NetworkManager-ի ներկառուցված WireGuard աջակցությունը նույնպես լռելյայն տեղադրում է peer-երթուղիներ, ինչը կասկածյալներին նեղացնում է մինչև անջատված տարբերակ, այլ երթուղային աղյուսակ կամ այլ բանի միջոցով ներմուծված կարգավորում։

Հաստատեք թունելը նախքան երթուղու հետևից գնալը

wg show-ը տպում է ինտերֆեյսը, peer-ը, վերջնակետը և վերջին ձեռքսեղմման տարիքը, իսկ ip addr show-ը հաստատում է, որ հասցեն առկա է։ Վերջերս կատարված ձեռքսեղմումը նշանակում է, որ բանալիները, վերջնակետը և UDP ուղին աշխատում են։ Ամեն ինչ կոտրված գտնվում է դրանցից ներքև՝ երթուղավորում, զտում կամ անունների լուծում։

Այնուհետև հարցրեք միջուկին, թե ինչ կանի իրական նպատակակետի հետ՝ հիպոթետիկի փոխարեն՝ ip route get 10.42.7.9։ Պատասխանը նշում է ելքային ինտերֆեյսը և այն աղբյուրի հասցեն, որը կկրեր փաթեթը։ Երբ այն նշում է ֆիզիկական ադապտերը, փաթեթը երբեք չի մտնում թունել, որքան էլ ձեռքսեղմումը առողջ թվա։

AllowedIPs-ը զտիչ է և երթուղիների ցանկ

AllowedIPs-ի նախադրյալները երկու աշխատանք են կատարում։ Դրանք ընտրում են, թե որ peer-ը կկրի ելքային նպատակակետ, և ստուգում են մուտքային փաթեթների աղբյուրի հասցեն, ինչը գաղտնաբառային երթուղավորման սահմանն է։ wg-quick-ում դրանք նաև վարում են երթուղիների ինքնաշխատ տեղադրումը, և հենց այդ լրացուցիչ վարքն է պատճառը, որ նույն կարգավորումն աշխատում է տերմինալից և չի աշխատում աշխատասեղանի հաճախորդից։

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

Հարցրեք՝ արդյոք peer-երթուղիները ընդհանրապես միացված են

Կարդացեք կարգավորումը նախքան ինչ-որ բան փոխելը՝ nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg։ Երբ peer-routes-ը ցույց է տալիս no, աջակցվող վերանորոգումը nmcli connection modify work-wg wireguard.peer-routes yes-ն է, որին հաջորդում է նորից միանալը։ Փոխարենը ստատիկ երթուղի ավելացնելը աշխատում է մինչև հաջորդ ակտիվացումը և հետո լուռ անհետանում է։ Այդ անհետացումը հուշումն է՝ ամեն առավոտ հանելուկի պես վերադարձող երթուղին պրոֆիլը չէ, որ տեղադրում է։

Եթե տարբերակն արդեն միացված է, ստուգեք՝ արդյոք նախադրյալն ապրում է այլ աղյուսակում, ip route show table all | grep 10-ի օգնությամբ։ Ոչ հիմնական աղյուսակում եղած երթուղին բացակայող չէ, այն ուղղակի անտեսանելի է որոնման համար, որը դիտում է միայն հիմնական աղյուսակը։ Ուղղեք քաղաքականության երթուղավորումը՝ վրան կրկնօրինակ գրառում կուտակելու փոխարեն։

Նախադրյալը ավելացրեք միացմանը, ոչ թե աշխատող համակարգին

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

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

Բաժանված թունելը որոշվում է նախադրյալների ցանկով

Բաժանված թունելի անջատիչ չկա՝ նախադրյալների ցանկն է որոշումը։ Peer-ը, որն ունի մեկ միջակայք գրասենյակի LAN-ի համար և մեկը լաբորատոր ցանցի համար, ուղարկում է հենց այդ նպատակակետերը թունելով և մնացած ամեն ինչ թողնում է հանգիստ։ Մեկ հոսթին անհրաժեշտ է /32, իսկ երկու տեղամասերում համընկնող միջակայքերին՝ հոսթի նախադրյալներ, մինչև ինչ-որ մեկը վերահամարակալի ենթացանցը։

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

Մեկ սեփականատեր երթուղային աղյուսակի համար

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

Երբ բաժանումը պետք է հետևի ֆիզիկական ադապտերին, ոչ թե նպատակակետին, դուք անցել եք քաղաքականության երթուղավորման, և քաղաքականության երթուղավորումը նույնպես մեկ հեղինակ է պահանջում։ Ստուգեք՝ կրկնելով ip route get-ը, ապա հասնելով հեռավոր նախադրյալի ներսում գտնվող հոսթի ինչ-որ բանով, որ տպում է իր ընտրած աղբյուրի հասցեն։ Ստուգեք IPv6-ը և DNS-ը առանձին, եթե պրոֆիլը կրում է դրանցից որևէ մեկը։