ESXi հյուր VPN. երթուղավորում, թե կամրջում՝ որոշեք նախքան պորտային խումբը
Երթուղավորված TUN-ին պետք են վերադարձի երթուղիներ. կամրջված TAP-ին՝ 2-րդ շերտի հասանելիություն և ավելի լայն պորտախմբի քաղաքականություն։ Որոշեք դերը՝ նախքան promiscuous ռեժիմի ընդլայնումը։
Երթուղավորեք փաթեթները կամ ընդլայնեք Ethernet տիրույթը. պորտային խմբի փոփոխությունը գալիս է այդ ընտրությունից հետո։ Մասնավոր հասցե ունեցող հավելվածի կողմից արդյունքները կարող են նույնը թվալ, մինչդեռ հիպերվիզորի պահանջները բոլորովին տարբեր են։ Դրա համար էլ նախ ընդլայնում են պորտային խումբը, ապա պատասխանում դիզայնի հարցին՝ սովորաբար broadcast փոթորիկից հետո։ Անցեք այս ստուգումները հերթով և կանգ առեք, քանի դեռ պահանջը մշուշոտ է, որովհետև ոչ մի պորտախմբի կարգավորում չի ուղղում դիզայն, որը երբեք չի ընտրվել։
Որոշումը ծառայության սեփականատիրոջն է. հիպերվիզորի կոնֆիգուրացիան պետք է այն իրականացնի, ոչ թե պատահաբար որոշի։
Ստուգեք, թե հեռավոր կողմին իրականում ինչ է պետք
Թվարկեք այն ծառայությունները, որոնց պետք է հասնեն հեռավոր հաճախորդները, և նրանց օգտագործած արձանագրությունները։ Եթե ցանկը հայտնի նախածանցերում մի քանի TCP ծառայություն է, երթուղավորումը բավարար է։ Եթե ինչ-որ բան իսկապես 2-րդ շերտի հարևանություն է պահանջում՝ broadcast-ից կախված հայտնաբերում, ոչ IP արձանագրություններ, սարք, որը չի ընդունում դարպասը, երթուղավորումը չի կարող դա նմանակել, և դա պետք է շուտ ասել։ Եղեք անկեղծ այդ ցանկի ոչ IP գրառումների մասին, որովհետև հենց այնտեղ է երթուղավորված դիզայնը մեկ շաբաթ անց լուռ ձախողվում։
Ապա ստուգեք հաճախորդների լողավազանը։ Երթուղավորված դիզայնին պետք է հասցեների տիրույթ և հեռավոր կողմում բացահայտ վերադարձի երթուղի. կամրջված դիզայնին պետք է, որ ընդլայնված Ethernet տիրույթը տիրապետի հասցեների բաշխմանը և մեկուսացմանը։ Ինչ էլ ընտրեք, այս VM-ից դուրս մեկը պետք է համաձայնի դրան։
Ինչ է պահանջում յուրաքանչյուր դիզայն վիրտուալ ցանցից
Երկու դիզայնը տարբերվում են նրանով, ինչ վիրտուալ ցանցը պետք է հանդուրժի, և աղյուսակը դա տեսնելու ամենակարճ ճանապարհն է.
| Դիզայն | Դերը հյուրի կողմում | Ինչ պետք է տեղավորի վիրտուալ ցանցը | Ձախողման ձևը սխալ ընտրության դեպքում |
|---|---|---|---|
| Երթուղավորված TUN | Երթուղիչ առանձին նախածանցերի միջև | Երթուղավորված հաճախորդների լողավազան և վերադարձի ուղիներ հեռավոր կողմում | Հաճախորդները հասնում են դարպասին և երբեք չեն հասնում դրա հետևի ծառայությանը |
| Կամրջված TAP | 2-րդ շերտի կամուրջ միացող հաճախորդների համար | Լրացուցիչ Ethernet ինքնություններ, broadcast երթևեկություն և VLAN կանոններ | vSwitch-ը գցում է կադրերը, կամ դիզայնը պահանջում է promiscuous ռեժիմ, որը ոչ ոք չի հաստատել |
Երթուղավորումը թողնում է broadcast տիրույթը տեղում և բնական տեղ է տալիս սահմանափակելու, թե որ ծառայություններն են անցնում դարպասով։ Կամրջումը տեղափոխում է սահմանը. հաճախորդները դառնում են ընդլայնված Ethernet տիրույթի մասնակիցներ, և հասցեների բաշխումը, մեկուսացումը և 2-րդ շերտի ցանկացած քաղաքականություն այժմ տարածվում են նրանց վրա։ Գրեք ընտրված տողը փոփոխությունների մատյանում։ «Երթուղավորված TUN, հաճախորդների լողավազան 10.90.0.0/24, վերադարձի երթուղի միջուկում» նման նախադասությունը թույլ չի տալիս հաջորդ ինժեներին նորից քննարկել դիզայնը պորտախմբի կարգավորումներից։
Ով պետք է տեսնի ում կադրերը
Պորտային խմբին դիպչելուց առաջ հարթակի սեփականատիրոջը մեկ հարց տվեք. պահանջո՞ւմ է արդյոք դիզայնը, որ այս VM-ը ստանա այլ մասնակիցներին ուղղված կադրեր։ Եթե պատասխանը ոչ է, այս բաժնից ոչինչ չի գործում, որովհետև երթուղավորված TUN-ը երբեք այդ տեսանելիության կարիքը չունի։ Եթե պատասխանը այո է, ապա Broadcom-ի ուղեցույցը promiscuous ռեժիմի մասին այն ընթերցումն է, որ կարևոր է. այն բացատրում է, թե որքան ավելի շատ է VM-ը տեսնում vSwitch-ից, և խորհուրդ է տալիս այդ քաղաքականությունը սահմանափակել մեկ պորտային խմբով։
Դրան վերաբերվեք որպես պահանջի ստուգում, ոչ թե թույլտվության թերթիկ։ Միացրեք կարգավորումը մեկ նվիրված կապակցման համար, երբ կամրջելու անհրաժեշտությունը գրի առնված է, և թողեք այն անջատված մնացած բոլոր տեղերում։ Այլ կամուրջի օրինակից պատճենված լայն VLAN trunk-ն այն մասն է, որը ոչ ոք չի հիշում հեռացնել, և մեկ VLAN-ով դիզայնը պետք է մնա մեկ VLAN-ով։
Գրանցեք, թե որ պորտային խումբը փոխվեց և ինչու, նույն տեղում, որտեղ գրել եք դիզայնի տողը։ Հենց այդ զույգն է հնարավոր դարձնում հաջորդ աուդիտը։
Պահեք հյուրի օբյեկտները բացահայտ
Linux-ի ներսում կամրջի անդամակցությունը և հասցեի սեփականությունը առանձին օբյեկտներ են, և դրանց խառնումը ստեղծում է շփոթեցնող կիսագործող վիճակ։ Հասցեները տվեք կամրջի ինտերֆեյսին կամ երթուղավորված թունելին, ոչ թե նույն ուղու երկու կողմերին, և անդամ պորտերը պահեք առանց IP կոնֆիգուրացիայի։
Խուսափեք մեկ ենթացանց անկախ տեղադրելուց երթուղավորված TUN-ի և անկապ Ethernet ինտերֆեյսի վրա։ Նման կոնֆիգուրացիան ստեղծում է երկու ուղի դեպի նույն նախածանցը, ասիմետրիկ պատասխաններ և աջակցության թեմա flapping-ի մասին, որը չի հիշատակում ուղիներից ոչ մեկը։ Եթե հյուրը նաև հյուրընկալում է կոնտեյներներ կամ տեղական հիպերվիզոր, ստուգեք, որ նրանք արդեն չեն կամրջվում նույն uplink-ի մեջ։ Մեկ NIC-ի վրա երկու կամուրջ դիզայն է, ոչ թե պատահար, որը ցանկանում եք հայտնաբերել փոփոխության պատուհանի ընթացքում։
Հաստատեք փաթեթի ուղով, ոչ ping-ով
Ստուգեք իրական ուղին, ոչ միայն հասանելիությունը։ Հաճախորդից հաստատեք, թե որ աղբյուր հասցեն է հասնում հեռավոր ծառայությանը, ապա որ պատասխանը վերադառնում է նույն ճանապարհով։ Հյուրի վրա ստուգեք կոնկրետ հոսքի փոխանցման հաշվիչները, իսկ պորտային խմբում հաստատեք, որ ընտրված դիզայնի պահանջից ավելի տեսանելիություն չի միացվել։
Վերջում փորձարկեք ձախողման ուղղությունը։ Կանգնեցրեք թունելը կամ անջատեք հաճախորդին և ստուգեք, որ երթևեկությունը լուռ չի ընկնում դեպի երթուղավորված ուղի, որը դուք չօգտագործված էիք համարում, որովհետև հենց այդ անկումն է, թե ինչպես կամրջված դիզայնը լուռ դառնում է ակամա երթուղիչ։