Комментарии 15
К примеру, вместо домена Alex-GLuck-Awesome-Company.local, можно смело использовать домен для сайта компании Alex-GLuck-Awesome-Company.com.
Как этом случае, из внутренней сети, попасть на внешний сайт компании Alex-GLuck-Awesome-Company.com?
Когда вы используете домен внутри организации(freeipa, ldap, ad) машины в этом домены создаются с адресами 3его уровня: host1.Alex-GLuck-Awesome-Company.com, host2.Alex-GLuck-Awesome-Company.com, ovirtengine.Alex-GLuck-Awesome-Company.com. И они не пересекаются с именем сайта, следовательно когда вы пытаетесь открыть ресурс по домену у вас днс резолвит интернет адрес сайта, куда вы преспокойненько попадаете. Понятненько?
Я возможно что то путаю, но проблемы с внешними и внутренними именами доменов и хостов в разных зонах и в одной вполне можно решить за счет Split DNS, данная технология реализована, например, в BIND. Делается это достаточно легко, достаточно погуглить: «Split DNS: заставим BIND работать на два фронта» и прочитать.
Как правило в организациях используется АД и там split zone(название технологии в BIND) или zone view(название технологии в powerDNS) сделать и поддерживать нецелесообразно. Лучше жёстко разделить ДНС записи на публичные и внутруненние по разным ДНС серверам. ДНС для внутренних записей будут переназначать параметры для внешних. А во внешних будет вполне примитивная логика работы, и ограниченный объём по количеству записей.
Абсолютно солидарен с Вами. Так в «продакшене» обычно и происходит. Однако замечу, что данное положение дел может резко измениться если у вас много раздельных внутренних и внешних доменов, принадлежащих разным организациям, но по тем или иным причинам, внезапно, решившим объединить свою инфраструктуру ИТ. Сценарии могут быть разными и каждый сам выбирает, что и как ему будет удобно в его инфраструктуре.
Не очень понимаю, чем нам поможет Split-DNS в случае одинаковых имен внешнего сайта и домена AD.
Допустим, есть домен AD company.ru и внешний сайт company.ru. Изнутри company.ru будет резолвиться в имена контроллеров домена. И собственно должен в них резолвиться, иначе AD не будет нормально работать.
Попадать на внешний сайт придется всякими извратными путями, не совсем удобными для конечных пользователей. Если знаете какой-то приличный путь, я был бы не против его узнать тоже.
Допустим, есть домен AD company.ru и внешний сайт company.ru. Изнутри company.ru будет резолвиться в имена контроллеров домена. И собственно должен в них резолвиться, иначе AD не будет нормально работать.
Попадать на внешний сайт придется всякими извратными путями, не совсем удобными для конечных пользователей. Если знаете какой-то приличный путь, я был бы не против его узнать тоже.
Создайте домен ad.company.ru или office.company.ru. Ну или купите другой публичный домен, если не знаете как совместить одновременную работу публичной и внутренней части.
Резонный вопрос. Если внутри организации действительно развернут AD DC и его доменная зона совпадает с публичной, то простой и «бескостыльный» метод всё это подружить, приучить сотрудников писать имя хоста сервера где размещен сайт, обычно это «www», например: «www.company.ru» и вопрос уйдет сам собой. В прочих случаях DNS конечно не поможет никак в такой ситуации, так как корень домена в AD DC предопределен и менять данное положение дел очень чревато последствиями, кроме того корень домена это ещё и корень DFS. А что касается «костылей», то если вопрос ограничивается лишь сайтом компании, то веб-прокси сервер внутри компании может закрыть данную проблему, правда это потребует дистрибуции самого этого прокси сервера, что породит отдельную проблему, но в конечном счете каждый сам решает на что он может пойти ради искусства.
Ну, метод к чему-то приучать пользователей, мне бескостыльным никак не кажется. Это первый из двух известных мне костылей. Второй, это использовать прокси (уже не очень приятно, в век, когда космические корабли бороздят просторы) и на нем перенаправлять HTTP-запросы куда надо.
А бескостыльные, на мой взгляд, это именно что использование для внутреннего домена домена третьего уровня типа office .company.ru, как выше было сказано, или (сюрприз!) использование домена типа .local.
А вообще, учитывая, что у компаний иногда бывают переименования, объединения, разделения и т.п., использование какого-нибудь безликого corp.local мне видится наиболее оптимальным.
Проблемы с сертификатами для доменов .local, мне кажутся надуманными, так как публиковать сертификаты умеет любой мало-мальски приличный реверс-прокси.
А бескостыльные, на мой взгляд, это именно что использование для внутреннего домена домена третьего уровня типа office .company.ru, как выше было сказано, или (сюрприз!) использование домена типа .local.
А вообще, учитывая, что у компаний иногда бывают переименования, объединения, разделения и т.п., использование какого-нибудь безликого corp.local мне видится наиболее оптимальным.
Проблемы с сертификатами для доменов .local, мне кажутся надуманными, так как публиковать сертификаты умеет любой мало-мальски приличный реверс-прокси.
Абсолютно согласен и в своих практиках предпочитаю именно такой способ, разве что мне не очень нравится домен «local», как-то длинно и не благозвучно, я лично использую «lan». Мне кажется, все мы говорим об одном и том же, просто автор не достаточно точно описал данный момент в своей статье. И я вообще не до конца понимаю зачем он это сделал, так как данный вопрос лежит за рамками статьи.
Вашему самоподписанному сертификату на зоны local или lan никто не будет доверять. Никакой реверс-прокси не поможет, вы будете использовать 2 зоны тогда. Статья не об этом. Про домены я так понял тема холиварная, я добавлю в план статью с мыслями на этот счёт.
На всех контроллерах домена AD в IIS настроен сайт-заглушка-редирект, перенаправляющий на адрес www.company.ru, естественно, на внешний адрес. Всё работает, как часы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как подружить Ovirt и Let's Encrypt