• Mikrotik + IPSec + Cisco. Часть 2. Тоннель на «сером» IP

      В продолжение к посту.
      В прошлый раз я рассматривал соединение, когда со стороны циски и микрота были реальные IP'ы.
      Здесь рассмотрю пример «серого реальника», т.е серый IP, который провайдер маскирует у себя под внешний с безусловной переадресацией (binat).

      Техническая задача: организовать ipip-тоннель между офисами, с шифрованием ipsec, при помощи Mikrotik RB450G и Cisco 2821.



      Ньюансы

      на циске внешний IP, а на микротике серый, который маскируется провайдером под внешний, с безусловной переадресацией (обращения к этому внешнику из интернета редиректятся на интерфейсный, серый «IP»).
      Схема:

      Читать дальше →
      • +6
      • 43.2k
      • 1
    • Mikrotik + IPSec + Cisco = Мир, Дружба, Жвачка

        Техническая задача: организовать ipip-тоннель между офисами, с шифрованием ipsec, при помощи Mikrotik RB450G и Cisco 2821.


        Ньюансы

        • последняя версия софта на микроте (5.20)
        • тип тоннеля на циске IPIP
        • тип трансформы «transport», вместо «tunnel»

        Исходные данные

        • Cisco 2821 (OS v12.4)
        • 2. Mikrotik RB450G
        • 3. Реальные внешние IP на обоих устройствах
        • 4. Адрес циски: 77.77.77.226. Подсеть со стороны циски: 10.192.0.0/22
        • 5. Адрес микротика: 88.88.88.2. Подсеть со стороны микротика: 192.168.88.0/24

        Предыстория

        Столкнулся по работе с необходимостью замены серверов в наших филиалах, на что-нибудь более надёжное, аппаратное.
        Связь у нас с центральным офисом осуществляется через тонели с шифрованием ipsec. В центральном офисе у нас, собственно всё на кошкообразных построено, а в большинстве филиалов стоят обычные сервера под FreeBSD, которые цепляются тонелями, с помощью racoon.
        Встала задача, в связи с устареванием, выходом из строя самих серверов, начать устанавливать простые, недорогие аппаратные решения.

        Братья по-разуму, коллеги и форумы натолкнули меня на изделия Mikrotik, и сразу же я направил к ним письмо следующего содержания:
        Читать дальше →
      • Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования

        Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования


        Вводные данные

        При наличии двух собственных подсетей /24, столкнулся с необходимостью стандартной работы BGP, и погуглив, обнаружил минимальное количество информации по этой теме. На просторах рунета, в основном рассматриваются случаи, когда имеется одна сетка /24, и 2 провайдера, один из которых используется, как резервный. Да даже и этот случай рассмотрен некорректно, либо разрознено, нормально встретил описания только на англоязычных ресурсах.

        Сразу же оговорюсь — рассматриваемые фичи CiscoOS: EXIST-MAP и NON-EXIST-MAP не поддерживаются UNIX-аналогами (типа Quagga).

        В данной статье я рассмотрю два примера конфигов, исходя из следующих данных.
        1. У нас есть два канала: основной рабочий и резервный. Оба провайдера анонсируют нам дефолт. Использование обоих каналов для нас нежелательно. Мы, в свою очередь, будем анонсировать им свои подсети, но если жив основной канал — анонс наших префиксов в резервный канал мы принудительно запретим, и будем анонсировать, только в случае падения рабочего канала
        2. У нас есть два рабочих канала. И нам необходимо, чтобы через первый канал всегда работала (анонсировалась) наша первая подсеть, а через второй канал — наша вторая подсеть. Оба провайдера при этом анонсируют нам дефолты. В случае, если падает один из каналов — мы переносим анонс с этого канала, на оставшийся в живых. При возобновлении работы упавшего канала — возвращаем анонсы в начальный вид — по одной подсети через каждого провайдера


        Теория:
        Читать дальше →
        • +11
        • 40.1k
        • 9