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-транк, скопійований з іншого прикладу моста, — це та частина, яку ніхто не згадує прибрати, а проєкт з одним VLAN має залишатися з одним VLAN.
Запишіть, яка група портів змінилася і чому, у тому самому місці, де записано рядок проєкту. Саме ця пара робить можливим наступний аудит.
Тримайте об'єкти гостьової системи явними
Усередині Linux членство в мості й володіння адресою — окремі об'єкти, і їхнє змішування створює заплутаний напівробочий стан. Призначайте адреси інтерфейсу моста або маршрутизованому тунелю, а не обом бокам одного шляху, і тримайте порти-учасники вільними від IP-конфігурації.
Уникайте незалежного розміщення однієї підмережі на маршрутизованому TUN і на не пов'язаному інтерфейсі Ethernet. Така конфігурація створює два шляхи до одного префікса, асиметричні відповіді та гілку підтримки про flapping, де не згадано жодного зі шляхів. Якщо гостьова система також розміщує контейнери або локальний гіпервізор, перевірте, чи вони вже не мостять у той самий uplink. Два мости на одній NIC — це проєкт, а не аварія, яку ви хочете виявити у вікно змін.
Підтверджуйте шляхом пакета, а не ping
Перевіряйте фактичний шлях, а не лише доступність. З клієнта підтвердьте, яка адреса джерела приходить до віддаленого сервісу, потім що відповідь повертається тим самим шляхом. На гостьовій системі перевірте лічильники пересилання для конкретного потоку, а на групі портів підтвердьте, що не ввімкнено додаткової видимості понад потрібну обраному проєкту.
Насамкінець перевірте напрямок відмови. Зупиніть тунель або від'єднайте клієнта й переконайтеся, що трафік не падає тихо на маршрутизований шлях, який ви вважали невикористаним, бо саме це падіння робить мостовий проєкт тихим ненавмисним маршрутизатором.