Перейти к содержанию
Как правильно добавить self-test и прочую отладку в тему
Официальное хранилище ПО в виде файлов

Как настроить IPSec/GRE туннель c Linux и пробросить по туннелю порт?

pdn_mail
 Поделиться

Рекомендуемые сообщения

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
Опубликовано (изменено)

Здравствуйте!

Случилась оказия завести сервер который сидит за серым IP и потребовалось пробросить на него порт по туннелю от шлюза с белым IP. 
Схема один в один как в статье http://blog.kvv213.com/2017/03/podklyuchaemsya-k-udalennomu-routeru-zyxel-po-ipsec-vpn-cherez-strongswan-na-headless-ubuntu-14lts/
за некоторым исключением: туннель GRE/IPSec на strongswan.

Туннель устанавливается, тут всё нормально:

 ipsec-eoip{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6644240_i c9bb72d4_o
 ipsec-eoip{1}:   192.168.2.2/32 === 192.168.0.1/32

а вот дальше, как пробросить порт начинаю буксовать:

во первых не видят друг друга концы туннеля, с левой машины на ping 192.168.100.1 тишина.... From 192.168.100.2 icmp_seq=1 Destination Host Unreachable

во вторых, проброска порта, но до этого пока не доходит. из-за во первых...

где что я не доделал или накосячил? Что сделать чтобы концы туннеля GRE друг друга увидели?

слева на машине linux: ip addr

  
	1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
   link/ether 00:1a:64:94:68:74 brd ff:ff:ff:ff:ff:ff
   inet 192.168.2.2/24 brd 192.168.2.255 scope global enp4s0
...
3: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether 00:1a:64:94:68:76 brd ff:ff:ff:ff:ff:ff
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
   link/gre 0.0.0.0 brd 0.0.0.0
5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
   link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: grelan@enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether 46:cf:f7:8f:fc:58 brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.2/24 scope global grelan
....


слева: ip route

default via 192.168.100.1 dev grelan  
(БЕЛЫЙ IP Zyxel) via 192.168.2.1 dev enp4s0  
192.168.2.0/24 dev enp4s0 proto kernel scope link src 192.168.2.2  
192.168.100.0/24 dev grelan proto kernel scope link src 192.168.100.2

Изменено пользователем pdn_mail
pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

Вот концовка сообщения


справа: Zyxel Giga II версия 2.09 

(config)> int Gre0 
Network::Interface::Repository: Created interface Gre0.
(config-if)> tunnel destination 192.168.2.2
Network::Interface::Tunnel: Destination set to 192.168.2.2.
(config-if)> ip address 192.168.100.1 255.255.255.0
Network::Interface::IP: "Gre0": IP address is 192.168.100.1/24.
(config-if)> up
Network::Interface::Base: "Gre0": interface is up.
(config-if)> security-level private 
Network::Interface::IP: "Gre0": security level set to "private".
(config-if)> no isolate-private
Netfilter::Manager: Private networks not isolated.
(config)> 

проброска порта - ip static tcp ISP 80 192.168.100.2 80 !http:80

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано

У вас TS неправильные, если вы pptp-ipsec пытаетесь использовать для защиты туннеля. В итоге туннель уходит в Интернет "голышом".

Сами смотрите:

Jul 21 16:14:24 ndm: Network::Interface::Tunnel: "Gre0": resolved destination 192.168.2.2 (192.168.2.2).
Jul 21 16:14:24 ndm: Network::Interface::Tunnel: "Gre0": resolved source 4X.2YZ.10.2.

И

Jul 21 16:03:31 ipsec: 12[IKE] CHILD_SA pptp-ipsec{29} established with SPIs c9bb72d4_i c6644240_o and TS 192.168.0.1/32 === 192.168.2.2/32 

Плюс ко всему вам нужен транспортный режим IPsec, и в TS укажите gre протокол вместо ip (в него у вас будет весь трафик заворачиваться, не только GRE).

access-list _WEBADMIN_IPSEC_pptp-ipsec
    permit gre 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
! 

Короче еще раз внимательно подумайте о настройках и все поправьте.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано (изменено)

Спасибо!

Добавил в настройки интерфейса Gre0 команду 

(config-if)> tunnel source 192.168.0.1

Gre потом один оставлю, Пока осталось с заворотом порта разобраться, про него чуть позже спрошу, как конфигурацию поковыряю, а сейчас можно вопрос?

Зачем нужен транспортный режим? Мне он разве даст через NAT работать? На схеме, что в ссылке дана в начале, слева перед сервером неадминистрируемый роутер с NAT.

Просто в этой схеме если вместо Zyxel использовать машинку с linux, то всё замечательно в режиме туннеля работает. Вот почему такой вопрос возник.

Изменено пользователем pdn_mail
pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

Добрый день!

Можно сказать почти у цели если бы не одно НО, не работает туннель так как надо.

Между двумя linux машинами эта конфигурация работает, а вот linux в паре с Zyxeleм артачится.  Пытаюсь пропинговать другой конец туннеля, мне возвращается: 

(config)> tools ping 192.168.100.2
sending ICMP ECHO request to 192.168.100.2...
PING 192.168.100.2 (192.168.100.2) 56 (84) bytes of data.
"Destination unreachable" ICMP packet received from 192.168.2.2 (type = 3, code = 3).
"Destination unreachable" ICMP packet received from 192.168.2.2 (type = 3, code = 3).

не пойму, что Zyxel отправляет такого, что linux не может понять куда направить пакет?

Когда между двумя машинками работает схема, то на машине за серым IP трассировка iptables ловит следующую последовательность пакетов:

Скрытый текст

июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:policy:5 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=46.X.Y.Z DST=192.168.2.2 LEN=176 TOS=0x00 PREC=0x00 TTL=56 ID=35069 DF PROTO=UDP SPT=4500 DPT=4500 LEN=156 
июл 25 17:37:48 arch2 kernel: TRACE: filter:INPUT:policy:3 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=46.X.Y.Z DST=192.168.2.2 LEN=176 TOS=0x00 PREC=0x00 TTL=56 ID=35069 DF PROTO=UDP SPT=4500 DPT=4500 LEN=156 
июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:rule:3 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 
июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:policy:5 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 
июл 25 17:37:48 arch2 kernel: TRACE: filter:INPUT:rule:1 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ] 
июл 25 17:37:48 arch2 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ] 
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188 
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188 
июл 25 17:37:48 arch2 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188

