Край на debian-volatile

Владимир | 02/16/2011

Е от вчера вече официално няма debian volatile хранилища (но пък вече има squeeze-updates). Ще кажете какво по дяволите е това … ами това са хранилища за пакети в които влиза често обновяван софтуер. От сорта на tzdata, clamav и други дреболии.

Официалното съобщение: http://www.debian.org/News/2011/20110215

Приниципно аз карам на stable (а не на codename-а (squeeze)) и това ми докара малко бели на главата в процеса на ъпгрейд. Но за това друг път.

Коментари
Няма коментари »
Категории
Разни
Tags
, ,
RSS коментари RSS коментари
Trackback Trackback

To cache or not to cache … that’s a stupid question

Владимир | 02/09/2011

След едно случайно заиграване покрай http://neo2shyalien.eu/2011/01/28/eaccelerator.html и великият facepalm момент си поставих задачката аджеба да видим колко производителност се печели от използването на Opcode Caching при PHP.

Речено сторено.

По долу ще откриете до какви резултати се стигна.
Прочети останалата част от поста »

Коментари
11 Коментара »
Категории
Статии
Tags
, , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

Multiple courier-imap-ssl instances on single machine

Владимир | 10/25/2010

Днес ще покажем как да си сглобим сървър за поща на който ще работят няколко инстанции на Courier. Интересното в случая ще е че на всяка от инстанциите ще има различен SSL сертификат. По този начин на една реална физическа машина ще хостваме няколко напълно легитимни мейл сървъра със техните си отделни сертификати.

Процедурата е пределно проста.
Първо трябва да си инсталираме необходимият софтуер. Аз лично съм привърженик на Debian и него си слагам

apt-get install postfix courier-imap-ssl sasl2-bin libsasl2-modules courier-pop-ssl ca-certificates

Е postfix-a не ни е нужен точно за това изпълнение но помага да го имаме. При изпълняването на горната команда ще бъдат инсталирани няколко допълнителни пакета включително courier-authlib.
След като приключи инсталацията трябва да спрем стартирането на цялата система courier с изключение на демона за аутентификация. Той ще остане единственото недублирано нещо.
Да приемем че имаме следният набор от мрежови настройки:

IP1: 10.199.199.201
IP2: 10.199.199.202
Mask: 255.255.255.0

Да осъзнавам факта че това не са публични адреси но ако не можете да си смените два адреса на няколко места … не знам защо изобщо четете това.
Следващата ни стъпка е да направим по две копия на конфигурациите на courier и стртиращите скриптове. В крайна сметка получаваме следна структура:

/etc/
/etc/courier/
/etc/courier-201/
/etc/courier-202/
/etc/init.d/courier-imap
/etc/init.d/courier-imap-201
/etc/init.d/courier-imap-202
/etc/init.d/courier-imap-ssl
/etc/init.d/courier-imap-ssl-201
/etc/init.d/courier-imap-ssl-202
/etc/init.d/courier-pop
/etc/init.d/courier-pop-201
/etc/init.d/courier-pop-202
/etc/init.d/courier-pop-ssl
/etc/init.d/courier-pop-ssl-201
/etc/init.d/courier-pop-ssl-202

Както се вижда структурата сме организирали по последният октет на IP адреса на който ще закачим инстанцията на куриер-а.

Следващата стъпка е да редактираме скриптовете за стартиране да сочат към правилната директория с конфигурации. Тоест трябва да редактираме всеки един от скриптовете с имена *-201, *-202 и да променим стойността на sysconfdir. По подразбиране тя е /etc/courier а трябва да стане съответно /etc/courier-201 и /etc/courier-202.

След като вече сме насочили скриптовете за стартиране към правилните директории е време да променим самите конфигурации. Поради факта че искаме да използваме SSL се налага всяка инстанция да е на отделен адрес. И понеже така и така имаме няколко адреса нека да преместим и неподсигурените връзки на същите адреси.

В конфигурационните файлове трябва да се променят следните опции

ADDRESS – от 0 да стане на конкретният IP адрес който сме заплюли (201,202)
SSLADDRESS – същото като по горе
PIDFILE – към зададеният път да добавим последният октет. Т.е. от imapd.pid да стане imapd-201.pid
SSLPIDFILE – аналогично на горното
TLSCERTFILE – дали ще е самоподписан или ще си е нормален това е ваш избор.

Е остана само да включите новосъздадените ни скриптове за стартиране да стартират при стартиране на машина да рестартирате и да тествате. Ако сте направили всичко вече си имате два напълно отделени пощенски сървъра изградени с Courier.

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , ,
RSS коментари RSS коментари
Trackback Trackback

Backup with rsnapshot and ssh

Владимир | 10/22/2010

Disclaimer: Описаните техники в този документ могат да ви помогнат но не е задължително да са напълно вярни и изчерпателни. Не поемам отговорност за каквито и да било реални или нереални, вреди, ползи, пропуски, паднали къщи или каквото и да е произтичащи от ползването или неползването на този документ.
История

  • 08.11.2007 – Първа версия

Мотивация
По темата за архивирането на данни има няколко мнения и всички те са вярни в определена степен и светлина. Най често споменаваните са:

  • Архивирайте често и редовно
  • Архивирайте когато е нужно и имайте свестен план за възстановяване
  • Real men don’t do backups! They let the internet mirror it!

Е за радост или съжаление аз съм от хората които са по първият начин. Държа данните ми да са на сигурно място. И за целта трябва да имам стратегия. Днес ще ви разкажа как този сайт се архивира. Какво се използва и как е навързано.
Трябва да се отбележи че системата не е от най-добрите но е достатъчно добра че да работи и да не ми създава проблеми.
Цел
Целта ни днес е да реализираме напълно автоматизирана система за архивиране на данните. Допълнителни цели са скорост, минимален обем на прехвърляните данни, лесно възстановяване на данните от архива, сигурност.
Съставките
Като цяло нищо странно или екзотично. Дебиан базирана система (и хостът и машината която архивира), rsnapshot, ssh, rsync, diff, cp, du, perl.
Основата на системата се върти около rsync, rsnapshot е обвивка която предлага доста възможности но всичко е постижимо с нормален rsync. Допълнително са ни необходими cron и известно количество познания за начина на работа и методите за сигурност около SSH.
Най-голямо внимание трябва да се обърне на подсигуряването на системата, тоест настройката на ssh
Настройване на rsnapshot
Това като цяло е най-лесната част от цялото занимание. Избрал съм rsnapshot поради факта че информацията се предава посредством rsync тоест само разликите, използва схема за ротиране на архивните копия и може би едно от най-важните неща – използва твърди връзки между непроменените файлове от различните стартове на архивирането и по този начин пести място.
След инсталацията му трябва да се редактира конфигурационният му файл в който трябва да се дефинират времеви периоди (не са точно времеви, но за това след малко), точки за архивиране и някои команди.
/etc/rsnapshot.conf

# дефинираме къде ще съхраняваме архивите
snapshot_root   /home/webbackup/
# дефиниране на някои команди които ще са ни необходими
cmd_cp          /bin/cp
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
# за съжаление тук не могат да се добавят допълнителни опции
cmd_ssh         /usr/bin/ssh
cmd_logger      /usr/bin/logger
cmd_du          /usr/bin/du
cmd_rsnapshot_diff      /usr/bin/rsnapshot-diff
# дефинираме си период (по-точно име и брой архиви)
interval        whgeto  10
# малко логове и т.н.
verbose         2
loglevel        3
logfile         /var/log/rsnapshot.log
lockfile        /var/run/rsnapshot.pid
# някои от данните не искаме да ги синхронизираме
exclude log/*
exclude phptmp/*
# и най накрая точките които ще архивираме
backup  root @ getoto.net:/var/www/       getoto.net/web/
backup  root @ getoto.net:/var/lib/mysql/ getoto.net/sql/

След като вече сме дефинирали какво и как да архивираме е време да си настроим периодична задачка която реално извършва архивирането. Това се постига чрез добавяне на запис в системата на cron.

0 */6   * * *   webbackup    /usr/bin/rsnapshot whgeto

Това се превежда като … на всеки 6 часа изпълнявай като потребител webbackup командата …
С това настройката на rsnapshot завършва. Но сега следва да си подсигурим достъпа до машината и да го ограничим до използването само на строго определени команди.

Настройване на SSH
След като системата ни е настроена да извършва регулярно архивиране на нашите данни е време да подсигурим достъпа. Искаме да получим следната ситуация. Вход без парола (с ключ), възможен само от определен адрес, който да може да изпълнява само строго определени команди.

