Թվում է՝ երկու VPN հաճախորդ կռվում են նույն սոքեթի համար, և ակնհայտ լուծումը պետք է լինի մեկի հեռացումը։ Գործնականում նրանք հազվադեպ են դիպչում նույն սոքեթին։ Յուրաքանչյուր միացում վերագրում է օպերացիոն համակարգի երթուղավորման աղյուսակը, և ամբողջական թունելի պրոֆիլը հավակնում է լռելյայն երթուղուն։ Սովորաբար հաղթում է վերջին միացածը, դրա համար ախտանիշը կարծես տեղափոխվում է հաճախորդների միջև։

Կոնֆլիկտն ապրում է երթուղավորման աղյուսակում

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

Հաճախորդները մեկ ընդհանուր աղյուսակի խմբագիրներ են։ Իմանալը, թե որ փոփոխությունն է եղել վերջինը, բացատրում է գրեթե բոլոր ախտանիշները։

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

Ստուգեք փաստացի որոշումը՝ փոխանակ վստահելու այն հաճախորդին, որը հայտնում է միացված լինելու մասին։ Հարցրեք համակարգին, թե որ ինտերֆեյսը կտանի կոնկրետ նպատակակետ։

ip route get 10.20.0.5
route print -4

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

Կանգնեցրեք երկրորդ հաճախորդին ամեն ինչ հավակնելուց

Մեկ հաճախորդ պետք է տիրի լռելյայն երթուղուն, իսկ մյուսը՝ կրի միայն իր նախածանցները։ OpenVPN հաճախորդները կարող են մերժել այն, ինչ սերվերը մղում է։

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull անտեսում է յուրաքանչյուր մղված երթուղի, մինչ pull-filter ignore "redirect-gateway" գցում է միայն լռելյայն երթուղու հրահանգը և պահպանում մղված DNS-ն ու այլ տարբերակներ։ Ընտրեք նրանց միջև՝ ելնելով նրանից, թե սերվերի կոնֆիգուրացիայի որքան մասն եք դեռ ուզում, ապա ավելացրեք այն կոնկրետ նախածանցները, որոնք երկրորդ ցանցին անհրաժեշտ են։ Հիշեք DNS-ի մասին, որովհետև այն լուծիչը, որը մղում է թունելը, որ չի կրում հարցումները, ոչինչ չի վերադարձնում։ Փորձեք մեկ հայտնի հոսթ յուրաքանչյուր ցանցում և հաստատեք աղբյուրի հասցեն, որը տեսնում է հեռավոր կողմը։

Ծածկվող ենթացանցերը հնարավոր չէ շրջանցել

Երբ երկու ցանցերն էլ հրապարակում են նույն նախածանցը, միջուկը մեկ գրառում է պահում երկու տարբեր վայրերի համար և պետք է ընտրի։ Հոսթի երթուղին չի կարող հորինել բացակայող տարբերությունը, և մետրիկի ճշգրտումը նույնպես չի կարող։ Վերահամարակալեք մի կողմը, կամ թող դրա ադմինիստրատորը թարգմանի հեռավոր տիրույթը, որպեսզի նախածանցները տարբերվեն։ Ստուգեք իրական ենթացանցերը նախքան հաճախորդներին մեղադրելը, քանի որ տնային երթուղիչի լռելյայն 192.168.1.0/24-ը բախվում է գրասենյակային տիրույթի հետ ավելի հաճախ, քան որևէ մեկը սպասում է։ Գրանցեք երկու տիրույթներն էլ տոմսում, որպեսզի հաջորդ փոփոխությունը նորից չստեղծի ծածկույթը։

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

Առնչվող հոդվածներ