Телефон +7 (812) 718-6184
СПб, Московский пр. 118
  1. О центре
  2. Статьи преподавателей
  3. Объединение сетей. Часть 1

Объединение сетей. Часть 1

05.10.2015

Введение

            Давайте пообщаемся на тему построения корпоративных сетей. И для начала ограничим круг вопросов, поскольку сюда можно отнести и структурированные кабельные системы и задачи выбора оборудования и еще очень многое. Ограничимся вопросом, который стар, как мир :) и вместе с тем актуален и по сей день. Это вопрос построения географически распределенной сети предприятия. Таким образом мы выделим за скобки вопросы связанные с так называемыми локальными сетями.
            Хотелось бы начать, как говорится с нуля, чтобы почувствовать задачу, а потом уже бросаться ее решать, чтобы не вышло, как в анекдоте, где после суток жестокого противостояния змей-горыныч спрашивает у Ивана, чего тот хотел-то, а в ответ — воды попить. Ну так и попил бы. :)

Постановка задачи

            Итак наше вводное: Мы уже строим локальные сети. Решили все вопросы, начиная от выбора топологии и заканчивая адресами устройств и форматами кадров. Прошли эволюцию от общей шины до коммутаторов с VLANами и прочими STP. И теперь появилась необходимость связать несколько локальных сетей. Задача абсолютно типична и широко распространена на сегодняшний день. Практически любой бизнес имеет несколько географических точек присутствия. Здесь у нас связь между филиалами и центральным офисом, удаленными сотрудниками, компаниями партнерами и многое другое. Несмотря на то, что большая часть бизнеса сегодня ориентируется на облачные решения, никуда не исчезают рабочие места сотрудников в офисах, на промплощадках и.т.д. Поэтому вопрос создания безопасных соединений между удаленными точками будет актуален еще очень долгое время. А для некоторых сфер деятельности, так вообще всегда. В чем же здесь основные вопросы? Что нужно для соединения удаленных точек?
            Наличие физического соединения. Или наличие среды передачи между точками. Понятно, что своими силами организация не будет прокладывать кабель между филиалами. Значит арендовать. Например телефонные линии. Лет 15 назад довольно популярное решение. Ассортимента то особо не было. На обоих точках ставили по модему, звонили с одного на другой и после установки звонка вуаля, можно гонять трафик.
            Конечно, все не совсем так просто. Получив физическое соединение необходимо пристроить логику. В локальных сетях у нас своя топология, много узлов, разделяемые линии связи, откуда и система адресации, и метод захвата среды или коммутация. Здесь же у нас цифра в аналог и наоборот с помощью модемов, соединение точка точка и идентификация противоположной стороны возможна локальная, то есть пир такой-то это мой com port такой-то и захват среды отсутствует. Появляются совсем другие протоколы, тип SLIP, PPP. Как вы понимаете это классика понимания базовых сетевых технологий. На выходе различные сетевые технологии, LAN и WAN со своими физическим и канальным уровнем. Естественно решение с модемами грустное по скорости и по цене. Да и о масштабируемости говорить не приходится. Естественно вопросы безопасности необходимо решать отдельно. Далее многие операторы начали предлагать свои услуги. Можно было арендовать выделенные линии, скорость выше, но и цена вопроса не радует. Появляются различные решения в стиле аренды цифровых каналов, типа T1, E1... или дробных вариантов, разные варианты ISDN, Frame Relay, ATM, которые даже гарантируют качество услуг, но к сожалению вопрос цены и присутствия технологии в нужной точке остается открытым и не всегда решаемым. Ну и задачи объединения сетевых технологий, выбора маршрутов, обеспечения безопасности по прежнему решаем мы.
            Огромное облегчение приносит распространение сети Internet. Это как раз и есть отражение того, что мы только что рассмотрели. Нагромождение различных сетевых технологий LAN, WAN связанных воедино, с помощью сетевого уровня (IP), да еще и с определенной степенью отказоустойчивости. Казалось бы, вот оно решение всех вопросов. Узлы идентифицируются некими глобальными адресами, уникальными во всей составной сети. Сама концепция стека TCP/IP предлагает возможность взаимодействия между любыми двумя узлами в Internet. Но это так же предполагает возможность такого взаимодействия не только между узлами нашей организации, но и любыми узлами! Безопасность коммуникаций в этом случае многократно хуже, чем в том же Frame Relay или выделенных линиях. А тут еще оказалось, что адресов не хватает. Придумали технологию NAT и совсем все интересно стало. Вроде адрес у узла есть, но какой-то он не такой, не настоящий. И модель беспрепятственного общения между любыми узлами сразу рушится. Так могут общаться только узлы с реальными (публичными) адресами. Вот тут и подведем черту. Что нам интересно. На сегодня подключение к интернету есть чуть ли не повсеместно. А это автоматически означает наличие физической связи между любыми узлами (помним про публичные адреса). Плата за услуги сети интернет невысока относительно, рассмотренных выше решений. И теперь ставим задачу организации связи между нашими узлами, да так, чтобы решение было:

  • позволяющим общаться узлам с серыми адресами
  • безопасным
  • масштабируемым
  • стандартизированным
  • легким в реализации

Можно добавить еще много пунктов, но и те, что есть уже находятся не в согласии друг с другом.

