Кинетиковод

Сейчас так у всех и на финале 2.13 и на драфте 2.14. А в чём вопрос то?

Как бы всё так и осталось. Куда вы тыркаете непонятно.

Сервер: (config)> interface EoIP0 (config-if)> tunnel source ISP (config-if)> tunnel eoip id 1500 (config-if)> ipsec preshared-key mytestingkey (config-if)> security-level private (config-if)> up (config-if)> no isolate-private (config)> interface Home (config-if)> include EoIP0 Клиент: (config)> interface EoIP0 (config-if)> tunnel destination (белый IP адрес) (config-if)> tunnel eoip id 1500 (config-if)> ipsec preshared-key mytestingkey (config-if)> security-level private (config-if)> up (config-if)> no isolate-private (config)> interface Home (config-if)> include EoIP0

В межсетевом экране Гиги откройте доступ для интерфейса PPTP.

При чём тут дефолт? ТС нужно изменить настройки удалённо не имея удалённого доступа. Увы, но приложение ему выбраться из столь пикантной ситуации не поможет.

Защита от дятлов. У меня 80 порт всегда закрыт, также как и всегда включён VPN. Да, ТС накосячил и не подумав захлопнул дверь. Но для того и существует троянский конь в виде приложения, которое имеет доступ к роутеру всегда и должно выручать в подобных ситуациях.

Ничего не выйдет. Я всегда удивлялся, почему в приложении не продублировали галки доступа к телнет и http. Возможности самого приложения крайне ограничены, так хотя бы с помощью него можно было бы к основным настройкам прорваться, но нет. Если уехал и доступ не открыл и при этом ещё и ни один из VPN серверов не включил, то про роутер можешь забыть. Тут только просить того, кто около роутера отпереть закрытую дверь изнутри. Если дома никого нет, можно соседу позвонить и попросить подключиться по wifi. Надеюсь в новом приложении эту проблему решили.

Для ваших целей Гига больше подходит. Всё же Экстра это аппарат для дома. Так ограничьте скорости для тех устройств с которых вы качаете ваши терабайты и процессор Экстры не будет забиваться под завязку. У вас должен быть установлен компонент "шейпер трафика". Ограничитель найдёте в разделе "список устройств".

Типа того. Но реально AES-128 SHA1 будет достаточно. Но если на вас ведут охоту агенты АНБ, то можете усилить шифрование.

На младших моделях AES работает значительно быстрее DES. Как на Гигах точно не скажу. Проверьте производительность по факту.

Зайдите в "Другие подключения".

Omni в паре с Asus PCE AC56 это конечно сильно. )))

Смените DES на AES и будет более 30 мегабит. Что касается падений, то вроде такого нет. Если хотите леталова, то берите две Гиги.

Используйте EoIP/IPsec между роутерами. Для Винды SSTP, по iOS надо тестировать.

Поясните, где взять эти записи?

Странные они эти разработчики IPsec. Но может тогда инвалиду костыль прикрутить? Тут вот коллеги по цеху калеке соорудили трость https://habr.com/post/252917/ Теперь хоть и прихрамывая, но ходит. Может и нашему больному подсобить по аналогии? Без динамического ip ну совсем некошерно получается. Если надо в CLI что-то прописать, то поделитесь секретом, дайте конфиг, тут все свои.

