VPN на ESXi: маршрутызацыя ці мастоўка — вызначыце ролю да групы портаў
Маршрутызаваны TUN патрабуе зваротных маршрутаў; маставы TAP — дасяжнасці другога ўзроўню і шырэйшай палітыкі групы портаў. Вызначыце ролю, перш чым пашыраць promiscuous mode.
Маршрутызуйце пакеты або пашырайце дамен Ethernet: змена групы портаў ідзе следам за гэтым выбарам. З пункту гледжання праграмы з прыватным адрасам вынікі могуць выглядаць аднолькава, тады як патрабаванні гіпервізара зусім розныя. Таму спачатку пашыраюць групу портаў, а пытанне дызайну вырашаюць другім, звычайна пасля шырокавяшчальнай буры. Праходзьце гэтыя праверкі па парадку і спыніцеся, пакуль патрабаванне яшчэ расплывістае, бо ніводная налада групы портаў не выправіць дызайн, які ніколі не абіралі.
Рашэнне належыць уладальніку сэрвісу; канфігурацыя гіпервізара павінна яго рэалізоўваць, а не выпадкова вызначаць.
Праверце, што насамрэч патрэбна далёкаму боку
Пералічыце сэрвісы, да якіх павінны дабрацца аддаленыя кліенты, і пратаколы, якія яны выкарыстоўваюць. Калі спіс — гэта некалькі сэрвісаў TCP на вядомых прэфіксах, маршрутызацыя справіцца. Калі нешта сапраўды патрабуе суседства 2-га ўзроўню — залежнае ад шырокавяшчання выяўленне, не-IP пратаколы, прылада, якая не прымае шлюз — маршрутызацыя не можа гэта імітаваць, і пра гэта трэба сказаць рана. Будзьце сумленныя адносна не-IP запісаў у гэтым спісе, бо менавіта там дызайн маршрутызацыі ціха правальваецца праз тыдзень.
Затым праверце пул кліентаў. Маршрутызаваны дызайн патрабуе дыяпазону адрасоў і яўнага зваротнага маршруту на далёкім баку; маставы дызайн патрабуе, каб пашыраны дамен Ethernet валодаў размеркаваннем адрасоў і ізаляцыяй. Што б вы ні абралі, хтосьці па-за гэтай VM павінен з гэтым пагадзіцца.
Што кожны дызайн патрабуе ад віртуальнай сеткі
Два дызайны розняцца ў тым, што віртуальная сетка павінна вытрымаць, і табліца — самы кароткі спосаб гэта ўбачыць:
| Дызайн | Роля гасцявога боку | Што павінна ўмясціць віртуальная сетка | Рэжым адмовы пры няправільным выбары |
|---|---|---|---|
| Маршрутызаваны TUN | Маршрутызатар паміж асобнымі прэфіксамі | Маршрутызаваны пул кліентаў плюс зваротныя шляхі на далёкім баку | Кліенты дасягаюць шлюза і ніколі не дасягаюць сэрвісу за ім |
| Маставы TAP | Маст 2-га ўзроўню для кліентаў, якія далучаюцца | Дадатковыя ідэнтычнасці Ethernet, шырокавяшчальны трафік і правілы VLAN | vSwitch скідае кадры, або дызайн патрабуе promiscuous mode, якога ніхто не ўхваліў |
Маршрутызацыя пакідае шырокавяшчальны дамен на месцы і дае натуральнае месца, каб абмежаваць, якія сэрвісы перасякаюць шлюз. Мастоўка перасоўвае мяжу: кліенты становяцца ўдзельнікамі пашыранага дамена Ethernet, і размеркаванне адрасоў, ізаляцыя і любая палітыка 2-га ўзроўню цяпер датычацца іх. Запішыце абраны радок у запіс пра змены. Фраза накшталт «маршрутызаваны TUN, пул кліентаў 10.90.0.0/24, зваротны маршрут на ядры» не дазволіць наступнаму інжынеру зноў абмяркоўваць дызайн з налад групы портаў.
Хто мае бачыць чые кадры
Задайце ўладальніку платформы адно пытанне перад тым, як кранаць групу портаў: ці патрабуе дызайн, каб гэтая VM атрымлівала кадры, адрасаваныя іншым удзельнікам? Калі адказ не, нішто ў гэтым раздзеле не датычыцца, бо маршрутызаваны TUN ніколі не мае патрэбы ў такой бачнасці. Калі адказ так, то рэкамендацыі Broadcom па promiscuous mode — гэта тое, што варта прачытаць: там выкладзена, наколькі больш vSwitch бачыць VM, і рэкамендавана абмежаваць гэтую палітыку адной групай портаў.
Стаўцеся да гэтага як да праверкі патрабавання, а не як да дазволу. Уключыце наладу для аднаго прысвечанага далучэння, калі патрэба мастоўкі запісана, і пакіньце яе выключанай усюды іншым. Шырокі транк VLAN, скапіяваны з іншага прыкладу моста, — гэта частка, якую ніхто не ўспамінае выдаліць, а дызайн з адным VLAN павінен заставацца з адным VLAN.
Запішыце, якая група портаў змянілася і чаму, там жа, дзе запісаны радок дызайну. Менавіта гэтая пара робіць магчымым наступны аўдыт.
Трымайце аб'екты госця яўнымі
Унутры Linux членства ў мосце і валоданне адрасам — асобныя аб'екты, і іх змешванне выклікае заблытаны паўпрацаздольны стан. Прызначце адрасы інтэрфейсу моста або маршрутызаванаму тунелю, а не абодвум бакам аднаго шляху, і трымайце парты-ўдзельнікі свабоднымі ад канфігурацыі IP.
Пазбягайце размяшчэння адной падсеткі незалежна на маршрутызаваным TUN і на няроднасным інтэрфейсе Ethernet. Такая канфігурацыя стварае два шляхі да аднаго прэфікса, асіметрычныя адказы і галіну падтрымкі пра флапінг, якая не згадвае ніводнага шляху. Калі госць таксама размяшчае кантэйнеры або лакальны гіпервізар, праверце, што яны ўжо не мосцяць у той самы uplink. Два масты на адной сеткавай карце — гэта дызайн, а не выпадак, які вы хочаце выявіць падчас акна змен.
Пацвердзіце шляхам пакета, а не ping
Правярайце фактычны шлях, а не толькі дасяжнасць. З кліента пацвердзіце, які адрас крыніцы прыходзіць да далёкага сэрвісу, потым — што адказ вяртаецца тым жа шляхам. На госці праверце лічыльнікі перасылкі для канкрэтнага патоку, а на групе портаў — што не ўключана дадатковая бачнасць звыш патрэбнай абранаму дызайну.
Нарэшце праверце кірунак адмовы. Спыніце тунель або адключыце кліента і праверце, што трафік не вяртаецца моўчкі на маршрутызаваны шлях, які вы лічылі невыкарыстаным, бо менавіта гэтае вяртанне — тое, як маставы дызайн ціха робіцца ненаўмысным маршрутызатарам.