Использовать тот же порт для двух разных приложений

[shadow7256]

Уважаемые.

Есть два приложения на одной машине - Web application (ASP.NET MVC) и Windows service. Внутри виндового сервиса есть self hosted WEB API, оно слушает порт 9700. На него клиенты шлют всякие HTTP запросы.

Клиент поставил условие - для всех входящих запросов из вне нужно пользовать только один порт - 443. То есть и Web application и WEB API должны слушать только порт 443.

Когда я это дело настроил то WEB API слушает порт 443 без проблем, а вот Web application перестало работать. На все запросы приходит ответ - Нет такого ресурса по адресу https://blabla.com/index.html

Насколько я нарыл информацию, то HTTP не позволяет делать port sharing если имя хоста одно и тоже.

Что можно придумать?

я спрошу у клиента есть ли у них какие то ограничения на использгование портов на одной машине. Если нет, то буду все запросы слать на Web application на порт 443, ну а та уже будет, если надо, переправлять на Windows service на другой порт. Но вдруг если ограничение тоже есть? Что тогда делать?

[veey+]

> Насколько я нарыл информацию, то HTTP не позволяет делать port sharing если имя хоста одно и тоже.
port sharing возможен. Например, WinRM also includes helper code that lets the WinRM listener to share port 80 with IIS or any other application that may need to use that port.
http://linux.last-bastion.net/infocentr ... leshooting
Но это зависит от конкретных приложений.
Еще в голову приходит сменить имя хоста. Т.е. создать алиас (cname). Вероятно, также нужно будет создать SPN.

[shadow7256]

Еще в голову приходит сменить имя хоста. Т.е. создать алиас (cname). Вероятно, также нужно будет создать SPN.

Сменить имя хоста где? в Web API или в Web application? что такое SPN?

[shadow7256]

WinRM also includes helper code that lets the WinRM listener to share port 80 with IIS or any other application that may need to use that port.[/i]

это точно не пойдет. Никакие WinRM клиент ставить не будет. У них вообще все очень и очень строго с этим делом

[veey+]

WinRM also includes helper code that lets the WinRM listener to share port 80 with IIS or any other application that may need to use that port.[/i]

это точно не пойдет. Никакие WinRM клиент ставить не будет. У них вообще все очень и очень строго с этим делом

я имел в виду, что winRM - это пример того, что шарить HTTP/HTTPS порты между несколькими приложениями возможно.

[veey+]

Еще в голову приходит сменить имя хоста. Т.е. создать алиас (cname). Вероятно, также нужно будет создать SPN.

Сменить имя хоста где? в Web API или в Web application? что такое SPN?

Сменить имя хоста, по которому обращаетесь к серверу.

Я так понимаю, речь идет о Windows.
Например, есть server.domain.local. В DNS создаем cname record "alias.domain.local" -> "server.domain.local".
Соответственно к одному приложению обращаетесь через server.domain.local:443, а к другому - alias.domain.local:443.
Чтобы это работало (если оно вообще должно работать), наверняка потребуется добавить соответствующий SPN (Service Principal Name). Для этого выясняете, под чем бежит ваш процесс (System или сервис аккаунт). Смотрите, какие там есть SPN и добавляете новый, только уже с alias.domain.local в качестве имени хоста.

[helg]

На серверных операционках вопрос решается установкой "reverse http(s) proxy" на порт 443, который в зависимости от параметров запроса проксируем либо на апликацию Web API, которая слушает localhost:9700, либо на service, который надо подвинуть с 443 куда на localhost:ANOTHER_PORT. Стандартная программа reverse http proxy это программа NGINX.

Но перед тем как чего-то ставить/двигать, хорошо бы глянуть: что это там за service, который сейчас на 443 висит. Может он сам уже умеет исполнять reverse http proxy - и достаточно ему просто сказать, чтобы какие-то URL-шаблоны он не сам обрабатывал, а проксировал на существующий localhost:9700/WebAPI.

[shadow7256]

На серверных операционках вопрос решается установкой "reverse http(s) proxy" на порт 443, который в зависимости от параметров запроса проксируем либо на апликацию Web API, которая слушает localhost:9700, либо на service, который надо подвинуть с 443 куда на localhost:ANOTHER_PORT. Стандартная программа reverse http proxy это программа NGINX.

