Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Клиент SSTP Mikrotik / вероятно, баг в версии 6.41.3

    Клиент SSTP Mikrotik / вероятно, баг в версии 6.41.3

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Клиент SSTP Mikrotik / вероятно, баг в версии 6.41.3, RouterOS
     
    panisk0
    Guest
    #1
    0
    06.04.2018 13:40:00
    Я использую SSTP для подключения двух сетей. Заметил, что если на время связь у оператора прерывается, клиент SSTP отказывается подключаться, даже когда линия снова начинает работать нормально. Единственное решение — удалить клиента SSTP и добавить нового с теми же параметрами или перезагрузить роутер клиента. Такая ситуация возникает у нескольких клиентов из разных локаций. Есть идеи?

    Лог главного роутера:  
    15:34:12 sstp,ppp,info,account sXs вошёл в систему, 172.1.55.6  
    15:34:12 sstp,ppp,info sstp-sXs: аутентификация прошла успешно  
    15:34:12 sstp,ppp,info sstp-sXs: завершается… — nonce не совпадает  
    15:34:12 sstp,ppp,info,account sXs вышел из системы, 0 0 10 0 1  
    15:34:12 sstp,ppp,info sstp-sXs: клиент отключён

    Лог клиентского роутера:  
    15:36:15 sstp,ppp,info sstp-sXs: подключение…  
    15:36:17 sstp,ppp,info sstp-sXs: аутентификация успешна  
    15:36:17 sstp,ppp,info sstp-sXs: завершение… — прервано пэром  
    15:36:17 sstp,ppp,info sstp-sXs: отключён
     
     
     
    JacquesLaG
    Guest
    #2
    0
    20.02.2022 07:45:00
    Привет, Sergejs! В данный момент мой hAPac2 (arm) работает на версии v6.48.6 (обновление routerboard тоже на v6.48.6). На нём запущен SSTP-сервер. Удалённое устройство SXTsq5lite пытается подключиться. Точную версию ПО этого устройства не знаю (новая, только из коробки, обновлений не было). У меня 85 активных SSTP-подключений к тому же hAPac2, все работают корректно. Скажи, какую информацию я могу предоставить, чтобы помочь разобраться с ситуацией?
     
     
     
    SpiritVII
    Guest
    #3
    0
    22.02.2022 13:55:00
    Привет, такое же поведение на CHR (приём с удалением и отменой работает…).
     
     
     
    bcmdevtl
    Guest
    #4
    0
    21.06.2022 02:52:00
    Привет, Sergejs! У нас на стороне такая же проблема — работаем на CHR версии 6.48.6 и RB951Ui-2HnD примерно на 100 сайтах. Ошибка «nonce not matching» появляется спустя некоторое время, перезагрузка роутера решает проблему, но спустя время она снова возвращается. Время от перезагрузки до появления ошибки варьируется от одного дня до недели или двух, поэтому мы настроили минимум ежемесячную перезагрузку.

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

    Знаю, что мы используем более старую версию, так как придерживаемся долгосрочных веток, но есть ли более свежая версия, в которой, по вашему мнению, эта проблема уже решена? Заранее спасибо!
     
     
     
    sindy
    Guest
    #5
    0
    08.08.2022 17:34:00
    Я столкнулся с этим впервые сегодня, на wAP ac LTE (arm) с прошивкой 6.47.10 (сервер — hAP ac2 с 6.48.6). Удаление и отмена на клиенте сработали. Думаю, это проявилось из-за сезонной перегрузки LTE-сектора, к которому подключён wAP ac. Пока не ясно, повторится ли ещё. Если да, есть ли тестовая сборка для версии 6.x? Устройство находится в 600 км, и рядом нет никого, кто достаточно квалифицирован для netinstall.
     
     
     
    anav
    Guest
    #6
    0
    08.08.2022 17:58:00
    Известная проблема, которая до сих пор не решена с 2018 года? Похоже, вы утверждаете, что из-за перегрузки Wi-Fi соединение SSTP начинает глючить? Кажется, здесь повторяется одна и та же тема с протоколами безопасности и тем, что происходит при отключении — никакого плавного восстановления... недостаток надежности в программном коде.
     
     
     
    mojiro
    Guest
    #7
    0
    18.03.2024 10:49:00
    Случается, что у меня такая же проблема с некоторыми старыми установками, которые я не могу обновлять, потому что они находятся удалённо. Мой SSTP Server работает на версии 7.14.1, а удалённые клиенты используют версии от 6.23 до 6.43.2. Проблема носит случайный характер, и единственным постоянным решением было отключить сертификат на сервере. То есть никакой безопасности в «безопасном» VPN, но они остаются подключёнными... ¯_(ツ)_/¯
     
     
     
    anav
    Guest
    #8
    0
    18.03.2024 11:36:00
    Или время для поездки — рано или поздно наличие удалённых устройств означает поездку. С wireguard и программным обеспечением ver7, вероятно, скоро. Это должно быть встроенной функцией любого IT-оборудования в любом случае.
     
     
     
    bcmdevtl
    Guest
    #9
    0
    25.04.2024 08:58:00
    В итоге мы обновились до версии 7 и начали использовать Wireguard, и он работает отлично. SSTP оставили в стороне и забыли обо всех тех проблемах.
     
     
     
    anav
    Guest
    #10
    0
    25.04.2024 13:41:00
    Между двумя устройствами MT настроить SSTP без сертификата было довольно просто, как резерв к wireguard. Теперь я склоняюсь к использованию IP-IP туннеля с IPsec secret — это простой и более надёжный резерв. Так что SSTP на пенсию, хаха.
     
     
     
    Cha0s
    Guest
    #11
    0
    09.11.2018 11:41:00
    Это только что случилось со мной на одном из моих SSTP VPN с версией 6.34.4. В логах я получаю ту же ошибку: «nonce не совпадает».
     
     
     
    andrei
    Guest
    #12
    0
    13.11.2018 13:47:00
    У меня то же самое. Похоже, это какая-то ошибка.
     
     
     
    MoneyTalks
    Guest
    #13
    0
    06.01.2019 14:31:00
    У меня тоже с версией 6.43.8 была такая проблема, пришлось перенастроить клиент SSTP, теперь всё работает.
     
     
     
    AndyW
    Guest
    #14
    0
    19.10.2020 08:41:00
    У меня тоже была такая проблема с версией 6.42.9 на VPN-терминаторе, работающем на CHR, и клиентами версии 6.44.5, запущенными на разном оборудовании Mikrotik. Самый быстрый способ её решить — удалить клиентский VPN, а потом отменить это изменение:  
    /interface sstp-client print  
    /interface sstp-client remove 0  
    /undo  

    Отключение и повторное включение ссылки, похоже, не помогало. Перезагрузка клиента тоже срабатывала. Думаю написать скрипт для этого, но сначала хотелось бы узнать, может, есть более удобное решение. У нас несколько SSTP VPN работают как VPN «сайт-сайт», большинство из них стабильны. Кажется, проблема возникает из-за нестабильности базового соединения (все, кроме одной VPN с такой проблемой, использовали сильно загруженные 3G или 4G каналы), но как только проблема появляется, она редко решается сама без ручного вмешательства.

    Пока что не смог найти, как исправить это централизованно. Если отключить учётную запись пользователя, появляются ошибки входа, но стоит только включить обратно — ошибка возвращается. Не знаю, совпадение ли это, но обычно проблема возникает только у одного-двух VPN-клиентов одновременно.  

    Раньше была серьёзная проблема с одним конкретным каналом, который приходилось перезагружать каждый день, но с появлением проблем на другом канале первый стал работать стабильно.  

    Кто-нибудь сталкивался с этим и сумел решить? Буду благодарен за любые советы!
     
     
     
    vogtdominik
    Guest
    #15
    0
    23.03.2021 09:24:00
    Со мной тоже такое случается. Сервер 6.46.7 CHR, клиенты 6.46.7 MIPSBE, по крайней мере, не уверен, повторяется ли это на ARM. Мы используем CHR VPN Server на DigitalOcean, и во время их технического обслуживания наши VPN-серверы всегда требуют присмотра. MIKROTIK, ПОЖАЛУЙСТА, ИСПРАВЬТЕ ЭТО! @AndyW: Мы используем запасной VPN по l2tp/ipsec, если основной SSTP VPN отказывает.
     
     
     
    sergejs
    Guest
    #16
    0
    03.11.2021 08:00:00
    Я понимаю, что это довольно старое сообщение... Но вдруг у вас случайно появилась такая же проблема. Мы можем предложить вам тестовую сборку для её решения. Дайте знать, если интересно.
     
     
     
    AndyW
    Guest
    #17
    0
    04.11.2021 08:27:00
    Привет, Sergejs! Я с удовольствием попробую тестовую сборку для этого. Мы сами провели дополнительные тесты, развернув около 40 таких ссылок. Похоже, что очень часто мобильная сеть работает нестабильно — связь то появляется, то пропадает. Изначально мы открывали SSTP-ссылки на порту 443 для Интернета, но это вызывало проблемы, потому что этот порт часто сканировали, как будто на нём веб-сервер. Чтобы исправить ситуацию, мы подключились к Mikrotik через обратный прокси Nginx. Именно эта схема вызывала больше всего ошибок с несовпадением nonce. После этого мы перенесли ссылки на использование высокоуровневого порта, и, похоже, теперь всё работает нормально.

    Также мы настроили сайты с двумя SSTP-туннелями: один на главном роутере, второй — на 4G-роутере, при этом основной маршрут идёт через главный роутер, а не через 4G-связь. Сайт, который вызывал у нас больше всего проблем, теперь использует оптоволоконную MPLS-связь, а SSTP остались только для наших управленческих подключений. Я также изучаю L2TP поверх IPSec, как советовал vogtdominik. Думаю, это поможет решить проблему с обрывами из-за плохого мобильного сигнала.

    Мне нравится простота SSTP с взаимной аутентификацией на основе TLS-сертификатов — это проще, чем IPSec, поэтому было бы здорово использовать это с уверенностью. Все наши объекты удалённые, но, поскольку у нас уже есть управленческое соединение через главный роутер, не составит труда обновить прошивку на 4G-роутере и подключить его к отдельному VPN-серверу для тестирования. Все 4G-маршрутизаторы — модели RBwAPR-2nD. Центральный сервер — CHR, работающий на KVM, так что мы можем создать ещё одну виртуальную машину для тестов.

    Как уже говорил, с тех пор, как мы перестали использовать обратный прокси Nginx, проблема не повторялась, так что, возможно, мы не лучший кандидат для тестирования. Но если смогу помочь — всегда рад.
     
     
     
    sergejs
    Guest
    #18
    0
    05.11.2021 09:53:00
    Энди, здесь ты найдёшь пакет mipsbe для исправления SSTP, https://box.mikrotik.com/d/dafb3cf8e9994dde8dfb/. Если у тебя получится часто воспроизводить эту проблему, будет здорово, если ты поделишься с нами своими отзывами.
     
     
     
    aoakeley
    Guest
    #19
    0
    03.02.2022 08:53:00
    Это уже исправлено в каких-нибудь новых версиях?
     
     
     
    sergejs
    Guest
    #20
    0
    03.02.2022 08:55:00
    Вы можете воспроизвести эту проблему у себя? Если да, мы можем предоставить вам последнюю бету для тестирования.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры