Tag Archives: vpn

Как работает MPLS VPN

Всем привет. Сегодня наш разговор пойдет о такой технологии, как MPLS VPN. В предыдущей статье сеть была  этой технологии. Я демонстрировал, как защищаться от флуда маршрутов со стороны клиента. В этой статье мы разберем, как работает сама сеть.

Я немного отступлю от обычной схемы своего повествования. Мой рассказ будет о том, что происходит в сети. А как что конфигурируется, можно прочитать в конфиге в конце статьи, да и в интернете масса примеров. Но вот что в интернете очень сложно найти, так это поэтапное описания, как такая сеть работает, какие этапы проходит пакет, почему не нужно организовывать туннели и самое главное, как проверить все ли правильно.


    Про виртуальные сети (часть 21). Ограничиваем таблицу маршрутизации VRF (часть 2)

    Итак, продолжаем разговор. В предыдущей статье мы разобрались, зачем нужно ограничивать таблицу маршрутизации и рассмотрели один из вариантов, как это сделать. Узнали, что можно ограничить таблицу маршрутизации командой maximum routes, но повлиять на использование ресурсов маршрутизатора процессом маршрутизации (OSPF в нашем случае) не можем.

    В этой статье рассмотрим другой способ ограничения маршрутов с использованием возможностей протокола BGP. (Вообще этот протокол много чего умеет, и в процессе его изучения создается ощущение, что он разве что картошку почистить не сможет.)


      Про виртуальные сети (часть 19). L2VPN + VRF

      Всем привет. Сегодня мы будем рассматривать такого зверя, как L2VPN. Что он из себя представляет? С точки зрения клиента – это просто Ethernet канал между двумя его маршрутизаторами, один широковещательный домен. А вот с точки зрения провайдера, все намного сложнее. Нужно поймать кадр Ethernet (ну или что там используется на канальном уровне), запаковать, передать через всю сеть, снова распаковать и отдать клиенту. Вот настройкой этой цепочки мы и займемся. Заодно проверим, что можно сделать, если взаимодействие провайдера с клиентом уже осуществляется и организовано с помощью VRF.


        L2TP — Layer 2 Tunneling Protocol

        Статью хотелось бы начать с вопроса:

        Зачем данный протокол?

        Из названия для того чтобы строить какие то туннели – туннели в наших сетях, а именно для объединения L2 доменов. Так как протокол L2 уровня, соответственно нужен для связи узлов по второму уровню модели OSI. А если еще заглянуть глубже, то L2TP нужен для инкапсулирования и туннелирования пакетов протокола PPP (Point-to-Point Protocol)

        L2tp – туннельный протокол работающий на канальном уровне модели OSI . Одно из главных преимуществ данного протокола является возможность работать в различных сетях не только IP, но и x25, frame relay и других, соединять L2 сети поверх различных других сетей.
        Немного истории.

        Протокол был создан благодаря взаимодействию двух корпораций Cisco и Microsoft в 1999 году.

        Немного порыскав в глобальной сети, нашел информацию:


          Что умеет туннельный интерфейс.

          Всем салют. Как я и обещал, немного расскажу про туннельные интерфейсы на виртуальных маршрутизаторах. Вообще речь шла о GRE, но это только один из режимов работы туннеля, и несмотря на то, что я буду все рассказывать на примере GRE, это также справедливо и для остальных режимов.

          Начнем немного с теории. Что такое туннель? Сразу представляется длинная сквозная дырка в земле, да? И когда мы говорим о сетевом туннеле, тоже представляется какая-то длинная труба, в которую впихиваются пакеты с одной стороны и выкидываются с другой, а маршрутизаторы их ловят (тем более, что так обычно и рисуют). Лично мне такая аналогия кажется немного притянутой за уши. Особенно если учесть, что ip-сети – это сети с пакетной коммутацией, в которых пакет может пройти различными путями, а туннель воспринимается как что-то стабильное. Более правильно, скорее, говорить о почтовых отправлениях, а туннельный интерфейс в этом случае почтальон, который упаковывает уже упакованные посылки и на новой упаковке пишет не адреса конечных отправителей и получателей, а адреса промежуточных почтовых отделений. А между этими отделениями такая посылка может путешествовать самыми разными путями и по земле, и по воде, и по воздуху, и даже, если вам угодно, по космосу. По прибытии в пункт назначения другой почтальон (туннельный интерфейс) распаковывает внешнюю упаковку и отправляет посылку уже конечному получателю.

          Конечно, я не собираюсь устраивать революцию в терминологии (тем более что у большинства читателей с почтой наверняка связаны не самые лучшие ассоциации), просто такое описание процесса, как мне кажется, лучше способствует пониманию сути сетевых туннелей. И в этой статье я хочу продемонстрировать некоторые возможности этих самых почтальонов – виртуальных туннельных интерфейсов.

          Итак, поехали.


            Про виртуальные сети (часть 18). DMVPN на виртуальных маршрутизаторах

            И снова привет. Мы уже изучили довольно много технологий, которые могут быть применены при построении сети на виртуальных маршрутизаторах. И теперь можно применить все эти знания (а так же кое-какие еще), чтобы построить макет сети предприятия.

            Предположим, что есть некое предприятие с центральным офисом и тремя филиалами, которые нужно объединить в одну сеть. Предприятие не очень богатое (а может просто имеет широкую географию), поэтому для связи между офисами использует арендованные каналы. Это может быть сеть одного конкретного провайдера или Интернет, не важно. Важно, что предприятию выделили IP-адреса, маршрутизируемые в этой  сети, и можно с их использованием объединять сети.

            DMVPN отлично подходит для этой задачи, поэтому в этой статье мы рассмотрим поэтапное построение и конфигурирование сети на базе этой технологии.


              Про виртуальные сети (часть 17).BGP в виртуальных сетях

              Сегодня мы обсудим Border Gateway Protocol (BGP). Как понятно из названия это протокол граничных (или пограничных, кому как нравится) маршрутизаторов, т.е. маршрутизаторов которые стоят на границах сетей и обеспечивают общение этих самых сетей между собой. Является основным протоколом маршрутизации в интернете. Ну и как следствие, является достаточно сложным в настройке, но зато и предоставляет много возможностей.

              Учитывая востребованность и распространенность этого протокола информации о нем в интернете читать, не перечитать. Однако у подавляющего большинства источников есть один общий недостаток, они или очень задвинуты в теорию и описание протокола, либо предлагаются конкретные конфиги, для конкретных сетей без особого разбора, что же это было. Я постараюсь, по мере возможности все-таки найти золотую середину, попытавшись с одной стороны объяснить, что же все-таки происходит при той или иной настройке, но и не вдаваясь особо в теорию, чтобы не усыпить читателя.

              Поехали.


                Лабораторная работа CCNA R&S #17

                Лабораторная работа из трэка подготовки CCNA 2.0 (Routing and Switching). Одна из новых тем – VPN. На наш взгляд, отсутствие любых вариантов VPN в базовом курсе CCNA значительно усложняло работу специалистов в реальных Enterprise сетях, так как практически все современные сети содержат подключение удаленных точек в виде VPN. И Cisco услышала голоса миллионов пользователей, поэтому VPN в курсе CCNA появились. Ура! Их настройкой ты и займешься в данной лабораторной работе. В частности, ты будешь настраивать GRE туннель (один из вариантов организации VPN). Но просто настройка GRE – это только пол дела в рамках данной лабораторной работы. Плюс к этому, ты еще будешь настраивать протокол динамической маршрутизации OSPF в варианте multi-area OSPF для работы через VPN. Давай становиться еще более продвинутым специалистом.

                Схема, задания и ответы…


                  Про виртуальные сети (часть 15). IP SLA в виртуальных сетях.

                  Если заглянуть на сайт cisco.com, то там можно найти документ, в котором есть следующее описание (прошу меня извинить за мой перевод, сделанный по японской технологии касавато):

                  IP SLA собирает информацию о производительности сети в реальном времени: время ответа, задержки, потери пакетов, измерение качества передачи голоса и пр. Пользователь имеет возможность надежно и предсказуемо производить измерения сетевой производительности продолжительное время, а также активно контролировать доступность сети. Cisco IOS IP SLA позволяет автоматизировать наблюдение за сетью, обеспечить гарантированный уровень обслуживания, активно контролировать сетевые операции и точно измерять сетевую производительность. Система активного мониторинга продолжительное время измеряет производительность сети по многочисленным маршрутам, непрерывно обеспечивая основную информацию о производительности.
                  Сетевой администратор может также использовать Cisco IOS IP SLA как инструмент для поиска неисправности. Он может получать статистику производительности от узла к узлу, между двумя маршрутизаторами Cisco или между маршрутизатором и сервером. Если сетевая производительности резко падает в процессе работы (перегрузка сети), сетевой администратор может точно определить узкое место и решить проблему. Cisco IOS IP SLA может также оценить уровень качества обслуживания для вновь внедряемого сервиса. Например, Cisco IOS IP SLA может определить, способна ли сеть обеспечить передачу голоса, смоделировав нагрузку и произведя измерение сетевой производительности для VoIP.


                    Про IPSec VPN между Cisco и D-link

                    Конечно же, мы очень любим активное сетевое оборудование Cisco Systems. И как показывает практика, любим не только за то, что это круто, а любим за понятность настройки, предсказуемость работы сконфигурированных фишек, прекрасные возможности траблшутинга. Однако, часто и мне, и тебе приходиться иметь дело с целым зоопарком оборудования других производителей. Причем не просто иметь дело, а соединять их друг с другом, с оборудованием Cisco для выполнения различных функций. Недавно нам пришлось собирать IPSec VPN между маршрутизаторами D-link DSR-1000, DSR-500, DSR-250 и маршрутизатором Cisco ASR 1002. Не будем вдаваться в причины, почему так получилось, остановимся лишь на технической стороне вопроса. Итак, задача: обеспечить работу WAN сети компании через 3G сеть оператора связи, причем трафик должен передаваться между всеми сайтами в зашифрованном (на сколько это возможно) виде. Вот как мы решили это задачу…


                      Hide me
                      Получать регулярно свежие материалы, лабораторные и вебинары
                      Email Имя
                      Show me