Но перед тем как чего-то ставить/двигать, хорошо бы глянуть: что это там за service, который сейчас на 443 висит. Может он сам уже умеет исполнять reverse http proxy - и достаточно ему просто сказать, чтобы какие-то URL-шаблоны он не сам обрабатывал, а проксировал на существующий localhost:9700/WebAPI.

Сейчас никаких сервисов на 443 не висит. Объясню по другому, возможно я неправильно объясняю.

Есть Web приложение, которое вертится на IIS на порту 80 (HTTP). Ясен пень, что мы его сконфигурим на порт 443 (на HTTPS). Это все без проблем.

Также есть windows service, внутри которого хостится Web API (self hosted API). Web API конфигурится сейчас так, что слушает порт 9700 на входящие запросы. Эти запросы не имеют никакого отношения к web запросам на веб приложение. У Web API свои задачи , у Web приложения свои.

Клиент сказал, что пока он тестирует, то использовать разные порты допустимо. Но в продакшене потом будет открыт только порт 443. И все

Следовательно как то надо сделать так, чтобы и веб приложение и Web API работали на одном порту - 443.

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

https://server.com:443/index.html

Если ему надо обратится к Web API то он обращается на:

GET https://server.com:443/api/Transactions

Но такой трюк просто так не пройдет. Нельзя по умолчанию шарить один и тот же порт для разных приложений, которые используют HTTP(s) протокол и имеют один и тот же domain name. Пусть даже полный URL выглядят по другому.

[shadow7256]

Я так понимаю, речь идет о Windows.
Например, есть server.domain.local. В DNS создаем cname record "alias.domain.local" -> "server.domain.local".
Соответственно к одному приложению обращаетесь через server.domain.local:443, а к другому - alias.domain.local:443.
Чтобы это работало (если оно вообще должно работать), наверняка потребуется добавить соответствующий SPN (Service Principal Name). Для этого выясняете, под чем бежит ваш процесс (System или сервис аккаунт). Смотрите, какие там есть SPN и добавляете новый, только уже с alias.domain.local в качестве имени хоста.

да Windows. Я все это запишу и передам их админам. Я так понимаю, это скорее работа сис админов нежели девелоперов

[veey+]

Я так понимаю, речь идет о Windows.
Например, есть server.domain.local. В DNS создаем cname record "alias.domain.local" -> "server.domain.local".
Соответственно к одному приложению обращаетесь через server.domain.local:443, а к другому - alias.domain.local:443.
Чтобы это работало (если оно вообще должно работать), наверняка потребуется добавить соответствующий SPN (Service Principal Name). Для этого выясняете, под чем бежит ваш процесс (System или сервис аккаунт). Смотрите, какие там есть SPN и добавляете новый, только уже с alias.domain.local в качестве имени хоста.

да Windows. Я все это запишу и передам их админам. Я так понимаю, это скорее работа сис админов нежели девелоперов

да.
Если дело только в имени хоста, то это может сработать.

[veey+]

> Когда я это дело настроил то WEB API слушает порт 443 без проблем, а вот Web application перестало работать. На все запросы приходит ответ - Нет такого ресурса по адресу https://blabla.com/index.html

хотя, чет меня терзают смутные сомнения. Это Web application вообще запускается? видно ли его в netstat -abn ?

[helg]

1. Есть Web приложение, которое вертится на IIS на порту 80 (HTTP). Ясен пень, что мы его сконфигурим на порт 443 (на HTTPS). Это все без проблем. https://server.com:443/index.html

2. Также есть windows service, внутри которого хостится Web API (self hosted API). Web API конфигурится сейчас так, что слушает порт 9700 на входящие запросы. Эти запросы не имеют никакого отношения к web запросам на веб приложение. У Web API свои задачи , у Web приложения свои. https://server.com:443/api/Transactions

Ага, то есть WebApp - это IIS. Смотрим: можно ли сконфигурировать "IIS reverse proxy". Гугл говорит,что можно, и даже объясняет как. По этим инструкциям и конфигурируем этот reverse proxy в IIS, чтобы все запросы, приходящие у нему на URI "/api/Transactions/СУФФИКС" проксировались на "http://localhost:9700/api/Transactions/СУФФИКС", где их обслуживает написанный Вами сервис. В результате запросы к Web приложению IIS обслуживает из собственных ресурсов, а запросы к сервисам - проксирует на 9700.

Всё заработает и не будет CORS.

[shadow7256]