Между машинками linux последовательность пакетов на машинке за серым IP выглядит так:

Скрытый текст

Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=192.168.2.202 DST=10.0.1.2 LEN=192 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172 
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:policy:2 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=192.168.2.202 DST=10.0.1.2 LEN=192 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172 
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:rule:1 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:rule:5 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:rule:1 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=grelan OUT= MAC=4a:d6:f9:19:3e:36:32:cf:6f:83:fb:5f:08:00 SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=48128 DF PROTO=ICMP TYPE=8 CODE=0 ID=647 SEQ=1 
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:policy:2 IN=grelan OUT= MAC=4a:d6:f9:19:3e:36:32:cf:6f:83:fb:5f:08:00 SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=48128 DF PROTO=ICMP TYPE=8 CODE=0 ID=647 SEQ=1 
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=grelan SRC=192.168.100.1 DST=192.168.100.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=26909 PROTO=ICMP TYPE=0 CODE=0 ID=647 SEQ=1 
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=grelan SRC=192.168.100.1 DST=192.168.100.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=26909 PROTO=ICMP TYPE=0 CODE=0 ID=647 SEQ=1 
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=ens4 SRC=10.0.1.2 DST=10.0.2.1 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=33368 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=ens4 SRC=10.0.1.2 DST=10.0.2.1 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=33368 DF PROTO=47 
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172 
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172 
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172

Но в связке linux - Zyxel машина на linux не может понять, что прилетело в GRE пакете от Zyxel, сразу даёт ответ о недостижимости хоста:  

июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ] 
июл 25 17:37:48 arch2 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ] 

Если честно, не могу разобраться, где я делаю ошибку? Или данная схема в принципе в паре linux - Zyxel работать не будет? (ну там чистый GRE нужен, или destination только на внешний интерфейс садить нужно)

