Երկու VPN հաճախորդ մեկ աշխատասեղանի վրա՝ ինչն է բախվում, և ինչն է աշխատում

Ձեր երկրորդ հաճախորդը միանում է, առաջինի ռեսուրսները դադարում են լուծվել, և տոմսում ասվում է, որ աշխատանքային VPN-ը փչացրել է անձնականը։ Ոչինչ փչացած չէ խափանման իմաստով. երկու հաճախորդներն էլ արեցին այն, ինչի համար նախագծված էին, և մեքենան ունի ընդամենը մեկ երթուղային աղյուսակ։ Բախումը չորս ռեսուրսների շուրջ է, որոնք յուրաքանչյուր հաճախորդ համարում է իրենը։ Անցեք դրանց հերթականությամբ, և շտկումը սովորաբար դառնում է դիզայնի ընտրություն, այլ ոչ վերանորոգում։

Քայլ 1՝ պարզեք, թե որ հաճախորդն է տիրում ելքին

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

ip route get 1.1.1.1
ip route show default
route print

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

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

Քայլ 2՝ ստուգեք անունների լուծիչը և համընկնող նախածանցները

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Ապա համեմատեք այն մասնավոր նախածանցները, որոնք օգտագործում են երկու ցանցերը։ Եթե երկու կողմերն էլ բաշխում են նույն տիրույթից, ոչ մի հաճախորդային կողմի լուծում չի շտկի դա, որովհետև մեքենան չի կարող ասել, թե որ 10.0.0.0/8 նպատակակետն է պատկանում որ թունելին։ Մի կողմը պետք է վերահամարակալվի կամ թարգմանվի, և դա զրույց է ցանցի սեփականատերերի հետ, ոչ թե կարգավորման փոփոխություն։ Համընկնումը միակ բախումն է, որտեղ ազնիվ պատասխանն այն է, որ դիզայնը պետք է փոխվի։

Կանգ առեք այստեղ, եթե նախածանցները համընկնում են։ Այս ցանկում ամեն ինչ հետագայում ենթադրում է, որ դրանք չեն համընկնում։

Քայլ 3՝ ընտրեք առանձնացման օրինաչափություն, որը դիմանում է

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

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

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

Քայլ 4՝ ստուգեք երկու ցանցերն էլ նույն նստաշրջանից

Փորձարկեք մեկ ռեսուրս յուրաքանչյուր մասնավոր ցանցում այն միջավայրից, որտեղ հավելվածն իրականում աշխատում է, ոչ ձեր shell-ից, եթե հավելվածը աշխատում է անվանատարածքի ներսում։ Ստուգեք ելքի ինտերֆեյսը, լուծված հասցեն և պատասխանի կոդը միասին, որովհետև երեքից մեկում հաջողությունը կարող է թաքցնել մյուսներում ձախողումը։ Կրկնեք վերագործարկումից հետո, որովհետև հաճախորդների մեկնարկի հերթականությունն է որոշում, թե ով կհաղթի։ Հենց այդ հերթականությունն են մարդիկ մոռանում արձանագրել։

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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