Вопросы Теги

Проблема с маршрутизацией между VM's Hyper-V

Пост-ГРЭС-R выглядела многообещающей, но я не знаю, жив ли проект все еще.

1
задан 1 July 2009 в 01:39
1 ответ

Я полагаю, что реализация Microsoft NAT страдает от артефакта, который много реализаций NAT делают (более старая Cisco PIXOS, Linux ipchains - предшественник iptables) в том, что NAT только происходит на трафике, прибывающем в "общедоступный" интерфейс. Изм Cisco для этого поведения является "hairpinning" (я предполагаю, потому что пакет делает "крутой поворот" и листы через интерфейс, в который это ввело).

Вот analagous проблема:

Клиент сделал, чтобы Cisco ПРОИЗВЕЛА ПРОБУ МОНЕТ в краю их сети, делающей NAT между общедоступным статическим IP-адресом и их LAN. У них есть сервер HTTP на LAN в 192.168.1.1, и их общедоступный IP 172.18.9.1. Запрос от браузера, работающего на ПК на LAN к возвратам "http://172.18.9.1" "Страница, не мог быть отображен", потому что ЯЩИК ДЛЯ ПРОБНОЙ МОНЕТЫ реализация NAT не делает NAT трафик, прибывающий во внутренний интерфейс, направляющийся в 172.18.9.1 к 192.168.1.1.

Вот вопрос об Отказе сервера, который также описывает поведение, я говорю о (хотя, снова, не конкретно цитируя реализацию NAT Microsoft): Не мог соединиться на natted сервере от главного компьютера на том же IP-адресе общественности использования LAN

Я полагаю, что Вы видите подобное поведение с реализацией NAT Microsoft, но у меня нет веского доказательства (т.е. документация от Microsoft). У меня нет ресурсов для вращения тестовой машины под рукой, и Microsoft, кажется, не использует ключевое слово "шпильки" в их документации к положительному или отрицательному.

(Я на самом деле нахожу это довольно забавным в том вопросе об Отказе сервера, на который я ссылаюсь выше, что люди полагают, что отсутствие "hairpinning" "нормально". Linux iptables обработал бы то, что Вы делаете w/без проблем. Я всегда рассматривал реализации NAT, которые не могут обработать этот "hairpinning" для подчиненного.)

2
ответ дан 3 December 2019 в 22:54
  • 1
    Интересный... единственная странная вещь там - это, если действительно Hyper-V VM не знал о NAT' d адреса, как это способный связаться правильно с другим VM' s, которые имеют общедоступный IP' s указывающий на них, обеспечил те другие VM' s общедоступный IP находится на другой подсети? Когда Вы говорите " зафиксированный с IPTables, " Вы обращаетесь к добавлению статического маршрута? Какой маршрут Вы добавили бы? –  Adam Brand 1 July 2009 в 03:32
  • 2
    ре: Как доступ между общедоступными работами подсетей - К сожалению, это много к макету, чтобы сказать Вам наверняка. Это действительно бросает петлю в мою гипотезу что Windows NT can' t делают " hairpin" NAT. ре: Linux iptables - я говорил, что iptables несомненно может делать " hairpin" NAT. Если я настраивал поле, чтобы сделать что you' ре, делающее на Linux, I' d имеют несколько, общедоступный дюйм/с присвоил моему физическому NIC, и iptables сделает NAT. Я wouldn' t должен вставить любые статические маршруты для разрешения " hairpin" NAT для случая - это просто было бы. –  Evan Anderson 1 July 2009 в 06:40
  • 3
    I' ll помещают еще некоторую мысль в это и видят, могу ли я придумать разумное объяснение. Тем временем возможно, кто-то с более авторитетным знанием о внутренностях Windows NT приедет и разъяснит мне. –  Evan Anderson 1 July 2009 в 06:41

Теги

Похожие вопросы