Jump to content

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


Recommended Posts

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

Случилась оказия завести сервер который сидит за серым 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 

Edited by pdn_mail
Link to comment
Share on other sites

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


справа: 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

Link to comment
Share on other sites

У вас 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

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

Link to comment
Share on other sites

Спасибо!

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

(config-if)> tunnel source 192.168.0.1

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

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

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

Edited by pdn_mail
Link to comment
Share on other sites

Добрый день!

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

Между двумя 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

...

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

Link to comment
Share on other sites

настроил туннель 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

Link to comment
Share on other sites

Цитата

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

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

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

Link to comment
Share on other sites

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

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? Или я просто ошибаюсь?

Link to comment
Share on other sites

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. Как на это повлияет автоматическая настройка даже не знаю. 

Link to comment
Share on other sites

Настраивал сейчас автомат, обратил внимание на неточность в справке по ссылке - 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
 

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

Link to comment
Share on other sites

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

Теперь к проблеме. Как и предполагалось, со стороны клиента ничего не изменилось при приёме пакетов, клиент на линукс не понимает что ему прислали, картина та-же, система по ходу не знает что делать с извлечённым пакетом из 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 в этот момент, отправил следующим сообщением. Там что-то можно разглядеть и понять, что происходит?

Link to comment
Share on other sites

3 часа назад, pdn_mail сказал:

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

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

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

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

Link to comment
Share on other sites

45 минут назад, pdn_mail сказал:

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

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

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

ping 192.168.100.1

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

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

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

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

Link to comment
Share on other sites

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

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

Edited by pdn_mail
Link to comment
Share on other sites

3 минуты назад, pdn_mail сказал:

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

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

Link to comment
Share on other sites

58 минут назад, pdn_mail сказал:

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

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

Link to comment
Share on other sites

Добрый день!

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

 

 

Link to comment
Share on other sites

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

 

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

 

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

 

Edited by gaaronk
Link to comment
Share on other sites

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

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

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

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

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

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

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

Link to comment
Share on other sites

Поехали.

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

 

Edited by gaaronk
  • Thanks 2
Link to comment
Share on other sites

9 часов назад, pdn_mail сказал:

Добрый день!

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

 

 

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

Link to comment
Share on other sites

10 часов назад, gaaronk сказал:

Поехали.

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

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

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

Edited by pdn_mail
Link to comment
Share on other sites

Strongswan 5.5.3

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

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

Link to comment
Share on other sites

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

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

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

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

Edited by pdn_mail
Link to comment
Share on other sites

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

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

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

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

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

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...