Я работаю под управлением 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].
[См. Ответ Анупамы Васант]
Похоже, мне придется пойти сложным путем и переписать код [трудно, потому что это означает иметь дело с менеджерами!]
Спасибо, что помогли мне найти / подтвердить проблему!