VPN гост в ESXi: маршрутизация или мостово свързване — решете преди порт групата
Маршрутизиран 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 режим е четивото, което има значение: то обяснява колко повече от vSwitch вижда VM и препоръчва политиката да се ограничи до една порт група.
Отнасяйте се към това като проверка на изискване, не като разрешение. Включете настройката за едно отделно прикачване, когато нуждата от мост е записана, и я оставете изключена навсякъде другаде. Широк VLAN trunk, копиран от друг пример за мост, е частта, която никой не помни да премахне, а дизайн с един VLAN трябва да си остане с един VLAN.
Запишете коя порт група е променена и защо, на същото място, където записахте реда за дизайна. Тази двойка прави следващия одит възможен.
Пазете обектите на госта явни
В Linux членството в мост и собствеността върху адрес са отделни обекти и смесването им води до объркващото полуработещо състояние. Задавайте адреси на мостовия интерфейс или на маршрутизирания тунел, не на двете страни на един и същ път, и дръжте портовете членове без IP конфигурация.
Избягвайте да слагате една подмрежа независимо върху маршрутизиран TUN и върху несвързан Ethernet интерфейс. Такава конфигурация създава два пътя към един и същ префикс, асиметрични отговори и тема в поддръжката за flapping, която не споменава нито един от пътищата. Ако гостът също хоства контейнери или локален хипервизор, проверете дали те вече не са мостосани към същия uplink. Два моста на една NIC са дизайн, а не инцидент, който искате да откриете по време на прозорец за промяна.
Потвърдете с път на пакет, не с ping
Проверете реалния път, не само достижимостта. От клиент потвърдете кой адрес на източника пристига в отдалечената услуга, после че отговорът се връща по същия път. На госта проверете броячите за препращане за конкретния поток, а на порт групата — че не е включена допълнителна видимост извън нужната на избрания дизайн.
Накрая тествайте посоката на отказа. Спрете тунела или откачете клиента и проверете, че трафикът не пада тихо към маршрутизиран път, който сте смятали за неизползван, защото този откат е начинът, по който мостов дизайн тихо става неволен рутер.