После того, как Вы установили на сервере Hetzner'a XenServer или иную ОС, Вы получаете 1 IP адрес, маску и шлюз. Поскольку для виртуальных машин необходимы отдельные адреса, у Вас есть возможность их заказать:
Для примера нам выделили 46.4.205.64/29. Как использовать все 8 адресов? Об этом ниже.
На XenCenter создаем дополнительную сеть:
Назначаем dom0 в этой подсети адрес из диапазона приватных адресов (в данном случае 172.16.1.1/24):
При создании новой VM в процессе настройки указываем, чтобы сетью выступала вновь созданная сеть Network 1:
Установка ОС в виртуальной машине может вызвать некоторые неудобства, если она будет нуждаться в интернете. Поэтому для Linux-дистрибутивов рекомендуется использовать полные образы, а не netinstall. Однако всегда для таких нужд можно заказать один дополнительный IP, и на момент установки использовать его (соответственно через сеть Network 0).
В процессе установки ОС при настройке сети указывайте IP из вышеупомянутого диапазона (в данном случае 172.16.1.0/24), к примеру 172.16.1.10/24 без указания шлюза.
После установки давайте назначим нашем виртуальной машине адрес 46.4.205.64:
— в настройках сетевого интерфейса (к примеру в debian):
iface lo inet loopback
auto eth0
iface eth0 inet static
address 172.16.1.10
netmask 255.255.255.0
auto eth0:0
iface eth0:0 inet static
address 46.4.205.64
netmask 255.255.255.255
— и пропишем маршрут в автозагрузке:
/sbin/ip route add default via 172.16.1.1 src 46.4.205.64
не забыв #chmod +x /etc/network/if-up.d/route
С этим, настройка сети виртуальной машины закончена. Осталось подкорректировать маршрутизацию на dom0.
Определяем uuid нашей сети (Network 1):
#xe network-list
Добавляем статический маршрут на нашу подсеть:
#xe network-param-set uuid=
uuid other-config:static-routes=46.4.205.64/29/172.16.1.1Проверочка:
46.4.173.64/29 via 172.16.1.1 dev xapi1
172.16.1.0/24 dev xapi1 proto kernel scope link src 172.16.1.1
<внешний адрес>/29 dev xenbr0 proto kernel scope link src <шлюз хетцнера>
Ну и в заключении:
Обмен пакетами с 46.4.205.64 по с 32 байтами данных:
Ответ от 46.4.205.64: число байт=32 время=40мс TTL=56
Ответ от 46.4.205.64: число байт=32 время=40мс TTL=56
Ответ от 46.4.205.64: число байт=32 время=40мс TTL=56
Ответ от 46.4.205.64: число байт=32 время=40мс TTL=56
Статистика Ping для 46.4.205.64:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 40мсек, Максимальное = 40 мсек, Среднее = 40 мсек
C:\Users\spacewalk>tracert 46.4.173.60
Трассировка маршрута к static.60.173.4.46.clients.your-server.de [46.4.173.60]
с максимальным числом прыжков 30:
1 1 ms 2 ms <1 мс 192.168.89.1
2 1 ms 1 ms 1 ms 213.231.0.200
3 2 ms 1 ms 1 ms odessa1-xe-0-0-0-931.ett.ua [80.93.126.69]
4 53 ms 34 ms 61 ms fft-od.ett.ua [80.93.127.238]
5 36 ms 45 ms 36 ms decix2-gw.hetzner.de [80.81.193.164]
6 40 ms 42 ms 40 ms core22.hetzner.de [213.239.245.17]
7 48 ms 42 ms 40 ms ex9k1.rz13.hetzner.de [213.239.229.150]
8 41 ms 40 ms 41 ms static.<внешний адрес>.clients.your-server.de [<внешний адрес>]
9 40 ms 40 ms 41 ms static.64.205.4.46.clients.your-server.de [46.4.
205.64]
Трассировка завершена.
Решение не привязано к конкретной платформе маршрутизации и ОС в виртуальных машинах, просто под рукой был такой набор ПО. Единственный вопрос — как это реализовать с виртуальной машиной Windows. Возможно в комментариях подскажут.
Экономьте адреса и спасибо за внимание.
Комментарии (25)
mxms
09.12.2016 14:02В сети /29 вы не сможете использовать все полученные 8 адресов подсети, а сможете только 6.
spacewalk
09.12.2016 14:04это решение обходит данную проблему
mxms
09.12.2016 14:08Гм. Не «по IP уставу» это.
spacewalk
09.12.2016 14:22по уставу) дело в том, что адреса прописаны с маской /32, это своего рода point-to-point
inkvizitor68sl
09.12.2016 15:44-1Угу, осталось теперь рассказать как-то всему интернету, что на адресе сети и на broadcast-адресе у вас хост, а не то, что там должно быть по стандартам.
И если с адресом сети попроще (в nix-ах как-то относительно подзабили на то, что этот адрес особенный), то вот с машиной на broadcast жить будет весело, ага.spacewalk
09.12.2016 16:26Понятия адреса сети и бродкаст адреса это исключительно понятия вашей сети. Для интернета эти адреса маршрутизируются одинаково. Если бы я использовал на клиентах в настройках сети 46.4.205.64/29, то для них существовал бы адрес сети .64 и броадкаст .72. А у меня /32. Для кого .72 является бродкастом?
inkvizitor68sl
09.12.2016 16:46> я использовал на клиентах
Всем по*й, как ты настроил «клиенты». Маршрутизацией сети 46.4.205.64/29 занимается вышестоящее железо. А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29.
Ну а вешать broadcast адрес на интерфейс — это вообще много ума иметь надо.spacewalk
09.12.2016 16:53> А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29
Можно ссылочку?inkvizitor68sl
09.12.2016 17:21+1https://tools.ietf.org/html/rfc2644, section 3, например.
spacewalk
09.12.2016 18:00+3помоему вы путаете. хетнцер дает мне 8 адресов, /29. я могу их использовать как мне удобно. могу организовать шлюз .65, «клиенты» 66-71. тогда у меня будет бродкаст 72, и данная рекомендация
>>https://tools.ietf.org/html/rfc2644
будет по отношению к этому шлюзу
>> дропать пакеты с src 46.4.205.64 и .72 для сети 46.4.205.64/29. понятие бродкаст адреса лежит в рамках одного бродкаст домена, а не всего интернета. завтра мне захочется поделить мою /27 на две /28 и у меня станет уже два бродкаста. И мне рекомендуют (https://tools.ietf.org/html/rfc2644) закрыть хождение пакетов от бродкаста через мой шлюз, потому что если извне через шлюз придет пакет с dest_ip бродкаста моей подсети, на него ответят все узлы этой подсети
представленная сеть не имеет шлюза, не имеет бродкаст-доменов в полном их понимании, там маршрутизируются /32 адреса и на крайний адрес ответит только он и никто больше, потому что пакет придет не через шлюз в бродкаст домен, он придет конкретно к узлу с адресом .72 или .64
mxms
09.12.2016 22:32Ещё раз подумал. В принципе, если в не будете организовывать именно подсети у себя и таковую не будет подразумевать маршрутизирующий вам этот диапазон IP софт, то, действительно, пофигу на бродкасты.
MeGaPk
09.12.2016 14:06А в XenServer починили OpenSwitch который вырубал на сервере инет, от любого школо доса?
Neris
09.12.2016 14:53Не так давно хецнер прилепили защиту от ддоса. Правда пока не понятно, на сколько эффективно она работает.
kotomyava
09.12.2016 15:22Защита от DDoS в исполнении Hetzner это нульроут на любой чих. =)
Что, в общем-то, и нормально за такие деньги.
mikeus
09.12.2016 17:02Не совсем понятно почему
#xe network-param-set uuid=uuid other-config:static-routes=46.4.205.64/29/172.16.1.1
а не сразу
#xe network-param-set uuid=uuid other-config:static-routes=46.4.205.64/29/172.16.1.10spacewalk
09.12.2016 17:03потому что это статический роут на всю подсеть /29 через интерфейс сети network 1, а этот интерфейс имеет адрес 172.16.1.1
mikeus
09.12.2016 18:51Я не знаток Xen, а подключать виртуалки к Network 0 и прописывать им эти белые адреса (т.е. без создания странной дополнительной Network 1) можно?
spacewalk
09.12.2016 21:08Задача Network 1 — организовать сетевую доступность между виртуальными машинами и dom0. Network 0 наверное можно было бы обойтись, если назначить alias интерфейсу xenbr0 с адресом приватной сети 172.16.1.1/24.
Но без использования приватной сети мне решения не видится
SLASH_CyberPunk
Простите, но где здесь экономия?
spacewalk
в интернете я встречал много мануалов, когда во второй сети самому xen'у назначается адрес из выделенной /29 подсети, и он является шлюзом. в этом случае теряется 3 адреса — адрес на xen'е + 2 (адрес подсети и бродкаст)
SLASH_CyberPunk
Я могу ошибаться, но прям у Hetzner в wiki это прописано…
Вы бы лучше расписали, как с одним белым айпи настраивать виртуалки и форвадить порты между внешкой и виртуалками…
spacewalk
В wiki как раз советуется путь через назначения одного из адресов шлюзом + 2 неиспользуемые.
От этого я и пытался уйти