Всего по чуть чуть

AD+userAccountControl

2011-12-23T17:59:00.002+04:00

В своих записях про exim я довольно часто использую запросы к AD, и использую фильтр такого содержания !(userAccountControl:1.2.840.113556.1.4.803:=2)

В принципе я никогда не интересовался почему именно так, ведь можно проверить и так (userAccountControl=514), что должно работать, но как показывает практика, работает не всегда.

Занимаясь настройкой связки exim + AD я наталкивался на разные документации и в итоге пришел к выводу что используемый мной фильтр не отвечает всем требованиям которые я предъявляю к данной связке.

Для начала приведу здесь выдержки из статьи на сайте Microsoft

Формат LDAP подходящее правило имеет следующий синтаксис:

Имя_атрибута:ruleOID:=Значение

В данной команде Имя_атрибута является LDAPDisplayName атрибута ruleOID Это идентификатор объекта (OID) для соответствующего правила управления, и Значение десятичное значение, будет использоваться для сравнения. Необходимо преобразовать шестнадцатеричное десятичное.

Значение ruleOID может принимать одно из следующих:

1.2.840.113556.1.4.803 - Это правило LDAP_MATCHING_RULE_BIT_AND. Подходящее правило имеет значение true, только если все биты из свойства соответствует значению. Это правило имеет как оператор побитового И.

1.2.840.113556.1.4.804 - Это правило LDAP_MATCHING_RULE_BIT_OR. Подходящее правило имеет значение true, если все биты из свойства соответствует значению. Это правило аналогично побитовый оператор OR.

После прочтения этого, все более или менее становится понятно. Но остается вопрос что это за бит 2? И тут натыкаемся вот на такую статью.

Теперь вообще все супер.

Свой фильтр думаю переписать, что бы отслеживать состояние LOCKOUT!!

Всех с Наступающим Новым Годом!!!

Exim AD Groups and Users

2011-12-13T18:12:00.002+04:00

В предыдущей заметке я описал как сделать пересылку почты.

В этой же я приведу примеры запросов для проверки существования почтовго адреса в AD для пользователя и для почтовых рассылок, которые бадут базироваться на группах распространения.

Опять же все примеры указаны с приведенными ранее настройками.

Итак первое, и думаю самое важное это проверка на существование почты у пользователя. Почтовый адрес указывается в описании пользователя в поле e-mail. Дополнительные адреса добавляются через ADSIEdit в атрибут otherMailbox. Проверка выполняется вот в таком роутере

ad_user:
    driver    =    redirect
    allow_fail
    allow_defer
    forbid_pipe
    forbid_file
    domains    =    +local_domains
    data    =    ${lookup ldap{LDAP_QUERY_USER}{${local_part}@${domain}}{fail}}
    redirect_router    =    dovecot

Содержание запроса вот такое

LDAP_QUERY_USER    =    LDAP_CONN?mail?sub?(&(objectClass=user)(|(mail=${quote_ldap:${local_part}@${domain}})(otherMailbox=${quote_ldap:${local_part}@${domain}}))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(msExchUserAccountControl=0)))

Опять же, у меня здесь идет проверка на существование почты на сервере Exchange, поэтому и стоит проверка. Если у пользователя установлен или основной почтовый адрес или дополнительный равный адресу получателя, то роутеру dovecot будут передан адрес получателя, в противном случае будет пустое значение, которое приведет к тому что роутер не сработает.

Заодно приведу роутер dovecot, с его параметрами, что бы было более понятно

dovecot:
    driver    =    accept
    domains    =    +local_domains
    condition    =    ${lookup ldap{LDAP_QUERY_USER}{yes}{no}}
    transport    =    dovecot
    cannot_route_message    =    Unknow user ($local_part@$domain)

Ну и сам транспорт dovecot

dovecot:
    driver    =    pipe
    delivery_date_add
    envelope_to_add
    command    =    /usr/libexec/dovecot/deliver -d "${lookup ldap{LDAP_QUERY_DOVECOT_TRANSPORT}{$value}}"
    user    =    dovenull
    group    =    mail
    message_prefix    =    ""
    message_suffix    =    ""
    log_output

