Մեկ հավելված WireGuard-ի միջով՝ կապումը երթուղավորում չէ

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

Մեխանիզմն ունի երկու կես՝ երթուղավորման աղյուսակ, որը պետք է օգտագործի միայն թունելի երթևեկությունը, և կանոն, որը համապատասխան աղբյուրը ուղարկում է այնտեղ։

Կապումը սահմանում է աղբյուրի հասցե և ոչ ավելին

Linux-ը ընտրում է ելքային միջերեսը՝ նպատակակետը երթուղավորման աղյուսակում փնտրելով, այն բանից հետո, երբ քաղաքականության կանոնները հնարավորություն ունեցան վերաուղղորդել այդ որոնումը։ Կանոնները կարող են ընտրել ըստ աղբյուրի հասցեի, firewall-ի նշանի, մուտքային միջերեսի, UID-ի կամ նույնիսկ պորտի՝ դրանցից յուրաքանչյուրը այս երթևեկը ամբողջի փոխարեն ասելու այլ ձև է։ VPN հաճախորդի կարգավորումն ընտրում է այն աղյուսակը, որը պարունակում է թունելի երթուղիները՝ կանոնն ընտրում է, թե որ երթևեկին է թույլատրվում դիմել դրան։ Միայն կապումը ոչ մեկը չի տալիս։

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

Տվեք թունելին իր սեփական աղյուսակը

wg-quick-ը տեղադրում է երթուղիները այնտեղ, որտեղ ասում է պրոֆիլը։ [Interface]-ի տակ Table = 40 ավելացնելը դրանք տեղափոխում է 40 աղյուսակ՝ հիմնականի փոխարեն։ Բարձրացրեք միջերեսը և հաստատեք, որ դրանք հասել են՝ ip -4 route ls table 40-ը պետք է ցույց տա թունելի երթուղիները, իսկ ip -4 route get 10.66.127.142-ը ցույց է տալիս, թե ինչպես է միջուկը հիմա լուծում դրանցից մեկը։ Երթուղիները սեփական աղյուսակում լինելով՝ հիմնական աղյուսակը շարունակում է աշխատել մնացած ամեն ինչի համար։

Նույնն արեք IPv6-ի համար՝ լայն նախածանց համադրելու փոխարեն։ ip -6 rule add from fd00::2/128 lookup 40-ը ամրացնում է մեկ հասցե՝ fc00::/8-ը կարող է բախվել հոսթի այլ միջերեսների հետ և ստեղծել կանոն, որը համապատասխանում է նախատեսվածից ավելիին։

Ավելացրեք աղբյուրի կանոնը և դիտեք հաշվիչները

Ապա միացրեք երկու կեսերը՝ ip -4 rule add from 10.66.127.142/32 lookup 40, նույն հասցեով կցված WireGuard-ի միջերեսին։ Երկու կանոններն էլ դրեք PostUp-ի մեջ, որ վերակապակցումը վերականգնի դրանք։ Ստուգեք իրական հարցումով, ոչ թե կարգավորմամբ՝ ip route get 1.1.1.1 from 10.66.127.142-ը պետք է նշի թունելի սարքը, իսկ curl --interface wg0 ifconfig.me-ը պետք է հաղորդի թունելի հասցեն՝ տան հասցեի փոխարեն։

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

Հակառակ դեպքը՝ պահեք SSH-ը թունելից դուրս

Հակառակ խնդիրը նույնքան տարածված է՝ wg-quick-ը տիրապետում է լռելյայն երթուղուն, և սերվերի հետ SSH նստաշրջանը մահանում է կեսին։ Նրա կանոնները նստում են ցածր առաջնահերթության համարի վրա, ուստի բացառությունը պետք է գնահատվի նրանցից շուտ։ ip rule add dport 22 ipproto tcp table main priority 123-ը դա անում է նոր iproute2-ում՝ որտեղ ընտրիչը հասանելի չէ, նշեք հոսքը nftables-ում և փոխարենը համադրեք նշանը։

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

Գրանցեք աղյուսակի համարը, աղբյուրի կանոնը և բացառությունը հենց պրոֆիլում։ Բոլոր երեքը պատկանում են մեկ ձևավորման և կխմբագրվեն միասին։