Вам необходимо будет выбрать способ обращения компьютеров в сети друг к другу по имени, а также способ обращения людей со всего мира к вашим незащищенным хостам по имени. Для этого существует несколько путей.
╚ Примечание: если вы решили не создавать внутреннюю (частную) сеть, то переходите к разделу Разд. Полностью незащищенная сеть, поддерживаемая провайдером. ╩
В этом случае, первичный DNS сервер для вашего домена поддерживается провайдером. Тем не менее, вы используете DNS в вашей внутренней сети при общении компьютеров в ней между собой. Имена незащищенных хостов и их IP адреса передаются провайдеру. Если вы хотите, к примеру, чтобы хост betty.example.com был WWW и FTP сервером, то вам нужно попросить провайдера проставить записи CNAME для www.example.com и ftp.example.com, указывающие на betty.example.com.
Настройте DNS на шлюзе в вашу внутренню сеть. Это нормально, с точки зрения безопасности, кроме того, упрощает перенастройку, если вы решите в дальнейшем перенести первичный DNS сервер на одну из своих машин.
Я предполагаю, что машина, на которой установлен сервер имен, имеет имя dns.example.com, является шлюзом во внутреннюю сеть, псевдонимом для fred.example.com и ее IP адрес 192.168.1.1. Если в вашем случае это не так, то нужно просто внести небольшие изменения в конфигурацию. Я не буду рассматривать их в этом HOWTO, за исключением особо интересных случаев.
Вам нужно будет скачать и скомпилировать последнюю версию BIND, the Berkeley Internet Name Domain. Ее можно найти на сайте BIND. Далее нужно настроить демон. Создайте файл /etc/named.conf со следующим содержимым:
options {
directory "/var/named";
listen-on { 192.168.1.1 };
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "pz/1.168.192";
};
zone "example.com" {
type master;
notify no;
file "pz/example.com";
}; |
Обратите внимание, что мы объявляем себя администратором (master) домена example.com. Между тем, наш провайдер также объявляет себя администратором для того же домена. Проблем не возникнет, если быть внимательным с настройкой. Все машины из внутренней сети должны для разрешения имен обращаться к dns.example.com. Они не должны обращаться к серверу провайдера, так как он считает себя администратором всего домена, но не знает IP адресов или имен машин из вашей внутренней сети. Аналогично, незащищенные хосты должны обращаться к серверу провайдера, а не к внутреннему серверу dns.example.com.
Теперь нужно создать различные файлы в подкаталоге /var/named.
Файл root.hints в точности соответствует описанному в документации по BIND и DNS HOWTO. К моменту создания этого документа следующие записи файла root.hints соответствовали действительности:
H.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.63.2.53 C.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.33.4.12 G.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.112.36.4 F.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.5.5.241 B.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.9.0.107 J.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.41.0.10 K.ROOT-SERVERS.NET. 6d15h26m24s IN A 193.0.14.129 L.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.32.64.12 M.ROOT-SERVERS.NET. 6d15h26m24s IN A 202.12.27.33 I.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.36.148.17 E.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.203.230.10 D.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.8.10.90 A.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.41.0.4 |
Файл pz/127.0.0 выглядит так:
$TTL 86400
@ IN SOA example.com. root.example.com. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS dns.example.com.
1 PTR localhost. |
Файл pz/1.168.192 выглядит так:
$TTL 86400 @ IN SOA dns.example.com. root.dns.example.com. ( 1 ; Serial 8H ; Refresh 8 hours 2H ; Retry 2 hours 1W ; Expire 1 week 1D ; Minimum 1 day ) NS dns.example.com. 1 PTR fred.example.com. PTR dns.example.com. PTR mail.example.com. 2 PTR barney.example.com. 3 PTR wilma.example.com. |
Файл pz/example.com выглядит так:
$TTL 86400 @ IN SOA example.com. root.dns.example.com. ( 1 ; Serial 8H ; Refresh 8 hours 2H ; Retry 2 hours 1W ; Expire 1 week 1D ; Minimum 1 day ) NS dns.example.com. IN A 192.168.1.1 IN MX 10 mail.example.com. IN MX 20 <ISP mail machine IP>. localhost A 127.0.0.1 fred A 192.168.1.1 A 10.1.1.9 dns CNAME fred mail CNAME fred barney A 192.168.1.2 wilma A 192.168.1.3 betty A 10.1.1.10 www CNAME betty ftp CNAME betty |
Одна строка из раздела "options" файла /etc/named.conf требует комментария:
listen-on { 192.168.1.1 }; |
╚ Примечание: если вы решили не создавать внутреннюю сеть, то переходите к разделу Разд. Полностью незащищенная сеть, поддерживаемая провайдером. ╩
Если вы решили использовать эту конфигурацию, значит вы решили, что ваша внутренняя сеть довольно мала и не будет часто меняться. Вы решили не использовать централизованную базу данных DNS сервера, а вместо этого поддерживать разрешение имен отдельно для каждой машины. Все машины должны обращаться к DNS серверу провайдера для разрешения имен машин за пределами внутренней сети. Для разрешения имен внутренней сети, необходимо создать таблицу хостов. Для Linux это означает внесение имен и IP адресов в файл /etc/hosts на каждой машине. Каждый раз при смене IP адреса или добавлении новой машины в сеть, этот файл должен быть обновлен на каждой машине.
Как и в разделе Разд. DNS во внутренней сети, домен поддерживается провайдером, списки имен хостов и IP адреса внешних хостов, а также все псевдонимы (такие как имена для ftp и www серверов) должны быть переданы провайдеру.
Я не буду рассматривать случай использования named для разрешения имен назащищенных хостов и отдельной, для каждой машины во внутренней сети базы хотя это можно реализовать. Если вы собираетесь использовать named для внешней или для внутренней сети, то почему бы не сделать это для обеих, хотя бы для упрощения конфигурации. В этом разделе я буду предполагать, что шлюз внутренней сети занимется разрешением имен и для внешней и для внутренней сети.
Нам требуется по-разному реагировать в зависимости от того, пришел ли запрос извне (в этом случае, мы не должны посылать IP адреса машин внутренней сети), или из внутренней сети. Ко времени написания этого документа существовал пакет BIND версии 8.2.2, используя который это поведение можно было релизовать, лишь запуская два демона named с различной конфигурацией. Впрочем, ведется активное обсуждение введения нового ключего слова "views", которое, возможно, будет добавлено для этой цели в BIND. Пока же придется довольствоваться предложенным решением.
В первую очередь, настройте сервер имен для внутренней сети, как описано в разделе Разд. DNS во внутренней сети, домен поддерживается провайдером.
Далее нужно настроить DNS для домена так, как он будет виден для остального мира. Свяжитесь с вашим провайдером и выясните делегирует ли он вам обработку запросов на реверсный поиск имен (reverse lookup). Хотя изначально DNS стандарт не рассматривал возможность обслуживания реверсных запросов на подсетях меньших, чем сети класса C, позже был разработан обходной путь, работающий со всеми, соответствующими стандарту, DNS клиентами, и закрепленный в RFC 2317. Если ваш провайдер собирается делегировать вам контроль за реверсным DNS вашего диапазона IP адресов, то вам необходимо будет выяснить точное имя in-addr псевдо-домена, выбранного ими для делегирования (RFC не дает соглашений для повседневнего использования). Я буду считать, что провайдер делегировал вам контроль, и имя псевдо-домена - 8.1.1.10.in-addr.arpa. Провайдер должен будет внести записи подобные
8.1.1.10.in-addr.arpa. 2H IN CNAME 8.8.1.1.10.in-addr.arpa. 9.1.1.10.in-addr.arpa. 2H IN CNAME 9.8.1.1.10.in-addr.arpa. 10.1.1.10.in-addr.arpa. 2H IN CNAME 10.8.1.1.10.in-addr.arpa. и т.д. |
Если провайдер собирается делегировать вам контроль за реверсным DNS, то он проставит CNAME записи в свою таблицу реверсной DNS зоны, указывающие на соответствующие записи в вашем псевдо-домене, как показано выше. Если он не собирается делегировать вам контроль, то вам придется просить его обновлять записи реверсной зоны каджый раз, когда вы будете добавлять, удалять или менять имя видимой изне машины вашего домена. Если данные реверсной DNS таблицы не соответствует данным прямой, то определенные услуги могут выдавать предупреждения или отказываться работать с машинами, для которых имеет место несоответствие.
Теперь создайте конфигурацию для второго named, который будет отвечать на запросы машин вне внутренней сети. Нужно перечислить только те хосты и IP адреса, которые видны снаружи. Ответы будут посылаться только на запросы, приходящие на внешний интерфейс шлюза.
Сперва создайте второй файл конфигурации, например /etc/named.ext.conf. В нашем случае он будет таким:
options {
directory "/var/named";
listen-on { 10.1.1.9; };
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "8.1.1.10.in-addr.arpa" {
type master;
file "ext/8.1.1.10";
};
zone "example.com" {
type master;
notify no;
file "ext/example.com";
}; |
Файлы root.hints и pz/127.0.0 , оба из каталога /var/named используются обеими демонами. Файл ext/8.1.1.10 выглядит так:
$TTL 86400
@ IN SOA fred.example.com. root.fred.example.com. (
1 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
NS dns.example.com.
9 IN PTR fred.example.com.
PTR dns.example.com.
PTR mail.example.com.
10 IN PTR betty.example.com.
PTR www.example.com.
PTR ftp.example.com. |
Файл ext/example.com содержит следующее:
$TTL 86400
@ IN SOA example.com. root.fred.example.com. (
10021 ; Serial
8H ; Refresh 8 hours
2H ; Retry 2 hours
1W ; Expire 1 week
1D ; Minimum 1 day
)
NS fred.example.com.
IN A 10.1.1.9
IN MX 10 mail.example.com.
IN MX 20 <ISP Mail Machine>.
localhost A 127.0.0.1
fred A 10.1.1.9
betty A 10.1.1.10
dns CNAME fred
mail CNAME fred
www CNAME betty
ftp CNAME betty |
Запустите оба демона на машине, являющейся шлюзом внутренней сети. В скрипты инициализации сетевых демонов внесите следующие строки:
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf /usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf |
Машины во внутренней сети должны быть настроены на работу с dns.example.com (в нашем примере имеющем IP адрес IP 192.168.1.1), в то время, как видимые извне машины могут посылать запросы как на внешний интерфейс шлюза внутренней сети (в нашем примере IP адрес 10.1.1.9), так и на DNS сервер провайдера.
В этой конфигурации все хосты видимы снаружи. Каждая машина домена имеет реальный IP адрес. Вы предоставляете провайдеру список IP адресов машин и их имена. Провайдер дает вам адрес, как минимум, одного своего DNS сервера. Настройка разрешения имен в Linux производится в файле /etc/resolv.conf:
search example.com nameserver <DNS host 1> nameserver <DNS host 2> |
Машины, работающие под Windows, настраиваются подобным же образом через диалоги настройки сети.
Если по какой-либо причине (например, смена провайдера) вы решили перенести ваш домен на новый IP адрес, то перед переносом необходимо подготовиться к нему.
Вам, наверное, хотелось бы, чтобы можно было после смены IP мгновенно перенастроить DNS со старых адресов на новые. Увы. Удаленные системы кэшируют ваши IP адреса, поэтому на последующие запросы будут возвращать ваши старые адреса, вместо того, чтобы запрашивать соответствующие сервера. В результате те, кто работал с вашим сайтом в момент смены IP адрсесов не смогут подсоединиться, хотя новые посетители будут нормально работать, так как только они получат правильные некэшированные данные. Кроме того, базовые сервера обновляются всего лишь два раза в сутки, поэтому сложно определить точное время, в которое они обновят ссылки на ваши первичный и вторичный сервер DNS.
Самый простой способ перейти на новые IP адреса - скопировать ваш сайт, по крайней мере его видимую часть, на новые IP адреса, а затем подождать, пока траффик не сместится туда полностью. Хотя этот способ не очень практичен.
Первое, что нужно сделать - договориться с вашим новым провайдером (или с вашим нынешним, если вы просто меняете IP адрес), чтобы он обновил ссылки на ваши первичный и вторичный сервер DNS. Это должно быть сделано, хотя бы за день до перемещения. Попросите его установить время жизни (TTL) на эту запись очень маленькое (минут 5, обычно это значение установлено 86400 сек. (1 день)).
По прошествии дня, присвойте вашей машине новый IP адрес. Синхронизируйте это с записями DNS у вашего провайдера. И верните TTL на прежнее значение.
Новый первичный и DNS серверы должны быть направлены на настоящий IP арес вашего сайта, с маленьким TTL.
Теперь, вы готовы к перемещению. Переместите машины на новые IP адреса Совместите это с обновлением записей DNS у провайдера. Через 5 минут (если установлен маленький TTL, до перемещения), траффик должен быть переключен на новый сайт. Теперь вы можете перестроить полномочия DNS на ваш вкус, создав первичный сервер, если вы этого хотите, и восстанавив обратно TTL на большое значение.
Конфигурация, описанная в разделе Разд. Настройка разрешения имен, имеет МХ записи, указывающие на машину ``mail.example.com''. МХ запись, с наиболее низким приоритетом, указывает удаленным серверам, куда посылать электронные письма. Другие записи МХ, с более высоким приоритетом используются как резервные приемники электронных писем. Они будут держать электронные письма в течении некоторого времени, пока основной приемник писем не может их обработать по какой-либо причине. Для примера считаем, что под псевдонимом fred.example.com mail.example.com обрабатывает электронные письма домена. Если Вы хотите разрешить доступ ISP ко всем работающим у Вас адресам электронной почты, Вы должны изменить записи МХ таким образом, чтобы указать на соответствующие ISP-машины. Спросите в службе технической поддержки Вашего ISP о том, какие имена хостов можно использовать в МХ записях.
Если Вы решили поднимать электронную почту для Вашего домена, нужно будет проделать несколько шагов для ее настройки. Если настройка произведена невнимательно, то вероятно, письма будут ходить очень медленно, т.к. будут находиться на одном хосте, в то время, как получатель зарегистрирован на другом. Из соображений безопасности, я рекомендую, чтобы почта, приходящая с машин, которые доступны из внешней сети, фильтровались (это поможет при борьбе с теми, кто хочет, чтобы у его настольной машины был реальный IP, а потом удивляется, почему его машина зависает дважды в день). Задача использования системы пересылки электронной почты целиком решается при помощи sendmail. Если кто-нибудь захочет рассказать о работающем решении на другом транспорте электронной почты, я только приветствую добавления.
Чтобы электронный адрес, зарегистрированный на одном хосте был виден на всех машинах, самое простое решение - экспортировать почтовую директорию, с правами на запись и чтение, по всей частной сети. Шлюз Вашей частной сети будет как собиратель и отправитель электронных писем для всей частной сети, у которой должны быть права на запись в директорию mail у root'а. Другие клиенты могут иметь или могут не иметь таких прав, по Вашему усморению. Моя личная философия безопасности - не должны предоставляться привилегии, если нет явной причины для этого. Из-за этого в моей сети root может читать почту только с определенной машины, но это не такое уж большое препятствие. Обратите внимание, что каталог почты может быть каталогом в сети, экспортируемым через NFS, или это может быть каталог на одном из внутренних серверов, экспортируемый в частную сеть. Если почтовый каталог резидентен на шлюзе частной сети, то не будет никаких проблем с правами для этой машины. Если же он находится на другом сервере, то обратите внимание, что электронные письма будут возвращаться, если с этим сервером, шлюзом или сетевым соединением возникнут проблемы.
Для Windows-машин в Вашей частной сети можно также установить РОР сервер на хосте, обслуживающем почту, или использовать samba для экспорта почты на эти машины. Windows-машины могут быть настроены для отправки и получения почты под именем пользователя Linux, типа joeuser@example.com так, чтобы адрес содержал имя хоста и доменное имя, но не имя машины такое, как barney.example.com. SMTP сервер должен быть установлен на gateway-машине частной сети, которая будет отвечать за отправку и любую пересылку почты.
Затем Вы должны настроить sendmail, чтобы отправлять письма от машин частной сети, переписывая адреса, если это необходимо. Получите исходники последней версии sendmail на sendmail.org. Соберите его, затем зайдите в подкаталог cf/domain, в каталоге с sendmail и создайте новый файл: example.com.m4
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Используя этот файл Вы соглашаетесь на все условия, перечисленные # в файле с лицензией, который поставляется с дистрибутивом # sendmail. # # # # Ниже идет универсальный файл настройки домена. Он должен подходить # к вашей системе. Если хотите перенастроить его, скопировать его в файл # для Вашего домена или сделать изменения, то скопируйте соответствующие # .mc файлы и измените `DOMAIN(generic)' чтобы сослаться на модифицированные # файлы. # divert(0) define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl FEATURE(redirect)dnl MASQUERADE_AS(example.com)dnl FEATURE(masquerade_envelope)dnl |
Этот файл определяет домен ``example.com''. Далее Вы должны создать файлы sendmail.cf, которые будут использоваться на хосте почты (шлюзе частной сети) и на других Linux-узлах частной сети.
Создайте следующий файл в поддиректории программы sendmail cf/cf: example.master.m4
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Используя этот файл, Вы соглашаетесь на все условия, перечисленные # в файле с лицензией, который поставляется с дистрибутивом # sendmail. # # # # Это прототип файла конфигурации, которая поддерживает только основной # протокол SMTP через TCP. # # Вы должны изменить макрокоманду `OSTYPE' в зависимости от ОС, на # которой этот файл будет работать; в данном файле Вы установите местоположение # различных файлов поддержки Вашей ОС. Вы можете создать файл домена в # ../domain и ссылаться на него, добавляя макрокоманду `DOMAIN' после # макрокоманды `OSTYPE'. Я рекомендую, скопировать данный файл # под другим именем, чтобы при обновлении версии sendmail Вам не приходилось # заново набирать его. # divert(0)dnl OSTYPE(linux)dnl DOMAIN(example.com)dnl FEATURE(nouucp) FEATURE(relay_entire_domain) FEATURE(`virtusertable', `hash /etc/sendmail/virtusertable')dnl FEATURE(`genericstable', `hash /etc/sendmail/genericstable')dnl define(`confPRIVACY_FLAGS', ``noexpn,novrfy'')dnl MAILER(local) MAILER(smtp) Cw fred.example.com Cw example.com |
Другой файл, который Вы должны создать, определит sendmail.cf для зависимых машин: example.slave.m4
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Используя этот файл, Вы соглашаетесь на все условия, перечисленные # в файле с лицензией, который поставляется с дистрибутивом # sendmail. # # # # Это прототип для "пустого клиента" -- т.е. клиента, который не # делает ничего, кроме отправки всех писем в почтовый сервер. В таком # виде данный файл не пригоден для использования!!! # # Для его использования Вы должны использовать свойство nullclient с # именем почтового сервера в качестве аргумента. Также определите # `OSTYPE', чтобы определить очередь каталогов и т.п. # Кроме того, выберете свойство nocanonify. Это поможет # посылать адреса через SMTP соединение; обычно они посылаются с подменой имени, # которая по умолчанию производится сервером почты. # # Данный файл не должен содержать никакие другие строки, кроме вышеперечисленных. # divert(0)dnl OSTYPE(linux) FEATURE(nullclient, fred.$m) Cm example.com |
Сформируйте соответствующие файлы sendmail.cf командой:
make example.master.cf example.slave.cf |
Эта конфигурация преполагает помещение большинства файлов конфигурации в подкаталог /etc/sendmail/. Она заставляет sendmail анализировать и использовать два специальных файла virtusertable.db и genericstable.db. Чтобы получить эти файлы, создайте их родительские прототипы. Первый - virtusertable.src:
John.Public@example.com jpublic Jane.Doe@example.com jdoe@somemachine.somedomain abuse@example.com root Pointyhaired.Boss@example.com #phb#@hotmail.com |
jpublic John.Public@example.com janedoe Jane.Doe@example.com whgiii Pointyhaired.Boss@example.com |
all : genericstable.db virtusertable.db virtusertable.db : virtusertable.src makemap hash virtusertable < virtusertable.src genericstable.db : genericstable.src makemap hash genericstable < genericstable.src |
Я имею опыт работы только с sendmail. Если у Вас есть опыт работы с другими транспортами почты, такими как Postfix, Exim, или smail, и Вы хотели бы дописать этот раздел, пожалуйста, свяжитесь со мной.
Вы должны установить сервер, видимый из внешней сети на машине, вне частной сети, а не на машине - шлюзе частной сети, по соображениям безопасности. Если серверу необходимо обращаться к некоторым ресурсам, находящимся внутри частной сети, ситуация становится более сложной. Вы не найдете описания таких случаев в данном документе.
Подробности об установке самого сервера могут быть найдены в документации к apache и в документе Linux WWW HOWTO.
Еще раз, FTP-хост должен быть виден из внешней сети, не устанавливайте FTP-сервер на шлюз частной сети. Прочитайте руководство по установке, которое идет с FTP-сервером. Убедитесь, что используете самую последнюю версию сервера, т.к. в ранних версиях многих FTP серверов есть уязвимые места, с точки зрения безопасности. Если Вам не требуется анонимный вход на FTP-сервер, убедитесь что отключили эту функцию в Вашей конфигурации. Я рекомендую, обязывать ваших пользователей использовать scp, это позволит им делать резервные копии всех изменяемых файлов. Более подробную информацию можно найти в разделе Разд. Безопасность Вашего домена.
Это обсуждается в разделе Разд. Конфигурирование Вашего брендмауэра.