Я установил туннель между 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 на любой хост на 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
Любые идеи?
У меня была эта проблема раньше - и если ваш туннель работает правильно, а сторона Cisco отправляет эхо-запрос в сеть 192.168, это означает, что ваш туннель работает и передает трафик.
Если вы не можете вернуться к Cisco или сегменту 10.10, проблема не в туннеле.
Проблема, скорее всего, в том, что вы используете Ubuntu в качестве брандмауэра для 192.168 для выхода в Интернет, и поэтому iptables настроен на маскировку сетевого трафика.
Настройка по умолчанию будет чем-то вроде следующего правила nat, если 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
Обратите внимание, что строка accept предшествует строке маскарада - она соответствует первой, и пакеты не будут изменены.