Ինչու ադապտերների հերթականությունը չի որոշում ձեր լաբորատորիայի VPN երթուղին
Հիպերվիզորում ադապտեր 1-ը ոչինչ չի ասում, թե հյուրը որ երթուղին կընտրի։ Համեմատեք նախածանցները, մետրիկաները և քաղաքականության կանոնները յուրաքանչյուր ապարատային փոփոխությունից հետո։
Այն, որ ադապտեր 1-ը հիպերվիզորի ցանկում առաջինն է, միայն ցուցադրման կարգ է, և հյուրի երթուղային աղյուսակը այն չի կարդում։ Ուղին որոշում են նախածանցը, մետրիկան և ցանկացած քաղաքականության կանոն, որը գործում է երկուսից առաջ։ Այդ պատճառով լաբորատոր VM-ին կամրջային ադապտեր ավելացնելը կարող է ստեղծել երկրորդ լռելյայն ուղի, մինչ հին NAT ինտերֆեյսը դեռ ցուցադրվում է որպես առկա և համարակալված երկրորդ։ Արդյունքը VM է, որը երբեմն օգտագործում է թունելը, երբեմն ոչ, առանց որևէ կոնֆիգուրացիայի փոփոխության, որը դա կբացատրի։
Երեք պայման է որոշում ուղին
Երեք պայմաններն են՝ որ նախածանցն է ավելի կոնկրետ, ինչ են անում մետրիկաները, երբ նախածանցները հավասար են, և ինչ կանոններ է կիրառել հյուրը ապարատային փոփոխությունից հետո։ Յուրաքանչյուրին կարելի է պատասխանել մեկ հրամանով, և ոչ մեկը չի ներառում հիպերվիզորի համարակալումը։
Հենց վերջին կետն է որոշումը. եթե չեք կարող ասել, թե որ նախածանցն է հաղթում VPN-ի վերջնակետի սեփական հասցեի համար, դուք երթուղային քաղաքականություն չունեք, դուք ունեք տոպոլոգիա, որը այսօր պատահաբար աշխատում է։
Առաջին պայման. որ նախածանցն է հաղթում
10.8.0.0/24-ի ուղին հաղթում է լռելյայն ուղուն դրա ներսում գտնվող հասցեի համար՝ անկախ մետրիկաներից և ադապտերների հերթականությունից։ Այդ պատճառով կոնկրետ ուղի տեղադրող VPN հաճախորդը շարունակում է աշխատել նույնիսկ երբ հայտնվում է երկրորդ ադապտեր ավելի ցածր մետրիկայով. կոնկրետությունը հաղթում է նախքան արժեքի դիտարկումը։ Ստուգեք ip route show-ով այն աղյուսակը, որը կարծում եք օգտագործվում է, և ip route get 203.0.113.9-ով այն պատասխանը, որը միջուկը իսկապես կտա կոնկրետ նպատակակետի համար։
Վերջնակետի սեփական հասցեն ամենակարևոր փորձն է։ Եթե VPN սերվերի հասցեն լուծվում է նոր ավելացված կամրջային ադապտերի միջոցով, թունելը կարող է երբեք չկառուցվել, կամ կառուցվել և ապա կորցնել իր սեփական տրանսպորտային ուղին։ Հարցրեք հենց այդ հասցեի մասին՝ փոխարենը ենթադրելու, որ թունելի ինտերֆեյսն է պատասխանը։
Երկրորդ պայման. ինչ է անում մետրիկան և ինչ չի անում
Նրա դերը ավելի նեղ է, քան մարդկանց մեծամասնությունը սպասում է։ Մետրիկաները լուծում են նույն նախածանցի ուղիների միջև հավասարությունը. նրանք թույլ չեն տալիս ավելի լայն ուղուն հաղթել ավելի կոնկրետին։ Հավասարության դեպքում նախընտրելի է փոքր թիվը, և տարբեր օպերացիոն համակարգեր հաշվում են հակառակ ուղղություններով, ինչի պատճառով Linux-ի և Windows-ի միջև պատճենված խորհուրդները հաճախ հակասում են իրենց։
Հյուրում ip route show-ը տպում է մետրիկան յուրաքանչյուր ուղու կողքին, իսկ Windows-ում Get-NetRoute-ը տպում է InterfaceMetric և ուղու մետրիկա։ Կարդացեք երկուսն էլ, որովհետև արդյունավետ նախապատվությունը կարող է գումար լինել, ոչ թե մեկ դաշտ։ Եթե կան երկու լռելյայն ուղիներ, դա է հայտնագործությունը. հյուրն ունի դուրս գալու երկու ճանապարհ, և թե որն է հաղթում, կախված է թվերից, որոնք ապարատային փոփոխությունը կարող է փոխել։
Երրորդ պայման. ինչ է իրականում կիրառել հյուրը
Կոնֆիգուրացիան նույնը չէ, ինչ կիրառված վիճակը։ Ինտերֆեյսների անունները կայուն չեն ապարատային փոփոխությունների ընթացքում բոլոր հարթակներում, և անվանը համապատասխանող կոնֆիգուրացիան այժմ կարող է ոչ մի բանի չկիրառվել։
Ստուգեք կիրառված վիճակը, ոչ թե նախատեսվածը։ ip -br link-ը ցույց է տալիս այժմ գոյություն ունեցող ինտերֆեյսները, իսկ NetworkManager-ով հոսթում nmcli connection show-ը ցույց է տալիս, թե որ պրոֆիլն է կապված որ սարքին։ Չկապված պրոֆիլը ինտերֆեյսը թողնում է վերև առանց հասցեավորման, ինչը նման է երթուղային խնդրի, բայց անվանման խնդիր է։ Վերականգնված պատկերները վատթարացնում են դա, որովհետև հյուրի պահված վիճակը կարող է հղում անել ադապտերների ինքնություններին, որոնք նոր ապարատը այլևս չի տրամադրում։
Պահեք լաբորատորիայի տոպոլոգիան վերարտադրելի
Պահեք նախատեսված վիրտուալ ցանցային միացումները հյուրի կոնֆիգուրացիայի կողքին, որպեսզի դերից ադապտեր քարտեզագրումը գրված լինի, այլ ոչ թե ցանկի դիրքից ենթադրվի։
Սովորաբար բավական է անվանել չորս դեր՝ մասնավոր կապ, կառավարում, արտաքին տրանսպորտ և թունել։ Յուրաքանչյուրը պետք է ֆայլում համապատասխանի կոնկրետ ադապտերի և կոնկրետ հյուրի ինտերֆեյսի։
Այնուհետև փորձարկեք իրական հավելվածը ապարատային փոփոխությունից, վերագործարկումից կամ վերականգնված պատկերից հետո, և այդ փորձարկման մեջ ներառեք դեպի VPN վերջնակետ տանող ուղին։ Եթե դարպասային VM-ն պետք է լինի միակ ելքը, ստուգեք, որ փորձարկման VM-ը չունի ակամա երկրորդ լռելյայն ուղի, որովհետև կամրջային ադապտերը հենց երկրորդ լռելյայն ուղին է ավելացնում։ Փորձարկեք հյուրից, ոչ հիպերվիզորի կոնսոլից, քանի որ երկուսը կարող են չհամաձայնել, թե որ ինտերֆեյսն որն է։
VirtualBox-ի ցանցային փաստաթղթերը նկարագրում են ադապտերների ռեժիմները և թե յուրաքանչյուրը ինչին է միանում, և հենց այդ մասն է, որ արժե կարդալ երկրորդն ավելացնելուց առաջ։ Լաբորատորիան, որը նույնականացնում է, թե որ ադապտերն է սպասարկում յուրաքանչյուր դերը, դարձնում է երթուղու փոփոխությունը բացատրելի։ Լաբորատորիան, որը հենվում է հիպերվիզորի համարակալման վրա, ամեն փոփոխություն դարձնում է փորձ։