Цялото това нещо се постига по следният начин:

  • Генериране на ключ който ще се използва за операциите – самият ключ е без парола. Избираме ключа да не е особенно голям за да пестим време, а и освен това ще е бъде доста ограничен. 
    ssh-keygen -t rsa -b 1024 -f ~/keys/backup && chmod 600 ~/keys/backup

    По този начин в папка ~/keys ще си генерираме РСА ключ с големина 1024 байта и ще променим правата му така че само ние да можем да го четем и променяме. Последната стъпка е много важна тъй като ако правата не са коректни ключа няма да бъде използван.

  • Добавяме публичната част от ключа в списъка с упълномощените ключове на машината която ще архивираме. Напълно достатъчно е публичната част от ключа да бъде копирана във файла /root/.ssh/authorized_keys
  • Влизаме един път със този ключ в целевият сървър (машина която ще архивираме). Целта на това е ръчно да приемем подписа на целевата машина като валиден. Ако тази стъпка се пропусне цялата операция по архивирането ще пропадне.
  • Редактираме файлът ~/.ssh/config – това е файл в който могат да се конфигурират множество аспекти на поведението на клиенат ssh на базата на това с кой хост се опитваме да се свържем. В моят случай файлът е със следното съдържание: 
    # За кой хост говорим
Host getoto.net
  # ще използваме само IPv4 (v6 не поддържаме)
  AddressFamily inet
  # ще използваме пакетен режим (неинтерактивен)
  BatchMode yes
  # ще използваме този файл за ключ
  IdentityFile /home/webbackup/keys/backup
  # и изискваме задължително версия 2
  Protocol 2

    По този начин принуждаваме ssh клиента да използва нашият ключ (специално създаден) когато се свързва към машината.
    С това приключва конфигурацията на хоста който извършва архивирането.

  • Редактиране на файлът /root/.ssh/authorized_keys – тук се извършва ограничаването на възможностите на нашият ключ. В този файл ще ограничим ключът ни за архивиране да може да се използва от едно място и да може да изпълнява само определени команди.
    /root/.ssh/authorized_keys

    command="/root/.ssh/authprogs.pl",from="11.22.33.44" ssh-rsa AAAAB3NzaC1 ...

    По този начин ограничаваме ключът да може да се използва само от машина с адрес 11.22.33.44 и единствената команда която може да изпълни (без да може да изпълни нещо друго) е /root/.ssh/authprogs.pl
    Програмата authprogs.pl е скрипт взет от http://www.hackinglinuxexposed.com/. Неговата цел е да предостави възможност за изпълняване на няколко различни команди. Причината е че чрез възможностите на ssh можем да зададем само една задължителна команда.
    Самият срипт има нужда от прост конфигурационен файл

    # хост
[11.22.33.44]
# команди които може да изпълнява
# Backups
rsync --server --sender -logDtprR --numeric-ids . /var/www
rsync --server --sender -logDtprR --numeric-ids . /var/lib/mysql

    По този начин ефективно прескочихме ограниченията на ssh

  • Тестване – пуснете ръчно rsnapshot с интервала който сме си дефинирали. Ще повиси малко и в последствие ще имате вече архиви в точката която сте дефинирали като архивна. 
    garota:~# ls -l /home/webbackup/
drwxr-xr-x 3 1005 1005 4096 2007-11-08 12:00 whgeto.0
drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:39 whgeto.1
drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:07 whgeto.2
garota:~# ls -l /home/webbackup/whgeto.1
drwxr-xr-x 4 1005 1005 4096 2007-11-08 11:36 getoto.net
garota:~# ls -l /home/webbackup/whgeto.1/getoto.net/
drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:36 sql
drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:10 web

Заключение
Е надявам се това да ви е помогнало поне малко. Вече би трябвало да имате изградена система за напълно автоматизиран и подсигурен бекъп. Поне на мен ми върши добра работа.

Полезни Връзки

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

Трикове с rsync или иначе казано какво ми стана с мирора

Владимир | 06/11/2010

Познайте каква е грешката когато синквате мирор на нещо да ползвате следното нещо

/usr/bin/rsync -avuC –delay-updates –delete –delete-after –timeout=300

За позналия дъвка с косъм :)

Също така приемам предложения какви точно опции да набода на rsync-а

Коментари
1 Коментар »
Категории
Разни
Tags
, , ,
RSS коментари RSS коментари
Trackback Trackback

DHCP + TFTP + PXELINUX = Netinstall

Владимир | 12/06/2009

Disclaimer: Описаните техники в този документ могат да ви помогнат но не е задължително да са напълно вярни и изчерпателни. Не поемам отговорност за каквито и да било реални или нереални, вреди, ползи, пропуски, паднали къщи или каквото и да е произтичащи от ползването или неползването на този документ.

Мотивация
Преди около седмица в Linux-BG се появи молба за помощ, за един леко прецакан windows. Ситуацията беше, че MBR на системата беше заминал по дяволите, а машината нямаше нито CD, нито флопи, нито пък можеше да стартира от USB. Остава като решение само стартиране от мрежа. Помогнахме му на човека понеже си имам инсталиран такъв сървър в къщи. Тази комбинация от софтуер е полезна и при други ситуации (основно мързел) като инсталация на отдалечени машини, тестове, и някои други добрини.

Цел
Да получим сървър от който да може да се стартира инсталация на операционна система.
Ще демонстрираме как се прави това с Debian, а за други дистрибуции е аналогично.

Необходими компоненти

  • Инсталирана и работеща линукс система която ще ползваме за PXE сървър
  • DHCP сървър – тук ще опишем настройката му
  • TFTP сървър
  • PXELINUX – от syslinux системата
  • Интернет свързаност или локално копие на необходимите пакети за инсталация
  • Желание за работа и малко трезва мисъл

Изхождаме от презумпцията че цялото това нещо ще го реализирате в мрежа която е отделена от основната ви, тъй като едно дребно недоглеждане може да направи много поразии. Ще се постарая да ви спестя проблемите но никога не се знае.

Теория на работата
Доста машини могат да стартират през мрежа, било то за да работят като терминали или по други съображения. За целта мрежовата им карта трябва да поддържа PXE стандарта за предпочитане над версия 0.91. Макар че може да бъде излъгана и с по-ниски версии.
Самият процес протича доста елементарно и като цяло е доста прост:

  • Машината стартира и се инициализира биос подсистемата
  • Инициализира се PXE подсистемата на мрежовата карта
  • Мрежовата карта изпраща заявка за IP адрес
  • DHCP сървъра отговаря като в допълнение и предлага да стартира от мрежа и я насочва към следващия сървър (TFTP)
  • TFTP сървъра предоставя на мрежовия стек малък файл който играе ролята на boot мениджър
  • От този мениджър си избираме една от опциите и стартираме

За повече информация по темата:

Настройка на DHCP сървър
Настройката не е нищо особенно има я подробно описана в документацията на sysllinux/pxelinux. Единственото което ни е необходимо в допълнение към нормален dhcp сървър са две допълнителни опции които ще обясним нагледно с пример.

/etc/dhcpd.conf

#
# Sample configuration file for ISC dhcpd for Debian
#
# $Id: dhcpd.conf,v 1.4.2.2 2002/07/10 03:50:33 peloy Exp $
#

# Задължително или няма да може да раздаваме адреси при нормална работа
authoritative;

# Да ще позволяваме стартирането на стари клиенти (идва от BOOTP протокола)
allow bootp;
# Да ще позволяваме стартирането на клиенти посредством PXE
allow booting;
# нашият следващ сървър от където ще си дръпнем boot loader
next-server 10.99.3.1;
# Как се казва нашият boot loader
filename "pxelinux.0";

default-lease-time 14400;
max-lease-time 86400;

# стандартна конфигурация на dhcp сървър
subnet 10.99.3.0 netmask 255.255.255.0 {
  range 10.99.3.10 10.99.3.200;
  option domain-name-servers 10.99.3.1;
  option domain-name "instalations.network";
  option routers 10.99.3.1;
  option subnet-mask 255.255.255.0;
  option broadcast-address 10.99.3.255;
  option default-ip-ttl 64;
  option default-tcp-ttl 64;
  option time-offset 7200;
  option time-servers 10.99.3.1;
  option ntp-servers 10.99.3.1;
  option netbios-name-servers 10.99.3.1;
  option netbios-node-type 8;
}

Ако нещо не ви е ясно ви съветвам да се обърнете към помощните страници на пакета dhcp

Настройка на TFTP сървър
За тфтп сървър ще използваме tftp hpa работещ в режим на демон.
той се инсталира пределно просто (при debian)

apt-get install tftpd-hpa

Конфигурацията му се намира в /etc/default/tftpd-hpa и е следната:

# ще работим като демон
RUN_DAEMON="yes"
# опциите са
# -l - работим в режим на демон
# -v - записваме подробна информация
# -s - работим в сигурен режим като сервираме само от тази директория
OPTIONS="-l -v -s /tftpboot"

Все още не стартирайте сървъра. Препоръчва се файловете както и директорията /tftpboot да са собственост на root и да са само за четене (от всички)

Настройки на PXELINUX
PXELINUX се намира в серята програми наречена syslinux. Не е необходимо да инсталирате целия пакет тъй като от него ще ползваме само pxelinux.0 и евентуално memdisk ако искате да стартирате дос

Конфигурацията му е до някъде сложна но ще се постарая да я обясня като хората. Самият pxelinux се конфигурира от един текстов файл който указва какво и с какви настройки да бъде стартирано. Също така поддържа възможност различните машини да получават различна конфигурация. Документацията в пакета syslinux е много добра макар и длъжка така че наистина я прочетете поне диагонално.
Нашата инсталация на pxeilinux ще живее в директорията /tftpboot и има следната структура:

/tftpboot/
/tftpboot/initrd/
/tftpboot/kernels/
/tftpboot/pxelinux.0
/tftpboot/pxelinux.cfg/
# нашата конфигурация
/tftpboot/pxelinux.cfg/default
/tftpboot/texts/

В случая ще демонстрираме една единствена конфигурация за всички машини. За разнообразни конфигурации моля погледнете в документацията. Следва и примерната конфигурация:
/tftpboot/pxelinux.cfg/default

# по подразбиране стартираме от локален диск
# прави се за да не стане гаф и да унищожим информация
default local
# закъснение при стартиране (5 секунди)
timeout 50
# да покажем ли промпт
prompt 1
# да покажем определен текст
display texts/menu.txt

label local
        localboot 0

# етикет за този кернел
label deb26n
# самият кернел
        kernel kernels/deb-testing-26.kernel
# допълнителни опции
        append initrd=initrd/deb-testing-26.initrd \
           vga=normal \
           ramdisk_size=16384 \
           root=/dev/rd/0 \
           devfs=mount,dall rw

label deb26e
        kernel kernels/deb-testing-26.kernel
        append initrd=initrd/deb-testing-26.initrd \
           DEBCONF_PRIORITY=low \
           vga=normal \
           ramdisk_size=16384 \
           root=/dev/rd/0 \
           devfs=mount,dall rw

Забележка: редовете append са разпределени на няколко реда от съображения за четимост, но в конфигурацията трябва да са на един ред.

Кернелът и initrd файла са взети от проекта дебиан и по точно от секцията му нетбоот. Добавени са с лека адаптация и допипване на командния ред

Заключение
Като цяло това е всичко. Не е особенно трудно да се постигне. Евентуален проблем който може да срещнете е че PXE агента на мрежовата карта е малко стар и не иска да работи с tftp сървър а задължително изисква pxe сървър, но това е лесно решимо.
За тези които искат готово решение без много много да си играят ето пакетирано всичко необходимо. Необходимо е само да имате инсталиран dhcp и tftp сървър.

Очаквам въпроси, коментари, предложения и каквото ви хрумне в коментарите.

Коментари
1 Коментар »
Категории
Статии
Tags
, , , , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

The Perfect SOHO router – Part 6

Владимир | 12/06/2009

Това е шестата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

След като вече имаме работещ рутер, който си филтрира и си има някакви дребни статистики може да се замислим за разни удобства и евентуално да му дадем допълнителни задачи.

Тъй като има изгледи тази статия да стане най-голямата и да се пише доста време, ще трябва да кликнете на линка прочети повече. Ще се радвам ако и вие споделите вашите малки номера и трикове.
Първото удобство с което ще разширим нашият рутер това е прокси. Освен простото прокси ще го направим и прозрачно за да можем да избегнем конфигурирането му на всяка машина. Трябва да се отбележи че има и автоматични методи за конфигуриране на прокси сървъри но те не са от най-удобните или пък безпроблемните.

Защо ни трябва прокси
Прокси сървърът представлява система която кешира заявки. Тоеск ако клиент А изиска файл file.html нашият сървър ще съхрани за определено време отговорът в своят кеш и при последваща заявка за този файл от друг клиент Б файлът ще бъде подаден от кеша, а не от интернет. По този начин постигаме спестяване на трафик, ускоряване, контрол. С малко повече труд може да се реализира антивирус, антиспам, филтрация на реклами, контрол на трафика и др. Най-популярното решение за прокси сървър е squid.

Проста конфигурация на squid
Ще дадем една много елементарна конфигурация при която всичко работи, но няма никакви защити от към използване. Конфигурацията е без коментарите от файла поради причината че целият файл е около 40К.

# на кой порт да слушаме и дали да ауторизираме (не)
http_port 9999 no-connection-auth
# на кой порт да си говорим с други проксита (няма да си говорим)
icp_port 0
# ако някой от тези стрингове се среща в URL - не кеширай
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
# workaround за буг в апачето
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
# максимална големина на обект в рам областта
maximum_object_size_in_memory 48 KB
# колко рам да заделим за кеширане
cache_mem 24 MB
# директория за кеш файлове (прочетете конфигурацията във файла, много полезна е)
cache_dir aufs /var/spool/squid 500 16 256
# логовете ...
access_log /var/log/squid/access.log squid
# малко анонимизация ... максимална всъщност)
client_netmask 0.0.0.0
# юзер за ftp сесии
ftp_user IEUser@
hosts_file /etc/hosts
# стандартни параметри за проверка по някои протоколи
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern .               0       20%     4320
# малко ACL-и. Почти всички са стандартни
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443          # https
acl SSL_ports port 563          # snews
acl SSL_ports port 873          # rsync
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 631         # cups
acl Safe_ports port 873         # rsync
acl Safe_ports port 901         # SWAT
acl Jabber_ports port 5222 5223	#Jabber
acl purge method PURGE
acl CONNECT method CONNECT
# това вече сме ние
acl clientnetwork src 10.42.3.0/255.255.255.0
# след като имаме ACL-и време е да почнем да раздаваме достъп
http_access allow manager localhost
http_access allow manager home
http_access deny manager
http_access allow purge localhost
http_access allow CONNECT Jabber_ports
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# ДАААА пуснахме го :)
http_access allow clientnetwork
http_access allow localhost
# Всичко което не е разрешено ... под ножа
http_access deny all
http_reply_access allow all
icp_access allow all
cache_mgr root
cache_effective_group proxy
# нека да скрием версията при грешки
httpd_suppress_version_string on
# и да не издаваме че има прокси по пътя
via off
forwarded_for off
cachemgr_passwd parola all
buffered_logs on
short_icon_urls on
coredump_dir /var/spool/squid
# нека да се опитаме да сме умни и да вземаме по няколко странички на куп
pipeline_prefetch on

Както се вижда това отново е една много проста конфигурация, която се различава съвсем малко от стандартната. Променили сме стандартният порт на който слуша сървърът ни, добавили сме настройка за in-memory кешът, увеличили сме малко дисковият кеш и сме скрили малко факта че има прокси. Сега остава да го направим сървърът ни прозрачен. Тоест да няма нужда клиентите да се настройват. Това се постига посредством пренасочване на изходящите заявки към определен порт. Да предположим че искаме да пренасочваме целият http трафик но не и https трафика и ftp трафика. Като допълнителен бонус знаем че част от клиентите посещават сайтове които не са на 80ти порт ами на 81,88,8800,8080. Също така доста сайтове предпочитат да имат два web сървъра, първият на порт 80 който сервира страниците и втори обикновенно на порт 81 който сервира картинки само.
Цялата задача се реализира по следният начин (използваме конвенциите от Четвърта част)

$IPT -t nat -A PREROUTING -i $INT_IF -m multiport --dports 21,80,81,88,8800,8080 -j REDIRECT --to-port 9999

Съответно порт 9999 е отворен поне за вътрешният интерфейс.

Темата с delay_pools също е интересна тъй като с нея може да се реализира прост шейпър. И за всеобща радост е много добре обяснена в конфигурационният файл.

Просто ограничаване на трафик
Понякога клиентите на рутера са малко нагли и теглят ужасно много. Ако нямаме познанията или желанието да реализираме някакъв вид шейпър, можем да направим временно решение посредством iptables. Решението се базира на идеята че ако линията е претоварена мрежовият стек се опитва да намали трафика. Обикновенно претоварена линия се открива когато започнат да се губят пакети. И за да изглежда реално пакетите трябва да се губят що годе случайно. Това се постига посредством модула към iptables RANDOM. Този модул е в patch-o-matic-ng base. Правилото изглежда по следният начин.

