Сети для самых маленьких часть 7

ИТ База знаний

Полезно

— Узнать IP – адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP – АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Настройка Site-To-Site IPSec VPN на Cisco

Настройка Router-on-a-Stick на Cisco

Настройка VLAN на Cisco – кейсы и история

Автоматический backup на Cisco ASA

Настройка NAT на Cisco

Grandstream GXP1782

Настройка GRE туннеля на Cisco

Всем привет! Сегодня в статье мы расскажем про настройку Point-to-Point GRE VPN туннелей на оборудовании Cisco и о том, как сделать их защищенными при помощи IPsec. Generic Routing Encapsulation (GRE) – это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня в point-to-point каналах.

Туннель GRE используется, когда пакеты должны быть отправлены из одной сети в другую через Интернет или незащищенную сеть. В GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), а пакеты отправляются через туннель GRE.

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

На приведенной ниже схеме показана процедура инкапсуляции простого незащищенного пакета GRE, проходящего через маршрутизатор и входящего в туннельный интерфейс:

Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN-соединение IPSec между сайтами, это не так. Основное отличие состоит в том, что туннели GRE позволяют multicast пакетам проходить через туннель, тогда как IPSec VPN не поддерживает multicast пакеты.

В больших сетях, где необходимы протоколы маршрутизации, такие как OSPF, EIGRP, туннели GRE – ваш лучший выбор. По этой причине, а также из-за того, что туннели GRE гораздо проще в настройке, инженеры предпочитают использовать GRE, а не IPSec VPN.

В этой статье объясняется, как создавать простые незащищенные (unprotected) и безопасные (IPSec encrypted) туннели GRE между конечными точками. Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями.

Создание Cisco GRE туннеля

Туннель GRE использует интерфейс «туннель» – логический интерфейс, настроенный на маршрутизаторе с IP-адресом, где пакеты инкапсулируются и декапсулируются при входе или выходе из туннеля GRE.

Первым шагом является создание нашего туннельного интерфейса на R1:

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

В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24.

Поскольку GRE является протоколом инкапсуляции, мы устанавливаем максимальную единицу передачи (MTU – Maximum Transfer Unit) до 1400 байт, а максимальный размер сегмента (MSS – Maximum Segment Size) – до 1360 байт. Поскольку большинство транспортных MTU имеют размер 1500 байт и у нас есть дополнительные издержки из-за GRE, мы должны уменьшить MTU для учета дополнительных служебных данных. Установка 1400 является обычной практикой и гарантирует, что ненужная фрагментация пакетов будет сведена к минимуму.

В заключение мы определяем туннельный источник, который является публичным IP-адресом R1, и пункт назначения – публичный IP-адрес R2.

Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии:

Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце.

Далее мы должны создать интерфейс Tunnel 0 на R2:

Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает:

Маршрутизация сетей через туннель GRE

На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это:

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

На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.

Та же конфигурация должна быть повторена для R2:

Теперь обе сети могут свободно общаться друг с другом через туннель GRE.

Защита туннеля GRE с помощью IPSec

Как упоминалось ранее, GRE является протоколом инкапсуляции и не выполняет шифрование. Создание туннеля GRE точка-точка без какого-либо шифрования чрезвычайно рискованно, поскольку конфиденциальные данные могут быть легко извлечены из туннеля и просмотрены другими.

Для этого мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и спокойствие. Наш пример ниже охватывает режим туннеля GRE IPSec.

Настройка шифрования IPSec для туннеля GRE (GRE over IPSec)

Шифрование IPSec включает в себя два этапа для каждого маршрутизатора. Эти шаги:

Настройка ISAKMP (ISAKMP Phase 1)
Настройка IPSec (ISAKMP Phase 2)

Настройка ISAKMP (ISAKMP Phase 1)

IKE существует только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с партнером.

Для начала, мы начнем работать над R1.

Первым шагом является настройка политики ISAKMP Phase 1:

Приведенные выше команды определяют следующее (в указанном порядке):

3DES – метод шифрования, который будет использоваться на этапе 1 Phase 1
MD5 – алгоритм хеширования
Authentication pre-share – использование предварительного общего ключа в качестве метода проверки подлинности
Group 2 – группа Диффи-Хеллмана, которая будет использоваться
86400 – время жизни ключа сеанса. Выражается в килобайтах или в секундах. Значение установлено по умолчанию.

Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10:

PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).

Создание IPSec Transform (ISAKMP Phase 2 policy)

Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS:

Вышеуказанные команды определяют следующее:

SP-3DES – метод шифрования
MD5 – алгоритм хеширования
Установите IPSec в транспортный режим.

Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre:

Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля:

Ну и наконец пришло время применить ту же конфигурацию на R2:

Проверка GRE over IPSec туннеля

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

Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу:

Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

😪 Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

😍 Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Сети для самых матёрых. Часть двенадцатая. MPLS L2VPN

L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола – IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.
Вот и нашим клиентам вынь да положь L2.

Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно). Однако в наш век конвергентных сетей, распределённых ЦОДов и международных компаний это не выход, и на рынок выплеснулось некоторое количество масштабируемых технологий випиэнирования на канальном уровне.
Мы же в этот раз сосредоточимся на MPLS L2VPN.

Технологии L2VPN

Прежде чем погрузиться в тёплый MPLS, взглянем на то, какие вообще виды L2VPN существуют.

VLAN/QinQ – их можно сюда отнести, поскольку основные требования VPN выполняются – организуется виртуальная L2 сеть между несколькими точками, данные в которой изолированы от других. По сути VLAN per-user организует Hub-n-Spoke VPN.
L2TPv2/PPTP – устаревшие и скучные вещи.
L2TPv3 вместе с GRE имеют проблемы с масштабированием.
VXLAN, EVPN – варианты для ЦОД”ов. Очень интересно, но DCI не входит в планы этого выпуска. Зато о них был отдельный подкаст (слушайте запись 25-го ноября)
MPLS L2VPN – это набор различных технологий, транспортом для которых выступает MPLS LSP. Именно он сейчас получил наиболее широкое распространение в сетях провайдеров.

Читать еще: Программы удаленного администрирования по локальной сети

Почему он победитель? Главная причина, безусловно, в способности маршрутизаторов, передающих MPLS-пакеты абстрагироваться от их содержимого, но при этом различать трафик разных сервисов.
Например, Е1-кадр приходит на PE, сразу же инкапсулируется в MPLS и уже никто по пути даже не заподозрит, что там внутри – важно только вовремя поменять метку.
А на другой порт приходит Ethernet-кадр и по тому же самому LSP он может пройти по сети, только с другой меткой VPN.
А кроме того MPLS TE позволяет строить каналы с учётом требований трафика к параметрам сети.
В связке же с LDP и BGP становится более просто настраивать VPN и автоматически находить соседей.
Возможность инкапсулировать трафик любого канального уровня в MPLS называется AToM – Any Transport over MPLS.
Вот список поддерживаемых AToM протоколов:

ATM Adaptation Layer Type-5 (AAL5) over MPLS
ATM Cell Relay over MPLS
Ethernet over MPLS
Frame Relay over MPLS
PPP over MPLS
High-Level Data Link Control (HDLC) over MPLS

Два мира L2VPN

Для построения любого L2VPN существуют два концептуально разных подхода.

Point-to-Point. Применим к любым типам протоколов канального уровня и в принципе, в полной мере исчерпывает все сценарии применения L2VPN. Поддерживает все мыслимые и немыслимые протоколы. Причём некоторые из них ещё и по-разному может реализовывать.
В основе лежит концепция PW – PseudoWire – псевдопровод.
Вы хотите соединить два узла друг с другом. Тогда сеть провайдера для вас будет как один виртуальный кабель – то, что вошло в него на одном конце обязательно выйдет на другом без изменений.
Общее название услуги: VPWS – Virtual Private Wire Service.
Point-to-Multipoint. Этот режим только для Ethernet, поскольку только в нём фактически такая необходимость есть. В этом случае у клиента может быть три-пять-десять-сто точек подключения/филиалов, и все они должны передавать данные друг другу, причём, как одному конкретному филиалу, так и всем сразу. Это до боли напоминает обычный Ethernet-коммутатор, но было бы страшной банальностью об этом говорить.
Название технологии: VPLS – Virtual Private LAN Service.

