forum.opennet.ru - "GRE/IPSEC over NAT" (15)

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"GRE/IPSEC over NAT"

Форум Открытые системы на сервере (Сеть. проблемы, диагностика / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"GRE/IPSEC over NAT"	+/–
Сообщение от pdn_mail (ok) on 03-Июл-17, 08:09
Здравствуйте! Прошу помощи. Есть две сетки, которые надо объединить, вот рисунок стенда на виртуалках: - http://storage5.static.itmages.ru/i/17/0630/h_1498810708_479... [host H1]----[router R1 (nat)]-----[router R2] Собственно пока требуется сделать самое простое - заставить работать GRE туннель между H1 и R2 поверх IPSEC через NAT. В качестве GRE туннеля используется протокол EoIP - https://code.google.com/archive/p/linux-eoip/ на Н1 zeoip0 - 192.168.10.1 на R2 zeoip0 - 192.168.10.2 Проблема вот в чём: IPSEC поднимается, но GRE по нему ходить не хочет. [root@R2 etc]# ipsec status Security Associations (1 up, 0 connecting): nat-t[2]: ESTABLISHED 99 minutes ago, 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2] nat-t{2}: REKEYED, TUNNEL, reqid 1, expires in 2 minutes nat-t{2}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] nat-t{3}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o nat-t{3}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] Без ната, например когда я организовываю канал между R1 и R2, я на интерфейсе R1 вижу, что GRE заворачивается в IPSEC, машинки общаются между собой. Если R1 сконфигурирован как шлюз с NAT, и канал организовываю между H1 и R2 то возникает проблема. На R1 вообще не видно пакетов ESP, туда почему-то ломится GRE: на R2 делаю ping 192.168.10.1 PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data. From 192.168.10.2 icmp_seq=1 Destination Host Unreachable From 192.168.10.2 icmp_seq=2 Destination Host Unreachable на R1 получаю: Jun 30 09:07:02 R1 kernel: TRACE: raw:PREROUTING:policy:4 IN=ens3 OUT= MAC=52:54:00:36:5c:07:52:54:00:66:16:fe:08:00 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=28345 DF PROTO=47 Jun 30 09:07:02 R1 kernel: TRACE: filter:INPUT:policy:1 IN=ens3 OUT= MAC=52:54:00:36:5c:07:52:54:00:66:16:fe:08:00 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=28345 DF PROTO=47 Jun 30 09:07:03 R1 kernel: TRACE: raw:PREROUTING:policy:4 IN=ens3 OUT= MAC=52:54:00:36:5c:07:52:54:00:66:16:fe:08:00 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=28392 DF PROTO=47 Jun 30 09:07:03 R1 kernel: TRACE: filter:INPUT:policy:1 IN=ens3 OUT= MAC=52:54:00:36:5c:07:52:54:00:66:16:fe:08:00 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=28392 DF PROTO=47 IPSEC не видно. Далее портянки конфигов и логов, думал не выкладывать, может кто-то уже знает в чём может быть дело. Но вдруг надо, так что выложу. Конфигурация шлюза R1 ничего необычного, обыкновенный маскарадинг и мониторинг [uzer@R1 ~]$ sudo iptables -nvL Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 1148 56929 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 49 3610 ACCEPT all -- ens4 ens3 0.0.0.0/0 0.0.0.0/0 [uzer@R1 ~]$ sudo iptables -nvL -t nat Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 48 3512 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0 [uzer@R1 ~]$ sudo iptables -nvL -t raw Chain PREROUTING (policy ACCEPT 517 packets, 33595 bytes) pkts bytes target prot opt in out source destination 17 1496 TRACE all -- * * 192.168.2.202 0.0.0.0/0 0 0 TRACE all -- * * 192.168.10.2 0.0.0.0/0 54 1948 TRACE all -- * * 10.0.1.2 0.0.0.0/0 ip ad 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:36:5c:07 brd ff:ff:ff:ff:ff:ff inet 192.168.2.201/24 brd 192.168.2.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe36:5c07/64 scope link valid_lft forever preferred_lft forever 3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:fe:8d:e9 brd ff:ff:ff:ff:ff:ff inet 10.0.1.1/24 brd 10.0.1.255 scope global ens4 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fefe:8de9/64 scope link valid_lft forever preferred_lft forever конфигурация хоста Н1: [root@H1 etc]# iptables -vnL Chain INPUT (policy ACCEPT 5151 packets, 1210K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 47 -- ens4 * 192.168.2.202 10.0.1.2 policy match dir in pol ipsec reqid 1 proto 50 0 0 ACCEPT 47 -- ens3 * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes) pkts bytes target prot opt in out source destination 1 98 ACCEPT 47 -- * ens4 10.0.1.2 192.168.2.202 policy match dir out pol ipsec reqid 1 proto 50 43 3122 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.202 tunnel-src 10.0.1.2 ip addr 2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:c2:cb:4d brd ff:ff:ff:ff:ff:ff inet 10.0.1.2/24 brd 10.0.1.255 scope global ens4 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fec2:cb4d/64 scope link valid_lft forever preferred_lft forever 3: zeoip0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether f2:3f:4c:42:d9:12 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global zeoip0 valid_lft forever preferred_lft forever inet6 fe80::f03f:4cff:fe42:d912/64 scope link valid_lft forever preferred_lft forever 4: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 22:97:e9:9f:85:7f brd ff:ff:ff:ff:ff:ff конфигурация хоста R2: [root@R2 etc]# iptables -vnL Chain INPUT (policy ACCEPT 5151 packets, 1210K bytes) pkts bytes target prot opt in out source destination 1 98 ACCEPT 47 -- ens3 * 10.0.1.2 192.168.2.202 policy match dir in pol ipsec reqid 1 proto 50 13 1022 ACCEPT 47 -- ens3 * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 47 -- * ens3 192.168.2.202 10.0.1.2 policy match dir out pol ipsec reqid 1 proto 50 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.202 tunnel-src 10.0.1.2 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.201 tunnel-src 192.168.2.202 ip addr 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:66:16:fe brd ff:ff:ff:ff:ff:ff inet 192.168.2.202/24 brd 192.168.2.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe66:16fe/64 scope link valid_lft forever preferred_lft forever 3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:02:78:e8 brd ff:ff:ff:ff:ff:ff inet 10.0.1.21/24 brd 10.0.1.255 scope global ens4 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe02:78e8/64 scope link valid_lft forever preferred_lft forever 4: zeoip0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 9a:50:6d:e8:be:cc brd ff:ff:ff:ff:ff:ff inet 192.168.10.2/24 scope global zeoip0 valid_lft forever preferred_lft forever inet6 fe80::9850:6dff:fee8:becc/64 scope link valid_lft forever preferred_lft forever я уже согласен с кем нибудь попробовать настроить обычный gretap с бриджем между Н1 и R2, вместо eoip, лишь бы хоть как-то заработало.
Ответить \| Правка \| Cообщить модератору

Оглавление

GRE/IPSEC over NAT, PavelR, 12:49 , 03-Июл-17, (1)

GRE/IPSEC over NAT, pdn_mail, 07:15 , 04-Июл-17, (2)

GRE/IPSEC over NAT, DN, 09:41 , 04-Июл-17, (3)

GRE/IPSEC over NAT, pdn_mail, 11:11 , 05-Июл-17, (6)

GRE/IPSEC over NAT, DN, 21:33 , 05-Июл-17, (12)

GRE/IPSEC over NAT, pdn_mail, 11:00 , 07-Июл-17, (13)

GRE/IPSEC over NAT, DN, 15:15 , 07-Июл-17, (15)

GRE/IPSEC over NAT, PavelR, 10:58 , 04-Июл-17, (4)

GRE/IPSEC over NAT, pdn_mail, 11:02 , 05-Июл-17, (5)
GRE/IPSEC over NAT, pdn_mail, 11:21 , 05-Июл-17, (7)
GRE/IPSEC over NAT, pdn_mail, 12:38 , 05-Июл-17, (8)
GRE/IPSEC over NAT, pdn_mail, 14:10 , 05-Июл-17, (9)

GRE/IPSEC over NAT, PavelR, 14:18 , 05-Июл-17, (10)
GRE/IPSEC over NAT, PavelR, 14:24 , 05-Июл-17, (11)

GRE/IPSEC over NAT, pdn_mail, 11:17 , 07-Июл-17, (14)

Сообщения по теме [Сортировка по времени | RSS]

1. "GRE/IPSEC over NAT" +/–

Сообщение от PavelR (??) on 03-Июл-17, 12:49

По сути вопроса, вам скорее всего надо пропустить трафик к 192.168.2.202 мимо NAT.
iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT
Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно.
>[uzer@R1 ~]$ sudo iptables -nvL -t nat
>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               destination
>   48  3512 MASQUERADE  all  --  *      ens3    0.0.0.0/0            0.0.0.0/0

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 04-Июл-17, 07:15

> По сути вопроса, вам скорее всего надо пропустить трафик к 192.168.2.202 мимо
> NAT.
> iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT
> Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно.
>>[uzer@R1 ~]$ sudo iptables -nvL -t nat
>>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target     prot opt in     out     source               destination
>>   48  3512 MASQUERADE  all  --  *      ens3    0.0.0.0/0            0.0.0.0/0
Нет, не то.
Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC между H1 и R2.
Во вторых R1 здесь ни при чём, через R1 должен ходить уже зашифрованный трафик между H1 и R2.
Проблема на R2 запихать GRE в IPSEC, и на R1 я должен видеть только пакеты UDP на порт 4500 и ничего более. По крайней мере в тунельном режиме IPSEC, как у меня. Но я вижу GRE пакеты.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "GRE/IPSEC over NAT" +/–

Сообщение от DN (ok) on 04-Июл-17, 09:41

> Во вторых R1 здесь ни при чём, через R1 должен ходить уже
> зашифрованный трафик между H1 и R2.
> Проблема на R2 запихать GRE в IPSEC, и на R1 я должен
> видеть только пакеты UDP на порт 4500 и ничего более. По
> крайней мере в тунельном режиме IPSEC, как у меня. Но я
> вижу GRE пакеты.
IMHO, определитесь с конечными интерфейсами GRE туннеля.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 05-Июл-17, 11:11

> IMHO, определитесь с конечными интерфейсами GRE туннеля.
Конечные интерфейсы EoIP zeoip0 на H1 и на R2 с IP 192.168.10.1 и 192.168.10.2.
EoIP ведь использует в качестве транспорта GRE. Который ходит между интерфейсами ens4 (на H1) и ens3 (на R2)
Связность через NAT должен обеспечить IPSEC.
Я вначале все данные привёл. У вас есть какие-то конкретные сомнения?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "GRE/IPSEC over NAT" +/–

Сообщение от DN (ok) on 05-Июл-17, 21:33

> Конечные интерфейсы EoIP zeoip0 на H1 и на R2 с IP 192.168.10.1
> и 192.168.10.2.
> EoIP ведь использует в качестве транспорта GRE. Который ходит между интерфейсами ens4
> (на H1) и ens3 (на R2)
> Связность через NAT должен обеспечить IPSEC.
IPSEC указали между 192.168.2.202 <---> 192.168.2.201
> Я вначале все данные привёл. У вас есть какие-то конкретные сомнения?
Сомнения должны быть у Вас, если у Вас не работает.
192.168.10.1 и 192.168.10.2, как конечные точки GRE туннеля на схеме не изображены.
http://storage5.static.itmages.ru/i/17/0630/h_1498810708_479...
Ethernet пакеты сетки 10.0.1.0/24 должны попадать в GRE туннель.
GRE пакеты с адресами 192.168.10.1 и 192.168.10.2 должны попадать в IPSEC туннель.
Где видно в IPSEC SA на R2, что GRE пакеты с адресом 192.168.10.2 попадают в IPSEC ?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

13. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 07-Июл-17, 11:00

> IPSEC указали между 192.168.2.202 <---> 192.168.2.201
> 192.168.10.1 и 192.168.10.2, как конечные точки GRE туннеля на схеме не изображены.
> http://storage5.static.itmages.ru/i/17/0630/h_1498810708_479...
У нас вышло непонимание. Поcмотрите ещё раз выхлоп ipsec status:
[root@R2 etc]# ipsec status
Security Associations (1 up, 0 connecting):
       nat-t[2]: ESTABLISHED 99 minutes ago, 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2]
       nat-t{2}:  REKEYED, TUNNEL, reqid 1, expires in 2 minutes
       nat-t{2}:   192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]
       nat-t{3}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o
       nat-t{3}:   192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]

