Туннель IPSEC с OpenSwan на Ubuntu <-> CISCO Router

Я настроил туннель между Linux-боксом UBUNTU SERVER и CISCO ROUTER.

Вот как выглядит топология:

host 1 ------ UBUNTU SERVER IPSEC <---> CISCO ROUTER ------ host 2
   |                    |                      |               |
   |                    |                      |               |
192.168.64.0/24      1.2.3.4                4.3.2.1      10.10.20.0/24

Вот моя проблема: туннель настроен и работает правильно. Я могу определенно пропинговать от CISCO ROUTER к любому хосту на 192.168.64.0/24 сеть. Но я не могу пинговать от 192.168.64.0/24 сеть к любому хосту на 10.10.20.0/24 сеть.

Вот некоторая информация:

ipsec.conf:

conn my_vpn
auto=start
authby=secret
ike=aes256-md5
phase2=esp
phase2alg=aes256-md5
type=tunnel
left=1.2.3.4
leftsubnet=192.168.64.0/24
    leftnexthop=%defaultroute
leftupdown="ipsec _updown --route yes"
keyingtries=3
keyexchange=ike
pfs=no
    right=4.3.2.1
    rightsubnet=10.10.20.0/24

Вывод команды ipsec look:

XFRM state:
src 4.3.2.1 dst 1.2.3.4
    proto esp spi 0x0f9898dd reqid 16385 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(md5) 0xSOMEVALUE
    enc cbc(aes) 0xSOMEOHTERVALUE
src 1.2.3.4 dst 4.3.2.1
    proto esp spi 0x667b62d8 reqid 16385 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(md5) 0xSOMEVALUE
    enc cbc(aes) 0xSOMEOHTERVALUE
XFRM policy:
src 192.168.64.0/24 dst 10.10.20.0/24 
    dir out priority 2344 
    tmpl src 1.2.3.4 dst 4.3.2.1
        proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24 
    dir fwd priority 2344 
    tmpl src 4.3.2.1 dst 1.2.3.4
        proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24 
    dir in priority 2344 
    tmpl src 4.3.2.1 dst 1.2.3.4
        proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
XFRM done
IPSEC mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
NEW_IPSEC_CONN mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ROUTING TABLES
default dev ppp0  scope link 
10.10.20.0/24 via 1.2.3.GW dev ppp0 
1.2.3.GW dev ppp0  proto kernel  scope link  src 1.2.3.4

куда 1.2.3.GW является 1.2.3.4Ворота.

Вывод команды ipsec verify:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.2.0-38-generic-pae (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [OK]
    [OK]
    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [FAILED]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking NAT and MASQUERADEing                                  [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Я должен добавить: UBUNTU имеет ppp0 соединение с публичным IP-адресом: 1.2.3.4,

Статическая информация о маршруте:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
10.10.20.0      1.2.3.GW        255.255.255.0   UG        0 0          0 ppp0

Есть идеи?

Источник

1 ответ

У меня уже была эта проблема - и если ваш туннель работает правильно, а сторона Cisco выполняет команду ping в сеть 192.168, это означает, что ваш туннель работает и пропускает трафик.

Если вы не можете пропинговать Cisco или сегмент 10.10, проблема не в туннеле.

Проблема, скорее всего, в том, что вы используете Ubuntu в качестве брандмауэра для 192.168 для доступа в Интернет, и поэтому iptables настроен для маскировки сетевого трафика.

Настройка по умолчанию будет выглядеть следующим образом: при условии, что eth1 является открытым интерфейсом:

iptables -A POSTROUTING -o eth1 -j MASQUERADE

Проблема в том, что трафик ipsec также выходит из eth1, так что вы тоже пытаетесь это маскировать.

Вставьте правило перед правилом маскарада, указав, что трафик ipsec не должен маскироваться, а просто приниматься, а strongswan сделает все остальное:

iptables -I POSTROUTING 1 -d 10.10.20.0/24 -o eth1 -j ACCEPT

так работает iptables -L -v -n -t nat должен дать вам следующее:

Chain PREROUTING (policy ACCEPT 8875K packets, 566M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 4898K packets, 325M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1089K packets, 82M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 1412 packets, 119K bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   336 ACCEPT     all  --  *      eth1    0.0.0.0/0            10.10.20.0/24
 101M 6481M MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0

Обратите внимание, что строка подтверждения предшествует строке маскарада - она ​​сначала совпадает, и пакеты не будут изменены.

Источник
Другие вопросы по тегам