Конфиги-то показал бы.

Заворачивание трафика в ipsec тунель определяется политиками ipsec (команда ip xfrm pol show).

Про виртуалку нифига не понял. Пакет идёт как обычно, в самом конце, уже после SNAT срабатывают политики ipsec и пакет уходит в тунель. Поэтому если у вас SNAT, то политика наоборот может не сработать, если SNAT поставит scr-ip адрес, для которого нет политики.

Если вам нужно, чтобы на сервере был ip-адрес local1, дак просто добавьте его, зачем для этого виртуалку поднимать?

Конфиг opensawn

conn test
        type=tunnel
        authby=secret

        auth=esp
        keyexchange=ike
        ike=3des-sha1-modp1024
        esp=3des-sha1
        pfs=yes
        keylife=«3600»

        left=server1
        leftsubnet=10.0.30.8/32
        leftnexthop=%defaultroute

        right=server2
        rightsubnet=10.78.0.12/32
        rightnexthop=%defaultroute

        keyingtries=%forever
        auto=add

1) вывод ip xfrm policy

ip xfrm policy
src 10.0.30.8/32 dst 10.78.0.12/32 
        dir out priority 2080 ptype main 
        tmpl src server1 dst server2
                proto esp reqid 16385 mode tunnel
src 10.78.0.12/32 dst 10.0.30.8/32 
        dir fwd priority 2080 ptype main 
        tmpl src server2 dst server1
                proto esp reqid 16385 mode tunnel

eth0:0    Link encap:Ethernet  HWaddr 08:60:6E:6A:47:9B  
          inet addr:10.0.30.8  Bcast:10.0.30.8  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

А как именно виртуалка связана с «реальной» сетью? Вообще это что за виртуалка - контейнер openvz или что-то другое? Сам хост с ней нормально по сети общается?
Поснифай на ней пинги и перепроверь правила iptables на сервере ipsec - может у тебя там срабатывает лишний NAT.

ну виртуалки уже нет (см. выше), да был контейнер openvz,

 
tcpdump -i eth0 | grep 10.0.78.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:20:08.878059 IP server1 > 10.0.78.12: ICMP echo request, id 5153, seq 1, length 64
09:20:09.877888 IP server1 > 10.0.78.12: ICMP echo request, id 5153, seq 2, length 64
09:20:10.877892 IP server1 > 10.0.78.12: ICMP echo request, id 5153, seq 3, length 64

То есть, сейчас local1 это реальная машина, а не виртуалка?
Это с какой машины снят трафик?

да, сейчас и local1 и server1 одна и та же машина, трафик с нее же

Я правильно понимаю, что у тебя на каждом сервере по два интерфейса, причем те, что указаны у тебя в *subnet - это внутренние, а left и right - внешние?

с их стороны server2 - циска, local2 - виндовая машина, с моей стороны на server1 есть только один физический интерфейс eth0 с внешним IP, IP local1 (т.е. 10.0.30.8) я прикрутил к нему же (eth0:0)

Дык что там в настройках iptables? Похоже, там таки живет лишний SNAT.
iptables -L -t nat дай глянуть.
И уточним: ты точно пингуешь с 10.0.78.12 адрес local1(т.е. alias), когда снифаешь?

grep не правильно, так правильнее:

tcpdump -i eth0 -n -nn host 10.0.78.12

Ну и ping надо от local1:

ping -n -I 10.0.30.8 10.0.78.12

если заработает, то тогда добавить маршрут до local2 с src local1.

По поводу возможного лишнего SNAT вам написали, то есть если у вас SNAT/MASQRADE всего исходящего с eth0 траффика, то нужно:

iptables -t nat -I POSTROUTING -s 10.0.30.8 -d 10.0.78.12 -j ACCEPT

iptables -L -t nat 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  —  10.0.30.8            10.0.78.12          
SNAT       all  —  10.0.0.0/8           anywhere            to:server1
MASQUERADE  all  —  10.0.30.8            anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

запускал

telnet -b 10.0.30.8 10.0.78.12

ping -n -I 10.0.30.8 10.0.78.12

результат соотв.

tcpdump -i eth0 -n -nn host 10.0.78.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:02.313445 IP 10.0.30.8.55811 > 10.0.78.12.23: Flags , seq 219843556, win 14600, options [mss 1460,sackOK,TS val 2909283250 ecr 0,nop,wscale 7], length 0
12:03:03.312872 IP 10.0.30.8.55811 > 10.0.78.12.23: Flags , seq 219843556, win 14600, options [mss 1460,sackOK,TS val 2909284250 ecr 0,nop,wscale 7], length 0
12:03:05.312872 IP 10.0.30.8.55811 > 10.0.78.12.23: Flags , seq 219843556, win 14600, options [mss 1460,sackOK,TS val 2909286250 ecr 0,nop,wscale 7], length 0
12:03:09.312871 IP 10.0.30.8.55811 > 10.0.78.12.23: Flags , seq 219843556, win 14600, options [mss 1460,sackOK,TS val 2909290250 ecr 0,nop,wscale 7], length 0
12:04:19.060039 IP 10.0.30.8 > 10.0.78.12: ICMP echo request, id 33977, seq 1, length 64
12:04:20.059881 IP 10.0.30.8 > 10.0.78.12: ICMP echo request, id 33977, seq 2, length 64
12:04:21.059885 IP 10.0.30.8 > 10.0.78.12: ICMP echo request, id 33977, seq 3, length 64

Выброси правила SNAT и MASQUERADE.

Выбросил. Вот весь файл правил для iptables http://pastebin.com/Dq3rHb6X

Результат

tcpdump -i eth0 -n -nn host 10.0.78.12                                                                                                                                                                                                                          
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                                                                                                                                                                                                     
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes                                                                                                                                                                                                       
12:24:12.978563 IP server1.58070 > 10.0.78.12.23: Flags , seq 3049966098, win 14600, options [mss 1460,sackOK,TS val 2910553915 ecr 0,nop,wscale 7], length 0                                                                                                         
12:24:13.977870 IP server1.58070 > 10.0.78.12.23: Flags , seq 3049966098, win 14600, options [mss 1460,sackOK,TS val 2910554915 ecr 0,nop,wscale 7], length 0           

Выбросил

Не выбросил:

$IPT -t nat -A POSTROUTING -s $VPS_LAN -o $WAN1_IF -j SNAT --to $WAN1_IP

У него tcpdump уже показывает пакет

10.0.30.8 > 10.0.78.12

почему вы решили, что SNAT отстался?

Я отвечаю на комментарий, где «server1.58070 > 10.0.78.12.23»
Кроме того, там же приведен файл, откуда я скопипастил активное правило. Кстати, а не плюет ли айписековский стек на туннелирование по той причине, что у ТСа сети пересекаются?

В комментарии aslubsky (22.08.2013 14:11:22) были пакеты «10.0.30.8 > 10.0.78.12», в ответ на этот комментарий вы thesis (22.08.2013 14:19:54) написали:

Выброси правила SNAT и MASQUERADE.

В результате «выбрасывания» снова появились пакеты «server1.58070 > 10.0.78.12.23». Кто кого троллит? :-)

Вроде ipsec стеку должно быть безразлично адресное пространство, есть политика, есть пакет, значит заворачиваем.

В результате «выбрасывания» снова появились пакеты «server1.58070 > 10.0.78.12.23».

Так ведь он выбросил только правило с masquerade, snat пока на месте.

Кто кого троллит? :-)

Пока что троллюсь я один(

Наверное, если он выкинет это правило, у всей локалки отвалится инет, и сразу прибежит злой директор, оставленный без своей дозы порнухи :-)

Я так понял из треда, что там раньше была локалка, а сейчас ее нет. Тем более, комментарии к правилам иптаблесов намекают, что вся эта «локалка» была виртуальной. (Иначе нафиг бы нужен этот alias, можно было использовать для тестовых пингов любую машину локалки)

Не совсем понимаю ваши NAT правила, обычно или SNAT или MASQRADE. Но, в общем, либо вам нужно полностью очистить таблицу POSTROUTING, либо первым там написать то правило, которое я привёл, чтобы пакеты «10.0.30.8 > 10.0.78.12» уходили как есть, без SNAT'а.

Потом смотрите вывод команды ″tcpdump -i eth0 -v -n -nn host 10.0.78.12 or esp″. Если при запущенном пинге появляются esp-пакеты server1 -> server2, значит траффик в ipsec заворачивается, и, возможно, проблемы с настройкой local2.

P.S. Логи и вывод команд лучше обрамлять тегами [code] [/code], см описание разметки LORCODE, ссылка внизу, по полем ввода текста комментария.

1) Выбросил

tcpdump -i eth0 -n -nn host 10.0.78.12                                                                                                                                                                                                                          
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                                                                                                                                                                                                     
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes                                                                                                                                                                                                       
13:42:11.759029 IP 10.0.30.8.56465 > 10.0.78.12.23: Flags , seq 2371209282, win 14600, options [mss 1460,sackOK,TS val 2915232695 ecr 0,nop,wscale 7], length 0  

2) да раньше все это дело было в локалке, и 10.0.30.8 был адрес реальной виндовой машины

3) действительно, если убрать правило нет на локалках пропадает инет, так что полностью убрать - не вариант, хотя для теста ничего страшного не случилось

сори, про тег code не увидел, исправлюсь

Да, там случилось что-то страшное. Был BSD и она RIP, поэтому и локалка исчезла, только CentOS'у удалось отбится :-))

Любую машину то не получится, нужно именно с этим адресом (/32), хотя вроде как сейчас винда позволяет быстро менять ip, без перезагрузки.

″or esp″ к опциям tcpdump'а. Если в выводе будут пакеты типа:

IP server1 > server2: ESP(spi=0xc7fb9fab,seq=0xb)

а на ping'и ответов не будет, можно будет побеспокоить админов server2.

сделал как рекомендовали т.е. установил $IPT -t nat -I POSTROUTING -s 10.0.30.8 -d 10.0.78.12 -j ACCEPT первым правилом в POSTROUTING

tcpdump -i eth0 -v -n -nn host 10.0.78.12 or esp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:54:05.765484 IP (tos 0x10, ttl 64, id 8193, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.30.8.39350 > 10.0.78.12.23: Flags [S], cksum 0xfcaf (correct), seq 2298147023, win 14600, options [mss 1460,sackOK,TS val 2915946702 ecr 0,nop,wscale 7], length 0
13:54:06.764865 IP (tos 0x10, ttl 64, id 8194, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.30.8.39350 > 10.0.78.12.23: Flags [S], cksum 0xf8c7 (correct), seq 2298147023, win 14600, options [mss 1460,sackOK,TS val 2915947702 ecr 0,nop,wscale 7], length 0
13:54:08.764866 IP (tos 0x10, ttl 64, id 8195, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.30.8.39350 > 10.0.78.12.23: Flags [S], cksum 0xf0f7 (correct), seq 2298147023, win 14600, options [mss 1460,sackOK,TS val 2915949702 ecr 0,nop,wscale 7], length 0

Ну дык мне написано, что «с нашей стороны есть только server1» - я верю. Я доверчивый. «Только» - значит «только». Опять же, см. каменты к иптаблесам.
А теперь да, оказывается что физическая локалка и все без инета.
Ох.

нет, я наверное не прав. объяснил, сейчас действительно только 1 сервак и все. Раньше был локальный сервак на FreeBSD и локалка

Покажите вывод команд ″ip xfrm policy show″, ″ip xfrm state show″ и ″ip xfrm monitor″ когда запущен ping.

А вы после того как добавили ip-адрес тунель перезапускали? А то у вас как-то странно, нет политики с ″dir in″, только ″dir out″ и ″dir fwd″.

ip xfrm pol show

src 10.0.30.8/32 dst 10.78.0.12/32 
        dir out priority 2080 ptype main 
        tmpl src server1 dst server2
                proto esp reqid 16385 mode tunnel
src 10.78.0.12/32 dst 10.0.30.8/32 
        dir fwd priority 2080 ptype main 
        tmpl src server2 dst server1
                proto esp reqid 16385 mode tunnel
src 10.78.0.12/32 dst 10.0.30.8/32 
        dir in priority 2080 ptype main 
        tmpl src server2 dst server1
                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 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 
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 

ip xfrm state show

src server2 dst server1
        proto esp spi 0x4dd64f13 reqid 16385 mode tunnel
        replay-window 32 flag 20
        auth hmac(sha1) 0x34677b1276cc6f0050ba1aaffbee88bf240d9a4f
        enc cbc(des3_ede) 0xd6d5cf79ef9caa63e3b116ec5d0c25711bd1dca14cedc3bb
src server1 dst server2
        proto esp spi 0x79113b1f reqid 16385 mode tunnel
        replay-window 32 flag 20
        auth hmac(sha1) 0xec8fd1f5ba3195d26e51874aa82d50828d3936c2
        enc cbc(des3_ede) 0x0c76ad69db4547431add91c58f351a72bf373b5105f337d5

ip xfrm monitor ничего не вывел, так и висел пока не прибил его

туннель перезапускал /etc/init.d/ipsec restart

ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.38dr2/K2.6.32-042stab078.28...
ipsec_setup: multiple ip addresses, using  server1 on eth0
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled

ipsec auto --up test

104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: received Vendor ID payload [RFC 3947] method set to=109 
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: received Vendor ID payload [Cisco-Unity]
003 "test" #1: received Vendor ID payload [Dead Peer Detection]
003 "test" #1: ignoring unknown Vendor ID payload [0dbc9253fcc1a4c5d0f3d90b68b55d13]
003 "test" #1: received Vendor ID payload [XAUTH]
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "test" #2: STATE_QUICK_I1: initiate
003 "test" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=ab2b7a8b
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x79113b1f <0x4dd64f13 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}

Хорошо. Значит ещё раз. При запущенной команде:

ping -n -I 10.0.30.8 10.0.78.12

1. ″ip xfrm pol show″ выводит политику ″src 10.0.30.8/32 dst 10.78.0.12/32 dir out″

2. ″tcpdump″ показывает на внешнем интерфейсе icmp-пакеты 10.0.30.8 -> 10.0.78.12 и не показывает ESP-пакетов

3. Команда ″ip xfrm monitor″ ничего не выводит.

Я переспрашиваю, просто, чтобы получить ответ, что всё это выполняется одновременно, потому что при неустойчивой связи, тунель может то появлятся, то исчезать.

Вывод вышеприведённых комманд сюда постить не надо, просто проверьте что всё так, и если всё в точности так, то посмотрите вывод ″lsmod″. Там должны быть загружены модули: ″ah4″, ″esp4″ и куча xfrm4-модулей (обязательно xfrm4_tunnel и xfrm4_mode_tunnel). Если их нет, загрузите через ″modprobe″. Я подразумеваю, что у вас дистрибутивное ядро 2.6.32. Если модули были загружены или их загрузка ничего не изменила, то у меня пока больше нет вариантов.

да, все именно так: 1,2,3 - да, модули все проверил, все что перечислили есть, ядро Linux main 2.6.32-042stab078.28

И что, при этой красоте пинги все равно не ходят?
А tcpdump -v proto 50, запущенный на server1, что-нибудь ловит при попытке пинговать local1 с другого конца туннеля?

Покажите ещё вывод команды ″setkey -DP″, ну и плюсую просьбу thesis'а о запуске пинга с local2 на local1.

Попробуйте закомментировать leftnexthop и добавить ″leftsourceip=server1″, вдруг поможет (ipsec перезапускать после правки конфига).

server1 и server2 это «белые» ipv4 адреса?

сори, был в оффлайне, отвечаю по порядку: 1) пинга с local2 на local1 - хост пингуется

tcpdump -v proto 50
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:50:05.407802 IP (tos 0x0, ttl 246, id 19308, offset 0, flags [none], proto ESP (50), length 112)
    server2 > server1: ESP(spi=0x677b42cd,seq=0x1), length 92

пинга с local2 на local1 - хост пингуется

Пингуется? Ответы на пинги приходят? И при этом в tcpdump'е ESP пакеты только server2 > server1?

Да, забыл про 6-ой CentOS, openswan появился и работал ещё в пятом, а потом RedHat выпилил пакет ipsec-tools. Пока идей почему пакет может «проваливаться» мимо правила политики нет, надо подумать.

Что у вас в файлах /proc/sys/net/ipv4/conf/*/disable_policy ?

Попробуйте взять дистрибутивное ядро, а не 2.6.32-042stab078.28, или вам нужен этот openvz?

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

disable_policy
/proc/sys/net/ipv4/conf/all/disable_policy - 0
/proc/sys/net/ipv4/conf/default/disable_policy - 0
/proc/sys/net/ipv4/conf/eth0/disable_policy - 0
/proc/sys/net/ipv4/conf/lo/disable_policy - 1
/proc/sys/net/ipv4/conf/venet0/disable_policy - 1

к сожалению openvz нужен, ОС снести и переставить другую уже не могу

Да ведь дистрибутивное ядро должно было остаться? Попробовать перегрузиться в него исключительно для эксперимента, grub'у ведь можно сказать и удалённо, что один раз загрузится с другим ядром, если проблема в физ. доступе.

Или попробуйте поискать userspace реализации ipsec под Linux, вроде они ещё есть живые.

А что у вас сейчас с таблицей маршрутов (ip route show), случаем 10.x.x.x через venet0 не отправлена?

нет, 10.x.x.x не через venet0, точнее там для каждой виртуалки своя запись есть, но есть еще такая

10.78.0.12 via server11 dev eth0  src server1 

default via server11 dev eth0 

10.78.0.12 via server11 dev eth0  src server1 

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes
        virtual_private=
        oe=off
        # Enable this if you see "failed to find any available worker"
        # nhelpers=0

Да нет, с базовым конфигом всё нормально. Я не поленился и соеденил две шестых ЦентОси с вашим конфигом (с другим адресами), но по этой же схеме, когда local1 назначен алиасом на интерфейс server1, а local2 дальше за server2.

Всё работало, единственно, что с одной из сторон сделал ″auto=start″, иначе тунель не поднимался. Пинги ходили, tcpdump показывал шифрованные ESP пакеты, ″ip xfrm monitor″ выдавал по сообщению на каждый пакет.

Причём ломая маршруты и создавая SNAT правила я не смог добится того, чтобы tcpdump на server1 показала icmp-пакеты local1 > local2. Пока есть политика пакеты заворачиваются в ESP. Я не могу с уверенностью сказать, что проблемя в ядре, openvz-ядро я себе ставить не буду, если у вас есть пара-тройка физических машин куда можно поставить ЦентОс, попробуйте сами провести эксперимент.

p.s. У меня server1 и server2 были в одном ethnet-сегменте, поэтому ipsec не добавлял маршрут к local2, но я пробовал прописывать маршрут к local2 через другой eth-интерфейс, это не влияло.

ок. сейчас пособираю из старого железа, тоже потестю. Спасибо огромное что не поленились у себя все это погонять

товарищи модеры, закрывайте тему, нифига я не нарыл и соотв. так и не смог поднять IPSec, плюнул и поднял на локальном mikrotik но это уже совсем другая история. спасибо всем кто помог

И это в линуксе через опу.

Офигеть.