В каком случае эта схема будет работать? В чём особенность? Может я зря не завернул всё в чистый GRE на IPSEC?  Может поэтому не работает? Или на линуксовой машине что-то надо добавить, чтобы именно в паре с Zyxel заработало?

конфигурация на linux:

Скрытый текст

ip route:

default via 192.168.2.1 dev enp4s0  
46.X.Y.Z via 192.168.2.1 dev enp4s0  
192.168.2.0/24 dev enp4s0 proto kernel scope link src 192.168.2.2  
192.168.100.0/24 dev grelan proto kernel scope link src 192.168.100.2

ip address:

1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
   link/ether 00:1a:64:94:68:74 brd ff:ff:ff:ff:ff:ff
   inet 192.168.2.2/24 brd 192.168.2.255 scope global enp4s0
      ....
3: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether 00:1a:64:94:68:76 brd ff:ff:ff:ff:ff:ff
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
   link/gre 0.0.0.0 brd 0.0.0.0
5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
   link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: grelan@enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether 02:90:68:cc:4f:47 brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.2/24 scope global grelan
...

отладочную информацию прикрепил следом.
 

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

настроил туннель GRE так, чтобы всё заворачивалось в GRE. Поднимается:

pptp-ipsec{13}:   192.168.0.0/24[gre] === 192.168.2.2/32[gre]

сделал:

access-list _WEBADMIN_IPSEC_pptp-ipsec
   permit gre 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
!

tools ping 192.168.100.2 теперь ничего не выдаёт, оно и понятно, так и должно быть если по IPSEC один GRE ходит. На другом конце отлавливается та-же картина, отсылаются PROTO=ICMP TYPE=3 CODE=3

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Цитата

access-list _WEBADMIN_IPSEC_pptp-ipsec
    permit ip 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
    permit gre 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
! 

Это не будет работать правильно, берется только самая первая запись.

Не помнимаю, чем вам автоматический туннель не угодил и почему захотелось делать все руками, не до конца понимая, как все это работает.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

Перенастроил на внешний интерфейс 

TRACE на linux машинке показывает:

июл 25 23:42:06 arch2 kernel: TRACE: filter:INPUT:policy:1 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=46.X.Y.Z DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=35509 DF PROTO=47  

до машинки долетает расшифрованный пакет GRE, но потом сразу идёт ответ о недостижимости хоста, т.е. пакет теряется где-то в маршрутизации, он не появляется в PREROUTING от интерфейса grelan:
июл 25 23:42:06 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=57777 PROTO=ICMP TYPE=3 CODE=3 [SRC=46.X.Y.Z DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=35509 DF PROTO=47 ]

Такое ощущение что идёт несовместимость на уровне протокола GRE? Или я просто ошибаюсь?

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано
3 часа назад, Le ecureuil сказал:
Цитата

access-list _WEBADMIN_IPSEC_pptp-ipsec
    permit ip 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
    permit gre 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255
! 

Это не будет работать правильно, берется только самая первая запись.

Не помнимаю, чем вам автоматический туннель не угодил и почему захотелось делать все руками, не до конца понимая, как все это работает.

Добрый вечер. Я убрал в итоге permit gre 192.168.0.0 255.255.255.0 192.168.2.2 255.255.255.255

Это не помогло. Поведение системы осталось прежним.

Потому в ручном и решил настроить, чтобы до конца понять как всё это работает. Кроме access-list есть ещё ошибки в настройках?

Туннель пока не рабочий. Завтра ради интереса попробую автоматический режим настроить, но ведь очевидно, что проблема на стороне linux машины, (слева по схеме, считаем - клиент). Почему туннель, по этой схеме построенный, с машиной linux в качестве сервера, работает, а когда практически ничего не меняя в схеме, меняем линукс машину на zyxel не работает?

Я надеюсь видно, что я пытаюсь принять пакеты отправляемые туннелем со стороны сервера, и проблема с приёмом пакетов происходит на клиенте, когда сервером выступает zyxel. Как на это повлияет автоматическая настройка даже не знаю. 

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

