Я работаю под управлением 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] на той же машине
Файл хостов является файлом хоста Windows 2008 по умолчанию.
Цикл проверки информации, интересно. Попробовал ... не сработало. Перепроверил, чтобы убедиться, что Id все сделал правильно - у меня есть.
Мне интересно, есть ли решение с использованием 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, оба для обратной петли.
Редактировать Кажется, я нашел ответ относительно причины проблемы. Я использовал 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 (interface), это однокомпонентное имя и считается локальным. 1.2.3.4 - это не однословное имя.
Возможные проблемы с этим в том, что такое имя могло бы считаться внешним
Можете ли вы попробовать, отдельно:
Отключить (если он включен и включить, если он отключен) IPv6 на сетевом адаптере?
Поместить какое-нибудь однокомпонентное имя для 1.2.3.4 в файл HOSTS?
Что такое соответствующее описание события, EventID и т. Д. В eventvwr.msc для сбоя связи с 1.2.3.4 до 127.0.0.1:8334?
Это для 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 -посль-модернизация к окнам-сервер 2008.aspx? в = wsignin1.0
Затем,
источник