Конфигурация сети виртуальной машины для маршрутизируемого режима на серверах Hetzner, OVH и Online.net противоречит интуиции, поскольку у вас есть сети, которые похожи на это:
Host IP: 192.168.0.2
Host Netmask: 255.255.255.0 (/24)
Host Gateway: 192.168.0.1
Guest IP: 10.0.0.1
Guest Netmask: 255.255.255.255 (/32)
Guest Gateway: 192.168.0.1
Guest MAC: 02:00:00:01:02:03
Приведенный выше пример является просто иллюстрацией, а не примерами IP-адресов, которые вы можете ожидать от любого из вышеупомянутых хостинг-провайдеров.
А? Какие? Как вы можете иметь подсеть только из одного IP-адреса (10.0.0.1/32)? Там нет места для ворот! Почему шлюз находится в другой подсети (192.168.0.0/24)?
Вот вопросы, которые заставляют Linux и Windows не проходить проверку работоспособности сети, поскольку сети для них не имеют смысла. Они думают, что ворота будут недоступны.
Hetzner, OVH и Online.net используют некоторые хитрости в сети, которые делают шлюз доступным в любом случае.
К счастью, как в Linux, так и в Windows вы можете переопределить проверки работоспособности и установить вышеуказанную конфигурацию интерфейса.
Возможные решения
Статическая адресация
Это проще всего сделать. Большая часть конфигурации, которую вам нужно сделать на хосте, - это создать мост.
хозяин
В Debian/Ubuntu, если ваш интерфейс управления / Интернет - это eth0 , вы можете отредактировать /etc/network/interfaces чтобы иметь мост br0 следующим образом:
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.0.2 # Host IP
netmask 255.255.255.0 # Host Netmask
gateway 192.168.0.1 # Host Gateway
metric 0
bridge_ports eth0
bridge_stp on
bridge_fd 0
bridge_maxwait 0
Запустите sudo service networking restart чтобы сетевая конфигурация начала действовать.
В RHEL/CentOS, если ваш интерфейс управления / Интернет - это eth0 , вы можете отредактировать /etc/sysconfig/network-scripts/ifcfg-eth0 для использования моста br0 следующим образом:
TYPE="Ethernet"
BOOTPROTO="none"
DEVICE="eth0"
ONBOOT="yes"
NM_CONTROLLED="no"
BRIDGE="br0"
Затем создайте новый файл /etc/sysconfig/network-scripts/ifcfg-br0 для настройки моста:
DEVICE="br0"
BOOTPROTO="static"
IPADDR="192.168.0.2" # Host IP
NETMASK="255.255.255.0" # Host Netmask
GATEWAY="192.168.0.1" # Host Gateway
ONBOOT="yes"
TYPE="Bridge"
NM_CONTROLLED="no"
Запустите sudo service network restart чтобы сетевая конфигурация вступила в силу.
Если вы остаетесь подключенным к вашему серверу, поздравляю, у вас есть рабочий мост!
гипервизор
На чистом Xen xl (libxenlight) это все, что вам нужно написать для конфигурации виртуального интерфейса:
vif=[ 'mac=02:00:00:01:02:03,bridge=br0' ]
Обратите внимание, что 02:00:00:01:02:03 - это MAC-адрес, который Hetzner, OVH или Online.net предоставили вам для гостевой сети, а br0 - это мост, который мы только что настроили выше.
Если вы используете libvirt, внутри <devices> добавьте этот интерфейс:
<interface type='bridge'>
<mac address='02:00:00:01:02:03'/>
<source bridge='br0'/>
</interface>
Как только вы настроите этот виртуальный интерфейс с правильным MAC-адресом и мостом, загрузите ваш гость и подключитесь к его консоли (xl console domU , virsh console domU или подключитесь к сеансу VNC гостя, если применимо).
гость
Здесь идет ужасная часть. Это зависит от операционной системы от того, как переопределить проверки работоспособности сети. Я расскажу о Debian/Ubuntu, RHEL/CentOS и Microsoft Windows NT.
В Debian/Ubuntu, если интерфейс называется eth0 , запишите это в /etc/network/interfaces:
auto eth0
iface eth0 inet static
address 10.0.0.1 # Guest IP
broadcast 10.0.0.1 # Guest IP
netmask 255.255.255.255
gateway 192.168.0.1 # Guest Gateway, a.k.a. Host Gateway
post-up route add 192.168.0.1 dev eth0
post-up route add default gw 192.168.0.1
pre-down route del 192.168.0.1 dev eth0
pre-down route del default gw 192.168.0.1
Команды iproute2 post-up и post-down сообщают операционной системе в любом случае применить шлюз, даже если он находится в другой подсети.
После запуска sudo service networking restart , вы должны быть в состоянии связаться с гостем через Guest IP 10.0.0.1 .
В RHEL/CentOS, если интерфейс называется eth0 , запишите это в /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE="eth0"
BOOTPROTO="none"
ONBOOT="yes"
USERCTL="no"
PEERDNS="yes"
TYPE="Ethernet"
NETMASK="255.255.255.255"
IPADDR="10.0.0.1" # Guest IP
GATEWAY="192.168.0.1" # Guest Gateway, a.k.a. Host Gateway
ARP="yes"
HWADDR="02:00:00:01:02:03" # Guest MAC
Затем напишите следующее в /etc/sysconfig/network-scripts/route-eth0:
192.168.0.1 dev eth0
default via 192.168.0.1 dev eth0
Этот файл говорит iproute2 применить шлюз в любом случае, даже если он находится в другой подсети.
После запуска sudo service network restart вы сможете подключиться к гостю через Guest IP 10.0.0.1 .
В Microsoft Windows NT перейдите в раздел "Сетевые подключения" на панели управления, щелкните интерфейс правой кнопкой мыши и выберите "Свойства". На вкладке "Сеть" выберите «Протокол Интернета версии 4 (TCP/IPv4)», затем нажмите "Свойства". Заполните поля, как показано:
Когда вы нажмете "ОК", вы получите это предупреждение:
Нажмите "ОК", чтобы подтвердить, что вы все равно хотите использовать шлюз.
Через несколько секунд вы сможете добраться до вашего гостя по гостевому IP 10.0.0.1 .
Динамическая адресация DHCP
К сожалению, это невозможно. Ни один DHCP-сервер не назначит вам 10.0.0.1/32 и сообщит вам, что шлюзом является 192.168.0.1 , даже если вы каким-либо образом перехватили DHCPDISCOVER гостя. И ни один DHCP-клиент не примет эту странную конфигурацию.
Вам нужна правильно структурированная сеть со шлюзом внутри вашей подсети для настройки DHCP. Единственный способ сделать это - создать частную сеть (172.16.0.0/12) и выполнить преобразование сетевого адреса между частным IP-адресом вашего гостя (172.16.0.2) и его общедоступным IP-адресом (10.0.0.1) через шлюз (172.16.0.1).
Частная сеть и NAT
Несмотря на то, что я проверил все вышеперечисленные шаги, я так и не смог создать индивидуальный / базовый NAT от частных IP-адресов до публичных IP-адресов. Частично причина в том, что для построения сетей нужно многое сделать.
Ваша сеть может выглядеть так:
Guest Public IP: 10.0.0.1
Guest Private IP: 172.16.0.2
Guest Netmask: 255.240.0.0 (/12)
Guest Gateway: 172.16.0.1
Затем узел будет пересылать трафик между гостевым общедоступным IP-адресом 10.0.0.1 и гостевым частным IP-адресом 172.16.0.2 через гостевой шлюз 172.16.0.1 .
OpenStack (который поддерживает Xen через libvirt) потенциально может обеспечить эту настройку NAT, а также DHCP-сервер в частной подсети через свою сетевую абстракцию, OpenStack Neutron, но сама настройка OpenStack - довольно сложная задача.
Мне удалось получить установку OpenStack с одним узлом и частные сети Neutron, работающие для экземпляров / гостей / серверов Nova, но я не мог понять, как преобразовывать частные IP-адреса (172.16.0.0/12) в NAT для внешних сетевых IP-адресов 10.0.0.1/32 , 10.0.0.2/32 и т.д.), Поскольку OpenStack не поддерживает нестандартную сетевую структуру Хетцнера, OVH и Online.net для готовых виртуальных машин. Это остается нерешенной проблемой.
Дополнительные ресурсы
