WireGuard-ի ամբողջական թունել. AllowedIPs 0.0.0.0/0-ը բավարար չէ

Զույգի AllowedIPs-ում 0.0.0.0/0, ::/0 տեղադրելը այն քայլն է, որը բոլորը հիշում են, և այն միայն որոշում է, թե ինչ երթևեկություն զույգին թույլատրված է կրել։ Այդ նախածանցերը ոչ մի երթուղի չեն ստեղծում, մյուս կողմում ոչինչ չեն փոխանցում և յուրաքանչյուր հավելվածի լուծիչը թողնում են հենց այնտեղ, որտեղ եղել է։ Չորս առանձին բան պետք է միաժամանակ ճիշտ լինի, որպեսզի ամբողջական թունելն իսկապես ամբողջական լինի, և դրանք լավագույնս ստուգվում են ստորև նշված հերթականությամբ, քանի որ ավելի ուշ ստուգումը չի կարող փրկել ավելի վաղը։ Ստորև յուրաքանչյուր ստուգում մի փաստ է, որը կարելի է կարդալ մեքենայից, ոչ այն կարգավորումը, որի կիրառմանը դուք հույս ունեք։

Ինչ է ընտրում զույգի նախածանցը, և ինչ ոչ

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

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

Երթուղավորել կլիենտին, ոչ միայն զույգերի ցանկը

Կառավարիչները, ինչպիսին է wg-quick -ը, հոսթի երթուղային աղյուսակը ծրագրավորում են ձեր փոխարեն, դրա համար է, որ երկու նույնական կարգավորման ֆայլեր տարբեր կերպ են վարվում՝ կախված նրանից, թե ինչպես է ինտերֆեյսը բարձրացել։ Նվազագույն պրոֆիլը բավական կարճ է, որպեսզի կարդացվի մեկ նստումով՝

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Աշխատանքը երկու մանրամասն է կրում։ Address դաշտը մեկ հոսթի նախածանց է, ոչ այն ենթացանցը, որը կլիենտը կարծում է, թե իրենն է, և հենց կառավարիչն է լռելյայն AllowedIPs-ը դարձնում իրական լռելյայն երթուղի։ Նույն ֆայլը բարձրացրեք ip link և wg setconf -ով, և ոչ մի երթուղի չի հայտնվի, ինչը նման է կոտրված թունելի, մինչդեռ դա առողջ թունել է՝ երթուղավորման քայլը բաց թողնված։ wg-quick -ի ձեռնարկը փաստագրում է երթուղավորումը և Table վարքը, որը ավելացնում են այդ կառավարիչները։

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

Վերջնակետը թունելից դուրս պահելը

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

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

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

Փոխանցումը և վերադարձի ուղին դարպասի վրա

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Որոնումը կատարվում է դարպասի վրա, ոչ կլիենտի, այլապես դուք կկարդաք այլ երթուղային աղյուսակ։ Եթե այն անվանում է սխալ ինտերֆեյս կամ հաղորդում է, որ երթուղի չկա, ապա կլիենտի կողմի ոչ մի փոփոխություն ինտերնետ ելք չի տա։ Երբ դարպասը թարգմանում է կլիենտների հասցեները դուրս գալիս, պատասխանը կախված է այդ թարգմանության վիճակից, ուստի կանոնը պետք է գոյություն ունենա հոսքի երկու ուղղությունների համար, ոչ միայն ելքայինի։

DNS-ը և ձախողման վիճակը՝ առանձին ստուգված

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

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

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