чёрным по белому написано:
INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o
       nat-t{3}:   192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]
Извините.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "GRE/IPSEC over NAT" +/–

Сообщение от DN (ok) on 07-Июл-17, 15:15

> чёрным по белому написано:
> INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o
>        nat-t{3}:   192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]
> Извините.
То есть, у Вас все заработало ?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

4. "GRE/IPSEC over NAT" +/–

Сообщение от PavelR (??) on 04-Июл-17, 10:58

>[оверквотинг удален]
>> NAT.
>> iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT
>> Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно.
>>>[uzer@R1 ~]$ sudo iptables -nvL -t nat
>>>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>>> pkts bytes target     prot opt in     out     source               destination
>>>   48  3512 MASQUERADE  all  --  *      ens3    0.0.0.0/0            0.0.0.0/0
> Нет, не то.
> Во вторых R1 здесь ни при чём, через R1 должен ходить уже
> зашифрованный трафик между H1 и R2.
Ок, почти определились с концами туннеля.
> Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC
> между H1 и R2.
Не понял, что за сопоставление имеется ввиду и зачем.
> Проблема на R2 запихать GRE в IPSEC, и на R1 я должен
> видеть только пакеты UDP на порт 4500 и ничего более. По
> крайней мере в тунельном режиме IPSEC, как у меня. Но я
> вижу GRE пакеты.
SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2.
В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым IPSEC.
Не забудьте после отстройки туннеля закрыть файрволлом возможность отправки нешифрованного трафика, иначе этому шифрованию грош цена.
Также рекомендую strongswan и его документацию, мне показалось удобным.
При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 05-Июл-17, 11:02