LDAP_QUERY_DOVECOT_TRANSPORT    =    LDAP_CONN?sAMAccountName?sub?(&(objectClass=user)(|(mail=${quote_ldap:${local_part}@${domain}})(otherMailbox=${quote_ldap:${local_part}@${domain}}))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Сам dovecot хранит почту для каждого пользователя в отдельном каталоге имеющем такое же имя как учетная запись пользователя.

Ну и после того как разобрались с пользователями можно приступить и к группам рассылки.

Группы рассылки создаются в AD как группы распространения, я создаю глобальные группы распространения, они имеют атрибут grouptype равным 2. Exchange при создании групп рассылки создает группы с типом, если не ошибаюсь равным 7. Аналогично в описании группы надо заполнить поле e-mail, и после чего добавить в группу пользователей. После чего можно смело отправлять письма. Роутер у меня вот такой, на самом деле это придумал не я, а нашел на просторах интернета

ad_group:
    driver    =    redirect
    domains    =    +local_domains
    allow_fail
    allow_defer
    data    =    ${sg\
                    {${map {<\n \
                                ${sg\
                                    {${lookup ldap{LDAP_QUERY_GROUP}}}\
                                    {\N, \N}\
                                    {\n}\
                                }\
                            }\
                            {\
                                ${lookup ldap{user=LDAP_USER pass=LDAP_PASS ldap:///${quote_ldapdn:$item}?mail?base?}}\
                            }\
                        }\
                    }\
                    {\N\n\N}\
                    {, }\
                }

ну и сам запрос
LDAP_QUERY_GROUP    =    LDAP_CONN?member?sub?(&(objectClass=group)(grouptype=2)(|(mail=${quote_ldap:${local_part}@${domain}})(proxyAddresses=smtp:${quote_ldap:${local_part}@${domain}})))

Дополнительные адреса для потчовой рассылки можно указать через ADSIEdit в атрибует proxyAddresses, т.к. у групп нет атрибута otherMailbox. Допольнительные адреса должны указываться в виде smtp:name@domain.ltd, для того что бы не поломать другие программы которые могут использовать этот атрибут с своих целях (Использует exchange, Microsoft communicator).

Ну вроде все.

exim ad mail forward

2011-11-28T18:38:00.001+04:00

В дальнейшем думаю что напишу больше про эту тему, а именно настройка exim+dovecot+AD с управлением потоками почты на основе записей в AD. Сейчас же для того что бы не забыть, оставляю себе памятку ну и не скрываю в тайнах.

Итак, есть сервер exim. Раньше он работал как relay на сервер Exchange, но потом было принято решение что Exchange дорого, да и не пользуются пользователи им на все его возможности. Оно и понятно, ведь половина пользователей сидят на Linux. было принято решение перейти на свободное ПО. Выбор пал на все тот же exim и dovecot. Ну и теперь есть задача организовать пересылку почты на другой почтовый ящик. Делается это все на exim очень просто, но я ленив, да и задумывая данную связку я хотел как можно меньше править конфиг exim, а больше администрировать его через AD.

Ну и с чего начать, конечно надо понять что хотим. В качестве желания я взял тот метод которым делается данное действие в MS Exchange 2007. А именно, там в настройках в параметрах потока почты, можно выбрать контакт или пользователя которому пересылать почту, ну и можно отметить галочку пересылки и сохранения в почтовом ящике. Меня это вполне устраивает. Немного покопавшись нашел в AD атрибуты отвечающие за данное действие. Итак, атрибут altrecipient. В нем указывается distinguished name контакта или пользователя, на адрес которого необходимо пересылать почту. Атрибут deliveryAndRedirect устанавливается в "true" если необходимо сохранять почту в почтовом ящике пользователя, если установлен в "false" или "not set", то, естественно, почту не сохраняем, а только пересылаем.

Вроде все что надо нашли. Теперь самое главное, надо написать условия для пересылки почты для exim. Если взять стандартный маршрут пересылки становится все понятно как работает логика. Также, необходимо не забывать что если в маршруте типа redirect, переменная data будет иметь пустую строку, то маршрут не сработает.

Теперь сформулируем правило работы что бы уже потом его перенести на язык программирования.

Если стоит флаг сохранять почту (deliverAndRedirect), то пересылать почту на почтовый адрес (altrecipient)и оставлять в почтовом ящике копию, в противном случае только пересылать почту на почтовый адрес (altrecipient). Если флаг не установлен deliveryAndRedirect и не установлен атрибут altrecipient, то выше приведенное условие вернет пустую строку. Здесь, также, надо не забыть проверить работу условия при установленном флаге сохранения почты и отсутствующем значении в атрибуте altrecipient. Если честно, то данную ветку я пока не проверял, но мне кажется, что здесь ничего страшного не произойдет.

Итак, вроде все есть, теперь осталось только написать все понятно для exim. И я приведу код маршрута после того как опишу пару переменных, которые облегчают понимание кода.

# Имя пользователя для авторизации в LDAP, в данном случае в AD

LDAP_USER=ldap_user@domain.ltd

# Пароль пользователя в LDAP

LDAP_PASS=ldap_password

# Имя домена в нотации LDAP, это корень откуда будет начинаться поиск

LDAP_BASE=dc=domain,dc=ltd

# Ну и что бы меньше писать в самом маршруте определим еще одну переменную

LDAP_CONN=user=LDAP_USER pass=LDAP_PASS ldap:///LDAP_BASE

ну и теперь сам маршрут

forward:
driver = redirect
allow_fail
allow_defer
domains = +local_domains
data = ${if eqi{\
${lookup ldap{LDAP_CONN?deliverAndRedirect?sub?(&(objectClass=user)(|(mail=${quote_ldap:${local_part}@${domain}})(otherMailbox=${quote_ldap:${local_part}@${domain}}))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(msExchUserAccountControl=0))(altrecipient=*))}}}\
{true}\
{${map\
{${lookup ldap{LDAP_CONN?altrecipient?sub?(&(objectClass=user)(|(mail=${quote_ldap:${local_part}@${domain}})(otherMailbox=${quote_ldap:${local_part}@${domain}}))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(msExchUserAccountControl=0))(altrecipient=*))}}}\
{${lookup ldap{user=LDAP_USER pass=LDAP_PASS ldap:///${quote_ldapdn:$item}?mail?base?}}}},$local_part@$domain}\
{${map\
{${lookup ldap{LDAP_CONN?altrecipient?sub?(&(objectClass=user)(|(mail=${quote_ldap:${local_part}@${domain}})(otherMailbox=${quote_ldap:${local_part}@${domain}}))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(msExchUserAccountControl=0))(altrecipient=*))}}}\
{${lookup ldap{user=LDAP_USER pass=LDAP_PASS ldap:///${quote_ldapdn:$item}?mail?base?}}}}\
}\
}

В данном примере у меня есть проверка атрибута msExchUserAccountControl, это условие мне необходимо для того что бы отличать пользователей которые пока еще работают с MS Exhcnage, и тех которые уже работают с dovecot.

Есть конечно во всем этом один минус, если в качестве altrecipient указан distinguished name другого пользователя, а у того, в свою очередь, в этом атрибуте указан distinguished name пользователя которому изначально посылалось письмо, то может возникнуть петля. Работу в этом режиме я пока не проверял. В MS Exchange это решается установкой атрибута altrecipientBL почтового контакта или пользователя в distinguished name пользователя от которого идет пересылка.

Надеюсь заметка оказалась кому-нибудь полезной, ну и конечно понятной. Я сам прихожу в ужас от данного условия.

racoon openswan

2011-11-15T22:19:00.000+04:00

Давно ничего не писал. Думаю, правда, никто и не заметил.
Вообщем тут подумал и решил для себя все таки пару заметок сделать, вдруг потом забуду.
Предисловие.
После выхода CentOS6 я почти сразу нашел стенд для того что бы установить данную ОС и посмотреть что де нового в ней было сделано. И обнаружил много довольно интересного. И одно новшество заставило меня немного покопаться в документации и почитать про это чудо. Ранее настраивая ipsec для связи своих территорий я использовал входящий в состав CentOS 5 пакет
ipsec-tools. Для организации ipsec использовался racoon, который стараниями команды разработчиков довольно быстро настраивался через системные конфигурационные файлы. Почитать можно в /usr/share/doc/initscripts-$version/sysconfig.txt. Ну а примеры я вроде у себя в блоге приводил. В CentOS 6 разработчики перешли к использованию пакета openswan, и мне кажется что не зря. Поэтому пришлось его немного повертеть и понять что почем. Мне кажется что для решения большинства задач хватит и racoon, но вот если надо более гибкое решение, то openswan отлично для этого подходит. В реализации скриптов для CentOS 5 мне так и не удалось заставить их организовывать шифрование только gre трафика между двумя хостами, только все или ничего. Openswan же позволяет более гибче управлять тем какой трафик шифровать, а какой нет.
Ну вообщем было принято решение переходить на openswan, тем более что новая площадка уже использовала CentOS 6. В итоге все было настроено, проверено и введено в эксплуатацию. Кроме одной удаленной площадки, где доступ к системе я не имею. На той удаленной площадке используется CentOS 5 и естественно racoon. Поставить туда openswan удалось но вот запустить его не получилось. Почему то при запуске он сыпет в лог и консоль ошибку о том что используется неправильный параметр запуска ipsec_setup, ну и дальше уже ничего не работает. Пришлось вязать между собой racoon и openswan. Решение оказалось довольно банальным и простым, но все же лучше написать как и что. Что самое интересное что пока писал, понял из-за чего не работало с самого начала.
Решение.
Конфиг ipsec со стороны CentOS 5 (racoon, не забываем что он сгенерится сам)
/etc/sysconfig/network-scripts/ifcfg-ipsec
TYPE=IPSEC
SRC=x.x.x.x
DST=y.y.y.y
IKE_METHOD=PSK
ONBOOT=no
не привожу файл с ключем

Конфиг со стороны CentOS6 (openswan)
/etc/ipsec.d/ipsec.conf
conn ipsec
type=transport
authby=secret
right=x.x.x.x
left=y.y.y.y
auto=start
salifetime=3600s
pfs=yes
ike=3des-sha1-modp1024
keyexchange=ike

Это то что в принципе устраивает большинство, но вот работать оно не будет. ТО что помогло мне на 100% это добавить в файл настроек на CentOS5 такую строку
AH_PROTO=none
после чего все заработало, хотя по логам racoon на тестовом стенде я видел что не хватает протокола AH но не сообразил почему.
Только при написании в блоге я понял что в настройках openswan по умолчанию для CentOS 6 прописан такой параметр

nat_traversal=yes

который и отключает AH протокол.

Ну вроде и все. Кстати сам совет отключить AH нашел на форуме, но вот ссылку дать не могу, ибо забыл.

Вроде все.

Cron mutt и русские символы

2010-04-01T15:09:00.000+04:00

Случилась ситуация что надо настроить отправку писем через cron которая должна происходить в последний день месяца и отсылать почту с русскими буквами в теме письма. Т.к. необходимо было отсылать файл то использовал для отсылки утилиту mutt

ну и вот что получилось в итоге
/var/spool/cron/root
23 50 28,29,30,31 * * /root/bin/script.sh

/root/bin/script.sh
#!/bin/sh

TMP="/tmp/tmp"`date +%F`".pdf"
MAILTO="mail@mail.man"
if [ `date -d "1 day" "+%d"` = "01" ]; then
    if [ -f $TMP ];then
         rm -f $TMP
    fi
    command > $TMP
    LANG=en_US.UTF-8 mutt -a $TMP -s "Отчет чего то там" ${MAILTO} < /dev/null
    rm -f $TMP
fi

Ну вот вроде и все.
У меня на CentOS5.4 работает.

*Кстати без опции LANG=en_US.UTF8 в тему письма ничего не пишется если есть русские буквы.

OSPF, IPSEC, gre, CentOS, Cisco

2010-03-03T18:52:00.001+03:00

"Начал писать данный пост давно, еще 3 октября 2010 года, но так и не закончил. Хочу опубликовать хоть в таком виде. Может все таки руки доберутся его до конца дописать. Хочу сказать сразу. Схема реализована и работает, правда уже все на Cisco, поэтому скорее всего конфиги немного изменились.

Введение

Я понимаю что в Интернете уже много написано как все настроить и т.п. Но свое все таки надо тоже держать.

Итак о чем я хочу написать?

Встала необходимость связать два офиса не только каналом точка-точка но и также резервировать этот канал посредством сети Интернет. Задача которая ничего особенного из себя не представляет. Все делается просто и куча документации есть. Но при настройке в первые приходится много изучать и понимать. Так немного попробую разжевать все что использовалось в настройке.

Входные данные

Определимся что и с чем будем связывать (рис.1).

Итак есть сети:
LLAN1 - 192.168.101.0/24
LLAN2 - 192.168.102.0/24
LDMZ - 10.101.1.0/24
RLAN1 - 192.168.200.0/21
PLAN - 172.16.1.0/24
RDMZ - 10.101.2.0/24

Сразу приведу расшифровку названий сетей:
LLAN1 - Left LAN 1
LLAN2 - Left LAN 2
LDMZ - Left DMZ
RLAN1 - Right LAN 1
PLAN - Private LAN
RDMZ - Right DMZ

Ну и аналогично получается для названия маршрутизаторов:
LGW1 - Left Gateway 1
LGW2 - Left Gateway 2
RGW1 - Right Gateway 1

Теперь надо определиться с интерфейсами и адресами шлюзов

LGW1
eth0 - 1.1.1.1/30 (Internet)
eth1 - 10.101.1.1/24 (LDMZ)

LGW2
eth0 - 10.101.1.2/24 (LDMZ)
eth1 - 192.168.101.1/24 (LLAN1)
eth2 - 192.168.102.1/24 (LLAN2)
eth3 - 192.168.150.1/24 (PtP)

RGW1
eth0 - 2.2.2.2/30 (Internet)
eth1 - 10.101.2.1/24 (RDMZ)

Естественно все маршрутизаторы построены с использованием ОС CentOS5.

Cisco 2851
(Ну вот по поводу Cisco, то здесь у меня есть один минус - не я ее настраивал. Поэтому все что смогу то тут выложу. )
VLAN2 - 10.101.2.2/24 (RDMZ)
VLAN3 - 172.16.1.1/24 (PLAN1)
VLAN4 - 192.168.250.2/24 (PtP)
VLAN1 - 192.168.200.1/24 (RLAN1)

Постановка задачи

Ну вот вроде определились с сетями и IP адресами. Теперь ставим задачи.

1. Необходимо организовать связь между двумя территориями
2. Обеспечить шифрование
3. Обеспечить отказоустойчивость
4. Ну и также надо сделать так что бы минимизировать время на обслуживание

Выбор инструментов для решения задач
1. Связь уже имеется посредством канала PtP, но также в контексте 3 задачи надо рассмотреть связь и через интернет
2. Здесь выбор пал на IPSec. IPSec будет работать в транспортном режиме т.к. если использовать туннельный режим то использование OSPF становится просто ненужным.
3. Отказоустойчивость можно организовать многими методами, но здесь был выбран протокол динамической маршрутизации OSPF. Он кстати и также решает еще и 4 задачу т.к. при увеличении подключенных территорий, и увеличении каналов доступа, сокращает время настройки маршрутов и также позволяет легко добавлять новые сети к существующим.

Настройка.

Приступим к настройке.
Сначала начнем с простого и будем соединять наши сети посредством канала PtP.

LGW2
/etc/sysconfig/network-scrips/ifcfg-ipsec0

ONBOOT=yes
TYPE=IPSEC
SRC=192.168.150.1
DST=192.168.250.2

IKE_METHOD=PSK

Здесь используется метод с использование парольной фразы, что не является довольно безопасным методом, но как связать Cisco и CentOS посредством сертификатов X.509 я так и не разобрался. Если кто-то имел дело с настройкой и есть желание поделиться, то всегда Welcome.

/etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK=qwerty

Такая короткая парольная фраза только для примера.

!!!!!! Кстати, если уж у нас канал точка-точка то наверное тут было бы лучше использовать адреса из одной сети, вернее так и делает большинство, но в моей конкретной задаче была конфигурация именно с разными сетями на концах канала. Поэтому не мешало бы создать файл /etc/sysconfig/network-scripts/route-eth3 такого содержания

192.168.250.0/24 via 192.168.150.1 dev eth3

С другой стороны на Cisco прописываем

ip route add 192.168.150.0 255.255.255.0 192.168.250.2

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key qwerty address 192.168.150.1 no-xauth

crypto ipsec transform-set my_transform_set ah-sha-hmac esp-3des esp-sha-hmac
mode transport

crypto map SDM_CMAP_1 1 ipsec-isakmp
description $Tunnel to192.168.150.1$
set peer 192.168.150.1
set transform-set my_transform_set
set pfs group2
match address 100

access-list 100 remark SDM_ACL Category=4
access-list 100 permit ip host 192.168.250.2 host 192.168.150.1
access-list 100 permit ip host 192.168.150.1 host 192.168.250.2

Далее необходимо настроить туннели поверх настроенного IPSec.

LGW2
/etc/sysconfig/network-scripts/ifcfg-gre1 (Именно 1 т.к. я использую в названиии файла имя устройства, а gre туннели должны начинаться с 1 т.к. 0 уже занят)
TYPE=GRE
ONBOOT=yes
DEVICE=ppp0
MY_INNER_IPADDR=192.168.254.253
MY_OUTER_IPADDR=192.168.150.1
PEER_INNER_IPADDR=192.168.254.254
PEER_OUTER_IPADDR=192.168.250.2
MTU=1420
TTL=64

После поднятия интерфейса у нас появится новое сетевое устройство под именем ppp0. Опять же, в моем примере надо было сохранить совместимость со старой конфигурацией, и не хотелось переписывать кучу правил iptables.

Cisco
interface Tunnel0
description $GRE MAIN$
ip address 192.168.254.254 255.255.255.252
ip access-group sdm_tunnel0_in in
ip mtu 1420
ip tcp adjust-mss 1400
tunnel source Vlan4
tunnel destination 192.168.150.1
tunnel path-mtu-discovery
crypto map SDM_CMAP_1
crypto ipsec df-bit clear

После всего этого необходимо проверить работоспособность выполнив на LGW2 команды

ifup ipsec0
ifup gre1
ping 192.168.254.254

Если ничего не получилось то стоит проверить есть проходят ли пакеты по IPSec без gre

ping 192.168.250.2

Ну и если после этого не заработало то остается только смотреть логи и смотреть правила iptables. На LGW2 они должны быть такого рода

iptables -A INPUT -i eth3 -p udp -s 192.168.250.2 -d 192.168.150.1 -m state --state NEW --dport 500 -j ACCEPT
iptables -A INPUT -i eth3 -p esp -s 192.168.250.2 -d 192.168.150.1 -j ACCEPT
iptables -A INPUT -i eth3 -p ah -s 192.168.250.2 -d 192.168.150.1 -j ACCEPT

У меня с такими правилами все заработало. Хотя может и стоило еще прописать правило для gre протокола.
Со стороны Cisco по данному вопросу ничего сказать не могу.

Если все заработало, то можно попробовать настроить или резервный канал или поднять OSPF. В моем случае я выбрал второй вариант т.к. после поднятия резервного канала вся настройка OSPF будет сводиться к тому что бы прописать в нем еще один дополнительный интерфейс и вес.

LGW2
За протокол OSPF у нас будет отвечать программное обеспечени quagga. Ставим его.
yum install quagga
Далее правим файл /etc/quagga/zebra.conf

hostname lgw2
password pass
log file /var/log/quagga/zebra.log

Этого достаточно, но в целях повышения безопасности советую прочитать документацию.

Далее файл /etc/quagga/ospfd.conf

hostname lgw2
password pass
interface ppp0
ip ospf cost 10
ip ospf priority 10
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 Kakoi_nibud_parol
!
router ospf
ospf router-id 10.101.1.2
network 192.168.254.253/32 area 0
!!! Только сети подключенные к данному маршрутизатору физически будут !!! публиковаться через OSPF, и то только те которые будут удволетворять !!! условиям прописанным в route-map OSPF-connected
redistribute connected route-map OSPF-connected
area 0 authentication message-digest
!
!!! Создаем список с сетями которые хотим публиковать
ip prefix-list OSPF-conn permit 10.101.1.0/24
ip prefix-list OSPF-conn permit 192.168.101.0/24
ip prefix-list OSPF-conn permit 192.168.102.0/24
ip prefix-list OSPF-conn deny any
!
!!! Объявляем route-map и указываем каким списком руководствоваться
route-map OSPF-connected permit 1
match ip address prefix-list OSPF-conn
!
log file /var/log/quagga/ospfd.log

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

После проделанных манипуляций выполняем команды

chkconfig zebra on
chkconfig ospfd on
service zebra start
service ospfd start

И смотрим логи на предмет ошибок. Если их нет значит все отлично. Но только даже если настроить на Cisco OSPF, у нас ничего не заработает т.к. (опять же в контексте моей задачи) включены правила iptables которые не разрешают прохождение пакетов. Значит надо прописать правила которые будут разрешать. Ничего более изящного я не придумал так что принимайте вот такое правило

iptables -A INPUT -i ppp0 -p ospf -j ACCEPT
(Здесь может быть я потом добавлю доп. правила iptables которые будут более жесткие, но сейчас они пока такие. Опять же хоть я и прописывал при настройке жестко использовать интерфейс p2p, но все равно пакеты идут на широковещательные адреса)

Теперь приведу настройки Cisco

interface Tunnel0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 7 здесь_будет_хэш
ip ospf cost 10
ip ospf priority 10
ip ospf mtu-ignore

interface Loopback0
description $OSPF 1$
ip address 22.22.22.22 255.255.255.255

router ospf 22
area 0 authentication message-digest
redistribute connected route-map TO-OSPF
network 192.168.254.254 0.0.0.0 area 0

route-map TO-OSPF permit 10
match ip address prefix-list ospf-new

! Создаем список с сетями которые хотим публиковать
ip prefix-list ospf-new seq 10 permit 10.101.2.0/24
ip prefix-list ospf-new seq 20 permit 192.168.200.0/24
! Здесь мы должны явно указать какую сеть не надо публиковать
ip prefix-list ospf-new seq 30 deny 172.16.1.0/24

Если у кого то возникнут вопросы, то здесь я ничем не могу Вам помочь, потому что сам не знаю ответы на многие вопросы. Для меня остается загадкой для чего нужен интерфейс Loopback0 с адресом 22.22.22.22/32, но в документации к Cisco указано что лучше его использовать. Также в prefix-list насколько я понял нельзя прописать правило deny any, поэтому здесь приходится прописывать все намного жестче.
Ну теперь у нас вроде все настроено и должно все работать.
Я не буду отвлекаться и подробно рассказывать как отыскать ошибки или проверить работоспособность, у меня заработало все не сразу но потом все получилось, Скажу лишь что основными командами были
telnet localhost ospfd
и
ip route

После всех проделанных манипуляций на обоих хостах должны появиться маршруты прописанные в настройках OSPF.

Также сделаю небольшое отступление и немного опишу процедуру публикации маршрута вида static. На Cisco это делается довольно просто, там особо ничего и прописывать не надо, то есть все также как и в приведенном примере, только не redistribute connected, а надо прописать redistribute static, ну и естественно также прописываем route-map и т.п. где указываем какие маршруты будем публиковать. Ну и самое главное это прописываем этот маршрут на Cisco с помощью ip route. Ну и радуемся. В quagga все немного по другому. Настройка OSPF аналогична как и у Cisco, но вот только если мы добавим маршрут с помощью команды ip route add или route, то этот маршрут не будет публиковаться. Для решения данной проблемы я лично потратил около половины дня, а все из-за того что не читал внимательно документацию. Оказалось все просто. Для того что бы данный маршрут начал публиковаться его надо удалить из таблицы маршрутизации ядра. После чего прописать маршрут в zebra, или в файле конфигурации /etc/quagga/zebra.conf или с помощью telnet localhost zebra.

Ну вот вроде бы и закончено с настройкой основного канала. Теперь можно приступить к настройке резервного.
Здесь как и в случае основного ничего нет сложного, есть только небольшое отличие. Создавать IPSec соединение нам придется уже не на LGW2 и Cisco, а на LGW1 и RGW1. А вот gre туннель как раз на LGW2 и Cisco.
Сначала настроим IPSec.

LGW1

/etc/sysconfig/network-scrips/ifcfg-ipsec0

ONBOOT=yes

TYPE=IPSEC

SRC=1.1.1.1

DST=2.2.2.2

IKE_METHOD=PSK

/etc/sysconfig/network-scripts/keys-ipsec0

IKE_PSK=qwerty

Ну и аналогично на

RGW1

/etc/sysconfig/network-scrips/ifcfg-ipsec0

ONBOOT=yes

TYPE=IPSEC

SRC=2.2.2.2

DST=1.1.1.1

IKE_METHOD=PSK

/etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK=qwerty

После чего необходимо прописать правила для iptables на каждом из хостов и поднять интерфейсы командой ifup ipsec0.

Видим что все работает и радуемся. Теперь самое дело приступить к настройке gre туннеля на LGW2 и Cisco. Начнем настройку с добавлении правил iptables на LGW1 и RGW1.

LGW1

iptables -A PREROUTING -t nat -i eth0 -s 2.2.2.2 -d 1.1.1.1 -p gre -j DNAT --to-destination 10.101.1.2

iptables -A FORWARD -p gre -s 2.2.2.2 -d 10.101.1.2 -i eth0 -o eth1 -j ACCEPT

RGW1

iptables -A PREROUTING -t nat -i eth0 -s 1.1.1.1 -d 2.2.2.2 -p gre -j DNAT --to-destination 10.101.2.2

iptables -A FORWARD -p gre -s 1.1.1.1 -d 10.101.2.2 -i eth0 -o eth1 -j ACCEPT

Ну и теперь настроим gre

LGW2

/etc/sysconfig/network-scripts/ifcfg-gre2

TYPE=GRE

ONBOOT=yes

DEVICE=ppp1

MY_INNER_IPADDR=192.168.253.253

MY_OUTER_IPADDR=10.101.1.2

PEER_INNER_IPADDR=192.168.253.254

PEER_OUTER_IPADDR=2.2.2.2

MTU=1420

TTL=64

Ну и самое главное теперь прописать настройки OSPF.

LGW2

в /etc/quagga/ospfd.conf добавляем после описания интерфейса ppp0 вот такие строки

interface ppp1

ip ospf cost 20

ip ospf priority 20

ip ospf authentication message-digest

ip ospf message-digest-key 1 md5 Kakoi_nibud_parol

И в секцию router добавляем строку

network 192.168.254.253/32 area 0

после чего можно перезапустить ospfd.

CentOS и заметки себе как поправить мелочи

2010-03-03T18:20:00.000+03:00

Здесь я периодически буду добавлять всякие мелочи связанные с ОС CentOS.
1. Отключить поддержку IPV6
Если прописать в /etc/sysconfig/network
NETWORKING_IPV6=no
то как ни странно, адреса IPV6 будут висеть на интерфейсах.
Также если добавить
IPV6INIT=no
в файл настройки интерфейса, то это тоже не помогает, хотя может и помогает после перезагрузки, но меня это не удовлетворило.
В итоге покопавшись в интернете нашел в официальном FAQ как его отключить совсем. Вот что там пишут касательно CentOS5

touch /etc/modprobe.d/disable-ipv6
echo "options ipv6 disable=1" >> /etc/modprobe.d/disable-ipv6

После чего делаем reboot и спокойно работаем.

2. Отключить ZEROCONF
Вообще я даже как-то не озадачивался этим вопросом, да и в документации видел данную опцию, но не придал значения ей. Читая Блог Dormestmass' blog обратил на него внимание и проделал описанные действия. А именно прописать в /etc/sysconfig/network

NOZEROCONF=yes

ну и потом service network restart

3. Прописать правила iproute
В документации в принципе все есть, но опять же в самом конце и не всегда можно сразу вспомнить. То что прописывать маршруты можно в файлах

/etc/sysconfig/static-routes
/etc/sysconfig/network-scripts/route-ethX

это в принципе известно. Но вот как добавить правила для iproute, я тоже сразу не нашел. Оказывается все банально просто. Прописываем строки вида

from IP1 table TABLES1

в файл

/etc/sysconfig/network-scripts/rule-ethX

IPSec и немного о нем

2010-02-01T11:53:00.000+03:00

Хотя навряд-ли я это уже когда нибудь забуду но все же.
Сейчас на работе приходится настраивать связку IPSEC + GRE, в принципе ничего сложного, тем более что настройка производится в дистрибутиве CentOS 5. Как и показано в документации все делается довольно просто и быстро. Но все же.
Началось все с того что мне надоели постоянные падения VPN канала между двумя территориями. Данный VPN канал организован при помощи PPP over SSH, и все бы хорошо у данного метода, но перезапуск при падении производится с помощью cron раз в 5 минут запуском скрипта который проверяет состояние канала, делая проверку наличия маршрута в таблице маршрутизации. Многие могут сказать что просто я не умею его (PPP over SSH) готовить, но мне как-то не очень интересно заниматься этим. да и все равно со временем граничные маршрутизаторы будут заменены на Cisco. И поэтому решил заняться IPSec.
Приступая к работе я не думал что придется ломать голову над чем то, тем более при таком обилии документации как на русском так и на ангийском, но вопросы все таки появились.
Первый это почему при поднятии IPSec у меня не появлялся интерфейс ipsec0 который я прописывал. Немного покопав и подумав я понял что он и не должен подниматься. Но нужно было как то заворачивать трафик на него. Опять покопавшись в интернете я ничего не нашел по linux, но зато нашел немного про Cisco. После чего было принято решение поднять gre over ipsec. Что было и сделано. После чего все нормально заработало.
Ну теперь немного конфигов и картинок.

Из рисунка видно что имеется два граничных маршрутизатора связанных посредством интернета. Каждый маршрутизатор обеспечивает свои сети. Для наглядности я дал имена сетям латинскими буквами A,B,C,D,E. Приставки L или R я добавил что бы было легче понимать где сеть находится, справа или слева. Соответственно маршрутизаторы я назвал просто GW, а приставки обозначают с какой стороны находится маршрутизатор.
Интерфейс для доступа в интернет у маршрутизатора LGW - eth0, у RGW - eth1. IP адреса интерфейсов 190.190.190.250/24 и 191.191.191.251/24 соответственно.
Файлы настроек для LGW:
/etc/sysconfig/network-scripts/ifcfg-ipsec0
ONBOOT=YES
TYPE=IPSEC
DST=191.191.191.251
IKE_METHOD=PSK
/etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK=ABCDEFGH

Файлы настроек для RGW:
/etc/sysconfig/network-scripts/ifcfg-ipsec1
ONBOOT=YES
TYPE=IPSEC
DST=190.190.190.250
IKE_METHOD=PSK
/etc/sysconfig/network-scripts/keys-ipsec1
IKE_PSK=ABCDEFGH

Я использую простую защиту по парольной фразе для наглядности и экспериментов, при вводе в эксплуатацию будет использован метод с сертификатами. (Заметка: здесь используется конфигурация ipsec точка-точка).
После чего можно поднять ipsec с помощью команд ifup ipsec0 и ifup ipsec1.
И попробовать выполнить команду ping до другого маршрутизатора. Если все нормально то можно перейти дальше, если же нет то советую проверить правильность настроек и попробовать заново.
Дальше нужно настроить GRE, делается это так же просто как и IPSec.
Файл настроек для LGW:

/etc/sysconfig/network-scripts/ifcfg-gre2
ONBOOT=YES
DEVICE=gre2
MY_INNER_IPADDR=192.168.254.253 # Внутренний адрес туннеля
MY_OUTER_IPADDR=190.190.190.250 # Внешний адрес на котором будем создавать туннель
PEER_INNER_IPADDR=192.168.254.254 # Внутренний адрес туннеля с другой стороны
PEER_OUTER_IPADDR=191.191.191.251 # Внешний адрес куда будет создаваться туннель

Файл настроек для RGW:

/etc/sysconfig/network-scripts/ifcfg-gre2
ONBOOT=YES
DEVICE=gre2

MY_INNER_IPADDR=192.168.254.254
MY_OUTER_IPADDR=191.191.191.251
PEER_INNER_IPADDR=192.168.254.253 PEER_OUTER_IPADDR=190.190.190.250

Ну и можно выполнить ifup gre2.
Теперь должен будет появиться интерфейс gre2 на обоих маршрутизаторах, после чего можно прописывать маршруты в сети A,B,C,D,E.

В продолжении попытаюсь рассказать о настройке второго канала gre + ipsec между этими же двумя маршрутизаторами и настройки ospf для переключения между двумя каналами.

Первый

2010-01-31T17:30:00.000+03:00

Всем посетителям хорошего настроения!
Это моя первая запись в блоге, и если честно я, как и многие другие, просто не знаю о чем написать. Может быть я поддался тенденциям нашего времени на ведения блогов или просто блог мне нужен, я пока еще не определился. Но точно знаю что данный блог я не буду вести часто и думаю что скорее всего иногда буду делиться своими заметками связанными с работой. И скорее всего они будут связаны с ОС linux.