Здравствуйте!
Прошу помощи.Есть две сетки, которые надо объединить, вот рисунок стенда на виртуалках: - 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[u]Проблема вот в чём:
IPSEC поднимается, но GRE по нему ходить не хочет.[/u][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 ad2: 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 ipsecChain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain 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 addr2: 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 ipsecChain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain 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 addr2: 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, лишь бы хоть как-то заработало.
По сути вопроса, вам скорее всего надо пропустить трафик к 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
> По сути вопроса, вам скорее всего надо пропустить трафик к 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 пакеты.
> Во вторых R1 здесь ни при чём, через R1 должен ходить уже
> зашифрованный трафик между H1 и R2.
> Проблема на R2 запихать GRE в IPSEC, и на R1 я должен
> видеть только пакеты UDP на порт 4500 и ничего более. По
> крайней мере в тунельном режиме IPSEC, как у меня. Но я
> вижу GRE пакеты.IMHO, определитесь с конечными интерфейсами GRE туннеля.
> IMHO, определитесь с конечными интерфейсами GRE туннеля.Конечные интерфейсы EoIP zeoip0 на H1 и на R2 с IP 192.168.10.1 и 192.168.10.2.
EoIP ведь использует в качестве транспорта GRE. Который ходит между интерфейсами ens4 (на H1) и ens3 (на R2)
Связность через NAT должен обеспечить IPSEC.Я вначале все данные привёл. У вас есть какие-то конкретные сомнения?
> Конечные интерфейсы 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 ?
> 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]Извините.
> чёрным по белому написано:
> 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]
> Извините.То есть, у Вас все заработало ?
>[оверквотинг удален]
>> 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-ов проблем вообще не возникло.
> Не понял, что за сопоставление имеется ввиду и зачем.А как работает нат на 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/...
> 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
Обратил внимание, что 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
> 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)Я правильно понимаю??
> Разве этим правилом мы не говорим что все исходящие пакеты GRE -
> должны заворачиваться в ipsec -Абсолютно нет. В IPSEC трафик заворачивается на основании совпадения трафика с SA (security association).
В файрволле вы можете только проверить, был/будет ли этот трафик зашифрован, и, соответственно, запретить передачу/получение нешифрованных данных.
> policy match dir out pol ipsec mode tunnel tunnel-dst 10.0.1.2 tunnel-src
> 192.168.2.202[/b]Лично я считаю, что просто достаточно проверять
-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, так что тоже без вариантов.
Кажется понял.
Похоже не удастся запустить 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, если получится.