Настраивал сейчас автомат, обратил внимание на неточность в справке по ссылке - https://help.keenetic.net/hc/ru/articles/115002715029-Настройка-туннелей-IPIP-GRE-и-EoIP

Цитата

В команде interface tunnel source можно указать как интерфейс-источник, так и IP-адрес, на котором будет "висеть" сервер. Однако предпочтение отдается интерфейсу, поскольку в данном случае вся перенастройка при смене адреса и прочих событиях будет происходить автоматически.

На самом деле, туннель слушает все интерфейсы, а командой указывается интерфейс с которым будет установлен режим туннеля.

Цитата

(config)> int Gre0 tunnel source 192.168.0.1
Network::Interface::Tunnel: Source IP set to 192.168.0.1.

(config)> sh ipsec

  ipsec_statusall: 

Status of IKE charon daemon (strongSwan 5.5.2, Linux 3.4.113, mips):
  uptime: 86 seconds, since Jul 26 12:29:12 2017
  malloc: sbrk 176128, mmap 0, used 121400, free 54728
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon random nonce openssl hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dynamic xauth-generic xauth-eap error-notify systime-fix unity
Listening IP addresses:
  46.X.Y.Z
  192.168.0.1
  10.1.30.1
  192.168.100.1
Connections:
        Gre0:  192.168.0.1...%any  IKEv1, dpddelay=30s
        Gre0:   local:  [192.168.0.1] uses pre-shared key authentication
        Gre0:   remote: uses pre-shared key authentication
        Gre0:   child:  192.168.0.1/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restart
Security Associations (0 up, 0 connecting):
  none
 

Думаю данная неточность в справке может вводить пользователей в заблуждение.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

протестировал работу в автоматическом режиме. Есть вопрос там транспортный режим работает принудительно? Можно ли и как в автомате включить туннельный режим?

Теперь к проблеме. Как и предполагалось, со стороны клиента ничего не изменилось при приёме пакетов, клиент на линукс не понимает что ему прислали, картина та-же, система по ходу не знает что делать с извлечённым пакетом из gre. 

Решил посмотреть на проблему с другого конца. Там тоже непонятно, пакеты отсылаются в сторону КЦ, но в ответ ничего не приходит:

ping 192.168.100.1

Скрытый текст

июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:rule:5 IN= OUT=grelan SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=58727 DF PROTO=ICMP TYPE=8 CODE=0 ID=3194 SEQ=1 UID=1000 GID=100 
июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=grelan SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=58727 DF PROTO=ICMP TYPE=8 CODE=0 ID=3194 SEQ=1 UID=1000 GID=100 
июл 26 21:22:12 arch2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=grelan SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=58727 DF PROTO=ICMP TYPE=8 CODE=0 ID=3194 SEQ=1 UID=1000 GID=100 
июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=47 
июл 26 21:22:12 arch2 kernel: TRACE: filter:OUTPUT:rule:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=47 
июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:rule:6 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:12 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:12 arch2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42279 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:13 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=47 
июл 26 21:22:13 arch2 kernel: TRACE: filter:OUTPUT:rule:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=47 
июл 26 21:22:13 arch2 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:13 arch2 kernel: TRACE: raw:OUTPUT:rule:6 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:13 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:13 arch2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42571 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:14 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=47 
июл 26 21:22:14 arch2 kernel: TRACE: filter:OUTPUT:rule:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=47 
июл 26 21:22:14 arch2 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:14 arch2 kernel: TRACE: raw:OUTPUT:rule:6 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:14 arch2 kernel: TRACE: raw:OUTPUT:policy:7 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
июл 26 21:22:14 arch2 kernel: TRACE: filter:OUTPUT:policy:2 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=42777 DF PROTO=UDP SPT=4500 DPT=4500 LEN=92 
 

Снял self-test в этот момент, отправил следующим сообщением. Там что-то можно разглядеть и понять, что происходит?

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
3 часа назад, pdn_mail сказал:

Настраивал сейчас автомат, обратил внимание на неточность в справке по ссылке - https://help.keenetic.net/hc/ru/articles/115002715029-Настройка-туннелей-IPIP-GRE-и-EoIP

