Site-2-Site IPSec VPN

[Negociador]

Доброго дня!
Вопрос по IPSec соединению. Перерыл массу мануалов, но похоже чего-то не догоняю.
Есть локальная сеть (A) с адресом 192.168.21.0/24 В качестве маршрутизатора Mikrotik, внешний адрес y.y.y.y
На второй стороне  VSD с адресом x.x.x.x. На сервере крутится сервис, к которому необходим доступ из локальной сети (A). В качестве внутреннего интерфейса сервера используется дополнительный адрес 192.168.133.133/32 на интерфейсе lo
С микротиком вопросов не возникает. Тот же сайт по схожим настройкам соединен туннелем с Zyxel USG без проблем. С тем лишь различием, что за Zyxel реальная сеть. т.е. Я считаю, что Mikrotik настроен верно.
Вопросы начинаются с настройкой strongswan и маршрутизации.

Текущая конфигурация:
ipsec.сonf

(Нажмите, чтобы показать/скрыть)

conn park
  auto=add
  type=tunnel
  ike=aes128-sha1-modp1024
  esp=aes128-sha1-modp1024
  keyexchange=ikev2
  leftfirewall=yes
  left=х.х.х.х
  leftsubnet=192.168.133.133/32
  authby=secret
  type=tunnel
  leftprotoport=17/1701
  rightprotoport=17/1701
  right=y.y.y.y
  rightsubnet=192.168.21.0/24
  rightfirewall=yes

ip addr show

(Нажмите, чтобы показать/скрыть)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 192.168.133.133/32 scope global lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host

ip xfrm policy

(Нажмите, чтобы показать/скрыть)

src 192.168.133.133/32 dst 192.168.21.0/24 proto udp sport 1701 dport 1701
        dir out priority 370943 ptype main
        tmpl src x.x.x.x dst y.y.y.y
                proto esp spi 0x0e62d30e reqid 1 mode tunnel
src 192.168.21.0/24 dst 192.168.133.133/32 proto udp sport 1701 dport 1701
        dir fwd priority 370943 ptype main
        tmpl src y.y.y.y dst x.x.x.x
                proto esp reqid 1 mode tunnel
src 192.168.21.0/24 dst 192.168.133.133/32 proto udp sport 1701 dport 1701
        dir in priority 370943 ptype main
        tmpl src y.y.y.y dst x.x.x.x
                proto esp reqid 1 mode tunnel
src 192.168.21.0/24 dst 192.168.133.133/32 proto udp sport 1701 dport 1701
        dir fwd priority 370944 ptype main
        tmpl src y.y.y.y dst x.x.x.x
                proto esp reqid 1 mode tunnel
src 192.168.21.0/24 dst 192.168.133.133/32 proto udp sport 1701 dport 1701
        dir in priority 370944 ptype main
        tmpl src y.y.y.y dst x.x.x.x
                proto esp reqid 1 mode tunnel
src 192.168.133.133/32 dst 192.168.21.0/24 proto udp sport 1701 dport 1701
        dir out priority 370944 ptype main
        tmpl src x.x.x.x dst y.y.y.y
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main

ip xfrm state

(Нажмите, чтобы показать/скрыть)

src x.x.x.x dst y.y.y.y
        proto esp spi 0x0e62d30e reqid 1 mode tunnel
        replay-window 0 flag af-unspec
        auth-trunc hmac(sha1) 0xcdb1816e2b8033936d7715b6869e472cc860b55f 96
        enc cbc(aes) 0x449ecf93f2c4c5f18cf8e84b2a15c2dc
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src y.y.y.y dst x.x.x.x
        proto esp spi 0xc1008bb5 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0x6941e54069ba172c1964c7083bfe6544c78dba80 96
        enc cbc(aes) 0x03c7cdd659e27b704d660a8d50a6db65
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

/etc/sysctl.conf

(Нажмите, чтобы показать/скрыть)

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Что указывать в правилах Firewall NAT, учитывая, что я использую интерфейс lo в качестве ip обратной сети,
понять не могу. Вероятно в этом и есть проблема. А может в чем-то другом...

Текущий конфиг:
 /sbin/iptables -L

(Нажмите, чтобы показать/скрыть)

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  y.y.y.y      anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

sbin/iptables -t nat -L

(Нажмите, чтобы показать/скрыть)

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Туннель, вроде есть, а пингов между сетями нет..
Буду рад любым комментариям для решения проблемы...

[AnrDaemon]

адрес 192.168.133.133/32 на интерфейсе lo

чо
Пользователь добавил сообщение 01 Декабря 2020, 08:32:39:

Вероятно в этом и есть проблема.

Естественно. Создайте новый интерфейс.

[aSmile]

Я не совсем понял, зачем туннель. Ведь сеть А ходит в интернет через микротик, в т.ч. и х.х.х.х доступен. Почему на него сервис не повесить? Или надо трафик зашифровать?

[AlexDem]

В качестве внутреннего интерфейса сервера используется дополнительный адрес 192.168.133.133/32 на интерфейсе lo

По идее это не внутренний сервис, это localhost
Вот что создает VPN сервер (текущая, рабочая конфигурация, правда не Swan, а OpenVPN, но принцип думаю тот же).

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:55449 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55449 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:4552556 (4.5 MB)  TX bytes:4552556 (4.5 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.100.0.1  P-t-P:10.100.0.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:3773350 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7672594 errors:0 dropped:23109 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:622583750 (622.5 MB)  TX bytes:9588332388 (9.5 GB)


Тоесть VPN на сервере должен создать ВНУТРЕННЮЮ сеть tun (или tap), вот по ней и надо настраивать клиента для доступа к удаленной сети. Ну если я правильно понял вопрос.

[Negociador]

чо

По поводу lo - вытащил отсуда...
http://www.nsg.ru/help/static_c.php?chapter=likbez&section=Ipsec&subsection=_10

На VSD один физический интерфейс eth0. И, в принципе, ничего не мешает создать eth0:0, но я решил
упороться именно с loopback, раз уж указано, что я могу его использовать. Кроме всего, в случае eth0:0, у меня
есть подозрение, что будут кидаться arp в сторону оборудования хостера, что не совсем хорошо и его придется тщательно прикрывать фаерволом... 

Я не совсем понял, зачем туннель. Ведь сеть А ходит в интернет через микротик, в т.ч. и х.х.х.х доступен. Почему на него сервис не повесить? Или надо трафик зашифровать?

Не совсем внятно я описал задачу. Внутри VSD cервера Zabbix, и он должен снимать данные с оборудования внутри сети за микротом. Поэтому туннель в данном случае предпочтительнее.

Тоесть VPN на сервере должен создать ВНУТРЕННЮЮ сеть tun (или tap), вот по ней и надо настраивать клиента для доступа к удаленной сети. Ну если я правильно понял вопрос.

Для OpenVPN это верно, но в случае с IPsec совсем иначе. Там можно поднять виртуальные интерфейсы с обоих сторон и на их основе построить маршрутизацию - route based ipsec, но есть же примеры, когда работает и без них. Из того, что мне удалось понять: IPsec не использует стандартную маршрутизацию. Вместо них используются селекторы трафика на основе политик соединения.

[AnrDaemon]

Ваш туннель уже создаёт новый интерфейс при подключении.
Не понимаю проблемы.

[Negociador]

Ваш туннель уже создаёт новый интерфейс при подключении.

А можно привести команду которой я могу могу посмотреть этот интерфейс?
Как я понимаю, интерфейс может быть поднят, если я использую в ipsec.conf параметры
leftsourceip=
rightsourceip=

Проблема в том, что на основании моих политик туннель поднимается. Но пакеты в него не уходят. Или уходят, но не достигают цели...
В случае с микротом и zyxel: на микроте я поднимаю привила фаервола raw-> prerouting-> notrack для пакетов в(из)локальных сетей участвующих в туннеле. тем самым запрещаю пакетам в этих направлениях проходить NAT. На zyxel вообще ничего не делаю. там маршрутизатор разруливает привила автоматом. А вот что писать на стороне strongswan я не понимаю.