1. Есть Web приложение, которое вертится на IIS на порту 80 (HTTP). Ясен пень, что мы его сконфигурим на порт 443 (на HTTPS). Это все без проблем. https://server.com:443/index.html

2. Также есть windows service, внутри которого хостится Web API (self hosted API). Web API конфигурится сейчас так, что слушает порт 9700 на входящие запросы. Эти запросы не имеют никакого отношения к web запросам на веб приложение. У Web API свои задачи , у Web приложения свои. https://server.com:443/api/Transactions

Ага, то есть WebApp - это IIS. Смотрим: можно ли сконфигурировать "IIS reverse proxy". Гугл говорит,что можно, и даже объясняет как. По этим инструкциям и конфигурируем этот reverse proxy в IIS, чтобы все запросы, приходящие у нему на URI "/api/Transactions/СУФФИКС" проксировались на "http://localhost:9700/api/Transactions/СУФФИКС", где их обслуживает написанный Вами сервис. В результате запросы к Web приложению IIS обслуживает из собственных ресурсов, а запросы к сервисам - проксирует на 9700.

Всё заработает и не будет CORS.

Скажите если я прав:

1. Web API так и остается висеть внутри виндового сервиса на порту 9700. Но напрямую эта Web api извне уже будет недоступна.
2. Web app конфигурится на порт 443.
3. Клиент все запросы к Web API теперь шлет на IIS на порт 443.
4. IIS reverse proxy эти запросы перехватывает и отсылает запрос на виндовый сервис (уже внутри серверной машины).
5. API возвращает результат и IIS вернет его клиенту

[helg]

Скажите если я прав:

1. Web API так и остается висеть внутри виндового сервиса на порту 9700. Но напрямую эта Web api извне уже будет недоступна.
2. Web app конфигурится на порт 443.
3. Клиент все запросы к Web API теперь шлет на IIS на порт 443.
4. IIS reverse proxy эти запросы перехватывает и отсылает запрос на виндовый сервис (уже внутри серверной машины).
5. API возвращает результат и IIS вернет его клиенту

Да, именно так.

[veey+]

> 2. Web app конфигурится на порт 443.
Непонятно, что такое Web app.

[shadow7256]

> 2. Web app конфигурится на порт 443.
Непонятно, что такое Web app.

Это Web приложение (ASP.NET MVC) которое крутится на IIS. Добавляется SSL certificate, добавляется HTTPS binding и все.

[shadow7256]

1. Есть Web приложение, которое вертится на IIS на порту 80 (HTTP). Ясен пень, что мы его сконфигурим на порт 443 (на HTTPS). Это все без проблем. https://server.com:443/index.html

2. Также есть windows service, внутри которого хостится Web API (self hosted API). Web API конфигурится сейчас так, что слушает порт 9700 на входящие запросы. Эти запросы не имеют никакого отношения к web запросам на веб приложение. У Web API свои задачи , у Web приложения свои. https://server.com:443/api/Transactions

Ага, то есть WebApp - это IIS. Смотрим: можно ли сконфигурировать "IIS reverse proxy". Гугл говорит,что можно, и даже объясняет как. По этим инструкциям и конфигурируем этот reverse proxy в IIS, чтобы все запросы, приходящие у нему на URI "/api/Transactions/СУФФИКС" проксировались на "http://localhost:9700/api/Transactions/СУФФИКС", где их обслуживает написанный Вами сервис. В результате запросы к Web приложению IIS обслуживает из собственных ресурсов, а запросы к сервисам - проксирует на 9700.

Всё заработает и не будет CORS.

Вы про это?*

https://blogs.msdn.microsoft.com/friis/ ... orld-apps/

[helg]

Вы про это?*
https://blogs.msdn.microsoft.com/friis/ ... orld-apps/

Полагаю, что это таки оно. Вам нужен только reverse proxy. URL rewrite, полагаю, в вашем случае не нужен: IISу не требуется менять URL от клиента при передаче его вашему сервису, да и в теле ответе сервиса, полагаю, не надо менять URLы при отдаче их клиенту - обычно ихтамнет. Но если в IIS они оба ставятся только вместе, одним компонентом, что же, значит именно этот компонент и надо ставить и конфигурить.

[idle0]

Можно иметь два IP на одном сервере, на одном на порту 443 будет жить IIS, а на другом ваш Web App - и тоже на порту 443