На самом деле, туннель слушает все интерфейсы, а командой указывается интерфейс с которым будет установлен режим туннеля.

Думаю данная неточность в справке может вводить пользователей в заблуждение.

Слушает он все (потому что служба strongswan общая на все типы IPsec), но реально будет работать только с тем, что указано в source.

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
45 минут назад, pdn_mail сказал:

протестировал работу в автоматическом режиме. Есть вопрос там транспортный режим работает принудительно? Можно ли и как в автомате включить туннельный режим?

Теперь к проблеме. Как и предполагалось, со стороны клиента ничего не изменилось при приёме пакетов, клиент на линукс не понимает что ему прислали, картина та-же, система по ходу не знает что делать с извлечённым пакетом из gre. 

Решил посмотреть на проблему с другого конца. Там тоже непонятно, пакеты отсылаются в сторону КЦ, но в ответ ничего не приходит:

ping 192.168.100.1

  Показать содержимое

Снял self-test в этот момент, отправил следующим сообщением. Там что-то можно разглядеть и понять, что происходит?

Да, транспортный режим принудительно, нет, туннельный нельзя.

Пока у меня нет времени собрать стенд, но постараюсь на неделе проверить.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано (изменено)

Если нетрудно, соберите стенд с арчем, т.к. на нём линукс клиент.

Пока попробую IPIP помучить.

Изменено пользователем pdn_mail
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
3 минуты назад, pdn_mail сказал:

Хм.. IPIP работает, учитывая, что этот протокол работает поверх GRE - просто удивительно!

ipip не работает поверх gre, это его "аналог" с меньшей функциональностью и количеством настроек.

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
58 минут назад, pdn_mail сказал:

Вы правы, это EoIP работает поверх, который я недавно пытался, пока, безуспешно завести.

EoIP работает не поверх GRE, они просто используют один и тот же IP protocol number - 47. А в остальном - они совершенно несовместимы, и ЕМНИП ни в одном дистрибутиве реализации EoIP из коробки нет.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано

Добрый день!

Стенд собрали? Что нибудь прояснилось почему туннель GRE с клиентом strongswan на linux не работает?

 

 

gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано (изменено)

Отлично работают GRE IPsec туннели с Debian. Стабильно

 

Вы в ACL должны указывать концы туннеля, а не трафик внутри туннеля.

 

А трафик внутрь заворачивайте маршрутизацией.

 

Изменено пользователем gaaronk
pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано
1 час назад, gaaronk сказал:

Вы в ACL должны указывать концы туннеля, а не трафик внутри туннеля.

С чего вы решили, что это не так?

1 час назад, gaaronk сказал:

А трафик внутрь заворачивайте маршрутизацией.

Рабочий пример можно?

Вот у меня с самого начала всё расписано, что и как, в конце исправлено с учётом замечаний Le ecureuil уже вроде всё разжевано, но туннель не работает. Как у вас в Debian это реализовано?

gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано (изменено)

Поехали.

Zyxel

  

access-list acl-tunnel-gre
    permit gre <zyxel wan ip> 255.255.255.255 <linux wan ip> 255.255.255.255
    
interface Gre0
    rename LinuxTunnel
    security-level private
    ip address 192.168.10.10 255.255.255.252
    ip dhcp client no dns-routes
    ip dhcp client no name-servers
    ip mtu 1400
    ip tcp adjust-mss pmtu
    tunnel source PPPoE0
    tunnel destination <linux wan ip>
    up
 
 ip route 192.168.0.0 255.255.0.0 LinuxTunnel
 
 crypto ike proposal ike-aes256-sha256
    encryption aes-cbc-256
    dh-group 14
    integrity sha256
!
crypto ike policy tun-ikev2-policy
    proposal ike-aes256-sha256
    lifetime 86400
    mode ikev2
    
crypto ipsec transform-set esp-aes128-sha1
    cypher esp-aes-128
    hmac esp-sha1-hmac
    dh-group 14
    lifetime 21600

