Какие бывают проблемы с работой в 1С через браузер
В таком режиме у меня уже пару лет работают несколько серверов с 1С. Иногда возникают нюансы с доступом через браузер. Например, не настроить обмен между базами, не зная их локальных путей. Бухгалтера сами его не смогут настроить. Им нужно будет передать информацию по директориям с базами. Понятное дело, что и обновить платформу они сами не смогут, так как нужно будет обновлять и публикацию баз. Когда вы сами подключены через браузер, сделать это невозможно.
Так что некоторые вещи, которые обычно бухгалтера в небольших компаниях способны сделать сами, придется делать тому, кто обслуживает этот сервер. Но бонусом идет то, что на самих пользовательских компьютерах ничего настраивать не надо. Вы просто передаете пользователю адрес в интернете и учетные данные. И он начинает работать в базе 1с. Платформу ставить не надо, как и решать вопрос с лицензиями на клиентах.
Еще один нюанс, связанный с обменом между базами. После обновления платформы на сервере, он перестает работать через браузер. Возникает ошибка доступа к COM объекту. Чтобы это исправить, надо выполнить на сервере регистрацию comcntr.dll примерно так.
regsvr32 "C:\Program Files\1cv8\8.3.18.1208\bin\comcntr.dll"
Сделать это надо в cmd с правами администратора. И повторять каждый раз при обновлении платформы, не забывая указать путь к новой версии файла.
С недавних пор я столкнулся с новой для меня ошибкой при подобной публикации баз с использованием nginx и proxy_pass. Раньше я использовал отличный от 80-го порт в apache. Но периодически стали проскакивать ссылки при работе с опубликованной базой 1с примерно такого вида — https://1c.site.ru:81/ в случае, если вы используете 81-й порт. Запросы извне по этой ссылке уходят в никуда и возникают ошибки. На стороне клиента они выглядят так:
Uncaught TypeError: Cannot read property ‘toUpperCase’ of undefined on https://……./mod_main_loader.js
Ошибка совершенно не гуглится, так что потратил много времени на ее решение. Помог режим отладки в chrome. Я просто проверил все запросы и нашел ошибочные с кривыми урлами. И так и сяк пытался их решить редиректами на веб серверах, но в итоге пришлось в apache переехать на 80-й порт и ошибка ушла.
Ну и еще одно отмечу. Иногда apache зависает или начинает сильно тупить. Обычно после долгого аптайма в несколько недель. Я подробно не разбирался в проблеме. Предпочел просто перезапускать его раз в сутки ночью. Для этого сделал обычный bat файл и настроил запуск через планировщик Windows.
@echo off sc stop "Apache2.4" timeout 90 sc start "Apache2.4"
Понятно, что это грубый костыль, но проблему решает. Ночью все равно с 1С никто не работает. Это история не про отказоустойчивость, резервирование и работу 7/24/365.
Установка сертификатов
Не имеет значение какие у вас сертификаты и где они будут расположены, но мы рекомендуем разместить все сертификаты в отдельном каталоге, например, /etc/keys/.
Proxmox nginx proxy нескольких веб серверов на одном ip
На все сертификаты и их приватные (закрытые) ключи следует установить владельца и группу root:root, а также права доступа chmod 600 для того, чтобы никто не смог похитить закрытую часть ключа.
Первоначальная инициализация nginx всегда выполняется с правами root, поэтому для сервера не будет проблемой считать конфигурационные файлы и сертификаты.
В нашем примере мы рассмотрим сертификаты srv1_example_org.crt, srv2_example_org.crt и их закрытые ключи srv1_example_org.key и srv2_example_org.key соответственно. Каждый выдан только для своего домена (srv1.example.org и srv2.example.org).
Настройка прав пользователей
Теперь необходимо установить необходимые права на ключевые папки, используемые при работе веб-доступа к базам данных «1С:Предприятие». Для каталога хранения файлов веб-сайтов, опубликованных на веб-сервере (по умолчанию C:\inetpub\wwwroot\ ) необходимо дать полные права группе «Пользователи» (Users). В принципе, этот шаг можно пропустить, но тогда для публикации или изменения публикации базы данных надо будет запускать «1С:Предприятие» от имени администратора. Для настройки безопасности данного каталога, кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Свойства» (Properties).
Далее необходимо дать полные права на каталог с установленными файлами «1С:Предприятие» (по умолчанию C:\Program Files (x86)\1cv8\ для 32-разрядного модуля расширения и C:\Program Files\1cv8\ для 64-разрядного) группе IIS_IUSRS.
Несколько IP-адресов
Чтобы использовать несколько IP-адресов, нужно добавить имя узла и соответствующий ему IP-адрес в систему определения адресов по именам (обычно DNS). После этого, для того чтобы посетить веб-узел, клиенту достаточно будет просто ввести в своем обозревателе его текстовое имя. При использовании нескольких IP-адресов для каждого IP-адреса необходима отдельная сетевая плата. На следующем рисунке показан компьютер, использующий несколько IP-адресов для размещения нескольких веб-узлов.
Примечание. Если этот способ используется для размещения нескольких узлов Интернета, потребуется также зарегистрировать текстовые имена в InterNIC.
Расширенная настройка прокси-сервера HTTP и TCP
Протокол HTTP работает поверх протокола TCP, но предоставляет дополнительную информацию о назначении сообщения. По этой причине два прокси настраиваются по-разному.
HTTP-трафик включает в себя целевой хост и порт для сообщения. Он отправляется по TCP-соединению с конечной точкой TCP, то есть между определенным хостом и портом. Как правило, HTTP-сообщение указывает на ту же конечную точку, что и TCP-соединение. Если вы изменяете конфигурацию клиента для использования прокси-сервера HTTP, соединение выполняется с другим хостом и портом, вместо указанного в URL-адресах HTTP. Это означает, что конечная точка TCP в сообщении отличается от той конечной, к которой она подключена.
Например, если HTTP-запрос отправлен на страницу http://192.0.2.1:8080/operation, запрос включает в себя «192.0.2.1:8080» в заголовке «Host» HTTP-сообщения, которое отправляется на 8080 порт на хосте 192.0.2.1.
Однако, если вы настроите HTTP-клиент на использование прокси-сервера, базовое TCP-соединение переходит к конечной точке TCP для него, в то время как сообщения все еще содержат исходную конечную точку.
Например, если вы настроите клиент на отправку своих сообщений на прокси-сервер по адресу 198281.100.1 порт 3128, а клиент отправит запрос для http://192.0.2.1:8080/operation, сообщение все еще содержит «192.0.2.1: 8080 »в заголовке« Host », а теперь также в поле« Request-Line ». Однако это сообщение теперь отправляется через TCP-соединение по адресу 198.51.100.1:3128. Таким образом, прокси-сервер HTTP может получать сообщения на одном порту (прокси-порт 8080) и может пересылать их нескольким различным службам на основе информации о получателе.
PHP
Установка PHP
Откроется страница с несколькими версиями пакета — там как мы ставим PHP как FastCGI, нам нужна версия «Non Thread Safe» (не потокобезопасная), так как она будет работать быстрее. И так, скачиваем zip-архив на сервер:
Для установка PHP на Windows достаточно просто распаковать содержимое архива в любой каталог, например, C:\Program Files\PHP:
Делаем копию файла php.ini-production и переименовываем его в php.ini:
Открываем на редактирование данный файл и правим следующее:
open_basedir = C:\inetpub\wwwroot
…
cgi.force_redirect = 0
…
short_open_tag = On
* где open_basedir — директория, в которой будут разрешены PHP-скрипты; cgi.force_redirect — указывает будет ли скрипты обрабатываться при прямом запросе или только при запросе от веб-сервера. В IIS запросы контролируются самим веб-сервером, поэтому опция может оказать обратный эффект; short_open_tag — позволяет использовать короткий вид открывающих тегов для PHP.
Проверяем, что PHP работает. Открываем командную строку Windows — переходим в каталог с установленным PHP:
cd «C:\Program Files\PHP»
Запускаем php с параметром -m:
php -m
Мы должны получить список подключенных модулей:
bcmath
calendar
Core
ctype
…
Но если мы получим ошибку, связанную с отсутствием файла VCRUNTIME140.dll:
… необходимо установить Microsoft Visual C++ Redistributable. Переходим на страницу https://www.microsoft.com/ru-RU/download/details.aspx?id=52685 и скачиваем компонент:
После загрузки, устанавливаем его на сервер, после чего, снова пробуем вывести на экран модули php:
php -m
Настройка сайта на IIS для работы с PHP
И так, веб-сервер поднят, PHP установлено, сайт работает. Настроим связку IIS + PHP. Открываем панель управления IIS — переходим к созданному сайту и кликаем по Сопоставления обработчиков:
В меню справа кликаем по Добавить сопоставление модуля:
Заполняем поля:
* где:
- Путь запроса — путь к файлам, при вызове которых действует сопоставление. В данном примере для всех файлов, заканчивающихся на php.
- Модуль — действующий модуль для обработки запроса.
- Исполняемый файл — файл, который будет выполнять обработку запроса. В данном примере мы выбрали файл из скачанного и распакованного нами архива PHP.
- Имя — произвольное имя для сопоставления.
Нажимаем OK и подтверждаем действие. Сопоставление создано.
Теперь заходим в Документ по умолчанию:
… и добавляем новый документ:
* в данном примете мы указываем, что по умолчанию сервер будет искать файл index.php, если таковой не указан явно в запросе.
Открываем в проводнике папку, в которой находятся файлы сайта (в нашем примере, C:\inetpub\wwwroot\php). Создаем файл index.php с содержимым:
<?php
phpinfo();
?>
PHP Manager в IIS
Скачиваем дополнение:
Выполняем установку на сервере, запустив загруженный файл. Открываем диспетчер управления IIS — мы должны увидеть PHP Manager:
Создание нового сайта
IIS 8 может поддерживать множество сайтов на одном сервере. В рассмотренных примерах развертывания содержимое добавлялось к сайту по умолчанию, а в этом разделе будет показано, как создать совершенно новый сайт. Разверните древовидное представление в IIS Manager, щелкните правой кнопкой мыши на узле Sites (Сайты) и в контекстном меню выберите пункт Add Web Site… (Добавить веб-сайт…). Откроется диалоговое окно Add Web Site, показанное на рисунке ниже:
Поле Site name (Имя сайта) должно содержать что-нибудь значащее. Оно используется для идентификации сайта в среде IIS Manager, но не влияет на содержимое сайта. В этом примере пул приложений был оставлен без изменений (пулы приложений рассматриваются далее). Поле Physical path (Физический путь) определяет местоположение, в котором IIS 8 будет искать содержимое для запросов на обслуживание, адресованных новому сайту. В этом примере на сервере был создан новый каталог D:\WebSites. Кнопки Connect as… (Подкл. как…) и Test Settings… (Тест настроек…) позволяют указать другие учетные данные пользователя для доступа к содержимому сайта.
![Публикация баз данных «1с:предприятия» 8.3 на веб-сервере iis в microsoft windows server 2012/2016 [rtzra's hive]](https://befam.ru/wp-content/uploads/d/8/5/d8531380463092dbfc8f863ce04388c8.png)
Раздел Bindings (Привязка) позволяет указать, как IIS 8 будет прослушивать запросы, поступающие от клиентов
IIS 8 поддерживает множество протоколов, но мы сосредоточим внимание на HTTP, поскольку он используется наиболее широко. Для этого в списке Type (Тип) выберем опцию http
Меню IP address (IP-адрес) позволяет выбрать сетевой интерфейс, который сервер будет прослушивать на предмет запросов. Для этого параметра было оставлено значение All Unassigned (Все неназначенные) — т.е. IIS будет прослушивать все интерфейсы за исключением тех, где другой сайт должен обслуживаться через этот же порт TCP. Значение Port (Порт) позволяет указать порт TCP, на котором IIS 8 будет прослушивать запросы клиентов. В общем случае каждый сайт должен обслуживаться через уникальный порт, поэтому, во избежание конфликтов с подключенным к порту 80 веб-сайтом по умолчанию, мы выбрали порт 8091.
Кроме того, отмечен флажок Start Web site immediately (Запустить веб-сайт сейчас) — т.е. сразу после щелчка на кнопке ОК сервер IIS создаст веб-сайт и начнет прослушивать запросы. Больше конфигурировать нечего, поэтому щелкните на кнопке OK, чтобы создать и запустить веб-сайт. Каждый из рассмотренных в предыдущей статье вариантов развертывания позволяет указывать сайт для развертывания — помните, что при развертывании сайты различаются по именам и используют указанные номера портов.
Локальные и глобальные IP адреса
Чтобы не запутаться в терминологии, глобальный IP адрес ещё называют «внешним», «белым» — это разные обозначения одного и того же.
Локальный IP адрес называют «внутренним», «серым», «приватным» — это всё одно и то же.
Работа домашней (локальной) сети, в которой присутствует роутер и несколько устройств, подключённых к роутеру, обычно выглядит следующим образом:
- Роутер подключается к Интернет-провайдеру. Интернет-провайдер назначает роутеру внешний IP адрес, который позволяет устанавливать соединения с глобальной сетью Интернет.
- Компьютеры по кабелю или Wi-Fi, а также мобильные телефоны через Wi-Fi подключаются к роутеру. Роутер раздаёт им локальные IP адреса.
- Если два устройства в локальной сети хотят обменяться данными, то они это делают через роутер, но сетевые пакеты не отправляются в глобальную сеть.
- Если какому-либо устройству понадобиться «выйти в Интернет», то он передаст соответствующий запрос роутеру, роутер подключится к нужному узлу в глобальной сети, роутер же получит ответ от узла в глобальной сети и передаст этот ответ устройству в локальной сети, которое сделало первоначальный запрос.
Управление настройками видимости отчетов пользователей для УТ 11.4
Возникла необходимость настроить видимость отчетов пользователям. При большом числе внешних отчетов с настройкой видимости «для всех» список отчетов сложно воспринимать. Пользователи просили убрать лишние не нужные им отчеты. Они могут настроить сами, но, конечно, ленятся — в итоге это ложится на плечи программиста 1С.
Обработка позволяет скрыть неиспользуемые отчеты из списка отчетов по разделам, доступным пользователю. Также данные настройки можно скопировать другим пользователям из списка. Может быть полезна программистам 1С, администраторам БД.
Делалась для себя, может, кому-то пригодится.
1 стартмани
Как настроить прием подключений через порт 8080?
Итак, заголовок «Host» был добавлен в HTTP/1.1. Соединения HTTP/1.0 не включает его в себя. По этой причине такие соединения, которые не проходят через прокси, не включают в себя хост и порт для сообщения. Однако информация по HTTP/1.0, отправленная через прокси-сервер, по-прежнему содержит целевой хост и порт в «строке запроса». Поэтому отсутствие заголовка «Host» не вызывает проблемы для прокси.
Чтобы включить прокси-сервер TCP, вы должны изменить конфигурацию клиента с конечной точки TCP в реальном времени на заменяемую конечную точку. В отличие от HTTP, этот протокол не обеспечивает встроенную возможность использования прокси. То есть, если вы подключаетесь к прокси-серверу через TCP, для передачи информации конечному адресату не предусмотрен какой-либо механизм.
ServerBindings — привязка сайтов в IIS
На одном веб сервере IIS можно запустить множество сайтов. Однако, чтобы IIS мог корректно распределять HTTP запросы, каждый сайт должен идентифицироваться уникальным значением. Для веб-сайта IIS оно формируется из трех атрибутов, комбинация которых для каждого сайта должна быть уникальной. Это:
- номер TCP порта
- IP адрес
- имя узла (host header)
Информация о запущенных сайтах хранится в атрибуте ServerBindings метабазы IIS в формате IP:Port:Hostname. Поэтому, что запустить несколько сайтов на одном порту и IP адресе, нужно использовать уникальный Host header. Что это такое? Host header – это часть HTTP запроса к серверу, который отправляет клиент, указывая к какому конкретно сайту он хочет обратиться. Соответственно, данный host header должен быть указан на стороне веб сервера, а в DNS содержаться корректная запись, по которой можно определить соответствие между именем хоста и IP адресом веб-сервера.
Например, наш тестовый веб сайт IIS уже на 80 порту. Нам нужно добавить второй сайт на этом же порту.
В консоли управления IIS создадим второй сайт (Add Website). С именем TestSite , файлы которого будут храниться в каталоге c:inetpubTestSite (имя хоста пока не указываем).
После того, как вы нажмете “OK”, появится предупреждение, в котором говорится, что вы не можете использовать привязку *:80 для двух сайтов, т.е. одновременно может работать только один из них.
Согласимся с этим предупреждением. Итак, у нас появился второй сайт, также привязанный к 80 порту, но запустить его без остановки первого сайта нельзя.
Размещаем на IIS Express
Создаем сайт для сервиса
Добавим шаблон сайта по контекстному меню от решения:
Выбрать пустой веб-сайт ASP.NET.Расположение указать в файловой системе. Папку расположения указать отдельную в решении (т.е. указать новую папку внутри папки решения, папка будет создана автоматически).
Получится примерно вот так:
Далее назначим сайт запускаемым проектом.
Выбрать Решение/Проекты. Наш сервис.
В результате у нас появилась папка Bin.
Если сейчас нажать на сайте Ctrl+F5 (Запуск без отладки), то получим следующую страницу:
Когда сайт работает у вас в трее будет значок IIS Express.
Когда новый сайт создается в VS IIS Express автоматически назначает ему порт.
Обычно IIS Express запускается из VS когда нужно отладить сайт. Если нужно IIS Express запустить во вне VS, то можно использовать следующую командную строку:
"C:\Program Files\IIS Express\iisexpress" /path:c:\myapp\ /port: /clr:v4.0
В моем случае:
"C:\Program Files (x86)\IIS Express\IISExpress.exe" /path:D:\WCFClubProject\HelloService\HostWebSite /port:17587 /clr:v4.0
Что такое порты в Windows
Давайте я попробую по простому объяснить, что такое порт. Представим себе большой микрорайон с большим количеством многоэтажных домов, в каждом из них есть квартиры с жильцами, общим количеством 65 536, каждая квартира имеет свой уникальный, порядковый номер. Теперь представим, что вам необходимо попасть к другу Васе, который живет в 1443 квартире, вы что делаете идете в нужный дом с таким номером квартиры, далее вам нужно заскочить к Марине, которая живет в 80 квартире, а теперь представьте, что вместо вас это ваш компьютер и вместо ваших друзей, это порты. Каждый такой порт уникален и отвечает за ответ пользователю по определенной службе, например,
- 80 — это http служба, которая отвечает вам при запрашивании страниц сайта
- 1433 — это порт службы SQL
- 443 — https зашифрованный вариант http, с использованием SSL сертификатов.
Из выше описанного, порты бывают двух типов:
- Жестко забронированные под определенные службы. Это порты которые используются исключительно определенными программами. Диапазон таких портов от 0-1024, но есть и выше, тот же 1433 у SQL или 55777 Vipnet.
- Динамические, используемые для повседневных вещей пользователя. Это диапазон после 1024, и используют их, например, в таком контексте: скачиваете файл, ваш компьютер использует один порт, смотрите online фильм, ваш компьютер использует второй порт и так далее. Как только передача данных заканчивается, порт освобождается.
Порты еще очень часто ассоциируют с сокетами, о которых я уже рассказывал, советую посмотреть.
Настройка нескольких сайтов в IIS на разных IP адресах
Теперь попробуем запустить на веб сервере IIS два сайта на разных IP адресах. В первую очередь нужно добавить на Windows Server отдельный VLAN интерфейс или просто назначить на сетевое подключение дополнительный IP адрес (алиас).
В этом примере у сервера основной IP адрес 192.168.13.100, и я добавлю на этот же сетевой адаптер дополнительный IP алиас 192.168.13.101:
Get-NetIPAddress | ft IPAddress, InterfaceAlias, SkipAsSourceNew-NetIPAddress –IPAddress 192.168.13.101 –PrefixLength 24 –InterfaceAlias “Ethernet” –SkipAsSource $True
Теперь на DNS сервере нужно создать A запись для нового сайта (сразу создадим PTR запись в обратной зоне):
Add-DnsServerResourceRecordA -Name NewSite3 -IPv4Address 192.168.13.101 -ZoneName test.com -TimeToLive 01:00:00 –CreatePtr
Осталось открыть настройки Site Binding и привязать сайт к новому IP адресу.
Немного не то.
Есть 2 сервера, не важно виртуальные или физические. Допустим 192.168.1.1 (vm1) и 192.168.1.2 (vm2)
Внешний ip. На каждой машине свой апач/iis/что-то ещё, но сайты разные.
То что вы написали там 1 сервер и разные сайты. А мне надо, чтобы были разные сайты и разные серверы, обслуживающие их.
Только через установку прокси на хост машине, теоретически возможно сделать через iptables но сложность настройки + вероятно бОльшие (чем просто nginx) потребляемые ресурсы.
А iptables не выручит? Я это представляю так. Пользователь набирает example1.com при получение такого запроса iptables на шлюзе перенаправляет запрос на 192.168.1.1 (vm1), если же example2.com, то отправляет запрос на 192.168.1.2 (vm2).
Я не знаю есть ли модуль для iptables который умеет парсить http. Есть вроде по регулярным выражениям, но опять же в случае с https тут Вы пролетаете.
Не вариант. Нужно, чтобы на одной из виртуалок была windows server 2008.
Посмотрите nginx. На виртуалках может быть что угодно.
Тогда, вестимо, прокси.
А апач хорошо справится с этой задачей?
смотря какие нагрузки. У меня на работе apache работает как прокси — не жалуемся. До этого стоял lighttpd — были проблемы с большими файлами на проксируемых хостах — он их сначала кэшировал у себя полностью в оперативке, а потом отдавал клиенту. Ну, то есть, представляешь как файл размером 500 мб забивает оперативку. А, и да, все модули типа cache и mem_cache естественно были отключены
Апач слишком прожорлив, nginx же изначально создавался как фронтенд-прокси.
DNS развести религия не позволяет? На худой конец на хостовой машине к примеру 1.1.1.1 в хостс пропиши 1.1.1.7 site.com 1.1.1.9 pron.com
Были ж люди как люди, и вдруг все стали удоры. (с)
Из локалки покатит, а как если из интернета попадать?
Ровно так же. Ваще, чтоб из инета нормально попадать нужно на хосте поднимать полноценный DNS, в нём уже прописать хоть 2, хоть 100500 виртуалок, разницы нет, впрочем и хостс тоже сойдёт чтоб не замарачиваться.
Источник
Аннотация
Предположим, вы хотите настроить общую конфигурацию для двух серверов IIS. В этом примере они именуются сервером A и сервером B. У вас будет два разных веб-сайта: Site1 и Site2. Оба этих веб-сайта будут использовать собственные выделенные IP-адреса, как показано ниже:
Сервер A —> Site1 —> 10.10.10.1Сервер A —> Site2 —> 10.10.10.2
Сервер Б —> Site1 —> 10.10.10.3Сервер Б —> Site2 —> 10.10.10.4
Теперь вы настроите сервер A B& для общей конфигурации, но при этом возникает уникальная ситуация, когда дело касается привязок веб-сайта. Конфигурация привязок веб-сайта обычно выглядит так, как показано ниже вapplicationHost.config файле:
Как видите, нет ничего, что идентифицирует веб-сервер по его имени (например, сервер A). Поэтому при привязке Site1 к версии 10.10.10.1 на сервере A эти параметры также реплицируются для сервера B. Но сетевая карта сервера B не распознает IP-адрес 10.10.10.1. На самом деле необходимо привязать 10.10.10.3 к Site1 через порт 443 и 80 для сервера B.
Чтобы устранить эту ситуацию, необходимо вручную добавить дополнительные привязки для каждого веб-сайта. Например, необходимо добавить дополнительные привязки для IP-адреса 10.10.10.3 и порта 443 на сервере A, хотя сервер A не понимает 10.10.10.3. Это нормально, так как службы IIS на сервере A игнорируют этот IP-адрес при запуске, так как не могут его найти. Для добавления этой привязки можно appcmd.exe следующую команду:
Примечание.
Пользовательский интерфейс диспетчера IIS не позволит сделать это для https; Необходимо использовать appcmd.exe.
После добавления этой привязки с appcmd.exe новая конфигурация в файлеapplicationHost.configбудет выглядеть следующим образом:
Помните, что фактический сертификат для этого сайта еще не назначен. Вы только что добавили привязки IP-адресов для порта 443. Теперь можно назначить существующий сертификат с помощью пользовательского интерфейса диспетчера IIS. Дополнительные сведения о том, как это сделать, см. в разделе «Настройка SSL в IIS 7».
После назначения сертификата записи будут настроены в http.sys и вы сможете просматривать их с помощью следующей команды NETSH из командной строки:
Аналогичным образом выполните описанные выше действия и логику, чтобы добавить остальные сайты и сертификаты на остальные серверы. Сведения о SSL-сертификате никогда не сохраняются вapplicationHost.config файле. Он является локальным для компьютера, и администратор сервера A должен экспортировать и импортировать правильные сертификаты на всех серверах фермы, использующих общую конфигурацию.
Создаём ссылки с нескольких DNS адресов на один сайт
Это можно осуществить двумя способами: созданием синонимов, или перенаправлением всех обращений с другого сайта.
1) Синонимы задаются директивой ServerAlias, могут содержать маску, и разделяются пробелом. Вот несколько примеров создания синонимов:
ServerAlias www.teo.mynetwork.ru ServerAlias *.teo.mynetwork.ru ServerAlias www.teo.mynetwork.ru god.mynetwork.ru pantheon.ru
Синоним — это DNS-имя. Имена могут быть абсолютно любыми, в том числе и из разных доменов, но все они должны разрешаться в IP-адреса, то есть их предварительно нужно зарегистрировать в DNS.
2) Перенаправление задаётся директивой Redirect. Создаём новый пустой сайт pantheon.ru. Как и для предыдущих сайтов, это делается в три шага: создание каталога для документов, для журналов и добавление конфигурации в httpd.conf:
<VirtualHost pantheon.ru>
DocumentRoot /var/www/html/pantheon
ServerName pantheon.ru
ErrorLog /var/log/httpd/pantheon/error_log
CustomLog /var/log/httpd/pantheon/access_log combined
Redirect / http://teo.mynetwork.ru
</VirtualHost>
Можно перенаправлять не со всего сайта, а только с определённого каталога или даже документа:
Redirect /samag http://samag.ru Redirect /ftp/ ftp://citkit.ru/pub/ Redirect /find/ya.htm http://yandex.ru
При этом Apache воспринимает первый параметр директивы Redirect не как URL, а как набор символов, при совпадении с которым происходит перенаправление. Отсюда следует, что он НЕ проверяет наличие указанных каталогов и файлов, а ссылки /samag и /samag/ НЕ считает одинаковыми.
Перенаправление с помощью файла .htaccess выглядит так:
RewriteEngine On RewriteRule ^wiki/(.*)$ http://new.site.ru/wiki/$1 RewriteRule ^(.*)$ http://new.site.ru/
- 1-я строка: включаем возможность менять URL
- 2-я строка: перенаправляем запрос к странице http://old.site.ru/wiki/Что-то на другой сайт, передавая параметры ($1)
- 3-я строка: любые другие запросы к старому сайту перенаправляем на новый.
Полезная ссылка:
http://www.portlet.ru/articles/webtips/redirect.html
Настройка редиректа с HTTP на HTTPS
Чтобы сделать редирект (перенаправление) HTTP на HTTPS нужно установить модуль Microsoft URL Rewrite Module:
-
Качаем последний релиз со страницы проекта https://www.iis.net/downloads/microsoft/url-rewrite
- Убедиться, что в настройках сайте не включена опция обязательного использования SSL (Require SSL)
-
Визуальная настройка делается через оснастку IIS, в свойствах сервера (или сайта, смотря куда требуется подключить) открываем «URL Rewrite», добавляем правило (Add Rule(s) и заполняем поля:
- Выбираем Inbound Rules / Blank Rule
- Name: HTTP to HTTPS Redirect
- Pattern: (.*)
-
Разворачиваем Conditions, добавляем (Add):
- Condition Input: {HTTPS}
- Pattern: ^OFF$
- Ignore Case: включено
-
Action Properties:
https://{HTTP_HOST}/{R:1} - Append query string: включено
- Применяем (Apply) и пробуем
-
Второй вариант: отредактировать файл web.config, в раздел <system.webServer> добавить правило:
<rewrite> <rules> <rule name="HTTP to HTTPS Redirect" enabled="true" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" /> </rule> </rules> </rewrite>
Зачем нужен обратный прокси
Обратный прокси выполняет одну из важнейших функций — применяет ко всем внешним подключениям определенные политики. Это может быть распределение, в зависимости от запрашиваемого имени, балансировка нагрузки, отдача статического содержимого из определенных каталогов, а также точка терминирования SSL соединений. На обратном прокси может располагаться wildcart сертификат, несколько простых сертификатов или сертификат на несколько имен. Все соединения между прокси и клиентами будут зашифрованы этим сертификатом, а на бекэнд серверах со службами можно будет не беспокоиться о настройке SSL и сроках действия сертификатов. Таким образом, с определенного момента, наличие обратного прокси снижает стоимость и увеличивает эффективность поддержки SSL на веб-серверах.
Назначение обратного прокси — терминирование SSL (HTTPS) и распределение HTTP запросов по серверам
Опубликованные базы 1С, также, как и другие веб приложения, могут работать через обратный прокси. В этом случае веб-сервер IIS или apache, с помощью которого публикуется база, может работать без настройки SSL в качестве бекэнд сервера, а обратный прокси, в роли которого применен nginx, терминирует ssl соединения к внешнему адресу из интернета и передает запрос на этот бекэнд. Бекэнд обрабатывает запрос и возвращает его обратно, через прокси сервер. Отдаваемый ответ оборачивается в SSL и возвращается клиенту. Так работает схема в общих чертах.
Если в сети имеется еще один веб-сервер, на котором находятся еще опубликованные базы 1С или любое другое веб-приложение и его необходимо опубликовать в интернет, можно добавить дополнительное доменное имя, сертификат для него и дополнить настройку nginx. Таким образом на одном внешнем IP адресе, на одном стандартном порту, могут начать работать два и более сайта с разными доменными именами.
Также путем редактирования локаций можно распределять запросы к одному доменному имени по разным серверам на основании запрашиваемых данных. Преимущество в том, что эта настройка всегда будет находиться в одном месте, рядом с сертификатами и может, как любой текстовый файл, храниться в системе управления версиями.