мы создали один производительный сервер и тестовую среду, которые представляют собой две виртуальные машины с разными внутренними IP-адресами. Наш общедоступный DNS-сервер указывает software.example.com на наш общедоступный IP-адрес. Если вы хотите использовать производительный сервер, введите https://software.example.com и если вы хотите получить доступ к серверу для тестирования, вы должны использовать https://software.example.com:10443. Затем наш брандмауэр перенаправит запрос на правильный внутренний IP-адрес.
Этого достаточно для внешнего использования, так как мы можем использовать один и тот же сертификат SSL для двух серверов (поскольку они используют одно и то же полное доменное имя). Но нам нужно использовать внутренний IP-адрес для производительного сервера, потому что он должен быть доступен даже при отключении интернет-соединения. Итак, я использовал запись A для внутреннего IP-адреса производительного сервера.
Теперь мы не можем открыть тестовый веб-сайт, используя DNS-имя, поскольку software.example.com указывает на производительный сервер внутри, мы просто можем использовать внутренний IP-адрес, например 192.168.1.10:10443, что приводит к ошибке сертификата SSL.
Вы знаете способ обойти это? Я хотел бы найти способ заставить адрес software.example.com работать внутри обоих серверов. Я бы не хотел, чтобы сайт был доступен только через интернет.
Я мог бы использовать другой сертификат для тестовой среды, но мне нужно было бы пойти с Let's encrypt, способ использования нашего платного сертификата от нашего провайдера был бы лучше.
Спасибо за ваши предложения.
Чтобы напрямую ответить на вопрос в заголовке, вы должны использовать SAN Поле (Subject Alternate Name) при создании CSR или заказе сертификата. SAN позволяет одному сертификату быть действительным для двух (или более) имен хостов.
Однако, глядя на текст вопроса, вам кажется, что вам больше интересно иметь одно имя, которое всегда будет достигать вашего внутреннего сервера, даже когда внешняя сеть недоступна, а не один сертификат, действительный для нескольких имен. Это можно сделать несколькими способами. Вот несколько первых, которые приходят на ум:
Настройте внутренний DNS-сервер, который является частным для вашей сети и возвращает внутренний IP-адрес для внутренних компьютеров (например, 192.168.1.10 для software.example.com) и пересылает запрос на внешний DNS-сервер (например, ваш Интернет-провайдер или 8.8 .8.8) для не внутренних имен. Это «наиболее правильное» решение и простейшее, если у вас уже есть внутренний DNS-сервер, но, если у вас его еще нет, вам придется настроить его и перенастроить все ваши внутренние машины для его использования.
Настроить "файл хостов" (/etc/hosts в Linux проверьте Google на наличие местоположений в Windows, OS X или других операционных системах) на всех своих внутренних машинах, чтобы сообщить им, что software.example.com находится на 192.168.1.10 без прохождения через DNS. Это имеет тот же общий эффект, что и №1, но требует гораздо больше работы по настройке и поддержке. Его единственным преимуществом является отсутствие необходимости настраивать внутренний DNS-сервер.
Сообщите своим внутренним пользователям, чтобы они всегда использовали IP-адрес или альтернативное имя для внутреннего доступа, независимо от того, работает ваш Интернет или нет. Если у вас нет соответствующего SAN в вашем сертификате, они могут «принять риск и продолжить», когда их браузер жалуется на недействительность сертификата. Если у вас нет SAN, это очень «неправильное» решение (поскольку оно включает игнорирование предупреждений безопасности браузера), но его проще всего реализовать, если у вас еще нет сетевой инфраструктуры для любого из другие решения.
Если у вас есть настраиваемый маршрутизатор, обрабатывающий трафик вашей внутренней сети, вы можете настроить его так, чтобы он отправлял трафик для внешнего IP-адреса вашего сервера непосредственно на сервер, не перенаправляя его из интернет-соединения и обратно. Это сохраняет внутренне видимый IP-адрес одним и тем же независимо от того, установлено соединение или нет, но это наиболее эзотерическое решение, поэтому оно должно быть хорошо задокументировано, если вы сделаете это, чтобы не сбить с толку кого-то (скорее всего, себя), кто должен отладить проблему маршрутизации когда-нибудь в будущем. Это также может не помочь, если вы не можете получить доступ к внешним DNS-серверам, когда ваше соединение обрывается, что возвращает нас к «настройке внутреннего DNS и использованию решения №1».
У вас есть несколько вариантов:
software.example.com к IP-адресу обратного прокси-сервера, таким образом вы можете использовать ту же настройку, что и для внешнего использования. Это можно сделать, например, с помощью NGINX, MS IIS или F5.software-testing.example.comдля тестовой среды и установите на этом сервере другой сертификат. На мой взгляд, это самый чистый вариант, поскольку вы не используете общую инфраструктуру, а сертификат SSL довольно дешев по сравнению с запуском дополнительных серверов и их обслуживанием.