Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • 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
    MK VPN & windows client

    MK VPN & windows client

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    MK VPN & windows client, RouterOS
     
    surfnet
    Guest
    #1
    0
    22.08.2005 23:50:00
    У меня на Mikrotik 2.9rc10 настроен DSL-аккаунт с обычным статным IP, маршрутизация идет через DSL, без PPPoE и прочего. Я сам выступаю в роли провайдера и пытаюсь настроить VPN-соединение для клиента, чтобы он мог получить доступ к своей сети. Настроил VPN по умолчанию, без шифрования. Соединение работает отлично изнутри нашей сети, где и происходит терминация DSL в нашем Redback. Однако, подключение из других мест не работает. Всегда получаю ошибку 651. Вот что показывают логи на Mikrotik:

    07:32:34 pptp,info TCP connection established from 66.151.140.236
    07:32:34 pptp,ppp,debug <66.151.140.236>: PPP started
    07:32:34 pptp,ppp,info : waiting for call…
    07:32:34 pptp,debug,packet rcvd Start-Control-Connection-Request from 66.151.140.236
    07:32:34 pptp,debug,packet protocol-version=0x0100
    07:32:34 pptp,debug,packet framing-capabilities=1
    07:32:34 pptp,debug,packet bearer-capabilities=1
    07:32:34 pptp,debug,packet maximum-channels=0
    07:32:34 pptp,debug,packet firmware-revision=2195
    07:32:34 pptp,debug,packet host-name=
    07:32:34 pptp,debug,packet vendor-name=Microsoft Windows NT
    07:32:34 pptp,debug,packet sent Start-Control-Connection-Reply to 66.151.140.236
    07:32:34 pptp,debug,packet protocol-version=0x0100
    07:32:34 pptp,debug,packet result-code=1
    07:32:34 pptp,debug,packet error-code=0
    07:32:34 pptp,debug,packet framing-capabilities=2
    07:32:34 pptp,debug,packet bearer-capabilities=0
    07:32:34 pptp,debug,packet maximum-channels=0
    07:32:34 pptp,debug,packet firmware-revision=1
    07:32:34 pptp,debug,packet host-name=MikroTik
    07:32:34 pptp,debug,packet vendor-name=MikroTik
    07:32:34 pptp,debug,packet rcvd Outgoing-Call-Request from 66.151.140.236
    07:32:34 pptp,debug,packet call-id=3448
    07:32:34 pptp,debug,packet call-serial-number=42859
    07:32:34 pptp,debug,packet minimum-bps=300
    07:32:34 pptp,debug,packet maximum-bps=100000000
    07:32:34 pptp,debug,packet bearer-type=3
    07:32:34 pptp,debug,packet framing-type=3
    07:32:34 pptp,debug,packet packet-recv-window-size=64
    07:32:34 pptp,debug,packet packet-processing-delay=0
    07:32:34 pptp,debug,packet phone-number-length=0
    07:32:34 pptp,debug,packet phone-number=
    07:32:34 pptp,debug,packet subaddress=
    07:32:34 pptp,ppp,debug <66.151.140.236>: PPP connected
    07:32:34 pptp,ppp,debug <66.151.140.236>: LCP lowerup
    07:32:34 pptp,ppp,debug <66.151.140.236>: LCP open
    07:32:34 pptp,debug,packet sent Outgoing-Call-Reply to 66.151.140.236
    07:32:34 pptp,debug,packet call-id=30
    07:32:34 pptp,debug,packet peers-call-id=3448
    07:32:34 pptp,debug,packet result-code=1
    07:32:34 pptp,debug,packet error-code=0
    07:32:34 pptp,debug,packet cause-code=0
    07:32:34 pptp,debug,packet connect-speed=100000
    07:32:34 pptp,debug,packet packet-recv-window-size=100
    07:32:34 pptp,debug,packet packet-processing-delay=0
    07:32:34 pptp,debug,packet physical-channel-id=0
    07:32:35 pptp,ppp,debug <66.151.140.236>: LCP timer
    07:32:35 pptp,ppp,debug,packet <66.151.140.236>: sent LCP ConfReq id=0x1
    07:32:35 pptp,ppp,debug,packet <mru 1460>
    07:32:35 pptp,ppp,debug,packet <magic 0x3f6ab60f>
    07:32:35 pptp,ppp,debug,packet
    07:32:36 pptp,ppp,debug <66.151.140.236>: LCP timer
    07:32:36 pptp,ppp,debug <66.151.140.236>: LCP timeout waiting initial data
    07:32:36 pptp,ppp,debug <66.151.140.236>: LCP lowerdown
    07:32:36 pptp,ppp,info : terminating…
    07:32:36 pptp,ppp,debug <66.151.140.236>: PPP disconnected <>
    07:32:36 pptp,ppp,debug <66.151.140.236>: PPP destroy
    07:32:36 pptp,ppp,debug <66.151.140.236>: PPP stopped
    07:32:36 pptp,ppp,info : disconnected
    07:32:36 pptp,ppp,debug <66.151.140.236>: CCP lowerdown
    07:32:36 pptp,ppp,debug <66.151.140.236>: CCP down event in initial state
    07:32:36 pptp,ppp,debug <66.151.140.236>: IPCP lowerdown
    07:32:36 pptp,ppp,debug <66.151.140.236>: IPCP down event in initial state
    Есть какие-нибудь идеи?
     
     
     
    wildbill442
    Guest
    #2
    0
    23.08.2005 03:52:00
    У тебя есть какие-нибудь правила брандмауэра, которые могут блокировать GRE-пакеты и/или TCP-порт 1723? Ты осуществляешь NAT для своих подписчиков? Или у них есть публичные маршрутизируемые IP-адреса?
     
     
     
    surfnet
    Guest
    #3
    0
    23.08.2005 13:33:00
    Я ничего не блокирую через файрвол, хотя и нахожусь за другим MK, делающим NAT.
     
     
     
    cmit
    Guest
    #4
    0
    23.08.2005 14:03:00
    Ты уже организовал прохождение TCP-соединения управления (порт 1723) и протокол GRE через твой NATing MikroTik к VPN-шлюзу?
     
     
     
    surfnet
    Guest
    #5
    0
    23.08.2005 15:05:00
    Как мне настроить пропуск TCP-соединения управления (порт 1723) и протокол GRE через ваш NAT MikroTik? Я думал, что они должны проходить автоматически, ведь многие наши существующие клиенты используют VPN для работы.
     
     
     
    cmit
    Guest
    #6
    0
    23.08.2005 15:16:00
    Хм, возможно, я тебя неправильно понял. Если ты находишься за NAT-устройством и выполняешь ВЫХОДЯЩИЙ NAT, то, вероятно, все должно быть в порядке. Проверь, что активен gre NAT helper (“/ip firewall service-port print”) - обычно он и так включен. Я думал, у тебя VPN-сервер находится за NAT-устройством – тогда тебе пришлось бы использовать dst-nat, чтобы перенаправить TCP-порт 1723 и протокол GRE на твой VPN-сервер…
     
     
     
    surfnet
    Guest
    #7
    0
    23.08.2005 15:30:00
    Вижу эти служебные порты… когда я их включаю, мне нужно добавить порт?, или оставить поле пустым? Вот статус портов на VPN-сервере MK. [admin@MikroTik] ip firewall service-port> print Flags: X - disabled, I - invalid NAME PORTS 0 ftp 21 1 tftp 69 2 irc 6667 3 X h323 4 quake3 5 mms 6 gre 7 pptp
     
     
     
    cmit
    Guest
    #8
    0
    23.08.2005 15:52:00
    Всё в порядке. Если ты за MASQUERADING NAT-устройством (то есть PPTP-клиент находится за NAT, а не сервер), всё должно работать…
     
     
     
    surfnet
    Guest
    #9
    0
    06.09.2005 13:56:00
    Ответ на мой собственный вопрос… У меня были свои внутренние проблемы с маршрутизацией mk - mk pptpt link, но у клиента я обнаружил, что это проблема в прошивке роутера Netgear. После обновления прошивки всё заработало отлично.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры