Ինչու՞ է երկրորդ VPN թունելը կոտրում առաջինը։

Երկրորդ VPN հաճախորդ տեղադրելը մեկ հաճախորդի ցանց հասնելու համար այս ամենի սկսվելու սովորական եղանակն է, և առաջին թունելը մթնում է, մինչ երկու հաճախորդներն էլ հաջողություն են հաղորդում։ Յուրաքանչյուր հաճախորդ տեղադրել է լռելյայն երթուղի, երկրորդն ավելի կոնկրետ էր, և միջուկն այժմ հետևում է դրան ամեն ինչի համար, բացի առաջին թունելի սեփական արտաքին կապից։ Ոչինչ չի ընկել, և ոչ մի պրոֆիլ սխալ չէ։ Մեկ երթուղին փոխարինել է մյուսին, և լուծումը որոշելն է, թե որ թունելը պետք է տիրապետի լռելյայնին։

Ախտանիշը՝ երկրորդ հաճախորդը հաղթում է լուռ

OpenVPN՝ redirect-gateway def1 ընտրանքը չի վերագրում 0.0.0.0/0։ Այն ավելացնում է 0.0.0.0/1 և 128.0.0.0/1. միասին նրանք ծածկում են բոլոր IPv4 հասցեները, և յուրաքանչյուր նախածանց երկարությամբ հաղթում է սովորական լռելյայնին։ Սկզբնական լռելյայնը մնում է աղյուսակում և այլևս չի օգտագործվում սովորական երթևեկության համար, իսկ VPN սերվերին տանող հոսթ-երթուղին թույլ չի տալիս թունելին որսալ իր սեփական արտաքին փաթեթները։ Երկու հաճախորդներն էլ անում են դա, իսկ երկրորդը պարզապես իր զույգը տեղադրում է ավելի ուշ։

Այդ պատճառով առաջին թունելը մեռած է թվում, ոչ թե անջատված։ Նրա ինտերֆեյսը վերևում է, կառավարման ալիքը կենդանի է, և ոչ մի հավելվածային երթևեկություն այլևս չի հասնում նրան։ Հակառակ բողոքն ունի նույն բացակայող push-ը՝ հեռախոսը, որը միանում է, բայց ոչինչ չի ուղարկում, սովորաբար խոսում է սերվերի հետ, որը երբեք չի հայտարարել redirect-gateway, ուստի սարքը պահում է իր լռելյայնը և հասնում է միայն լողավազանին։

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

Կարդացեք, թե որ թունելն է իրականում հաղթում

Մի՛ եզրակացրեք հաղթողին հաճախորդների մեկնարկի հերթականությունից կամ սկուտեղի պատկերակից։ Հարցրեք միջուկին, թե որ երթուղին կօգտագործի երկու մասնավոր ցանցերից դուրս գտնվող նպատակակետի համար, և կարդացեք վերադարձած ինտերֆեյսը։

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Առաջին երկուսը Linux-ի պատասխանն են, իսկ վերջին երկուսը Windows-ի համարժեքը։ Գործարկեք դրանք, մինչ երկու թունելներն էլ վերևում են, ապա անջատեք մեկը և նորից գործարկեք։ Երկու ելքերի տարբերությունը այն փաստն է, որ ձեզ պետք է լուծում ընտրելուց առաջ, և այն ավելի քիչ ժամանակ է խլում, քան հաճախորդներից որևէ մեկի մատյանը կարդալը։

Գրանցեք արդյունքը՝ ներառյալ ինտերֆեյսի անունը և համընկած նախածանցը։ Տոմսը, որն ասում է, թե երկրորդ VPN-ը կոտրել է առաջինը, ախտանիշի նկարագրություն է, ոչ թե երթուղային պնդում, որի վրա ինչ-որ մեկը կարող է գործել։ Որոնումը այն դարձնում է փաստ, որը հաջորդ ինժեները կարող է վերարտադրել մեկ հրամանով։

Windows՝ թույլ մի՛ տվեք, որ մեկ պրոֆիլը տիրապետի լռելյայնին

Windows-ը պահում է պահված պրոֆիլներ, և ներկառուցված հաճախորդը թույլ է տալիս, որ մեկը կախված լինի մյուսից, որպեսզի առաջինն ինքնաբերաբար բարձրանա, երբ երկրորդը հավաքում է։ Վերջին միացած պրոֆիլը հակված է պահել լռելյայնը, ուստի գործնական տերը վերջին հավաքումն է, ոչ առաջինը։ Տվեք յուրաքանչյուր պրոֆիլի իր push-երթուղիները և միացրեք split tunneling-ը նրա համար, որը չպետք է տիրապետի լռելյայնին։

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling-ը փոխում է դա. աղյուսակ են մտնում միայն սերվերի push արած նախածանցները, ինչը լռելյայնը թողնում է առաջին թունելի մոտ։ Դիզայնը դեռ ձախողվում է, եթե երկու սերվերներն էլ լռելյայն երթուղի push անեն, որովհետև այդ ժամանակ վերջին կապն է հաղթում, և հաճախորդի կողմի ոչ մի կարգավորում դա չի փոխում։ Ուղղեք push-ը սերվերի կողմում կամ ընդունեք մեկ տեր։

Հավելվածով գործարկվող պրոֆիլները այլ հատկություն են և արժե իմանալ. Windows պրոֆիլը կարող է սկսվել, երբ անվանված գործարկվող ֆայլը մեկնարկում է, ընդ որում երթևեկության զտիչները որոշում են, թե ինչ է այն տանում։ Սա պրոֆիլի կարգավորում է, ոչ թե firewall-ի կանոն, և լուծում է լռելյայն երթուղու հակամարտությունից տարբեր խնդիր։

Linux՝ պահեք երկրորդ թունելը հիմնական աղյուսակից դուրս

Մեկ մեքենայի վրա openvpn --config-ի երկու օրինակ գործարկելը երկու հաճախորդներին էլ դնում է նույն աղյուսակում, և երեք տարբերակ բաժանում է նրանց աճող մեկուսացմամբ։ Ամենաթեթևը երկրորդ հաճախորդին ընդհանրապես աղյուսակը խմբագրելուց արգելելն է՝ route-nopull-ով և բացահայտ երթուղիներով, կամ route-up սկրիպտով, որը տեղադրում է միայն այն, ինչ դուք նախատեսում եք։ Այն ժամանակ երկրորդ թունելը կրում է հենց ձեր նշած նախածանցները և ոչինչ ավելին։ Այն ժամանակ դուք եք որոշում, թե որ նախածանցը ուր գնա՝ հետո պարզելու փոխարեն։

Քաղաքականության երթուղավորումը միջին տարբերակն է։ Կանոնը ընտրում է առանձին աղյուսակ մեկ աղբյուրի հասցեի կամ firewall-ի նշանի համար, և այդ աղյուսակը կրում է երկրորդ թունելի երթուղիները։ Հակադարձ ուղու զտումը այստեղ թակարդն է, որովհետև այն պատասխանը, որը գալիս է այլ ինտերֆեյսով, քան աղյուսակը կընտրեր, դեն է նետվում, ուստի ստուգեք rp_filter կարգավորումը՝ նախքան եզրակացնելը, որ թունելը կոտրված է։

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Ցանցային անվանատարածքները ամենածանր և ամենամաքուր տարբերակն են։ Գործարկեք երկրորդ հաճախորդին ip netns-ի ներսում, տվեք նրան veth զույգ և մտեք այդ անվանատարածք՝ օգտագործելու համար։ Միջամտությունը վերանում է, որովհետև յուրաքանչյուր անվանատարածք ունի իր աղյուսակները՝ մեկը կիսելու փոխարեն, ինչն արժե լրացուցիչ կարգավորումը, երբ երկու թունելները պետք է շաբաթներ շարունակ վերևում մնան։

Ըստ հավելվածի, և շղթայավորումը որպես առանձին խնդիր

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

Շղթայավորումը այլ գործողություն է, քան երկու թունել կողք-կողքի գործարկելը։ A-ն B-ի վրայով շղթայավորելը նշանակում է, որ ներքին սերվերի հասցեն պետք է հասանելի լինի արտաքին թունելի ներսից։ Արտաքին հաճախորդը նույնպես չպետք է ներքին հաճախորդի գաղտնագրված փաթեթները արտահոսք համարի։ Մեկ հաճախորդ վիրտուալ մեքենայի ներսում կոպիտ, բայց հուսալի տարբերակն է. երկուսը մեկ հոսթում պահանջում են վերևի երթուղային աշխատանքը գումարած արտաքին ուղի դեպի ներքին սերվեր, որը երբեք չի մտնում ներքին թունել։

Գրեք լռելյայնի տիրոջը, յուրաքանչյուր թունելի կրած նախածանցների ցանկը և DNS ուղին։ Այդ երեք փաստերը հաջորդ դեպքը դարձնում են որոնում, ոչ թե հետաքննություն։