Терминология

Традиционно термины будут вводиться по мере необходимости. Но о некоторых сразу.
PE – Provider Edge – граничные маршрутизаторы MPLS-сети провайдера, к которым подключаются клиентские устройства (CE).
CE – Customer Edge – оборудование клиента, непосредственно подключающееся к маршрутизаторам провайдера (PE).
AC – Attached Circuit – интерфейс на PE для подключения клиента.
VC – Virtual Circuit – виртуальное однонаправленное соединение через общую сеть, имитирующее оригинальную среду для клиента. Соединяет между собой AC-интерфейсы разных PE. Вместе они составляют цельный канал: AC→VC→AC.
PW – PseudoWire – виртуальный двунаправленный канал передачи данных между двумя PE – состоит из пары однонаправленных VC. В этом и есть отличие PW от VC.

VPWS. Точка-точка

VPWS – Virtual Private Wire Service.
В основе любого решения MPLS L2VPN лежит идея PW – PseudoWire – виртуальный кабель, прокинутый из одного конца сети в другой. Но для VPWS сам этот PW и является уже сервисом.
Эдакий L2-туннель, по которому можно беззаботно передавать всё, что угодно.
Ну, например, у клиента в Котельниках находится 2G-базовая станция, а контроллер – в Митино. И эта БС может подключаться только по Е1. В стародавние времена пришлось бы протянуть этот Е1 с помощью кабеля, радиорелеек и всяких конвертеров.
Сегодня же одна общая MPLS-сеть может использоваться, как для этого Е1, так и для L3VPN, Интернета, телефонии, телевидения итд.
(Кто-то скажет, что вместо MPLS для PW можно использовать L2TPv3, но кому он нужен с его масштабируемостью и отсутствием Traffic Engineering”а?)

VPWS сравнительно прост, как в части передачи трафика, так и работы служебных протоколов.

VPWS Data Plane или передача пользовательского трафика

Туннельная метка – то же, что и транспортная, просто длинное слово “транспортное” не помещалось в заголовок.

0. Между R1 и R6 уже построен транспортный LSP с помощью протокола LDP или RSVP TE. То есть R1 известна транспортная метка и выходной интерфейс к R6.
1. R1 получает от клиента CE1 некий L2 кадр на AC интерфейс (то может оказаться Ethernet, TDM, ATM итд. – не имеет значения).
2. Этот интерфейс привязан к определённому идентификатору клиента – VC ID – в некотором смысле аналогу VRF в L3VPN. R1 даёт кадру сервисную метку, которая сохранится до конца пути неизменной. VPN-метка является внутренней в стеке.
3. R1 знает точку назначения – IP-адрес удалённого PE-маршрутизатора – R6, выясняет транспортную метку и вставляет её в стек меток MPLS. Это будет внешняя – транспортная метка.
4. Пакет MPLS путешествует по сети оператора через P-маршрутизаторы. Транспортная метка меняется на новую на каждом узле, сервисная остаётся без изменений.
5. На предпоследнем маршрутизаторе снимается транспортная метка – происходит PHP. На R6 пакет приходит с одной сервисной VPN-меткой.
6. PE2, получив пакет, анализирует сервисную метку и определяет, в какой интерфейс нужно передать распакованный кадр.

Если вы читали предыдущий выпуск про L3VPN, то в вопросе передачи пользовательского трафика не увидите ничего нового – пара MPLS-меток и передача по транспортному LSP. Ingress PE проверяет какие метки поставить и в какой интерфейс отправить, P меняет транспортную метку, а Egress PE по метке VPN принимает решение, в какой AC-интерфейс передать полученный кадр.

VPWS Control Plane или работа служебных протоколов

Транспортная метка может назначаться как LDP (см. выпуск про MPLS), так и RSVP-TE (ещё ждёт своего часа).
Для примера, возьмём LDP – по всей сети запускается этот протокол, который для каждого Loopback-адреса каждого MPLS-маршрутизатора распространит по сети метки.
В нашем случае R1 после работы LDP будет, грубо говоря, знать 5 меток: как добраться до каждого из оставшихся маршрутизаторов.
Нас интересует LSP R1→R6 и обратно. Заметьте, что для того, чтобы VC перешёл в состояние UP, должны быть оба LSP – прямой и обратный.

Существует несколько разных способов реализации услуги VPWS. Об этом мы поговорим чуть ниже, а для примера разберём ту, которая наиболее часто сейчас используется.

За распространение сервисных меток отвечает тот же LDP, только генно-модифицированный – Targeted LDP. Теперь он может устанавливать соединение с удалёнными маршрутизаторами и обмениваться с ними метками.
В нашем примере к R1 и R6 подключены клиенты. R1 через LDP сообщит свою метку для этого клиента R6 и наоборот.

На обоих концах вручную мы настраиваем удалённую LDP-сессию. Она никак не привязана к VPN. То есть одна и та же сессия может использоваться для обмена метками любым количеством VPN.
Обычный LDP – это link-local протокол и ищет соседей среди непосредственно подключенных маршрутизаторов, то есть TTL его пакетов – 1. Однако tLDP достаточна IP-связность.

Как только с обеих сторон появятся AC-интерфейсы с одинаковым VC-ID, LDP поможет им сообщить друг другу метки.

Сети для самых маленьких. Часть ой, всё

Дорогие мои друзья, отважные критики, тихие читатели и тайные почитатели, СДСМ заканчивается.

Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

Правильно было бы остановиться на BGP, но в MPLS въехать на IP не очень получается — пришлось его захватить. Возможно, стоило бы не браться за Traffic Engineering, но коли уж взялся за L2VPN, как остановиться? Аппаратная архитектура — неотъемлемое предисловие к QoS. А QoS настолько долго требовали, что про него нельзя было не написать. Ровным счётом не от чего избавиться.
Последней статьёй планировалась некая коллекция лучших практик (предлагайте приятно звучащий синоним — и я заменю эту кальку) по дизайну провайдинговых сетей, но со временем и опытом стало понятно, что это не только необъятный пласт подходов, но и прекрасная почва для словесных перепалок. Да и почему нужно остановиться на провайдерах? А операторы связи? А ЦОДы? А сети предприятий?

Читать еще: Что значит оперативная память в телефоне?

Нельзя сказать: делайте так и это правильно. Нельзя научить инженера разрабатывать дизайн — он должен вырасти до этого сам, пробравшись через свои терновые кусты.

Это именно то, что предлагает СДСМ — едва заметная тропка от простого к сложному.

Куча народу приложило кто руку, кто голову к написанию этих статей:

Макс aka gluck — соавтор первых статей и автор 4-й части про STP и раздела IP SLA в 8-й. По совместительству более 5 лет — админ проекта.
Наташа Самойленко — дополнительные материалы, задачи и их решения ко многим выпускам. А так же поддержка, которую нельзя переоценить
Дмитрий aka JDima — критик и корректор.
Алекс Клиппер — критик и корректор.
Дмитрий Фиголь — критик и корректор.
Марат Бабаян aka botmoglotx — автор выпусков про EVPN и фотографий для выпуска 14.
Андрей Глазков aka glazgoo — критик и корректор.
Александр Клименко aka volk — критик и корректор.
Александр Фатин — критик и корректор.
Алексей Кротов — критик и корректор.
Команда linkmeup — вычитка материалов.
Антон Клочков — организатор. Благодаря нему у проекта есть лабораторная среда, сервер вещания, а теперь и свой хостинг подкастов.
Антон Автушко — разработчик сайта, который верой и правдой служит уже 6 лет. Ливстрит давно почил, ни один плагин больше не поддерживается, а сайт ещё живёт. И за lookmeup.linkmeup.ru, мертворождённый, но с хорошей идеей.
Тимофей Кулин — админ и разработчик сайта.
Никита Асташенко — разработчик сайта.
Нина Долгополова — художник-иллюстратор. Лого и иллюстрации к 9-му и 10-му выпускам.
Павел Силкин — художник-иллюстратор (0-й и 1-й выпуск).
Анастасия Мецлер — художник-иллюстратор (11-й выпуск).
Дарья Корманова — художник-иллюстратор (12-й выпуск).
Артём Чернобай — художник-иллюстратор (13-й, 14-й и 15-й выпуски и эта заключительная статья).

