9/29/2010

За лошите практики - общи мисли

При ежедневната работа с Linux базирани операционни системи като системен администратор, доста често се сблъскваш с широка разнообразност от похвати, по които може да се реши даден проблем. Добрата системна администрация, зависи от това кой точно е най-удачният модел и избора на такъв е изключително важен.

Но кой е точно правилният метод, ако една от основните философии на Linux системите е точно пълната свобода на действие?

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

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

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

За това е важно за един системен администратор да е до болка запознат с установените пътища и да има поглед върху "голямата картинка" и концепцията.

Точно поради тази причина използвам Fedora, защото по принцип дериватите на Red Hat Linux винаги са държали страшно много на концепцията и мисленето в дългосрочен план.

За да не съм напълно голословен, ето един пример, за тея които биха ме разбрали:

# echo 1 >> /proc/sys/net/ipv4/ip_forward

След това тази команда се записва в някой системен файл, който се стартира със инициализацията, като например /etc/rc.local.

Ще оставя на читателя да разбере как се прави това по правилният начин. И това не е Red Hat или Fedora начина, а по принцип важи за всички модерни Linux системи.

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

9/24/2010

OpenVPN в кратки стъпки [3]

Нека продължим с конфигурацията на клиентската машина за нашият OpenVPN.

Първо копираме един от примерните конфигурационни файлове в директорията /etc/openvpn така:

# cp /usr/share/doc/openvpn-*/sample-config-files/roadwarrior-client.conf /etc/openvpn/client.conf

След това редактираме файла, като след remote тука:

remote [my server hostname or IP address]

записваме публичният IP адрес на сървъра ни. Имайте предвид, че ако на сървъра работи iptables, ще трябва да разрешите входящи връзки по порт 1194/udp, за да имате успешна комуникация. Във Fedora 13, firewall-а е пуснат по подразбиране и по-надолу ще обясня как да добавим тези правила, за да може всичко да е наред.

Може, разбира се, накрая на конфигурационният файл да добавим опцията:

log-append /var/log/openvpn

с цел диагностика, ако възникнат проблеми.

Преди да стартираме сървъра за да изградим VPN връзката, трябва да заредим модула за tun интерфейса, който ще използваме.

Това става чрез:

# modprobe tun



Но тъй като, това ще важи само докато не рестартираме системата, е нужно да добавим следното в директорията /etc/modprobe.d/

# touch /etc/modprobe.d/tun.conf
# echo "alias tun tun" > /etc/modprobe.d/tun.conf



Това е начина, по който модерни Линукс системи като Fedora използват за управление на модулите, които да се зареждат при стартиране. Писането на команди по разни скриптове, които се стартират с инициализацията на операционната система е проява на ниска техническа култура и не се препоръчва.

Така, време е да добавим openvpn в стандартните runlevel-и, за да може да се инициализира със стартирането на системата. Това във Fedora става с познатата ни вече команда chkconfig:

# chkconfig --levels openvpn on

Сега е време да пуснем нашият OpenVPN клиент и да проследим дали всичко е наред.

# service openvpn start

Във списъчният файл (ако сме задали такъв във конфигурацията, ако не всички системни съобщения отиват в /var/log/messages) трябва да видим нещо от рода:

Fri Sep 24 11:46:13 2010 us=542777 TUN/TAP device tun0 opened
Fri Sep 24 11:46:13 2010 us=542802 TUN/TAP TX queue length set to 100
Fri Sep 24 11:46:13 2010 us=542837 /sbin/ip link set dev tun0 up mtu 1500
Fri Sep 24 11:46:13 2010 us=543851 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Fri Sep 24 11:46:13 2010 us=547866 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Fri Sep 24 11:46:13 2010 us=548549 /sbin/ip route add 172.16.0.0/12 via 10.8.0.5
Fri Sep 24 11:46:13 2010 us=549134 Initialization Sequence Completed


С това всичко трябва да е наред и ако изпълним:

$ ping 10.8.0.1

би трябвало да получим ICMP отговор от сървъра ни.


PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=2.12 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=1.78 ms
64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=1.84 ms


Ето и какво трябва да направите, ако искате да разрешите порт 1194/udp, за да може да получавате входящи връзки. Първо трябва да решим къде ще добавим това правило в цялата firewall таблица. Разбира се, веригата която ни трябва е INPUT, тъй като няма да правим никаква машрутизация на тези пакети. Най-добре, според мен, е в тази верига това да се случи преди всички Reject правила, за да може да избегнем конфликти. Естествено, ако вашият сървър е конфигуриран първо да филтрира всичко и после да приема определни пакети, правилото трябва да е под филтриращите такива.

В най-общ случай това трябва да работи винаги:

# iptables --insert INPUT 1 --match state --state NEW --match udp --protocol udp --dport 1194 --jump ACCEPT

След като изпълни тази команда и проверим дали всичко вече работи е необходимо да запишем тези правила за да се изпълняват при инициализацияата на firewall-а. Това в модерни Линукс системи като Fedora се прави чрез:

# service iptables save

Което записва промените във файла /etc/sysconfig/iptables, от където се зареждат при стартиране. Имайте предвид, че ръчното редактиране на този файл не се препоръчва и вероятно ще доведе до грешки.

Повече информация за OpenVPN, може да намерите тук:

http://openvpn.net/

9/19/2010

OpenVPN в кратки стъпки [2]

Нека продължим историята за OpenVPN връзката, от предишният пост.

Като цяло конфигурацията на OpenVPN сървъра е елементарна и доста праволинейна. На първо време трябва да изберем дали искаме routing или bridging метод за връзка между системите във VPN-а.

Разликите може да прочетете тук.

Аз избрах routing, защотo е по-гъвкав от колкото Ethernet bridging.

Така, първо нека преместим един от примерните конфигурационни файлове в директорията /etc/openvpn/. Това става така:

# cp /usr/share/doc/openvpn-2.1.1/sample-config-files/roadwarrior-server.conf /etc/openvpn/server.conf

След това отваряме файла /etc/openvpn/server.conf с любимията си текстов редактор (трябва да сте root за да може да записвате промените).

Първият ред показва порта, на който OpenVPN сървъра ще чака заявка, за осъществяване на комуникация. Вторият ред показва какъв вид връзка ще използваме (това не е много интуитивно, но ако сте прочели FAQ-то по-горе, ще разберете че за Routing използваме tun, а за Bridging използваме tap). По-надолу следват конфигурацията на ключовете, и пътищата до тях. Тук трябва да променим пътя до директорията с ключове, която направихме в първата част на това howto. Ето пример:

tls-server
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/lateralus.crt
key /etc/openvpn/easy-rsa/keys/lateralus.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

Малко по-надолу указваме режима да е сървър, оказваме IP адресите, които сървъра ще използва за крайни точки (тези адреси, не трябва да съществуват в мрежата, за да не стават конфликти) , също така и адресите, които да се раздават на клиентите, в нашият случай оставяме комуникационна четворка за всеки един от тях.

По-интересна е опцията push, чрез която може да окажете какви routing пътища трябва да се добавят към статичната routing таблица на клиентите. Например, ако имаме частна мрежа 172.16.0.0/12, която клиентите в VPN-а искате да достъпват е нужно да направим следният push към тях

# Push any routes the client needs to get in
# to the local network.
push "route 172.16.0.0 255.240.0.0"

По този начин, след като клиента се е удостоверил пред сървъра, последният му изпраща заявка за модифициране на routing таблицата му. Понеже това рядко ще работи out-of-the-box, може да се наложи модифициране на firewall-а на системата (iptables), което ще покажа как се случва по-надолу.

По-надолу в примерният файл има още push заявки за DHCP към клиенти с операционна система Windows. Тъй като не използвам Windows, в този пример, тези опции съм ги коментирал. Всичко останало съм го оставил така както си е, само съм добавил най-накрая на файла:

log-append /var/log/openvpn

За да мога да записвам съобщенията от сървъра, целта е ясна.

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

# chkconfig --levels openvpn on

Това в системи базирани на Red Hat (като Fedora, CentOS и т.н.) ще добави openvpn в runlevel 2,3,4,5, което с прости думи обяснено означава, че сървъра ще се пуска при инициализация на системата.

Сега е време да стартираме сървъра. Това може да стане или чрез рестарт на цялата система (което не се препоръчва разбира се) или по-лесният вариант е:

# service openvpn start

Ако всичко е наред, би трябвало сървъра да се инициализира, като това може да се проследи в log файла /var/log/openvpn, ако сме указали тази опция в конфигурацията.

Другият вариант, който може да използваме за debugging е да стартираме


# openvpn --verb --config /etc/openvpn/server.conf

Като това ще изпълни openvpn и ще изведе инициализиращите съобщения директно в терминала.

9/14/2010

OpenVPN в кратки стъпки [1]

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

1. Инсталираме openvpn пакета. В стандартната дистрибуция на Fedora 13 това става така:
# yum install openvpn
2. Създаваме директория, където ще се пазят инструментите за създаване на ключове и променливите.
# mkdir ~/easy-rsa
# mkdir ~/easy-rsa/keys

3. Копираме инструментите и някои стандартни файлове в директорията, която създадохме:
# cp /usr/share/openvpn/easy-rsa/2.0/* ~/easy-rsa
4. На този етап е хубаво да отворим файла vars за да променим аргументите на:
# cd ~/easy-rsa/
# cat vars

export KEY_COUNTRY=""
export KEY_PROVINCE=""
export KEY_CITY=""
export KEY_ORG=""
export KEY_EMAIL=""

/намират се най-долу на примерният файл/
5. Задаваме vars на обвивката за изпълнение:
# source vars
6. Почистваме за всеки случай:
# ./clean-all

=============================================

Така сме готови да създадем PKI (Public Key Infrastructure), която се състои от:

* отделен сертификат (публичен ключ) за сървъра и за всеки един клиент по отделно.
* главен Certificate Authority (CA) сертификат и ключ, с който се подписват всички други сертификати за сървъра и клиентите.

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

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

Как да генерираме тези сертификати и ключове?

1. Влизаме в директорията, където преместихме инструментите по-горе
# cd ~/easy-rsa
След това изпълняваме скрипта, който ще генерира Certificate Authority (CA) сертификат:
# ./build-ca
Ще ви бъдат зададени, няколко въпроса. Хубаво е да отбележим, че този скрипт взима аргументите на променливите от файла vars, който променихме по-горе, като единственото по-различно е Common Name, което трябва да въведем сами. При мен използвах: lateralus

Country Name (2 letter code) [BG]:
State or Province Name (full name) [SF]:
Locality Name (eg, city) [SOFIA]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []: lateralus
Email Address [me@myhost.mydomain]:


2. След това трябва да създадем сертификат и ключ за сървъра. За целта изпълняваме:

# ./build-key-server server

( На мястото на аргумента 'server' може да поставим каквото си поискаме ).
Повечето неща, може да ги пропусне, защото са по подразбиране. Единственото, което трябва да въведем сами е Common Name. Две функции, ще изискат потвърждение "Sign the certificate? [y/n]" и "1 out of 1 certificate requests certified, commit? [y/n]". Естествено потвърждаваме!

3. Следва да създадем сертификати и ключове за клиентите. Например за клиента homebox изпълняваме:

# ./build-key homebox

Ще ви бъдат зададени познатите въпроси, след което ще се генерират сертификат и ключ. Това трябва да се изпълни за всеки един клиент по-отделно като трябва да внимаваме да няма клиенти със едно и също име.

4. Генериране на Diffie-Hellman параметрите:

# ./build-dh

Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................


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