Решение

            Вот мы и подошли к идее создания неких виртуальных частных сетей VPN поверх существующей, недорогой и небезопасной сети Internet. Исходя из условий понятно, что с наскока такую задачу не решить. Слишком много условий. Ясно, что в начальный момент, при отсутствии стандартов в этой области развили огромный зоопарк несовместимых решений. И несмотря на то, что сегодня многие решения стандартизованы, это совсем не означает совместимости между различными вендорами. И очень часто можно видеть в сети вопросы типа, а как подружить бульдога с носорогом. И если в плане коммутации и маршрутизации большинство детских болезней уже победили и оборудование многих вендоров без проблем трудится совместно, то в области VPN решений еще не все так гладко. Но давайте обо всем по порядку.
            Решим первую проблему, общение хостов с серыми адресами. В чем собственно сама проблема? Хост с таким адресом может легко обратиться к хосту с реальным IP, при этом NAT роутер заменит серый адрес на свой публичный и создаст запись о таком преобразовании. Реальный хост в интернете ответит на публичный адрес NAT роутера, а тот в свою очередь передаст пакет узлу с серым адресом в соответствии с созданной ранее записью. Если же записи нет, то невозможно обратиться к хосту с серым адресом по публичному адресу роутера. А обратьться напрямую на серый адрес невозможно в принципе, ибо такие адреса не маршрутизируются в интернете. Как вариант нужен некий узел посредник в сети интернет с адресом известным обоим сторонам. Через этот узел мы и будем пробивать “дырки” в NAT роутерах. И таких вариантов великое множество, начиная от служб коротких сообщений и заканчивая системами видеонаблюдения. Кстати с развитием облаков, такая опция становится очень популярной. Ресурсов от такого прокси много не требуется, разворачивается решение очень быстро. Но удобно это для единичных сервисов, а не для организации составной сети предприятия. Остается вариант с туннелированием. Подход так же довольно распространенный. Если, что-то в данной среде невозможно или запрещено, то это, что-то можно упаковать в то, что разрешено и законно передать. Гусеничный трактор может ездить по полям, но ему запрещено ездить по асфальту. А если с одного поля на другое есть только шоссе, то трактор можно поставить на трейлер и перевезти. Вот такое туннелирование. Анология очевидна. Серые адреса запрещены в интернете, поэтому пакет от одного серого IP к другому упаковать в пакет от реального IP одного роутера к реальному IP другого. На рисунке ниже, у роутера R3 должна быть директива “пакеты в сеть 172.16.0.0/24 упаковывать в IP пакет от 192.1.1.2 к 203.7.7.4. А получившийся в результате этого пакет маршрутизировать, как обычно по своей таблице маршрутизации. Заметьте, что это еще не решение проблемы прохода через NAT. Как раз наоборот. Мы пытаемся обойти NAT и использовать обычную маршрутизацию законных пакетов, в которых будут находиться “не совсем законные”. Напомню, если NAT работает в режиме PAT, то он привязывается еще и к портам, которых у IP просто нет. Поэтому NAT мы обходим. Натирование в интернет будет работать. А пакеты в удаленную сеть предприятия мы отправляем через туннельный интерфейс, который в NAT конфигурации не участвует. Мы привыкли, что маршрут в таблице явно указывает на интерфейс, через который отправлять пакет, а тут указан пакет в который упаковать исходный.

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

 
Очевидные минусы такой реализации:
  1. Отсутствие аутентификации. Кто угодно может инкапсулировать пакеты таким же образом. Для этого достаточно знать схемы адресации внутренних сетей. Однако обратные пакеты будут маршрутизироваться не назад к злоумышленнику, а на законный роутер. То есть не все так просто. Нужно еще хитро заспуфить адрес роутера отправителя. Но все равно в целом некрасиво. Зачем нам в сети нежелательные пакеты?
  2. Данные передаются по публичной сети и никак не защищены от просмотра и изменения. А вот тут уже серьезный минус. Мало какой организации подойдет такой вариант пересылки данных. А если организация оперирует личными данными пользователей, то она еще и нарушает закон.
  3. Масштабируемость здесь отсутствует. При создании множества соединений все необходимо делать вручную. Нужно дополнять решение протоколами динамической маршрутизации и определиться, что делать с динамическими публичными IP адресами.
В плане стандартизации здесь все отлично. Никаких нестандартных протоколов не используется. Ну и легкость реализации на высоте. Туннели такого типа поддерживались в Windows 2000 Server и доступны для настройки на оборудовании CISCO.
Пример основных настроек для роутера с одной стороны туннеля приведен ниже. Вторая сторона настраивается аналогично. Меняется местами начало и конец туннеля и естественно маршруты, в соответствующие сети.
interface Tunnel0
 ip address 192.168.0.1 255.255.255.0
 tunnel source FastEthernet0/0
 tunnel destination 203.7.7.4
 tunnel mode ipip
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
interface FastEthernet0/0
 ip address 192.1.1.2 255.255.255.0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip route 0.0.0.0 0.0.0.0 192.1.1.1
ip route 172.16.0.0 255.255.255.0 Tunnel0
ip route 172.16.0.0 255.255.255.0 192.168.0.2

Естественно такое решение неактуально сегодня по описанным выше соображениям. Актуальные варианты рассматриваются в курсе безопасности SIMOS от компании CISCO. В курсе разбираются варианты построения различных VPN сетей с использованием CISCO IOS оборудования и CISCO ASA устройств. В следующих частях мы рассмотрим как же решать вопросы с конфиденциальностью передаваемых данных, аутентификацией узлов и масштабируемостью решений. А пока можете реализовать такой вариант на реальном оборудовании или на эмуляторах. 

Олег Годунов, инструктор УЦ ЭВРИКА