Статья про QoS стала последней в цикле. К моменту её завершения стало очевидно, насколько простецки и неполно написаны первые выпуски. Да что там первые?! Вплоть до BGP всё очень плохо.

Кроме того, читатели часто сами находят ошибки и предлагают исправления.

Идея перенести всё это на gitbook, привнесённая Наташей Самойленко выглядела настолько привлекательной, что мы это сделали:

Сегодня там большая часть статей в актуальном виде.

Любой желающий может форкнуть проект, внести изменения и сделать Pull Request в master. После того, как я его подтвержу, изменения появятся в gitbook’е.

Инструкция для молодых контрибьютеров с горящими глазами.

Пока я считаю, что бумажной книге по СДСМ не быть. Пока я не готов посвятить время переписыванию первых статей, чтобы получился законченный, красивый и, главное, всеобъемлющий материал про сети. Всё же в этой жизни много интересных вещей, а с перфекционизмом я как-нибудь справлюсь.

Не самым последним фактором завершения цикла и смещения интересов является смена места работы.

И короткий анонс: наши руки не для скуки, а для графомании. Ждите новую серию статей. Про автоматизацию.

Сети для самых маленьких. Часть нулевая. Планирование

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN’ы, настройка оборудования.

В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.

Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Следует несколько конкретизировать ситуацию.

1 В данный момент у компании есть два офиса: 200 квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.

2 Есть четыре группы пользователей: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера (С), которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.

3 Пользователи групп С, Б и ФЭО будут только в офисе на Арбате, ПТО и Д будут в обоих офисах.

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

При проектировании сети следует стараться придерживаться иерархической модели сети, которая имеет много достоинств по сравнению с “плоской сетью”:

• упрощается понимание организации сети

• модель подразумевает модульность, что означает простоту наращивания мощностей именно там, где необходимо

• легче найти и изолировать проблему

• повышенная отказоустойчивость засчет дублирования устройств и/или соединений

• распределение функций по обеспечению работоспособности сети по различным устройствам.

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение — быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: как правило, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

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

Составим приблизительную схему:

На представленной схеме ядром (Core) будет маршрутизатор 2811, коммутатор 2960 отнесём к уровню распространения (Distribution), поскольку на нём агрегируются все VLAN в общий транк. Коммутаторы 2950 будут устройствами доступа (Access). К ним будут подключаться конечные пользователи, офисная техника, сервера.

Именовать устройства будем следующим образом: сокращённое название города (msk) — географическое расположение (улица, здание) (arbat) — роль устройства в сети + порядковый номер.

Соответственно их ролям и месту расположения выбираем hostname:

Маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз)

Коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch)

Коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch)

Вся сеть должна быть строго документирована: от принципиальной схемы, до имени интерфейса.

Прежде, чем приступить к настройке, я бы хотел привести список необходимых документов и действий:

• Схемы сети L1, L2, L3 в соответствии с уровнями модели OSI (Физический, канальный, сетевой)

• План IP-адресации = IP-план.

• Подписи (description) интерфейсов

• Список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAMNVRAM, список интерфейсов)

• Метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах

• Единый регламент, определяющий все вышеприведённые параметры и другие.

