Гостевая виртуальная машина CentOS Hyper V недоступна из Интернета
У меня есть виртуальная машина CentOS, сидящая на хосте HyperV с двумя интерфейсами, один интерфейс, подключенный к сети домена через коммутатор (192.168.1.8 / 24) GW 192.168.1.254. Другой интерфейс подключен непосредственно к межсетевому экрану (fortigate) (172.20.0.1/29) GW 172.20.0.254. Вышеуказанные интерфейсы также настроены как виртуальные коммутаторы Hyper-V на хосте.
Шлюзы - это интерфейсы, настроенные в настройке FW для разделения трафика.
172.20.0.x / 29 - сегмент публичного адреса, назначенный провайдером.
Гостевая виртуальная машина имеет два интерфейса eth0 (192.168.1.7/24), подключенных через 192.168.1.8 (виртуальный коммутатор) на хосте. И eth1 (172.168.0.2/29) подключен через 172.20.0.1 (виртуальный коммутатор) на хосте.
Проблема в том, что я могу пинговать оба интерфейса виртуальной машины с хоста и с брандмауэра. Но я не могу пинговать eth1 (172.20.0.2) из Интернета, но могу подключиться к интерфейсу хоста 172.20.0.1 из Интернета.
Обратите внимание, что гостевая виртуальная машина CentOS может проверять связь с ресурсами локальной сети и выходить в Интернет с помощью проверки связи источника с обоих интерфейсов.
Когда я отслеживаю маршрут к обоим адресам 172.20.0.1 и 172.20.0.2 с внешнего IP-адреса источника на AWS. Я могу достичь 172.20.0.1 (интерфейс хоста). Маршрут к 172.20.0.2 (интерфейс виртуальной машины) завершается непосредственно перед брандмауэром извне.
Мой ход мыслей теперь наводит меня на мысль, что есть дополнительная настройка, которую необходимо выполнить на FW, может быть, добавить статический маршрут в FW, ретранслирующий трафик непосредственно на виртуальную машину? Есть предположения? Я просто хочу убедиться, прежде чем приступить к выполнению этого упражнения.
Это очень необычная конфигурация, и у вас есть некоторые ошибки и / или опечатки.
Обычный способ сделать это - настроить коммутаторы Hyper-V как внешние коммутаторы. Это позволяет виртуальным сетевым адаптерам виртуальной машины напрямую общаться с другим сетевым оборудованием. Например. 192.168.1.7 будет разговаривать с 192.168.1.254. Хосту вообще не нужно иметь сетевой адаптер или IP-адрес с 192.168.1.8. Аналогично для подсети 172.20.0.0. Я подозреваю, что у вас может быть внутренний виртуальный коммутатор, настроенный как NAT с плохой подсетью.
Вы упомянули 172.168.0.2/29, что, как я полагаю, является опечаткой 172.20.0.2/29. Однако 172.20.0.2/29 охватывает только адреса 172.20.0.0-172.20.0.7, в то время как вы указываете шлюз как 172.20.0.254. Поскольку шлюз не находится в подсети, этот интерфейс не может маршрутизировать к нему. Это заставляет меня думать, что 172.20.0.1, которого вы достигли, не является вашим хостом, а на самом деле является другим интерфейсом на брандмауэре или маршрутизаторе.
Вы упомянули, что 172.20.0.0/29 назначается поставщиком Интернет-услуг, но вы пометили маршрутизатор снаружи, а за ним брандмауэр и виртуальную машину с той же подсетью. Маршрутизатор и брандмауэр обычно должны иметь внутреннюю подсеть, отличную от внешней. Похоже, вы пытаетесь использовать ту же подсеть между хостами и межсетевым экраном, которая также используется между межсетевым экраном и маршрутизатором. Хотя существуют такие межсетевые экраны, которые действуют как прозрачные мосты, гораздо чаще используются маршрутизированные сегменты.
В целом мне интересно, что вы пытаетесь сделать. Множественная адресация с несколькими адаптерами в разных подсетях - относительно редкое явление, и размещение компьютера как во внешнем Интернете за брандмауэром (назовем его DMZ), так и во внутренней локальной сети - очень плохая практика безопасности. Гораздо проще сделать это с одним адаптером и DMZ или одним адаптером и NAT, а затем позволить межсетевому экрану или маршрутизатору маршрутизировать между подсетями DMZ и LAN.
У вас не может быть двух шлюзов по умолчанию на одной машине, другой становится избыточным. вы можете разделить трафик и направить его напрямую от интерфейса хоста к Интернету.