$IPT -t nat -A FORWARD -i $INT_IF -s < client_IP > -m RANDOM --average 5% -j DROP

Методът изобщо не е красив и понякога само натоварва допълнително линията. Ако ползваме голям процент обаче (над 30%) обикновенно клиентите се усещат и просто си спират свалящите се работи.

Малко по-подробни статистики
Ако статистиките от mrtg не са ви достатъчни може да използвате ipaudit-web. Като цяло е доста добър софтуер, вади прилични статистики, но за съжаление е малко натоварващ.

За момента това са работите за които се сещам. Всеки който иска нека публикува и своите дребни трикове в коментарите. Ще се постарая да ги интегрирам.

Сървър за точно време
Това е едно удобство за клиентската мрежа което може да осигури стабилност на определен тип приложния. Най-вече тези които зависят от точното врем. Освен тях от точно време може да се възползва всеки който иска. Сървърът се реализира посредством пакета ntpd и конфигурацията му е доста семпла и проста

# /etc/ntp.conf, configuration for ntpd
# къде да пазим нашето отместване. Специфична настройка необходима за работа на сървъра
driftfile /var/lib/ntp/ntp.drift
# къде да съхраняваме статистиките
statsdir /var/log/ntp
# какви статистики искаме и точно с какви опции
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to more than 300 low-stratum NTP servers.
# Your server will pick a different set every time it starts up.
#  *** Please consider joining the pool! ***
#  *** <http ://www.pool.ntp.org/join.html> ***
# да научим нашият сървър къде да пита за точно време
server 0.bg.pool.ntp.org iburst
server 1.bg.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server pool.ntp.org iburst

Както виждате настройката е пределно проста. Единственото което си струва да се отбележи е че обявяваме времето на всеослушание. Никой не гарантира че то ще бъде използвано, но нека да го има. Ако имаме желание може да уведомим нашите клиенти къде могат да открият нашият сървър за време посредством следните редове в конфигурацията на нашият dhcp сървър (dhcpd):

option time-servers 10.99.3.1;
option ntp-servers 10.99.3.1;

Трябва също така да се отбележи че за да работи тази услуга, портът на който работи да бъде отворен. Препоръчително е това да стане само за вътрешният интерфес. Портът за който иде реч е 123.

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , , , , , , , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

The Perfect SOHO router – Part 5

Владимир | 12/06/2009

Това е петата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

В тази част ще изградим една много проста система за наблюдение и диагностика на нашият рутер.
Защо
За да знаем какво се случва с нашият рутер. Винаги е полезно да знаем в какво състояние е нашият рутер и то да можем да достигнем до тази информация бързо.

Какво ще има
Личното ми предложение за елементарна система е както следва:

  • Web базирана – за лесен достъп от всякъде
  • Проверка на състоянието на интернет свързаността – за да може с един поглед да се каже дали имаме връзка и дали проблема е някъде при нашият доставчик
  • Проверка на състоянието на мрежовите карти – дали са включени, да не би кабелчето да е избягало и т.н.
  • Проверка на използването на паметта – да не би случайно да сме влезнали в swap зоната и харда да траши
  • Проверка броя активни сесии – за да видим до къде е стигнало използването
  • Трафик статистика с помощта на mrtg
  • Пълна системна информация от phpsysinfo

Скрипт за проверка на състоянието на интернет свързаността
Това е един много прост скрипт който ще се опита да направи няколко пинг-а до определен адрес който сме сигурни че е винаги на линия. Използваме ип адрес а не име за да избегнем проблема с пропаднал DNS.
За да работи коректно този скрипт е необходимо да имаме ping, tail, cut, php

<?php
// simple checking of connectivity
// vvitkov
// 02.11.2006
?>
<html>
<head>
<title>Connection check</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
</link></head>
<body>
<?php include "header.php"; ?>
<center><br /><br /><h2>Checking Conection with
<?php
$target="194.145.63.12";
if (isset($_REQUEST['t'])){
        $target=$_REQUEST['t'];
}
echo "<font color=#000000>" . $target . "</h2><br /><br />";
$OK="<div class=ok>CONNECTION IS UP</div>";
$NO="<div class=no>CONNECTION DOWN</div>";

$status=exec("ping -q -c3 $target | tail -n 1 | cut -d' ' -f1");

if ($status == "rtt") { echo $OK; } else { echo $NO; }
?>
<br /><br />
<div class=sub><a href="?t=www.abv.bg">Check with abv.bg</a>&nbsp;<a href="?t=www.google.com">Check with Google</a></div>

<?php include "footer.php"; ?></center>

Самият скрипт изобщо не е красив а да не говорим и че не е много сигурен но върши работа. Ето примерен изглед на успешна и неуспешна проверка.
pingcheck-ok
pingcheck-no
както забелязвате ако подадем хост който не съществува за проверка ще ни върне отговор че нямаме интернет, което може да не е вярно. Поради тази причина освен проверка с ip са сложени два популярни сайта които се очаква че са винаги на линия.

Скрипт за проверка на състоянието на мрежовите карти
Идеята на този скрипт е да установи дали имаме физическа свързаност. Не винаги е полезен но върши работа.
За да работи скрипта имаме нужда от sudo, mii-tool.

<?php
// simple checking of network cards
// vvitkov
// 02.11.2006
?>
<html>
<head>
<title>NIC check</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
</link></head>
<body>
<?php include "header.php"; ?>
<center><br /><br /><h2>Checking Network Cards</h2><br />
<?php
$status=exec("sudo /sbin/mii-tool eth0 | md5sum | cut -d' ' -f1");
if ($status === '011d899f145c89793888771019335049'){
        echo "<div class=ok>External network is UP";
} else {
        echo "<div class=no>External network is DOWN<br />Please check Cable (eth0)</div>";
}
$status=exec("sudo /sbin/mii-tool eth1 | md5sum | cut -d' ' -f1");
if ($status === 'e413ff927a35f4df4c8bdecd70111902'){
        echo "<div class=ok>Internal network is UP</div>";
} else {
        echo "<div class=no>Internal network is DOWN<br />Please check Cable (eth1)</div>";
}
?>
</center>

<?php include "footer.php"; ?>

Проверката на картите не е универсална поради използваните md5 суми, но това може да се коригира особенно лесно. Напълно достатъчно е да се търси в изхода на командата mii-tool стринга link ok. За да работи този скрипт е необходимо потребителят от чието име вървъ нашият web сървър да има достъп до mii-tool. Това става посредством следният ред в /etc/sudoers

www-data ALL=(ALL) NOPASSWD: /sbin/mii-tool

Проверка на използването на паметта
Този скрипт е полезен за проверка на използваната памет. При рутери е особенно важно системата да не използва swap тъй като това краде процесорни цикли и като цяло затормозва машината. За да работи скрипта ни е необходима командата free

< ?php
// simple checking of memory utilisation
// vvitkov
// 02.11.2006
?>
< html >
<head>
<title>Memory Usage</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
</link></head>
< ?php include "header.php"; ?>
< body ><center><br /><h2>Memory Usage</h2><br /></center>
< ?php
$stat=explode(" ", shell_exec("free -m| head -2|tail -1|awk '{print $2\" \"$3\" \"$4}'"));
$stat2=explode(" ", shell_exec("free -m| head -4|tail -1|awk '{print $2\" \"$3\" \"$4}'"));
$tresh=30;
?>
<table border=0 align=center>
        <tr>
                <th>Mem type</th>
                <th>Used</th>
                <th>free</th>
                <th>Total</th>
        </tr>
        <tr>
                <th>RAM</th>
                <td>< ?php echo $stat[1]; ?></td>
                <td>< ?php echo $stat[2]; ?></td>
                <td>< ?php echo $stat[0]; ?></td>
        </tr>
        <tr>
                <th>SWAP</th>
                <td>< ?php
                        if ($stat2[1] > $tresh) {
                                echo "<font color=red weight=bold>$stat2[1]</font>" ;
                        } else {
                                echo $stat2[1];
                        }
                ?>
                </td>
                <td>< ?php echo $stat2[2]; ?></td>
                <td>< ?php echo $stat2[0]; ?></td>
        </tr>
        <tr>
                <th>TOTAL</th>
                <td>< ?php echo ($stat[1]+$stat2[1]); ?></td>
                <td>< ?php echo ($stat[2]+$stat2[2]); ?></td>
                <td>< ?php echo ($stat[0]+$stat2[0]); ?></td>
        </tr>
        <tr>
                <td>&nbsp;</td>
                <th>< ?php
                        if ($stat2[1] > $tresh) {
                                echo "<font color=red weight=bold>^^^</font>" ;
                        } else {
                                echo "&nbsp";
                        }
                ?>
                </th>
                <td>&nbsp;</td>
                <td>&nbsp;</td>
        </tr>
