У нас есть два сайта с двумя IP-адресами, использующими только порт 80, и репозиторий SVN, использующий 443 на одном из этих IP-адресов. Когда я пытаюсь настроить SSL для одного из двух сайтов (с IP, который не используется SVN), он отказывается запускаться, потому что утверждает, что 443 уже используется, хотя он должен использовать полностью отдельный IP.
У нас есть веб-сервер с Windows Server 2003 x64, работающий под управлением IIS 6. У нас есть два домена, каждый из которых сопоставляется со своим собственным IP-адресом. Допустим, сайт A соответствует 1.1.1.1, а сайт B соответствует 2.2.2.2. SVN настроен на прослушивание 1.1.1.1:443, а сайты A и B прослушивают 1.1.1.1:80 и 2.2.2.2:80 соответственно. Это работает нормально, пока я не попытаюсь настроить сайт B для прослушивания 2.2.2.2:443, и в этом случае сайт B не запустится, как упоминалось выше. Если я остановлю SVN, то смогу запустить веб-службы (включая службу 2.2.2.2:443), но затем при повторной попытке запустить SVN выдает ту же базовую ошибку «уже используется». Но пока они оба слушают порт 443, они делают это на разных IP-адресах, что, как я думал, должно работать.
Я использовал netstatи увидите, что SVN действительно прослушивает 1.1.1.1:443, а не 0.0.0.0:443 (что, я думаю, означает, что он прослушивает все IP-адреса?). Ранее он был настроен для прослушивания «любого» IP-адреса, и я подумал, что решил бы свою проблему, установив для него прослушивание только на 1.1.1.1, но внесение этого изменения не имело никакого эффекта. Больше ничего не слушает 443. Точно так же два сайта, настроенные в IIS, настроены только на поиск своих соответствующих IP-адресов, а не «любые неназначенные», и когда я настраиваю сайт B на использование SSL на порту 443, я аналогичным образом ограничиваю его на просто IP 2.2.2.2.
Учитывая, что я могу получить либо веб-сервис или SVN работает нормально, но не одновременно, кажется довольно очевидным, что они конфликтуют друг с другом. Но разве их отдельные IP-адреса не должны разрешить этот конфликт?
Хорошо, я не хочу отвечать на свой вопрос, но, похоже, я нашел исправление, хотя сомневаюсь, что это общее решение.
Эта статья в базе знаний похоже, ссылается на мою точную проблему:
В IIS 6.0 есть два веб-сайта. Веб-сайт 1 привязан к 10.10.10.2:80 для HTTP-трафика. Веб-сайт 1 также привязан к 10.10.10.2:443 для трафика SSL. Веб-сайт 2 привязан к 10.10.10.3:80 только для HTTP-трафика.
В этом сценарии при использовании команды netstat для просмотра портов, которые прослушивает компьютер, вы можете заметить, что IIS 6.0 привязан к портам 80 и 443 на обоих IP-адресах.
Из их решения мне пришлось добавить новое значение в реестр. Итак, под ключ HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, Мне пришлось добавить значение DWORD DisableEndpointSharing, и установите его на 1. Вторая часть их решения не применима (работает httpcfg query iplisten сказал мне, что список прослушивания IP уже пуст).
После добавления указанного выше значения реестра и перезапуска IIS сайт B теперь отображается под netstat как привязанный к 2.2.2.2:443 вместо 0.0.0.0:443, и я мог без проблем запустить SVN, привязанный к 1.1.1.1:443.
Так что, по крайней мере, в этом случае, я полагаю, это была просто известная проблема с обходным путем, которая каким-то образом применима к нашей конфигурации.
предложение использовать порт 8443 для SVN, как вторичный порт ssl. Он аналогичен портам с 8080 по 80. Тогда у вас не должно возникнуть проблем с назначением порта 443 сайту.
убедитесь, что ваш маршрутизатор настроил переадресацию портов на 8443 для SVN
вы также можете использовать SVN + ssh на защищенном порту 22