LINUX.ORG.RU
ФорумAdmin

IPsec настройки разрешенных подсетей


0

1

Добрый день.
Ситуация такая - есть настроенный туннель между FortiGate и OpenSWAN. Локальные подсети что со стороны FortiGate'а, что со стороны OpenSWAN'а 255.255.0.0. Проблемы со стороны OpneSWAN. После поднятия туннеля сам хост с OpenSWAN'ом пинугет другую сеть (у него айпишник 192.168.1.181), другие хосты, имеющие адреса 192.168.1.х тоже пинугют, а вот из любой другой подсети, например, 192.168.2.15, не пинугет. Traceroute говорит, что пакет доходит до хоста с OpenSWAN'ом и там остается.
Насколько я понял, параметры конфига leftsubnet, rightsubnet, virtual_private настраивают доступность подсетей для другой стороны. Нет ли какой-то настройки, ограничивающей форвадинг трафика через IPsec-туннель? ip_forward включен, iptables отключен. Конфиг ниже:

config setup
plutodebug=all
dumpdir=/var/run/pluto/
nat_traversal=yes
virtual_private=%v4:10.109.0.0/16,%v4:!192.168.0.0/16
oe=off
protostack=netkey

conn smart
type=tunnel
authby=secret
auth=esp
ikelifetime=86400s
keylife=28800s
phase2alg=aes256-sha1
ike=aes256-sha1;modp1024
keyexchange=ike
pfs=no
left=%defaultroute
leftsubnet=192.168.0.0/16
leftsourceip=192.168.1.181
right=Public_IP
rightsubnets=10.109.0.0/16



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

Эти параметры leftsubnet, rightsubnet, virtual_private настраивают как бы маршрутизацию, точнее политики (xfrm), в соответсвии с которыми пакет будет или не будет завёрнут в тунель. traceroute не показывает, что пакет где-то остаётся, он просто показывает последнюю безпроблемную точку маршртуа. Если у вас тунель не загружен трафиком, попробуйте запустить ping с 192.168.2.15 и tcpdump на внешнем интефейсе хоста с openswan. На один icmp пакет должен приходится один тунелированый пакет. У вас может быть три варианта по выхлопу tcpdump — с хоста ничего никуда не уходит, с хоста уходят icmp-пакеты мимо тунеля и с хоста уходят пакеты по тунелю.

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

Хост с OpenSWAN находится за NAT'ом, интерфейс один.
tcpdump говорит следующее:

14:17:31.593897 IP 192.168.10.1 > 10.109.106.147: ICMP echo request, id 56117, seq 130, length 64
14:17:32.593766 IP 192.168.10.1 > 10.109.106.147: ICMP echo request, id 56117, seq 131, length 64

Т.е. пакеты приходят, но в туннель не попадают.

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

Покажите ″ip xfrm pol″.

Посмотрите tcpdump для случая пинга из сети 192.168.1.x (с хоста, а не сервера), чтобы убедиться, что tcpdump работает правильно и вы устанавливаете правильные фильтры, показывающие и icmp и тунельные пакеты (udp, если через NAT).

Если окажется, что tcpdump для 192.168.1.x показывает, а для 192.168.10.x не показывает тунельные пакеты, попробуйте проследить прохождение пакета по цепочкам iptables. У вас ведь iptables есть, просто все цепочки во всех таблицах пустые? Либо создавайте во всех цепочках правила без цели (-s 192.168.10.1 -p icmp) и потом смотрите счётчики, либо попрбуйте ″-j TRACE″: http://serverfault.com/questions/385937/how-to-enable-iptables-trace-target-o...

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

Да, фильтры для tcpdump я указывал неправильные. Натравив его на правильный хост, увидел, что udp-пакеты отправляются, независимо из какой подсети. Т.е. icmp request вместе с udp-пакетом уходят, а ответ не приходит. Выглядит так, будто это проблема второй стороны, но там филиппинцы, с ними сложно :-) Надо погуглить про настройку FortiGate, может там в нескольких местах нужно подсети прописать.

Вывод ip xfrm policy, на всякий случай:
src 192.168.0.0/16 dst 10.109.0.0/16
dir out priority 2608 ptype main
tmpl src 192.168.1.181 dst Public_IP
proto esp reqid 16385 mode tunnel
src 10.109.0.0/16 dst 192.168.0.0/16
dir fwd priority 2608 ptype main
tmpl src Public_IP dst 192.168.1.181
proto esp reqid 16385 mode tunnel
src 10.109.0.0/16 dst 192.168.0.0/16
dir in priority 2608 ptype main
tmpl src Public_IP dst 192.168.1.181
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
dir 4 priority 0 ptype main
src ::/0 dst ::/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main

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

Проблема действительно оказалась на второй стороне. Спасибо большое за помощь.

dagger_nn
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.