Երկրորդ ենթացանցի ավելացումը կայք-կայք VPN-ին՝ երկու ուղի
Քաղաքականության վրա հիմնված թունելները պահանջում են համապատասխան ընտրիչներ երկու կողմերում; երթուղու վրա հիմնվածները՝ երթուղի։ Ընտրեք ճիշտ ուղին և նախ ուղղեք վերադարձի երթուղին։
Աշխատող կայք-կայք թունելին երկրորդ ենթացանց ավելացնելը մեկ նախագծում տևում է հինգ րոպե, մյուսում՝ գրեթե ամբողջ կեսօրը։ Երբ թունելը երթուղիներ է տեղադրում ձեր նշած նախածանցերի համար, դուք ավելացնում եք երթուղի, և երթևեկությունը հետևում է դրան։ Երբ այն բանակցում է մեկ հաստատուն ընտրիչ զույգի շուրջ, նոր նախածանցը մնում է անպաշտպան, քանի դեռ երկու կողմերը չեն համաձայնել համապատասխան զույգի շուրջ։ Երեք բան է որոշում՝ ինչ է իրականում նկարագրում յուրաքանչյուր կողմի կազմաձևը, արդյոք բանակցված երթևեկությունը նեղանում է մինչև ամենափոքր համապատասխան զույգը, և ումն է նոր տիրույթի վերադարձի ուղին։
Կարդացեք միջուկը, ոչ թե կարգավիճակի պիտակը
Կապի մասին հաղորդող թունելը տեղադրել է առնվազն մեկ զավակ ասոցիացիա, բայց ոչ պարտադիր այն, ինչ դուք եք մտածում։ Linux-ում միջուկը ցույց է տալիս, թե ինչ է կիրառվում՝ ip xfrm policy թվարկում է ընտրիչ զույգերը, իսկ swanctl --list-sas (կամ հին ipsec statusall) ցույց է տալիս, թե ինչի շուրջ են պայմանավորվել կողմերը՝ ներառյալ երթևեկության ընտրիչները յուրաքանչյուր ուղղությամբ։ Եթե նոր նախածանցը ոչ մեկում չկա, այն անպաշտպան է, ինչ էլ ասի կազմաձևի ֆայլը։
Համեմատեք երթուղիների աղյուսակի հետ։ Երթուղու վրա հիմնված կարգավորման դեպքում թունելի սարքը պաշտպանված նախածանցերի հաջորդ ցատկն է։ Քաղաքականության վրա հիմնված կարգավորումը հաճախ հեռավոր ենթացանցի համար առանձին երթուղի չունի, միայն լռելյայն երթուղին, որովհետև երթևեկությունն ընտրում է քաղաքականությունը, ոչ աղյուսակը։
Քաղաքականության վրա հիմնված թունելներ. երկու կողմերն էլ պետք է թվարկեն նոր նախածանցը
strongSwan-ի տերմիններով ընտրիչը գտնվում է զավակ կազմաձևի local_ts և remote_ts դաշտերում՝ leftsubnet-ի և rightsubnet-ի հաջորդներում։ Նոր նախածանցը պետք է հայտնվի երկու կողմերում հայելային՝ այն, ինչ A կայքը կոչում է տեղական, B կայքը կոչում է հեռավոր։ Անհամապատասխանությունը հազվադեպ է մաքուր սխալ տալիս։ Կողմերը նեղանում են մինչև հատումը, հին նախածանցը շարունակում է աշխատել, և միայն նորը լուռ ձախողվում է։
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense-ում կամ OPNsense-ում դա նշանակում է երկրորդ Phase 2 գրառում, որը զուգակցում է նոր տեղական ենթացանցը նոր հեռավորի հետ, ապա կիրառում։ Պահեք հին գրառումը. փոխարինելը տեղափոխում է սկզբնական ենթացանցը՝ ավելացնելու փոխարեն։ Եթե գոյություն ունեցող Phase 2-ն արդեն ծածկում է 0.0.0.0/0-ի նման գերգանց կամ ամփոփված տիրույթ, մի ավելացրեք ավելի նեղ գրառում կողքին. համընկնող ընտրիչները տեղադրում են մրցակցող քաղաքականություններ, և գնահատման կարգը որոշում է հաղթողին։
IKEv1-ը յուրաքանչյուր ենթացանց զույգ դարձնում է իր Phase 2-ը, և մեկ զույգ փոխանակման համար վերցնող կողմը մերժում է մնացածը։ IKEv2-ը կարող է մեկ զավակում կրել մի քանի ընտրիչ զույգ, բայց միայն եթե երկու իրականացումներն էլ ընդունեն դրանք։ swanctl --list-sas-ից ստացված ցանկը ճշմարտությունն է. ինչ դուք մուտքագրել եք, հարցում է։
Երթուղու վրա հիմնված թունելներ. երթուղին քաղաքականությունն է
XFRM միջերեսը կամ VTI սարքը երթևեկությունը կրում է երթուղիների աղյուսակի համաձայն։ Դուք նոր նախածանցն ուղղում եք սարքին երկու կայքերում, և կիրառվում է միջերեսի ձևափոխությանը կապված վիճակը։ Համաժամեցնելու ընտրիչ զույգ չկա, դրա համար այս նախագիծն ավելի լավ է մասշտաբավորվում ենթացանցերի աճի հետ։ strongSwan-ի փոխանցման ուղեցույցը մանրամասնում է միջուկի կողմը։
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard-ը գնում է ավելի հեռու։ AllowedIPs-ը միաժամանակ կրիպտոգրաֆիկ թույլատրելի ցանկն է և, wg-quick-ի միջոցով, երթուղիների աղյուսակի գրառումը։ Ավելացրեք նախածանցը միայն մեկ կողմում և կստանաք ձեռքսեղմում, ելքային փաթեթներ և լռություն, որովհետև հեռավոր կողմը մերժում է փաթեթները, որոնց աղբյուրը իր ցանկում չէ։ wg set ձևը փոխարինում է ամբողջ ցանկը, ուստի կրկնեք արդեն աշխատած նախածանցերը, այլապես կկտրեք դրանք։
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Այդ երկրորդ հրամանը պարտադիր է, երբ wg-quick-ի փոխարեն օգտագործել եք wg set։ Միջուկը նոր ցանկն անմիջապես ընդունում է, բայց ոչինչ դրա համար երթուղի չի ավելացնում, ուստի տեղական ստեղծված երթևեկությունը դեռ դուրս է գալիս լռելյայն դարպասով։ Սա ամենատարածված պատճառն է, թե ինչու նոր WireGuard ենթացանցը աշխատում է թունելի հոսթից, ոչ՝ նոթբուքից։
Վերադարձի ուղին ավելի հաճախ է ձախողվում, քան թունելը
Նոր հեռավոր ենթացանցի հոսթերը պատասխանները պետք է հետ ուղարկեն VPN դարպասով։ Երբ այդ դարպասը նրանց լռելյայն երթուղիչը չէ, պատասխանը գնում է LAN երթուղիչին, որը կա՛մ մերժում է այն, կա՛մ փոխանցում է ինտերնետ՝ մասնավոր աղբյուրի հասցեով։ Փորձարկեք հեռավոր կողմի հոսթից, ոչ դարպասից. ip route get 10.30.20.15 Linux-ում կամ Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShell-ում ցույց է տալիս հաջորդ ցատկը, որն իսկապես կօգտագործի հոսթը։ Եթե պատասխանը թունելի վերջնակետը չէ, այնտեղ ավելացրեք ստատիկ երթուղի նոր նախածանցի համար։
Աղբյուրի NAT-ը այն կայքում, որտեղ վերադարձի երթուղի չկա, օրինական այլընտրանք է, և շատ hub-and-spoke տեղակայումներ այդպես խուսափում են յուրաքանչյուր սերվերի դիպչելուց։ Կիրառեք այն նաև նոր նախածանցի վրա նպատակակետի կողմի դարպասում։
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEԳինը իրական է։ Հեռավոր մատյանները դադարում են ցույց տալ առանձին աղբյուրի հասցեներ, և սկզբնական ենթացանցի վրա հիմնված հրապարակային պատի կանոնները միաձուլվում են դարպասի համար մեկ կանոնի։ Ընտրեք դա գիտակցաբար, ոչ այն պատճառով, որ երթուղի էր պակասում։
Հրապարակային պատերը վերադարձի ուղու մյուս կեսն են։ Գոտու վրա հիմնված սարքերը ինքնաշխատ չեն տարածում գոյություն ունեցող թունելի միջերեսի գոտին նոր ենթացանցի վրա, և հին նախածանցի համար գրված կանոնը չի համապատասխանի։ Ավելացրեք նոր ենթացանցը գոտուն կամ կանոնների զույգին երկու ուղղությամբ, նախքան IPsec-ին մեղադրելը։
Որոշեք երեք հարցով, ապա ստուգեք երթևեկությամբ
Կարճ տարբերակը. կողմի կազմաձևը նշո՞ւմ է նախածանցներ (քաղաքականության վրա հիմնված), թե՞ երթևեկությունը երթուղվում է միջերես (երթուղու վրա հիմնված)։ Երկու ծայրերն էլ թվարկո՞ւմ են նոր նախածանցը։ Կա՞ վերադարձի ուղի նոր ենթացանցից դեպի սկզբնական աղբյուրի տիրույթ։
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Ստուգումը այն տեղն է, որտեղ փոփոխությունների մեծ մասը շատ շուտ է փակվում։ Դարպասից ping-ը քիչ բան է ապացուցում, որովհետև դարպասն ինքն իրենից է ուղարկում և հաճախ համընկնում է հոսթից տարբեր քաղաքականության։ Ping արեք նոր ենթացանցի հոսթից, ապա գործարկեք փոփոխությունը հարուցած ծրագիրը և դիտեք հաշվիչները, ոչ կարգավիճակի պատկերակը։
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showՔաղաքականության վրա հիմնված թունելում ip xfrm state-ի հաշվիչները պետք է աճեն երկու ուղղությամբ. հարթ հաշվիչները նշանակում են, որ փաթեթը երթուղվում է, բայց ընտրված չէ։ WireGuard-ում wg show-ը հաղորդում է փոխանցումը յուրաքանչյուր կողմի համար, և զրո ստացված բայթով ձեռքսեղմումը մատնանշում է հեռավոր կողմի ցանկը կամ նրա վերադարձի երթուղին։
Ավարտեք՝ գրանցելով նախածանցը, կողմի ընտրիչը կամ երթուղին, վերադարձի ուղու որոշումը և հրապարակային պատի գրառումը թունելի մնացած գույքագրման հետ միասին։ Ապա վերագործարկեք մեկ դարպաս և նորից փորձարկեք. ձեռքով ավելացված երթուղին անհետանում է, և հաջորդ մարդը պետք չէ նորից հայտնաբերել դա։