Vmware esxi nat настройка
VMware настройка сети. Настройка виртуального коммутатора.
Выбираем наш единственный виртуальный коммутатор и нажимаем на значок сетевой карты
В открывшемся окне видим, что у нас сейчас активен один сетевой адаптер vmnic0. Жмем на зеленый плюс, чтобы добавить второй
Видим нашу вторую сетевуху, выбираем ее и группу адаптеров, в которую нужно ее добавить(в нашем случае Active adapters).
Active adapters — сетевая карта будет использоваться
Standby adapters — сетевая карта будет задействована в случае выхода из строя основной
Unused adapters — сетевая карта не будет использоваться.
На следующем экране видим, что наши адаптеры находятся в группе активных(можно поменять группу адаптера с помощью синих стрелок, а также удалить адаптер или добавить еще).
Жмем ОК и видим, что теперь в нашем свиче два сетевых адаптера(у меня подключен только один, поэтому VMware «сигналит», что отказоустойчивость потеряна.
В виртуальных свичах VMware есть сеть для виртуальных машин VM Network(сюда подключаются виртуальные машины) и VMkernel, предназначенный для служебного трафика(Management, VMotion, iscsi и т.п.).
Давайте настроим наш управляющий интерфейс, который используется для управления хостом.
Выделяем окно с заголовком Management Network и нажимаем на карандаш для редактирования.
В настройках Management Network вы можете изменить название сети, VLAN(если используется), настройки безопасности, traffic shaping(в стандартном свиче ограничивается только исходящий трафик) и режим файловера и балансировки нагрузки.
Настройка правил Firewall
По умолчанию в пункте default rule for ingress traffic выбрана опция Deny, т. е. Firewall будет блокировать весь трафик.
Чтобы добавить новое правило, нажмите +. Появится новая запись с названием New rule. Отредактируйте ее поля в соответствии с вашими требованиям.
В поле Name задайте название правила, например Internet.
В поле Source введите необходимые адреса источника. По кнопке IP можно задать единичный IP-адрес, диапазон IP-адресов, CIDR.
По кнопке + можно задать другие объекты:
- Gateway interfaces. Все внутренние сети (Internal), все внешние сети (External) или Any.
- Virtual machines. Привязываем правила к определенной виртуальной машине.
- OrgVdcNetworks. Сети уровня организации.
- IP Sets. Заранее созданная пользователем группа IP-адресов (создается в Grouping object).
В поле Destination укажите адрес получателя. Тут такие же опции, как и в поле Source.
В поле Service можно выбрать или указать вручную порт получателя (Destination Port), необходимый протокол (Protocol), порт отправителя (Source Port). Нажмите Keep.
В поле Action выберите необходимое действие: разрешить прохождение трафика, соответствующее этому правилу, или запретить.
Применяем введенную конфигурацию, выбрав пункт Save changes.
Примеры правил
Правило 1 для Firewall (Internet) разрешает доступ в Интернет по любым протоколам серверу с IP 192.168.1.10.
Правило 2 для Firewall (Web-server) разрешает доступ из Интернета по (ТСР-протокол, порт 80) через ваш внешний адрес. В данном случае – 185.148.83.16:80.
NAT (Network Address Translation) – трансляция приватных (серых) IP-адресов во внешние (белые), и наоборот. Благодаря этому процессу виртуальная машина получает доступ в Интернет. Для настройки этого механизма нужно настроить правила SNAT и DNAT.
Важно! NAT работает только при включенном Firewall и настроенных соответствующих разрешающих правилах.
Создание правила SNAT. SNAT (Source Network Address Translation) – механизм, суть которого состоит в замене адреса источника при пересылке пакета.
Сначала нужно узнать доступный нам внешний IP-адрес или диапазон IP-адресов. Для этого зайдите в раздел Administration и кликните дважды на виртуальный дата-центр. В появившемся меню настроек перейдите во вкладку Edge Gateways. Выберите нужный NSX Edge и кликните на него правой кнопкой мыши. Выберите опцию Properties.
В появившемся окне во вкладке Sub-Allocate IP Pools вы сможете посмотреть внешний IP-адрес или диапазон IP-адресов. Запишите или запомните его.
Дальше кликните на NSX Edge правой кнопкой мыши. В появившемся меню выберите опцию Edge Gateway Services. И мы снова в панели управления NSX Edge.
В появившемся окне открываем вкладку NAT и нажимаем Add SNAT.
В новом окне указываем:
- в поле Applied on – внешнюю сеть (не сеть уровня организации!);
- Original Source IP/range – внутренний диапазон адресов, например, 192.168.1.0/24;
- Translated Source IP/range – внешний адрес, через который будет осуществляться выход в Интернет и который вы посмотрели во вкладке Sub-Allocate IP Pools.
Создание правила DNAT. DNAT – механизм, изменяющий адрес назначения пакета, а также порт назначения. Используется для перенаправления входящих пакетов с внешнего адреса/порта на приватный IP-адрес/порт внутри частной сети.
Выбираем вкладку NAT и нажимаем Add DNAT.
В появившемся окне укажите:
— в поле Applied on – внешнюю сеть (не сеть уровня организации!);
— Original IP/range – внешний адрес (адрес из вкладки Sub-Allocate IP Pools);
— Protocol – протокол;
— Original Port – порт для внешнего адреса;
— Translated IP/range – внутренний IP-адрес, например, 192.168.1.10
— Translated Port – порт для внутреннего адреса, в который будет транслироваться порт внешнего адреса.
Применяем введенную конфигурацию, выбрав пункт Save changes.
Дальше на очереди инструкция по DHCP, включая настройку DHCP Bindings и Relay.
ESX doesn’t have NAT inbuilt, so here’s how to configure it with the help of a VMware appliance called pfSense (an Open Source firewall/router).
There are three components in this setup:
- Host
- router/pfSense
- NAT Client
A great read for beginners and those refreshing is the VMware Virtual Networking Concepts whitepaper
Now lets create a network that our NAT’ed VMs will be using.
When prompted under Connection Type, select a ‘VM Network’, as this is for the typical traffic within the Virtual Machine (not IO or management of your machines).
Lets create a vSwitch that doesn’t connect to anything, a dud, a blankie. This will be our NAT’ed environment. It’s quite important that you DON’T connect a network card to this vSwitch to prevent any inadvertent DHCP leakage. Make sure you have nothing selected.
Give it a name to differentiate.
Once you’re done, click finish and you will have something two network available to your VMs:
Time to setup pfSense. Once you’ve downloaded and extracted it. You have the option of either copying it directly to your datastore and then adding directly to inventory, or importing via the Standalone Converter. I find the latter is always faster.
router/pfSenseIncase you’re converting pfSense first (like I did whilst re-doing it for this post), I recommend you disable the network interfaces until you’ve finished setting up the host networks. We’ll enable these in a later step.
Once the conversion is complete, time to configure our virtual router. pfSense is provided with two NICs out of the box. One for the WAN interface (which is your internal LAN), and one for ‘its’ LAN - the one on which it will be servicing DHCP requests.
Mark down the last 4 digits of the MAC address, these will help to validate the following step.
Configuring pfSense NICs
Start the pfSense VM. You will be guided through the mapping of the interfaces, and just to make sure - check to see the MAC addresses matching to the VM Network (in my case 67:3c) and NAT Network (67:46).
Upon following the wizard, and if you’ve followed everything accordingly (or rather I documented the steps properly) you will be shown the interfaces within pfSense, their mapping (WAN vs LAN) and IP addresses.
You are now ready to assign clients on this host to the NAT Network and have them pick up addresses dished out by your shiny new appliance.
The whole setup takes just under 5 minutes from start to finish to complete.
Сети виртуальных машин.
Сеть виртуальных машин создается аналогично, только в мастере нужно выбрать Virtual Machine Port Group
Выбрать или создать VSwitch
указать название сети и VLAN
и завершить создание
После этого в нашем виртуальном коммутаторе появится еще одна сеть виртуальных машин и в настройках виртуальных машин станет доступно подключение к этой сети.
Дополнительный виртуальный коммутатор можно создать при создании VMkernel или VM Network. Как я уже говорил, наличие физического сетевого адаптера требуется только, если ВМ должны иметь доступ к внешним ресурсам(находящимся не на данном хосте ESXi).
Ну вот вкратце и всё по настройке сети VMware. Если что-то осталось не рассмотренным или непонятным, пишите в комментариях, — будем дополнять.
Часть первая
После небольшого перерыва возвращаемся к NSX. Сегодня покажу, как настроить NAT и Firewall.
Во вкладке Administration перейдите в ваш виртуальный дата-центр – Cloud Resources – Virtual Datacenters.
Выберите вкладку Edge Gateways и кликните на нужный NSX Edge правой кнопкой мыши. В появившемся меню выберите опцию Edge Gateway Services. Панель управления NSX Edge откроется в отдельной вкладке.
Выводы
Этот сервер у меня уже с конца января 2011 года. Чего я на нем только не перепробовал делать/пробовать. И разные сервисы, и Gentoo, и FBSD, и GlassFish, и фаирволы/нат, FireFox на виндовой машине через SSH + XMing и т.п. И все это в одной машине. Теперь я с уверенностью могу заявить, что виртуализация — это круто. К сожалению пока еще не удалось попробовать KVM и XEN (лайв сиди с XEN не в счет — нужно ручками пощупать), но запускать на виртуальной машине еще один гипервизор… даже для моего извращенного мозга, это слишком. Видимо просто не пришло его время.
Скоро придет из другого Китая USB звуковуха, и у меня появится навороченный будильник с управляемым производственным календарем из 1Ски. ^_^
В общем и целом, у кого есть возможность поставить сие чудо на выделенную машину — дерзайте. Возможно кому-то этот топик поможет настроить сервер на работе. Так или иначе, буду рад, что помог.
Спасибо за внимание.
P.S. Я не претендую на 100% защищенность данной схемы, но она куда лучше открытых портов, успокаивает мою параною и дает неоценимый опыт длительного использования. Само собой, стандарные порты на конечных серверах изменены, где это возможно. Не хватает блока по IP адресам злостных брутфорсеров, но это еще все впереди.
UPD: Прошу прощения, если не верно выбрал блог. Ткните, пожалуйста, носом куда лучше его поместить?
Для этого выбираем наш хост, жмем на вкладку Configure, и в разделе Networking выбираем Virtual Switches.
Поскольку у нас на хосте имеется два сетевых адаптера(как установить драйвер на неподдерживаемую сетевую карту мы рассматривали в статье), давайте добавим нашу сетевую карту в виртуальный свич и настроим так называемый тиминг(объединение сетевых интерфейсов).
Виртуальных коммутаторов на хосте может быть несколько. Если вы хотите, чтобы ваши виртуальные машины находились в изолированной сети, можно создать виртуальный коммутатор, не используя сетевые адаптеры.
Ну а мы рассмотрим настройку обычного виртуального свича.
Организация сети в виртуальной среде ESXi на Hetzner
При подключении машин в виртуальной инфраструктуре VMware ESXi выполз тот момент, о котором я не задумывался в офисе – ESXi не умеет самостоятельно рутить пакеты, а также не поддерживает функционал NAT, который имеется в VMware Workstation.
Поэтому для того, чтобы вируальные машины увидели мир, их надо:
- либо вешать на реальные IP адреса, что у Хетзнера несколько накладно, т.к по дешману дополнительно отслюнявливают только 3 штуки (1IP уже изначально занят под сам сервер ESXi), остальные надо докупать в составе FlexiPack, т.к совокупная стоимость владения /27 сеткой получается порядка 1.33 евро за IP;
- либо поднимать виртуальный рутер, который одной картой смотрит наружу через реальный IP, который вешается на отдельный MAC-адрес, а второй картой смотрит в виртуальную сеть.
Поскольку торговых терминалов предполагалось порядка 10-15 штук на каждом сервере, то я решил идти путем маршрутизации. Для чего заказал дополнительно несколько IP адресов, завел виртуальную машину под FreeBSD, назначил ей один физический интерфейс и один виртуальный, после чего прописал ей MAC-адрес, выданный Hetzner, на физику для того, чтобы реальный IP подхватывался интерфейсом и поднял на ней NAT и Firewall, дополнительно прикрыв инфраструктуру от внешних атак, в добавок к host-based IPS которые я ставлю на рабочие станции.
В принципе нарезать можно любое количество VLAN, знай только подрубай виртуальные интерфейсы к рутеру, да настраивай раздачу IP клиентским машинам через DHCP. Подумываю поковырять на счет HA кластера для ESXi, тем более что такая возможность есть, но для его построения необходимо также поднимать vCenter, что требует отдельного времени на изучение лицензирования всего этого зоопарка.
Получилось более чем приятно, т.к тестовые машинки просто лётают только в путь, т.ч даже появились алчные мыслишки- не забарыжить ли подобным решением в паблики, т.к народ частенько шукает по инету виндовые станции.
На хабре много статей, про то настройку тех или иных кусочков домашнего сервера. Хотелось бы поделиться еще одним вариантом построения домашней сети, нацеленной на сисадмина или разработчика. На этот раз на базе ESXi.
Кого заинтересовало — добро пожаловать под кат.
Я не буду рассказывать про установку и настройку ESX и гостевых систем, ибо в сети полно статей на эту тему, да и документация на официальном сайте вполне приличная. А расскажу я некоторые идеи, которые я реализовал дома и некоторые тонкости. Но обо всем по порядку.
Начнем с самого сервера — IBM System X3200 M2. Достался он мне практически даром. Узнал от друга, что его друг продает какой-то сервер. Созвонились, встретились, и — вуаля, сервер после небольшого моддинга, занял почетное место старой машинки на базе еще Celeron'a 1.8. Должен отметить правда, что корпус был слегка помят, а именно, не хватало нижней части передней крышки, а внутри не было оперативной памяти вообще. Но это мелочи. Сложнее оказалось достать 2 недостающие салазки в корзину. В городе в прямой продаже нет, в специализированных магазинах под заказ — ждать 1.5 мес и сумма 1.5к за штуку… отказался от этой идеи. Заказал с Китая за 500р с доставкой, пришли за те же 1.5 мес.
Итого имеем:
- Сервер IBM System X3200 M2
- Intel® Xeon® X3320 2.5GHz
- 4Г DDR2 800MHz
- 5 жестких дисков общим объемом около 2TB (без рейда)
- ESXi
- Ноутбук Asus F3SE (заменяет мне комп — стационарной машины, кроме сервера у меня нет, фактически, это мое рабочее место и средство для развлечений),
- Точка доступа LinkSys WRT54GS v7 (WAN, 4xLAN 100Mb,WiFi), перепрошитая с dd-wrt micro (эх, сколько мы с ней пережили :) ),
- Телефон с WiFi — Nokia E52.
Цели конечной системы:
- Максимально разгрузить ноутбук по программному обеспечению,
- Предоставить платформу для разработки и тестов (схема примерно такая: установил, настроил, попробовал, выключил; когда понадобилось — включил заново),
- Вместе со смотрящими в сеть сервисами, обеспечить корпоративный уровень защиты сервера и данных. В случае дилеммы «функционал/безопасность» выбирать безопасность.
Итак, приступим к самой интересной части. С этого момента будем считать, что сервер подключен к сети, функционирует 24/7, есть безлимитный интернет, установлен ESXi, создано несколько гостевых систем (win2k8 — 1шт, winxp — 1шт, Fedora 14 — N шт в минимальной конфигурации, или любой другой дистрибутив по вкусу и цвету), если где-то что-то запускается (mc, nano, sudo и прочее), то подразумевается, что оно уже установлено.
Шаг 1. Выбор функционала
- Веб сервера (Apache, IIS, GlassFish/Tomcat),
- СУБД (MSSQL, MySQL, FireBird, PostgreSQL),
- Torrent-клиент, FlyLinkDC клиент,
- SSH доступ ко всем linux-серверам, RDP до одного из Win серверов,
- Файловое хранилище.
Шаг 2. Архитектура сети
И вот что у нас примерно должно получиться:
Хочу сразу предостеречь уважаемых хабровчан от холивара на тему организации данной сети, она продиктована некоторыми субъективными требованиями, и, пока что, изменяться может только виртуальная ее часть. Простите, но «так исторически сложилось». Однако, конструктивная критика приветствуется. Учту в дальнейшем.
Как видно из диаграммы, из всех виртуальных машин, к физической сети подключена только одна — GALAXY. Этот сервер будет являться шлюзом ко всем виртуальным машинам, будет следить за доступом к важным портам (SSH, RDP) а также вести разнообразные логи.
Шаг 3. Настройка шлюза
Не мудрствуя лукаво, выложу конфиг фаирвола со своего шлюза, с небольшими изменениями. Само собой, все интерфейсы подняты, настроены статические IP, прописаны DNSы, шлюзы, на точке настроен необходимый NAT. Прошу прощения, но все IP и порты заменены или затерты. В этом плане — я параноик если что. :)
modprobe ip_nat_ftp
modprobe ip_conntrack_ftp
modprobe nf_conntrack_tftp
$ -F -t nat
$ -F -t filter
$ -F -t mangle
По аналогии с сервером VENERA, настраиваем остальные сервера, включая и исключая нужные порты правилами. Обращу Ваше внимание, что блоке nat venera закомментирована 3я строчка.
Она разрешает соединения к SSH порту 12121. Закомментирована она по описанной ниже причине.
Шаг 4. Паранойя
Кульминацией сего повествования, является реализация техники port knocking.
Возможно кто-либо из вас сталкивался с этой темой, но по тем или иным причинам отбросил ее реализацию. Кому лень Кто не может сходить по ссылке выше, в двух словах расскажу что это и с чем едят. Эта техника позволяет открывать нужный порт, только после того, как с этого же IP постучались на некую последовательность портов. Причем порты из этой последовательности могут быть даже не открыты. Достаточным признаком, является посылка на этот порт пакета с флагом SYN ( ну или другого, по вашему усмотрению). После того как последовательность верно активирована, выполняется команда, открывающая нужный порт в фаирволе. чтобы закрыть этот порт, нужно, согласно этой же технике, постучаться таким же образом на другую последовательность портов.
Само собой «все уже украдено до нас» (С). Существует демон knockd и клиент вместе с ним, реализующий данный функционал.
Все было бы достаточно просто, если бы я не столкнулся со странной проблемой. Бинарника под RPM системы нет (ткните носом, пожалуйста, если я плохо искал).
Качаем исходники, распаковываем.
и все заработало :)
Кстати, с форумов народ пишет, что под FreeBSD ставят без проблем из портов, но я на своей (да, есть у меня и такая виртуалка для тестов) не пробовал. Отпишитесь, пожалуйста, об объективных результатах с последней версией.
Документация к knockd неплохая. Демон простой, удобный, проверил — работает. Так что, с Вашего разрешения, описывать его не буду, но приведу примерный конфиг для данного случая с фаирволом для полноты картины:
[options]
logfile = /var/log/knockd.log
[openSSH]
sequence = порт1,порт2,порт3
seq_timeout = 5
command = /sbin/iptables -A FORWARD -s %IP% -p tcp --dport 8080 -j ACCEPT
tcpflags = syn
[closeSSH]
sequence = порт3,порт2,порт1
seq_timeout = 5
command = /sbin/iptables -D FORWARD -s %IP% -p tcp --dport 8080 -j ACCEPT
tcpflags = syn
Дома использую несколько последовательностей для открытия разных портов к разным виртуальным машинам. К сожалению, порты выбрал только TCP, ибо с ними можно соединяться простым telnet'ом. Но как только разберусь с мобильным клиентом knockd для UDP, обязательно все сделаю как нужно.
На остальных виртуальных машинах заводим необходимые службы, настраиваем все как нам нравится. Не забываем пробросить через виртуальный шлюз нужные порты, и прописать нечто в /etc/knockd.conf, если необходимо. Пользуемся.
Интерфейсы VMkernel.
Думаю, нужно еще рассмотреть настройки интерфейса VMkernel, используемого для служебных нужд.
Интерфейсов VMkernel может(и должно) быть несколько, чтобы разделить трафик управления от, например, трафика iscsi. Желательно, чтобы это были физически разделенные сети, ну или, хотя бы, на уровне VLANs.
Давайте настроим несколько таких интерфейсов.
Выбираем в секции Networking вкладку VMkernel adapters, выделяем пока единственный vmk0 и жмем карандаш для редактирования
В открывшемся окне на первой вкладке выбираем тип трафика, который разрешен на этом интерфейсе(давайте разрешим здесь еще VMotion — трафик миграции ВМ).
На других вкладках этого мастера можно изменить такие настройки как MTU, настройки IPv4 и IPv6.
После нажатия ОК настройки будут сохранены.
Теперь давайте создадим еще один VMkernel для трафика, например Fault Tolerance. Настройка сети для трафика хранилищ iscsi описана в статье Как подключить iscsi-lun к хосту esxi.
Итак, жмем на глобус с плюсом, чтобы добавить новый адаптер VMkernel
Выбираем тип VMkernel Network Adapter
Выбираем, использовать имеющийся или создать новый виртуальный коммутатор(мы выберем наш единственный). Жмем Next.
На следующем экране задаем имя нашего адаптера, выбираем какой версии протокол IP будет использоваться и какой трафик
Указываем сетевые настройки(статика или DHCP)
На завершающем экране мастера проверяем настройки и жмем Finish.
Видим, что теперь у нас появился второй VMkernel адаптер, который будет использован для передачи трафика Fault Tolerance logging.
Читайте также: