LINUX.ORG.RU
решено ФорумAdmin

Маршрутизация через указанный хост в OpenBSD

 , ,


0

2

Hi. folks!

Суть такова. Есть маршрутизатор с OpenBSD 5.1 на борту. На нем работает IPSec и соединяет его с другим маршрутизатором на CentOS 6. Как правильно объяснить OpenBSD что для некоторых destination необходимо заворачивать трафик в IPSec и передавать его на CentOS? Т.е. например я хочу выходить на ya.ru через удаленный шлюз на CentOS - прописываю в pf.conf:

pass in quick on $Lan from $Lan:network to 213.180.204.3 route-to enc0

В результате обычный коннект до ya.ru пропадает, но и tcpdump'ом на enc0 никакой активности не наблюдается. Для enc0 выставляю

pass in on enc0 from any to any                    
pass out on enc0 from any to any
но ситуация никак не изменяется. До CentOS пакеты также не долетают исходя из tcpdump.

Правильно ли я понимаю что подобное нужно делать именно через route-to а не как-нибудь иначе?

Спасибо.

Правильно ли я понимаю что подобное нужно делать именно через route-to а не как-нибудь иначе?

Нет, не правильно. У тебя туннелем кто рулит? Вот его и надо настраивать , тобишь софт. У тебя в туннель завернется только тот трафик который ты прописал, да еще и на обоих сторонах. В линуксе обычно указывается директивами leftsubnets и rightsubnets.

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

Не понимаю причем здесь это. IPSec может быть поднят как host-to-host и в этом случае значение left/right subnet будет равно значению left т.е. IP-адресу хоста. По вашей логике маршрутизация в принципе в этом случае не должна работать.

В моей ситуации:

left - centos - внутренний ip - 10.100.1.2
right - openbsd - внутренний ip - 10.1.1.2
просто нужно указать что для определенных адресов необходимо слать не на default а через 10.100.1.2.

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

Моя логика в том что вторая фаза ipsec где указывается right и left subnets не сможет туннелировать трафик адресов отличных от этих параметров.

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

Опять не вижу проблемы. В моей ситуации имеется туннельный режим и ESP. Как известно, в нем мы имеем оригинальный IP пакет упакованный в зашифрованном виде как та самая payload. В этом пакете (payload) и указывается тот или иной dst. Не все ли равно что в нем указано для IPSec - 10.100.1.2 или 213.180.204.3, учитывая то что в заголовках верхнего уровня всегда в качестве src и dst указаны публичные адреса маршрутизаторов?

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

В этом пакете (payload) и указывается тот или иной dst. Не все ли равно что в нем указано для IPSec - 10.100.1.2 или 213.180.204.3


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

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

Допустим. Есть ли документ где четко написано что это так и написано почему это невозможно сделать? Я не понимаю почему IPSec по вашей логике накладывает (должен накладывать?) ограничения на содержимое payload (значение dst addr)? Мое мнение таково что все эти leftsubnets не более чем настройка позволяющая автоматически добавлять маршруты при старте туннеля.

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

При указании leftsubnet = 0.0.0.0/0 весь трафик автоматом перенаправляется в туннель, и в таблице маршрутизации IPSec предсказуемо становится маршрутом по умолчанию.

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

Так вот ты и ответил на вопрос

Я не понимаю почему IPSec по вашей логике накладывает (должен накладывать?) ограничения на содержимое payload (значение dst addr)?


Как настроишь так и поплывет. Маршруты он создаст сам. Истина что payload это то что ты пишешь в left и right subnets, маршруты это следствие которое вызывается после определения payload.
Критерием инкапсуляции трафика в туннель является то что ты пишешь в subnets. Другой трафик в туннель не попадет, верно ? А ты хочешь засунуть в туннель трафик к яндексу, и прикинь на той стороне туннеля приходит пакет с payload subnets которого он не знает , что он сделает с этим пакетом при его декапсуляции ???

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

Мда, таки вы правы, я не прав.

Рабочая конфигурация такая. Справа (OpenBSD) оставляем как есть, т.е. 10.1.1.0/24. Слева (Centos) же пишем такую конструкцию:

  leftsubnets = { 10.100.1.0/24 X.X.X.X/32 Y.Y.Y.Y/32 }
  leftsourceip = 10.100.1.2

  rightsubnet = 10.1.1.0/24
  rightsourceip = 10.1.1.2
Где, X.X.X.X и Y.Y.Y.Y - хосты (или сети) к которым мы хотим выходить через IPSec. После рестарта туннеля со стороны Centos все начинает работать автоматически без каких-либо изменений на стороне OpenBSD.

trancefer ★★
() автор топика
Ответ на: комментарий от pyatak123
ike active esp tunnel \
  from vr0 to 1.2.3.4 peer 1.2.3.4 \
  main auth hmac-sha1 enc 3des group modp2048 \
  quick auth hmac-sha1 enc 3des group modp2048 \
  psk secret

ike active esp tunnel \
  from vr0 to 10.100.1.0/24 peer 1.2.3.4 \
  main auth hmac-sha1 enc 3des group modp2048 \
  quick auth hmac-sha1 enc 3des group modp2048 \
  psk secret

ike active esp tunnel \
  from 10.1.1.0/24 to 10.100.1.0/24 peer 1.2.3.4 \
  main auth hmac-sha1 enc 3des group modp2048 \
  quick auth hmac-sha1 enc 3des group modp2048 \
  psk secret
trancefer ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.