Ինչպես կառուցել WireGuard թեստ երկու peer-ով, որն ապացուցում է մեկ ուղի

WireGuard թեստը, որը կրում է լռելյայն երթուղի, LAN նախածանց, DNS և firewall-ի բացառություն, չի կարող ասել, թե դրանցից որն է կոտրվել։ Կրճատեք այն երկու peer-ի, մեկ զույգ հասցեի և մեկ թույլատրված ծառայության, և խափանումը տեղ չի ունենա թաքնվելու։ Ձանձրալի հիմքը հենց ախտորոշումն է։ Կառուցեք այն առաջինը՝ այն տևում է տասնհինգ րոպե և խնայում է այն կեսօրը, որը հակառակ դեպքում կանցկացնեիք գուշակելով։

Այն, ինչ ապացուցում է հիմքը, ավելի նեղ է, քան շատերն են սպասում։ Այն ապացուցում է, որ երկու ինքնություններ համաձայն են, որ UDP-ն հասնում է լսող պորտին, և որ մեկ թույլատրված նպատակակետ կրում է հարցում։ Փոխանցումը, NAT-ը, LAN երթուղիները և DNS-ը առանձին գործառույթներ են, որոնք ավելացվում են հետո՝ մեկ առ մեկ։

Բանալիները, հասցեները և միակ endpoint-ը

Ստեղծեք բանալիների զույգ յուրաքանչյուր համակարգում և նրանց միջև տեղափոխեք միայն հրապարակային կեսերը։ wg genkey | tee privatekey | wg pubkey > publickey փաստաթղթավորված մեկտողանոց հրամանն է, և այն մասնավոր բանալին թողնում է ֆայլում, որը հետո կարող եք պաշտպանել։ Ընտրեք թունելի հասցեներ տիրույթից, որը չի հանդիպում ձեր ոչ մի այլ կարգաբերման մեջ, օրինակ՝ 10.99.0.1/24 և 10.99.0.2/24։ Գրեք, թե որ հասցեն որ մեքենային է պատկանում, որովհետև յուրաքանչյուր հետագա ստուգում կախված է այդ քարտեզագրումից։

Մասնավոր բանալիները երբեք չեն ճամփորդում։ Եթե թեստին անհրաժեշտ է մեկը՝ պատճենված մյուս կողմ, թեստն արդեն սխալ է գնացել։ Երբ երկու համակարգերը գտնվում են NAT-ի հետևում, գոնե մեկին պետք է հասանելի UDP պորտ, մինչ մյուսը կրում է Endpoint, որը ցույց է տալիս դրան, և հրապարակային հասցեն ու պորտը տեղ ունեն ձեր գրառումներում, ոչ թե 51820-ի մասին ձեր ենթադրություններում։

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

Այն դաշտերը, որոնք պատկանում են wg-ին, և նրանք, որոնք չեն

Հիմնական դաշտերի հավաքածուն փոքր է՝ PrivateKey և ListenPort՝ Interface-ի տակ, PublicKey, AllowedIPs և Endpoint՝ Peer-ի տակ։ Address-ը և DNS-ը պատկանում են wg-quick-ին, ոչ թե հենց wg-ին, և այդ տարբերությունը կծում է այն պահին, երբ նույն կարգաբերումը տեղափոխվում է այլ գործիք։

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs-ը միաժամանակ երկու աշխատանք է կատարում։ Այն ընտրում է, թե որ նպատակակետերն են մտնում թունել, և թույլատրում է peer-ին օգտագործել այդ աղբյուր հասցեները ժամանելիս։ Դրա համար մյուս կողմի հայելային գրառումը պետք է ճիշտ անվանի ձեր թունելի հասցեն՝ սխալ peer-ի համար /32-ը կարդացվում է որպես երթուղային խնդիր և իրեն պահում է որպես թույլտվության խնդիր։ WireGuard արագ սկիզբ ցույց է տալիս նույն երկու peer-ի ձևը կանոնական ձևակերպմամբ, եթե ցանկանում եք համեմատել դաշտերի անունները։

Կարդալ ձեռքսեղմումը պատկերակի փոխարեն

Բարձրացրեք ինտերֆեյսը նրա միջոցով, ինչին այն պատկանում է, ապա կարդացեք վիճակ, ոչ թե կարգավիճակի լույս։ wg show տպում է վերջին ձեռքսեղմումը յուրաքանչյուր peer-ի համար՝ բայթ հաշվիչների հետ միասին, և վերջին մի քանի րոպեի ձեռքսեղմումը նշանակում է, որ բանալիները, endpoint-ը և UDP ուղին բոլորը աշխատում են։ Հաշվիչը, որ աճում է միայն մեկ ուղղությամբ, ինքն է պատասխանը, և դա նույն խափանումը չէ, ինչ երբեք չկատարվող ձեռքսեղմումը։

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

Մեկ թույլատրված ծառայություն ապացուցել, ապա հակառակը

Հարցում ուղարկեք մյուս peer-ի թունելի հասցեին այնպիսի ծառայության, որը պետք է պատասխանի, և ընտրեք ping-ից ավելի լավ բան։ Բացակայող ICMP պատասխանը կարող է հոսթի զտում լինել, ոչ թե թունելի խափանում, ուստի լուռ ping-ը ոչ մի ուղղություն չի ապացուցում։ TCP կապը ձեզ հայտնի բաց պորտին, կամ տվյալներ վերադարձնող հարցումը ձեզ տալիս է պատասխան, որը կարող եք մեկնաբանել։

Հակառակ ուղղությունը վարեք որպես առանձին թեստ՝ սեփական արդյունքով, որովհետև երկու ուղղություններն ունեն առանձին firewall և AllowedIPs գրառումներ և կարող են ձախողվել անկախ։ Եթե ձեռքսեղմումն աշխատում է, իսկ հարցումը՝ ոչ, խնդիրը տվյալների ուղու մեջ է, ոչ թե թունելում՝ AllowedIPs, լսող ծառայությունը կամ հոսթի firewall։ Ուղղեք դա նախքան փոխանցում, NAT կամ DNS ավելացնելը, այլապես կեսօրը կանցկացնեք վրիպազերծելով մի գործառույթ, որն երբեք մեղավոր չի եղել։

Հիմքը որպես հղում պահելը

Պահեք աշխատող տոպոլոգիան և պրոֆիլի աղբյուրը մի տեղում, որտեղից կարող եք վերականգնել, և հեռու պահեք դրանք ցանկացած պանակից, որը համաժամացվում է հրապարակային ծառայության հետ։ Ապա ավելացրեք մեկ գործառույթ միաժամանակ՝ յուրաքանչյուրից հետո կրկնելով սկզբնական հարցումը՝ փոխանցում, NAT, LAN երթուղի և միայն դրանից հետո DNS։ Յուրաքանչյուր հավելում, որը կոտրում է թեստը, այժմ նույնականացվող է, որովհետև ուրիշ ոչինչ չշարժվեց։

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