</table>
<div class="sub">If there is a red number ... that is a problem</div>
< ?php include "footer.php"; ?>

Единствената променлива която трябва да се коригира е $tresh. Тя се използва за да извади предупреждение че използването на swap е нарастнало над някакво ниво. Възможно е да бъде нагласена на примерно 20% но смятам че е по удачно да бъде въведена на ръка.

Проверка броя активни сесии
Ако има проблеми с отваряне на страници, това може да е индикация на изхабени сесии. Тъй като знаем че някои доставчици лимитират броя сесии, този инструмент може да бъде полезен. Трябва да се отбележи че числата които са отчетени не са строго меродавни, тъй като не се отчита състоянието на сесията а просто наличието и. Тоест ако сесията е в състояние CLOSE_WAIT въпреки че може да бъде оползотворена тя се включва в бройката.
За да работи коректно скрипта са ни необходими sudo, netstat-nat

<?php
// simple checking of connectivity
// vvitkov
// 02.11.2006
?>
<html>
<head>
<title>Connection statistics</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
</link></head>
<?php include "header.php"; ?>
<body ><center><br /><h2>Connection statistics</h2><br /></center>
<table border=0 align=center>
        <tr>
                <th>Proto</th>
                <th>Clients</th>
                <th>Ruter</th>
        </tr>
        <tr>
                <th>TCP</th>
                <td><?php echo exec("sudo netstat-nat -n -S -p tcp | grep ESTABLISHED | wc -l"); ?></td>
                <td><?php echo exec("sudo netstat-nat -n -L -p tcp | grep ESTABLISHED | wc -l"); ?></td>
        </tr>
        <tr>
                <th>UDP</th>
                <td><?php echo exec("sudo netstat-nat -n -S -p udp | grep ESTABLISHED | wc -l"); ?></td>
                <td><?php echo exec("sudo netstat-nat -n -L -p udp | grep ESTABLISHED | wc -l"); ?></td>
        </tr>
</table>
<br />
<div class=sub>Only active connections are visible</div>
<?php include "footer.php"; ?>

Заключение
В тази статия не е показана настройка на mrtg и phpsysinfo, тъй като те са относително елементарни. С това приключва нашата елементарна система за наблюдение и статистика. Самата система е наистина доста проста но върши работа.
Прилагам цялата система в архивиран вид. За да работи е необходимо да си настроите mrtg посредством cfgmaker и indexmaker от инсталацията на mrtg и phpsysinfo посредством пакетната система на дебиан.

monitoring system

Трябва да се отбележи че системата има възможност да показва съобщения настроени от администратора в основният си изглед. Това се постига благодарение на файла header.php

Серията продължава в The Perfect SOHO router – Part 6

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , , , , , , , , , , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

The Perfect SOHO router – Part 4

Владимир | 12/06/2009

Това е четвъртата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

След като вече сме инсталирали нашият рутер и сме пуснали някои услуги е време да конфигурираме самият процес на рутиране. Това се постига чрез стандартни инструменти като route, iptables, arp, iproute2.

В тази част ще покажем следните варианти:

  • Прост елементарен рутер – това е най елементарният но за сметка на това не предлага кой знае какви възможности
  • Рутер който изпълнява NAT/masquerade и firewall функции – това е може би най-разпространеният вариант.
  • Рутер който изпълнява баланс на трафика от два или повече доставчика – това вече е по-напреднала тема но въпреки всичко има полза от нея.

Примерите и конфигурациите ще са доста опростени като ще покажем само скелета на системата, тъй като всеки има различни изисквания. В края на статията ще дам малко връзки с допълнителна информация за четене и помощ.

Прост рутер
При тази ситуация нашият рутер просто развърта тряфика. В общият случай не се прави маскиране или филтрация на трафикатъй като като цяло е решено че не е необходимо. Това решение обикновенно се ползва при големи мрежи просто за да се сегментира мрежата. Постига се особенно елеменарно тъй като изисква включване на една единствена опци в кернела и разрешаването и за изпълнение. Опцията е IP FORWARDING. Може да бъде разрешена по два различни начина:

  1. Посредством proc системата (тя е налична при всички случаи): 
    echo "1" > /proc/sys/net/ipv4/ip_forward
  2. Посредством sysctl системата (може да не е налична): 
    sysctl -w net.ipv4.ip_forward=1

Тази настройка разрешава препращане на пакети между интерфейсите на рутерът ни и така реално го стартираме. Необходимо е тази настройка да бъде сложена на такова място че при стартирането на нашата машина тя да бъде изпълнена автоматично. Добро място за тази настройка е /etc/rc.local или отделен файл който се изпълнява съвсем в края на процеса на стартиране.
Както забелязвате това е един много опростен рутер който не предлага почти никакви ползи. За да работи правилно всяка от клиентските машини трябва да има собствен адрес, който е разпознаваем в обхвата на мрежата. Този рутер не изпълнява филтрация и не предпазва по никакъв начин машините зад него. Като цяло това решение е удачно за големи мрежи които искат да сегментират адресното си пространство и които имат сериозен рутер и firewall на входа им.

Рутер който изпълнява NAT/masquerade и firewall функции
Това е може би най-често използваното решение. Предимствата му са че зад един адрес могат да се скрият (маскират) доста олям брой машини (теоретично почти неограничен стига да имаме процесорна мощ).
Конфигурацията за този пример ще изградим при следните предпоставки:

  • Външен интерфейс: eth0 със съответно назначения му адрес и маска
  • Вътрешен интерфейс: eth1 със съответно назначения му адрес и маска
  • Проста защита от DoS, DDoS атаки и сканиране
  • Лимит на специфични ICMP заявки
  • Достъп до http и ssh от външната страна на рутера ни
  • Достъп до http, ssh, dns, dhcp от вътрешната страна
  • SNAT за всички клиенти на рутера ни (дори при динамичен адрес)
  • Препращане на 10 порта за всеки клиент – за удобство на потребителите ни
  • Изрична филтрация на част от боклука във външната/вътрешната ни мрежа

Темата за ограничения по TTL изрично ще я пропусна. Реализира се просто и има достатъчно документация по въпроса.

#!/bin/bash

# Simple firewalling router
# author: vvitkov
# contact: http://www.getoto.net/az/
#
# Licence: CC NC-BY-SA v3
# Disclaimer: i take no responsibility for the consequences of using or not using this.
# It is up to you to decide what to do with this stuff.
# Please if you use this write me a note and don't remove the author info.

#######
# Settings, vars
#######
echo "Setting Up Variables ..."
IPT="/sbin/iptables"
if [ -x /sbin/sysctl ] ; then
	SYSCTL="/sbin/sysctl -w"
fi

# define external interface, ip, mask, broadcast
EXT_IF="eth0"
EXT_IP="$(/sbin/ifconfig $EXT_IF | grep "addr:" | cut -d":" -f2 | cut -f1 -d" ")"
EXT_NM="$(/sbin/ifconfig $EXT_IF | grep "addr:" | cut -d":" -f4 | cut -f1 -d" ")"
EXT_BC="$(/sbin/ifconfig $EXT_IF | grep "addr:" | cut -d":" -f3 | cut -f1 -d" ")"

# define internal interface, ip, mask, broadcast
INT_IF="eth1"
INT_IP="$(/sbin/ifconfig $INT_IF | grep "addr:" | cut -d":" -f2 | cut -f1 -d" ")"
INT_NM="$(/sbin/ifconfig $INT_IF | grep "addr:" | cut -d":" -f4 | cut -f1 -d" ")"
INT_BC="$(/sbin/ifconfig $INT_IF | grep "addr:" | cut -d":" -f3 | cut -f1 -d" ")"
INT_NET="$INT_IP"/"$INT_NM"

# define the loopback
LO_IF="lo"
LO_IP="127.0.0.1"

# define allowed ports
EXT_IN_TCP="22 80"
EXT_IN_UDP="33434:33524"

INT_IN_TCP="22 53 67 68 80"
INT_IN_UDP="53 67 68 33434:33524"

