VPN c динамической маршрутизацией (GRE Racoon OSPF)
Материал из ALT Linux Wiki
Sudmal (обсуждение | вклад) |
|||
(2 промежуточные версии не показаны) | |||
Строка 1: | Строка 1: | ||
- | |||
- | |||
- | |||
- | |||
== Исходные данные == | == Исходные данные == | ||
Схема такой сети масштабируема от двух офисов до довольно большой сети крупного предприятия. | Схема такой сети масштабируема от двух офисов до довольно большой сети крупного предприятия. | ||
Применение OSPF позволяет не прописывать маршруты вручную на каждом из маршрутизаторов сети удалённых филиалов, а также позволяет организовать несколько резервных каналов с автоматическим переключением. | Применение OSPF позволяет не прописывать маршруты вручную на каждом из маршрутизаторов сети удалённых филиалов, а также позволяет организовать несколько резервных каналов с автоматическим переключением. | ||
- | Начнём с | + | Начнём с простого — два филиала, на каждом в качестве маршрутизатора стоит Linux. |
<pre> | <pre> | ||
|------| |------| | |------| |------| | ||
Строка 14: | Строка 10: | ||
== Решение == | == Решение == | ||
+ | |||
=== Туннели === | === Туннели === | ||
OSPF роутеры используют IP multicast для обмена сообщениями, поэтому необходимо использовать туннели GRE over IP. | OSPF роутеры используют IP multicast для обмена сообщениями, поэтому необходимо использовать туннели GRE over IP. | ||
Строка 35: | Строка 32: | ||
Разрешить 47 IP протокол (GRE) в ваших правилах фильтрации трафика: | Разрешить 47 IP протокол (GRE) в ваших правилах фильтрации трафика: | ||
<pre>iptables -I INPUT -i eth1 -p 47 -j ACCEPT | <pre>iptables -I INPUT -i eth1 -p 47 -j ACCEPT | ||
- | iptables -I OUTPUT -o eth1 -p 47 -j ACCEPT</pre> | + | iptables -I OUTPUT -o eth1 -p 47 -j ACCEPT</pre> |
- | на | + | на «внешних» интерфейсах обоих филиалов. |
- | Делаем | + | Делаем |
<pre>ifup gre1</pre> | <pre>ifup gre1</pre> | ||
на обеих сторонах. | на обеих сторонах. | ||
Строка 54: | Строка 51: | ||
gre1: gre/ip remote y.y.y.y local x.x.x.x ttl 64 | gre1: gre/ip remote y.y.y.y local x.x.x.x ttl 64 | ||
</pre> | </pre> | ||
- | ''Примечание: для нормальной работы OSPF необходимо явно задать значение TTL для строящегося туннеля (например, TUNOPTIONS='ttl 64'). По умолчанию TTL=inherit, что значит | + | ''Примечание: для нормальной работы OSPF необходимо явно задать значение TTL для строящегося туннеля (например, TUNOPTIONS='ttl 64'). По умолчанию TTL=inherit, что значит «наследовать значение TTL из вкладываемого в туннель пакета». В случае с OSPF, TTL=1, стало быть первый встречный маршрутизатор отбросит такой пакет, что нам совсем не нужно.'' |
- | Проверка | + | Проверка работы — пинг удалённой стороны туннельного интерфейса (в нашем случае это 172.17.0.1). |
Если через этот туннель будет передаваться любая бизнес-информация, то её следует шифровать, чем мы сейчас и займёмся. | Если через этот туннель будет передаваться любая бизнес-информация, то её следует шифровать, чем мы сейчас и займёмся. | ||
Строка 140: | Строка 137: | ||
</pre> | </pre> | ||
- | В '''/etc/racoon/psk.txt''' указывается ключ | + | В '''/etc/racoon/psk.txt''' указывается ключ шифрования — должен быть идентичен на обеих сторонах. |
- | Обратите внимание, y.y.y. | + | Обратите внимание, y.y.y.y — внешний IP адрес противоположной стороны туннеля: |
<pre>у.y.y.y blablabla_secret_code_Kote_2011</pre> | <pre>у.y.y.y blablabla_secret_code_Kote_2011</pre> | ||
Права на файлы: | Права на файлы: | ||
Строка 162: | Строка 159: | ||
Смотрим в /var/log/messages (при необходимости и для общего развития можно повысить debug-level в racoon.conf). | Смотрим в /var/log/messages (при необходимости и для общего развития можно повысить debug-level в racoon.conf). | ||
- | Делаем | + | Делаем проверку — пинг противоположной стороны GRE туннеля. |
Вуаля! | Вуаля! | ||
Строка 168: | Строка 165: | ||
=== Динамическая маршрутизация === | === Динамическая маршрутизация === | ||
Динамическая маршрутизация реализована с использованием протокола [[ruwp:OSPF|OSPF]] | Динамическая маршрутизация реализована с использованием протокола [[ruwp:OSPF|OSPF]] | ||
- | (англ. Open Shortest Path First) | + | (англ. Open Shortest Path First) — протокола динамической маршрутизации, основанного на технологии отслеживания состояния канала (link-state technology) и использующего алгоритм Дейкстры (Dijkstra’s algorithm) для нахождения кратчайшего пути. Протокол OSPF был разработан IETF в 1988 году. Последняя версия протокола описана в RFC 2328. Протокол OSPF представляет собой протокол внутреннего шлюза (Interior Gateway Protocol — IGP). Протокол OSPF распространяет информацию о доступных маршрутах между маршрутизаторами одной автономной системы. |
OSPF предлагает решение следующих задач: | OSPF предлагает решение следующих задач: | ||
- | *Увеличение скорости сходимости (в сравнении с протоколом RIP2, так как нет необходимости выжидания многократных тайм-аутов по 30 сек.); | + | * Увеличение скорости сходимости (в сравнении с протоколом RIP2, так как нет необходимости выжидания многократных тайм-аутов по 30 сек.); |
- | *Поддержка сетевых масок переменной длины (VLSM); | + | * Поддержка сетевых масок переменной длины (VLSM); |
- | *Достижимость сети (быстро обнаруживаются отказавшие маршрутизаторы и топология сети изменяется соответствующим образом); | + | * Достижимость сети (быстро обнаруживаются отказавшие маршрутизаторы и топология сети изменяется соответствующим образом); |
- | *Оптимальное использование пропускной способности ( | + | * Оптимальное использование пропускной способности (так как строится минимальный остовный граф по алгоритму Дейкстры); |
- | *Метод выбора пути. | + | * Метод выбора пути. |
Функциональность OSPF содержится в пакете Quagga, пережившем не только животное (подвид южноафриканской зебры), давшее ему название, но и проект GNU Zebra, благодаря усовершенствованию которого проект Quagga в своё время появился на свет. | Функциональность OSPF содержится в пакете Quagga, пережившем не только животное (подвид южноафриканской зебры), давшее ему название, но и проект GNU Zebra, благодаря усовершенствованию которого проект Quagga в своё время появился на свет. | ||
Quagga поддерживает следующие протоколы маршрутизации: | Quagga поддерживает следующие протоколы маршрутизации: | ||
- | *собственно OSPF | + | * собственно OSPF v2 — демон ospfd; |
- | *RIP v1, | + | * RIP v1, v2 — демон ripd; |
- | *OSPF v3 | + | * OSPF v3 IPv6 — демон ospf6d; |
- | *RIP ng | + | * RIP ng IPv6 — демон ripngd; |
- | *BGP v4+, включая поддержку multicast и | + | * BGP v4+, включая поддержку multicast и IPv6 — демон bgpd; |
Базовым ядром Quagga является демон маршрутной информации zebra, выполняющий роль промежуточного уровня абстракции (abstraction layer) ядра ОС, и предоставляющий Zserv API клиентам (демонам маршрутизации) по протоколу TCP. | Базовым ядром Quagga является демон маршрутной информации zebra, выполняющий роль промежуточного уровня абстракции (abstraction layer) ядра ОС, и предоставляющий Zserv API клиентам (демонам маршрутизации) по протоколу TCP. | ||
Строка 302: | Строка 299: | ||
</pre> | </pre> | ||
--[[Участник:Sudmal|Сунцов Дмитрий]] 21:29, 20 января 2011 (UTC) | --[[Участник:Sudmal|Сунцов Дмитрий]] 21:29, 20 января 2011 (UTC) | ||
+ | |||
+ | {{Category navigation|title=VPN|category=VPN|sortkey={{SUBPAGENAME}}}} | ||
+ | {{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}} |
Текущая версия на 12:24, 19 июля 2015
Содержание |
Исходные данные
Схема такой сети масштабируема от двух офисов до довольно большой сети крупного предприятия. Применение OSPF позволяет не прописывать маршруты вручную на каждом из маршрутизаторов сети удалённых филиалов, а также позволяет организовать несколько резервных каналов с автоматическим переключением. Начнём с простого — два филиала, на каждом в качестве маршрутизатора стоит Linux.
|------| |------| 192.168.1.0/24 ------|Linux |-x.x.x.x~~~~~~~~~~~y.y.y.y- |Linux |--------192.168.2.0/24 |------| |------|
Решение
Туннели
OSPF роутеры используют IP multicast для обмена сообщениями, поэтому необходимо использовать туннели GRE over IP. В ALT linux Ark 5 поддержка таких туннелей идёт из коробки. Конфиги: папка /etc/net/ifaces/gre1 (её нужно создать вручную, как и нижеприведенные файлы): /etc/net/ifaces/gre1/ipv4address:
172.17.0.0 peer 172.17.0.1
/etc/net/ifaces/gre1/options:
TUNLOCAL=x.x.x.x TUNREMOTE=y.y.y.y TUNTYPE=gre TYPE=iptun TUNTTL=64 TUNMTU=1476 TUNOPTIONS='ttl 64' DISABLE=no
Настройки противоположной стороны идентичны, необходимо лишь поменять местами IP адреса в TUNLOCAL и TUNREMOTE.
Разрешить 47 IP протокол (GRE) в ваших правилах фильтрации трафика:
iptables -I INPUT -i eth1 -p 47 -j ACCEPT iptables -I OUTPUT -o eth1 -p 47 -j ACCEPT
на «внешних» интерфейсах обоих филиалов. Делаем
ifup gre1
на обеих сторонах. Если солнечная активность в день настройки минимальна, в системе появится сетевой интерфейс gre1, смотрим:
# ifconfig gre1 gre1 Link encap:UNSPEC HWaddr 3E-7A-38-81-8A-BF-00-05-00-00-00-00-00-00-00-00 inet addr:172.17.0.0 P-t-P:172.17.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 MiB)
и здесь:
# ip tu sh gre0: gre/ip remote any local any ttl inherit nopmtudisc gre1: gre/ip remote y.y.y.y local x.x.x.x ttl 64
Примечание: для нормальной работы OSPF необходимо явно задать значение TTL для строящегося туннеля (например, TUNOPTIONS='ttl 64'). По умолчанию TTL=inherit, что значит «наследовать значение TTL из вкладываемого в туннель пакета». В случае с OSPF, TTL=1, стало быть первый встречный маршрутизатор отбросит такой пакет, что нам совсем не нужно.
Проверка работы — пинг удалённой стороны туннельного интерфейса (в нашем случае это 172.17.0.1).
Если через этот туннель будет передаваться любая бизнес-информация, то её следует шифровать, чем мы сейчас и займёмся.
Шифрование передаваемых данных
Устанавливаем ipsec_tools
apt-get install ipsec-tools
Конфиги: /etc/racoon/racoon.conf:
path include "/etc/racoon/"; path pre_shared_key "/etc/racoon/psk.txt"; log notify; # notify,debug,debug2 # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } # if no listen directive is specified, racoon will listen to all # available interface addresses. listen { isakmp x.x.x.x [500]; } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5;# maximum trying count to send. interval 20 sec;# maximum interval to resend. persend 1;# the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 15 sec; } # remote y.y.y.y { exchange_mode main; #exchange_mode aggressive; doi ipsec_doi; situation identity_only; nonce_size 16; lifetime time 60 min; initial_contact on; support_proxy on; proposal_check obey;# obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } # Шифруем только GRE sainfo address x.x.x.x/32 47 address y.y.y.y/32 47 { pfs_group 2; lifetime time 24 hour; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; }
/etc/racoon/setkey.conf:
#!/sbin/setkey -f flush; spdflush; spdadd x.x.x.x/32 y.y.y.y/32 47 -P out ipsec esp/tunnel/x.x.x.x-y.y.y.y/unique; spdadd y.y.y.y/32 x.x.x.x/32 47 -P in ipsec esp/tunnel/y.y.y.y-x.x.x.x/unique;
В /etc/racoon/psk.txt указывается ключ шифрования — должен быть идентичен на обеих сторонах. Обратите внимание, y.y.y.y — внешний IP адрес противоположной стороны туннеля:
у.y.y.y blablabla_secret_code_Kote_2011
Права на файлы:
# l ... -rw------- 1 root root psk.txt -rw-r--r-- 1 root root racoon.conf -rw-r--r-- 1 root root setkey.conf
Дабы загрузить правила, говорим:
# setkey -f /etc/racoon/setkey.conf
На противоположной стороне конфиг соответствующий, за исключением ротации IP адресов (x.x.x.x и y.y.y.y).
Опционально, разрешить порт 500 tcp и udp на внешних интерфейсах в ваших правилах фильтрации трафика.
Запускаем сервис racoon на обеих сторонах:
# service racoon start
Смотрим в /var/log/messages (при необходимости и для общего развития можно повысить debug-level в racoon.conf).
Делаем проверку — пинг противоположной стороны GRE туннеля.
Вуаля!
Динамическая маршрутизация
Динамическая маршрутизация реализована с использованием протокола OSPF (англ. Open Shortest Path First) — протокола динамической маршрутизации, основанного на технологии отслеживания состояния канала (link-state technology) и использующего алгоритм Дейкстры (Dijkstra’s algorithm) для нахождения кратчайшего пути. Протокол OSPF был разработан IETF в 1988 году. Последняя версия протокола описана в RFC 2328. Протокол OSPF представляет собой протокол внутреннего шлюза (Interior Gateway Protocol — IGP). Протокол OSPF распространяет информацию о доступных маршрутах между маршрутизаторами одной автономной системы. OSPF предлагает решение следующих задач:
- Увеличение скорости сходимости (в сравнении с протоколом RIP2, так как нет необходимости выжидания многократных тайм-аутов по 30 сек.);
- Поддержка сетевых масок переменной длины (VLSM);
- Достижимость сети (быстро обнаруживаются отказавшие маршрутизаторы и топология сети изменяется соответствующим образом);
- Оптимальное использование пропускной способности (так как строится минимальный остовный граф по алгоритму Дейкстры);
- Метод выбора пути.
Функциональность OSPF содержится в пакете Quagga, пережившем не только животное (подвид южноафриканской зебры), давшее ему название, но и проект GNU Zebra, благодаря усовершенствованию которого проект Quagga в своё время появился на свет. Quagga поддерживает следующие протоколы маршрутизации:
- собственно OSPF v2 — демон ospfd;
- RIP v1, v2 — демон ripd;
- OSPF v3 IPv6 — демон ospf6d;
- RIP ng IPv6 — демон ripngd;
- BGP v4+, включая поддержку multicast и IPv6 — демон bgpd;
Базовым ядром Quagga является демон маршрутной информации zebra, выполняющий роль промежуточного уровня абстракции (abstraction layer) ядра ОС, и предоставляющий Zserv API клиентам (демонам маршрутизации) по протоколу TCP.
Суть такова: Демоны маршрутизации просчитывают маршруты по своему протоколу и выдают результаты zebra, который выбирает лучший маршрут на основе административного расстояния и добавляет его в таблицу маршрутизации.
От теории к практике, установка:
# apt-get install quagga
Обратите внимание на то, что необходимо рекурсивно сменить права на папку /etc/quagga:
chown -R quagga:quagga /etc/quagga
Конфиги неиспользуемых протоколов переносим в папку samples (например), оставляем только ospfd.conf и zebra.conf:
# ls -la /etc/quagga/ -rw------- 1 quagga quagga 783 Дек 30 22:07 ospfd.conf drwxr-xr-x 2 quagga quagga 4096 Мар 26 2010 samples -rw------- 1 quagga quagga 529 Дек 30 22:08 zebra.conf
/etc/quagga/ospfd.conf:
! hostname host-x password 8 LrjDz/a2KALVQ enable password 8 LrjDz/a2KALVQ log file /var/log/quagga/ospfd.log informational service password-encryption no banner motd ! interface gre0 ! interface gre1 description link-gre1 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 SecrEtKeY ip ospf cost 100 ip ospf dead-interval 60 ! interface lo ! router ospf ospf router-id 192.168.1.1 redistribute connected route-map RedistNets network 172.17.0.0/30 area 0.0.0.0 ! access-list 111 permit ip 192.168.1.0 0.0.0.255 any access-list localhost permit 127.0.0.1/32 access-list localhost deny any ! route-map RedistNets permit 10 match ip address 111 ! line vty access-class localhost
/etc/quagga/zebra.conf
hostname router password 8 LrjDz/a2KALVQ enable password 8 LrjDz/a2KALVQ log file /var/log/quagga/zebra.log informational service password-encryption no banner motd ! interface gre0 ! interface gre1 ip address 172.17.0.2/30 link-detect ! interface lo description loopback ! access-list localhost permit 127.0.0.1/32 access-list localhost deny any ! ip forwarding no ipv6 forwarding ! line vty access-class localhost !
Опять же, конфиги противоположной стороны в плане соответствующих IP адресов зеркальны. Запуск и настройка запуска при старте системы:
service zebra start service ospfd start chkconfig ospfd on chkconfig zebra on # netstat -nlp |grep :260 tcp 0 0 127.0.0.1:2600 0.0.0.0:* LISTEN 13362/zebra tcp 0 0 127.0.0.1:2601 0.0.0.0:* LISTEN 13362/zebra tcp 0 0 127.0.0.1:2604 0.0.0.0:* LISTEN 13294/ospfd
Интерфейс конфигурирования практически идентичен цисковскому. Для подключения к консоли zebra или ospfd, соответственно, необходимо выполнить:
telnet 127.0.0.1 2601 telnet 127.0.0.1 2604
Все пароли по умолчанию cisco. Если обе стороны сконфигурированы правильно, то в консоли ospfd можно увидеть:
# telnet 127.0.0.1 2604 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. User Access Verification Password: HOST-X> enable Password: HOST-X# sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 192.168.2.1 1 Full/DROther 54.982s 172.17.0.1 gre1:172.17.0.2 0 0 0
В таблице маршрутизации появится новый маршрут (или несколько):
# ip ro sh 192.168.2.0/24 via 172.17.0.1 dev gre1 proto zebra metric 20 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 default via x.x.x.x dev eth1
--Сунцов Дмитрий 21:29, 20 января 2011 (UTC)