СЕРГЕЙ СУПРУНОВ,телекомуникационен инженер с широк IT профил. В свободното си време изучава FreeBSD и Python и се опитва да разбере неприязънта си към KDE
Конфигуриране на DHCP сървъри
и конфигуриране на динамични DNS актуализации
Клиентът, разбира се, винаги е прав. Но само толкова, колкото сървърът му позволява.
Инсталиране и конфигуриране на ISC DHCP сървъра
Най-популярната реализация на DHCP сървър на UNIX-подобни системи е dhcpd разработката на Internet Systems Consortium (ISC). По подразбиране FreeBSD не включва тази програма. Доста лесно се инсталира от колекцията „Портове“:
# cd /usr/ports/net/isc-dhcp30-server/
# направете инсталиране
Но, за съжаление, към момента на писане на статията единствената версия, която можеше да се инсталира без проблеми - 3.0.7 - беше много остаряла (поддръжката й беше официално спряна през март 2009 г.).
В резултат на това беше решено да се инсталира ISC DHCP версия 4.1.0 от източника (командата „./configure --help“ след разопаковането ще ви позволи да видите наличните опции на конфигуратора; може да искате да използвате някои от тях) :
# извличане на http://ftp.isc.org/isc/dhcp/dhcp-4.1.0.tar.gz
dhcp-4.1.0.tar.gz 100% от 1061 kB 174 kBps
# tar xzvf dhcp-4.1.0.tar.gz
# cd dhcp-4.1.0
# ./configure
# направи
# направете инсталиране
След инсталирането ще трябва ръчно да подготвите скрипт за автоматично стартиране. Можете да използвате един от наличните в /usr/local/etc/rc.d или /etc/rc.d като основа. Тук измамих малко и използвах скрипта от порта на isc-dhcp-30-сървъра:
# cd /usr/ports/net/isc-dhcp30-сървър
#mkdirwork
# направи списък за прилагане
# cp работа/isc-dhcpd /usr/local/etc/rc.d/
Тъй като името на демона и повечето ключове за стартиране са еднакви, такова заместване не би трябвало да създава проблеми.
Има един важен момент - за да работи DHCP сървърът, ядрото на системата трябва да бъде сглобено с поддръжка за bpf псевдоустройство (филтър за пакети Berkeley; използва се за получаване на „сурови“ данни от интерфейса, включително излъчвани пакети). GENERIC ядрото винаги включва тази поддръжка, така че освен ако изрично не я изключите, не трябва да се изисква повторно изграждане на ядрото.
Можете да проверите дали това устройство е включено във вашето ядро по следния начин:
$ grep bpf /usr/src/sys/`uname -p`/conf/`uname -i`
# Устройството `bpf" позволява пакетния филтър на Бъркли.
# Имайте предвид, че "bpf" е необходим за DHCP.
устройство bpf # Бъркли пакетен филтър
Сега нека добавим няколко реда към /etc/rc.conf (това обаче ще работи само ако обработката на променливи е предвидена в скрипта за автоматично стартиране; isc-dhcpd, който „изтръгнахме“ от портовете, го предоставя):
dhcpd_enable="ДА"
dhcpd_ifaces="nfe0"
Основните параметри са зададени във файла /usr/local/etc/dhcpd.conf (примерен файл ще бъде инсталиран по време на инсталацията).
Нека да разгледаме пример за не сложна, но доста работеща конфигурация:
# Име на домейн. Имената на клиентски хостове ще бъдат разширени до FQHN
име на домейн опция "example.org";
# DNS сървъри, които ще се предлагат на клиенти.
# Можете също да използвате техните IP адреси
опция домейн-име-сървъри ns1.example.org, ns2.example.org;
# „По подразбиране“ и максимално време за наемане на адрес в секунди
default-lease-time 3600;
max-lease-time 86400;
авторитетен;
# Метод за динамично актуализиране на DNS.
# Ще говорим повече по-късно, сега ще го изключим
ddns-update-style няма;
# Източник на съобщение за регистриране чрез syslogd
лог-съоръжение local7;
# Подмрежова декларация
диапазон 192.168.1.200 192.168.1.249;
Опция рутери 192.168.1.1;
В самото начало на файла се поставят глобални параметри, които, ако е необходимо, могат да бъдат предефинирани допълнително в отделни „декларации“ на подмрежи и диапазони. Обикновено тук се посочват името на домейна, списък с DNS сървъри (ако същите се използват за повечето от поддържаните мрежи) и стойности за времето за наемане (по подразбиране максимумът; ако е необходимо, можете да зададете минимумът).
Параметърът авторитет ви позволява да декларирате сървъра авторитетен (отговорен) в обслужваната мрежа. Разликата между авторитетен сървър и „обикновен“ е, че последният игнорира всички заявки за адреси, които не са описани в неговата конфигурация, докато авторитетният сървър изпраща DHCPNAK в отговор на такива заявки. Благодарение на това поведение, клиент, преместен от друга подмрежа, ще може да получи нов адрес по-бързо (в отговор на DHCPREQUEST с адрес от предишната подмрежа, той незабавно ще получи DHCPNAK и ще започне да получава нов адрес; в противен случай, DHCPDISCOVER ще бъде изпратен само след като времето за изчакване изтече отговор). В същото време „случайните“ DHCP сървъри (например, погрешно стартирани с настройки от примерния файл) е по-малко вероятно да се намесват в мрежата, тъй като, тъй като не са авторитетни, те просто ще игнорират DHCPREQUEST заявките на „други хора“.
За да поддържате регистрационни файлове (а те никога няма да са излишни), в допълнение към декларирането на източника (съоръжението) в конфигурацията на dhcpd, ще трябва да направите още две неща: да създадете лог файл (например с командата „touch /var /log/dhcpd.log”) и добавете реда към /etc/syslog.conf:
local7.* /var/log/dhcpd.log
След което syslogd трябва да се рестартира:
/etc/rc.d/syslogd рестартирайте
Е, не забравяйте да конфигурирате ротацията на този лог файл в /etc/newsyslog.conf.
Нека се върнем към конфигурацията на dhcpd. Всички най-интересни неща се съдържат в описанието на подмрежата. В нашия пример всичко е просто - с диапазонния ред ние определяме диапазона от адреси, които dhcpd може да „наеме“ на клиентите, опцията за рутери определя списък с маршрути по подразбиране. Друга настройка, необходима за работа в мрежата – адреси на DNS сървъри – ще бъде получена от глобалната опция сървъри за имена на домейни.
Моля, обърнете внимание, че по описанието на подмрежата авторитетният сървър ще разграничи „валидните“ от „невалидните“ адреси. По този начин сървър, работещ с горната конфигурация, ще върне DHCPNAK в отговор на заявка (DHCPREQUEST) за адрес 192.168.0.22 (тъй като заявеният адрес не попада в подмрежа, която му е известна), но ще остане мълчалив, когато иска адреса 192.168.1.22 (тъй като този адрес, въпреки че не е включен в нито един от диапазоните, е правилен за тази подмрежа и може да се обслужва от втори DHCP сървър; ще говорим за това по-подробно по-късно в раздела).
В допълнение към обхвата на адресите и шлюза, можете да посочите огромен брой допълнителни опции в описанието на подмрежата. Пълен списък на поддържаните опции можете да намерите в помощта: man dhcp-options(5).
Ако множество подмрежи са достъпни през един интерфейс, тогава техните декларации за подмрежи трябва да бъдат вложени в декларация за споделена мрежа:
споделена мрежа rl0-net (Подмрежа 192.168.1.0 мрежова маска 255.255.255.0 (
Обхват 192.168.1.100 192.168.1.199;
Опция рутери 192.168.1.1;
Подмрежа 192.168.2.0 мрежова маска 255.255.255.0 (
Обхват 192.168.2.100 192.168.2.199;
Опция рутери 192.168.2.1;
Опциите, общи за всички подмрежи, могат да бъдат поставени директно в декларацията за споделена мрежа - в този случай те ще засегнат всички декларации за подмрежи.
Басейни и класове
Понякога се налага да разделяме клиентите по един или друг критерий и да им даваме различни възможности. Например искаме да разпределим адреси от диапазона 10.0.0.10 - 10.0.0.19 на клиенти, чието име на хост започва с "a" (например "acer"), и на всички останали от 10.0.0.20 - 10.0.0.99. За да направите това, можете да използвате декларация на клас и два така наречени пула:
клас "а-клиенти" (Съвпадение, ако подниз (опция име на хост, 0, 1) = "a";
подмрежа 10.0.0.0 мрежова маска 255.255.255.0 (
басейн (
Разрешаване на членове на "а-клиенти";
Диапазон 10.0.0.10 10.0.0.19;
басейн (
Отказване на членове на "а-клиенти";
Диапазон 10.0.0.20 10.0.0.99;
Тоест, присвоихме клиентски машини към класа a-клиенти съгласно горния израз и след това създадохме два пула, в единия от които разрешихме обслужване на членове от съответния клас, а в другия, напротив, ги забранихме. По подобен начин можете да създавате изрази въз основа на MAC адреса (хардуерна променлива) и други опции. Повече информация относно синтаксиса на изразите, позволени в конфигурацията на dhcpd, може да бъде намерена на страницата на ръководството dhcp-eval(5).
В допълнение към членството в класа, командите за разрешаване/забраняване поддържат изразите unknown-clients (клиенти, които не са предали своите имена на хостове), known-clients (тези, които са ги предали) и all clients (всякакви клиенти). Вижте документацията за подробности.
Фиксирани адреси
Понякога има нужда от по-ясен контрол на получаването на адреси от някои хостове. Например само някои компютри в локалната мрежа изискват достъп до интернет, докато на прокси сървър достъпът се регулира от IP адрес. Можете ръчно да зададете адреси на „избрани“ хостове, които не попадат в интервала, обслужван от сървъра. Или можете да използвате механизма за присвояване на фиксирани адреси, който dhcpd предоставя:
хост acer (Хардуерен Ethernet 00:1b:38:22:8c:17;
Фиксиран адрес 10.161.193.177;
Ако добавите този фрагмент към конфигурационния файл (и не забравяйте да рестартирате dhcpd), тогава този хост винаги ще получава посочения IP адрес. Идентификацията на хоста ще се извършва чрез MAC адрес. IP адресите, присвоени на конкретни хостове по този начин, не трябва да попадат в нито един от диапазоните.
Ако трябва да опишете няколко хоста, които имат много от едни и същи опции, те могат да бъдат комбинирани в група:
група(Общи опции...
Хост acer ( ...специфични опции за хост...)
Хост fuji (...специфични опции за хост...)
В този случай общите опции са включени в декларацията на групата, докато отделните опции остават в декларациите на хоста.
Характеристики на използване на множество DHCP сървъри
В сравнително големи мрежи, от съображения за надеждност и балансиране на натоварването, обикновено се използват няколко DHCP сървъра. Очевидно е необходимо да се избягва „припокриването“ на адресното пространство, когато един и същ IP адрес може да бъде издаден от различни сървъри. В противен случай е възможен конфликт - в края на краищата, ако сървър "A" даде на клиента определен адрес, тогава сървър "B" все още ще го счита за свободен и може да го даде на друг клиент (клиентът, преди да приеме IP адреса, трябва използвайте ARP-заявка, за да сте сигурни, че той е свободен; това донякъде намалява вероятността от конфликт, но все пак не го елиминира напълно).
Класическата препоръка, известна като „правилото 80/20“, е следната: един сървър (основен) трябва да обслужва 80% от адресите на пула, а втори сървър (вторичен) трябва да обслужва останалите 20%. Това ще позволи на мрежата да „издържи“ известно време на един спомагателен сървър в случай на проблеми с основния, при условие че не всички клиенти започват да искат адреси едновременно. Вярно е, че когато прилагате това правило във вашата мрежа, препоръчително е да се уверите, че основният сървър е по-бързият - в противен случай спомагателният незабавно ще разпредели пула си на клиентите и ако възникне извънредна ситуация, той просто няма да има какво да предлагайте ги. (В настройките на ISC сървъра можете да зададете параметъра min-secs, който указва закъснението в секунди преди издаване на отговор на клиента. Използването му на вторичния сървър ще увеличи шансовете първичният сървър да отговори първи.)
Възниква въпросът: няма ли два авторитетни DHCP сървъра да си пречат? Ако те имат една и съща декларация за подмрежа (но различни, неприпокриващи се адресни интервали, описани в обхват), тогава заявка за адрес от такава подмрежа, дори ако не е в обхвата, обслужван от определен сървър, няма да се счита за „чужд ” - сървърът просто няма да отговори, като по този начин ще позволи на друг сървър да обработи тази заявка. Ако този „друг сървър“ не е наличен, тогава клиентът, без да чака отговор на DHCPREQUEST, ще изпрати DHCPDISCOVER заявка и ще бъде безопасно обслужен от оставащия сървър.
Някои сървъри (по-специално ISC) поддържат така наречения механизъм DHC-FAILOVER (подготовката на съответния стандарт спря на документа http://tools.ietf.org/html/draft-ietf-dhc-failover-12) , който предоставя на два сървъра възможността да споделят общ пул от IP адреси, синхронизирайки информацията за издадените адреси и позволявайки им динамично да се сменят един друг, ако е необходимо.
Динамичен DNS
И така, ние решихме проблема с автоматичното получаване на настройки от мрежовите компютри. Но остава още един въпрос - интеграция с DNS сървъра. Разбира се, в повечето мрежи можете и без това - достъпът по име обикновено е необходим само до сървъри, които от своя страна почти винаги се конфигурират ръчно и следователно статичният DNS е напълно достатъчен. Но понякога все още е удобно, когато всеки клиентски компютър е достъпен в мрежата под собственото си име (особено ако не можете да разчитате на постоянството на IP адреса), така че нека да разгледаме как да конфигурирате динамично актуализиране на DNS записи (ако приемем, че ISC се използва като DNS сървър BIND).
На първо място, трябва да активирате автоматичните актуализации в настройките на вашия DNS сървър:
# Декларирайте ключа за достъп (можете да го зададете във всяка зона, но е по-удобно)ключ DHCP_KEY (
Алгоритъм hmac-md5;
# "Директна" зона
зона "test.inr" (
Тип майстор;
Файл "master/test.inr";
# "Обратна" зона
зона "0.0.10.in-addr.arpa" (
Тип майстор;
Разрешаване на актуализация (ключ DHCP_KEY; );
Файл "master/0.0.10.in-addr.arpa";
Тоест, ние декларираме DHCP_KEY (името може да бъде произволно) и след това го посочваме като условие, при което ще бъде разрешено обновяване на зони (в описанието на всички зони, които трябва да се обновяват автоматично). За да генерирате ключ (в секретния ред), можете да използвате помощната програма mmencode:
$ echo "Супер таен ключ" | mmencode
U3VwZXIgc2VjcmV0IGtleQo=
Помощната програма md5 върши добра работа:
$ echo "Супер таен ключ" | md5
Въпреки че по-„правилният“ начин за генериране на ключ е да използвате помощната програма dhssec-keygen:
$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST test.inr
Ktest.inr.+157+41531
$ ls -l Ktest.inr.+157+41531.*
Rw------- 1 amsand amsand 52 11 19 август: 08 Ktest.inr.+157+41531.key
Rw------- 1 amsand amsand 92 11 19 август: 08 Ktest.inr.+157+41531.частен
Тук създаваме 128-битов „хост“ ключ, използвайки алгоритъма HMAC-MD5, наречен test.inr. В резултат на това се формират два файла - ключът може да бъде извлечен от всеки един.
Е, за да се повиши сигурността (тъй като файлът named.conf обикновено се чете от всички потребители), ключовият оператор се поставя в отделен файл, който може да се чете само от root потребителя, и в named.conf се включва с помощта на оператора за включване:
включва "key.conf";
Вместо разрешаване на актуализация, можете да използвате по-„мощния“ раздел за правила за актуализиране (ние допълнително ще ограничим типа публикации и поддомейн):
зона "test.inr" (Тип майстор;
Правила за актуализиране (
Предоставяне на DHCP_KEY поддомейн test.inr A TXT;
Файл "master/test.inr";
Сега остава да направите някои промени в DHCP конфигурацията:
# Посочете метода за актуализиране (има и ad-hoc, но не се препоръчва)ddns-update-style interim;
# Ние описваме същия ключ (можете просто да го копирате от named.conf - синтаксисът е същият)
# Ако операторът за ключ е поставен в отделен файл, можете, както в named.conf, да използвате оператора include:
### включват "key.conf";
ключ DHCP_KEY (
Алгоритъм hmac-md5;
Тайна "c20f9433f5f5ecf1f245a6112d7dd651";
# "Директна" зона за актуализиране
зона test.inr (
Основен 10.0.0.220;
Ключ DHCP_KEY;
# "Обратна" зона, която трябва да се актуализира
зона 0.0.10.in-addr.arpa (
Основен 10.0.0.220;
Ключ DHCP_KEY;
Когато описвате зони, основният параметър указва адреса на основния DNS сървър, обслужващ зоната (т.е. този, на който трябва да се изпращат актуализации).
Сега трябва да се уверим, че потребителят, под чието име се изпълнява посоченият процес (при FreeBSD това обикновено е bind), има правото да създава файлове в директорията /var/named/etc/namedb/master.
Ако всичко е направено правилно, следващия път, когато клиентът поиска адрес, файловете, съответстващи на зонови файлове с разширение jnl, ще се появят в главната директория. Това са регистрационни файлове за актуализиране, използвани от сървъра за възстановяване на съответната информация след рестартиране. Тук ще се съхраняват съответните записи на ресурси (в двоичен формат, така че четенето им няма да ви даде нищо полезно).
В случай на проблеми вижте регистрационните файлове. По-долу са две съобщения от /var/log/messages, които срещате най-често:
4 май 17:23:14 freetest dhcpd: ако acer.example.org IN A rrset не съществува, добавете acer.example.org 300 IN A 10.0.0.180: времето изтече.
4 май 17:27:23 freetest име: master/test.inr.jnl: създаване: разрешението е отказано
Първият запис в този случай е причинен от несъответствие в име на домейн - домейнът „по подразбиране“ example.org е посочен в DHCP конфигурацията, която не се обслужва от нашия DNS сървър. За съжаление, това не е единствената причина за времето за изчакване - трябва също така да имате предвид правата за достъп до съответните файлове, правилата за филтриране на пакети (ако DHCP и DNS работят на различни машини) и коректността на посочване на адреса на DNS сървъра.
Второто показва, че посоченият процес не може да създаде jnl файл в главната директория. Очевидно проблемът е проблем с разрешения - уверете се, че посоченият процес може да създава файлове в главната директория и проблемът ще изчезне.
Както можете да видите, DHCP е доста мощен протокол, който ви позволява да автоматизирате много значителна част от процеса на настройка на мрежата. За съжаление, поради известна „грубост“ по отношение на стандартизацията и някои проблеми със сигурността, все още не може да се говори за 100% автоматизация. Но това не ви пречи да го използвате точно сега.
Приложение
WIDE DHCP
Трябва да се каже, че ISC DHCP не е единствената опция. В колекцията от портове можете да намерите друг DHCP сървър - WIDE DHCP. Вярно е, че този проект трудно може да се нарече „активен“ - текущата версия в „Портове“ (1.4.0.6_2) практически не е актуализирана от 2003 г., страницата на проекта (http://www.sfc.wide.ad.jp /~tomy/dhcp /index-e.html) е изоставен. Въпреки това, той се справя доста добре с основната задача.
Инсталирането от колекцията от портове ще изисква допълнителна работа. Началото е традиционно:
# cd /usr/ports/net-mgmt/wide-dhcp
# направете инсталиране
В резултат на това в /usr/local/sbin ще се появи dhcps файл, ще бъде създаден скрипт за автоматично стартиране и ще бъдат добавени съответните страници с ръководство.
След това трябва да редактирате скрипта за автоматично стартиране /usr/local/etc/rc.d/wide-dhcps.sh.sample (и да го преименувате на wide-dhcps.sh). Той не само е в „стария“ формат (т.е. не е подготвен за помощната програма rcorder), но е и недовършен. Трябваше ръчно да въведа променливата PREFIX и да добавя опции към стартовия ред на dhcps, които указват местоположението на конфигурационните файлове и базите данни. В същия ред трябва да посочите интерфейсите, на които dhcps трябва да работи.
След това файловете dhcpdb.pool и dhcpdb.relay ще трябва да бъдат създадени ръчно (по подразбиране в /etc промених директорията на /usr/local/etc, както е обичайно във FreeBSD). Примери могат да бъдат намерени в директорията db_sample на дистрибуцията. Вторият от тях се използва за указване на рутери, през които са достъпни други подмрежи, обслужвани от този DHCP сървър, а в случай на „линейна“ мрежова структура може да се остави празен (но самият файл трябва да съществува). Първият е основният конфигурационен файл. Нека ви дам един прост пример:
# Създайте подмрежа (ние добавяме общи параметри тук:
# маска, шлюз и адрес за излъчване)
подмрежа:snmk=255.255.255.0:rout=10.0.0.1:brda=10.0.0.255:
# (първото поле е само ID на публикацията,
# и също така свързва конфигурацията на подмрежата, дефинирана по-горе)
ip198: :ipad=10.0.0.198:dfll=3600:maxl=7200:tblc=подмрежа:
ip199: :ipad=10.0.0.199:dfll=3600:maxl=7200:tblc=подмрежа:
Както можете да видите, за всеки адрес на пул трябва да напишете свой собствен ред, но можете също да дадете на всеки адрес свои собствени параметри. Използва се същия файлов формат като за системните бази данни termcap, printcap и др.; Списъкът с наличните параметри е доста обширен (можете да го намерите в страницата на ръководството dhcpdb.pool(5)).
След всички тези мъки сървърът може да бъде стартиран и трябва да работи правилно. Въпреки това, като се има предвид объркващият синтаксис на конфигурацията, не намерих нито една причина, поради която тази реализация може да се използва вместо ISC. Но знанието за съществуването му е полезно във всеки случай.
Въпроси за сигурност
За съжаление, сигурността на DHCP протокола все още оставя много да се желае. Работните групи на IETF са предложили различни методи за подобряване на това (например удостоверяване на клиента, вижте RFC 3118), но повечето от тях все още не са приложени никъде.
DHCP реле
Както бе споменато в първата част на статията, DHCP протоколът активно използва заявки за излъчване, които почти винаги се отхвърлят от рутерите. Тоест разпространението им обикновено е ограничено до един сегмент от локалната мрежа.
Често обаче е непрактично да се инсталира отделен DHCP сървър на всеки сегмент. В този случай способността на повечето рутери да работят в режим DHCP Relay идва на помощ, „хвърляйки“ заявки и отговори между отделни подмрежи. Принципът на работа на такъв „прокси сървър“ е следният: след получаване на DHCP заявка за излъчване на един от обслужваните интерфейси, той я пренасочва (в обикновен, unicast пакет) към DHCP сървъри, дефинирани в неговата конфигурация. Полученият отговор се излъчва (ако е необходимо) в пакет към подмрежата, от която е дошла оригиналната заявка.
Повечето хардуерни рутери поддържат функцията DHCP Relay. Ако FreeBSD или Linux играе ролята на рутер между вашите подмрежи, можете да инсталирате или програмата dhcrelay, която е част от ISC DHCP пакета, или отделен сървър от колекцията портове - /usr/ports/net/dhcprelay. Конфигурирането и в двата случая се свежда до стартиране на тази програма с опции, които определят списъка с интерфейси за слушане и списъка с DHCP сървъри, към които заявката трябва да бъде препредадена. Във FreeBSD, в случай на програмата dhcprelay, за да я стартирате автоматично, просто включете три реда в /etc/rc.conf:
dhcprelay_enable="ДА"
dhcprelay_server="10.0.0.220"
dhcprelay_ifaces="ed0
Между другото, функцията DHCP Relay по някакъв начин увеличава управляемостта на мрежата, тъй като ви позволява изрично да посочите списък от DHCP сървъри, с които да работите.
помощна програма nsupdate
Дистрибуцията на ISC BIND включва помощна програма, която ви позволява да изпращате динамични DNS актуализации. Може да бъде полезно както за намиране на проблеми (например, ако когато DHCP сървърът издаде адрес на клиент, зоната не се актуализира, но чрез nsupdate зоните се актуализират нормално, става очевидно, че трябва да се справите с конфигурацията на dhcpd ), и за актуализиране на зони „ръчно“.
Нека да разгледаме типичен пример за работа:
$ nsupdate -v
> сървър 10.0.0.220
> ключ DHCP_KEY
> актуализиране добавяне на new.test.inr 300 A 10.1.1.15
>покажи
Изходяща заявка за актуализиране:
;; ->>ЗАГЛАВКА<<- opcode: UPDATE, status: NOERROR, id: 0
;; знамена: ; ЗОНА: 0, ПРЕДВАРИТЕЛНИ: 0, АКТУАЛИЗАЦИЯ: 0, ДОПЪЛНИТЕЛНИ: 0
;; СЕКЦИЯ ЗА АКТУАЛИЗИРАНЕ:
new.test.inr. 300 IN A 10.1.1.15
> изпрати
> напусни
Тоест, ние декларираме DNS сървър и таен ключ, след което използваме командата update add, за да поставим команда за добавяне на съответния запис в „опашката“ (300 в този пример е продължителността на живота на записа). С командата show можете да видите текущото състояние на „опашката“ изпращане на този пакет към сървъра. Ако всичко е минало добре (и тъй като не се показват съобщения за грешка, това е както трябва), тогава когато поискате от DNS сървъра адреса за new.test.inr, ще получите 10.1.1.15. (Да, този адрес не е валиден за нашата подмрежа, но DNS сървърът не навлиза в тези „тънкости“ - той просто си върши работата.)
В допълнение към своя интерактивен режим, nsupdate ви позволява да изпълнявате команди от файл, което може да бъде полезно за автоматично извършване на актуализации. Вижте man nsupdate(8) за подробности.
- Страница на официалния уебсайт на ISC DHCP – https://www.isc.org/software/dhcp.
- Колисниченко Д. Конфигуриране на DHCP. // Системен администратор, № 5, 2003 г. – стр. 12-14 (http://www.algoint.ru/?MenuItem=tech_dhcp2).
- Иванов П. DHCP: изкуството да се управляват IP адреси. – http://www.citforum.ru/internet/tifamily/dhcp.shtml.
- Bog BOS: BOOTP/DHCP протокол – http://www.bog.pp.ru/work/bootp.html.
- RFC 2131. Протокол за динамична конфигурация на хост –http://tools.ietf.org/html/rfc2131 .
- http://www.ietf.org/rfc/rfc2136.txt.
Сред обикновените потребители никой никога не се е замислял как работи интернет. Как се случва сърфирането в световната мрежа, защо браузърите стигат точно до страниците, които поискате. Това е мястото, където DNS сървърът (система за имена на домейни) влиза в игра. Тази система е необходима, за да следва правилно маршрутите между интернет адресите, от компютъра до заявените сайтове.
Кога и защо има нужда от смяна на DNS сървъра?
По подразбиране DNS сървърът се задава от вашия интернет доставчик, но има случаи на претоварване, когато твърде много клиенти имат достъп до определена услуга. Поради това скоростта на изтегляне и прехвърляне на пакети данни може да спадне значително. Освен това някои DNS сървъри имат ограничения поради законодателството на държавата, в която работят. Случва се правителства дори да блокират глобални социални мрежи и месинджъри. В някои случаи промяната на DNS може да позволи достъп до блокирани ресурси, както и да увеличи скоростта на изтегляне на файлове и съдържание.
Принципът на работа на DNS сървъра е да насочи потребителя към правилния интернет адрес
Как да разберете адреса на регистрирания DNS сървър и как да го промените
Сега глобалната тенденция за доставчиците е автоматично да определят DNS сървъра, тоест той не е необходим първоначално. Но все още е доста лесно да го разпознаете, само с няколко кликвания на мишката.
Windows
Можете да намерите своя DNS сървър и да го промените в съответната колона на „Контролен панел“.
- Натиснете клавишната комбинация Win+R, въведете контрол в полето „Изпълнение“ и стартирайте командата с бутона OK или Enter на клавиатурата.
Стартирайте „Контролен панел“ чрез изпълнимата програма
- Променете изгледа от „Категории“ на „Икони“ и щракнете върху елемента „Център за мрежи и споделяне“.
Изберете елемента „Център за мрежи и споделяне“
- Ще се отвори прозорец с активни (активни, свързани) мрежи. Кликнете върху връзката срещу тази, която има достъп до интернет.
Разглеждаме списъка с активни мрежи в „Център за мрежи и споделяне“
- Ще се отвори прозорецът за състоянието на мрежата. Щракнете върху бутона „Подробности...“.
В прозореца „Състояние“ щракнете върху бутона „Подробности“.
- Ще се появи друг прозорец с всички данни на свързаната мрежа. В колоната „IPv4 DNS сървъри“ се запознаваме с текущите адреси на услугите, които връзката използва в момента.
Преглед на свързани DNS сървъри
Промяната на DNS сървъра също е лесна. Първо, нека се върнем към прозореца "Състояние".
В резултат на това имаме достъп до посочената услуга за преобразуване на имена на домейни.
Ubuntu
За да промените DNS настройките на операционните системи Ubuntu, можете да използвате различни методи. Най-простият е използването на интерфейса.
- В горния десен ъгъл има падащо меню за мрежа. Кликнете върху съответната икона и изберете „Промяна на връзката...“.
Отворете падащото меню на мрежата и щракнете върху „Промяна на връзката...“
- Изберете активна интернет връзка и щракнете върху „Промяна“.
Изберете интернет връзка и щракнете върху бутона „Промяна“.
- Отидете в раздела „Настройки на IPv4“.
Отидете в раздела „Настройки на IPv4“.
- Променете филтъра „Метод на конфигуриране“ на „Автоматично (DHCP, само адрес)“.
Променете филтъра „Метод на конфигуриране“ на „Автоматично (DHCP, само адрес)“
- В колоната „DNS сървъри“ въведете необходимите адреси, разделени със запетаи. След това щракнете върху бутона „Запазване“ и затворете прозореца.
В полето „DNS сървъри“ въвеждаме съответните адреси
За да разберете текущия DNS сървър в Ubuntu OS, трябва да въведете командата $ cat /etc/resolv.conf в терминала. Това ще покаже цялата информация в мрежата: колоната на сървъра на имена съдържа адреса на домейна.
На рутера
Струва си да се отбележи веднага, че не всички модели рутери ви позволяват да промените адреса на DNS сървърите в техните настройки. Някои устройства ви позволяват да ги замените с добре познати услуги, например Yandex-DNS или Google DNS.
- Първо, трябва да отидете на страницата за управление на рутера. За да направите това, въведете 192.168.1.1 в адресната лента на всеки браузър и натиснете клавиша Enter.
- В зависимост от марката на рутера, допълнителните инструкции имат опции. В някои случаи допълнителни настройки и информация може вече да са на главната страница. Но най-често трябва да натиснете определен бутон, за да отидете в придружаващото меню. Бутонът може да се нарича Разширено, Настройка, „Настройки“ и т.н. Кликнете върху този бутон, за да отидете в допълнителното меню.
- Има няколко опции за промяна на услугата:
Грешки, които могат да възникнат при използване на DNS
Рядко се случва потребителят да срещне грешки, които са свързани с DNS сървъра, но те се случват и се разделят на два вида: вътрешни и външни. Под външни имаме предвид проблеми със самата услуга, до която браузърът има достъп. Този проблем е лесен за решаване: трябва да зададете автоматичен избор на DNS или да промените услугата на по-надеждна, както е показано в примерите по-горе.
Ако промяната на методите не реши проблема, тогава проблемът е свързан с услугата „DNS клиент“. Може да е деактивиран или повреден от вируси.
Ако проблемът не изчезне след рестартиране, това означава, че сервизните файлове са повредени и трябва да стартирате системно сканиране за вируси и да възстановите OS файловете. По-добре е да използвате две или три антивирусни програми.
Видео: Как да коригирате грешки на DNS сървъра
Промяната на DNS сървъра е лесна. Ако е необходимо, можете лесно да възстановите скоростта на любимите си сайтове. Следвайте инструкциите по-горе и няма да имате никакви проблеми при сърфиране в Интернет.
Понякога е необходимо да регистрирате DNS за компютър с динамичен IP адрес. Лесен начин за това са услуги като dyndns, описани в скорошната тема Свързване на домейн и динамичен IP. Понякога този подход работи доста слабо.
Например, в моята ситуация, доставчикът Понякогапроменя моя публичен IP адрес. Това понякога се случва обикновено веднъж на няколко месеца. Освен това домашният ми компютър рядко се рестартира. През това време услугата dyndns, която преди това използвах, успя да ми изпрати няколко известия за неактивност, за да деактивира „неизползвания“ акаунт. Също така не е възможно да преминете към ръчно регистрирана DNS зона, защото понякога адресът все още се променя. Освен това обикновено разбирате за това, когато имате нужда от достъп до домашния си компютър тук и сега.
За да приложите описания метод, ще ви е необходим сървър в Интернет с обвързване на DNS сървър. Както и домейн зона, чийто поддомейн ще разпределим за нашия компютър. Описана е опция за свързване на Linux компютър към Linux сървър. За да използвате други операционни системи, ще трябва да прочетете ръководствата и да промените някои стъпки.
Така:
1. Имаме инсталиран bind9 сървър с домейн server.org
2. Създайте зона client.server.org.zone:
$ ПРОИЗХОД.
$TTL 10; 10 секунди
client.server.net В SOA ns1.server.net. hostmaster.server.net. (
18; сериен
10800; опресняване (3 часа)
3600; повтори (1 час)
604800; изтича (1 седмица)
10; минимум (10 секунди)
$TTL 3600; Един час
NS ns1.server.net.
NS ns2.server.net.
MX 10 client.server.net.
Тук сървърите ns1.server.net и ns2.server.net са DNS сървърите за нашата зона, client.server.net е адреса на домашния ни компютър
3. генерирайте ключове на клиента:
клиент # cd /etc/namedb/keys
клиент# dnssec-keygen -b 512 -a HMAC-MD5 -v 2 -n ХОСТ client.server.net.
4. Създайте файл с ключа на сървъра:
сървър# cd /var/named/chroot/и т.н
сървър # vim keys.conf:
Ключ client.server.net. (
алгоритъм "HMAC-MD5";
тайна "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f+uIIxxei8qm7AVgNBprxtcU+FQMzBvU/Y+nyM2xbs/C8kF3eJQUA==";
};
В този случай се използва симетричен ключ, който не е безопасен: ако някой има достъп до ключовия файл на вашия сървър, той може да използва вашия ключ, за да промени данните за вашата зона. В този случай можете да използвате асиметричен ключ.
Задайте правата за достъп до файла с ключовете:
сървър # chmod 640 keys.conf
server# chown root:named keys.conf
5. добавете нашата зона към named.conf:
включва "/etc/keys.conf"
зона "client.server.net" (
тип майстор;
файл "zones/client.server.net";
позволи актуализация(
ключ client.server.net;
};
};
Ето параметър, който ви позволява да актуализирате данните за зоната. Като цяло, след като прочетете ръководствата, можете да намерите опции за този параметър, които ви позволяват да актуализирате само един запис в зоната за даден ключ. Тоест, можете да имате зона с регистрирани в нея поддомейни client1, client2 и т.н. който ще бъде разрешен с ключовете key1, key2 и т.н.
6. Рестартирайте DNS сървъра:
сървър # /etc/init.d/named презареждане
7. Създайте скрипт на клиента, който ще актуализира данните за зоната:
#!/bin/bash
IFACE="wlan0"
TTL=3600
СЪРВЪР=ns1.example.com
HOSTNAME=foo.example.com
ZONE=example.com
KEYFILE=/root/ddns-keys/Kfoo.example.com.+157+12345.private
New_ip_address=`ifconfig $IFACE | grep "inet адрес:" | awk "(печат $2)" | awk -F ":" "(печат $2)"`
new_ip_address=$(нов_ip_адрес/ /)
Nsupdate -v -k $KEYFILE<< EOF
сървър $ СЪРВЪР
зона $ZONE
актуализиране изтриване на $HOSTNAME A
актуализирайте добавете $HOSTNAME $TTL A $new_ip_address
изпрати
EOF
В началото на скрипта са описани съответните параметри: интерфейс, имена на сървъри и зони, местоположение на файла с ключа.
8. Остава само да конфигурирате автоматично стартиране/автоматична промяна на адреса при смяна на DNS.
Ще направим това с помощта на скрипт за NetworkManager:
създайте файл /etc/NetworkManager/dispatcher.d/20-dyndns.sh:
#!/bin/sh
Iface=$1
състояние=$2
If [ "x$state" == "xup" ] ; тогава
/etc/namedb/ddns-update
elif [ "x$state" == "xdown" ]; тогава
вярно
фи
Нека го направим изпълним и собственост на root потребителя.
Нека стартираме, проверим, използваме.
Upd: Ако не работи, проверете (задайте) на сървъра правата на named да записва в папката, в която се намира файлът client.server.org.zone
named ще създаде файл client.server.org.zone.jnl там
Използвани са следните материали.
http://www.dyndns.com/.Всичко най-много необходими елементипрез които трябва да преминете (щракнете или попълнете) ще бъдат отбелязани с червена рамкаи са дадени обяснения.
Така като отидете на dyndns.comтогава виждаме началната картина Ако вече сте били тук и в бъдеще след регистрация, щракнете върху Вход (Вход). Сега щракнете върху Вземете БЕЗПЛАТНО име на домейн
Изберете 1-вата безплатна опцияи щракнете върху Регистрация
1. Въведете име за вашия поддомейн(ето пример за teamspeak3) и изберете домейн от списъка с възможни, което предпочитате.
2. Въведете текущия ip адрес на вашия компютърили сървър, ако извършвате тази операция директно от него, тогава можете да щракнете върху връзката IP адресът на вашето текущо местоположение е(текущият ви IP адрес) и самата система ще го замени в полето IP адрес.
3. Кликнете върху Добавяне в количката
Грешки:
Моля, въведете валиден IP адрес (Забравих да въведа вашия IP)
Това име на хост вече съществува (този поддомейн вече е зает)
Още веднъж проверяваме името на вашия домейн и цената е само $0 за тази услуга, а след това попълнете директно регистрационните данни.
1. Потребителско име (Измислете и запомнете потребителско име за тази услуга)
2. Парола (Създайте и запомнете парола)
3. Потвърдете паролата (Въведете паролата си отново)
4. Имейл (Въведете служебния си имейл адрес, на него ще бъде изпратено потвърждение за регистрация)
5. Потвърдете имейл (Въведете имейл адреса си отново)
6. Въведете номера от горното изображение(Въведете числата от картинката)
7. Съгласен съм (Не забравяйте да поставите отметка в квадратчето, че сте съгласни с условията на услугата, не е необходимо да поставяте отметки в другите квадратчета)
След това щракнете върху Създаване на акаунт
Сега щракнете върху Моите хостове (Моите домейни), за преглед и активираненашият създаден поддомейн.
Кликнете върху Плащане, за да активиратеза активиране на домейна
Цялата процедура струва 0 USD, просто щракнете върху Напред(по-нататък)
Всичко, което остава, е да щракнете върху Активиране на услуги(Активиране на услуги), за да завършите активирането на вашия домейн.
Сега получаваме съобщение за успешно активиране, остава малко: научете как да видите списъка с вашите домейни и изтегляне на програма за компютър(Сървър), който автоматично ще уведоми сървъра за промяна на IP адреса.
