pdn_mail Posted July 21, 2017 Share Posted July 21, 2017 (edited) Здравствуйте! Случилась оказия завести сервер который сидит за серым 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 July 21, 2017 by pdn_mail Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 21, 2017 Share Posted July 21, 2017 Какая версия прошивки? Где self-test? Как настраивали на Keenetic? Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 21, 2017 Author Share Posted July 21, 2017 да тут предпросмотра нет, конец обрезало. Пытаюсь отредактировать. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 21, 2017 Author Share Posted July 21, 2017 Вот концовка сообщения справа: 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 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 21, 2017 Share Posted July 21, 2017 У вас 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 ! Короче еще раз внимательно подумайте о настройках и все поправьте. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 21, 2017 Author Share Posted July 21, 2017 (edited) Спасибо! Добавил в настройки интерфейса Gre0 команду (config-if)> tunnel source 192.168.0.1 Gre потом один оставлю, Пока осталось с заворотом порта разобраться, про него чуть позже спрошу, как конфигурацию поковыряю, а сейчас можно вопрос? Зачем нужен транспортный режим? Мне он разве даст через NAT работать? На схеме, что в ссылке дана в начале, слева перед сервером неадминистрируемый роутер с NAT. Просто в этой схеме если вместо Zyxel использовать машинку с linux, то всё замечательно в режиме туннеля работает. Вот почему такой вопрос возник. Edited July 21, 2017 by pdn_mail Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 21, 2017 Share Posted July 21, 2017 Да, транспортный режим даст использовать IPsec под GRE, причем все будет проходить через NAT. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 25, 2017 Author Share Posted July 25, 2017 Добрый день! Можно сказать почти у цели если бы не одно НО, не работает туннель так как надо. Между двумя 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 ... отладочную информацию прикрепил следом. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 25, 2017 Author Share Posted July 25, 2017 настроил туннель 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 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 25, 2017 Share Posted July 25, 2017 Цитата 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 ! Это не будет работать правильно, берется только самая первая запись. Не помнимаю, чем вам автоматический туннель не угодил и почему захотелось делать все руками, не до конца понимая, как все это работает. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 25, 2017 Author Share Posted July 25, 2017 Перенастроил на внешний интерфейс 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? Или я просто ошибаюсь? Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 25, 2017 Author Share Posted July 25, 2017 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. Как на это повлияет автоматическая настройка даже не знаю. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 26, 2017 Author Share Posted July 26, 2017 Настраивал сейчас автомат, обратил внимание на неточность в справке по ссылке - 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 unityListening 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 Думаю данная неточность в справке может вводить пользователей в заблуждение. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 26, 2017 Author Share Posted July 26, 2017 протестировал работу в автоматическом режиме. Есть вопрос там транспортный режим работает принудительно? Можно ли и как в автомате включить туннельный режим? Теперь к проблеме. Как и предполагалось, со стороны клиента ничего не изменилось при приёме пакетов, клиент на линукс не понимает что ему прислали, картина та-же, система по ходу не знает что делать с извлечённым пакетом из 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 в этот момент, отправил следующим сообщением. Там что-то можно разглядеть и понять, что происходит? Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 26, 2017 Share Posted July 26, 2017 3 часа назад, pdn_mail сказал: Настраивал сейчас автомат, обратил внимание на неточность в справке по ссылке - https://help.keenetic.net/hc/ru/articles/115002715029-Настройка-туннелей-IPIP-GRE-и-EoIP На самом деле, туннель слушает все интерфейсы, а командой указывается интерфейс с которым будет установлен режим туннеля. Думаю данная неточность в справке может вводить пользователей в заблуждение. Слушает он все (потому что служба strongswan общая на все типы IPsec), но реально будет работать только с тем, что указано в source. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 26, 2017 Share Posted July 26, 2017 45 минут назад, 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 в этот момент, отправил следующим сообщением. Там что-то можно разглядеть и понять, что происходит? Да, транспортный режим принудительно, нет, туннельный нельзя. Пока у меня нет времени собрать стенд, но постараюсь на неделе проверить. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 26, 2017 Author Share Posted July 26, 2017 (edited) Если нетрудно, соберите стенд с арчем, т.к. на нём линукс клиент. Пока попробую IPIP помучить. Edited July 26, 2017 by pdn_mail Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 26, 2017 Author Share Posted July 26, 2017 Хм.. IPIP работает, учитывая, что этот протокол работает поверх GRE - просто удивительно! Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 26, 2017 Share Posted July 26, 2017 3 минуты назад, pdn_mail сказал: Хм.. IPIP работает, учитывая, что этот протокол работает поверх GRE - просто удивительно! ipip не работает поверх gre, это его "аналог" с меньшей функциональностью и количеством настроек. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 26, 2017 Author Share Posted July 26, 2017 Вы правы, это EoIP работает поверх, который я недавно пытался, пока, безуспешно завести. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 26, 2017 Share Posted July 26, 2017 58 минут назад, pdn_mail сказал: Вы правы, это EoIP работает поверх, который я недавно пытался, пока, безуспешно завести. EoIP работает не поверх GRE, они просто используют один и тот же IP protocol number - 47. А в остальном - они совершенно несовместимы, и ЕМНИП ни в одном дистрибутиве реализации EoIP из коробки нет. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 31, 2017 Author Share Posted July 31, 2017 Добрый день! Стенд собрали? Что нибудь прояснилось почему туннель GRE с клиентом strongswan на linux не работает? Quote Link to comment Share on other sites More sharing options...
gaaronk Posted July 31, 2017 Share Posted July 31, 2017 (edited) Отлично работают GRE IPsec туннели с Debian. Стабильно Вы в ACL должны указывать концы туннеля, а не трафик внутри туннеля. А трафик внутрь заворачивайте маршрутизацией. Edited July 31, 2017 by gaaronk Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted July 31, 2017 Author Share Posted July 31, 2017 1 час назад, gaaronk сказал: Вы в ACL должны указывать концы туннеля, а не трафик внутри туннеля. С чего вы решили, что это не так? 1 час назад, gaaronk сказал: А трафик внутрь заворачивайте маршрутизацией. Рабочий пример можно? Вот у меня с самого начала всё расписано, что и как, в конце исправлено с учётом замечаний Le ecureuil уже вроде всё разжевано, но туннель не работает. Как у вас в Debian это реализовано? Quote Link to comment Share on other sites More sharing options...
gaaronk Posted July 31, 2017 Share Posted July 31, 2017 (edited) Поехали. 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 July 31, 2017 by gaaronk 2 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 31, 2017 Share Posted July 31, 2017 9 часов назад, pdn_mail сказал: Добрый день! Стенд собрали? Что нибудь прояснилось почему туннель GRE с клиентом strongswan на linux не работает? Приоритет низкий, руки дойдут не в ближайшие дни. Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted August 1, 2017 Author Share Posted August 1, 2017 (edited) 10 часов назад, gaaronk сказал: Поехали. Упустили самый важный момент. Уточните пожалуйста, на чём у вас организован IPSEC? название и версию софтины. А так вам большое спасибо за пример. Есть над чем подумать. И ещё, у вас клиент не за натом судя по всему сидит, хотя это не принципиально важно. Edited August 1, 2017 by pdn_mail Quote Link to comment Share on other sites More sharing options...
gaaronk Posted August 1, 2017 Share Posted August 1, 2017 Strongswan 5.5.3 Клиент? Тут нет понятия клиент, оба соединения равноправны. У вас кто за NAT - линукс или кинетик? Внешний IP статический или динамический? Quote Link to comment Share on other sites More sharing options...
pdn_mail Posted August 1, 2017 Author Share Posted August 1, 2017 (edited) За натом linux, как клиент (я так говорю, потому, что он инициирует соединение), тоже на Strongswan 5.5.3 В первом посте схема, Zyxel на белом IP, Linux за натом с динамическим внешним IP. Правда я понял почему у вас работает, у вас изначально есть связность gre туннеля, т.к. он и ipsec напрямую видят и сидят на одинаковых внешних интерфейсах, в моём случае связность gre туннелю обеспечивает ipsec, концы сидят на разных интерфейсах, вот тут и возникает проблема. Ещё раз попытаюсь, максимально повторив вашу конфигурацию, то что будет возможно повторить в моём случае, чуть позже отпишусь, что получилось. Edited August 1, 2017 by pdn_mail Quote Link to comment Share on other sites More sharing options...
gaaronk Posted August 1, 2017 Share Posted August 1, 2017 Если у вас такая схема, то вам надо обязательно: 1. Обновить кинетик до 2.10 2. Конфигурировать авто туннель на кинетикие в режиме ikev2 3. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал leftid и rightid что бы на линуксе настроить строго зеркально 4. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал ike, esp, ikelifetime, lifetime что бы на линуксе задать такие же 5. На линуксе в параметрах туннеля использовать как source локальный адрес линукса Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.