LINUX.ORG.RU
Форум — Admin  

Роутинг до локальной сети от шлюза ipsec

 ,


0

1

Добрый день! Настроил ipsec ikev2 для соединения сетей. Сеть 1: 192.168.210.0/24 gw 192.168.210.1 Сеть 2: 192.168.220.0/24 gw 192.168.220.1

ipsec-соединение устанавливает strongswan на ubuntu (Ip 192.168.220.2). Слушает ipsec-cервер роутер Zyxel - 192.168.210.1, он же основной роутер сети. На роутере 192.168.220.1 прописал роут до сети 192.168.210.0/24.

Соединение 192.168.220.2 <=> 192.168.210.1 устанавливается, но пинги и соединения идут соответственно из сети 192.168.210.0/24 только до одной машины 192.168.220.2. И наоборот соединения есть только с машины 192.168.220.2 до любого устройства в сети 192.168.210.0/24.

Подскажите, пожалуйста, куда копать?

ipsec.conf 

config setup

conn %default
  ikelifetime=60m
  rekeymargin=3m
  keyingtries=%forever
  keyexchange=ikev2
  ike=aes128-sha1-modp2048,3des-sha1-modp1536!
  esp=aes128-sha1,3des-sha1!
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s

conn myvpn
  keyexchange=ikev2
  left=%any
  leftid=%any
  leftsubnet=192.168.220.0/24
  auto=start
  leftfirewall=yes
  right=x.x.x.x
  rightsubnet=192.168.210.0/24
  rightid=%any
  leftauth=psk
  rightauth=psk

таблица маршрутизации роутера 192.168.220.1 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.210.0   192.168.220.2   255.255.255.0   UG    1      0        0 LAN
192.168.220.0   *               255.255.255.0   U     0      0        0 LAN
default         x.x.x.x   0.0.0.0         UG    0      0        0 WAN

192.168.220.2 ip route list 

default via 192.168.220.1 dev eth2  metric 100
192.168.220.0/24 dev eth2  proto kernel  scope link  src 192.168.220.2

192.168.220.2 ip route list table 220 

192.168.210.0/24 via 192.168.220.1 dev eth2  proto static  src 192.168.220.2

192.168.220.2 ip xfrm policy 

src 192.168.220.0/24 dst 192.168.210.0/24
        dir out priority 375423
        tmpl src 192.168.220.2 dst xx.xxx.xxx.xxx
                proto esp spi 0xc93d24a8 reqid 1 mode tunnel
src 192.168.210.0/24 dst 192.168.220.0/24
        dir fwd priority 375423
        tmpl src xx.xxx.xxx.xxx dst 192.168.220.2
                proto esp reqid 1 mode tunnel
src 192.168.210.0/24 dst 192.168.220.0/24
        dir in priority 375423
        tmpl src xx.xxx.xxx.xxx dst 192.168.220.2
                proto esp reqid 1 mode tunnel
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 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

192.168.220.2 iptables -L 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  192.168.210.0/24     192.168.220.0/24     policy match dir in pol ipsec reqid 1 proto esp
ACCEPT     all  --  192.168.220.0/24     192.168.210.0/24     policy match dir out pol ipsec reqid 1 proto esp

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

тут я пытаюсь пинговать из сети 192.168.210.0: 

Обмен пакетами с 192.168.220.1 по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

Статистика Ping для 192.168.220.1:
    Пакетов: отправлено = 4, получено = 0, потеряно = 4
    (100% потерь)

В этот момент на 192.168.220.2 tcpdump -vvv -n -i eth2 icmp and src net 192.168.0.0/16 and dst net 192.168.0.0/16 

tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
20:50:29.894321 IP (tos 0x0, ttl 127, id 12657, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.210.130 > 192.168.220.1: ICMP echo request, id 1, seq 110, length 40
20:50:34.867746 IP (tos 0x0, ttl 127, id 12658, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.210.130 > 192.168.220.1: ICMP echo request, id 1, seq 111, length 40
20:50:39.866282 IP (tos 0x0, ttl 127, id 12659, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.210.130 > 192.168.220.1: ICMP echo request, id 1, seq 112, length 40
20:50:44.866513 IP (tos 0x0, ttl 127, id 12660, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.210.130 > 192.168.220.1: ICMP echo request, id 1, seq 113, length 40
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel



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

То есть c 192.168.220.2 в eth2 пакеты ушли уже нешифрованные - это нормально в твоей конфигурации?

Покажи iptables -vn -L FORWARD - надо посмотреть идёт ли что-то по счетчикам тех правил.

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

192.168.220.2 в eth2 смотря куда, интерфейс один, шифрование должено быть между 192.168.220.2 <=> 192.168.210.2

root@Server:~# iptables -vn -L FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth2   *       192.168.210.0/24     192.168.220.0/24     policy match dir in pol ipsec reqid 3 proto 50
    0     0 ACCEPT     all  --  *      eth2    192.168.220.0/24     192.168.210.0/24     policy match dir out pol ipsec reqid 3 proto 50
PaulZi
() автор топика

ipsec-соединение устанавливает strongswan на ubuntu (Ip 192.168.220.2).

А ip_forward на ней включён вообще?

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

То есть c 192.168.220.2 в eth2 пакеты ушли уже нешифрованные

Там вроде есть особенности -

Capturing traffic with tcpdump or wireshark by listening on a normal network interface shows encapslated
and decapsulated IPsec traffic only for inbound traffic. For outbound traffic only the encrypted traffic is seen.
This is because of how the capturing socket used by the aforementioned tools (or rather libpcap) work.

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

Слона то я и не заметил, был в полной уверенности, что всё включено давно. Спасибо, всё заработало!

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

Век живи - век учись! Про то, что tcpdump работает ДО файрвола знал, теперь вот знаю что в туннельном режиме есть такая особенность. У меня везде просто транспортный(GRE over IPSEC), поэтому такие тонкости для меня в новинку.

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