Я запускаю Windows Server 2008 R2, у нас есть приложение, которое подключается (привязывается к) общедоступному IP-адресу на сервере к 127.0.0.1:8334 [подключается к службе, прослушивающей 0.0.0.0:8334]
В Windows 2003 с этим не было проблем. Мы можем подключиться с помощью TCP от 1.2.3.4 [например] до 127.0.0.1:8334.
В Windows 2008 мы обнаружили, что TCP-соединения с общедоступного IP-адреса, например От 1.2.3.4 до 127.0.0.1:8334 даже не получится. но служба принимает соединения от 127.0.0.1 до 127.0.0.1:8334 и от 127.0.0.1 до 1.2.3.4:8334.
Пытался отключить брандмауэр Windows, настроить его ведение журнала и т. Д. (Никаких полезных записей в журнале не обнаружено), но безрезультатно. Это проблема нового сетевого стека?
правки
1.2.3.4 пытается подключиться к localhost [127.0.0.1] на том же компьютере
Файл Hosts - это файл хоста Windows 2008 по умолчанию.
Информация о петлевой проверке, интересно. Пробовал ... не сработало. Перекрестная проверка, чтобы убедиться, что я все сделал правильно - у меня.
Мне интересно, есть ли решение, использующее NAT или какой-либо другой способ переадресации портов - если я перенаправлю 127.0.0.1:port на 1.2.3.4:port, это сработает? Учитывая, что приложение прослушивает 0.0.0.0:port, оно будет принимать соединения на 1.2.3.4:port.
Файл HOSTS действительно содержит localhost 127.0.0.1, однако файл hosts используется только при поиске имени хоста. В этом случае наше приложение не будет искать имя хоста, поскольку IP-адрес 127.0.0.1 жестко запрограммирован в нем (а не в имени хоста localhost). Таким образом, файл HOSTS здесь не пригодится.
Что касается портов выше 1024 [вы, возможно, имеете в виду проблему MaxUserPort?] Я проверил это, попробовав простое подключение к порту 445 - работает с 127.0.0.1, не работает, когда я подключаюсь с исходного IP 1.2.3.4. 445 - это стандартная служба Windows, поэтому она должна работать!
В настоящее время на машине не запущен NAT или RRAS ... было интересно, есть ли способ выполнить перенаправление - я предполагаю, что это не сработает, поскольку стек TCP / IP отклонит пакет до того, как он достигнет интерфейса обратной связи для перенаправления.
Печать маршрута, которую я проверил - кажется, все в порядке, сначала маршрутизируются общедоступные IP-адреса, затем, наконец, сетевая маска 127.0.0.0 255.255.255.0 и 127.0.0.1 сетевая маска 255.255.255.255 оба в loopback.
редактировать Кажется, я нашел ответ на вопрос о причине проблемы. Я использовал eventvwr.msc, включил ведение журнала Winsock, отключил другие службы, просто попробовал этот тест подключения. Получил ошибку, которая в шестнадцатеричном виде сопоставлена с STATUS_INVALID_ADDRESS_COMPONENT, когда я ее искал.
Это заставило меня: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Это подтвердило, что это конструктивное изменение в WFP для Vista / 7 / Server 2008 [платформа фильтрации Windows].
[См. Ответ Анупамы Васантха]
Похоже, мне придется пойти тяжелым путем и переписать код [сложно, потому что это означает иметь дело с менеджерами!]
Спасибо, что помогли мне найти / подтвердить проблему!
Не забывайте, что в Windows 2008 брандмауэр включен по умолчанию. Это потенциально может заблокировать любой и весь трафик даже на интерфейсе обратной связи. Кроме того, если вы привязываетесь к 0.0.0.0, вы принимаете соединения на ВСЕХ интерфейсах. Брандмауэр все равно заблокирует это. Вы можете попробовать выключить брандмауэр во время тестирования ... а затем снова включить. У меня не было проблем с подключением к различным программам, которые я разработал на 127.0.0.1.
Попробуйте подключиться к 127.0.0.2 в Vista / win2k8 и выше - звучит забавно, но работает. Были положительные результаты в прошлом
Я почти уверен, что это связано с функцией безопасности проверки обратной петли, хотя я не могу подробно узнать, как она реализована, только как ее преодолеть:
http://chillicode.wordpress.com/tag/loopback-check/
А для "ПРИМЕНЯЕТСЯ К" Windows 2008 см. http://support.microsoft.com/kb/896861
Что именно находится в вашем файле HOSTS? У меня нет W2008. Вы имеете в виду, что там нет "127.0.0.1 localhost"?
Я также где-то читал, что настройка W2008 по умолчанию не позволяет связываться с портами больше 1024.
Вы можете отправить отзыв о MS Windows Server 2008 непосредственно команде MS через
и они ответят
Если вы пытались отключить «кольцевую проверку» методом редактирования реестра, то потребуется перезагрузка. Другой - нет.
NAT внутри машины? 127.0.0.1 не пересылается и не маршрутизируется, я думаю, это внутреннее устройство, вы можете отключить сетевую карту, ваша 1.2.3.4 исчезнет, но 127.0.0.1 останется там.
Что выводит ваш (Run -> cmd -> route print)?
«Есть еще один момент, - подумал я, хотя не знаю, как его сложить».
127.0.0.1 - это localhost (интерфейс), это одинарное имя и считается локальным. 1.2.3.4 - это не однозначное имя.
Возможные проблемы с этим заключаются в том, что такое имя могло считаться внешним
Можете попробовать, отдельно:
Отключение (если он включен и включение, если он отключен) IPv6 на сетевом адаптере?
Помещать однозначное имя для 1.2.3.4 в файл HOSTS?
Каково соответствующее описание события, EventID и т. Д. В eventvwr.msc для отказа связи с 1.2.3.4 на 127.0.0.1:8334?
«445 - это стандартная служба Windows»
Это для SMB-direct через TCP / IP? для обмена файлами? CIFS?
Не очень надежно ... Постоянно взламывается исправлениями MS. Читать:
(«Просмотр NetBIOS по подсетям может завершиться ошибкой после обновления до Windows Server 2008») - http://blogs.technet.com/b/networking/archive/2008/07/25/netbios-browsing-across-subnets-may-fail-after-upgrading-to-windows-server-2008.aspx?wa= wsignin1.0
Затем,
"у нас возникла та же проблема, что и описанная ранее, с компьютерами Vista SP2, пытающимися достичь общего файлового ресурса Windows Server 2008 SP1 или SP2. Служба обмена файлами защищена брандмауэром Windows с повышенной безопасностью с использованием предопределенного правила для общего доступа к файлам (SMB), регулирующего безопасное соединение "