#######
# Lets go
#######
echo "Tunning ..."
if [ -z $SYSCTL ] ; then
	# stop forwarding
	$SYSCTL net.ipv4.ip_forward=0
	# fix our routing a bit
	$SYSCTL net.ipv4.conf.default.accept_redirects=0
	$SYSCTL net.ipv4.conf.default.accept_source_route=0
	$SYSCTL net.ipv4.conf.default.send_redirects=0
	$SYSCTL net.ipv4.conf.default.rp_filter=1
	# don't log strange packets
	$SYSCTL net.ipv4.conf.default.log_martians=0
	# smurf rpotection
	$SYSCTL net.ipv4.icmp_echo_ignore_broadcasts=1
	$SYSCTL net.ipv4.icmp_ignore_bogus_error_responses=1
	$SYSCTL net.ipv4.conf.default.proxy_arp=0
	# keep quiet about arp requests/answers
	$SYSCTL net.ipv4.conf.default.arp_filter=1
	$SYSCTL net.ipv4.conf.default.arp_announce=2
	$SYSCTL net.ipv4.conf.default.arp_ignore=2
	# set the ttl to a windows like box (additional layer of security)
	$SYSCTL net.ipv4.ip_default_ttl=128
	# recycle fast unused buckets for packet infos
	$SYSCTL net.ipv4.tcp_tw_recycle=1
	$SYSCTL net.ipv4.tcp_tw_reuse=1
	# do not stamp the packets
	$SYSCTL net.ipv4.tcp_timestamps=0
else
	echo "0" > /proc/sys/net/ipv4/ip_forward
	echo "0" > /proc/sys/net/ipv4/conf/default/accept_redirects
	echo "0" > /proc/sys/net/ipv4/conf/default/accept_source_route
	echo "0" > /proc/sys/net/ipv4/conf/default/accept_send_redirects
	echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter
	echo "0" > /proc/sys/net/ipv4/conf/default/log_martians
	echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
	echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
	echo "0" > /proc/sys/net/ipv4/conf/default/proxy_arp
	echo "1" > /proc/sys/net/ipv4/conf/default/arp_filter
	echo "2" > /proc/sys/net/ipv4/conf/default/arp_announce
	echo "2" > /proc/sys/net/ipv4/conf/default/arp_ignore
	echo "128" > /proc/sys/net/ipv4/ip_default_ttl
	echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
	echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
	echo "0" > /proc/sys/net/ipv4/tcp_timestamps
fi

# Clear all tables
echo "Start on clean ..."
$IPT -F
$IPT -t nat -F
$IPT -t mangle -F

$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

echo "Setting custom chains ..."
$IPT -N bad_packets
$IPT -N bad_tcp_packets
$IPT -N icmp_packets
$IPT -N tcp_in
$IPT -N udp_in
$IPT -N tcp_out
$IPT -N udp_out

echo "Setting some protections ..."
echo "  General"
$IPT -A bad_packets -p ALL -i $EXT_IF -s $INT_NET -j DROP
$IPT -A bad_packets -p ALL -m state --state INVALID -j DROP
$IPT -A bad_packets -p tcp -j bad_tcp_packets
$IPT -A bad_packets -p ALL -j RETURN

echo "  TCP"
$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPT -A tcp_in -p TCP -s 0/0 --destination-port 113 -j REJECT
$IPT -A bad_tcp_packets -p tcp -j RETURN

echo "  ICMP"
$IPT -A icmp_packets --fragment -p ICMP -j DROP
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -m limit --limit 1/s -j ACCEPT
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
$IPT -A icmp_packets -p ICMP -j RETURN

echo "  UDP"
$IPT -A udp_in -p UDP -s 0/0 --dport 137 -j DROP
$IPT -A udp_in -p UDP -s 0/0 --dport 139 -j DROP
$IPT -A udp_in -p UDP -s 0/0 --dport 113 -j REJECT

echo "Filling the chains ..."
echo "  UDP INCOMING"
for PORT in $EXT_IN_UDP ; do
	$IPT -A udp_in -p UDP -i EXT_IF -s 0/0 --dport $PORT -j ACCEPT;
done
for PORT in $INT_IN_UDP ; do
	$IPT -A udp_in -p UDP -i INT_IF -s 0/0 --dport $PORT -j ACCEPT;
done
$IPT -A udp_in -j RETURN

echo "  UDP OUTGOING"
$IPT -A udp_out -p UDP -s 0/0 -j ACCEPT

echo "  TCP INCOMING"
for PORT in $EXT_IN_TCP ; do
	$IPT -A tcp_in -p TCP -i $EXT_IF -s 0/0 --dport $PORT -j ACCEPT
done
for PORT in $INT_IN_TCP ; do
	$IPT -A tcp_in -p TCP -i $INT_IF-s 0/0 --dport $PORT -j ACCEPT
done
$IPT -A tcp_in -p TCP -j RETURN

echo "  TCP OUTGOING"
$IPT -A tcp_out -p TCP -j ACCEPT

echo "  INCOMING"
$IPT -A INPUT -p ALL -i $LO_IF -j ACCEPT
$IPT -A INPUT -p ALL -j bad_packets
$IPT -A INPUT -p ALL -d 224.0.0.1 -j DROP
$IPT -A INPUT -p ALL -i $INT_IF -s $INT_NET -j ACCEPT
$IPT -A INPUT -p ALL -i $INT_IF -d $INT_BC -j ACCEPT
$IPT -A INPUT -p UDP -i $INT_IF --sport 68 --dport 67 -j ACCEPT
$IPT -A INPUT -p ALL -i $EXT_IF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p ALL -i ! $EXT_IF -m state --state NEW -j ACCEPT
$IPT -A INPUT -p TCP -i $EXT_IF -j tcp_in
$IPT -A INPUT -p UDP -i $EXT_IF -j udp_in
$IPT -A INPUT -p ICMP -i $EXT_IF -j icmp_packets
$IPT -A INPUT -m pkttype --pkt-type broadcast -j DROP

echo "  FORWARD"
$IPT -A FORWARD -p ALL -j bad_packets
$IPT -A FORWARD -p tcp -i $INT_IF -j tcp_out
$IPT -A FORWARD -p udp -i $INT_IF -j udp_out
$IPT -A FORWARD -p ALL -i $INT_IF -j ACCEPT
$IPT -A FORWARD -i $EXT_IF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p ALL -i $EXT_IF -m state --state NEW -j ACCEPT

echo "  OUTPUT"
$IPT -A OUTPUT -m state -p icmp --state INVALID -j DROP
$IPT -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPT -A OUTPUT -p ALL -o $LO_IF -j ACCEPT
$IPT -A OUTPUT -p ALL -s $INT_IP -j ACCEPT
$IPT -A OUTPUT -p ALL -o $INT_IF -j ACCEPT
$IPT -A OUTPUT -p ALL -o $EXT_IF -j ACCEPT

echo "  NAT"
echo "      PORT FORWARDING"
TMP="`echo $INT_IP | cut -d\. -f1-3`"
for HOST in `seq 2 254` ; do
        PORTR=$((10000+HOST*10)):$((10009+HOST*10))
        echo "   $PORTR for $TMP.$HOST"
        $IPT -A FORWARD -p udp -i $EXT_IF --dport $PORTR -d $TMP.$HOST -j ACCEPT
        $IPT -A FORWARD -p tcp -i $EXT_IF --dport $PORTR -d $TMP.$HOST -j ACCEPT
        $IPT -t nat -A PREROUTING -p udp -i $EXT_IF --dport $PORTR -j DNAT --to $TMP.$HOST
        $IPT -t nat -A PREROUTING -p tcp -i $EXT_IF --dport $PORTR -j DNAT --to $TMP.$HOST
done

$IPT -t nat -A POSTROUTING -o $EXT_IF -j SNAT --to $EXT_IP

if [ -z $SYSCTL ] ; then
	$SYSCTL net.ipv4.ip_forward=1
else
	echo "1" > /proc/sys/net/ipv4/ip_forward
fi

Като цяло това е един относително добър базов firewall. В него има няколко интересни момента а именно:

  • Начинът по който вземаме адресите на мрежовите карти – както сте забелязали единствените променливи които не се извличат това са имената на интерфейсите. По този начин самият firewall става по гъвкав и приложим за почти всякакъв вид връзки.
  • Начина по който реализираме маскирането. Правим го със SNAT тъй като той е по лек отколкото MASQUERADE. За хората които ще кажат че при динамични връзки (pppoe, ip идващо от dhcp) това не е подходящо, да по принцип сте прави. Обаче ако използваме възможностите на DHCP клиента/pppoe клиента това може да бъде избегнато. В момента в който нашият адрес бъде подменен можем принудително да изпълним отново нашият firewall и той отново да си вземе правилния адрес и да се оправи както си му е редът.
  • Начинът по който препращаме портове на машините зад нас – използвана е конструкция която е валидна само в bash с която да се генерират две числа които използваме за начало и край на обхвата от портове. След това експлицитно ги отваряме във веригата FORWARD макар че това не е строго необходимо и в последствие ги препращаме чрез DNAT.
  • Обхватът от портове 33434:33524 – тези портове трябва да са отворени за да работи traceroute

Рутер който изпълнява баланс на трафика от два или повече доставчика
Тук ще дадем само частта която реално изпълнява балансирането на трафика. Вземаме пример само с два доставчика, но разширяването на примера не е проблем. Задачата е малко по обемиста тъй като за удобство ще използваме iproute. Самият пакет има доста криптичен синтаксис но след като му свикнете едва ли ще ви се разделя с него.

За да можем да балансираме трафик ни трябват следните инструменти:

  • iproute2
  • поддръжка в кернела за multipath routing
  • Компилиран в кернела поне една дисциплина за multipath routing – аз лично препоръчвам wrr

За да можем да използваме имена в конфигурацията е необходимо да ги добавим във файла /etc/iproute2/rt_tables. Индексите им са между 2 и 252. Ако ще балансирате повече от 200 доставчика … не четете на правилното място.

#!/bin/bash
#
# Simple balancing router
# author: vvitkov
# contact: http://www.getoto.net/az/
#
# Licence: CC NC-BY-SA v3
# Disclaimer: i take no responsibility for the consequences of using or not using this.
# It is up to you to decide what to do with this stuff.
# Please if you use this write me a note and don't remove the author info.

### Settings
ISP1_NET="1.2.3.0/24"
ISP1_GW="1.2.3.1"
ISP1_IF="eth1"
ISP1_OUR_HOST="1.2.3.99"
ISP2_NET="9.8.7.0/24"
ISP2_GW="9.8.7.1"
ISP2_IF="eth2"
ISP2_OUR_HOST="9.8.7.99"

INT_NET="10.42.3.0/24"

# Defining routing tables for source routing
if ( ip ru ls | grep main | grep 50 )
then
        ip r f t main
else
        ip ru a prio 50 t main
fi

if ( ip ru ls | grep isp_rules1 )
then
        ip r f t isp_rules1
else
        ip ru a from $ISP1_NET prio 201 t isp_rules1
fi

if ( ip ru ls | grep isp_rules2 )
then
        ip r f t isp_rules2
else
        ip ru a from $ISP2_NET prio 202 t isp_rules2
fi

# Clear all the existing routes
ip r f any
ip r f t default

# Host routes
ip r a $ISP1_NET dev $ISP1_IF src $ISP1_OUR_HOST
ip r a $ISP2_NET dev $ISP2_IF src $ISP2_OUR_HOST

# Local networks
ip r a 127.0.0.0/8 dev lo
ip r a $INT_NET dev eth0

# Default gateways
ip r a 0/0 via $ISP1_GW dev $ISP1_IF table isp_rules1 proto static
ip r a prohibit 0/0 table isp_rules1 metric 1 proto static

ip r a 0/0 via $ISP2_GW dev $ISP2_IF table isp_rules2 proto static
ip r a prohibit 0/0 table isp_rules2 metric 1 proto static

# lets shake it :)
ip r a 0/0 proto static table default nexthop via $ISP1_GW dev $ISP2_IF nexthop via $ISP2_GW dev $ISP2_IF

# Remote networks with static routes
ip r a < NETWORK IN ISP1 > via $ISP1_GW dev $ISP1_IF
ip r a < NETWORK IN ISP2 > via $ISP2_GW dev $ISP2_IF

# flush caches
ip r f c

С това завършват примерите за конфигуриране на рутер. Знам че не са покрити всички възможности, но човек трябва да се потруди малко.

Серията продължава в The Perfect SOHO router – Part 5

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , , , , , , , , , , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

The Perfect SOHO router – Part 3

Владимир | 12/06/2009

Това е третата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

След като вече сме инсталирали нашият рутер е време да започнем неговата конфигурация. Започваме от DNS и DHCP услугите поради следните причини:

  • Добро упражнение е
  • Така ще осигурим първоначална сигурност и лесна конфигуруемост на нашата мрежа
  • Имаме възможност да тестваме относително спокойно

Защо ни трябва DNS
DNS системата се използва за откриване на съответствията между име и ip адрес. Самата система представлява огромна разпределена база от данни в която са организирани всички съществуващи имена по света. Полезно е да имаме собствен DNS поради следните причини:

  • Възможност да си създадем собствен фалшив домейн
  • Ускорено отговаряне на запитванията
  • Кеширане на отговорите
  • Частична независимост от нашият доставчик

Защо ни трябва DHCP
DHCP е протокол за динамично и автоматизирано конфигуриране на мрежовата част от нашата операционна система. С негова помощ ние можем да зададем огромно множество от параметри които да настроят работата на клиентските машини. Също така този протокол ни спестява необходимостта да обиколим всички клиентски машини при всяка промяна на мрежовите настройки. Посредством този протокол можем да зададем следните настройки (непълен списък):

  • IP адрес на машината
  • DNS сървъри
  • Сървъри за стартиране по мрежа
  • Подразбиращ се път за изход към интернет
  • Сървър за точно време
  • TTL
  • Максимална големина на пакета
  • други

Възможните варианти
Както почти всичко в света на GNU/Linux и за тази задача има няколко варианта. Двата най често използвани варианта за малка мрежа са: отделен DNS и DHCP софтуерен сървър; единствен софтуерен сървър който комбинира DNS и DHCP. За момента най популярните решения за малки мрежи (до 30 – 50 машини) са:

  • bind9 + dhcpd
  • dnsmasq

Тук ще опишем конфигурирането и на трите продукта. Моето лично предпочитание е комбинацията между bind9 и dhcpd

Конфигуриране на dhcpd
За конфигурирането изхождаме от следните предпоставки:

  • Вътрешната ни мрежа е 10.42.3.0/24
  • Намира се на интерфейс eth1
  • Нашият DNS се намира на адрес 10.42.3.1
  • Допълнително сервираме и един DNS на нашият доставчик намиращ се на адрес 1.2.3.4
  • Нашият gateway се намира на адрес 10.42.3.1
  • Всички наши машини се намират във несъществуващ домейн internal.tld
  • Ще подадем малко допълнителни настройки за унифициране на вътрешната ни мрежа

След всичко казано ето примерна конфигурация на нашият dhcp сървър
/etc/dhcpd.conf

#
# Sample configuration file for ISC dhcpd for Debian
#
# $Id: dhcpd.conf,v 1.4.2.2 2002/07/10 03:50:33 peloy Exp $
#

# option definitions common to all supported networks...
# без това нашият сървър няма да работи правилно
authoritative;

# несъществуващият домейн към който ще принадлежим
option domain-name "internal.tld";
# нашият dns сървър. В случая ползваме само него за яснота. А също и за разширяемост в последствие
option domain-name-servers 10.42.3.1;

# мрежовата маска. Няма нужда да оставяме клиентите да отгатват
option subnet-mask 255.255.255.0;
# за колко време им отпускаме адрес
default-lease-time 14400;
# колко време максимално може да притежават адреса ако случайно dhcp сървърът ни спре да работи
max-lease-time 86400;

# нашата мрежа от която ще раздаваме адреси
subnet 10.42.3.0 netmask 255.255.255.0 {
  # конкретните адреси които ще раздаваме
  range 10.42.3.2 10.99.3.254;
  # отново нашите DNS сървъри
  option domain-name-servers 10.99.3.1, 1.2.3.4;
  # и домейна
  option domain-name "internal.tld";
  # рутерът (gateway)
  option routers 10.42.3.1;
  # маската
  option subnet-mask 255.255.255.0;
  # къде да се отправят масови запитвания
  option broadcast-address 10.42.3.255;
  # настройка на TTL (windows машините не се подчиняват)
  option default-ip-ttl 64;
  option default-tcp-ttl 64;
  # отместване спрямо GMT
  option time-offset 7200;
  # настройка на типа на нода в MS мрежа
  option netbios-node-type 8;
}

Като цяло това е една добра начална конфигурация. Както ще забележите има известно припокриване на дефинициите за DNS, мрежова маска и домейн. Това е с цел в последствие ако искаме да сегментираме мрежата ни. Ако имаме такова желание ще е напълно достатъчно да разделим секцията ни subnet на няколко части и за всяка част да раздаваме различни настройки. Основното правило е да се дефинират възможно най-много параметри на възможно най-горно ниво (пр: глобално). Така в последствие има по-малко поддръжка по самата конфигурация.

Остана да се отбележи че сървърът трябва да слуша само на вътрешният интерфейс (eth1). Това се постига посредством указване на кой интерфейс да слуша демонът в конфигурационният файл /etc/default/dhcp.

Като цяло това завършва конфигурирането на dhcpd.

Конфигуриране на bind9
Това ще нашият DNS сървър. За неговата конфигурация изхождаме от същите предположения както и за DHCP сървърът ни. Като допълнение ще създадем нашият домейн internal.tld.

