Տնային WireGuard թունելին պետք է վերադարձի երթուղի LAN-ից
Ձեռքսեղմումը հեշտ մասն է։ Որոշեք աշխատանքի բաժանումը երթուղիչի և դարպասի միջև, պահեք նոթբուքի աղբյուրը անփոփոխ և LAN-ին տվեք վերադարձի երթուղի։
Տուն հասանելիությունը մեկ մասնավոր ծառայություն է, ոչ թե երկրորդ ինտերնետ ելք։ WireGuard-ը ավարտվում է երթուղիչի հետևում գտնվող Linux մեքենայի վրա, երթուղիչը պահպանում է իր ընթացիկ աշխատանքը, իսկ նոթբուքը թունելով ուղարկում է միայն տան նախածանցը։ Որ սարքն է փոխանցում և որը՝ ավարտում, այն որոշումն է, որից բխում է յուրաքանչյուր հաջորդ կանոն։ Սխալվեք այդ բաժանման մեջ, և կվրիպազերծեք NAT, որը երբեք չէիք ուզում ավելացնել։
Որոշեք, թե ով է փոխանցում և ով է ավարտում
Հանրային մուտքը երթուղիչինն է: այն ընդունում է UDP փաթեթը և փոխանցում Linux հոսթին։ Այդ հոսթը տիրապետում է WireGuard լսողին և LAN փոխանցման որոշմանը։ Գործնականում քարտեզագրումը UDP 51820-ը ուղարկում է 192.168.50.10, իսկ հավելվածի սեփական պորտը մնում է փակ։ Դերերի բաժանումը կարճ է պահում ֆայրվոլը։
Գրեք հասցեների պլանը մինչև ինտերֆեյսը ստեղծելը։ Երթուղիչ 192.168.50.1, դարպաս 192.168.50.10, ծառայություն 192.168.50.20, թունել 10.77.0.0/24՝ .1 դարպասով և .2 նոթբուքով։ Թունելի տիրույթը չպետք է համընկնի այն ցանցի հետ, որին նոթբուքն արդեն հասնում է, այլապես նպատակակետերը դառնում են երկիմաստ. Օպերատորի մակարդակի NAT-ը կամ վերևի երթուղիչը կարող է արգելափակել ներգնա հասանելիությունը, և ոչ մի տեղական պորտի փոխանցում դա չի ուղղում։
Փոխանակեք բանալիները, ապա չափեք AllowedIPs-ը
Ստեղծեք առանձին բանալու զույգ յուրաքանչյուր ծայրի համար և տեղափոխեք միայն հանրային բանալիներ ստուգված ուղիով։ Դարպասի peer գրառումը թույլ է տալիս միայն նոթբուքի թունելի աղբյուրը, որովհետև տան LAN-ը գտնվում է դարպասի, ոչ թե նոթբուքի հետևում։ LAN-ը այդ գրառման մեջ դնելը նկարագրում է տոպոլոգիա, որը դուք չեք կառուցել։
[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64
[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32AllowedIPs-ը տան նախածանցն է գումարած դարպասի թունելի հասցեն, երբեք 0.0.0.0/0, որպեսզի սովորական զննարկումը պահպանի իր տեղական ուղին։ Պահեք մեկ կազմաձևի տեր և երբեք մի միացրեք նույն ինտերֆեյսը երկրորդ ցանցային կառավարչին։
Վերադարձի երթուղին այն մասն է, որը մարդիկ բաց թողնում են
Այս ձևավորումը պահպանում է նոթբուքի 10.77.0.2 աղբյուրը՝ դարպասի տեսքով քողարկելու փոխարեն, ուստի տան սարքերը պետք է իմանան, թե ինչպես պատասխանեն դրան։ Ավելացրեք ստատիկ երթուղի տան երթուղիչում 10.77.0.0/24-ի համար՝ 192.168.50.10 հաջորդ ցատկով, և կարդացեք, թե ինչ է wg-quick-ը ածանցում AllowedIPs-ից իր տեղեկանքում։ Առանց այդ երթուղու՝ ավարտված ձեռքսեղմումը գոյակցում է հավելվածի պատասխանների հետ, որոնք երբեք չեն հասնում։
Եթե երթուղիչը չի կարող կրել այդ երթուղին, ընտրեք փաստաթղթավորված վերադարձի ձևավորում։ Իսկ լուռ NAT ավելացնելը փոխում է հենց նոր գրած ձեր աղբյուրի մոդելը։
Թույլատրեք մեկ ծառայություն, ոչ ենթացանցը
Միացրեք IPv4 փոխանցումը դարպասի վրա և առանձին պահեք ֆայրվոլի երեք պարտականություն՝ թույլ տալ WireGuard լսողին, փոխանցել նոթբուքի աղբյուրը միայն 192.168.50.20, և տան ցանցի մնացած մասը փակ թողնել այդ peer-ի համար։ Ինտեգրեք կանոնները արդեն օգտագործվող ֆայրվոլ կառավարչի մեջ՝ այն դատարկելու փոխարեն։ Ամբողջ տան նախածանցի երթուղին դրա ներսում յուրաքանչյուր սարք օգտագործելու թույլտվություն չէ։
Հավելվածի սեփական նույնականացումը և հոսթի ֆայրվոլը առանձին դարպաս են։ Անվանեք այն ծառայությունը, որը թույլատրում է կանոնների հավաքածուն, որպեսզի հաջորդ գնահատողը կարողանա ստուգել այն նախատեսված առաջադրանքի դեմ։
Փորձարկեք դրսից, ապա դուրս բերեք մաքուր
Բարձրացրեք պրոֆիլները իրենց տիրոջ միջոցով, հաստատեք ձեռքսեղմումը, ապա փորձարկեք նախատեսված հավելվածը հաստատված արտաքին ցանցից և ստուգեք պատասխանը։ Փորձեք տնային ծառայություն, որը պետք է մնա մերժված, որովհետև թույլատրող կանոնը անտեսանելի է, քանի դեռ ինչ-որ բան չի օգտագործում այն։ HTTPS-ի համար օգտագործեք վկայագրի անունը և թողեք վավերացումն աշխատի; հում հասցեն մուտքագրելը և նախազգուշացումը շրջանցելը ոչինչ չի ապացուցում ուղու մասին։ PersistentKeepalive-ը ընտրովի է: այն օգնում է NAT-ին կապված peer-ին պարապությունից հետո, բայց դա ոչ բացակայող երթուղի է, ոչ էլ թույլտվության ուղղում։
Դինամիկ հանրային հասցեն պահանջում է DNS թարմացումներ, և նոթբուքը փոփոխությունից հետո պետք է նորից լուծի իր վերջնակետը; նոր DNS գրառումները չեն տեղափոխում կազմաձևված վերջնակետը։ Դուրս բերեք նոթբուքը՝ հեռացնելով նրա peer-ը պահված և ակտիվ կազմաձևից; միայն նոթբուքի պրոֆիլը ջնջելը չի չեղարկում դարպասի լիազորումը։