Порты VMware ESXi: какие открывать для работы хоста и vCenter

Чтобы ESXi работал с vCenter и пускал администратора к управлению, на пути трафика должны быть открыты два порта: 443 (TCP, веб-интерфейс, API и vSphere Client) и 902 (TCP и UDP, связь vCenter с хостом и консоли виртуальных машин). Этого достаточно для базового управления одним хостом. Всё остальное - SSH, синхронизация времени, миграция vMotion, общее хранилище, кластер - добавляет свои порты по мере того, как вы включаете эти функции.

Ниже - полная таблица портов ESXi и vCenter с направлением трафика и назначением, разбор по задачам и то, что из этого нельзя выставлять в интернет. Статья пригодится, когда между администратором, vCenter и хостами стоит межсетевой экран (firewall) и нужно понять, какие именно порты на нём открыть.

Как устроен фаервол ESXi

Прежде чем открывать порты, стоит понять одну вещь: на ESXi нет «голого» списка правил, который вы редактируете руками. Фаервол хоста работает через профили сервисов. Каждой службе (SSH, vMotion, NFS, агент vCenter) соответствует свой набор портов, который открывается и закрывается вместе со службой.

Поэтому фраза «открыть порт 8000 на ESXi» на практике означает «включить службу vMotion» - и хост сам откроет нужный порт. По умолчанию закрыто почти всё: фаервол пускает только трафик включённых служб. Это удобно и безопасно: вы не держите открытым то, чем не пользуетесь.

У каждой службы можно дополнительно ограничить список разрешённых адресов - указать, из каких подсетей или VLAN к ней пускать. Это второй рубеж: даже если порт открыт, к нему достучится только админская сеть, а не весь мир.

Полная таблица портов ESXi

Здесь собраны порты, которые ESXi использует чаще всего. Направление - откуда и куда идёт трафик (вх. - хост принимает соединение, исх. - хост сам устанавливает).

Порты 5988/5989 и обнаружение служб по SLP (порт 427) в новых версиях ESXi отключены по умолчанию. Служба SLP выключена «из коробки» начиная с ESXi 7.0 Update 2c и ESXi 8.0, и это прямое следствие серии уязвимостей: именно через открытый наружу OpenSLP работал шифровальщик ESXiArgs, массово выкосивший хосты, торчавшие в интернет. Правило фаервола называется CIMSLP, и включают его только тогда, когда CIM-клиенту нужно найти хост автоматически. Если аппаратный мониторинг не используется, не трогайте ни 427, ни 5988/5989.

Порты vCenter и связка «хост - vCenter - клиент»

Управление в vSphere идёт по цепочке: администратор открывает vSphere Client в браузере, тот стучится в vCenter, а vCenter уже командует хостами ESXi. На каждом участке свои порты.

Администратор - vCenter: порт 443 (TCP). Это весь веб-интерфейс и API. Порт 80 только перенаправляет на 443.

vCenter - хосты ESXi: порты 443 и 902. По 443 идёт управление, по 902 vCenter шлёт данные на хост, а хост в ответ отправляет heartbeat по UDP 902. Если 902 заблокировать между vCenter и хостом, хост в интерфейсе будет «отваливаться» в статус «не отвечает», хотя сам работает.

Отдельно у vCenter Server Appliance есть порт 5480 (TCP) - это VAMI, интерфейс управления самой виртуальной машиной vCenter (обновления, сеть, сервисы). Его открывают только администраторам, не пользователям.

Если в инфраструктуре несколько vCenter в режиме Enhanced Linked Mode, между ними добавляются служебные порты репликации каталога (389, 636 и другие). Для одного vCenter они не нужны.

Порты под конкретные задачи

Базовое управление - это 443 и 902. Остальные порты появляются, когда вы включаете соответствующую функцию.

vMotion

Живая миграция виртуальных машин между хостами идёт по TCP 8000. Порт нужен в обе стороны между всеми хостами, которые участвуют в миграции. vMotion обычно выносят в отдельную сеть (VLAN) - и ради скорости (миграция забивает канал), и ради безопасности: служебный трафик переноса памяти виртуальных машин не стоит смешивать с пользовательским.

vSAN

Программное хранилище vSAN использует TCP 2233 для передачи самих данных и UDP 12321 для служебного обмена в кластере. Добавьте сюда TCP 8080 - по нему vSAN Vendor Provider общается с vCenter. Эти порты нужны только между узлами vSAN и почти всегда живут в выделенной сети хранилища, куда снаружи доступа нет.

Высокая доступность (HA) и Fault Tolerance

