Материал просмотрен 38,772 раз(а)
С чем обязательно придётся столкнуться при сопряжении разных подсетей – это маршрутизация. Ох, сколько раз я задумчиво чесал затылок не понимая, почему узел назначения оставался недоступным. Ну чтож, попробуем это чётко спланировать, чтобы не ошибиться.
Я немного перерисовал исходную схему, чтобы было понятно, как будет проходить маршрутизация и какой интерфейс с каким адресом. Вот план (немного преобразованый):
Подпишу сетевые интерфейсы:
Всё просто. Шлюзы внутри с адресом.1, снаружи – по номеру подсети.10 – 10-ая подсеть, .20 – 20-ая подсеть. А хосты с адресом.2. Думаю, с этим вопросов не возникло. Чтож, проверим маршрутизацию сейчас. Для этого с каждого узла пропингуем все остальные хосты.
Как мы видим, доступность есть только у узлов, непосредственно связанных виртуальным сетевым кабелем. Будем это исправлять!
Маршруты будем добавлять с помощью команды ROUTE командной строки. Что нам нужно добавить? Смотрим в табличку и добавляем те назначения, которые мы НЕ видим. И прописываем тот узел, который является следующим шагом для пакета на этом пути. Вот подробности:
Как добавляются маршруты для рабочих станций? Утилита route
Синтаксис примерно такой:
route add
Покажем на примере. Узел host . Передавать пакеты на узел serv.main.com . Пробуем послать ping, пакеты не доходят. (см. скриншот выше). Почему? Да потому что наш компьютер не знает, куда передавать пакеты в неизвестную подсеть (узел 10.0.0.10). Это не наша подсеть, поэтому теряемся в догадках.
Задача маршрутизации – обеспечить передачу пакетов в другие сети. Если бы у нас был установлен основной шлюз (default gateway), то все пакеты с неизвестным адресом сети назначения передавались бы именно на него “Пусть сами разбираются”, но такой параметр у нас не указан.
Итак, настраиваем узел host.
route add 10.0.0.0 mask 255.0.0.0 192.168.10.1
Все пакеты, адрес назначения которых стоит “подсеть 10.0.0.0/8” будут отправляться на 192.168.10.1. Что происходит при этом на 192.168.10.1? 192.168.10.1 – это узел serv.main.com , который имеет второй сетевой интерфейс 10.0.0.10. Пакеты на этот интерфейс, посланные с host – дойдут без проблем, так как маршрут до узла мы прописали.
Вот такая занимательная маршрутизация. Итак, маршрут до 10.0.0.10 у нас есть. Сделаем аналогичным образом маршруты до подсети 192.168.20.0/24. Всё-всё-всё посылаем на 192.168.10.1 (так как – это наш единственный “выход” с узла host).
Пришла пора настраивать узел serv.main.com , который стал полновесным маршрутизатором.
Идём в управление сервером и смотрим, чтобы была установлена роль “Маршрутизация и удалённый доступ” (Routing and remote access). Если всё ОК, входим в “Администрирование” в эту оснастку.
Или устанавливаем её. Для этого отключаем службу Windows Firewall
После добавления роли “Маршрутизация и удалённый доступ” мы видим следующую оснастку. Открываем конфигурирование.
Начинаем конфигурирование. Настраивать будем всё вручную, чтобы лучше разобраться в маршрутизации.
А в этом окне мастера настройки маршрутизации и удалённого доступа выбираем “маршрутизацию между сетями”. Как раз то, что нужно.
И у нас появилось вот такое дерево в консоли MMC. Интересует нас “статические маршруты”.
И добавим вот такой маршрут. В общем-то это похоже на графическую оболочку утилиты route, поэтому объясню лишь то, что мы сделали. Для сети 192.168.10.0/24 мы указали адрес следующего прыжка 192.168.10.1 для пакетов, пришедших с интерфейса 10.0.0.10 (т.е. те пакеты, которые идут извне к нам, например от узла MAIN.COM или ADMIN.MAIN.COM
Подобную ситуцию сделаем и на MAIN.COM
В общем виде – то же самое. Указываем “ОТКУДА”, “КУДА” и “КУДА ПОСЫЛАТЬ”. На метрику внимания не обращаем, это для приоретизации одних маршрутов перед другими, когда из одной точки можно добраться в другую разными путями.
Маршруты настроили. Простая проверка PING доказывает. Все узлы доступны друг для друга!
Друзья! Вступайте в нашу
Итак, поворотный момент в истории компании "Лифт ми Ап". Руководство понимает, что компания, производящая лифты, едущие только вверх, не выдержит борьбы на высококонкурентном рынке. Необходимо расширять бизнес. Принято решение о покупке двух заводов: в Санкт-Петербурге и Кемерово.
Нужно срочно организовывать связь до новых офисов, а у вас ещё даже локалка не заработала.
Сегодня:
1. Настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing)
2. Пытаемся разобраться с процессами, происходящими в сети, и что творится с данными.
3. Планируем расширение сети (IP-адреса, вланы, таблицы коммутации)
4. Настраиваем статическую маршрутизацию и разбираемся, как она работает.
5. Используем L3-коммутатор в качестве шлюза
В данный момент (вспомним ) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 - можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью
, а операция объединения подсетей в суперсети называется суммированием
подсетей (суммированием маршрутов, если быть точным, route summarization)
Приносим извинения за гигантские простыни, видео тоже с каждым разом становится всё длиннее и невыносимее. Постараемся в следующий раз быть более компактными.
Все заинтересованные, но незарегистрированные приглашаются на беседу в .
За подготовку статьи большое спасибо моему соавтору и моей жене за львиное терпение.
Для очень недовольных: эта статья не абсолют, она не раскрывает теоретические аспекты в полной мере и, потому не претендует на роль полноценной документации. С точки зрения авторов это вспомогательной средство для новичков, волшебный стимул, если желаете. На хабре у вас есть возможность поставить минус, а не доказывать нашу неправоту. Прошу вас, поступите именно так, потому что ваши недовольства встретят лишь вышеприведённые аргументы.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”. Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился.
Итак, поворотный момент в истории компании “Лифт ми Ап”. Руководство понимает, что компания, производящая лифты, едущие только вверх, не выдержит борьбы на высококонкурентном рынке. Необходимо расширять бизнес. Принято решение о покупке двух заводов: в Санкт-Петербурге и Кемерово.
Нужно срочно организовывать связь до новых офисов, а у вас ещё даже локалка не заработала.
Сегодня:
Содержание:
Процесс настройки маршрутизатора очень прост:
0) Сначала закончим с коммутатором msk-arbat-dsw1. На нём нам нужно настроить транковый порт в сторону маршрутизатора, чего мы не сделали в прошлый раз.
Msk-arbat-dsw1(config)#interface FastEthernet0/24
msk-arbat-dsw1(config-if)# description msk-arbat-gw1
msk-arbat-dsw1(config-if)# switchport trunk allowed vlan 2-3,101-104
msk-arbat-dsw1(config-if)# switchport mode trunk
1) Назначаем имя маршрутизатора командой hostname
, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.
Router0#clock set 12:34:56 7 august 2012
Router0# conf t
Router0(config)#hostname msk-arbat-gw1
Желательно время на сетевые устройства раздавать через NTP (любую циску можно сделать NTP-сервером, кстати)
Msk-arbat-gw1(config)#interface fastEthernet 0/0
msk-arbat-gw1(config-if)#no shutdown
3) Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).
Msk-arbat-gw1(config)#interface fa0/0.2
msk-arbat-gw1(config-if)#description Management
Логика тут простая. Сначала указываем обычным образом физический интерфейс, к которому подключена нужная сеть, а после точки ставим некий уникальный идентификатор этого виртуального интерфейса. Для удобства, обычно номер сабинтерфейса делают аналогичным влану, который он терминирует.
4) Теперь вспомним о стандарте 802.1q , который описывает тегирование кадра меткой влана. Следующей командой вы обозначаете, что кадры, исходящие из этого виртуального интерфейса будут помечены тегом 2-го влана. А кадры, входящие на физический интерфейс FastEthernet0/0 с тегом этого влана будут приняты виртуальным интерфейсом FastEthernet0/0.2.
Msk-arbat-gw1(config-if)#encapsulation dot1Q 2
5) Ну и как на обычном физическом L3-интерфейсе, определим IP-адрес. Этот адрес будет шлюзом по умолчанию (default gateway) для всех устройств в этом влане.
Msk-arbat-gw1(config-if)#ip address 172.16.1.1 255.255.255.0
Аналогичным образом настроим, например, 101-й влан:
Msk-arbat-gw1(config)#interface FastEthernet0/0.101
msk-arbat-gw1(config-if)#description PTO
msk-arbat-gw1(config-if)#encapsulation dot1Q 101
msk-arbat-gw1(config-if)#ip address 172.16.3.1 255.255.255.0
и теперь убедимся, что с компьютера из сети ПТО мы видим сеть управления:
Работает и отлично, настройте пока все остальные интерфейсы. Проблем с этим возникнуть не должно.
Все устройства, адреса которых будут находиться в диапазоне 172.16.3.1-172.16.3.254 с такой же маской, как у вас, будут являться членами вашей подсети. Что происходит с данными, если вы отправляете их на устройство с адресом из этого диапазона? Повторим это с некоторыми дополнениями.
Для отправки данных они должны быть упакованы в Ethernet-кадр, в заголовок которого должен быть вставлен MAC-адрес удалённого устройства. Но откуда его взять?
Для этого ваш компьютер рассылает широковещательный ARP-запрос. В качестве IP-адреса узла назначения в IP-пакет с этим запросом будет помещён адрес искомого хоста. Сетевая карта при инкапсуляции указывает MAC-адрес FF:FF:FF:FF:FF:FF - это значит, что кадр предназначен всем устройствам. Далее он уходит на ближайший коммутатор и копии рассылаются на все порты нашего влана (ну, кроме, конечно, порта, из которого получен кадр). Получатели видят, что запрос широковещательный и они могут оказаться искомым хостом, поэтому извлекают данные из кадра. Все те устройства, которые не обладают указанным в ARP-запросе IP-адресом, просто игнорируют запрос, а вот устройство-настоящий получатель ответит на него и вышлет первоначальному отправителю свой MAC-адрес. Отправитель (в данном случае, наш компьютер) помещает полученный MAC в свою таблицу соответствия IP и MAC адресов ака ARP-кэш. Как выглядит ARP-кэш на вашем компьютере прямо сейчас, вы можете посмотреть с помощью команды arp -a
Потом ваши полезные данные упаковываются в IP-пакет, где в качестве получателя ставится тот адрес, который вы указали в команде/приложении, затем в Ethernet-кадр, в заголовок которого помещается полученный ARP-запросом MAC-адрес. Далее кадр отправляется на коммутатор, который, согласно своей таблице MAC-адресов, решает, в какой порт его переправить дальше.
Но что происходит, если вы пытаетесь достучаться до устройства в другом влане? ARP-запрос ничего не вернёт, потому что широковещательные L2 сообщения кончаются на маршрутизаторе(т.е., в пределах широковещательного L2 домена), нужная сеть находится за ним, а коммутатор не пустит кадры из одного влана в порт другого. И вот для этого нужен шлюз по умолчанию (default gateway) на вашем компьютере. То есть, если устройство-получатель в вашей же подсети, кадр просто отправляется в порт с мак-адресом конечного получателя. Если же сообщение адресовано в любую другую подсеть, то кадр отправляется на шлюз по умолчанию, поэтому в качестве MAC-адреса получателя подставится MAC-адрес маршрутизатора.
Проследим за ходом событий.
1) ПК с адресом 172.16.3.2/24 хочет отправить данные компьютеру с адресом 172.16.4.5.
Он видит, что адрес из другой подсети, следовательно, данные должны уйти на шлюз по умолчанию. Но в таком случае, ПК нужен MAC-адрес шлюза. ПК проверяет свой ARP-кэш в поисках соответствия IP-адрес шлюза - MAC-адрес и не находит нужного
2) ПК отправляет широковещательный ARP-запрос в локальную сеть. Структура ARP-запроса:
- на канальном уровне в качестве получателя - широковещательный адрес (FF:FF:FF:FF:FF:FF), в качестве отправителя - MAC-адрес интерфейса устройства, пытающегося выяснить IP
- на сетевом - собственно ARP запрос, в нем содержится информация о том, какой IP и кем ищется. 
3) Коммутатор, на который попал кадр, рассылает его копии во все порты этого влана (того, которому принадлежит изначальный хост), кроме того, откуда он получен.
4) Все устройства, получив этот кадр и, видя, что он широковещательный, предполагают, что он адресован им.
5) Распаковав кадр, все хосты, кроме маршрутизатора, видят, что в ARP-запросе не их адрес. А маршрутизатор посылает unicast’овый ARP-ответ со своим MAC-адресом.
6) Изначальный хост получает ARP-ответ, теперь у него есть MAC-адрес шлюза. Он формирует пакет из тех данных, что ему нужно отправить на 172.16.4.5. В качестве MAC-адреса
получателя ПК ставит адрес шлюза. При этом IP-адрес
получателя в пакете остаётся 172.16.4.5
7) Кадр посылается в сеть, коммутаторы доставляют его на маршрутизатор.
8) На маршрутизаторе, в соответствии с меткой влана, кадр принимается конкретным сабинтерфейсом. Данные канального уровня откидываются
.
9) Из заголовка IP-пакета, рутер узнаёт адрес получателя, а из своей таблицы маршрутизации видит, что тот находится в непосредственно подключенной к нему сети на определённом сабинтерфейсе (в нашем случае FE0/0.102).
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
10) Маршрутизатор отправляет ARP-запрос с этого сабинтерфейса - узнаёт MAC-адрес получателя.
11) Изначальный IP-пакет, не изменяясь
инкапсулируется в новый кадр
, при этом:
12) Кадр доставляется коммутаторами до хоста-получателя.
Будет она вот такой:
То есть прибавляются две точки в Санкт-Петербурге: небольшой офис на Васильевском острове и сам завод в Озерках - и одна в Кемерово в районе Красная горка. Для простоты у нас будет один провайдер “Балаган Телеком”, который на выгодных условиях предоставит нам L2VPN до обеих точек. В одном из следующих выпусков мы тему различных вариантов подключения раскроем в красках. А пока вкратце: L2VPN - это, очень грубо говоря, когда вам провайдер предоставляет влан от точки до точки (можно для простоты представить, что они включены в один коммутатор).
Следует сказать несколько слов об IP-адресации и делении на подсети. В нулевой части мы уже затронули вопросы планирования, весьма вскользь, надо сказать. Вообще, в любой более или менее большой компании должен быть некий регламент - свод правил, следуя которому вы распределяете IP-адреса везде. Сеть у нас сейчас разрастается и разработать его очень важно.
Ну вот к примеру, скажем, что для офисов в других городах это будет так:
Это весьма упрощённый регламент, но теперь мы во всяком случае точно знаем, что у шлюза всегда будет 1-й адрес, до 12-го мы будем выдавать коммутаторам и всяким wi-fi-точкам, а все сервера будем искать в диапазоне 172.16.х.13-172.16.х.23. Разумеется, по своему вкусу вы можете уточнять регламент вплоть до адреса каждого сервера, добавлять в него правило формирования имён устройств, доменных имён, политику списков доступа и т.д. Чем точнее вы сформулируете правила и строже будете следить за их выполнением, тем проще разбираться в структуре сети, решать проблемы, адаптироваться к ситуации и наказывать виновных. Это примерно, как схема запоминания паролей: когда у вас есть некое правило их формирования, вам не нужно держать в голове несколько десятков сложнозапоминаемых паролей, вы всегда можете их вычислить. Вот так же и тут. Я некогда работал в средних размеров холдинге и знал, что если я приеду в офис где-нибудь в забытой коровами деревне, то там точно x.y.z.1 - это циска, x.y.z.2 - дистрибьюшн-свитч прокурва, а x.y.z.101 - компьютер главного бухгалтера, с которого надо дать доступ на какой-нибудь контур-экстерн. Другой вопрос, что надо это ещё проверить, потому что местные ИТшники такого порой наворотят, что слезами омываешься сквозь смех.
Было дело парнишка решил сам управлять всем доступом в интернет (обычно это делал я на маршрутизаторе). Поставил proxy-сервер, случайно поднял на нём NAT и зарулил туда трафик локальной сети, на всех машинах прописав его в качестве шлюза по умолчанию, а потом я минут 20 разбирался, как так: у них всё работает, а мы их не видим.
Почему это так? И как вообще понять все эти маски подсетей? В рамках одной статьи мы не сможем этого рассказать, иначе она получится длинная, как палуба Титаника и запутанная, как одесские катакомбы. Крайне рекомендуем очень плотно познакомиться с такими понятиями, как IP-адрес, маска подсети, их представления в двоичном виде и CIDR (Classless InterDomain Routing) самостоятельно. Мы же далее будем только аргументировать выбор конкретного размера сети. Как бы то ни было, полное понимание придёт только с практикой.
Вообще, очень неплохо эта тема раскрыта в этой статье: http://habrahabr.ru/post/129664/
В данный момент (вспомним ) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 - можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью
, а операция объединения подсетей в суперсети называется суммированием
подсетей (суммированием маршрутов, если быть точным, route summarization)
Приносим извинения за гигантские простыни, видео тоже с каждым разом становится всё длиннее и невыносимее. Постараемся в следующий раз быть более компактными.
В данный момент (вспомним ) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 - можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью
, а операция объединения подсетей в суперсети называется суммированием
подсетей (суммированием маршрутов, если быть точным, route summarization)
Приносим извинения за гигантские простыни, видео тоже с каждым разом становится всё длиннее и невыносимее. Постараемся в следующий раз быть более компактными.
Все заинтересованные, но незарегистрированные приглашаются на беседу в ЖЖ .
За подготовку статьи большое спасибо моему соавтору и моей жене за львиное терпение.
Для очень недовольных: эта статья не абсолют, она не раскрывает теоретические аспекты в полной мере и, потому не претендует на роль полноценной документации. С точки зрения авторов это вспомогательной средство для новичков, волшебный стимул, если желаете. На хабре у вас есть возможность поставить минус, а не доказывать нашу неправоту. Прошу вас, поступите именно так, потому что ваши недовольства встретят лишь вышеприведённые аргументы.
Добавить метки
