Ինչպես VPN-ով ուղարկել ընդամենը մեկ մասնավոր ենթացանց

Մեկ մասնավոր ենթացանց թունելով, իսկ մնացած ամեն ինչ ձեր սովորական ուղով անցկացնելը փոքր հարցում է՝ սխալվելու շատ եղանակներով։ Արդյունքը որոշում է ոչ թե split tunneling պիտակով վանդակը, այլ այն, թե որտեղ է կիրառվում որոշումը՝ հենց պատվիրատուի երթուղիների աղյուսակում, սերվերի ուղարկած երթուղում, թե երկու կողմերի բանակցած քաղաքականության մեջ։ Ընտրեք սխալ շերտը և կստանաք կամ ամբողջական թունել, որը երբեք չէիք ուզում, կամ երթուղի դեպի թունել, որը մյուս կողմը հրաժարվում է ընդունել։ Ցանկացած կարգավորում բացելուց առաջ ես օգտագործում եմ երեք պայմանի փորձարկում, ապա ընտրում ներքևի մեխանիզմներից մեկը։

Երեք պայման, որոնք որոշում են նախագիծը

Առաջին՝ ձեզ պետք է ճշգրիտ նախածանցը և դիմակը ցանցի սեփականատիրոջից։ 10.x ցանցը նախածանց չէ, նախածանց է 10.20.0.0/16։ Համոզվեք, որ այն չի համընկնում ձեր տնային LAN-ի, Docker կամրջի կամ ձեր գործարկած մեկ այլ VPN-ի հետ, որովհետև համընկնումը երթուղին դարձնում է երկիմաստ, և միջուկն ընտրում է այն գրառումը, որը դուք չէիք նկատի ունեցել։

Երկրորդ՝ ով է պատասխանում վերադարձող երթևեկությանը։ Փաթեթը թունել ուղղելը այն հասցնում է միայն VPN սերվերին։ Եթե ենթացանցը գտնվում է մեկ այլ երթուղիչի հետևում, որը վերադարձի երթուղի չունի դեպի ձեր պատվիրատուների լողավազանը, սերվերը պետք է քողարկի երթևեկությունը, կամ այդ երթուղիչը պետք է սովորի ձեր լողավազանը։ Ոչ մի պատվիրատուի կողմի երթուղի չի շտկում բացակայող վերադարձի ուղին։

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

WireGuard. AllowedIPs-ը երթուղիների աղյուսակն է

Պատվիրատուի վրա AllowedIPs թվարկում է այն նպատակակետերը, որոնք կարող են մտնել թունել, իսկ wg-quick յուրաքանչյուր գրառում դարձնում է սովորական երթուղի։ Այսպիսով, այս առաջադրանքի պատվիրատուի կեսը մեկ տող է։

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Այժմ համեմատեք սերվերի գրառումը նույն պատվիրատուի համար։ Այն նկարագրում է, թե ինչ կուղարկի սերվերը պատվիրատուին, և դա սովորաբար պատվիրատուի թունելի հասցեն է, ոչ թե մասնավոր ենթացանցը։

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Այս երկուսի փոխանակումը ամենահաճախ հանդիպող սխալն է։ 10.20.0.0/16-ը սերվերի peer բաժնի տակ դնելը հայտարարում է, որ ամբողջ ենթացանցը գտնվում է այդ պատվիրատուի հետևում, և դա տեղից տեղ պահանջ է, ոչ թե թույլտվություն։ Ոչ մի peer-ի AllowedIPs-ին չհամապատասխանող փաթեթներ լուռ դեն են նետվում, ուստի սխալ գրառումը ճիշտ նման է հրապատի խնդրի։

Եթե երթուղիները ինքներդ եք կառավարում, սահմանեք Table = off-ը [Interface]-ի տակ և ավելացրեք ցանկալի երթուղին։ Այդ դեպքում ոչինչ ինքնաբերաբար չի ավելանում, ուստի երթուղին պատկանում է նրան, ինչը բարձրացնում է ինտերֆեյսը։

OpenVPN. ուղարկեք երթուղին, ապա համոզվեք, որ այն հասնում է

Սովորական սերվերի վրա փոփոխությունը սերվերի կարգավորումների մեկ հրահանգ է՝ պատվիրատուների լողավազանի կողքին։

push "route 10.20.0.0 255.255.0.0"

Պատվիրատուն ավելացնում է այն միանալիս։ Խափանման ռեժիմը ի հայտ է գալիս, երբ նույն պրոֆիլը նաև ուղարկում է redirect-gateway, կամ երբ ինչ-որ մեկն արդեն ավելացրել է route-nopull-ը՝ առաջինը միացումը դարձնում է ամբողջական թունել, իսկ երկրորդը դեն է նետում ուղարկված բոլոր երթուղիները, ներառյալ ձերը։

Ամբողջական թունելով սերվերի դեմ նեղ վարքագիծ պահանջող պատվիրատուն պետք է անտեսի միայն այն մասերը, որոնք չի ուզում։ OpenVPN 2.4 և ավելի նոր տարբերակներում pull-filter-ը հենց դրա համար է։

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Առանձին պահեք հասցեների ընտանիքները՝ ուղարկված IPv4 երթուղին ոչինչ չի անում ներքին ծառայության համար, որը լուծվում է IPv6-ի, և այդ ծառայությունը ձախողվում է թունելով, մինչ մնացած ամեն ինչ կարգին է թվում։

