Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • 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
    Успешное тестирование маршрутизатора Amazon CHR на RouterOS

    Успешное тестирование маршрутизатора Amazon CHR на RouterOS

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Успешное тестирование маршрутизатора Amazon CHR на RouterOS, RouterOS
     
    killersoft
    Guest
    #1
    0
    25.10.2016 09:47:00
    Всем привет. Только что провёл тест Amazon Web Services с Mikrotik RouterOS, используя доступный в amazon marketplace релиз RouterOS v6.34.1. Так как это был просто тест, я сделал обновление до v6.38rc15 — прошло без проблем. Для теста использовал t2.micro (Free tier). От старта всего процесса в marketplace до появления ссылки на winbox прошло около 2 минут. В общем, прикрепил пару скриншотов работы с winbox.

    Кстати, быстро проверил webproxy — тоже работает отлично.
     
     
     
    ditonet
    Guest
    #2
    0
    22.11.2016 00:25:00
    @killersoft Ты смог запустить CHR с добавленным вторым сетевым интерфейсом? С уважением,
     
     
     
    hca
    Guest
    #3
    0
    23.01.2017 01:46:00
    Я тоже пытаюсь это протестировать, но не могу войти в образ mikrotik с помощью AWS-key.pem — он запрашивает пароль. Правильный ли пользователь root? Должен ли я иметь доступ под root, как описано в инструкциях по подключению из маркетплейса, или там какой-то секрет? Очень хочу попробовать. Спасибо!
     
     
     
    ditonet
    Guest
    #4
    0
    23.01.2017 22:18:00
    Пользователь по умолчанию — «admin». Вот статья в Wiki по установке CHR на AWS: http://wiki.mikrotik.com/wiki/Manual:CHR_AWS_installation Надеюсь, будет полезно.
     
     
     
    hogsberg
    Guest
    #5
    0
    31.01.2017 19:54:00
    Привет. Я успешно запустил экземпляр AWS CHR (6.38.1), НО если я подключаю ко второму сетевому интерфейсу на инстансе, он отображается как Запущенный в разделе Интерфейсы с правильно назначенным IP-адресом, но при этом совершенно не работает (не доступен ни через веб, ни через Winbox). В конечном итоге весь инстанс становится нестабильным и недоступным. Это баг или я что-то делаю не так?
     
     
     
    ditonet
    Guest
    #6
    0
    01.02.2017 12:05:00
    У меня были похожие проблемы, и в итоге я решил не использовать CHR на AWS. С уважением,
     
     
     
    janisk
    Guest
    #7
    0
    03.02.2017 08:35:00
    Пожалуйста, проверьте документацию AWS или подробно опишите, какие действия вы выполняли, чтобы прийти к выводу, что это не работает. В моих тестах вторичный интерфейс корректно добавлялся, и изменение назначенного адреса на интерфейсе не вызывало проблем с подключением к работающему инстансу.

    Добавлю: тест был проведён на версии 6.38.2 на EC2-инстансах. При этом есть требование обязательно иметь Elastic IP для инстанса, если используется более одного интерфейса. Также проверьте настройки безопасности сети, так как трафик может блокироваться внутренним файрволом Amazon.
     
     
     
    ditonet
    Guest
    #8
    0
    03.02.2017 10:44:00
    @janisk Я проходил тест AWS два месяца назад и уже не помню подробностей. Были другие мелкие проблемы/неудобства из-за инфраструктуры AWS, а не из-за CHR, который работал нормально. Я также тестировал другие облачные сервисы и в итоге решил не запускать CHR на AWS. Сейчас уже два месяца запускаю два CHR на других облаках, и пока всё отлично. С уважением,
     
     
     
    hogsberg
    Guest
    #9
    0
    03.02.2017 11:55:00
    Эээ... Думаю, я описал всё подробно. Всё довольно просто. Мне нужен внешний IP только на одном интерфейсе, так что дополнительный Elastic IP не нужен — у инстанса изначально есть внешний IP. Кроме того, второй внутренний IP назначен второму сетевому интерфейсу. Но в любой момент времени доступен только один интерфейс. Оба интерфейса используют одну и ту же группу безопасности, которая разрешает входящие подключения по winbox.
     
     
     
    janisk
    Guest
    #10
    0
    03.02.2017 12:22:00
    С какой сети у вас был локальный IP-адрес, назначенный интерфейсам? Также, как указано в документации Amazon, назначенный IP-адрес NATится только на один внутренний IP-адрес, и виртуальные интерфейсы не могут взаимодействовать друг с другом.
     
     
     
    hogsberg
    Guest
    #11
    0
    03.02.2017 13:42:00
    Это моя текущая тестовая настройка, внутреннюю сеть 172.31.32.0/20 предоставляет AWS. На ether2 добавлен Elastic IP, чтобы проверить, повлияет ли это на работу. Для теста я подключен к AWS через site-to-site VPN, используя функцию AWS VPN (с аппаратным MT с моей стороны). Разве я не должен иметь возможность пинговать как ether1 internal, так и ether2 internal от своего конца? Сейчас могу пинговать только ether1. Если отключить ether1 на MT, могу пинговать ether2. Если снова включить ether1, всё равно могу пинговать только ether1.
     
     
     
    janisk
    Guest
    #12
    0
    06.02.2017 08:14:00
    Насколько я понял из документации AWS, работает это так. Тебе нужно изучить настройки VPS, чтобы понять, как создать локальную сеть или как настроить туннель от AWS к твоей сети. В инфраструктуре AWS эти интерфейсы никак между собой не связаны.
     
     
     
    hca
    Guest
    #13
    0
    15.02.2017 21:11:00
    У меня проблемы с IPSEC VPN-туннелем от «HOME» до CHR на AWS. У меня есть несколько туннелей между MT, разбросанными по интернету, но с AWS CHR никак не получается разобраться. Я пытаюсь обращаться с ним как с обычным MT-роутером в интернете — это правильно? Фаза 2 не завершается, хотя политики и секреты совпадают. Нужны свежие глаза…

    НАСТРОЙКА:  
    У меня есть образ CHR, работающий на AWS, и физический MT-роутер дома. У обоих есть свои приватные сети.

    HOME_IP_ADDRESS  
    HOME_INSIDE_NETWORK = 192.168.30.0/24  
    HOME_INSIDE_ADDRESS = 192.168.30.1

    CHR_IP_ADDRESS  
    CHR_INSIDE_NETWORK = 172.31.64.0/24  
    CHR_INSIDE_ADDRESS = 172.31.64.X

    Security group для инстанса CHR EC2 полностью открыта, и по интернету, и по приватной сети.  
    HOME и CHR имеют открытые фаерволы для IP друг друга и для всех адресов в приватных сетях за ними.

    CHR настроен на NAT для трафика, выходящего из CHR_INSIDE_NETWORK через роутер CHR.  
    HOME и CHR настроены так, чтобы обходить NAT для VPN-трафика между их сетями.

    Роутер HOME может пинговать CHR_IP_ADDRESS, и CHR пингует HOME_IP_ADDRESS.  
    CHR пингует CHR_IP_ADDRESS и CHR_INSIDE_ADDRESS, а также другие Linux-инстансы в CHR_INSIDE_NETWORK.

    HOME и CHR используют дефолтные ipsec proposals:

    HOME>set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m name=default pfs-group=modp1024

    CHR>set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m name=default pfs-group=modp1024

    Настройки HOME:  
    /ip address add address=192.168.30.1/24 comment=defconf interface=ether2-master network=192.168.30.0  
    /ip ipsec peer add address=CHR_IP_ADDRESS/32 auth-method=pre-shared-key comment=AWS-CHR dh-group=modp1024 disabled=no dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-128,3des exchange-mode=main generate-policy=no hash-algorithm=sha1 lifetime=1d nat-traversal=no policy-template-group=default proposal-check=obey secret=SECRET send-initial-contact=yes  
    /ip ipsec policy add action=encrypt comment=AWS-CHR disabled=no dst-address=172.31.64.0/24 dst-port=any ipsec-protocols=esp level= require priority=0 proposal=default protocol=all sa-dst-address=CHR_IP_ADDRESS sa-src-address=HOME_IP_ADDRESS src-address=192.168.30.0/24 src-port=any tunnel=yes

    Настройки CHR:  
    /ip address add address=172.31.64.X interface=ether2 network=172.31.64.0  
    /ip ipsec peer add address=HOME_IP_ADDRESS/32 auth-method=pre-shared-key comment=HOME dh-group=modp1024 disabled=no dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-128,3des exchange-mode=main generate-policy=no hash-algorithm=sha1 lifetime=1d nat-traversal=no policy-template-group=default proposal-check=obey secret=SECRET send-initial-contact=yes  
    /ip ipsec policy add action=encrypt comment=HOME disabled=no dst-address=192.168.30.0/24 dst-port=any ipsec-protocols=esp level= require priority=0 proposal=default protocol=all sa-dst-address=HOME_IP_ADDRESS sa-src-address=CHR_IP_ADDRESS src-address=172.31.64.0/24 src-port=any tunnel=yes

    Логи CHR, ошибки:  
    HOME_IP_ADDRESS failed to pre-process ph2 packet.  
    HOME_IP_ADDRESS peer sent packet for dead phase2  
    HOME_IP_ADDRESS failed to pre-process ph2 packet.  
    …

    Логи HOME, ошибки:  
    В окне IPSEC policy соединение показывает “msg 1 sent”, а потом “no phase2”.
     
     
     
    hca
    Guest
    #14
    0
    16.02.2017 15:28:00
    Я нашёл ошибку. Адреса AWS в предыдущем сообщении были неполными. При настройке туннеля используется как «внешний» интернет-адрес CHR, так и «внутренний» NATed-адрес. В ipsec-политике для sa-src-address должен использоваться CHR_IP_ADDRESS_INTERNAL, а CHR_IP_ADDRESS_EXTERNAL применяется в других местах. Чтобы ещё раз повторить конфигурацию из предыдущего сообщения:

    HOME_IP_ADDRESS  
    HOME_INSIDE_NETWORK = 192.168.30.0/24  
    HOME_INSIDE_ADDRESS = 192.168.30.1  

    CHR_IP_ADDRESS_EXTERNAL  
    CHR_IP_ADDRESS_INTERNAL  
    CHR_INSIDE_NETWORK = 172.31.64.0/24  
    CHR_INSIDE_ADDRESS = 172.31.64.X  

    Настройки HOME:  
    /ip ipsec peer add address=52.37.130.208/32 comment=AWS-CHR nat-traversal=no secret=SECRET  
    /ip ipsec policy add comment=AWS-CHR dst-address=172.31.64.0/24 sa-dst-address=CHR_IP_ADDRESS_EXTERNAL sa-src-address=HOME_IP_ADDRESS src-address=192.168.30.0/24 tunnel=yes  

    Настройки CHR:  
    /ip ipsec peer add address=HOME_IP_ADDRESS/32 comment=HOME nat-traversal=no secret=SECRET  
    /ip ipsec policy add comment=HOME dst-address=192.168.30.0/24 sa-dst-address=HOME_IP_ADDRESS sa-src-address=CHR_IP_ADDRESS_INTERNAL src-address=172.31.64.0/24 tunnel=yes
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры