AllowedIPs-ը երթուղային ցանկ է, ոչ թե հրդեպատի կանոն

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

Մեկ դաշտ, երկու ընթերցող՝ ելքի ընտրություն և աղբյուրի ստուգում

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

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

Հաճախորդի բլոկն այն տեղն է, որտեղից սկսվում է այս շփոթության մեծ մասը։ Բաժանված թունելը նշում է հեռավոր ցանցերը, իսկ ամբողջական թունելը նույն դաշտն է՝ լռելյայն նախածանցով:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Երկու ձևերն էլ ինքնին ամբողջական են, և դրանք այլընտրանքներ են, ոչ թե քայլեր։ Առաջինը թունելով ուղարկում է միայն այդ երկու ցանցերը. երկրորդը ուղարկում է բոլոր նպատակակետերը, և ::/0 գրառումը IPv6-ն ավելացնում է IPv4 լռելյայնին։ Ինչ էլ ընտրեք, այդ նախածանցերը այդ զուգորդի ամբողջ երթուղային որոշումն են, հենց որ wg-quick-ը սկսի տեղադրել երթուղիներ։

Կենտրոնին այլ ցանկ է պետք

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

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Հոսթի նախածանցը կրում է թունելի հասցեն, իսկ ցանցի նախածանցը՝ այն, ինչ գտնվում է հաճախորդի հետևում, և երկուսն էլ անհրաժեշտ են։ Առանց հոսթի նախածանցի կենտրոնը չի կարող վերադարձնել հաճախորդի սեփական թրաֆիկը, իսկ առանց ցանցի նախածանցի նրա հետևի LAN-ը մնում է անհասանելի. զուգորդը, որի հետևում ոչինչ չկա, ստանում է միայն հոսթի նախածանցը։

Երթուղիների տեղադրումը բաց թողնելը բաց է թողնում

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

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

DNS-ը և IPv6-ը որոշվում են առանձին

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

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