WireGuard-ը աշխատում է բջջային տվյալներով, բայց ոչ նույն wifi-ով
LAN-ի ներսից դեպի երթուղիչի հանրային հասցե ուղարկված հարցումն անցնում է այլ ուղիով, քան բջջային տվյալներով եկողը։ Փորձեք դրսից, ապա ընտրեք տեղական ուղի։
Թունելը բարձրանում է բջջային տվյալներով, ապա տանը մնում է միացման վիճակում՝ նույն պրոֆիլով, նույն peer բանալիով և առանց միջանկյալ կարգավորման փոփոխության։ Տարբերությունը ճանապարհի մեջ է. LAN-ի ներսից դեպի երթուղիչի հանրային հասցե ուղարկված հարցումը նույն ճամփորդությունը չէ, ինչ ինտերնետից եկող հարցումը։ Տան մուտքային սարքերի մեծ մասը կա՛մ ընդհանրապես չի իրականացնում վերադարձի ուղին, կա՛մ իրականացնում է միայն որոշ արձանագրությունների համար։ Դա ախտանիշը ներկայացնում է որպես կոտրված բանալի, թեև բանալու մեջ ոչինչ չի փոխվել։ Պարզեք, թե որ ուղին է ձախողվել, նախքան բանալուն, պորտի փոխանցմանը կամ հաճախորդի պրոֆիլին դիպչելը։
Մեկ հասցե, երկու տարբեր ուղի
Դրսից փաթեթը հասնում է երթուղիչի հանրային հասցեին, և պորտի փոխանցման կանոնը այն հանձնում է ներքին հոսթում գտնվող WireGuard լսողին։ Ներսից հաճախորդը կանչում է նույն հանրային հասցեն, ուստի փաթեթը հեռանում է հաճախորդից, հասնում երթուղիչին և պետք է հետ շրջվի դեպի LAN։ Հենց այդ հետշրջման վրա են երկու ուղիները բաժանվում, քանի որ երթուղիչը պետք է թարգմանի հոսք, որը միաժամանակ դուրս է գալիս և նորից մտնում նույն ինտերֆեյսով։ Շատ իրականացումներ այն դեն են նետում՝ թարգմանելու փոխարեն, և հաճախորդն այնուհետև սպասում է ձեռքսեղմման, որը երբեք չի ուղարկվել։
Այս վարքագիծը սովորաբար կոչվում է NAT loopback կամ hairpinning, և այն պատկանում է երթուղիչին, ոչ թե WireGuard-ին. RFC 4787-ը ներկայացնում է թարգմանության այն դեպքերը, երբ մուտքը կարող է աջակցել դրան կամ ոչ։ WireGuard-ն ինքը կարծիք չունի ուղու մասին, քանի որ տեսնում է միայն իր ինտերֆեյսին հասնող փաթեթները։ Երբ երթուղիչը դեն է նետում հոսքը, դեմոնը երբեք ոչինչ չի ստանում, հաճախորդը հաղորդում է ձեռքսեղմման ժամկետի ավարտի մասին, և սերվերի մատյանը մնում է դատարկ։ Դատարկ մատյանը, ուստի, նշան է, թե որտեղ է կանգ առել փաթեթը, ոչ թե ապացույց, որ սերվերն ընկել է։ Սա է նաև պատճառը, թե ինչու վերատեղադրումը ոչինչ չի փոխում։
Հակառակն էլ կարևոր է. սերվերի մատյանը, որը ցույց է տալիս ձեռքսեղմման փորձ LAN-ի հասցեից, ապացուցում է, որ փաթեթը հասել է և ուղին կարգին է, ինչը հետաքննությունը տեղափոխում է բանալիների և թույլատրված հասցեների։ Կարդացեք մատյանը նրա համար, ինչ նա ապացուցում է, ոչ թե նրա համար, ինչ դուք հույս ունեիք տեսնել։
Նախ վերարտադրեք, հետո փոխեք
Փորձեք լիազորված արտաքին ցանցից նույն սարքով և նույն պրոֆիլով, ապա կրկնեք փորձը LAN-ի ներսում՝ առանց որևէ բան խմբագրելու։ Դրսում ավարտված ձեռքսեղմումը և ներսում սարքից երբեք չհեռացող հաճախորդը վերարտադրում են վիճակը՝ գուշակելու փոխարեն։ Երկու փորձերն էլ պետք է օգտագործեն նույն պրոֆիլը, հակառակ դեպքում համեմատությունը ոչինչ չի ապացուցում։
Ապա նայեք, թե ինչի է լուծվում վերջնակետի անունը այս սարքի համար։ Հետևյալ երեք հրամանները նաև ցույց են տալիս, թե որ հասցեն է հաճախորդն իրականում կանչել.
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netԱռաջին հրամանը հաղորդում է վերջնակետը, որն ինտերֆեյսը հիմա օգտագործում է, իսկ մյուս երկուսը ցույց են տալիս, թե ինչի է անունը լուծվում այս մեքենայում։ Հաճախորդը, որը կանչում է հանրային հասցե՝ գտնվելով սերվերի նույն ցանցում, օգտագործում է hairpin ուղին։ Հաճախորդը, որը կանչում է LAN-ի հասցեն, դա չի անում, և այնտեղի խափանումը պատկանում է այլ հետաքննության։ Այդ տարբերությունը որոշում է՝ արդյոք հաջորդ բաժինն ընդհանրապես կիրառելի է։
Մոտակա սերվերին հասնելու աջակցվող եղանակներ
Ամենամաքուր դասավորությունը հորիզոնի բաժանված պատասխանն է. հանրային անունը ինտերնետի համար լուծվում է հանրային հասցեի, իսկ ներսի հաճախորդների համար՝ սերվերի LAN հասցեի։ Պրոֆիլը պահում է մեկ վերջնակետի անուն, և լուծիչն ընտրում է ուղին։ Դա պահանջում է ներքին DNS պատասխանի վերահսկողություն, որը տան երթուղիչը սովորաբար առաջարկում է, և կազմակերպությունը կարող է դիտավորյալ կարգավորել։ Այդ վերահսկողությունից զուրկ մնում են երթուղիչի ֆունկցիան կամ երկրորդ պրոֆիլը։
Երթուղիչի ֆունկցիան արտացոլումն է. մուտքը թարգմանում է հոսքը ներսից դուրս և հետ ուղարկում ներս։ Որտեղ այն աշխատում է, հաճախորդի փոփոխություն պետք չէ, իսկ որտեղ չի աշխատում, ոչ մի հաճախորդի կարգավորում այն չի փրկի։ Փորձարկեք այն՝ ներքին փորձի ընթացքում դիտելով սերվերի մատյանը, փոխարենը երթուղիչի ֆունկցիաների ցանկը կարդալու։
Պրոֆիլը մասնավոր հասցեի վերափոխելը ախտորոշում է, ոչ թե նախագիծ։ Այն ապացուցում է, որ սերվերը պատասխանում է LAN-ում, և կոտրում է նույն պրոֆիլը այն պահին, երբ նոթբուքը հեռանում է տնից։
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Պրոֆիլը պահեք օգտագործելի տնից դուրս
Ինչ ուղի էլ ընտրեք, ինքնության ստուգումը հանգիստ թողեք։ Վերջնակետի հասցեն peer-ի ինքնությունը չէ, և հասցեի փոփոխությունը երբեք չի արդարացնում օտար հանրային բանալու ընդունումը, որը պատահաբար պատասխանում է։ WireGuard-ը նույնականացնում է բանալիով, ուստի սխալ հոսթը ձախողվում է ձեռքսեղմման վրա՝ անսպասելի բանի հասանելիություն տալու փոխարեն։
Եթե հանրային հասցեն տեղափոխվում է, դինամիկ DNS-ն է, որ անունը պահում է օգտակար, և հաճախորդի թարմացման վարքագիծը որոշում է, թե որքան արագ կհասնի փոփոխությունը։ Փորձեք դա դրսից հասցեի փոփոխությունից հետո, որովհետև LAN-ի դեպքը չի կարող հաստատել այն։ Ուշադրություն դարձրեք լուծիչին, որը հին պատասխանը պահում է գրանցման կյանքից ավելի երկար։ Անունը, որը դեռ ցույց է տալիս նախորդ հասցեին, ուղիղ նման է ընկած սերվերի։
Գրեք, թե որ անունն է օգտագործում պրոֆիլը և ինչի է այն լուծվում սահմանի յուրաքանչյուր կողմում։ Պրոֆիլը, որը կախված է երթուղիչի ֆունկցիայից, որը ոչ ոք չի գրանցել, աջակցության զանգ է, որը սպասում է հաջորդ որոնվածի թարմացմանը։ Գրառումը նաև ասում է հաջորդ մարդուն՝ արդյոք ներքին խափանումը հայտնի hairpin դեպքն է, թե նոր բան։