crypto ipsec profile linux.tunnel.com
    dpd-interval 20
    identity-local fqdn zyxel.tunnel.com
    match-identity-remote linux.tunnel.com
    authentication-local pre-share
    authentication-remote pre-share
    mode transport
    policy tun-ikev2-policy
    
 crypto map linux-tunnel
    set-peer <linux wan ip>
    set-profile linux.tunnel.com
    set-transform esp-aes128-sha1
    match-address acl-tunnel-gre
    nail-up
    virtual-ip no enable
    enable
    
 service ipsec

 

Linux - /etc/network/interfaces 

auto gre2
iface gre2 inet static
        address 192.168.10.9
        netmask 255.255.255.255
        up ip link set gre2 mtu 1400
        pre-up iptunnel add gre2 mode gre remote <zyxel wan ip> local <linux wan ip> dev eth1 ttl 64
        pointopoint 192.168.10.10
        post-down iptunnel del gre2

 

Linux - /etc/ipsec.conf 

conn %default
    right=%any
    compress=no
    dpddelay=20s
    dpdtimeout=60s
    installpolicy=yes
    fragmentation=yes
    keyexchange=ikev2
    ike=aes256-aes128-sha256-modp2048,aes256gcm16-aes128gcm16-prfsha256-modp2048!
    mobike=no
 
conn tmpl-static-tun-transport
    dpdaction=clear
    ike=aes256-sha256-modp2048,aes256gcm16-prfsha256-modp2048!
    esp=aes128-sha1-modp2048,aes128gcm16-modp2048!
    ikelifetime=24h
    keyexchange=ikev2
    keyingtries=1
    lifetime=6h
    inactivity=10m
    type=transport
    
conn zyxel-tun
    also=tmpl-static-tun-transport
    left=<linux-wan-ip>
    leftauth=psk
    leftid="linux.tunnel.com"
    leftsubnet=%dynamic[gre]
    right=<zyxel-wan-ip>
    rightauth=psk
    rightid="zyxel.tunnel.com"
    rightsubnet=%dynamic[gre]
    auto=route

 

Изменено пользователем gaaronk
  • Спасибо 2
Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
9 часов назад, pdn_mail сказал:

Добрый день!

Стенд собрали? Что нибудь прояснилось почему туннель GRE с клиентом strongswan на linux не работает?

 

 

Приоритет низкий, руки дойдут не в ближайшие дни.

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано (изменено)
10 часов назад, gaaronk сказал:

Поехали.

Упустили самый важный момент. Уточните пожалуйста, на чём у вас организован IPSEC? название и версию софтины.

А так вам большое спасибо за пример. Есть над чем подумать.

И ещё, у вас клиент не за натом судя по всему сидит, хотя это не принципиально важно.

Изменено пользователем pdn_mail
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано

Strongswan 5.5.3

Клиент? Тут нет понятия клиент, оба соединения равноправны.

У вас кто за NAT  - линукс или кинетик? Внешний IP статический или динамический?

pdn_mail Продвинутый пользователь

pdn_mail

Опубликовано
  • Автор
Опубликовано (изменено)

За натом linux, как клиент (я так говорю, потому, что он инициирует соединение), тоже на Strongswan 5.5.3

В первом посте схема, Zyxel на белом IP, Linux за натом с динамическим внешним IP.

Правда я понял почему у вас работает, у вас изначально есть связность gre туннеля, т.к. он и ipsec напрямую видят и сидят на одинаковых внешних интерфейсах, в моём случае связность gre туннелю обеспечивает ipsec, концы сидят на разных интерфейсах, вот тут и возникает проблема.

Ещё раз попытаюсь, максимально повторив вашу конфигурацию, то что будет возможно повторить в моём случае, чуть позже отпишусь, что получилось.  

Изменено пользователем pdn_mail
gaaronk Поставщик контента

gaaronk

Опубликовано
Опубликовано

Если у вас такая схема, то вам надо обязательно:

1. Обновить кинетик до 2.10

2. Конфигурировать авто туннель на кинетикие в режиме ikev2

3. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал leftid и rightid что бы на линуксе настроить строго зеркально

4. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал ike, esp, ikelifetime, lifetime что бы на линуксе задать такие же

5. На линуксе в параметрах туннеля использовать как source локальный адрес линукса

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
 Поделиться
Перейти к списку тем

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю