Ներդրված WireGuard՝ մեջտեղի թռիչքը չի կարող պատասխանել իր սեփական պորտին
Երբ մեջտեղի թռիչքը ամեն ինչ ուղարկում է մեկ թունել, իր մուտքային ծառայության պատասխանները դուրս են գալիս սխալ ճանապարհով։ Ինտերֆեյսի աղբյուր-պորտի կանոնը շտկում է դա։
Երեք WireGuard թռիչք հասնում են ցանց, որը հանրային հասցե չունի, և այնուհետև մեջտեղի մեքենան դադարում է պատասխանել այն պորտին, որի վրա պետք է լսեր։ Թունելը դեպի առաջ դեռ աշխատում է, հեռավոր հոսթը դեռ պատասխանում է, և միայն մեջտեղի սերվերն է լռել դրսից։ Այդ համադրությունը շփոթեցնող է հենց այն պատճառով, որ ինքն իրեն է ստեղծել՝ մեջտեղի թռիչքը ենթարկվում է իր իսկ երթուղավորման աղյուսակին, և աղյուսակն ուղարկում է նրա պատասխանները սխալ ուղղությամբ։
Շղթա, որն աշխատում է, մինչև չխոսես մեջտեղի արկղի հետ
Վերցրեք պատկերավոր շղթա՝ հաճախորդ A-ն հասնում է B սերվերին UDP 500-ով, և B-ն առաջ է գնում դեպի C սերվեր UDP 500-ով։ C-ն երթևեկություն ընդունում է միայն իր միակ գործընկերոջ հասցեից, ինչը նրան դարձնում է տերև և պահում նրա վարքը պարզ։ B-ն տերև չէ, և այս խափանման մեջ ամեն հետաքրքիրը հենց այնտեղ է տեղի ունենում։
Տարբերությունը կարևոր է, որովհետև տերևի և մեջտեղի դերերը քաշում են հակառակ ուղղություններով։ Տերևը կարող է ամեն ինչ ուղարկել մեկ թունել առանց հետևանքի, քանի որ իրենից ուրիշ ոչինչ կախված չէ։ Մեջտեղի թռիչքը միաժամանակ հաճախորդների վերջնակետ է և հաճախորդ դեպի հեռավոր կողմը, և այդ երկու աշխատանքները տարբեր երթուղավորում են ուզում։
Ինչու է պատասխանը դուրս գալիս թունելով
B-ի վրա C-ին ուղղված ինտերֆեյսը կրում է AllowedIPs = 0.0.0.0/0՝ համապատասխան լռելյայն երթուղու հետ միասին։ Այդ պատճառով B-ի ստեղծած յուրաքանչյուր փաթեթ մտնում է այդ թունել, եթե ավելի կոնկրետ բան նախապատվություն չստանա։
A-ից B-ին հասցեագրված փաթեթը գալիս է և ընդունվում է, որովհետև B-ն նպատակակետն է, և տեղական հանձնումը տեղի է ունենում առաջինը։ Պատասխանը տեղում ստեղծված բոլորովին նոր փաթեթ է՝ ուղղված A-ի հանրային հասցեին, և այդ նպատակակետը համապատասխանում է թունելի լռելյայն երթուղուն։ C-ն ստանում է այն, չի տիրապետում այդ հասցեին և գցում է այն։
Ախտանիշը կարդացվում է որպես հրային պատի խնդիր կամ բանալու անհամապատասխանություն, և այստեղ ոչ մեկը ճիշտ չէ։ C-ի ուղղությամբ թունելի վրա արված գրավումը ցույց է տալիս, որ պատասխանները գնում են սխալ ուղղությամբ։ Այդ մեկ դիտարկումը խնայում է ավելի շատ ժամանակ, քան կոնֆիգուրացիա կարդալու ցանկացած քանակությունը, ուստի գրի առեք այն նախքան բանալիները փոխելը։ Ով չի տեսել գրավումը, կենթադրի, որ թունելն ինքն է կոտրված։
Նեղ վերանորոգումը՝ աղբյուր-պորտին համապատասխանող քաղաքականության կանոններ
B-ի լսող սոկետից պատասխանները դուրս են գալիս աղբյուր-պորտ 500-ով։ Քաղաքականության կանոնը կարող է համապատասխանել դրան և այդ փաթեթները վերադարձնել սովորական աղյուսակ:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Քաղաքականության կանոնները դիտվում են առաջնահերթության կարգով, և հիմնական աղյուսակը գտնվում է 32766-ում, ուստի 100-ի կանոնը հարցվում է նախքան թունելի լռելյայն երթուղին խոսելը։ Ավելացրեք մեկ գրառում յուրաքանչյուր պորտի համար, որը պետք է հասանելի մնա դրսից, և ոչ ավելին, որպեսզի փոխանցվող երթևեկությունը շարունակի օգտագործել այն թունելը, որի համար կառուցվել է։
Իմացեք այս հնարքի սահմանը։ sport ընտրիչը համապատասխանում է տեղում ստեղծված փաթեթներին, ինչը ծածկում է հենց պատասխանի դեպքը և դիտմամբ չի ծածկում այն երթևեկությունը, որը B-ն ուղղակի փոխանցում է մեկ ուրիշի փոխարեն։ B-ի հետևում տեղակայված ծառայությունը դեռ պետք է իր պատասխանը, և հակառակի ձևացումը տալիս է լուծում, որն աշխատում է առաջին ծառայության համար և ձախողվում երկրորդի համար։
Տվեք կանոնին տեր
Հուշող տողում մուտքագրված կանոնը անհետանում է հաջորդ անգամ, երբ ինտերֆեյսը վերակառուցվի։ WireGuard-ի կարգավորման մեջ դրեք այն այնտեղ, որտեղ ինտերֆեյսը ստեղծվում և հեռացվում է:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Եթե ինտերֆեյսը պատկանում է NetworkManager-ին, տարածման կեռիկին կամ կոնտեյների մուտքի կետին, զույգը պատկանում է այդ տիրոջը, ոչ թե ձեռքով խմբագրված ֆայլին։ Ստուգեք գործող կանոնները վերամիացումից հետո, ոչ միայն առաջին մեկնարկից հետո, որովհետև առաջին մեկնարկը այն դեպքն է, որը միշտ աշխատում է։
Համեմատեք այլընտրանքները ազնվորեն
Աղբյուր-պորտի կանոնը չորս ելքերից մեկն է և դրանցից ամենանեղը։ Այն ունի այն առավելությունը, որ բացարձակապես չի դիպչում թունելի քաղաքականությանը, և դրա համար է, որ սովորաբար գոյատևում է հետագա փոփոխություններից։ Նեղ վերանորոգումները նաև բարձրաձայն ձախողվում են, երբ դադարում են կիրառվել, մինչդեռ լայն բացառությունը շարունակում է լուռ աշխատել այն պատճառի անհետանալուց շատ ավելի ուշ։ Այդ տարբերությունը ավելի կարևոր է, քան նրբագեղությունը, երբ երկու տարի անց արկղը պատկանում է ուրիշի։
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Ստուգեք երկու ծայրերից այն բանից հետո, երբ ընտրել եք։ A-ից սկսեք կապ B-ի պորտին և որոշ ժամանակ զբաղեցրած պահեք այն։ B-ի վրա ստիպեք միջուկին հիմնավորել պատասխանի ճանապարհը ինչ-որ բանով, ինչպիսին է ip route get <address-of-A> sport 500, և հաստատեք, որ այն նշում է WAN ինտերֆեյսը, այլ ոչ թե թունելը։ Դրանից հետո ստուգեք, որ C-ի հետևում ինչ-որ բան դեռ պատասխանում է շղթայի միջոցով, ինչը ապացուցում է, որ բացառությունը մնաց նեղ և չվերածվեց շրջանցման։ Վերջապես, գրանցեք պորտերը դիզայնի նշումներում, այլապես հաջորդ օպերատորը նորից կհայտնաբերի դա այլ ծառայության վրա։