LINUX.ORG.RU
ФорумAdmin

OSPF в Quagga на несколько сетей

 , , , ,


0

2

Дорбый день всем. Будет большое описание сети, чтобы было понятно, что к чему. Но суть вопроса в конце поста.

Есть примерно такая схема сети (упрощенно): http://i61.tinypic.com/21kkyfa.png

С левой стороны схемы как-бы основная часть сети. Назовем основную сеть MainNET, где в основном маршрутизаторы/свитчи с OSPF. На схемке показан для простоты один такой OSPF Router.

В центре «OpenVPN Server», на нём также работает quagga с ospfd. eth0 подключен к MainNET, eth1 = выход в Инет и соотв. через инет к нему подключаются клиенты.

Сеть OpenVPN настроена режиме tls-server с опцией client-to-client, т.е. все клиенты видят друг друга и сети за ними разрешены через статические маршруты (клиенты OpenVPN в т.ч. маршрутизируют трафик из/в VPN). Сеть 192.168.254.X/24 является соб-но «виртуальной» сетью для OpenVPN интерфейсов tap0.

Чтобы трафик роутился на сервере статически (через хелперы скриптов OpenVPN) прописываются маршруты вида 10.1.1.X/24 via 192.168.254.101. В свою очередь на клиенте прописаны статически (на деле передается от сервера через OpenVPN push, но это не меняет сути) маршруты в MainNET и прочие сети (за OSPF Router) через 192.168.254.1 (т.е. сервер OpenVPN).

Всё это вполне работает, смысл такого гибрида OSPF/статические маршруты исторический.

Столкнулись с 2мя неудобствами в данной схеме - для изменения маршрутов у клиента нужно перезапускать клиента после изменения конфига. Ну и главное - у OpenVPN ограничение на размер PUSH сообщений жестко хардкоден, и нам стало не хватать этого места.

Планируется на клиентах OpenVPN поднять quagga где это возможно и маршрутами обмениваться через OSPF.

В «левой» части схемы поднял и настроил ospfd без проблем, а вот добавить новые зоны «за VPN» - почему-то проблема. Когда в конфиг ospfd.conf на OpenVPN сервере добавляю сеть 192.168.254.X/24 для анонса, то он перестает анонсировать сети за VPN (redistribute static):

interface eth0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 КЛЮЧИК
!
interface eth1
!
interface tap0
 ip ospf authentication message-digest
 ip ospf message-digest-key 2 md5 КЛЮЧИК
!
router ospf
 ospf router-id 192.168.0.1
 redistribute kernel
 redistribute connected
 redistribute static
 network 192.168.0.0/24 area 0.0.0.0
! network 192.168.254.0/24 area 0.0.0.254
 distribute-list filter out kernel
 distribute-list filter out connected
 distribute-list filter out static
!
access-list 1 deny 192.168.253.0 0.0.0.255
access-list 1 deny 192.168.252.0 0.0.0.255
access-list 1 permit any
access-list filter deny 192.168.252.0/24
access-list filter deny 192.168.253.0/24
access-list filter deny 169.254.0.0/16
access-list filter permit any
!

Сети 192.168.252-253 просто специально фильтруются. Стоит раскомментировать строчку "! network 192.168.254.0/24 area 0.0.0.254" и он перестает распространять свои статические маршруты на OSPF Router. Соб-но вида «10.1.1.0/24 via 192.168.254.101», из ядра, которые туда записаны хелпером OpenVPN (через ip route add ...).

Т.е. пока этой строки нет, на OSPF Router я вижу маршруты, которые передает OpenVPN Server из своего ядра. Как только эта строка добавляется, почему-то он перестает их распространять. Видимо из-за того, что они соб-но и находятся за сетью 192.168.254.0/24. Но как быть, когда мне надо раздавать маршруты в «обе стороны»?

PS: Блин как же много написал... так всегда, когда проблему хочешь подробно описать...



Последнее исправление: nstorm (всего исправлений: 1)

Так, для начала избавься от статики. Мешать это следует только в крайних случаях (например, есть роутер не умеющий OSPF), в остальных - нужно оставить только динамику.

Во вторых, сходи почитай про терминологию OSPF и вообще про него.

К примеру, если нужно анонсировать сеть, за которой нет роутеров, то просто добавь ее как STUB в конфиг, не надо редистрибутить статику.