Имеем Экстру 2 и Омни 1 на 2.13.A.5.0-4. Между ними установлено IPsec соединение, где Экстра сервер, а Омни клиент, соединение успешно устанавливается и стабильно работает. Но в случае смены ip адреса Экстры туннель не поднимается и в логах клиента видим это: IpSec::Configurator: remote peer of crypto map "w" is down. Авг 20 18:51:41 ndm IpSec::Configurator: "w": crypto map active IKE SA: 0, active CHILD SA: 0. Авг 20 18:51:41 ndm IpSec::Configurator: fallback peer is not defined for crypto map "w", retry. Авг 20 18:51:41 ndm IpSec::Configurator: "w": schedule reconnect for crypto map. Авг 20 18:51:41 ipsec 09[IKE] establishing IKE_SA failed, peer not responding Авг 20 18:51:57 ndm IpSec::Configurator: reconnecting crypto map "w". Авг 20 18:51:59 ndm IpSec::Configurator: "w": crypto map shutdown started. Авг 20 18:51:59 ipsec 09[CFG] received stroke: unroute 'w' Авг 20 18:51:59 ipsec 05[CFG] received stroke: terminate 'w{*}' Авг 20 18:51:59 ipsec 05[CFG] no CHILD_SA named 'w' found Авг 20 18:51:59 ndm IpSec::Configurator: "w": crypto map shutdown complete. Авг 20 18:51:59 ipsec 08[CFG] received stroke: terminate 'w[*]' Авг 20 18:51:59 ipsec 08[CFG] no IKE_SA named 'w' found Авг 20 18:52:01 ipsec 09[CFG] received stroke: initiate 'w' Авг 20 18:52:01 ndm IpSec::Configurator: "w": crypto map initialized. Авг 20 18:52:01 ipsec 05[IKE] initiating IKE_SA w[4] to 88.81.58.211 Авг 20 18:52:09 ipsec 07[IKE] retransmit 1 of request with message ID 0 Авг 20 18:52:18 ipsec 08[IKE] retransmit 2 of request with message ID 0 Авг 20 18:52:28 ipsec 06[IKE] retransmit 3 of request with message ID 0 Авг 20 18:52:38 ipsec 07[IKE] retransmit 4 of request with message ID 0 Авг 20 18:52:50 ipsec 06[IKE] retransmit 5 of request with message ID 0 Авг 20 18:53:03 ipsec 07[IKE] retransmit 6 of request with message ID 0 Авг 20 18:53:17 ipsec 07[IKE] retransmit 7 of request with message ID 0 Авг 20 18:53:33 ipsec 05[IKE] retransmit 8 of request with message ID 0 Авг 20 18:53:50 ipsec 07[IKE] giving up after 8 retransmits Авг 20 18:53:50 ndm IpSec::Configurator: remote peer of crypto map "w" is down. Причина оказалась в том, что клиент после смены адреса сервера вместо того чтобы узнать новый адрес пытается подключиться по старому. Ни дёрганье рубильника соединения, ни перезагрузка не понуждают клиент узнать новый адрес сервера. Но если забить вместо доменного имени ip адрес сервера в настройки клиента, то он сразу подключается. В итоге ситуация оказалась даже ещё веселее, чем казалась вначале. Допустим мы создали подключение с указанием доменного имени сервера, клиент обратился к DNS (в данном случае KeenDNS) и узнал, что адрес сервера допустим 1.1.1.1 и подключился по этому адресу. Далее сервер сменил ip, туннель упал, а клиент безрезультатно пытается подключиться по адресу 1.1.1.1. Мы в настройках клиента указываем вместо доменного имени сервера его текущий ip адрес, допустим 2.2.2.2 и клиент тут же подключается по этому адресу. Меняем ip сервера и туннель снова падает. Заменяем ip адрес обратно на доменное имя и клиент вместо того, чтобы отрезолвить ip адрес сервера, снова подключается по адресу 1.1.1.1!!! Понятное дело если у сервера статический ip, то данной проблемы не будет, но с динамическим как быть? Все же если клиента не трогать, то в конце концов он подключится, но ждать придётся очень долго. Также обнаружился забавный глюк в виде того, что нельзя задать имя подключения, если оно содержит чётное количество символов, Кинетик пишет "недопустимые символы". Также глючит выключатель соединения, но это уже глюки web и другая тема.

И заодно не помешало бы добавить туда уровень сигнала wifi клиентов в децибелах.

Это очень странно. Подключаетесь вы через провайдера, а ip от openvpn? Так быть не должно. VPN клиенты по умолчанию используют основное соединение и не используют openvpn как вы и хотели. Если сделать openvpn основным, то pptp подключаться не будет. Трудно представить чего вы там накрутили.

Одновременно имеют два внешних ip? Это как?

У вас сейчас при подключении pptp клиентов какое соединение они используют?

Уже давно. А резервное подключение случаем не через модем?

Уже сделали. Вам лучше попробовать OpenVPN, там многое из того что вы хотите есть.

SSTP в случае серого ip работает через сервера NDMS, которые являются посредником. Для других типов подключений этого не предусмотрено. Хотя есть сервисы (платные) позволяющие подключаться к серым ip и через L2TP. Для проверки доступа к роутеру откройте его вебморду на внешку и попробуйте зайти на неё через мобильную сеть. Используйте при этом ip выданный провайдером, а не доменное имя. Keendns позволит вам зайти на вебморду по доменному имени в режиме облака даже на серый ip, опять же через NDMS. Забудьте вы про keendns, он L2TP не помощник. Ещё вариант, что провайдер блокирует VPN, но это маловероятно. А SSTP "прикидывается" обычным https и его не блокируют.

Значит у вас серый ip и к L2TP подключиться нельзя. Вам провайдер видимо выдаёт микс, иногда белый, иногда серый ip.