У нас есть несколько виртуальных машин на Windows 2008 Server (Hyper-V), и у нас возникла проблема с маршрутизацией между ними.
Настройка такова, что сервер Hyper-V запускает RRAS и сопоставляет IP-адреса своей сетевой карты внутренним IP-адресам (192.168.1.X), которые используют виртуальные машины. Виртуальные машины используют сервер Hyper-V в качестве шлюза для исходящего трафика. Причина такой настройки заключается в том, что наш интернет-провайдер назначает IP-адреса по MAC-адресу, поэтому в противном случае виртуальная машина не могла бы использовать внешний IP-адрес, назначенный серверу.
Проблема в том, что виртуальные машины не могут разговаривать друг с другом, используя свой внешний IP-адрес. Например, если сервер A - 4.2.2.1 (внешний IP-адрес) / 192.168.1.1 (внутренний IP-адрес), а сервер B - 4.2.2.2 (внешний IP-адрес) / 192.168.1.2 (внутренний IP-адрес), вы не сможете пинговать 4.2.2.2 из 4.2. .2.1. Вы МОЖЕТЕ пинговать 192.168.1.1 из 192.168.1.2. У нас также есть сервер C с номером 4.2.3.1 (другая подсеть), и эта машина не имеет проблем с проверкой связи с сервером A или сервером B. По сути, если машины не находятся в разных подсетях, они не могут общаться друг с другом.
Причина, по которой мы просто не используем 192.168.1.X для связи, заключается в том, что для этой конкретной цели мы настраиваем сервер мониторинга. Этот сервер мониторинга будет использовать полное доменное имя (например, servera.myservers.net), чтобы попытаться проверить связь с сервером B. Поэтому нам нужно знать, есть ли сбой DNS или что-то в этом роде.
Одна странность заключается в том, что если вы выполняете трассировку с сервера A на сервер C, вы получаете тайм-аут для первых двух попыток, а затем соединение, но вы не видите, что оно проходит через шлюз.
Я считаю, что реализация Microsoft NAT страдает от артефакта, который есть во многих реализациях NAT (более старые Cisco PIXOS, Linux ipchains - предшественник iptables) в том, что NAT выполняется только для трафика. прибытие на «публичном» интерфейсе. Cisco-ism для этого поведения - "шпилька" (я предполагаю, потому что пакет делает "шпильку поворота" и уходит через интерфейс, в который он вошел).
Вот аналогичная проблема:
У клиента есть Cisco PIX на границе своей сети, которая выполняет NAT между общедоступным статическим IP-адресом и его локальной сетью. У них есть HTTP-сервер в локальной сети по адресу 192.168.1.1, а их общедоступный IP-адрес - 172.18.9.1. Запрос от браузера, запущенного на ПК в локальной сети, на "http://172.18.9.1"возвращает" Страница не может быть отображена ", потому что реализация PIX NAT не выполняет NAT для трафика, поступающего на внутренний интерфейс, привязанный к 172.18.9.1 к 192.168.1.1.
Вот вопрос о сбое сервера, который также описывает поведение, о котором я говорю (хотя, опять же, без ссылки на реализацию NAT от Microsoft): Невозможно подключиться к серверу natted с главного компьютера в той же локальной сети, используя общедоступный IP-адрес
Я считаю, что вы наблюдаете аналогичное поведение с реализацией NAT от Microsoft, но у меня нет веских доказательств (например, документации от Microsoft). У меня нет ресурсов, чтобы развернуть тестовую машину под рукой, и Microsoft, похоже, не использует ключевое слово «шпилька» в своей документации как положительное, так и отрицательное.
(На самом деле я нахожу довольно забавным в том вопросе о сбое сервера, о котором я упоминал выше, что люди считают отсутствие «приколов» «нормальным». Linux iptables справится с тем, что вы делаете, без проблем. У меня всегда считал реализации NAT, которые не могут справиться с этим "приколом", хуже.)