Երբ մասնավոր ենթացանցը VPN սերվերի վրա չէ, այլ մեկ այլ պատվիրատուի հետևում, սերվերին պետք է տեղյակ պահել։ client-config-dir-ի միջոցով ավելացրեք ֆայլ յուրաքանչյուր պատվիրատուի համար, որը պարունակում է iroute 10.20.0.0 255.255.0.0, գումարած համապատասխան route-ը, որպեսզի մյուս պատվիրատուները սովորեն ուղին։ Առանց iroute-ի սերվերը ոչ մի պատճառ չունի այդ նախածանցը հենց այդ թունելով ուղարկելու։

IPsec. երթևեկության ընտրիչները պետք է համաձայնեն

IPsec-ի դեպքում ուղարկելու երթուղի չկա։ Երկու կողմերը բանակցում են, թե որ հասցեներն են թունելի ներսում, և համաձայնված ընտրիչներից դուրս երթևեկությունը ոչ գաղտնագրվում է, ոչ էլ անցնում դրա միջով։ strongSwan պատվիրատուի վրա ընտրիչները բացահայտ են։

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Եթե դարպասը երկու կողմերում էլ կարգավորված է 0.0.0.0/0-ով, IKEv2-ի նեղացումը սովորաբար երեխա SA-ն իջեցնում է երկու առաջարկների հատմանը, ինչը ցանկալի արդյունքն է։ Որոշ դարպասներ փոխարենը մերժում են իրենց կարգավորված ընտրիչներին չհամապատասխանող առաջարկը, և մատյանն այդ դեպքում ցույց է տալիս ձախողված երեխա SA, ոչ թե երթուղային բողոք։ Երբ դա տեղի է ունենում, փոփոխությունը դարպասինն է, որովհետև պատվիրատուի երթուղին չի կարող թունել ստեղծել այն ընտրիչի համար, որը մյուս կողմը չի ընդունի։

Windows-ում ներկառուցված պատվիրատուն նույն որոշումը թաքցնում է երկու կարգավորումների հետևում։ Թունելի բաժանումը պետք է միացված լինի, և նախածանցը պետք է գրանցվի պրոֆիլում։

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Հենց նախածանցի գրանցումն է այն, ինչը թույլ է տալիս նրան վերապրել վերամիացումը, ինչը ձեռքով ավելացված երթուղին չի անում։

Վերջնակետը և DNS-ը պահեք որոշումից դուրս

VPN վերջնակետը պետք է հասանելի մնա առանց թունելի, այլապես թունելը փլուզվում է ինքն իր մեջ։ Երբ երթուղվում է միայն 10.20.0.0/16-ը, դա ինքնաբերաբար է, քանի որ վերջնակետը հանրային հասցե է։ Ամբողջական թունելի պրոֆիլում դա այդպես չէ, և պատվիրատուին անհրաժեշտ է բացահայտ հոսթի երթուղի դեպի վերջնակետ, մինչև թունելը բարձրանա։

DNS-ը երկրորդ որոշումն է, որը երթուղու ուղարկումը ձեր փոխարեն չի կայացնում։ Ներքին անունները սովորաբար լուծվում են լուծիչի միջոցով, որին հասնում է միայն մասնավոր ցանցը։ Եթե սերվերն ուղարկում է DNS սերվեր, ամեն անուն անցնում է դրա միջով, իսկ եթե ոչ՝ ներքին անունները կա՛մ ձախողվում են, կա՛մ հրապարակայնորեն լուծվում ինչ-որ բանի, որը դուք չէիք նկատի ունեցել։ Բաժանված DNS-ը պահում է մեկ որոնման տիրույթ ներքին լուծիչի վրա, բայց դա կախված է պատվիրատուի աջակցությունից, ուստի վերաբերվեք դրան որպես առանձին առաջադրանք, ոչ թե երթուղման կողմնակի ազդեցություն։

Ստուգեք, ապա վերագործարկեք և նորից ստուգեք

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Առաջին տողը նշում է ինտերֆեյս։ Եթե այն նշում է ձեր ֆիզիկական ինտերֆեյսը, երթուղին երբեք չի հասել։ Windows-ում Find-NetRoute -RemoteIPAddress 10.20.5.7-ը պատասխանում է նույն հարցին, և վերջին փորձարկումը պետք է դեռ ցույց տա ձեր սովորական հասցեն, ոչ թե VPN սերվերի։

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

Նախքան այն ավարտված անվանելը հաստատեք չորս բան՝ նախածանցը եկել է ցանցի սեփականատիրոջից և չի համընկնում ոչ մի տեղական բանի հետ, վերադարձի ուղին գոյություն ունի կամ այն փոխարինում է քողարկման կանոն, ձեր կարգավորած մեխանիզմն է, որ կիրառում է երթուղումը ձեր հարթակում, և նույն փորձարկումները անցնում են մաքուր վերագործարկումից հետո։ strongSwan-ի փոխանցման նշումները արժե կարդալ, եթե վերադարձի ուղին է այն մասը, որը շարունակ ձախողվում է։