Windows Server 2008 - підключення до 127.0.0.1


9

У мене працює 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.

Інформація про перевірку циклу, цікаво. Спробував це ... не працював. Перекреслено, щоб перевірити, чи я зробив все правильно - я маю.

Мені цікаво, чи є рішення, використовуючи 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 - однак, файл хостів використовується лише у пошукових іменах хостів. У цьому випадку наша програма не шукатиме жодного імені хоста, оскільки 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, коли я переглядав її в Google

Це мене змусило: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba

Що підтвердило, що це зміна дизайну в WFP для Vista / 7 / Server 2008 [платформа фільтрації Windows].

[Дивіться відповідь Анупами Васант]

Схоже, мені доведеться пройти важкий шлях і переписати код [важко, бо це означає мати справу з менеджерами!]

Дякуємо, що допомогли мені знайти / підтвердити проблему!


Чи є у вашому описі 1.2.3.4 та 127.0.0.1 на одній машині? Що ви маєте для них у файлі хостів?
Геннадій Ванін Геннадій Ванін

Відповіді:


1

Не забувайте, що в Windows 2008 брандмауер увімкнено за замовчуванням. Це потенційно може блокувати будь-який та весь трафік навіть на інтерфейсі зворотного зв'язку. Крім того, якщо ви прив’язуєте до 0,0.0.0, ви приймаєте з'єднання на ВСІХ інтерфейсах. Брандмауер все одно заблокує це. Ви можете спробувати вимкнути брандмауер під час тестування ..., а потім увімкнути його. У мене не було проблем із підключенням до різних програм, розроблених на 127.0.0.1.


0

Спробуйте підключитися до 127.0.0.2 в Vista / win2k8 і вище - звучить смішно, але це працює. У минулому мали позитивні результати


-3

Я найбільш впевнений, що він пов'язаний із функцією захисту перевірки циклу, хоча я не можу детально розкрити, як він реалізований, лише як його подолати

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 -> print print)?

Є ще один момент, я думав, хоча я не знаю, як це скласти.

127.0.0.1 - localhost (інтерфейс), це однозначне ім'я та вважається локальним. 1.2.3.4 - неоднозначна назва.

Можливі проблеми з цим полягає в тому, що таке ім'я, можливо, вважалося зовнішнім


Можна спробувати окремо:

  1. Вимкнення (якщо він увімкнено та включений, якщо його вимкнено) IPv6 на мережевому адаптері?

  2. Поставити якесь одне міткове ім'я для 1.2.3.4 у файл HOSTS?


Що відповідає опису події, EventID тощо у eventvwr.msc за невдачу зв'язку від 1.2.3.4 до 127.0.0.1:8334?


"445 - це стандартна послуга Windows"

Це для SMB-прямого через 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-upgrade-to-windows-server-2008.aspx? wa = wsignin1.0

Тоді,

"У нас є та сама проблема, що описана раніше на машинах Vista SP2, які намагаються досягти спільного доступу до файлів Windows Server 2008 SP1 або SP2. Послуга обміну файлами захищена брандмауером Windows з розширеною безпекою, використовуючи заздалегідь визначене правило для спільного використання файлів (SMB), що регенерує a безпечне з'єднання "

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.