Конфигурацията му е разделена в няколко файла, а именно:

  • /etc/bind/named.conf – основна конфигурация. Като цяло в този файл се включват други файлове
  • /etc/bind/named.conf.options – тук се намират опциите настройващи поведението на нашият сървър
  • /etc/bind/named.conf.local – тук се намират дефинициите на нашите зони
  • Зонови файлове – това са същинските зони

Ще покажем конфигурациите на самият сървър и дефинициите на нашите зони, като ще пропуснем тези които съществуват стандартно.

/etc/bind/named.conf

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

/etc/bind/named.conf.options

options {
        // директория в която ще работим. Ако имаме относително име на файл
        // то ще се търси в тази директория
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you might need to uncomment the query-source
        // directive below.  Previous versions of BIND always asked
        // questions using port 53, but BIND 8.1 and later use an unprivileged
        // port by default.

        query-source address * port 53;

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                1.2.3.4;
        };

        auth-nxdomain no;    # conform to RFC1035
        // няма да използваме IPv6
        listen-on-v6 { none; };
        // Не позволяваме рекурсия. Т.е. не отговаряме за домейни които не знаем
        // тази опция ще бъде предефинирана в по-късен етап
        recursion no;
        // поради факта че не слушаме на IPv6 и не дефинираме такива зони в лога
        // се появяват няколко реда които са особенно дразнещи. Това ги премахва
        empty-zones-enable no;
};

/etc/bind/named.conf.local

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

// дефиниция на лист за достъп. Локалната машина задължително трябва да е в нея
acl internal {
        10.42.3.0/24;
        127.0.0.0/8;
};

// изглед. Това е нова възможност на bind която позволява сепарация на информацията
// в зависимост от това от къде идваме
view "internal" {
        // от този изглед могат да получават отговори хостове от нашият списък
        match-clients { internal; };
        // вече можем да отоваряме и за домейни които не са при нас
        recursion yes;

        // нашият несъществуващ домейн
        zone "internal.tld" {
                type master;
                // къде се намира същинската зона
                file "/etc/bind/internal.tld-forward";
                // ако включим динамично опресняване на информацията в DNS
                // само описаните клиенти ще могат да изпълняват такива заявки
                allow-transfer { internal; };
                allow-update { internal; };
        };

         // Това е обратната ни зона. Създава съответствие IP/име
        zone "3.99.10.in-addr.arpa" {
                type master;
                file "/etc/bind/internal.tld-reverse";
                allow-transfer { internal; };
                allow-update { internal; };
        };

        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "/etc/bind/db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        zone "localhost" {
                type master;
                file "/etc/bind/db.local";
        };

        zone "127.in-addr.arpa" {
                type master;
                file "/etc/bind/db.127";
        };

        zone "0.in-addr.arpa" {
                type master;
                file "/etc/bind/db.0";
        };

        zone "255.in-addr.arpa" {
                type master;
                file "/etc/bind/db.255";
        };
};

Като цяло това завършва конфигурацията на нашият сървър. Както ще забележите той слуша на всички интерфейси но за нормални заявки отговаря само ако заявката идва от вътрешната мрежа. Стандартно логовете при дебиан отиват в /var/log/daemon.log. Сега остана само да опишем нашите зони.

internal.tld – /etc/bind/internal.tld-forward

; BIND db file for internal.tld
; Време на живот по подразбиране
$TTL 86400

; Запис който ни дефинира като собственици на домейна
@       IN      SOA     perfect-soho-r01.internal.tld.      root. (
                        2007060101     ; serial number YYMMDDNN
                        28800           ; Refresh
                        7200            ; Retry
                        864000          ; Expire
                        86400           ; Min TTL
                        )
                ; нашият DNS. Това е glue запис
                NS      perfect-soho-r01.internal.tld.

; ако името не е пълно специфицирано добави това
$ORIGIN internal.tld.

perfect-soho-r01  IN      A       10.42.3.1
; псевдоним на нашият рутер
gate IN CNAME perfect-soho-r01

3.42.10.in-addr.arpa - /etc/bind/internal.tld-reverse

; BIND reverse data file for internal.tld
$TTL    86400
@       IN      SOA     garota.internal.tld. root. (
                     2007060101         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL

@       IN      NS      perfect-soho-r01.internal.tld.
1       IN      PTR     perfect-soho-r01.internal.tld.

С това завършва конфигурацията на bind9.

Конфигуриране на dnsmasq
dnsmasq екомбинация от dns и dhcp сървър подходящ за малки мрежи. Има ниско потребление на рам, настройва се относително бързо и лесно. Като цяло не съм много сведущ по него, но с малко помощ от man тази конфигурация излезе

# Configuration file for dnsmasq.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.

# Never forward plain names (with a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv

# Uncomment this to filter useless windows-originated DNS requests
# Note that (amongst other things) this blocks all SRV requests,
# so don't use it if you use eg Kerberos.
filterwin2k

# Add domains which you want to force to an IP address here.
# The example below send any host in doubleclick.net to a local
# webserver.
# a bit of spam/ad blocking
address=/doubleclick.net/127.0.0.1

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

# If you want dnsmasq to listen for requests only on specified interfaces
# (and the loopback) give the name of the interface (eg eth0) here.
# Repeat the line for more than one interface.
interface=eth1

# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
#     as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
#    domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=internal.tld

# Uncomment this to enable the integrated DHCP server, you need
# to supply the range of addresses available for lease and optionally
# a lease time. If you have more than one network, you will need to
# repeat this for each network on which you want to supply DHCP
# service.
dhcp-range=10.42.3.2,10.42.3.254,255.255.255.0,4h

# If this line is uncommented, dnsmasq will read /etc/ethers and act
# on the ethernet-address/IP pairs found there just as if they had
# been given as --dhcp-host options. Useful if you keep
# MAC-address/host mappings there for other purposes.
read-ethers

# Send options to hosts which ask for a DHCP lease.
# See RFC 2132 for details of available options.
# Note that all the common settings, such as netmask and
# broadcast address, DNS server and default route, are given
# sane defaults by dnsmasq. You very likely will not need any
# any dhcp-options. If you use Windows clients and Samba, there
# are some options which are recommended, they are detailed at the
# end of this section.
# For reference, the common options are:
# subnet mask - 1
# default router - 3
# DNS server - 6
# broadcast address - 28
dhcp-option=6,10.42.3.1,1.2.3.4
# Set the default time-to-live to 50
dhcp-option=23,64

# The following DHCP options set up dnsmasq in the same way as is specified
# for the ISC dhcpcd in
# http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt
# adapted for a typical dnsmasq installation where the host running
# dnsmasq is also the host running samba.
# you may want to uncomment them if you use Windows clients and Samba.
dhcp-option=19,0           # option ip-forwarding off
#dhcp-option=44,0.0.0.0     # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
#dhcp-option=45,0.0.0.0     # netbios datagram distribution server
dhcp-option=46,8           # netbios node type
dhcp-option=47             # empty netbios scope.

# Set the DHCP server to authoritative mode. In this mode it will barge in
# and take over the lease for any client which broadcasts on the network,
# whether it has a record of the lease or not. This avoids long timeouts
# when a machine wakes up on a new network. DO NOT enable this if there's
# the slighest chance that you might end up accidentally configuring a DHCP
# server for your campus/company accidentally. The ISC server uses the same
# the same option, and this URL provides more information:
# http://www.isc.org/index.pl?/sw/dhcp/authoritative.php
dhcp-authoritative

# Normally responses which come form /etc/hosts and the DHCP lease
# file have Time-To-Live set as zero, which conventionally means
# do not cache further. If you are happy to trade lower load on the
# server for potentially stale date, you can set a time-to-live (in
# seconds) here.
local-ttl=600

# If you want dnsmasq to detect attempts by Verisign to send queries
# to unregistered .com and .net hosts to its sitefinder service and
# have dnsmasq instead return the correct NXDOMAIN response, uncomment
# this line. You can add similar lines to do the same for other
# registries which have implemented wildcard A records.
#bogus-nxdomain=64.94.110.11

#log-queries

Не твърдя че конфигурацията е перфектна, но просто нямам много опит с dnsmasq.

Заключение
След като сме свършили всичко това се очаква че вече имаме работещи услуги и относително стабилна машина. Сега е добър момент за кратка почивка тъй-като следва описването на нашата защитна стена и рутирането.

Серията продължава в The Perfect SOHO router – Part 4

Коментари
Няма коментари »
Категории
Статии
Tags
, , , , , , , , , , , , , , , , ,
RSS коментари RSS коментари
Trackback Trackback

« Previous Entries