> Не понял, что за сопоставление имеется ввиду и зачем.
А как работает нат на R1? затем наверное CONTRACK и нужен.
> SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то
> между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2.
> В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым
> IPSEC.
> Также рекомендую strongswan и его документацию, мне показалось удобным.
> При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло.
так я им - strongswan и делаю туннель
не знаю почему именно так он организовал туннель.
вот ipsec.conf c R2
conn nat-t
      left=192.168.2.202
      leftsubnet=192.168.2.202/32[47/0]
      leftfirewall=yes
      right=%any
      rightsubnet=10.0.1.2/32[47/0]
      auto=start
      keyexchange=ikev1
      authby=psk
      ike=aes128-sha1-modp1024!
      esp=aes128-sha1-modp1024!

вот ipsec.conf c H1

conn nat-t
      keyexchange=ikev1
      authby=psk
      ike=aes128-sha1-modp1024!
      esp=aes128-sha1-modp1024!
      left=%any
      leftfirewall=yes
      right=192.168.2.202
      rightsubnet=192.168.2.202/32[47/0]
      auto=start

срисовал под себя c
https://www.strongswan.org/testing/testresults/ikev1/nat-rw/...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 05-Июл-17, 11:21

> SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то
> между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2.
> В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым
> IPSEC.
Ничего странного в этом нет, т.к. ipsec строится через NAT.
[uzer@R2 ~]$ sudo ipsec status
Security Associations (1 up, 0 connecting):
  ipsec-eoip[2]: ESTABLISHED 3 minutes ago, 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2]
  ipsec-eoip{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c9177d1a_i c0c54ab0_o
  ipsec-eoip{1}:   192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]