У меня есть тоже некий сервер OpenVPN и некоторый набор клиентов к нему (в основном - неттопы с йотой), за которыми локалки свои стоят.

Вот конфиг кваги с сервера, всё тупо и просто:

hostname ovpn.domain.ru
password zebra
enable password zebra

interface vlan8
    ip ospf authentication message-digest
    ip ospf message-digest-key 1 md5 xxxx
    ip ospf hello-interval 1
    ip ospf dead-interval 3
    ip ospf priority 99
    ip ospf cost 10

interface tap0
    ip ospf authentication message-digest
    ip ospf message-digest-key 1 md5 xxxx
    ip ospf hello-interval 10
    ip ospf dead-interval 40
    ip ospf priority 99
    ip ospf cost 40
    ip ospf network broadcast

router ospf
    log-adjacency-changes
    ospf router-id 10.1.16.18
    network 10.1.16.0/24 area 0
    network 10.254.222.0/24 area 0
    area 0 authentication message-digest
tap0 смотрит на впн клиентов, vlan8 в основную сеть с другими роутерами.

У клиентов аналогично, только их сети помечены как стаб и всё.

blind_oracle ★★★★★
()

Тут возможна засада, связанная с OpenVPN.
http://www.lissyara.su/doc/man/safety/openvpn/

Читать, начиная с

# Чтобы назначить специфический IP адрес
# специфическому клиенты или если за клиентом
# располагается подсеть, которая тоже использует эту VPN,
# используйте поддиректирию «ccd» для хранения специфических

То есть, простого ip route add на нужном хосте не хватает - не работает оно. Не знаю, справится ли с этим quagga...

AS ★★★★★
()
Ответ на: комментарий от blind_oracle

У меня есть тоже некий сервер OpenVPN и некоторый набор клиентов к
нему (в основном - неттопы с йотой), за которыми локалки свои стоят.

Хотя, вот это похоже на данный случай, который опасение у меня вызывает...

AS ★★★★★
()
Ответ на: комментарий от AS

Ну я ccd и юзаю, в них у меня файлики с именами такими же как и CN сертификатов у клиентов. Там им айпи адреса и пушатся.

А дальше уже квагга работает поверх этого без проблем.

Есть еще более «простой» способ - юзать p2p openvpn соединения, а не p2mp как по умолчанию. Тогда вообще никаких проблем - два конца туннеля в /30 или /31 сети и между ними OSPF.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Там им айпи адреса и пушатся.

Это понятно, но там про маршрутизацию на сети за клиентами. То есть, если на OpenVPN сервере сделать

ip route add <net/cidr> via <ip клиента>

оно не работает. Ну или я не нашёл, как его правильно пнуть. Вот, кстати, что я не сделал - это не посмотрел, в тот момент, что получилось при использовании ccd в маршрутах. Надо будет повторить опыт, может, будет понятно, почему с ip route не вышло.

Есть еще более «простой» способ - юзать p2p openvpn соединения

А вот это да, должно получиться. До варианта p2p я у OpenVPN не дочитал.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

оно не работает. Ну или я не нашёл, как его правильно пнуть. Вот, кстати, что я не сделал - это не посмотрел, в тот момент, что получилось при использовании ccd в маршрутах. Надо будет повторить опыт, может, будет понятно, почему с ip route не вышло.

Не вышло потому, что у OpenVPN внутренний мультиплексор, который разруливает траффик. А <ip клиента> у тебя нигде нет, он скрыт за туннельным p2p-интерфейсом tun/tap (который на самом деле p2mp) и поэтому роутинг через него пойти не могёт.

А p2p отлично работает и настраивается с полпинка, как-то так:

dev tap0
nobind
remote x.x.x.x 1194
proto udp
topology p2p

mlock
nice -19
fast-io

ifconfig 192.168.254.4 192.168.254.3

mtu-disc maybe
tun-mtu 1500
fragment 1400
mssfix 1400

keepalive 10 120

secret /etc/openvpn/openvpn.key

auth SHA1
cipher AES-128-CBC

user root
group root

persist-key
persist-tun

verb 3
Юзать tap, на мой взгляд, лучше т.к. точно не будет проблем с роутинговыми протоколами, которые работают по мультикасту (тот же OSPF).

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Не вышло потому, что у OpenVPN внутренний мультиплексор, который разруливает
траффик. А <ip клиента> у тебя нигде нет, он скрыт за туннельным
p2p-интерфейсом tun/tap (который на самом деле p2mp) и поэтому роутинг
через него пойти не могёт.

В общем, я примерно так и понял, потому и предупредил, что там не всё так просто. И удивился, что оно заработало, потому как про p2p у OpenVPN не дочитал.

Юзать tap, на мой взгляд, лучше т.к. точно не будет проблем с роутинговыми
протоколами, которые работают по мультикасту (тот же OSPF).

Зато трафика летит больше. А OSPF и без мультикаста нормально работает. Либо через p2p, либо если нейборов руками указать.

AS ★★★★★
()
Ответ на: комментарий от AS

Это понятно, но там про маршрутизацию на сети за клиентами. То есть, если на OpenVPN сервере сделать

ip route add <net/cidr> via <ip клиента>

оно не работает.

Работает прекрасно. Как я написал, у меня такая схема работает уже. Для этого и есть опция OpenVPN client-to-client.

Как пишет blind_oracle:

Не вышло потому, что у OpenVPN внутренний мультиплексор, который разруливает траффик. А <ip клиента> у тебя нигде нет, он скрыт за туннельным p2p-интерфейсом tun/tap (который на самом деле p2mp) и поэтому роутинг через него пойти не могёт.

Как раз таки опция client-to-client в паре с topology subnet (которая по умолчанию для dev tap) и выпускает пакеты из «внутреннего роутера» в ядро и позволяет их роутить как обычные и «видеть» подсети за клиентами.

Ну или еще опция iroute есть для решения аналогичных случаев.

У меня даже quagga работает и раздает маршруты в подсети за VPN-клиентами (раздавая статические записи из ядра, которые туда записывает OpenVPN через ip route add). Проблема у меня только в раздаче маршрутов кваггой клиентам за VPN.

nstorm
() автор топика
Ответ на: комментарий от AS

Вот, если интересно, как у меня работает машрутизация клиентам за OpenVPN через обычные статические ip route:

dev tap

mode server
tls-server
proto tcp-server # это не имеет значение для сабжа, в большинстве задач лучше udp.

ifconfig 192.168.254.1 255.255.255.0

# параметры TLS
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
crl-verify crl.pem

# соб-но раздача клиентам маршрутов
push "route-gateway 192.168.254.1"
client-config-dir /etc/openvpn/ccd

route-up /etc/openvpn/route # вот в этом файле и задаются у меня маршруты через ip route, он ниже
client-to-client # самая важная опиция )

# дальше опции, которые не должны влиять на задачу, но оставлю их
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
cipher AES-256-CBC
comp-lzo
max-clients 60
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3
mute 20
fast-io
mssfix

И пример файла /etc/openvpn/route:

#!/bin/sh
source /etc/profile
export PATH=$PATH:/sbin

# Client X
ip route add 10.4.1.0/24 via 192.168.254.141 dev tap0

# Client Y
ip route add 192.168.99.0/24 via 192.168.254.99 dev tap0

И т.д. Ес-но в ccd всем клиентам выдается статический ip в подсети 192.168.254.X и через него «вручную» и забит маршрут тут. Еще соотв. через ccd файл я передаю клиентам маршруты в сети за OpenVPN сервером, и именно от этой части и хочется избавиться.

nstorm
() автор топика
Ответ на: комментарий от nstorm

Как раз таки опция client-to-client в паре с topology subnet (которая по умолчанию для dev tap) и выпускает пакеты из «внутреннего роутера» в ядро и позволяет их роутить как обычные и «видеть» подсети за клиентами.

Да, кстати, более того, при такой настройке клиенты и подсети за ними могут видеть и сети не только за сервером, но и за другими клиентами. Если у них настроены соотв. маршруты.

Фактически у меня все клиенты и их подсети + подсети за сервером работают как бы в одной физической сети, что и требовалось у меня.

Ес-но тут надо учитывать безопасность и прочее. Можно решать фаерволлом, если роуты настроены через IP на сервере (192.168.254.1 в данном примере), то они пушатся в ядро и соотв. проходят правила iptables. Но если роуты делать напрямик клиент - клиент, то в ядро они не пушатся и роутятся внутри tap0. Но у меня ситуация в том, что все «клиенты» OpenVPN - доверенные серверы, поэтому мне это не проблема.

nstorm
() автор топика
Ответ на: комментарий от nstorm

client-to-client # самая важная опиция )

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

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)

А вот редистрибуция статики, если у маршрута dst ip в сторону IP в другой арии, поже, похоже осуществляется только у ту арию, где DST IP. У меня и без openvpn маршрут не пошёл в нулевую. Может быть, это правильно, кстати, так как за редистрибуцию между ариями должен ospf отвечать, в смысле настройки редистрибуции между ариями. А попробуй на OpenVPN сервере сделать

ip route add blackhole 10.0.0.0/8

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Вроде я пробовал даже в одну, 0 зону пихать их...

А на счет блэкхола - что я должен увидеть, когда это сделаю? Т.е. ну добавлю я этот блэкхольный маршрут, что потом проверить?

nstorm
() автор топика
Ответ на: комментарий от nstorm

А на счет блэкхола - что я должен увидеть, когда это сделаю?

Он не роутится в другую арию и должен бы заредистрибутиться. Соответственно, пакеты из левой части должны прийти на vpn-сервер, а он уже знает более специфические маршруты, так что, с него должно пойти по мелким уже.

На самом деле, тоже не редистрибутится. Но, по идее, препятствий в таком анонсе быть не должно. Можно покопать в эту сторону, думаю.

AS ★★★★★
()

Вот так работает: ip route 10.0.0.0/8 Null0
Это не у ospfd, а у самой zebra.

AS ★★★★★
()

А ваще обязательно OpenVPN то юзать? Я, где можно, всё перевел на ipsec+gre и проще и гемора меньше. Ну, либо, если нужно работать из-за NATа, то openvpn p2p удобнее будет (особенно в плане поиска багов), чем эти пляски с ccd, client-to-client и кваггой сверху.

Минус только если клиентов очень много.

blind_oracle ★★★★★
()
Ответ на: комментарий от AS

На самом деле, тоже не редистрибутится.

Неа, blackhole не распространился. Зато «ip route add 10.0.0.0/8 via 192.168.254.99» на VPN сервере скажем моментально приходит на другом хосте: 10.0.0.0/8 via 192.168.0.1 dev eth0 proto zebra metric 20

nstorm
() автор топика
Ответ на: комментарий от blind_oracle

Не скажите, что с ipsec гемора меньше. В своё время пробовал - нееее, слишком замудрено и отлаживать сложнее.

С OpenVPN мне гораздо проще - привычный TLS, CA, и с client-to-client и dev tap всё работает так, как будто это физический интерфейс. Можно и iptables как обычно разруливать и tcpdump'ом смотреть... И плюс кросплатформенность просто достигается.

Это конечно кому как удобнее. Но повторюсь - дело ведь не в OpenVPN. У меня он работает прекрасно уже, проблем нет. Надо лишь со статики перейти на OSPF. А с динамической маршрутизацией я просто не очень хорошо знаком, видимо тут что-то не так настраиваю. Про OpenVPN я рассказал лишь чтобы детально схему сети описать.

nstorm
() автор топика
Ответ на: комментарий от nstorm

ip route add 10.0.0.0/8 via 192.168.254.99

Но «ip route 10.0.0.0/8 Null0» в zebra.conf красивее. :-)

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

AS ★★★★★
()
Ответ на: комментарий от nstorm

Только зачем? Мне всё-таки не дропать нужно, а нечто другое )

Это тоже надо, только ты этого ещё не знаешь. ;-)

При наличии blackhole route на 10.0.0.0/8, пакеты по имеющимся маршрутам, например, на 10.0.1.0/24, 10.0.2.0/24 будут нормально ходить. А пакет в неизвестную сеть 10.4.20.0/24 дропнется, так как она попадёт в общий маршрут 10.0.0.0/8 -> null.

В противном случае, он у тебя уйдёт на 192.168.254.99 (10.0.0.0/8 via 192.168.254.99), оттуда вернётся по default gw, уйдёт обратно и помрёт только исчерпав ttl, создав вагон трафика.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Это тоже надо, только ты этого ещё не знаешь. ;-)

Ну как бы знаю. Только у меня роуты во все зарезервированные сетки hwmark'ается и правилами iptables дальше REJECT --reject-with icmp-net-unreachable. В отличии от просто отбрасывания пакета в /dev/null, это клиенту генерит нормальный ответ network unreachable.

Но всё-таки тема о другом )

nstorm
() автор топика
Ответ на: комментарий от nstorm

Если о другом, тогда с анонсом большой сети с vpn-сервера вопрос решить получилось ?