Жирным выделено то, за чем мы будем следить в рамках программы-симулятора. Разумеется, все изменения сети нужно вносить в документацию и конфигурацию, чтобы они были в актуальном состоянии.

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

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

Сети для самых маленьких. Часть 0. Планирование

Это первая статья из серии «Сети для самых маленьких». Мы с Максимом aka Gluck долго думали с чего начать: маршрутизация, VLAN’ы, настройка оборудования. В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум, читали о эталонной модели OSI, о стеке протоколов TCP/IP, знаете о типах существующих VLAN’ов, о наиболее популярном сейчас port-based VLAN и о IP адресах. Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.

Читать еще: Построение сети предприятия с нуля

Эскиз сети

Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак, у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование, и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Следует несколько конкретизировать ситуацию:

В данный момент у компании есть два офиса: 200 квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.
Есть четыре группы пользователей: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера (С), которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.
Пользователи групп С, Б и ФЭО будут только в офисе на Арбате, ПТО и Д будут в обоих офисах.

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

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

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение — быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: как правило, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

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

Составим приблизительную схему:

Приблизительная схема сети

Именовать устройства будем следующим образом: сокращённое название города (msk) — географическое расположение (улица, здание) (arbat) — роль устройства в сети + порядковый номер.

Соответственно их ролям и месту расположения выбираем hostname:

маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз);
коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch);
коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch).

Документация сети

Вся сеть должна быть строго документирована: от принципиальной схемы, до имени интерфейса.

Прежде, чем приступить к настройке, я бы хотел привести список необходимых документов и действий:

схемы сети L1, L2, L3 в соответствии с уровнями модели OSI (физический, канальный, сетевой);
план IP-адресации = IP-план;
список VLAN;
подписи (description) интерфейсов;
список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAMNVRAM, список интерфейсов);
метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах;
единый регламент, определяющий все вышеприведённые параметры и другие.

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

Маркировка кабелей и устройств

Маркировка кабелей заземления

Подготовим нужные нам документы:

Список VLAN

Каждая группа будет выделена в отдельный влан. Таким образом мы ограничим широковещательные домены. Также введём специальный VLAN для управления устройствами. Номера VLAN c 4 по 100 зарезервированы для будущих нужд.

АйТи бубен

Инструменты пользователя

Инструменты сайта

Боковая панель

Содержание

IPSec Tools Racoon

IPsec-Tools это порт c FreeBSD использует утилиты setkey, racoon.

IPSec (сокращение от спецификации IP Security) – надстройка к протоколу IP, обеспечивающая безопасность протоколов более высокого уровня. IPSec был разработан для IPv6 протокола, а позже портирован на IPv4 протокол. IPSec шифрует IP-пакеты, ему безразличны интерфейсы (например gif) на шифрование которых он настроен вообще. IPSec обеспечивает IP-сжатие(IP Compression, IPcomp) пакетов перед их шифрованием. Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Другие защищённые протоколы, такие как SSL сертификаты для для сайта, почты и TLS, работают на транспортном уровне (уровни OSI 4 — 7).

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

Режимы работы IPsec(транспортный, туннельный)

Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения “виртуальных туннелей” между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, Что это такое VPN).

В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE туннели и др.).

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

Security Associations (SA). Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association, позволяет задать например mode transport | tunnel | ro | in_trigger | beet – режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

Security Policy (SP) – политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.

IPSec (сеть-сеть) между серверами FreeBSD

Теперь ping должны ходить между сетями.

если команда ничего не вывела, значит нужно пересобрать ядра на обоих маршрутизаторах с параметрами

Создаем SSL сертификаты на каждом хосте. Копируем с одной на другую файлики *.public. В принципе, имена ключей неважны, можно называть и по IP, с соответствующими расширениями.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

Настройка на шлюзе #2 аналогична только меняются IP местами.

Настройка утилиты racoon

Cмотрим логи /var/log/security и /var/log/messages.

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

на любом из хостов для просмотра информации о параметрах безопасности.

голоса

Рейтинг статьи