Кластер высокой доступности (HA) обменивается состоянием по порту 8182 (TCP и UDP) между хостами. Fault Tolerance, который держит синхронную копию виртуальной машины, добавляет 8100 и 8200. Все эти порты - внутрикластерные, наружу их выпускать не нужно.

iSCSI и NFS

Подключение внешнего хранилища идёт по TCP 3260 (iSCSI) или 2049 (NFS). Трафик хранилища, как и vMotion с vSAN, держат в отдельной сети: это и быстрее, и безопаснее.

Резервное копирование

Большинство систем бэкапа виртуальных машин (которые работают через vSphere API) забирают данные через уже знакомый порт 902 и управляющий 443. Отдельные порты под бэкап обычно не нужны - смотрите требования конкретного продукта, если он использует свой агент.

Что открывать на внешнем firewall, а что нельзя

Главное правило: порты управления ESXi и vCenter не должны смотреть в интернет. Ни 443, ни 902, ни 22. Хост виртуализации, доступный с любого IP, - это прямой путь к компрометации всей инфраструктуры: на ESXi регулярно находят уязвимости, а за ними охотятся шифровальщики.

Как сделать правильно для небольшой инфраструктуры:

• Управление - в отдельную сеть. Вынесите интерфейсы управления ESXi и vCenter в отдельный VLAN, куда нет доступа из пользовательской сети и тем более из интернета.
• Доступ - только из админской подсети или по VPN. Администратор подключается к vCenter через VPN либо с конкретных рабочих мест. На фаерволе разрешайте 443 и 902 только с этих адресов.
• Ограничьте список адресов на самих службах. В ESXi у каждой службы можно задать разрешённые подсети - используйте это как второй рубеж на случай ошибки в правилах фаервола.
• vMotion, vSAN, хранилище - в свои сети. Эти порты вообще не должны пересекаться с управлением и тем более выходить наружу.

Как посмотреть и изменить открытые порты

Состояние фаервола и список служб удобнее всего смотреть прямо в веб-интерфейсе хоста: Хост - Управление - Безопасность и пользователи - Профиль безопасности (в vCenter - в настройках хоста, раздел Firewall). Там видно, какие службы включены и какие порты они открывают, и там же задаются разрешённые адреса.

Из командной строки хоста (по SSH) тот же фаервол смотрят так:

• посмотреть правила: esxcli network firewall ruleset list
• разрешённые адреса службы: esxcli network firewall ruleset allowedip list
• выключить или включить правило: esxcli network firewall ruleset set -r CIMSLP -e false (вместо CIMSLP - имя нужного правила из первой команды, -e true включает обратно)
• какие порты хост реально слушает: esxcli network ip connection list | grep -i listen

Последняя команда полезнее, чем кажется: она показывает фактическую картину, а не то, что должно быть по профилю. Если служба включена, а порта в выводе нет - причина внутри хоста, и лезть в настройки внешнего фаервола бессмысленно.

Через PowerCLI список исключений фаервола по хосту достаётся командой Get-VMHostFirewallException.

Менять номера портов по умолчанию (например, увести 443 на другой) технически можно, но на практике это редко нужно и часто ломает совместимость с vCenter, бэкапом и плагинами. Гораздо надёжнее оставить стандартные порты и закрыть доступ к ним сетью.

Порт фаервола и портгруппа - это разные вещи

Слово «порт» в vSphere означает две совершенно разные сущности, и на этом регулярно спотыкаются.

Порт фаервола - это номер TCP или UDP, про который вся статья выше: 443, 902, 8000. Он про то, какой трафик пускать к хосту.

Портгруппа (port group) - это настройка виртуального коммутатора: именованная группа виртуальных портов с общими параметрами, к которой подключаются сетевые адаптеры виртуальных машин. Именно в ней задаётся VLAN, политика безопасности и балансировка. «Management Network» и «VM Network» - это портгруппы, а не порты фаервола. Число портов в портгруппе на стандартном коммутаторе в современных версиях выделяется динамически, поэтому вручную его задавать больше не нужно.

Посмотреть портгруппы хоста из командной строки:

• список портгрупп стандартного коммутатора: esxcli network vswitch standard portgroup list - покажет имя, коммутатор, число активных клиентов и VLAN ID
• сами коммутаторы: esxcli network vswitch standard list

Так что если задача звучит как «настроить транковый порт» или «поменять VLAN у машины» - это про портгруппы и коммутатор, и правила фаервола тут ни при чём.

Когда стандартного подхода не хватает

В свежих версиях vSphere часть системных служб нельзя ограничить по списку IP так же свободно, как пользовательские, - фаервол не даст сузить им доступ, потому что ими управляет сама система. Это нормально: такие службы обычно работают только внутри кластера, и их закрывают на уровне сети, а не правилами на хосте.

Ещё один частый случай - распределённый коммутатор и сторонние плагины (резервное копирование, мониторинг, NSX). Каждый из них может требовать свои порты. Перед внедрением всегда сверяйтесь с документацией конкретного продукта: универсального списка «открыть всё это» не существует, и открывать лишнее не нужно.

vCenter не подключается к хосту: чек-лист по портам

Если хост в vCenter висит как «не отвечает» или не добавляется, дело часто именно в портах. Что проверить по порядку:

1. Служба на хосте включена. В профиле безопасности ESXi проверьте, что нужная служба активна (для управления - порт 443 и агент на 902).
2. Внешний фаервол не режет 902. Это самая частая причина. Локально на хосте порт открыт, а маршрутизатор или межсетевой экран между vCenter и хостом его блокирует. Виноват обычно не ESXi, а сеть между ними.
3. Проверьте связь до порта - и по TCP, и по UDP. Порт 902 работает по обоим протоколам, и heartbeat, из-за которого хост уходит в «не отвечает», идёт именно по UDP. Проверка только TCP тут обманывает: она пройдёт успешно, а проблема останется. Как проверять - ниже, в разделе про UDP.
4. DNS и время. Хост и vCenter должны разрешать имена друг друга (порт 53) и иметь синхронное время (NTP, порт 123). Расхождение часов ломает доверие сертификатов, и хост не подключится, даже когда порты открыты.

Коротко

Для управления одним хостом ESXi хватает портов 443 и 902. vCenter добавляет к ним 443 и 902 в сторону хостов плюс 5480 для управления самим appliance. vMotion (8000), vSAN (2233, 12321, 8080), HA (8182), FT (8100/8200), хранилище (3260, 2049) подключаются по мере того, как вы включаете эти функции, и живут в отдельных сетях. Главное - не выставлять управление в интернет: доступ к vCenter и ESXi только из админской сети или по VPN.

Частые вопросы

Какой порт у ESXi по умолчанию?

Основных два: 443 (TCP) - веб-интерфейс, API и подключение vCenter; 902 (TCP/UDP) - связь с vCenter и консоли виртуальных машин. Порт 80 только перенаправляет на 443.

Можно ли изменить порт ESXi по умолчанию?

Технически да, но обычно не нужно и рискованно: смена портов ломает совместимость с vCenter, системами бэкапа и плагинами. Безопаснее оставить стандартные порты и закрыть к ним доступ на уровне сети.

Какие порты нужны для vMotion, vSAN и HA?

vMotion - TCP 8000, vSAN - TCP 2233, UDP 12321 и TCP 8080, высокая доступность (HA) - 8182 (TCP/UDP). Все эти порты нужны только между хостами кластера и наружу не выпускаются.

Как проверить, открыт ли порт до ESXi?

По TCP с администраторской машины: в Windows - Test-NetConnection адрес -Port 902, в Linux - nc -vz адрес 902. По UDP из Linux - nc -u -vz адрес 902; Test-NetConnection проверять UDP не умеет. Помните, что для UDP однозначен только отрицательный ответ: молчание означает и «открыт», и «пакет выброшен по дороге».

Через какой порт PowerCLI подключается к vCenter?

По тому же TCP 443, что и веб-интерфейс: Connect-VIServer идёт по HTTPS. Отдельный порт под PowerCLI открывать не нужно. Если сессия не устанавливается, а браузер к vCenter заходит, дело обычно в сертификате, а не в порте.

Какие порты использует VMware Tools?

Своих сетевых портов у VMware Tools нет. Гостевая система общается с хостом через внутренний канал VMCI на уровне гипервизора, и открывать под это что-либо на фаерволе не требуется. Сетевые порты нужны только тем функциям, которые ходят наружу сами, - например, если вы поднимаете в гостевой ОС собственный сервис.

Почему vCenter не подключается к хосту ESXi?

Чаще всего блокируется порт 902 на сетевом оборудовании между vCenter и хостом, либо разъехалось время и не сходятся сертификаты. Проверьте доступность 443 и 902 (и по TCP, и по UDP), работу DNS и синхронизацию по NTP.

Разбираетесь с виртуализацией VMware глубже? Загляните в смежные материалы: что такое ESXi и зачем он нужен, сравнение версий ESXi и их требования и как подобрать сервер под vSphere.