А null, не null - в общем-то, действительно, случай частный.

AS ★★★★★
()
Ответ на: комментарий от nstorm

Не скажите, что с ipsec гемора меньше. В своё время пробовал - нееее, слишком замудрено и отлаживать сложнее.

Просто ты вероятно его не так готовил. Нынче всё делается с полпинка, через тот же StrongSwan. Плюс - бесплатное ускорение шифрования через ядро, тем же AES-NI. Чтобы его добиться в OpenVPN нужно погеморится, да и результат всё равно не тот будет.

Вот, к примеру мой конфиг StrongSwan для коннекта точка-точка:

conn %default
    keyingtries=%forever
    authby=secret
    mobike=no
    keyexchange=ikev2
    compress=yes
    ike=aes256gcm128-sha2_512-modp4096!
    esp=aes128gcm64-modp4096!
    type=transport

    closeaction=clear
    dpdaction=restart
    dpddelay=60s

    auto=start

conn conn1
    left=1.1.1.1
    right=2.2.2.2
и всё, пароль в /etc/ipsec.secrets. Даже гораздо короче чем OpenVPN :)

После этого навешиваем между хостами обычный GRE тоннельный интерфейс:

ip tunnel add gre_conn1 remote 2.2.2.2 local 1.1.1.1 ttl 64
ip address add dev gre_conn1 192.168.254.2 peer 192.168.254.1
ip link set dev gre_conn1 mtu 1400 up
и имеем радость, юзаем этот интерфейс как обычно.

Плюсы - это стандартизованное решение и IPSEC/GRE туннель можно построить хоть до цыски, хоть до джунипера, хоть до царя гороха. А с OpenVPN только до *nix-а или винды.

С OpenVPN мне гораздо проще - привычный TLS, CA, и с client-to-client и dev tap всё работает так, как будто это физический интерфейс. Можно и iptables как обычно разруливать и tcpdump'ом смотреть... И плюс кросплатформенность просто достигается.

1. Никто не мешает делать IPSEC через CA, это даже более предпочтительный вариант чем статические ключи.

2. iptables и tcpdump тут тоже никто не запрещал :)

3. Кроссплатформенность у IPSEC гораздо шире, я выше писал.

Это конечно кому как удобнее. Но повторюсь - дело ведь не в OpenVPN. У меня он работает прекрасно уже, проблем нет.

Ну, если топик создал, значит проблемы есть. Может и не из-за OpenVPN конкретно, но тем не менее - хитрый нестандартный механизм работы OpenVPN в p2mp режиме доставлят прилично гемора т.к. он, по сути, использует некий внутренний роутинг и он не всегда ведёт себя так, как надо или ожидаешь.

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Ну может дело привычки. Я с IPSec сталкивался на KAME, и видимо отложились плохие впечатления из-за него ) OpenSWAN не мучал.

На счет GRE - для винды ведь придется поднимать L2TP еще отдельно.

И к тому же режим p2mp у OpenVPN вполне стандартный. Более того режим server и topology subnet вполне дефолтны для ус-в dev tap. Просто видимо вы тоже не до конца или давно изучали OpenVPN. Там достаточно много опций для гибкой настройки.

И проблема у меня явно не из-за него. Т.к. он настроен и работает как обычная сеть вполне. Проблема как я уже говорю скорее всего в моем плохом опыте с OSPF.

nstorm
() автор топика
Ответ на: комментарий от AS

Если о другом, тогда с анонсом большой сети с vpn-сервера вопрос решить получилось ?

Она анонсируется в левую (по схеме) часть сети, правая часть вообще никаких анонсов не видит, пока я не пропишу network 192.168.254.0/24 на сервере. Но тогда, как я уже говорил пропадают анонсы в левую часть наоборот (

nstorm
() автор топика
Ответ на: комментарий от nstorm

правая часть вообще никаких анонсов не видит, пока я не пропишу network 192.168.254.0/24

Это правильно. «network 192.168.254.0/24 area ...» описывает сеть, где искать соседей, и область. Вот когда прописываешь, анонс 10.0.0.0/8 сохраняется, или пропадает ?

А, стоп. Ты же его сделал, как «ip route add 10.0.0.0/8 via 192.168.254.99», а 192.168.254.99 в другую область уходит. Сделай не на 192.168.254.99, а, всё же, в null. Потом придумаешь, куда его роутить, чтобы «хост анричибал» вернуть.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.