KorDen Posted August 17, 2017 Share Posted August 17, 2017 (edited) 13 минуты назад, Le ecureuil сказал: Начиная со следующей сборки draft автопрописывание роута к destination должно работать При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал) Т.е. я рассматриваю два случая с автотуннелями с default route на туннель: 1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется? 2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать. Edited August 17, 2017 by KorDen Quote Link to comment Share on other sites More sharing options...
r13 Posted August 17, 2017 Share Posted August 17, 2017 7 минут назад, KorDen сказал: При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал) Т.е. я рассматриваю два случая с автотуннелями с default route на туннель: 1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется? 2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать. На драфте и попробуем эти сценарии Quote Link to comment Share on other sites More sharing options...
intelworker Posted August 17, 2017 Author Share Posted August 17, 2017 Ребята, а не подскажите как правильно ping-check прописать для IPIP0 в моей ситуации? Чтобы был рестарт интерфейса на стороне клиента в случае если перестает пинговаться офисный роутер/статический внешний IP. Пытался искать и сам пробовал разобраться, но что-то по ходу я не в силах понять,как создать новый профиль через командную строку. Quote Link to comment Share on other sites More sharing options...
KorDen Posted August 17, 2017 Share Posted August 17, 2017 @intelworker, так уже есть DPD-интервал IPsec в 30 секунд, и по нему вроде бы вполне рестартуется соединение, по крайней мере у меня соединение достаточно быстро восстанавливается после рестарта роутера-сервера. Quote Link to comment Share on other sites More sharing options...
intelworker Posted August 17, 2017 Author Share Posted August 17, 2017 (edited) А как посмотреть включен ли он для интерфейса IPIP0? Это же все через командную строку так понимаю смотреть, в вебе я этого всего для IPIP не увижу В справочнике команд есть только упоминание dpd для профилей crypto ipsec. А пока настроил такой вот ping-check, вроде даже работает и проверяет, осталось дождаться поведения при фейлах. ping-check profile IPIP0 host 8.8.8.8 update-interval 30 mode icmp max-fails 5 timeout 10 restart-interface show ping-check IPIP0 pingcheck: profile: IPIP0 host: 8.8.8.8 update-interval: 30 max-fails: 5 timeout: 10 mode: icmp interface: name: IPIP0 successcount: 6 failcount: 0 status: pass Edited August 17, 2017 by intelworker Quote Link to comment Share on other sites More sharing options...
r13 Posted August 18, 2017 Share Posted August 18, 2017 7 часов назад, intelworker сказал: А как посмотреть включен ли он для интерфейса IPIP0? Это же все через командную строку так понимаю смотреть, в вебе я этого всего для IPIP не увижу В справочнике команд есть только упоминание dpd для профилей crypto ipsec. А пока настроил такой вот ping-check, вроде даже работает и проверяет, осталось дождаться поведения при фейлах. ping-check profile IPIP0 host 8.8.8.8 update-interval 30 mode icmp max-fails 5 timeout 10 restart-interface show ping-check IPIP0 pingcheck: profile: IPIP0 host: 8.8.8.8 update-interval: 30 max-fails: 5 timeout: 10 mode: icmp interface: name: IPIP0 successcount: 6 failcount: 0 status: pass DPD это встроенный механизм контроля работы туннеля ipsec для контроля именно туннеля никаких дополнительных пингчеков не надо, и так должно работать с настройками по умолчанию.. Quote Link to comment Share on other sites More sharing options...
intelworker Posted August 18, 2017 Author Share Posted August 18, 2017 Ну, через час после того как я это ping-check прописал у меня роутер просто повис походу, видать IP на модеме сменился и что-то пошло не так. До этого просто была такая ситуация что IP видать тоже сменился, а туннель об этом узнал через час или более, как итог, отсутствие инета полностью час и более. Не понимаю что с этим делать пока. Quote Link to comment Share on other sites More sharing options...
r13 Posted August 18, 2017 Share Posted August 18, 2017 10 минут назад, intelworker сказал: Ну, через час после того как я это ping-check прописал у меня роутер просто повис походу, видать IP на модеме сменился и что-то пошло не так. До этого просто была такая ситуация что IP видать тоже сменился, а туннель об этом узнал через час или более, как итог, отсутствие инета полностью час и более. Не понимаю что с этим делать пока. Выкладывать селфтесты для разработчиков если есть подозрение на баг Quote Link to comment Share on other sites More sharing options...
intelworker Posted August 18, 2017 Author Share Posted August 18, 2017 (edited) Проблема в том, что я это могу делать только ночью когда время появляется, попробую селф-тесты позже. Сейчас журналы просмотрел и судя по всему что-то происходит с туннелем когда синхронизируется время, а не когда IP на модеме сменяется. В прошлый раз в журнале тоже самое наблюдал, последние записи были относительно обновления времени, а потом мертвая тишина в логе. [I] Aug 18 00:40:26 ndm: Ntp::Client: unable to communicate with "0.pool.ntp.org". [I] Aug 18 00:40:26 ndm: Ntp::Client: could not synchronize, waiting... [I] Aug 18 00:40:26 ndm: kernel: EIP93: build outbound ESP connection, (SPI=c5b3432f) [I] Aug 18 00:40:26 ndm: kernel: EIP93: build inbound ESP connection, (SPI=c254ab9e) [I] Aug 18 08:48:50 ndm: Core::System::Clock: system time has been changed. [I] Aug 18 08:48:53 ipsec: 05[CFG] system time jump detected from 1503006024s to 1503035333s, initiate SA rekeying [I] Aug 18 08:48:53 ipsec: 05[IKE] establishing CHILD_SA IPIP0 Понимаю, этот кусок лога мало что скажет разработчику, но вот в логе записей нет после 00:40, хотя по логам приложений запущенных на ноуте, интернет пропал в 1:44, т.е. через час после последней записи. Часовые пояса настроены верно, если что. В 8:48 я выключил/включил роутер. Edited August 18, 2017 by intelworker Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 18, 2017 Share Posted August 18, 2017 16 часов назад, KorDen сказал: При переходе на резерв будет корректно переключаться маршрут на резервный канал? А если уже есть маршрут до этого узла? А то я теперь осмыслил, что у меня при резерве через 3G туннель-то и не работал (основной канал давно не падал, так что на практике не обнаруживал) Т.е. я рассматриваю два случая с автотуннелями с default route на туннель: 1) к серверу подключается по беляку, стандартное резервирование проводного инета мобильным модемом, при переходе на резерв маршрут перепишется? 2) Опять резерв, но уже специально жестко прописан destination ip маршрутом через проводной инет. Возможна ситуация, когда основной инет лежит, но по локалке сервер доступен (и там есть инет), т.е. мне именно надо чтобы в случае падения сети был вариант остаться на туннеле, и только потом уходить на модем. Собственно, сейчас только так и можно сделать. Будет. Если обнаружено, что туннель упал, то эти автороуты сбрасываются и начинается их новое определение. Если есть маршрут - ничего страшного, новая запись будет проигнорирована. 1) да 2) будет работать как сделаете, если он прописан через другой интерфейс - должен выбраться путь через него. 1 Quote Link to comment Share on other sites More sharing options...
KorDen Posted August 18, 2017 Share Posted August 18, 2017 13 часа назад, intelworker сказал: А как посмотреть включен ли он для интерфейса IPIP0? show ipsec ... Connections: VirtualIPServer: %any...%any IKEv1, dpddelay=20s VirtualIPServer: local: [mykeenetic.net] uses pre-shared key authentication VirtualIPServer: remote: uses pre-shared key authentication VirtualIPServer: remote: uses XAuth authentication: eap VirtualIPServer: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=restart IPIP0: x.x.x.x...y.y.y.y IKEv2, dpddelay=30s IPIP0: local: [IPIP0] uses pre-shared key authentication IPIP0: remote: [IPIP0] uses pre-shared key authentication IPIP0: child: 0.0.0.0/0[ipencap] === y.y.y.y/32[ipencap] TRANSPORT, dpdaction=restart IPIP1: a.b.c.d...%any IKEv2, dpddelay=30s IPIP1: local: [IPIP1] uses pre-shared key authentication IPIP1: remote: [IPIP1] uses pre-shared key authentication IPIP1: child: e.f.g.h/32[ipencap] === 0.0.0.0/0[ipencap] TRANSPORT, dpdaction=restart Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 18, 2017 Share Posted August 18, 2017 8 минут назад, KorDen сказал: show ipsec ... Connections: VirtualIPServer: %any...%any IKEv1, dpddelay=20s VirtualIPServer: local: [mykeenetic.net] uses pre-shared key authentication VirtualIPServer: remote: uses pre-shared key authentication VirtualIPServer: remote: uses XAuth authentication: eap VirtualIPServer: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=restart IPIP0: x.x.x.x...y.y.y.y IKEv2, dpddelay=30s IPIP0: local: [IPIP0] uses pre-shared key authentication IPIP0: remote: [IPIP0] uses pre-shared key authentication IPIP0: child: 0.0.0.0/0[ipencap] === y.y.y.y/32[ipencap] TRANSPORT, dpdaction=restart IPIP1: a.b.c.d...%any IKEv2, dpddelay=30s IPIP1: local: [IPIP1] uses pre-shared key authentication IPIP1: remote: [IPIP1] uses pre-shared key authentication IPIP1: child: e.f.g.h/32[ipencap] === 0.0.0.0/0[ipencap] TRANSPORT, dpdaction=restart просто > show interface IPIP0 вам тоже это покажет Quote Link to comment Share on other sites More sharing options...
KorDen Posted August 18, 2017 Share Posted August 18, 2017 26 минут назад, Le ecureuil сказал: просто > show interface IPIP0 вам тоже это покажет DPD-интервала там нет, только tunnel-local-source: 1.2.3.4 tunnel-remote-destination: 5.6.7.8 ipsec-enabled: yes ipsec-ikev2-allowed: yes ipsec-ikev2-enabled: yes ipsec-encryption-level: strong Quote Link to comment Share on other sites More sharing options...
utya Posted August 18, 2017 Share Posted August 18, 2017 Товарищи а данный подход для eoip (ipsec) заработает? Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 18, 2017 Share Posted August 18, 2017 1 час назад, utya сказал: Товарищи а данный подход для eoip (ipsec) заработает? Да, вполне. Quote Link to comment Share on other sites More sharing options...
r13 Posted August 19, 2017 Share Posted August 19, 2017 В 17.08.2017 в 18:43, Le ecureuil сказал: Начиная со следующей сборки draft автопрописывание роута к destination должно работать @Le ecureuil Маршрут добавляется, спасибо. Буду тестить. Тем временем новая хотелка: Сейчас туннели over ipsec считаются поднятыми всегда независимо от реального состояния. Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв. Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс). Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте 1 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 19, 2017 Share Posted August 19, 2017 2 часа назад, r13 сказал: @Le ecureuil Маршрут добавляется, спасибо. Буду тестить. Тем временем новая хотелка: Сейчас туннели over ipsec считаются поднятыми всегда независимо от реального состояния. Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв. Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс). Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте Спасибо за комментарии, поработаем над этим. 1 Quote Link to comment Share on other sites More sharing options...
r13 Posted August 20, 2017 Share Posted August 20, 2017 (edited) @Le ecureuil Протестировал маршрут до узла, с авто туннелями все четко. (тестировал с и без маршрутом добавленным вручную 2 параллельных туннеля к 1й точке IPIP и PPTP) А вот PPTP наоборот после отключения пересоздает маршрут. В логе следующее: Скрытый текст Aug 20 19:10:37ndm Network::Interface::Base: "PPTP0": interface is down. Aug 20 19:10:37ndhcpc PPTP0: sendmsg() failed (invalid argument). Aug 20 19:10:37ndhcpc PPTP0: can not send RELEASE (invalid argument) in RELEASING state. Aug 20 19:10:37ndm kernel: Fast VPN ctrl: release for src 77.22.136.81 Aug 20 19:10:37pppd_PPTP0 MPPE disabled Aug 20 19:10:37pppd_PPTP0 Connection terminated. Aug 20 19:10:37ndm Dhcp::Client: DHCP server is not responding. Aug 20 19:10:37ndm Network::Interface::IP: "PPTP0": IP address cleared. Aug 20 19:10:37pppd_PPTP0 Closing connection (unhandled) Aug 20 19:10:37pppd_PPTP0 Sent control packet type is 12 'Call-Clear-Request' Aug 20 19:10:37pppd_PPTP0 Closing connection (call state) Aug 20 19:10:37pppd_PPTP0 Terminating on signal 15 Aug 20 19:10:37pppd_PPTP0 Exit. Aug 20 19:10:37ndm Network::Interface::Base: "PPTP0": interface is down. Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": disabled connection. Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81". Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2"). Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2). Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": connection service standby. Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": enabled connection via any interface. Aug 20 19:10:39ndm Process: "PPTP0 DHCP client" has been killed. Так же при запуске роутера даже отключенный PPTP создает маршрут: Скрытый текст Aug 20 19:01:46ndm IpSec::CryptoEngineManager: hardware crypto processing was enabled. Aug 20 19:01:46ndm Http::Manager: new Web server configuration was applied. Aug 20 19:01:47ndhcpc FastEthernet0/Vlan2: NDM DHCP client (version 3.2.11) started. Aug 20 19:01:47ndhcpc FastEthernet0/Vlan2: created PID file "/var/run/ndhcpc-eth2.2.pid". Aug 20 19:01:48ndhcpc FastEthernet0/Vlan2: received OFFER for 192.168.1.66 from 192.168.1.1. Aug 20 19:01:49ndhcpc FastEthernet0/Vlan2: received ACK for 192.168.1.66 from 192.168.1.1. Aug 20 19:01:49ndm Dhcp::Client: configuring interface ISP. Aug 20 19:01:49ndm Network::Interface::IP: "FastEthernet0/Vlan2": IP address is 192.168.1.66/24. Aug 20 19:01:49ndm Dhcp::Client: obtained IP address 192.168.1.66/24. Aug 20 19:01:49ndm Dhcp::Client: interface "ISP" is global, priority 700. Aug 20 19:01:49ndm Dhcp::Client: adding a default route via 192.168.1.1. Aug 20 19:01:49ndm Dhcp::Client: adding name server 192.168.1.1. Aug 20 19:01:49ndm Dns::Manager: name server 192.168.1.1 added, domain (default). Aug 20 19:01:49ndm Network::InterfaceFlusher: flushed conntrack and route cache. Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": disabled connection. Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81". Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2"). Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2). Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": connection service standby. Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": enabled connection via any interface. Edited August 20, 2017 by r13 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 21, 2017 Share Posted August 21, 2017 17 часов назад, r13 сказал: @Le ecureuil Протестировал маршрут до узла, с авто туннелями все четко. (тестировал с и без маршрутом добавленным вручную 2 параллельных туннеля к 1й точке IPIP и PPTP) А вот PPTP наоборот после отключения пересоздает маршрут. В логе следующее: Показать содержимое Aug 20 19:10:37ndm Network::Interface::Base: "PPTP0": interface is down. Aug 20 19:10:37ndhcpc PPTP0: sendmsg() failed (invalid argument). Aug 20 19:10:37ndhcpc PPTP0: can not send RELEASE (invalid argument) in RELEASING state. Aug 20 19:10:37ndm kernel: Fast VPN ctrl: release for src 77.22.136.81 Aug 20 19:10:37pppd_PPTP0 MPPE disabled Aug 20 19:10:37pppd_PPTP0 Connection terminated. Aug 20 19:10:37ndm Dhcp::Client: DHCP server is not responding. Aug 20 19:10:37ndm Network::Interface::IP: "PPTP0": IP address cleared. Aug 20 19:10:37pppd_PPTP0 Closing connection (unhandled) Aug 20 19:10:37pppd_PPTP0 Sent control packet type is 12 'Call-Clear-Request' Aug 20 19:10:37pppd_PPTP0 Closing connection (call state) Aug 20 19:10:37pppd_PPTP0 Terminating on signal 15 Aug 20 19:10:37pppd_PPTP0 Exit. Aug 20 19:10:37ndm Network::Interface::Base: "PPTP0": interface is down. Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": disabled connection. Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81". Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2"). Aug 20 19:10:37ndm Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2). Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": connection service standby. Aug 20 19:10:37ndm Network::Interface::Ppp: "PPTP0": enabled connection via any interface. Aug 20 19:10:39ndm Process: "PPTP0 DHCP client" has been killed. Так же при запуске роутера даже отключенный PPTP создает маршрут: Показать содержимое Aug 20 19:01:46ndm IpSec::CryptoEngineManager: hardware crypto processing was enabled. Aug 20 19:01:46ndm Http::Manager: new Web server configuration was applied. Aug 20 19:01:47ndhcpc FastEthernet0/Vlan2: NDM DHCP client (version 3.2.11) started. Aug 20 19:01:47ndhcpc FastEthernet0/Vlan2: created PID file "/var/run/ndhcpc-eth2.2.pid". Aug 20 19:01:48ndhcpc FastEthernet0/Vlan2: received OFFER for 192.168.1.66 from 192.168.1.1. Aug 20 19:01:49ndhcpc FastEthernet0/Vlan2: received ACK for 192.168.1.66 from 192.168.1.1. Aug 20 19:01:49ndm Dhcp::Client: configuring interface ISP. Aug 20 19:01:49ndm Network::Interface::IP: "FastEthernet0/Vlan2": IP address is 192.168.1.66/24. Aug 20 19:01:49ndm Dhcp::Client: obtained IP address 192.168.1.66/24. Aug 20 19:01:49ndm Dhcp::Client: interface "ISP" is global, priority 700. Aug 20 19:01:49ndm Dhcp::Client: adding a default route via 192.168.1.1. Aug 20 19:01:49ndm Dhcp::Client: adding name server 192.168.1.1. Aug 20 19:01:49ndm Dns::Manager: name server 192.168.1.1 added, domain (default). Aug 20 19:01:49ndm Network::InterfaceFlusher: flushed conntrack and route cache. Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": disabled connection. Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": remote endpoint is resolved to "77.22.136.81". Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": local endpoint is resolved to "192.168.1.66" (via "FastEthernet0/Vlan2"). Aug 20 19:01:51ndm Network::Interface::PppTunnel: "PPTP0": added host route to 77.22.136.81 via 192.168.1.1 (FastEthernet0/Vlan2). Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": connection service standby. Aug 20 19:01:51ndm Network::Interface::Ppp: "PPTP0": enabled connection via any interface. Это не баг, это фича. PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен. 1 Quote Link to comment Share on other sites More sharing options...
r13 Posted August 21, 2017 Share Posted August 21, 2017 4 минуты назад, Le ecureuil сказал: Это не баг, это фича. PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен. Ок, попробую с connect / no connect Кстати, галка в веб интерфейсе в настройках PPTP делает up/down или connect / no connect? Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 21, 2017 Share Posted August 21, 2017 1 минуту назад, r13 сказал: Ок, попробую с connect / no connect Кстати, галка в веб интерфейсе в настройках PPTP делает up/down или connect / no connect? Она делает connect / no connect. 1 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 21, 2017 Share Posted August 21, 2017 В 8/19/2017 в 12:13, r13 сказал: @Le ecureuil Маршрут добавляется, спасибо. Буду тестить. Тем временем новая хотелка: Сейчас туннели over ipsec считаются поднятыми всегда независимо от реального состояния. Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв. Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс). Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте В следующей сборке draft должно работать. Просьба проверить. 1 Quote Link to comment Share on other sites More sharing options...
r13 Posted August 21, 2017 Share Posted August 21, 2017 7 часов назад, Le ecureuil сказал: Это не баг, это фича. PPP-интерфейсы нужно отключать не через up/down, а через connect / no connect. В противном случае PPP-линк все равно будет установлен, однако интерфейс будет опущен. потестил с no connect, все отлично работает Quote Link to comment Share on other sites More sharing options...
r13 Posted August 21, 2017 Share Posted August 21, 2017 (edited) @Le ecureuil Смоделировал ситуацию "криворучки", когда PPTP интерфейс уже создал свой роут через ISP а у IPIP интерфейса указан source PPTP а не ISP в этом случае: Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved destination 77.23.136.81 (*.mykeenetic.net). Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved source 192.168.5.204. Aug 21 21:12:03ndm Network::Interface::Tunnel: "IPIP4": system failed [0xcffd0464], unable to get route to tunnel destination endpoint. Понятно что настройка кривовата но надо бы подкрутить обработку исключения. Edited August 21, 2017 by r13 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 22, 2017 Share Posted August 22, 2017 12 часа назад, r13 сказал: @Le ecureuil Смоделировал ситуацию "криворучки", когда PPTP интерфейс уже создал свой роут через ISP а у IPIP интерфейса указан source PPTP а не ISP в этом случае: Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved destination 77.23.136.81 (*.mykeenetic.net). Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved source 192.168.5.204. Aug 21 21:12:03ndm Network::Interface::Tunnel: "IPIP4": system failed [0xcffd0464], unable to get route to tunnel destination endpoint. Понятно что настройка кривовата но надо бы подкрутить обработку исключения. В каком плане подкрутить? Не выводить? Нет уж, пусть юзер с кривоватыми настройками это видит и беспокоится, а потом и настроит соответствующе. И вообще одновременное задание source и destination у туннеля с ipsec является логической ошибкой - должно быть либо то, либо другое, ибо оно включает режим клиента или сервера. Quote Link to comment Share on other sites More sharing options...
r13 Posted August 22, 2017 Share Posted August 22, 2017 (edited) 3 часа назад, Le ecureuil сказал: В каком плане подкрутить? Не выводить? Нет уж, пусть юзер с кривоватыми настройками это видит и беспокоится, а потом и настроит соответствующе. И вообще одновременное задание source и destination у туннеля с ipsec является логической ошибкой - должно быть либо то, либо другое, ибо оно включает режим клиента или сервера. Подкрутить в плане выводить без "system failed" A без указания tunnel source на клиенте в случае еще одного туннеля в тот же destination не получается, Иначе в моем случае IPIP нуннель идет через роут через ISP при этом резолвя source oт PPTP0 интерфейса. IPIP туннель при этом не поднимается. В случае же указатия и source и destanation все заводится. Но это частный случай. в общем случае да, достаточно указать только destination на клиенте. Фактически указание tunnel source на клиенте это аналог настройки "Подключаться через" у других соединений. Edited August 22, 2017 by r13 Quote Link to comment Share on other sites More sharing options...
r13 Posted August 29, 2017 Share Posted August 29, 2017 @Le ecureuil Ставлю экспериент: Основное соединение ISP Если Поверх него в качестве интернет соединения поднят PPTP то последующий IPIP интерфейс поднимается через PPTP0. Если же поверх ISP в качестве интернет соединения поднят IPIP то последующее поднятие PPTP интерфейсa поднимается через ISP. PPTP настроен как подключаться через любое интернет подключение. Почему такие различия в поведении? селфтест далее. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 31, 2017 Share Posted August 31, 2017 Потому что вы в одну и ту же точку соединяетесь по этим туннелям. IPIP уже прописал host route к 77.37.136.81 через 192.168.1.1, потому PPTP тоже подбирает этот маршрут. Quote Link to comment Share on other sites More sharing options...
r13 Posted August 31, 2017 Share Posted August 31, 2017 34 минуты назад, Le ecureuil сказал: Потому что вы в одну и ту же точку соединяетесь по этим туннелям. IPIP уже прописал host route к 77.37.136.81 через 192.168.1.1, потому PPTP тоже подбирает этот маршрут. В обоих случаях один из интерфейсов создает этот host route Вопрос про различие в выборе sorce интерфейса: IPIP похоже выбирает тот что является default route(и поэтому соединение идет через PPTP), а PPTP тот что определил из таблицы роутинга а именно ISP из этой записи host route. Или не так? Quote Link to comment Share on other sites More sharing options...
90105 Posted December 1, 2017 Share Posted December 1, 2017 В 26.11.2017 в 14:26, r13 сказал: Все сделал по инструкции, но не заработало. Я правильно понимаю, что у домашнего роутера при правильных настройках должен появится внешний ИП адрес как у офисного? Ошибка в логах Dec 01 14:54:33ndm IpSec::Configurator: general error while establishing crypto map "IPIP0" connection. 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.