[uzer@H1 ~]$ sudo ipsec status
[sudo] password for uzer:
Security Associations (1 up, 0 connecting):
  ipsec-eoip[1]: ESTABLISHED 4 minutes ago, 10.0.1.2[10.0.1.2]...192.168.2.202[192.168.2.202]
  ipsec-eoip{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0c54ab0_i c9177d1a_o
  ipsec-eoip{1}:   10.0.1.2/32[gre/0] === 192.168.2.202/32[gre/0]
а разве не так должно быть?

Подозреваю что тут на R2 правило должно быть прописано по другому, только пока понять не могу как.
Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     47   --  *      ens3    192.168.2.202        10.0.1.2             policy match dir out pol ipsec reqid 1 proto 50
    0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202
    0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.202 tunnel-src 10.0.1.2
    0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.201 tunnel-src 192.168.2.202
пока что на ping 192.168.10.1 (c R2 на H1) получаю вот что:
Jul 05 07:15:53 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0
Jul 05 07:15:53 R2 kernel: TRACE: nat:OUTPUT:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0
Jul 05 07:15:53 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0
Jul 05 07:15:53 R2 kernel: TRACE: nat:POSTROUTING:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0
Jul 05 07:15:53 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32788 DF PROTO=47 UID=0 GID=0
Jul 05 07:15:53 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32788 DF PROTO=47 UID=0 GID=0
Jul 05 07:15:54 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32805 DF PROTO=47 UID=0 GID=0
Jul 05 07:15:54 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32805 DF PROTO=47 UID=0 GID=0
Jul 05 07:15:54 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49772 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=2 UID=0 GID=0
Jul 05 07:15:54 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49772 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=2 UID=0 GID=0
Jul 05 07:15:55 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32812 DF PROTO=47 UID=0 GID=0
Jul 05 07:15:55 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32812 DF PROTO=47 UID=0 GID=0

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 05-Июл-17, 12:38

Обратил внимание, что GRE пакеты на машине R2 почему-то отсылаются не на 10.0.1.2, а на 192.168.2.201.
Странно, но возможно сам виноват, не перезагрузил eoip с новой конфигурацией.
Теперь после перезагрузки этого интерфейса, ping 192.168.10.1 на R2 вызывает такое прохождение пакетов:
ul 05 09:09:03 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0
Jul 05 09:09:03 R2 kernel: TRACE: nat:OUTPUT:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0
Jul 05 09:09:03 R2 kernel: TRACE: filter:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0
Jul 05 09:09:03 R2 kernel: TRACE: nat:POSTROUTING:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0
Jul 05 09:09:03 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=40644 DF PROTO=47 UID=0 GID=0
Jul 05 09:09:03 R2 kernel: TRACE: filter:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=40644 DF PROTO=47 UID=0 GID=0
Jul 05 09:09:04 R2 kernel: TRACE: raw:PREROUTING:policy:4 IN=ens3 OUT= MAC=52:54:00:66:16:fe:52:54:00:36:5c:07:08:00 SRC=192.168.2.201 DST=192.168.2.202 LEN=108 TOS=0x00 PREC=0x00 TTL=63 ID=60790 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88
Jul 05 09:09:04 R2 kernel: TRACE: filter:INPUT:policy:2 IN=ens3 OUT= MAC=52:54:00:66:16:fe:52:54:00:36:5c:07:08:00 SRC=192.168.2.201 DST=192.168.2.202 LEN=108 TOS=0x00 PREC=0x00 TTL=63 ID=60790 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88
Jul 05 09:09:04 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=43743 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88 UID=0 GID=0
теперь вроде заворачивается в IPSEC, но обратных посылок с H1 (10.0.1.2) пока нет.
P/S/ Зря радовался, это скорее всего согласование новых ключей было.
А на ping 192.168.10.1 вываливается на R2 следующее:
Jul 05 10:26:41 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=22875 DF PROTO=ICMP TYPE=8 CODE=0 ID=3173 SEQ=175 UID=0 GID=0
Jul 05 10:26:41 R2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=22875 DF PROTO=ICMP TYPE=8 CODE=0 ID=3173 SEQ=175 UID=0 GID=0
Jul 05 10:26:41 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9063 DF PROTO=47 UID=0 GID=0
Jul 05 10:26:41 R2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9063 DF PROTO=47 UID=0 GID=0

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 05-Июл-17, 14:10

> SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то
> между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2.
> В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым
> IPSEC.
Объясните пожалуйста на пальцах какая связь адресов между вот этим SA:
192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2]
и этим правилом:
Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes)
pkts bytes target     prot opt in     out     source               destination
   0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202
Я серьёзно.
Разве этим правилом мы не говорим что все исходящие пакеты GRE - (... 47   --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out ...)
должны заворачиваться в ipsec - (... pol ipsec mode ..) в туннель который организован между (... tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202)
Я правильно понимаю??

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "GRE/IPSEC over NAT" +/–

Сообщение от PavelR (??) on 05-Июл-17, 14:18

> Разве этим правилом мы не говорим что все исходящие пакеты GRE -
> должны заворачиваться в ipsec -
Абсолютно нет. В IPSEC трафик заворачивается на основании совпадения трафика с SA (security association).
В файрволле вы можете только проверить, был/будет ли этот трафик зашифрован, и, соответственно, запретить передачу/получение нешифрованных данных.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "GRE/IPSEC over NAT" +/–

Сообщение от PavelR (??) on 05-Июл-17, 14:24

> policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src
> 192.168.2.202
Лично я считаю, что просто достаточно проверять
-A UPLINK_OUT -m policy --dir out --pol ipsec -j RETURN ### IPSEC traffic
-A UPLINK_OUT -s xx.xx.xx.xx/32 -d y.y.y.0/24 -m comment --comment "Not IPsecured traffic" -j DROP
-A UPLINK_OUT -o eth0 -j RJ_BOGON  ### aka ACCEPT
т.е. без филигранного шаблона проверки "трафик пошел именно в тот туннель" и "в том mode":
1) других туннелей-то и нету :-)
2) У меня в конфиге явно прописаны leftsubnet/rightsubnet, так что тоже без вариантов.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "GRE/IPSEC over NAT" +/–

Сообщение от pdn_mail (ok) on 07-Июл-17, 11:17

Кажется понял.
Похоже не удастся запустить EoIP с помощью этой штуки - https://code.google.com/archive/p/linux-eoip/
На R2 используется два интерфейса, один ens3 с IP 192.168.2.202 смотрящий в сеть с сервером NAT за которым сидит клиент H1 с IP 10.0.1.2,
и второй, ens4 с IP 10.0.1.21 смотрящий в локальную сеть. Так вот, эта тулза linux-eoip когда задаёшь адрес назначения клиента H1 с IP 10.0.1.2, садится на интерфейс ens4 и начинает слать пакеты в локальную сеть. Как её заставить сесть на интерфейс ens3 c IP 192.168.2.202 документации нет, а в исходники лазить я не силён.
Два варианта, найти нормальный модуль EoIP для Linux, либо настраивать чистый GRE, но предпочтительней EoIP, если получится.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "GRE/IPSEC over NAT"	+/–
Сообщение от PavelR (??) on 03-Июл-17, 12:49
По сути вопроса, вам скорее всего надо пропустить трафик к 192.168.2.202 мимо NAT. iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно. >[uzer@R1 ~]$ sudo iptables -nvL -t nat >Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source destination > 48 3512 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 04-Июл-17, 07:15
	> По сути вопроса, вам скорее всего надо пропустить трафик к 192.168.2.202 мимо > NAT. > iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT > Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно. >>[uzer@R1 ~]$ sudo iptables -nvL -t nat >>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source destination >> 48 3512 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0 Нет, не то. Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC между H1 и R2. Во вторых R1 здесь ни при чём, через R1 должен ходить уже зашифрованный трафик между H1 и R2. Проблема на R2 запихать GRE в IPSEC, и на R1 я должен видеть только пакеты UDP на порт 4500 и ничего более. По крайней мере в тунельном режиме IPSEC, как у меня. Но я вижу GRE пакеты.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "GRE/IPSEC over NAT"	+/–
	Сообщение от DN (ok) on 04-Июл-17, 09:41
	> Во вторых R1 здесь ни при чём, через R1 должен ходить уже > зашифрованный трафик между H1 и R2. > Проблема на R2 запихать GRE в IPSEC, и на R1 я должен > видеть только пакеты UDP на порт 4500 и ничего более. По > крайней мере в тунельном режиме IPSEC, как у меня. Но я > вижу GRE пакеты. IMHO, определитесь с конечными интерфейсами GRE туннеля.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 05-Июл-17, 11:11
	> IMHO, определитесь с конечными интерфейсами GRE туннеля. Конечные интерфейсы EoIP zeoip0 на H1 и на R2 с IP 192.168.10.1 и 192.168.10.2. EoIP ведь использует в качестве транспорта GRE. Который ходит между интерфейсами ens4 (на H1) и ens3 (на R2) Связность через NAT должен обеспечить IPSEC. Я вначале все данные привёл. У вас есть какие-то конкретные сомнения?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	12. "GRE/IPSEC over NAT"	+/–
	Сообщение от DN (ok) on 05-Июл-17, 21:33
	> Конечные интерфейсы EoIP zeoip0 на H1 и на R2 с IP 192.168.10.1 > и 192.168.10.2. > EoIP ведь использует в качестве транспорта GRE. Который ходит между интерфейсами ens4 > (на H1) и ens3 (на R2) > Связность через NAT должен обеспечить IPSEC. IPSEC указали между 192.168.2.202 <---> 192.168.2.201 > Я вначале все данные привёл. У вас есть какие-то конкретные сомнения? Сомнения должны быть у Вас, если у Вас не работает. 192.168.10.1 и 192.168.10.2, как конечные точки GRE туннеля на схеме не изображены. http://storage5.static.itmages.ru/i/17/0630/h_1498810708_479... Ethernet пакеты сетки 10.0.1.0/24 должны попадать в GRE туннель. GRE пакеты с адресами 192.168.10.1 и 192.168.10.2 должны попадать в IPSEC туннель. Где видно в IPSEC SA на R2, что GRE пакеты с адресом 192.168.10.2 попадают в IPSEC ?
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	13. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 07-Июл-17, 11:00
	> IPSEC указали между 192.168.2.202 <---> 192.168.2.201 > 192.168.10.1 и 192.168.10.2, как конечные точки GRE туннеля на схеме не изображены. > http://storage5.static.itmages.ru/i/17/0630/h_1498810708_479... У нас вышло непонимание. Поcмотрите ещё раз выхлоп ipsec status: [root@R2 etc]# ipsec status Security Associations (1 up, 0 connecting): nat-t[2]: ESTABLISHED 99 minutes ago, 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2] nat-t{2}: REKEYED, TUNNEL, reqid 1, expires in 2 minutes nat-t{2}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] nat-t{3}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o nat-t{3}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] чёрным по белому написано: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o nat-t{3}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] Извините.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	15. "GRE/IPSEC over NAT"	+/–
	Сообщение от DN (ok) on 07-Июл-17, 15:15
	> чёрным по белому написано: > INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6b99c38_i cff55aa7_o > nat-t{3}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] > Извините. То есть, у Вас все заработало ?
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	4. "GRE/IPSEC over NAT"	+/–
	Сообщение от PavelR (??) on 04-Июл-17, 10:58
	>[оверквотинг удален] >> NAT. >> iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT >> Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно. >>>[uzer@R1 ~]$ sudo iptables -nvL -t nat >>>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) >>> pkts bytes target prot opt in out source destination >>> 48 3512 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0 > Нет, не то. > Во вторых R1 здесь ни при чём, через R1 должен ходить уже > зашифрованный трафик между H1 и R2. Ок, почти определились с концами туннеля. > Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC > между H1 и R2. Не понял, что за сопоставление имеется ввиду и зачем. > Проблема на R2 запихать GRE в IPSEC, и на R1 я должен > видеть только пакеты UDP на порт 4500 и ничего более. По > крайней мере в тунельном режиме IPSEC, как у меня. Но я > вижу GRE пакеты. SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым IPSEC. Не забудьте после отстройки туннеля закрыть файрволлом возможность отправки нешифрованного трафика, иначе этому шифрованию грош цена. Также рекомендую strongswan и его документацию, мне показалось удобным. При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 05-Июл-17, 11:02
	> Не понял, что за сопоставление имеется ввиду и зачем. А как работает нат на R1? затем наверное CONTRACK и нужен. > SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то > между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. > В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым > IPSEC. > Также рекомендую strongswan и его документацию, мне показалось удобным. > При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло. так я им - strongswan и делаю туннель не знаю почему именно так он организовал туннель. вот ipsec.conf c R2 conn nat-t left=192.168.2.202 leftsubnet=192.168.2.202/32[47/0] leftfirewall=yes right=%any rightsubnet=10.0.1.2/32[47/0] auto=start keyexchange=ikev1 authby=psk ike=aes128-sha1-modp1024! esp=aes128-sha1-modp1024! вот ipsec.conf c H1 conn nat-t keyexchange=ikev1 authby=psk ike=aes128-sha1-modp1024! esp=aes128-sha1-modp1024! left=%any leftfirewall=yes right=192.168.2.202 rightsubnet=192.168.2.202/32[47/0] auto=start срисовал под себя c https://www.strongswan.org/testing/testresults/ikev1/nat-rw/...
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	7. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 05-Июл-17, 11:21
	> SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то > между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. > В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым > IPSEC. Ничего странного в этом нет, т.к. ipsec строится через NAT. [uzer@R2 ~]$ sudo ipsec status Security Associations (1 up, 0 connecting): ipsec-eoip[2]: ESTABLISHED 3 minutes ago, 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2] ipsec-eoip{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c9177d1a_i c0c54ab0_o ipsec-eoip{1}: 192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0] [uzer@H1 ~]$ sudo ipsec status [sudo] password for uzer: Security Associations (1 up, 0 connecting): ipsec-eoip[1]: ESTABLISHED 4 minutes ago, 10.0.1.2[10.0.1.2]...192.168.2.202[192.168.2.202] ipsec-eoip{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0c54ab0_i c9177d1a_o ipsec-eoip{1}: 10.0.1.2/32[gre/0] === 192.168.2.202/32[gre/0] а разве не так должно быть? Подозреваю что тут на R2 правило должно быть прописано по другому, только пока понять не могу как. Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 47 -- * ens3 192.168.2.202 10.0.1.2 policy match dir out pol ipsec reqid 1 proto 50 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.202 tunnel-src 10.0.1.2 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 192.168.2.201 tunnel-src 192.168.2.202 пока что на ping 192.168.10.1 (c R2 на H1) получаю вот что: Jul 05 07:15:53 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0 Jul 05 07:15:53 R2 kernel: TRACE: nat:OUTPUT:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0 Jul 05 07:15:53 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0 Jul 05 07:15:53 R2 kernel: TRACE: nat:POSTROUTING:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49603 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=1 UID=0 GID=0 Jul 05 07:15:53 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32788 DF PROTO=47 UID=0 GID=0 Jul 05 07:15:53 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32788 DF PROTO=47 UID=0 GID=0 Jul 05 07:15:54 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32805 DF PROTO=47 UID=0 GID=0 Jul 05 07:15:54 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32805 DF PROTO=47 UID=0 GID=0 Jul 05 07:15:54 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49772 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=2 UID=0 GID=0 Jul 05 07:15:54 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49772 DF PROTO=ICMP TYPE=8 CODE=0 ID=2931 SEQ=2 UID=0 GID=0 Jul 05 07:15:55 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32812 DF PROTO=47 UID=0 GID=0 Jul 05 07:15:55 R2 kernel: TRACE: filter:OUTPUT:policy:5 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=32812 DF PROTO=47 UID=0 GID=0
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	8. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 05-Июл-17, 12:38
	Обратил внимание, что GRE пакеты на машине R2 почему-то отсылаются не на 10.0.1.2, а на 192.168.2.201. Странно, но возможно сам виноват, не перезагрузил eoip с новой конфигурацией. Теперь после перезагрузки этого интерфейса, ping 192.168.10.1 на R2 вызывает такое прохождение пакетов: ul 05 09:09:03 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0 Jul 05 09:09:03 R2 kernel: TRACE: nat:OUTPUT:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0 Jul 05 09:09:03 R2 kernel: TRACE: filter:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0 Jul 05 09:09:03 R2 kernel: TRACE: nat:POSTROUTING:policy:1 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28045 DF PROTO=ICMP TYPE=8 CODE=0 ID=3106 SEQ=1 UID=0 GID=0 Jul 05 09:09:03 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=40644 DF PROTO=47 UID=0 GID=0 Jul 05 09:09:03 R2 kernel: TRACE: filter:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=40644 DF PROTO=47 UID=0 GID=0 Jul 05 09:09:04 R2 kernel: TRACE: raw:PREROUTING:policy:4 IN=ens3 OUT= MAC=52:54:00:66:16:fe:52:54:00:36:5c:07:08:00 SRC=192.168.2.201 DST=192.168.2.202 LEN=108 TOS=0x00 PREC=0x00 TTL=63 ID=60790 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88 Jul 05 09:09:04 R2 kernel: TRACE: filter:INPUT:policy:2 IN=ens3 OUT= MAC=52:54:00:66:16:fe:52:54:00:36:5c:07:08:00 SRC=192.168.2.201 DST=192.168.2.202 LEN=108 TOS=0x00 PREC=0x00 TTL=63 ID=60790 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88 Jul 05 09:09:04 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens3 SRC=192.168.2.202 DST=192.168.2.201 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=43743 DF PROTO=UDP SPT=4500 DPT=4500 LEN=88 UID=0 GID=0 теперь вроде заворачивается в IPSEC, но обратных посылок с H1 (10.0.1.2) пока нет. P/S/ Зря радовался, это скорее всего согласование новых ключей было. А на ping 192.168.10.1 вываливается на R2 следующее: Jul 05 10:26:41 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=22875 DF PROTO=ICMP TYPE=8 CODE=0 ID=3173 SEQ=175 UID=0 GID=0 Jul 05 10:26:41 R2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=zeoip0 SRC=192.168.10.2 DST=192.168.10.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=22875 DF PROTO=ICMP TYPE=8 CODE=0 ID=3173 SEQ=175 UID=0 GID=0 Jul 05 10:26:41 R2 kernel: TRACE: raw:OUTPUT:policy:4 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9063 DF PROTO=47 UID=0 GID=0 Jul 05 10:26:41 R2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=ens4 SRC=10.0.1.21 DST=10.0.1.2 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9063 DF PROTO=47 UID=0 GID=0
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	9. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 05-Июл-17, 14:10
	> SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то > между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. > В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым > IPSEC. Объясните пожалуйста на пальцах какая связь адресов между вот этим SA: 192.168.2.202[192.168.2.202]...192.168.2.201[10.0.1.2] и этим правилом: Chain OUTPUT (policy ACCEPT 766 packets, 139K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202 Я серьёзно. Разве этим правилом мы не говорим что все исходящие пакеты GRE - *(... 47 -- * 0.0.0.0/0 0.0.0.0/0 policy match dir out ...) должны заворачиваться в ipsec - (... pol ipsec mode ..) в туннель который организован между (... tunnel tunnel-dst 10.0.1.2 tunnel-src 192.168.2.202)** Я правильно понимаю??
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	10. "GRE/IPSEC over NAT"	+/–
	Сообщение от PavelR (??) on 05-Июл-17, 14:18
	> Разве этим правилом мы не говорим что все исходящие пакеты GRE - > должны заворачиваться в ipsec - Абсолютно нет. В IPSEC трафик заворачивается на основании совпадения трафика с SA (security association). В файрволле вы можете только проверить, был/будет ли этот трафик зашифрован, и, соответственно, запретить передачу/получение нешифрованных данных.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "GRE/IPSEC over NAT"	+/–
	Сообщение от PavelR (??) on 05-Июл-17, 14:24
	> policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src > 192.168.2.202 Лично я считаю, что просто достаточно проверять -A UPLINK_OUT -m policy --dir out --pol ipsec -j RETURN ### IPSEC traffic -A UPLINK_OUT -s xx.xx.xx.xx/32 -d y.y.y.0/24 -m comment --comment "Not IPsecured traffic" -j DROP -A UPLINK_OUT -o eth0 -j RJ_BOGON ### aka ACCEPT т.е. без филигранного шаблона проверки "трафик пошел именно в тот туннель" и "в том mode": 1) других туннелей-то и нету :-) 2) У меня в конфиге явно прописаны leftsubnet/rightsubnet, так что тоже без вариантов.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	14. "GRE/IPSEC over NAT"	+/–
	Сообщение от pdn_mail (ok) on 07-Июл-17, 11:17
	Кажется понял. Похоже не удастся запустить EoIP с помощью этой штуки - https://code.google.com/archive/p/linux-eoip/ На R2 используется два интерфейса, один ens3 с IP 192.168.2.202 смотрящий в сеть с сервером NAT за которым сидит клиент H1 с IP 10.0.1.2, и второй, ens4 с IP 10.0.1.21 смотрящий в локальную сеть. Так вот, эта тулза linux-eoip когда задаёшь адрес назначения клиента H1 с IP 10.0.1.2, садится на интерфейс ens4 и начинает слать пакеты в локальную сеть. Как её заставить сесть на интерфейс ens3 c IP 192.168.2.202 документации нет, а в исходники лазить я не силён. Два варианта, найти нормальный модуль EoIP для Linux, либо настраивать чистый GRE, но предпочтительней EoIP, если получится.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору