Ретранслятор служебной шины Azure подключается к неизвестному IP-адресу: 40.112.124.x:9352.

Мы поставляем локальное программное обеспечение, которое предоставляется в облаке с помощью ретранслятора служебной шины Azure. Базовый код, который мы используем для предоставления, выглядит следующим образом (я удалил все, что можно было идентифицировать):

    ServiceHost sh = new ServiceHost(typeof(BasicHttpEntityService));
    BasicHttpRelayBinding basicHttpRelayBinding = new BasicHttpRelayBinding();

    Uri uriEndPointAddress = ServiceBusEnvironment.CreateServiceUri("https", "ourdomain", "test-url-appendage");
    m_shRelayServiceHost.AddServiceEndpoint(
      typeof(IMyService),
      basicHttpRelayBinding,
      uriEndPointAddress
    ).Behaviors.Add(
      new TransportClientEndpointBehavior
      {
        TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(
          "MyUser",
          "MyPassword")
      });
    sh.Open();

Это прекрасно работает для большинства наших клиентов, однако у одного из наших клиентов есть строгая политика брандмауэра.

Согласно рекомендациям SB, которые мы обнаружили, мы попросил их открыть порты 9351-9354 для нашего домена.servicebus.windows.net. Теперь мы обнаруживаем, что при входящем запросе служба подключается как к «нашему домену» (мы видим, что это удается в Wireshark, а также в журнале WCF), так и к неизвестной (нам) службе на 40.112.124.x: 9352 (последний октет меняется при каждом запросе).

Мне удалось воспроизвести проблему в моей среде разработки, запретив подключения к любому адресу 40.x.x.x на любом порту. Вот что происходит в журнале WCF:

System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions 40.112.124.25:9352

Server stack trace: 
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at Microsoft.ServiceBus.RelayedConnectionSession.ConnectAsyncResult.<GetAsyncSteps>b__4(ConnectAsyncResult thisRef, IAsyncResult r)
   at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result)

Exception rethrown at [0]: 
   at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at Microsoft.ServiceBus.RelayedConnectionSession.EndConnect(IAsyncResult result)

В это время нет исходящего DNS-запроса, поэтому нет имени хоста, которое дает какие-либо подсказки о функции этого исходящего соединения.

Из моего расследования это похоже, что это подсеть, контролируемая Microsoft, поэтому я в порядке с подключением службы ретрансляции к ней, но я хотел бы знать:

  1. Является ли это дополнительное подключение необязательным?
  2. Если нет, должны ли мы разрешить всю подсеть?
  3. Может ли этот диапазон IP-адресов измениться в будущем? Это где-то жестко запрограммировано?

person Erik    schedule 08.03.2016    source источник


Ответы (1)


В конце концов, мы запросили поддержку у Microsoft. Вкратце их ответы были такими:

  1. #P2# <блочная цитата> #P3#
  2. #P4# <блочная цитата> #P5#

Так что хорошая новость в том, что они работают над этим. Плохая новость заключается в том, что прямо сейчас нам нужно будет добавить МНОГО IP-адресов в белый список, чтобы обеспечить бесперебойную работу.

person Erik    schedule 31.03.2016