Почему моя целевая машина .NET Remoting активно отклоняет соединение? - PullRequest
5 голосов
/ 12 ноября 2008

Я пытаюсь установить базовую связь .NET Remoting между 2x 64-битными машинами Windows. Если Machine1 действует как клиент, а Machine2 как сервер, то все работает нормально. В противном случае возникает следующее исключение:

System.Net.Sockets.SocketException: не может быть установлено соединение, потому что целевая машина активно отказала ему

Код сервера:

TcpChannel channel = new TcpChannel(6666);
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownServiceType(
  typeof(MyRemotableObject),"HelloWorld",WellKnownObjectMode.Singleton);

Код клиента:

TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);
// Create an instance of the remote object
remoteObject = (MyRemotableObject)Activator.GetObject(
  typeof(MyRemotableObject), "tcp://172.16.7.44:6666/HelloWorld");

Есть идеи, что случилось с моим кодом?

Ответы [ 2 ]

11 голосов
/ 12 ноября 2008

Брандмауэр Windows? (Автор вопроса говорит, что это не так.)

Для отслеживания проблем с подключением применяется стандартный подход (применяется в любом порядке):

  • пинг машины
  • дважды проверьте, действительно ли какой-то процесс прослушивает порт 6666 (netstat -an)
  • Телнет машины по порту 6666
  • попробуйте использовать другой сервис на машине.
  • проверьте, не нарушает ли какая-либо конфигурация процесс сервера, прослушивающий 6666, и заставляет его отказать вам. (не знаю, возможно ли это с удаленным взаимодействием .NET)
  • наблюдать за связью с машиной, используя анализатор пакетов (например, Packetyzer), чтобы выяснить, что происходит на уровне TCP / IP.
  • возможно, активные компоненты сетевой инфраструктуры между сервером и клиентом (коммутаторы уровня 3, межсетевые экраны, NAT-маршрутизаторы и т. Д.) Мешают
5 голосов
/ 12 ноября 2008

Если предположить, что одни и те же двоичные файлы / конфиги работают в одном направлении, но не в другом, это скажет мне что-то не так в сетевой части дома для начала.

  • Вы используете IP-адреса - дважды проверьте привязанные адреса на целевом компьютере по сравнению с config / code с помощью IPCONFIG / ALL.
  • Есть ли на "серверном" компьютере несколько сетевых карт? Служба связана, например, с одной сетевой платой, а не с обеими?
  • ping на сервере скажет вам, что ICMP маршрутизируется между компьютерами - можете ли вы создать сеансовые ориентированные запросы, например, открытие UNC-путей на сервере от клиента.

Помимо межсетевого экрана, единственное другое соединение, от которого я отказался, было:

  • Разрешение имени - существующая запись хоста была неправильной. Здесь не должно быть проблем.
  • Ориентированный на IPSEC - различные политики между компьютерами не позволяли одной из них принимать входящие соединения от другой. Возможно, если вы работаете в защищенной корпоративной среде. Если вы работаете в среде IPSec, проверьте такие простые вещи, как часы, действительные сертификаты компьютера. Все это может помешать установлению сеансов IPSec.
  • стрессовая проблема - стек IP исчерпал свободные блоки управления TCP из-за неправильной конфигурации сервера. Точно так же звучит, как будто вы не можете установить соединение - возможно, это не проблема.

Я бы начал с брандмауэра 1-го - либо установив политику для исключения входящих запросов на этот сокет, доверяя всем сокетам с исходного IP-адреса, либо отключив его все вместе. (лично последний является быстрым и грязным в качестве теста, но я бы сделал первое в производственной среде)

Помимо журналов событий, журнал аудита, если у вас включен брандмауэр, но он пробит. Netmon и т. Д. Все становятся вашими друзьями.

...