Настройка маршрутизации между двумя сетями: Настройка маршрутизации между подсетями. — Litl-admin.ru

Как настроить роутинг между двумя локальными сетями? — Хабр Q&A

Добрый день!
Имеется сервер с 3-мя сетевыми картами.
Первая смотрит в интернет 192.168.0.0/24 (p4p1), остальные две обслуживают разные подсети: 192.168.1.0/24 (br0) и 192.168.10.0/24 (p32p1)
На сервере поднят NAT. Доступ в интернет необходим и работает из подсети 192.168.1.0/24
Теперь понадобилось иметь доступ и подсети 192.168.1.0/24 в 192.168.10.0/24.
1) Форвардинг разумеется включен
2) Траффик между интерфейсами разрешен:
iptables -A FORWARD -i br0 -o p32p1 -j ACCEPT

Однако работать оно что-то не хочет…

Таблица маршрутизации:

Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 p4p1
192.168.0.0     *               255.255.255.0   U     0      0        0 p4p1
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.10.0    *               255.255.255.0   U     0      0        0 p32p1

Конфиг iptables:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type source-quench -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type echo-request -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type parameter-problem -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -i br0 -o p4p1 -j ACCEPT
-A FORWARD -i br0 -o p32p1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# SSH
-A INPUT -p udp -m udp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# OpenVPN
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT

# NTP
-A INPUT -i br0 -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 123 -j ACCEPT

# DNS
-A INPUT -i br0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i p32p1 -p tcp -m tcp --dport 53 -j ACCEPT

# MDNS
-A INPUT -i br0 -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 5353 -j ACCEPT

# SAMBA
-A INPUT -i br0 -p tcp -m tcp --dport 135 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 137 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 138 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 139 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 445 -j ACCEPT

# WWW
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

COMMIT


*nat

# NAT
-A POSTROUTING -o p4p1 -j MASQUERADE

COMMIT

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

Урок 27. Настройка статической маршрутизации

Чтобы лучше понять принцип маршрутизации настроим статическую маршрутизацию на основе нескольких примеров. Для настройки подключимся к консоли маршрутизатора посредством консольного (rollover) кабеля, а после установки IP адреса можно подключаться через Telnet/SSH.

После включения питания оборудование проходит диагностику, называемую POST (Power On Self Testing). Если оборудование и система в порядке, то загружается операционная система IOS (Internetwork Operating System).

Если система не содержит конфигурацию, то система запустит мастера первоначальной настройки, с помощью которого можно настроить порты, пароль к системе и т.д.:

Рекомендую пропустить данный этап и настроить необходимые параметры самостоятельно.

Но прежде повторим какие режимы доступны для настройки:

Теперь настроим сеть, указанную на рисунке:

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

Приступим. 

Приведем настройки для маршрутизатора A_Router. Настройки для маршрутизатора B_Router аналогичны за исключением IP адресов.

Ввод в режим глобальной конфигурации:

 Меняем имя маршрутизатора:

Назначаем IP адрес и маску для интерфейса FastEthernet 0/0, подключенного к локальной сети: 

Затем включаем интерфейс:

 Для информативности можно добавить комментарий к каждому интерфейсу:

То же самое проделаем и с другим интерфейсом, подключенному к маршрутизатору В. Настрой там сеть 10.1.1.0/30.  Подобные интерфейсы еще называют WAN (Wide Area Network) интерфейсами.

Теперь настроим статическую маршрутизацию к сети 192.168.1.0/24:

либо можно ввести IP адрес интерфейса вместо его названия:

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

Вот как выглядит конфигурация на обоих маршрутизаторах:

Теперь выполни команду ping 192.168.1.100 с любого компьютера маршрутизатора A_Router. Если результат выглядит примерно так

то, все настроено правильно.

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

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

Нажми Enter и конфигурация из оперативной памяти будет скопирована в энергонезависимую.

Running-config — текущая конфигурация в оперативной памяти

Startup-config — сохраненная конфигурация в энергонезависимой памяти NVRAM. Именно этот файл будет загружен в оперативную память маршрутизатора при включении питания.

Чтобы просмотреть текущую конфигурацию введи:

Чтобы увидеть таблицу маршрутизации введи:

Ты увидишь новый маршрут обозначенный буквой S, то есть статический (static):

Чтобы увидеть список всех интерфейсов введи:

Теперь немного усложним задачу. Между маршрутизаторами поставим третий маршрутизатор:

Конфигурация маршрутизатора A_Router не изменилась, а в B_Router необходимо изменить адрес WAN интерфейса.

Вот как будет выглядеть конфигурация C_Router:

Таблицы маршрутизации A_Router и B_Router также не изменились. А в C_Router выглядит так:

А теперь еще больше усложним сеть, добавив четвертый маршрутизатор:

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

Добавим новый маршрут в A_Router и B_Router. Настроем D_Router аналогично C_Router с учетом адресации.

Теперь таблицы маршрутизации будут выглядеть так:

Запустим утилиту Ping на одном из хостов, чтобы убедиться, что маршрутизация работает правильно.

По какому же маршруту передаются пакеты? 

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

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

В данном примере один маршрут является более медленным по сравнению с другим маршрутом, что может привести к значительным задержкам при передаче пакетов. Это крайне нежелательно при передаче медиатрафика (видео, голос). Для такого типа трафика необходим постоянный маршрут с минимальными задержками, то есть оптимальным решением является использовать быстрый маршрут для всего трафика, а второй — в качестве резервного на случай отказа первого.

Рассмотрим другую ситуацию. Подключим к сети коммутатор:

Конфигурация прежняя. Таблицы маршрутизации на A_Router и B_Router тоже не изменились. Пакеты свободно проходят по двум маршрутам.

Теперь отключим C_Router и проверим как будет работать связь:

В чем же дело? Ведь у нас же есть работающий маршрут. 

Взглянем на таблицу маршрутизации A_Router:

Ничего не изменилось. Маршрутизатор считает, что C_Router все еще работает и продолжают передавать через него часть пакетов. Поэтому почти половина пакетов потеряна.

Если мы отключим интерфейс Fast Ethernet 1/0 на A_Router, то запись о маршруте исчезнет из таблицы маршрутизации и все пакеты будут приняты:

Здесь оптимальным решением было бы использовать более медленный маршрут в качестве основного либо изменить топологию сети (данный пример лишь показательный).

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

Какое же решение существует в данных примерах? 

Решение простое: в таблицу маршрутизации поместить один (основной) маршрут, который удаляется из таблицы в случае потери связи на канальном уровне. Альтернативный маршрут добавляется в таблицу сразу после удаления основного из таблицы.

Достигается это с помощью установки определенных приоритетов, которые называются административное расстояние (administrative distance). 

Административное расстояние показывает насколько надежным является маршрут по сравнению с другими маршрутами и принимает значения от 1 до 255. Чем ниже значение, тем более надежен маршрут. Статические маршруты по умолчанию всегда имеют административное расстояние равным 1. При наличии двух и более маршрутов до одной и той же сети в таблицу маршрутизации помещается маршрут с наименьшим административным расстоянием. То же самое касается и маршрутов, вычисленных динамическими протоколами маршрутизации RIP, OSPF, EIGRP. Каждый из них имеет определенное значение административного расстояния:

• RIP — 120
• OSPF — 110
• EIGRP — 90

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

Вот как настраивается административное расстояние для статических маршрутов:

Следует быть внимательным и аккуратным при использовании статической маршрутизации.

Где используется статическая маршрутизация? 

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

Неужели в этом случае для каждой сети нужно настраивать отдельный маршрут? 

Нет, достаточно ввести такую команду:

Данная запись означает все сети, то есть образуют единый маршрут для всех сетей. Поэтому нет необходимости настраивать маршруты для каждой отдельной сети.

Однако запись

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

Комментарии для сайта Cackle

Мультиван и маршрутизация на Mikrotik RouterOS / Хабр

С исправлениями и дополнениями от 01.09.2020

Введение

Взяться за статью, помимо тщеславия, побудила удручающая частота возникновения вопросов по этой теме в профильных группах русскоязычного телеграм-сообщества. Статья ориентирована на начинающих администраторов Mikrotik RouterOS (далее ROS). В ней рассматривается только мультиван, с акцентом на маршрутизацию. Бонусом присутствуют минимально достаточные настройки для обеспечения безопасной и удобной работы. Те, кто ищет раскрытия тем очередей, балансировки нагрузки, вланов, бриджей, многоступенчатого глубокого анализа состояния канала и тому подобного — могут не тратить времени и сил на прочтение.

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

В качестве подопытного, выбран пятипортовый маршрутизатор Mikrotik с ROS версии 6.45+. Он будет маршрутизировать трафик между двумя локальными сетями (LAN1 и LAN2) и тремя провайдерами (ISP1, ISP2, ISP3). Канал к ISP1 имеет статический “серый” адрес, ISP2 — “белый”, получаемый по DHCP, ISP3 — “белый” с PPPoE авторизацией. Схема подключения представлена на рисунке:

Задача настроить роутер “МТК” на основе схемы так, чтобы:

1. Обеспечить автоматическое переключение на резервного провайдера. Основной провайдер — ISP2, первый резерв — ISP1, второй резерв — ISP3.
2. Организовать выход сети LAN1 в Интернет только через ISP1.
3. Предусмотреть возможность маршрутизировать трафик из локальных сетей в Интернет через выбранного провайдера на основе address-list.
4. Предусмотреть возможность публикации сервисов из локальной сети в Интернет (DSTNAT)
5. Настроить фильтр файерволла для обеспечения минимально достаточной безопасности со стороны Интернет.
6. Роутер мог выпускать собственный трафик через любого из трех провайдеров в зависимости от выбранного адреса источника.
7. Обеспечить маршрутизацию ответных пакетов в канал, с которого они пришли (включая LAN).

Замечание. Настраивать роутер будем “с чистого листа”, дабы гарантировать отсутствие сюрпризов в меняющихся от версии к версии стартовых конфигурациях “из коробки”. В качестве инструмента настройки выбран Winbox, где будут наглядно отображаться изменения. Сами настройки будут задаваться командами в терминале Winbox. Физическое подключение для настройки осуществляется прямым соединением с интерфейсом Ether5.

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

Пытливый и внимательный админ, самостоятельно настраивая такую или подобную схему, вдруг неожиданно осознает, что оно и так нормально работает. Да-да, без этих ваших пользовательских таблиц маршрутизации и прочих route rules, коими пестрят большинство статей на эту тему. Проверим?

Адресацию на интерфейсах и шлюзы по умолчанию настроить можем? Да:

На ISP1 прописали адрес и шлюз с distance=2 и check-gateway=ping.

На ISP2 настройка dhcp клиента по умолчанию — соответственно distance будет равен единице.

На ISP3 в настройках pppoe клиента при add-default-route=yes ставим default-route-distance=3.

NAT на выход прописать не забываем:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

По итогу, у пользователей локалок котики весело грузятся через основного провайдера ISP2 и есть резервирование канала при помощи механизма check gateway.

Пункт 1 задачи реализован. Где же мультиван со своими метками? Нет…

Дальше. Нужно выпустить конкретных клиентов из LAN через ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS \

passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS \

passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Пункты 2 и 3 задачи реализованы. Метки, марки, route rules, где вы?!

Нужно дать доступ к любимому OpenVPN серверу с адресом 172.17.17.17 для клиентов из Интернет? Пожалуйста:

/ip cloud set ddns-enabled=yes

Клиентам в качестве пира даем результат вывода: “:put [ip cloud get dns-name]”

Прописываем проброс порта из инета:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194 \

in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Пункт 4 готов.

Настраиваем фаервол и прочую безопасность для пункта 5, параллельно радуемся тому, что у пользователей уже все работает и тянемся к емкости с любимым напитком…

А! Туннели же еще забыли.

l2tp-клиент, настроенный по нагугленной статье, до любимого голландского VDS поднялся? Да.

l2tp-сервер с IPsec поднялся и клиенты по ДНС-имени из IP Cloud(см выше.) цепляются? Да.

Откинувшись на спинку стула, прихлебывая напиток, лениво рассматриваем пункты 6 и 7 задачи. Думаем — а оно нам надо? Все ж и так работает (с)… Так вот если оно таки не надо, то на этом все. Мультиван реализован.

Что такое мультиван? Это подключение нескольких каналов Интернет к одному роутеру.

Дальше статью можно не читать, поскольку что там кроме выпендрежа сомнительной применимости может быть?

С теми, кто остался, кто заинтересован пунктами 6 и 7 задачи, а также ощущает зуд перфекционизма, погружаемся глубже.

Важнейшей задачей реализации мультиван является корректная маршрутизация трафика. А именно: независимо от того, в какой (или в какие)^{Примечание 3} канал(ы) провайдера смотрит маршрут по умолчанию на нашем роутере, он должен возвращать ответ именно в тот канал, с которого пакет пришел. Задача понятна. Проблема-то где? Ведь в простой локальной сети задача та же, но никто дополнительными настройками не заморачивается и беды не ощущает. Отличие в том, что любой маршрутизируемый узел в Интернет доступен через каждый из наших каналов, а не через строго конкретный, как в простой локалке. А “беда” заключается в том, что если к нам пришел запрос на IP-адрес ISP3, то в нашем случае ответ уйдет через канал ISP2, поскольку туда направлен шлюз по умолчанию. Уйдет и будет отброшен провайдером, как некорректный. С проблемой определились. Как ее решать?

Решение разделим на три этапа:

1. Предварительная настройка. На этом этапе будут заданы базовые настройки маршрутизатора: локальная сеть, фаервол, address lists, hairpin NAT и пр.
2. Мультиван. На этом этапе будут промаркированы и рассортированы по таблицам маршрутизации нужные соединения.
3. Подключение к ISP. На этом этапе будут настроены интерфейсы, обеспечивающие подключение к Интернет, задействована маршрутизация и механизм резервирования каналов Интернет.

Замечание. Три разных типа подключения к ISP выбраны специально для того, чтобы показать — ничего неразрешимого в настройке мультиван с динамическими адресами нет и продемонстрировать один из вариантов решения.
Важно! Для переключения каналов по алгоритму заданному при помощи стоимости маршрутов distance используется механизм check gateway.

Скрипты, приведенные в статье, к резервированию каналов отношения не имеют.

1. Предварительная настройка

1.1. Очищаем конфигурацию роутера командой:

/system reset-configuration skip-backup=yes no-defaults=yes

соглашаемся с “Dangerous! Reset anyway? [y/N]:” и, после перезагрузки, подключаемся Winbox-ом по MAC. На данном этапе конфигурация и база пользователей очищены.

1.2. Создаем нового пользователя:

/user add group=full name=knight password=ultrasecret comment="Not horse"

логинимся под ним и удаляем дефолтного:

/user remove admin

Замечание. Именно удаление а не отключение дефолтного пользователя автор считает более безопасным и рекомендует к применению.

1.3. Создаем базовые interface lists для удобства оперирования в файерволле, настройках discovery и прочих MAC серверах:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Подписываем комментариями интерфейсы

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

и заполняем interface lists:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN comment=LAN1
/interface list member add interface=ether5 list=LAN comment=LAN2

Замечание. Писать понятные комментарии стоит потраченного на это времени плюс сильно облегчает траблшутинг и понимание конфигурации.

Автор считает необходимым, в целях безопасности, добавить в interface list “WAN” интерфейс ether3, не смотря на то, что по нему не будет ходить протокол ip.

Не забываем, что после того, как на ether3 будет поднят интерфейс PPP, его тоже нужно будет добавить в interface list “WAN”

1.4. Скрываем роутер от обнаружения соседства и управления из сетей провайдеров по МАС:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Создаем минимально достаточный набор правил фильтра файрволла для защиты роутера:

/ip firewall filter add action=accept chain=input \
comment="Related Established Untracked Allow" \
connection-state=established,related,untracked

(правило обеспечивает разрешение для установившихся и родственных соединений, которые инициированы как из подключенных сетей, так и самим роутером)

/ip firewall filter add action=accept chain=input \
comment="ICMP from ALL" protocol=icmp

(пинг и не только пинг. Разрешен весь icmp на вход. Весьма полезно для нахождения проблем с MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" \
in-interface-list=WAN

(закрывающее цепочку input правило запрещает все остальное, что прилетает из Интернет)

/ip firewall filter add action=accept chain=forward \
comment="Established, Related, Untracked allow" \
connection-state=established,related,untracked

(правило разрешает установившиеся и родственные соединения, которые проходят сквозь роутер)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" \
connection-state=invalid

(правило сбрасывает соединения, с connection-state=invalid, проходящие сквозь роутер. Оно настоятельно рекомендовано Mikrotik, но в некоторых редких ситуациях может вызывать блокировку полезного трафика)

/ip firewall filter add action=drop chain=forward \
comment="Drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

(правило запрещает проходить сквозь роутер пакетам, которые идут из Интернет и не прошли процедуру dstnat. Это убережет локальные сети от злоумышленников, которые, находясь в одном широковещательном домене с нашими внешними сетями, пропишут в качестве шлюза наши внешние IP и, таким образом, попытаются “исследовать” наши локальные сети. )

Замечание. Примем за условие, что сети LAN1 и LAN2 являются доверенными и трафик между ними и с них не фильтруется.

1.6. Создаем список с перечнем не маршрутизируемых сетей:

/ip firewall address-list
add address=0.0.0.0/8 comment="\"This\" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"\
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Это список адресов и сетей, которые не маршрутизируются в Интернет и, соответственно, мы тоже будем этому следовать. )

Замечание. Список может изменяться, поэтому советую периодически проверять актуальность.

1.7. Настраиваем DNS для самого роутера:

/ip dns set servers=1.1.1.1,8.8.8.8

Замечание. В текущей версии ROS динамические серверы имеют приоритет перед статически заданными. Запрос на разрешение имени отсылается первому серверу по порядку следования в списке. На следующий сервер переход осуществляется при недоступности текущего. Таймаут большой — более 5 сек. Возврат обратно, при возобновлении работы “упавшего сервера”, автоматически не происходит. С учетом этого алгоритма и наличия мультивана, автор рекомендует не использовать серверы, выдаваемые провайдерами.

1.8. Настраиваем локальную сеть.

1.8.1. Конфигурируем статические IP-адреса на интерфейсах локальных сетей:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Задаем правила маршрутов к нашим локальным сетям через главную таблицу маршрутизации:

/ip route rule add dst-address=192.168.88.0/24 table=main comment="to LAN1"
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Замечание. Это один из простых и быстрых способов получить доступ к адресам локальных сетей с соурсами внешних IP-адресов интерфейсов роутера, через которые не идет маршрут по умолчанию.

1.8.3. Если необходимо включаем Hairpin NAT для LAN1 и LAN2:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" \
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" \
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Замечание. Это позволяет пользователям из LAN1 и LAN2 получать доступ через внешний IP (dstnat) к серверам, находящимся с пользователями в одном сегменте сети.

2. Собственно, реализация того самого корректного мультиван

Для решения задачи “отвечать туда откуда спросили” будем использовать два инструмента ROS: connection mark и routing mark. Connection mark позволяет пометить нужное соединение и в дальнейшем работать с этой меткой, как условием для применения routing mark. А уже с routing mark возможно работать в ip route и route rules. С инструментами разобрались, теперь нужно решить какие соединения метить — раз, где именно метить — два.

С первым все просто — мы должны пометить все соединения, которые приходят в роутер из Интернет по соответствующему каналу. В нашем случае это будут три метки (по количеству каналов): “conn_isp1”, “conn_isp2” и “conn_isp3”.

Нюанс со вторым заключается в том, что входящие соединения будут двух видов: транзитные и те, которые предназначены самому роутеру. Механизм connection mark работает в таблице mangle. Рассмотрим движение пакета на упрощенной диаграмме, любезно собранной специалистами ресурса mikrotik-trainings.com (не реклама):

Следуя по стрелкам, мы видим, что пакет, приходящий в “input interface”, проходит по цепочке “Prerouting” и только потом разделяется на транзитный и локальный в блоке “Routing Decision”. Поэтому, для убиения двух зайцев, задействуем Connection Mark в таблице Mangle Prerouting цепочки Prerouting.

Замечание. В ROS метки “Routing mark” указаны в разделе Ip/Routes/Rules как “Table”, а в остальных разделах, как “Routing Mark”. Сие может внести некую путаницу в понимание, но, по сути, это одно и то же, и является аналогом rt_tables в iproute2 на linux.

2.1. Метим входящие соединения от каждого из провайдеров:

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1 \
new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2 \
new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3 \
new-connection-mark=conn_isp3 passthrough=no

Замечание.

Те читатели, кто пробует буквально и в порядке чтения повторить настройку предложенную в статье, при вводе третьей команды столкнутся с ошибкой: «input does not match any value of interface». Это связано с отсутствием в данный момент интерфейса «pppoe-isp3», который будет сконфигурирован в п. 3.3.2. На данном этапе можно вместо «pppoe-isp3» ввести «ether3». После выполнения п. 3.3.2 следует вернуться и поставить актуальное имя интерфейса.

Для того, чтобы не метить уже помеченные соединения я использую условие connection-mark=no-mark вместо connection-state=new.

passthrough=no — потому, что в этом способе реализации перемаркировка исключена и для ускорения можно прервать перебор правил после первого же совпадения.

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

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” и попали к своему адресату в локальной сети.

Важно! В ROS нет логического деления на внешний и внутренний интерфейсы. Если проследить путь движения ответного пакета по приведенной диаграмме, то он пройдет по тому же логическому пути, что и запрос:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” просто для запроса “Input Interface” был интерфейс ISP, а для ответа — LAN

2.2. Направляем ответный транзитный трафик по соответствующим таблицам маршрутизации:

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Замечание. in-interface-list=!WAN — мы работаем только с трафиком из локальной сети и dst-address-type=!local не имеющим адрес назначения адреса интерфейсов самого роутера.

То же самое для локальных пакетов, которые пришли в роутер по пути:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

Важно! Ответ пойдет по следующему пути:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”


2.3. Направляем ответный локальный трафик по соответствующим таблицам маршрутизации:

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local new-routing-mark=to_isp3 passthrough=no

На этом этапе задачу подготовки к отправке ответа в тот канал Интернет, с которого пришел запрос можно считать решенной. Все помечено, промаркировано и готово маршрутизироваться.
Отличным “побочным” эффектом такой настройки является возможность работы проброса портов DSNAT с обоих (ISP2, ISP3) провайдеров одновременно. Не на всех, так как на ISP1 у нас не маршрутизируемый адрес. Этот эффект важен, например, для почтового сервера с двумя MХ, которые смотрят в разные каналы Интернет.

Для устранения нюансов работы локальных сетей с внешними IP роутера используем решения из пп. 1.8.2 и 3.1.2.6.

Кроме того, можно задействовать инструмент с маркировками и для решения пункта 3 задачи. Реализуем так:

2.4. Направляем трафик от локальных клиентов из списков маршрутизации в соответствующие таблицы:

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 \
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 \
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 \
passthrough=no src-address-list=Via_ISP3

По итогу, это выглядит приблизительно так (картинка кликабельна):

3. Настраиваем подключение к ISP и задействуем маршрутизацию по маркам

3.1. Настраиваем подключение к ISP1:
3.1.1. Конфигурируем статический IP-адрес:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Настраиваем статическую маршрутизацию:
3.1.2.1. Добавляем “аварийный” маршрут по умолчанию:

/interface bridge add name=br-lo comment="Loopback interface"
/ip route add distance=254 gateway=br-lo comment="Emergency route"

Замечание. Этот маршрут позволяет трафику от локальных процессов проходить этап Route Decision независимо от состояния каналов любого из провайдеров. Нюанс исходящего локального трафика заключается в том, что чтобы пакет хоть куда-то двинулся, в основной таблице маршрутизации должен присутствовать активный маршрут до шлюза по умолчанию. Если его нет, то пакет просто будет уничтожен.

В качестве расширения инструмента check gateway для более глубокого анализа состояния канала предлагаю использовать метод рекурсивных маршрутов. Суть метода заключается в том, что мы указываем маршрутизатору искать путь к своему шлюзу не напрямую, а через промежуточный шлюз. В качестве таких “проверочных” шлюзов будут выбраны 4.2.2.1, 4.2.2.2 и 4.2.2.3 (это публичные адреса Level3DNS) соответственно для ISP1, ISP2 и ISP3. Можете выбрать любые другие доступные адреса, исходя из собственных предпочтений.

3.1.2.2. Маршрут до “проверочного” адреса:

/ip route add check-gateway=ping comment="For recursion via ISP1" \
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Замечание. Значение scope понижаем до дефолтного в ROS target scope, чтобы использовать в дальнейшем 4.2.2.1 в качестве рекурсивного шлюза. Подчеркиваю: scope маршрута до “проверочного” адреса должно быть меньше или равно target scope того маршрута, который будет ссылаться на проверочный.

3.1.2.3. Рекурсивный маршрут по умолчанию для трафика без routing mark:

/ip route add check-gateway=ping comment="Unmarked via ISP1" \
distance=2 gateway=4.2.2.1

Замечание. Значение distance=2 используется потому, что ISP1 по условиям задачи заявлен как первый резервный.

3.1.2.4. Рекурсивный маршрут по умолчанию для трафика c routing mark “to_isp1”:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 \
routing-mark=to_isp1

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

По этому маршруту весь трафик, который имеет mark route “to_isp1”, будет направлен на шлюз первого провайдера не зависимо от того, какой в данный момент активен шлюз по умолчанию для таблицы main.

3.1.2.5. Первый резервный рекурсивный маршрут по умолчанию для маркированного трафика провайдеров ISP2 и ISP3:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp3

Замечание. Эти маршруты нужны, в том числе, для резервирования трафика с локальных сетей, которые состоят членами address list “to_isp*”’

3.1.2.6. Прописываем маршрут для локального трафика роутера в интернет через ISP1:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Замечание. В сочетании с правилами из пункта 1.8.2, обеспечивается выход в нужный канал с заданным соурсом. Это является критичным для построения туннелей, в которых задается IP-адрес локальной стороны(EoIP, IP-IP, GRE). Поскольку правила в ip route rules выполняются сверху вниз, до первого совпадения условий, то данное правило должно быть после правил из пункта 1.8.2.

3.1.3. Прописываем правило NAT для исходящего трафика:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1" \
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Замечание. NATим все выходящее, кроме того, что попадает в политики IPsec. Я стараюсь не использовать action=masquerade без крайней необходимости. Оно работает медленнее и более ресурсоемко, чем src-nat, поскольку для каждого нового соединения вычисляет адрес для NAT.

3.1.4. Отправляем клиентов из списка, которым запрещен выход через остальных провайдеров сразу на шлюз провайдера ISP1.

/ip firewall mangle add action=route chain=prerouting \
comment="Address List via ISP1 only" dst-address-list=!BOGONS passthrough=no \
route-dst=100.66.66.1 src-address-list=Via_only_ISP1 place-before=0

Замечание. action=route имеет более высокий приоритет и применяется раньше остальных правил маршрутизации.

place-before=0 — помещает наше правило первым в списке.

3.2. Настраиваем подключение к ISP2.

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

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if (\$bound=1) do={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \
          [ find where dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip route add check-gateway=ping comment=\"For recursion via ISP2\" \
          distance=1 dst-address=4.2.2.2/32 gateway=\$\"gateway-address\" scope=10\r\
    \n   /ip route add check-gateway=ping comment=\"Unmarked via ISP2\" \
          distance=1 gateway=4.2.2.2\r\
    \n   /ip route add comment=\"Marked via ISP2 Main\" distance=1 gateway=4.2.2.2 \
          routing-mark=to_isp2\r\
    \n   /ip route add comment=\"Marked via ISP1 Backup1\" distance=2 \
          gateway=4.2.2.2 routing-mark=to_isp1\r\
    \n   /ip route add comment=\"Marked via ISP3 Backup2\" distance=3 \
          gateway=4.2.2.2 routing-mark=to_isp3\r\
    \n   /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
          out-interface=\$\"interface\" to-addresses=\$\"lease-address\" \
          comment=\"NAT via ISP2\"\r\
    \n   /ip route rule add comment=\"From ISP2 IP to Inet\" \
          src-address=\$\"lease-address\" table=to_isp2 \r\
    \n} else={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \
          [ find where dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip firewall nat remove  [find comment=\"NAT via ISP2\"]\r\
    \n   /ip route rule remove [find comment=\"From ISP2 IP to Inet\"]\r\
    \n}\r\
    \n" use-peer-dns=no use-peer-ntp=no

Сам скрипт в окне Winbox (кликабельно):

Замечание. Первая часть скрипта срабатывает при успешном получении аренды, вторая — после освобождения аренды.^{Примечание 2}

Важно! В отдельных случаях шлюз может не отвечать на ICMP запросы. C этим можно встретиться на lte подключении в режиме passthrough или, если провайдер фильтрует ICMP на шлюз. В такой ситуации, для маршрута «For recursion via ISP(x)», вместо check-gateway=ping нужно указывать check-gateway=arp.

3.3. Настраиваем подключение к провайдеру ISP3.

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

Замечание. Интерфейс ppp может быть указан в качестве шлюза вместо IP-адреса. Однако в таком варианте рекурсивный маршрут задействовать не получится. Посему мы получаем в переменную IP-адрес стороны провайдера и используем ее дальше точно так же, как и для остальных провайдеров

3.3.1. Сначала конфигурируем профиль:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client \
on-down="/ip route remove [ find gateway=\"4.2.2.3\" ]\r\
    \n/ip route remove [ find where dst-address ~\"4.2.2.3\" ]\r\
    \n/ip firewall nat remove  [find comment=\"NAT via ISP3\"]\r\
    \n/ip route rule remove [find comment=\"From ISP3 IP to Inet\"]" \
on-up="/ip route remove [ find gateway=\"4.2.2.3\" ]; /ip route remove \
    [ find where dst-address ~\"4.2.2.3\" ]\r\
    \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \
    dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=10\r\
    \n/ip route add check-gateway=ping comment=\"Unmarked via ISP3\" distance=3 \
    gateway=4.2.2.3\r\
    \n/ip route add comment=\"Marked via ISP3 Main\" distance=1 gateway=4.2.2.3 \
    routing-mark=to_isp3\r\
    \n/ip route add comment=\"Marked via ISP1 Backup2\" distance=3 gateway=4.2.2.3 \
    routing-mark=to_isp1\r\
    \n/ip route add comment=\"Marked via ISP2 Backup2\" distance=3 gateway=4.2.2.3 \
    routing-mark=to_isp2\r\
    \n/ip firewall mangle set [find comment=\"Connmark in from ISP3\"] \
    in-interface=\$\"interface\"\r\
    \n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
    out-interface=\$\"interface\" to-addresses=\$\"local-address\" \
    comment=\"NAT via ISP3\"\r\
    \n/ip route rule add comment=\"From ISP3 IP to Inet\" \
    src-address=\$\"local-address\" table=to_isp3 "

Сам скрипт в окне Winbox(кликабельно):

Замечание. Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;

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

3.3.2. Теперь, используя профиль, создаем подключение ppp:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no \
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client \
user=isp3_client

Замечание. Некоторые провайдеры «забывают» отдавать параметр «remote-address». В таком случае, при подключении скрипт настройки отработает некорректно, а в логе вы увидите такую ошибку:

pppoe,ppp,info pppoe-isp3: could not determine remote address, using xxx.xxx.xxx.xxx

Для решения этой проблемы нужно вручную задать в ppp профиле адрес(любой фиктивный):

/ppp profile set isp3_client remote-address=169.254.69.96

Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;

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

В качестве последнего штриха настроим часы:

/system ntp client set enabled=yes \
server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Для тех, кто дочитал до конца

Предложенный способ реализации мультиван — есть личное предпочтение автора и не является единственно возможным. Инструментарий ROS обширен и гибок, что с одной стороны вызывает сложности для начинающих, с другой — причина популярности. Изучайте, пробуйте, открывайте для себя новые инструменты и решения. Например, в качестве применения полученных знаний, можно в данной реализации мультиван заменить инструмент Сheck-gateway с рекурсивными маршрутами на Netwatch.

Примечания

1. Check-gateway — механизм, который позволяет деактивировать маршрут после двух подряд не успешных проверок шлюза на доступность. Проверка осуществляется раз в 10 секунд, плюс таймаут ответа. Итого, фактический тайминг переключения лежит в диапазоне 20-30 секунд. Если такой тайминг переключения не достаточен — есть вариант воспользоваться инструментом Netwatch, где таймер проверки можно задавать вручную.
   
   Механизм Check-gateway не срабатывает при периодических потерях пакетов в канале.

   Важно! Деактивация/активация маршрута механизмом Check-gateway влечет за собой деактивацию/активацию всех остальных маршрутов, которые идут через тот же шлюз. Поэтому включать check-gateway для всех связанных маршрутов нет необходимости.

2. Бывает, что в механизме работы DHСP происходит сбой, который выглядит, как клиент подвисший в состоянии renew. В таком случае вторая часть скрипта не отработает, но корректно ходить трафику не помешает, поскольку состояние отслеживает соответствующий рекурсивный маршрут.
3. ECMP (Equal Cost Multi-Path) — в ROS есть возможность задать маршрут с несколькими шлюзами и одинаковой distance. В таком случае соединения будут распределяться по каналам, используя алгоритм round robin, пропорционально количеству указанных шлюзов.

За толчок к написанию статьи, помощь при формировании ее структуры и расстановке акцентов — личная благодарность Евгению @jscar

Азы статической маршрутизации ~ Сетевые заморочки

В прошлой статье мы с вами обсудили процесс маршрутизации между сетями, подключенными к интерфейсами одного единственного маршрутизатора (рекомендую ознакомиться с ней), сегодня же мы разберем, как осуществляется маршрутизация между сетями, подключенными к разным маршрутизаторам, связанным между собой. Пока что мы не будим лезть в дебри протоколов динамической маршрутизации, а разберемся, как пользоваться статической маршрутизацией. В качестве примеров, для демонстрации настройки будим использовать маршрутизаторы фирмы Cisco,  доступные в Packet Tracer.
Как мы уже выяснили, если у нас всего один маршрутизатор, то нам достаточно всего лишь сконфигурировать его интерфейсы, и он сразу же будет выполнять маршрутизацию между сетями, подключенными к нему. Немного по иному обстоят дела, если в нашей сети есть несколько маршрутизаторов. Допустим, наша интерсеть сеть будет иметь следующий вид:

Как мы и обсуждали ранее сети, подключенные к интерфейсам одного маршрутизатора, будут видеть друг друга. Так сети «левого » маршрутизатора 192.168.1.0/24, 172.20.0.0/16 и 192.168.100.0/30 будут видеть друг друга. Аналогично обстоят дела с «правым» маршрутизатором. Но вот как будут обстоять дела с взаимодействием сетей данных маршрутизаторов между собой? Например, компьютеры сети 10.0.0.0/8 не будут доступны из сети 192.168.1.0/24.  Данный принцип, для всех сетей, проиллюстрирован на «жестком» рисунке ниже:

Почему же некоторые сети не видят друг друга. Все очень просто, соседние маршрутизаторы не содержат записей о сетях подключенных, только к другому маршрутизатору. Например, маршрутизатор «левый» не знает о существование сети 10.0.0.0/8, подключенной к «правому» маршрутизатору.

Давайте сымитируем данную ситуацию в Cisco Packet Tracer, а заодно поищем пути ее решения. Для начала соберем в Packet Tracer следующую схему (как это сделать смотрите в предыдущей статье):

На данной схеме компьютер PC0 имеет IP адрес – 192.168.1.100, PC1 – 172.20.20.100, PC2 – 192.168.2.100, PC3 – 10.10.10.100. Интерфейсы маршрутизатора, к которым подключены компьютеры, имеют такие же адреса, как и сами компьютеры, только в четвертом октете стоит 1. Например, для интерфейса к которому подключен ПК с адресом 192.168.1.100 зададим IP адрес 192.168.1.1. В качестве шлюза по умолчанию у каждого компьютера указан интерфейс маршрутизатора, к которому он подключен. После настройке интерфейсов маршрутизаторов, сохраните их конфигурации, выполнив wr mem. Далее соединим маршрутизаторы между собой. Чтобы это сделать, нам потребуется добавить к маршрутизатору интерфейсную плату. В данном случае добавим к маршрутизатору плату  NM-1FE-TX (NM – Network module, 1FE – содержит один порт FastEthernet, TX – поддерживает 10/100MBase-TX).Чтобы это сделать перейдите к окну конфигурации маршрутизатора, выключите его, щелкнув по кнопке питания изображенной на нем.

После этого перетяните необходимую интерфейсную плату в разъем маршрутизатора.

После того как карта добавлена, еще раз щелкните по тумблеру маршрутизатора, чтобы включить его. Посмотрите его интерфейсы, должен добавиться еще один – FastEthernet1/0. Повторите аналогичные действия со вторым маршрутизатором. Задайте интерфейсу FastEthernet1/0 «левого» маршрутизатора IP адрес 192.168.100.1 c с маской 255.255.255.252, а «правому маршрутизатору» 192.168.100.2 с аналогичной маской. После этого соедините интерфейсы FastEthernet1/0  этих маршрутизаторов между собой.

Проверим доступность компьютеров одной сети из других. Если все сделано верно, то картина доступности должна соответствовать второму рисунку данной статьи. Если вы внимательно посмотрите на данный рисунок, то заметите что на данном рисунке не все стрелки двунаправленные. С двунаправленными стрелками все понятно, если вы будите пинговать в данном направлении, то компьютеры будут отвечать вам на ваши ICMP запросы (так как происходит маршрутизация в пределах одного маршрутизатора). Намного интереснее  обстоит дело с однонаправленными зелеными стрелками. Хотя пинги в данном направлении не проходят, на самом деле ICMP пакеты доходят до места назначения, но вот вернуться обратно уже не могут. Рассмотрим как это происходит на конкретном примере. Допустим, с компьютера с IP адресом 172.20.20.100 вы пытаетесь пропинговать интерфейс с IP адресом 192.168.100.2, «правого» маршрутизатора. Картина будет выглядеть следующим образом:

Попробуем отследить путь ICMP пакетов. Для этого включим дебаги  (режим отладки определенных параметров) на маршрутизаторах, через которые предположительно должны пройти ICMP пакеты. Выполним команду debug ip packet, на обоих маршрутизаторах. После чего опять попытаемся пропинговать с адреса  172.20.20.100 адрес 192.168.100.2. Посмотрим, что появилось на «левом маршрутизаторе»:

IP: tableid=0, s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), routed via RIB

IP: s=172.20.20.100 (FastEthernet0/1), d=192.168.100.2 (FastEthernet1/0), g=192.168.100.2, len 128, forward

Первая строка говорит о том, что на маршрутизатор прибыл пакет с адреса 172.20.20.100, направляемый на адрес 192.168.100.2. Во второй строчке говорится о том, что данный пакеты был передан дальше, ключевое слово здесь «forward».

Теперь посмотри, что творится в это же время на «правом» маршрутизаторе:

IP: tableid=0, s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), routed via RIBIP: s=172.20.20.100 (FastEthernet1/0), d=192.168.100.2 (FastEthernet1/0), len 128, rcvd 3

IP: s=192.168.100.2 (local), d=172.20.20.100 len 128, unroutable

Как видно из первых двух строчек, наш ICMP пакет все таки дошел до «правого» маршрутизатора.  А что должен сделать интерфейс, на который направлялся ping? Правильно, ответить на него послав ICMP пакеты в обратном направлении  с адреса 192.168.100.2 на 172.20.20.100. Вот тут то и начинаются проблемы. «Правый» маршрутизатор не имеет в своей таблице маршрутизации информации о сети 172.20.20.0/16. Шлюз по умолчанию мы еще не прописывали, поэтому маршрутизатор просто не может отослать ответы, в результате чего появляется третья строка дебага, ключевое слово в которой «unroutable».

После того как мы разобрались с тем, как в нашей сети, в данный момент, ходят пакеты. Отключим дебаги (no debug ip packet – отключает включенный ранее дебаг, show debugging – позволяет посмотреть включенные дебаги), и перейдем к настройке маршрутизации.

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

   ip route 0.0.0.0 0.0.0.0 192.168.100.2

На «правом» маршрутизаторе:

   ip route 0.0.0.0 0.0.0.0 192.168.100.1

В следующих командах первые 4 цифры обозначают IP адрес сети назначения, следующие  4 цифры обозначают её маску, а последние 4 цифры – это IP адрес интерфейса, на который необходимо передать пакеты, чтобы попасть в данную сеть. Если мы указываем в качестве адреса сети 0.0.0.0 с маской 0.0.0.0, то данный маршрут становится маршрутом по умолчанию, и все пакеты, адреса назначения которых, прямо не указаны в таблице маршрутизации будут отправлены на адрес, указанный в нем.

Посмотрим как это выглядит на конкретном примере. Допустим, мы хотим пропинговать с компьютера с адресом 192.168.1.100 компьютер с IP адресом 10.10.10.100.  В качестве шлюза по умолчанию на компьютере с адресом 192.168.1.100 установлен адрес интерфейса маршрутизатора 192.168.1.1. Сначала компьютер будет искать в свой таблице маршрутизации (да у обычного компьютера она тоже есть) непосредственно адрес 10.10.10.100, после того как он его не найдет, он начнет искать в таблице маршрутизации маршрут к сети 10.0.0.0/8. После того, как данный маршрут так же не будет обнаружен. ICMP пакеты будут отправлены на адрес по умолчанию, то есть на интерфейс маршрутизатора с адресом 192.168.1.1. Получив пакет, маршрутизатор просмотрит адрес его назначения – 10.10.10.100 и также попытается обнаружить его в свой таблице маршрутизации. Когда это не увенчается успехом, маршрутизатор попробует найти в свой таблице маршрутизации маршрут к сети 10.0.0.0/8. Когда он не обнаружит и его, пакет будет отправлен используя, только что заданный нами, маршрут по умолчанию. И ICMP пакет будет передан на интерфейс, с адресом 192.168.100.2, «правого» маршрутизатора. Правый маршрутизатор попробует обнаружить в свой таблице маршрутизации маршрут к адресу 10.10.10.100. Когда это не увенчается успехом, «правый» маршрутизатор будет искать маршрут к сети 10.0.0.0/8. Информация о данной сети содержится в таблице маршрутизации, и маршрутизатор знает, что для того чтобы попасть в данную сеть необходимо отправить пакеты на интерфейс FastEthernet0/1, непосредственно к которому подключена данная сеть. Так как в нашем примере вся сеть 10.0.0.0/8, представляет из себя всего 1 компьютер, то пакеты сразу же попадают в место назначения, компьютер с IP адресом 10.10.10.100. При отсылке ответных ICMP пакетов, все происходит аналогичным образом, только адресом назначения уже будет являться 192.168.1.100/24.

К сожалению далеко не всегда можно обойтись указанием только маршрутов по умолчанию. В более сложных сетевых конфигурациях может потребоваться прописывать маршрут для каждой из сетей в отдельности. Давайте сразу рассмотрим как же это делается.  Для этого, сначала удалим из таблицы маршрутизации все статически добавленные маршруты, используя команду no ip route xxxx(адрес сети) yyyy(маска) zzzz(адрес интерфейса). В конечном итоге таблицы маршрутизации должны содержать только информацию о непосредственно подключенных  к ним сетях. Для «левого» маршрутизатора таблица будет примерно такой:

Теперь нам необходимо добавить к каждому из маршрутизаторов маршруты к двум сетям, которые ему неизвестны (к сетям, подключенным к соседнему маршрутизатору). На «левом» маршрутизаторе выполним:

   ip route 192.168.2.0 255.255.255.0 192.168.100.2

   ip route 10.0.0.0 255.0.0.0 192.168.100.2

На правом маршрутизаторе выполним:

   ip route 192.168.1.0 255.255.255.0 192.168.100.1

   ip route 172.20.0.0 255.255.0.0 192.168.100.1

Если все сделано верно, то ваши сети должны будут взаимодействовать согласно рисунку:

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

Настройка маршрутизации win 10, как сделать раздельное использование 2х сетевых интерфейсов?

У меня если что стандартное подключение, получает все адреса от роутера на автомате…

Вообщем… поковырявшись с маршрутизацией… у меня не получается даже пустить трафик на определенный ИП
(при включённым vpn)
К примеру: берем сайт (https://2ip.ru/) для проверки вашего ИП, посредством ping получаем его айпишник.
Далее… в постоянные маршруты прописываем: route -p add 188.40.35.183 mask 255.255.255.255 192.168.1.1
…по логике получается, мы говорим: вот адрес иди через стандартную дверь (шлюз) в данном случае роутер.
На практике: все равно весь трафик идет через vpn…
(карта маршрута)

Пробовал и в обратной последовательности, когда в конфиге vpn делаешь так: https://community.openvpn.net/openvpn/wiki/IgnoreR…
Весь трафик начинает идти через стандартное подключение, прописываешь маршрут для заданного ип, но! все равно часть трафика не заворачивает в openVpn -овское подключение…

Люди добрые! Что я делаю не так?
(по идее должно работать)

/////
Так, вроде я решил проблему )

1. В конфиге openVPN (вверху) добавляем…
route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway
(тем самым мы пускаем весь трафик через стандартное подключение)

2. Лезем сюда и ставим: https://r1ch.net/projects/forcebindip
(Эта штуковина управляет нужными нам прогами, и говорит им «туды ходи и через эту дверь» Но вы поняли…)
(На дворе 2016 год! и к сожалению винда не умеет решать подобные задачи штатными средствами)

3. (для тех кому лень постоянно в командной строке писать)
Для нужной нам проги (какую хотим запускать) делаем батник (запускаем от имени админа)
В батнике пишем (для примера сделал для Хрома)
ForceBindIP.exe 10.211.1.1 «C:\Program Files (x86)\Google\Chrome\Application\chrome.exe»

4. Ип интерфейса узнаем (он постоянно меняется) в «сведения о сетевом подключении»
(либо команда: route print)

PS: Получились грабли )) но зато работает все! проверил 3ри раза!
Если у кого появится свои варианты решения данных задач, буду рад их изучить.

Статичная маршрутизация. Настройка маршрутов между роутерами. Принципы маршрутизации сообщений

Всем привет сегодня мы с вами поговорим про такую вещь как статическая маршрутизация в оборудовании Cisco. Эта статья продолжение поста Как настроить маршрутизатор cisco / Организация сети для небольшого офиса . Там мы настроили локальную сеть в двух офисах компании, один маленький офис, второй чуть побольше. На роутере во втором офисе мы остановились на настройке статической маршрутизации, чем мы и займемся.

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

Первые два утверждения показывают, что для перехода к сети 0 и 0 с помощью маски 0 используйте 2 в качестве следующего маршрутизатора с пересылкой. В последнем утверждении говорится, что для перехода в сеть 0 маска 0 использует 2 в качестве маршрутизатора следующего прыжка. Имейте в виду, что общение — это два пути. То есть, для двух устройств для разговора должен быть путь в обоих направлениях. Поэтому для завершения конфигурации каждый из других маршрутизаторов на диаграмме также должен быть настроен со статическими маршрутами во все сети, к которым они напрямую не подключены.

Первое с чем нужно познакомиться, это с понятием таблицы маршрутизации. Если в двух словах это некая карта маршрутов, до сетей о которых знает ваш коммутатор 3 уровня или роутер. Для большей наглядности ее можно сравнить с картой дорог до городов России. И для того, чтобы например мне попасть из Москвы в Нижний Новгород, я должен выбрать определенную дорогу. Так и ваш роутер выбирает ее. Далее если мне нужно из Москвы попасть в Казань, и мне нужно ехать туда через Нижний Новгород, то В НН должен быть свой маршрут до Казани и так далее.

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

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

Статический маршрут — это постоянный неизменный маршрут, чаще всего прописанный в ручную.

Схема сети офисов

У нас есть филиал, в котором 3 компьютера коммутатор второго уровня Cisco 2960 и Роутер Cisco 1841, есть три vlan (2,3,4). Есть главный офис в котором есть 5 vlan (2,3,4,5), маршрутизацией локального трафика занимается ядро в виде коммутатора 3 уровня Cisco 3560, который VLAN 5 подключен к роутеру Cisco 2911, на котором настроен будет интернет и канал до филиала.

Пример настройки маршрутизации с вызовом по требованию

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

В предыдущем посте где мы создавали данную локальную сеть я не настроил vlan 5 на роутере и ядре, исправим это.

Настройка Cisco 2911 и Cisco 3560

Настройка Cisco 3560

enable

conf t

Создаем Vlan 5

vlan 5

name VLAN5

exit

Настроим ip адрес VLAN5

int vlan 5

ip address 192.168.5.1 255.255.255.0

exit

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

Управление удаленным маршрутизатором

Пути по умолчанию — это статические маршруты, которые используются для определения маршрута к неизвестному месту назначения. Как правило, вам не нужно настраивать маршрут по умолчанию на маршрутизаторе, потому что маршрутизатор должен уже знать, как перенаправить кадр в пункт назначения, проверив их таблицу маршрутов для известного пути. Однако, если маршрутизатор не имеет ученого пути, он использует оператор маршрута по умолчанию.

Добавим порт gi1/1 в VLAN5

int gi0/1

выставляем режим доступа

switchport mode access

switchport access vlan 5

no shutdown

do wr mem

Настройка Cisco 2911

Так как у нас локальной маршрутизацией трафика занимается ядро то тут sub интерфейсов создавать не нужно. Настроим порт роутера gi0/0 на vlan5.

enable

conf t

Настроим ip адрес VLAN5

int gi0/0

ip address 192.168.5.251 255.255.255.0

no shutdown

do wr mem

Сценарии развертывания одноадресной маршрутизации

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

Внутренние и внешние протоколы маршрутизации

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

Добавление статических маршрутов на Cisco 2911

Так как наш роутер Cisco 2911 ничего не знает о сетях 192.168.1.0, 192.168.2.0, 192.168.3.0, то нужно задать ему статические маршруты до них, через ядро делается это следующим образом.

Удостоверимся что пинг не проходит до компьютера 192.168.1.1, вводим на роутере.

ping 192.168.1.1

Видим ответов нет

Что вы должны знать о маршрутизации

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

Переходим в режим конфигурирования командой

и смотрим команду ip:

Router(config)#ip ?

access-list Named access-list

cef Cisco Express Forwarding

default-gateway Specify default gateway (if not routing IP)

default-network Flags networks as candidates for default routes

dhcp Configure DHCP server and relay parameters

domain IP DNS Resolver

domain-lookup Enable IP Domain Name System hostname translation

domain-name Define the default domain name

flow-export Specify host/port to send flow statistics

Маршрутизаторы не отправляют широковещательные рассылки в поисках удаленных сетей; поэтому, если сеть не указана в таблице маршрутизаторов, маршрутизатор просто отбрасывает пакеты. Теперь, как маршрутизатор поддерживает свою таблицу маршрутизации? Ответ довольно прост. На маршрутизаторе настроены либо маршруты маршрута вручную, либо динамические протоколы используются для заполнения маршрутной информации маршрутизаторам.

Ручная настройка маршрутов на вашем маршрутизаторе может быть выгодной и невыгодной. Статическая маршрутизация имеет следующие преимущества. Никакой дополнительной обработки и дополнительных ресурсов, как в случае с динамическими протоколами маршрутизации. Требование дополнительной полосы пропускания, вызванное передачей чрезмерных пакетов для процесса обновления таблицы маршрутизации. Дополнительная защита путем ручного ввода или отклонения маршрутизации в определенные сети. К недостаткам статической маршрутизации относятся следующие.

forward-protocol Controls forwarding of physical and directed IP broadcasts

ftp FTP configuration commands

host Add an entry to the ip hostname table

local Specify local options

name-server Specify address of name server to use

nat NAT configuration commands

route Establish static routes

routing Enable IP routing

ssh Configure ssh options

tcp Global TCP parameters

Нам нужна команда ip route.

Знакомство со статической маршрутизацией

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

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

так как ip адрес на ядре сети (Cisco 3560) у VLAN 5 у нас 192.168.5.1 то он будет выступать для нас шлюзом. В итоге пишем.

ip route 192.168.1.0 255.255.255.0 192.168.5.1

ip route 192.168.2.0 255.255.255.0 192.168.5.1

ip route 192.168.3.0 255.255.255.0 192.168.5.1

и выполнив теперь команду Ping мы видим. что пакет дошел до 192.168.1.1

Использование административных расстояний в статических маршрутах

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

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

Планирование сети

Все бы хорошо, но мы не правильно спланировали сеть в удаленном офисе. Так как там как и в главном, тоже есть сеть 192.168.1.0, 192.168.2.0, 192.168.3.0, такого быть не должно иначе получается дубли. Как правильно планировать сеть я писал тут, вам нужно перенастроить, как ранее описано в предыдущей статье. В итоге в филиале я заменил сети на 11, 22, 33 третьи актеты ip адреса. Общая картина теперь выглядит так.

Аналогичная конфигурация должна выполняться и на других маршрутизаторах. Помните, что маршрутизаторы знают только о сетях, напрямую связанных с ними. Статические маршруты или маршруты, изученные динамическими протоколами, должны быть настроены для того, чтобы маршрутизаторы выполняли свою работу: Маршрутизация пакетов, конечно. Также имейте в виду, что маршруты по умолчанию выбираются, когда нет определенного соответствия в таблице маршрутизации для данной сети. Они предпочтительно используются в сетях с заглушками.

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

Соединение роутеров

Соединяем наши роутеры. Предположим, что между ними есть прямой линк, в жизни конечно это VPN канал . настроим в начале роутер Cisco 2911 в главном офисе.

Создание таблицы маршрутизации

Основными соображениями при создании таблицы маршрутизации являются. Если маршрутизатор узнает о пункте назначения из более чем одного протокола маршрутизации, будет сравниваться административная дистанция и предпочтение будет отдано маршрутам с более низким административным расстоянием. Метрика — это мера, используемая протоколом маршрутизации для расчета наилучшего пути к данному месту назначения, если он изучает несколько путей к одному и тому же месту назначения. Длина префикса.

• Административное расстояние Это мера верности происхождения маршрута.
• Другими словами, это авторитет источника маршрута.
• В каждом протоколе маршрутизации используется другой показатель.

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

маска тут 32 бита так как нам достаточно всего 2 ip адреса.

enable

conf t

int gi0/1

no shutdown

ip address 192.168.100.1 255.255.255.252

end

wr mem

Теперь настроим роутер Cisco 1841 в филиале. У меня это интерфейс fa0/1

enable

conf t

int fa0/1

ip address 192.168.100.2 255.255.255.252

no shutdown

do wr mem

Маршрутизатор решает, следует ли устанавливать маршруты, представленные процессами маршрутизации, на основе административного расстояния указанного маршрута. Если этот путь имеет наименьшее административное расстояние до этого пункта назначения, он будет установлен в таблице маршрутизации. Если этот маршрут не соответствует лучшему административному расстоянию, маршрут будет отклонен.

Чтобы понять это лучше, давайте посмотрим на пример. Каждому процессу маршрутизации присваивается административное расстояние, которое используется для определения маршрута установки. Если предпочтительный маршрут провалится, следующий лучший маршрут будет успешным в следующей попытке. Другое решение заключается в том, что неудачный протокол маршрутизации установил свой маршрут в таблице для поддержания маршрута и запросил, чтобы процесс таблицы маршрутизации сообщал, что лучший маршрут терпит неудачу.

У нас загорелись порты обоих коммутаторов.

Проверяем пинги с роутеров друг до друга

do ping 192.168.100.1

Видим, что все успешно.

Настройка маршрутов между роутерами

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

ip route 0.0.0.0 0.0.0.0 192.168.100.1

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

ip route 192.168.1.0 255.255.255.0 192.168.100.1

ip route 192.168.2.0 255.255.255.0 192.168.100.1

ip route 192.168.3.0 255.255.255.0 192.168.100.1

do wr mem

Настроим теперь роутер у главного офиса, нам нужно добавить маршруты до сетей 192.168.11.0, 192.168.22.0, 192.168.33.0.

ip route 0.0.0.0 0.0.0.0 192.168.100.2

либо если нужно в ручную отдельным маршрутом.

Статическая маршрутизация в вопросах и ответах

Этот краткий FAQ я составил, руководствуясь идеей необходимости вычленить из огромной области знаний, называемой “статическая IP-маршрутизация”, только те вопросы, которые действительно необходимо знать читателю рубрики, в которой помещена эта статья, то бишь, системному администратору.

В повседневной работе рядовой администратор систем, завязанных на LAN, сталкивается с вопросами маршрутизации лишь эпизодически. И, естественно, не имея достаточного времени, чтобы ясно увидеть задачу, он не может эффективно ее решить. Но маршрутизация – это инструмент чрезвычайно гибкий, и достаточно иметь десяток приемов, чтобы вчерашние проблемы превратить в приятную работу. Именно с такими приемами читатель сможет познакомиться, дочитав статью до конца.
Что касается динамической маршрутизации, могу лишь сказать, что это несколько другая тема, которая здесь не рассматривается, но которую невозможно понять, не зная основ в статике.
Ниже рассматриваются примеры, реализованные на ОС Linux. Если вы работаете на другой ОС, то необходимо лишь уточнить синтаксис команд и незначительные детали. Также для понимания поднимаемых вопросов необходимо хорошее понимание IP-адресации и начальные навыки в конфигурировании сетевых устройств.

вопрос 1

Почему хосты, интерфейсы которых имеют IP-адреса, принадлежащие разным логическим сетям, в некоторых случаях могут нормально взаимодействовать без дополнительной маршрутизации? Вот примеры подобных пар IP-адресов: 10.10.1.1/8 – 10.10.2.2/16, 192.168.5.1/16 – 192.168.5.2/24. Ведь в первом случае адреса сетей будут 10.0.0.0 и 10.10.0.0, во втором 192.168.0.0 и 192.168.5.0.

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

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

Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
Теперь посмотрим, подходит ли такая запись для пакета с адресом 10.10.2.2. Применим к этому адресу маску 255.0.0.0 из вышеприведенной записи. Получаем логическую сеть 10.0.0.0. Таким образом, пакет отправится на интерфейс eth0. А для получателя, IP-адрес отправителя пакета совершенно безразличен, и учитывается только при генерации ответа.

То же можно сказать и о хосте с интерфейсом, у которого IP-адрес 10.10.2.2/16. Применение маски 255.255.0.0 к IP адресу 10.10.1.1 даст логическую сеть 10.10.0.0. Маршрут на этом хосте для такой логической сети существует, и пакет с адресом назначения 10.10.1.1 будет отправлен именно по этому маршруту. Замечу, что это может быть ответ на пакет, пришедший с с хоста, рассмотренного первым. В результате получаем полноценный обмен пакетами.

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

То, что мы обсудили, имеет название. Supernetting – высвобождение адресов хостов за счет уменьшения количества сетей — метод, обратный выделению подсетей за счет уменьшения количества хостов (subnetting).

вопрос 2

У меня в LAN появился хост с “неподходящей” подсетью в IP-адресе, например, другого класса. Изменять этот IP-адрес нельзя. Что делать? Не менять же адреса у всех хостов, которые с ним работают?

Есть несколько методов решения этой проблемы.

Метод 1.
Самый простой инеэффективный
– добавить дополнительный IP-адрес с подходящей подсетью хосту, который инициирует коннекты. Здесь есть варианты. Можно установить дополнительный интерфейс и сконфигурировать его соответствующим образом. Проще добавить к интерфейсу так называемый alias. Это дополнительный IP-адрес, привязанный к интерфейсу и действующий наравне с основным. Следующая команда присваивает интерфейсу eth0 дополнительный IP адрес 172.16.1.1.

#ifconfig eth0:1 inet 172.16.1.1 netmask 255.255.0.0 broadcast 172.16.255.255
где eth0:x – название виртуальных интерфейсов, которые обслуживаются той же сетевой картой, что и интерфейс eth0. Указание broadcast в данном случае не обязательно, но если вы практикуете использование нестандартных масок, рекомендую взять в привычку указание этого параметра, т.к. по умолчанию принимается значение, соответствующее классу IP-адреса и часто не соответствует указанной маске.

Замечу, что при добавлении интерфейса с IP-адресом либо IP alias, всегда автоматически добавляется соответствующий маршрут в таблицу маршрутизации. Именно это обстоятельство позволяет решить нашу проблему.
Недостаток данного метода в необходимости конфигурирования большого количества клиентов.

Метод 2.
Можно добавить в хосты, инициирующие коннекты, соответствующий маршрут. Например. Клиентский хост имеет знакомый из предыдущего вопроса IP-адрес 10.10.2.2/16. Сервер имеет IP-адрес 172.16.1.200/16. Добавляем на клиентском хосте маршрут.

#route add –net 172.16.0.0 netmask 255.255.0.0 eth0
Тем самым мы указываем, что все пакеты, предназначенные для логической сети 172.16.0.0, нужно отправлять на интерфейс eth0. Этого достаточно, чтобы клиентский хост с IP-адресом 10.10.2.2/16 мог устанавливать сессии с сервером 172.16.1.200/16. Этот метод на самом деле мало отличается от первого:-)
/* Можно также использовать маршрут на отдельный хост (подробнее рассмотрен в вопросе 6). Если в приведенном выше примере не существенно, какую форму записи маршрута (на хост или на сеть) выбрать, есть ситуации, когда маршрут на хост является единственно возможным вариантом. Сразу пример: внутри нашей сети, использующей «нереальные» (fake) адреса, находится хост с реальным адресом, причем все остальные его собратья по IP-сети (подсети) находятся в другом месте (за шлюзом, например). В этом случае можно использовать только маршрут на хост. — прим. ред. */

Метод 3.
Может оказаться очень эффективным метод указания маршрута на шлюзе (благо он есть практически в любой организации), если клиентские рабочие станции уже настроены на него. На Рис. 1 показана такая ситуация. Многочисленные клиентские хосты (Cx) настроены на шлюз по умолчанию 10.10.99.99/16. Тогда на G1 добавляем маршрут, как это сделано в предыдущем пункте.

G1#route add –net 172.16.0.0 netmask 255.255.0.0 eth0

Тогда все пакеты хостов Сx к адресу 172.16.1.200/16 будут вначале перенаправляться на G1, потому что на Cx маршрута на сеть 172.16.0.0 нет и, следовательно, применяется маршрут по умолчанию (default) на 10.10.99.99, а затем с G1 согласно указанного нами маршрута на интерфейс, подключенный к внутренней LAN. Это может быть интерфейс eth0. А может быть и дополнительный eth2. И, наконец, с этого интерфейса пакеты попадают на S1 .

/* Кстати, если уж вводить на G1 дополнительный интерфейс, можно изменить и схему подключения G1 и S1, а именно: S1 включить напрямую в eth2 на G1, оставив последнему только одну точку подключения к LAN. С точки зрения network design’a это несколько корректней, особенно применительно к некоммутируемому Ethernet, хотя в каждом конкретном случае могут быть свои нюансы. — прим. ред. */

Вот результат применения команды tracert на Windows-машине C1 в описанном случае.

С1>tracert 172.16.1.200

Tracing route to 172.16.1.200 over a maximum of 30 hops

1 1 ms 2 1 ms

Trace complete.

Недостаток этого метода очевиден. Весь трафик будет проходить через G1, поэтому необходимо предусмотреть достаточную пропускную способность оборудования по всему маршруту следования трафика.

вопрос 3

Третий метод замечательно работает, но теперь S1 не видит клиентов Cx!

Все верно. Теперь посмотрим на S1 как клиента для Cx. Чего не хватает? Маршрута для сети 10.10.0.0 на S1. Добавляем.

S1#route add –net 10.10.0.0 netmask 255.255.0.0 eth0
На этот раз нет смысла заворачивать маршрут на G1, потому что есть возможность прописать маршрут сразу на S1, и только один раз.

вопрос 4

А если в обсуждаемой выше схеме хосту G1 присвоить дополнительный IP 172.16.x.x? Тогда нет необходимости прописывать маршрут?

Совершенно верно. Можно было на G1 не добавлять маршрут, а присвоить IP-адрес интерфейсу eth2, либо IP alias на eth0, как описано в методе 1 вопроса 2. Тогда остается добавить маршрут по умолчанию на наш законный шлюз (как это сделано на всех клиентах Cx) на сервере S1, чтобы он мог инициировать коннекты к Cx.

S1#route add default gw 10.10.99.99
Получаем еще одну полностью работающую схему. Думаю, здесь вопросов больше нет.

вопрос 5

Какие существуют способы диагностики, помогающие устранить ошибки в конфигурации маршрутов?

Выявление ошибок, на мой взгляд, удобно проводить, двигаясь от конечного интерфейса к начальному. Последовательный ping в таком направлении обычно сразу позволяет выявить этап, на котором застревают пакеты. Следует отметить опцию –R в команде ping. Она показывает маршрут движения пакета, подобно тому, как это делает команда traceroute. Для того, чтобы увидеть пришедший ICMP-пакет на интерфейс назначения может пригодится сетевой монитор, скажем, tcpdump. Например, команда

#tcpdump proto ICMP

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

Для проверки правильности прохождения пакетами маршрутов незаменимой остается traceroute. Напомню, что каждая строка (hop) означает изменение маршрута согласно таблиц маршрутизации. Первая строка обычно порождается таблицей маршрутизации хоста, с которого идет трассировка. Каждая последующая – прохождение маршрутизатора.

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

Отличной проверкой правильной работы канального уровня /* точнее, сопряжения канального уровня с сетевым — прим. ред. */ может служить наличие корректного MAC-адреса нужного интерфейса в ARP-кэше. Например.

source_host>ping –с 1
source_host>arp –a
Сверив полученный из кэша адрес с истинным адресом интерфейса (команда ifconfig),

target_host>ifconfig
можно сказать что, скорее всего, на канальном уровне все в порядке.

/* Когда ситуация в вашей сети еще не совсем «устаканилась», то бишь вы часто меняете адреса на некоторых хостах/интерфейсах, изучение ARP-кэша поможет вам отыскать самый что ни на есть классический глюк: если некий адрес только что принадлежал одному хосту и его переназначили другому, то MAC-адрес прежнего хозяина того IP-адреса, который вы столь усердно и безрезультатно пингуете, мог просто застрять в ARP-кэше. Пакеты уходят «вникуда», их там никто не ждет — старый владелец адреса может быть отключен или ему назначен другой адрес и он пытается смаршрутизировать пакеты… ерунда в общем полная:)

Очистить ARP-кэш (полностью или частично) можно с помощью команды arp –d. — прим. ред. */
В принципе, пяти команд – ifconfig, route, ping, arp, и traceroute хватает для решения любой задачи статической маршрутизации. Ну и сетевой анализатор, как было сказано выше, не помешает.

вопрос 6

Какие еще существуют записи для таблицы маршрутизации?

Пока мы применяли один тип маршрута – трафик логической подсети направлялся на интерфейс. Другой тип маршрута для выделения нужного трафика — это маршрут для указанного хоста. Т.е. есть возможность указать маршрут персонально для одного хоста (опция add -host), хотя применяется такая запись редко.

Это были виды маршрутов с точки зрения критериев принятия решения о выборе записи.
С точки зрения направления движения трафика помимо рассмотренного нами указания интерфейса есть возможность перенаправить пакеты на указанный IP-адрес шлюза (gateway). Тогда не учитывается конкретный IP-адрес, указанный в пакетах и, следовательно, принятие решения о цели пакетов откладывается до следующего маршрутизатора. Таких перенаправлений может быть сколь угодно много, и ограничено лишь значением TTL (Time To Live).

Частным случаем перенаправления на шлюз является запись default. Это запись для сети, имеющей значение 0.0.0.0, т.е. “вся сеть“. Правило для такого маршрута срабатывает, когда IP-адрес цели пакета не подходит ни под один из критериев, указанных в таблице маршрутизации. На практике маршрут по умолчанию следует настраивать на шлюз в Интернет. В этом есть практический смысл. Если хосты, которые запрашивает клиент, отсутствуют в LAN, то они могут быть в остальной сети, т.е. в Интернет.
В добавлении маршрута на конкретный IP-адрес есть одна особенность. Для IP-адреса шлюза уже должен существовать маршрут. Иначе неизвестно куда отправлять пакет. Поясню сказанное на примере. Сначала добавляем запись для сети 192.168.5.0, а затем уже запись для сети 172.16.0.0 на шлюз 192.168.5.1.

#route add –net 192.168.5.0 netmask 255.255.255.0 eth0
#route add –net 172.16.0.0 netmask 255.255.0.0 gw 192.168.5.1 eth0
вопрос 7

Моя LAN разделена на две большие части, которые соединены достаточно медленной (1Мбт/c) линией. Широковещательный трафик занимает значительную долю этой линии. Как мне разделить две эти сети на подсети, чтобы проходил трафик только с конкретными IP-адресами?

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

Рассмотрим конфигурацию приведенной схемы.
Верхняя часть.

G1#echo «1» >

R1#echo «1» > /proc/sys/net/ipv4/ip_forward

R1#route add default gw 10.10.99.99

Нижняя часть.

R2#echo «1» > /proc/sys/net/ipv4/ip_forward

На хостах G1, R1, R2 должен быть включен форвард пакетов между сетевыми адаптерами. Вписываем “1” в файл /proc/sys/net/ipv4/ip_forward, если это не сделано.

Множество клиентов Cx имеют настройку на шлюз G1 для всех неизвестных сетей (по умолчанию). Любой обращение к сетям, отличным от 10.10.0.0, обрабатывает G1. В случае, если идет обращение к сети 10.20.0.0, шлюз G1 перенаправляет это обращение к маршрутизатору R1. А маршрутизатор R1 перенаправляет на маршрутизатор R2. В свою очередь R2 непосредственно находится в сети 10.20.0.0. и направляет обращение к нужному клиенту.

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

Теперь посмотрим на движение ответа на рассмотренный запрос. Удаленные клиенты CRx имеют настройку по умолчанию на шлюз R2. IP-адрес хоста назначения будет относиться к сети 10.10.0.0 и, следовательно, ответ на запрос направится на R2. Здесь такой маршрут снова неизвестен, ответ перенаправлятся по маршруту по умолчанию, на R1, на котором есть интерфейс с подходящей сетью 10.10.0.0. Здесь ответ направляется сразу непосредственно на Cx, минуя шлюз G1, что нас вполне устраивает.

Рассмотрим движение запросов в Интернет всех клиентов Cx и CRx. Предполагаем, что запросы обрабатываются посредством Source network address translation (SNAT), и обеспечивается шлюзом G1. В верхней части клиенты Cx имеют простое подключение к Интернету посредством указания маршрута по умолчанию. Думаю, здесь все ясно. В нижней части клиенты имеют маршрут по умолчанию на шлюз R2. Попав на R2, запрос будет перенаправлен дальше опять по маршруту по умолчанию на R1. На R1 ситуация повторится, и запрос уйдет на шлюз в Интернет G1. Далее по назначению. Ответы на запрос пойдут по тому же маршруту в обратном направлении. Для этого на G1 и R1 уже предусмотрены маршруты для сети 10.20.0.0.
Если нужно в нижней части схемы добавить дополнительный шлюз G2 (10.20.99.99/16) с подключением клиентов CRx в Интернет, то просто зеркально отображаем конфигурацию из верхней части.

С1#route add default gw 10.10.99.99
G1#echo «1» > /proc/sys/net/ipv4/ip_forward
G1#route add –net 10.20.0.0 netmask 255.255.0.0 gw 10.10.99.98 eth2
R1#echo «1» > /proc/sys/net/ipv4/ip_forward
R1#route add –net 10.20.0.0 netmask 255.255.0.0 gw 172.17.1.2 eth2
R1#route add default gw 10.10.99.99

G2#echo «1» > /proc/sys/net/ipv4/ip_forward
G2#route add –net 10.10.0.0 netmask 255.255.0.0 gw 10.20.99.98 eth2
СR1#route add default gw 10.20.99.99
R2#echo «1» > /proc/sys/net/ipv4/ip_forward
R2#route add –net 10.10.0.0 netmask 255.255.0.0 gw 172.17.1.1 eth2
R2# route add default gw 10.20.99.99

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

С1#route add default gw 10.10.99.98
R1#echo «1» > /proc/sys/net/ipv4/ip_forward
R1#route add default gw 172.17.1.2
СR1#route add default gw 10.20.99.98
R2#echo «1» > /proc/sys/net/ipv4/ip_forward
R2# route add default gw 172.17.1.1
вопрос 8

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

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

Александр Мисюк, Alexter at tut.by.
Выражаю признательность шеф-редактору за существенное замечание и указание на допущенную мной ошибку в этом вопросе

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2

Всем привет ранее мы с вами установили службу маршрутизации и удаленного доступа в Windows Server 2008 R2, теперь с помощью нее мы настроим NAT. Преобразование сетевых адресов (NAT) позволяет преобразовывать адреса IP версии 4 (IPv4) компьютеров одной сети в IPv4-адреса компьютеров другой сети. IP-маршрутизатор с включенным NAT, связывающий частную сеть (например, корпоративную) с общедоступной (такой как Интернет), позволяет компьютерам в частной сети получать доступ к компьютерам в общедоступной сети с помощью данной службы преобразования.

Технология NAT была разработана как временное решение проблемы исчерпания IPv4-адресов. Количество глобально уникальных (общедоступных) IPv4-адресов слишком мало для стремительно растущего числа компьютеров, которым требуется доступ к Интернету. Хотя долгосрочное решение — разработка адресов IP версии 6 (IPv6) — существует, IPv6 еще не получил широкого распространения. Технология NAT позволяет компьютерам любой сети применять повторно используемые частные адреса для подключения к компьютерам, имеющим глобально уникальные общедоступные адреса в Интернете.

Итак у нас есть компьютер на котором есть интернет от провайдера и есть локальная сеть без интернета, нужно раздать интернет всем компьютерам локальной сети имея только компьютер с двумя сетевыми адаптерами. Имеем две сетевые карты LAn локальная сеть и Wan интернет. Этот интернет мы раздадим всем.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-00

Есть тестовый сервер с Debian 7. Смотрим его сетевые параметры командой ifconfig, видим что у него только локальная сеть есть.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-02

Сделаем команду ping ya.ru видим, что хост не найдет, другими словами инета нет.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-03

Открываем на нашем сервере Пуск-Администрирование-Маршрутизация и удаленный доступ.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-04

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

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-05

Щелкаем правым кликом по серверу и выбираем Настроить и включить маршрутизацию и удаленный доступ.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-06

Откроется мастер установки сервера маршрутизации и удаленного доступа.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-07

В данном окне мы с вами выберем NAT, обратите внимание что еще есть VPN сервер и Безопасное соединение между двумя частными сетями.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-08

Затем нужно указать сеть с интернетом, которая и будет натить другую.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-09

Готово.

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-11

Все сервер настроен

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-12

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

Как настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2-13

Вот так вот просто настроить NAT между двумя сетями с помощью службы маршрутизации и удаленного доступа в Windows Server 2008 R2.

Материал сайта pyatilistnik.org

CCNA RSE 6.3.2.4 Лабораторная работа — Настройка межинтерфейсной маршрутизации между VLAN

CCNA RSE 6.3.2.4 Лабораторная работа — Настройка межинтерфейсной маршрутизации между VLAN

6.3.2.4 Лабораторная работа — Настройка ответов по межинтерфейсной маршрутизации между Vlan

Топология

Таблица адресации

Цели
Часть 1: Создание сети и настройка основных параметров устройства
Часть 2: Настройка коммутаторов с VLAN и транкингом
Часть 3: Проверка транкинга, VLAN, маршрутизации и подключения

Предпосылки / сценарий
Устаревшая маршрутизация между VLAN редко используется в современных сетях; тем не менее, полезно настроить и понять этот тип маршрутизации, прежде чем переходить к маршрутизации между VLAN-маршрутизаторами (на основе магистрали) или настройке коммутации уровня 3.Кроме того, вы можете столкнуться с межинтерфейсной маршрутизацией между VLAN в организациях с очень маленькими сетями. Одним из преимуществ устаревшей маршрутизации между VLAN является простота настройки. В этой лабораторной работе вы настроите один маршрутизатор с двумя коммутаторами, подключенными через интерфейсы Gigabit Ethernet маршрутизатора. На коммутаторах будут настроены две отдельные VLAN, и вы настроите маршрутизацию между VLAN.

Примечание : Эта лабораторная работа предоставляет минимальную помощь с фактическими командами, необходимыми для настройки маршрутизатора и коммутаторов.Необходимые команды настройки коммутатора VLAN приведены в Приложении A этой лабораторной работы. Проверьте свои знания, пытаясь настроить устройства, не обращаясь к приложению.

Примечание : Маршрутизаторы, используемые в практических занятиях CCNA, — это маршрутизаторы с интегрированными сервисами (ISR) Cisco 1 941 с Cisco IOS, выпуск 1 5.2 (4) M3 (образ universalalk9). Используемые коммутаторы: Cisco Catalyst 2960 с Cisco IOS, выпуск 1 5.0 (2) (образ lanbasek9). Могут использоваться другие маршрутизаторы, коммутаторы и версии Cisco IOS.В зависимости от модели и версии Cisco IOS доступные команды и полученные выходные данные могут отличаться от того, что показано в лабораторных работах. Правильные идентификаторы интерфейсов см. В сводной таблице интерфейсов маршрутизатора в конце этой лабораторной работы.

Примечание : Убедитесь, что маршрутизаторы и коммутаторы были стерты и не имеют конфигураций запуска. Если вы не уверены, обратитесь к своему инструктору.

Примечание для инструктора : Обратитесь к руководству инструктора по лаборатории для получения информации о процедурах инициализации и перезагрузки устройств.

Необходимые ресурсы

• 1 Маршрутизатор (Cisco 1941 с универсальным образом Cisco IOS версии 15.2 (4) M3 или аналогичный)
• 2 коммутатора (Cisco 2960 с Cisco IOS версии 15.0 (2) образ lanbasek9 или аналогичный)
• 2 ПК (Windows 7, Vista или XP с программой эмуляции терминала, например Tera Term)
• Консольные кабели для настройки устройств Cisco IOS через консольные порты
• Кабели Ethernet, как показано в топологии
  

Часть 1: Построение сети и настройка основных параметров устройства

В части 1 вы настроите топологию сети и при необходимости очистите все конфигурации.
Шаг 1: Подключите сеть, как показано в топологии.
Шаг 2: Инициализируйте и перезагрузите маршрутизатор и коммутаторы.
Шаг 3. Сконфигурируйте базовые настройки для R1.

а. Консоль в R1 и войдите в режим глобальной конфигурации.

г. Скопируйте следующую базовую конфигурацию и вставьте ее в рабочую конфигурацию на R1.

нет IP-поиска домена
имя хоста R1
сервисное шифрование паролей
включить секретный класс
баннер motd #
Несанкционированный доступ строго запрещен.#
линия con 0
пароль cisco
авторизоваться
регистрация синхронная
строка vty 0 4
пароль cisco
логин

г.Настройте адресацию на G0 / 0 и G0 / 1 и включите оба интерфейса.
г. Скопируйте текущую конфигурацию в конфигурацию запуска.

Шаг 4: Настройте базовые параметры на обоих коммутаторах.
а. Консоль в коммутатор и войдите в режим глобальной конфигурации.
г. Скопируйте следующую базовую конфигурацию и вставьте ее в рабочую конфигурацию коммутатора.

нет IP-поиска домена
сервисное шифрование паролей
включить секретный класс
баннер motd #
Несанкционированный доступ строго запрещен.#
Линия кон 0
пароль cisco
авторизоваться
регистрация синхронная
строка vty 0 15
пароль cisco
авторизоваться
выход

г.Настройте имя хоста, как показано в топологии.
г. Скопируйте текущую конфигурацию в конфигурацию запуска.

Шаг 5: Сконфигурируйте базовые настройки на ПК-А и ПК-В.
Настройте ПК-A и ПК-B с IP-адресами и адресом шлюза по умолчанию в соответствии с таблицей адресации.

Часть 2: Настройка коммутаторов с VLAN и транкингом

В части 2 вы настроите коммутаторы с VLAN и транкингом.

Шаг 1. Настройте VLAN на S1.
а. На S1 создайте VLAN 10. Назначьте Student как имя VLAN.
г. Создайте VLAN 20. Назначьте Faculty-Admin как имя VLAN.
г. Настройте F0 / 1 как магистральный порт.
г. Назначьте порты F0 / 5 и F0 / 6 для VLAN 10 и настройте F0 / 5 и F0 / 6 как порты доступа.
e. Назначьте IP-адрес VLAN 10 и включите его. См. Таблицу адресации.
ф. Настройте шлюз по умолчанию в соответствии с таблицей адресации.

Шаг 2: Настройте VLAN на S2.
а. На S2 создайте VLAN 10. Назначьте Student как имя VLAN.
г. Создайте VLAN 20. Назначьте Faculty-Admin как имя VLAN.
г. Настройте F0 / 1 как магистральный порт.
г. Назначьте порты F0 / 11 и F0 / 18 для VLAN 20 и настройте F0 / 11 и F0 / 18 как порты доступа.
e. Назначьте IP-адрес VLAN 10 и включите его. См. Таблицу адресации.
ф. Настройте шлюз по умолчанию в соответствии с таблицей адресации.

Часть 3: Проверка транкинга, виртуальных локальных сетей, маршрутизации и подключения

Шаг 1. Проверьте таблицу маршрутизации R1.
а. На маршрутизаторе R1 введите команду show ip route . Какие маршруты указаны на R1?
Сети 192.168.10.0/24 и 192.168.20.0/24 перечислены на R1.

R1 # показать IP-маршрут
* 25 марта, 15: 05: 00.003:% SYS-5-CONFIG_I: настраивается с консоли с помощью консоли
Коды: L — локальный, C — подключенный, S — статический, R — RIP, M — мобильный, B — BGP.
D — EIGRP, EX — EIGRP external, O — OSPF, IA — внутренняя область OSPF
N1 — OSPF NSSA внешний тип 1, N2 — OSPF NSSA внешний тип 2
E1 — OSPF внешний тип 1, E2 — OSPF внешний тип 2
i — IS-IS, su — сводка IS-IS, L1 — IS-IS уровень-1, L2 — IS-IS уровень-2
ia — внутренняя область IS-IS, * — кандидат по умолчанию, U — статический маршрут для каждого пользователя
o — ODR, P — периодически загружаемый статический маршрут, H — NHRP, l — LISP
+ — реплицированный маршрут,% — переопределение следующего перехода
Шлюз последней инстанции не установлен
192.168.10.0 / 24 имеет переменные подсети, 2 подсети, 2 маски
C 192.168.10.0/24 подключен напрямую, GigabitEthernet0 / 1
L 192.168.10.1/32 подключен напрямую, GigabitEthernet0 / 1
192.168.20.0/24 имеет переменные подсети, 2 подсети, 2 маски
C 192.168.20.0/24 подключен напрямую, GigabitEthernet0 / 0
L 192.168.20.1/32 подключен напрямую, GigabitEthernet0 / 0

г. На обоих S1 и S2 введите команду show interface trunk .Установлен ли порт F0 / 1 на обоих коммутаторах на магистраль
? ______ Есть

г. Выполните команду show vlan Short как на S1, так и на S2. Убедитесь, что сети VLAN 10 и 20 активны, и что правильные порты на коммутаторах находятся в правильных сетях VLAN. Почему F0 / 1 не указан ни в одной из активных VLAN?
Это магистральный порт, он не назначен VLAN.

г. Эхо-запрос от ПК-A в VLAN 10 к ПК-B в VLAN 20. Если маршрутизация между VLAN работает правильно, эхо-запросы между 192.168.10.0 и 192.168.20.0 должны быть успешными.

Примечание : Может потребоваться отключить брандмауэр ПК для проверки связи между ПК.

e. Проверьте связь между устройствами. Вы должны иметь возможность пинговать между всеми устройствами. Устраните неполадки, если вам это не удалось.

Reflection
В чем преимущество использования устаревшей маршрутизации между VLAN?
Ответы могут отличаться. Настройка маршрутизатора и коммутаторов относительно проста и понятна.На маршрутизаторе не требуются субинтерфейсы, и НЕ нужно настраивать транкинг между маршрутизатором и коммутатором.

Сводная таблица интерфейсов маршрутизатора

Приложение A: Команды конфигурации

Коммутатор S1

S1 (конфигурация) # vlan 10
S1 (config-vlan) # имя Студент
S1 (config-vlan) # выход
S1 (конфигурация) # vlan 20
S1 (config-vlan) # имя Факультет-Администратор
S1 (config-vlan) # выход
S1 (config) # интерфейс f0 / 1
S1 (config-if) # магистраль режима switchport
S1 (config-if) # диапазон интерфейса f0 / 5 — 6
S1 (config-if-range) # доступ в режиме switchport
S1 (config-if-range) # switchport access vlan 10
S1 (config-if-range) # интерфейс vlan 10
S1 (config-if) # IP-адрес 192.168.10.11 255.255.255.0
S1 (config-if) # не закрывать
S1 (config-if) # выход
S1 (config) # IP-шлюз по умолчанию 192.168.10.1

Переключатель S2

S2 (конфигурация) # vlan 10
S2 (config-vlan) # имя Студент
S2 (config-vlan) # выход
S2 (конфигурация) # vlan 20
S2 (config-vlan) # имя Факультет-Администратор
S2 (config-vlan) # выход
S2 (config) # интерфейс f0 / 1
S2 (config-if) # магистраль режима switchport
S2 (config-if) # интерфейс f0 / 11
S2 (config-if) # доступ к режиму switchport
S2 (config-if) # switchport access vlan 20
S2 (config-if) # интерфейс f0 / 18
S2 (config-if) # доступ к режиму switchport
S2 (config-if) # switchport access vlan 20
S2 (config-if-range) # interface vlan 10 & lt

.

CCNA RSE 6.3.3.7 Лабораторная работа — настройка ответов по маршрутизации между Vlan на основе магистрали 802.1Q

CCNA RSE 6.3.3.7 Лабораторная работа — Настройка ответов 802.1Q для маршрутизации между Vlan на основе магистрали

Топология

Таблица адресации

Характеристики назначения портов коммутатора

Цели
Часть 1: Построение сети и настройка основных параметров устройства
Часть 2: Настройка коммутаторов с VLAN и транкингом
Часть 3: Настройка маршрутизации между VLAN на основе магистрали

Предпосылки / сценарий
Второй метод обеспечения маршрутизации и подключения для нескольких VLAN — это использование 802.Магистраль 1Q между одним или несколькими коммутаторами и одним интерфейсом маршрутизатора. Этот метод также известен как маршрутизация между VLAN-маршрутизаторами. В этом методе интерфейс физического маршрутизатора разделен на несколько подынтерфейсов, которые обеспечивают логические пути ко всем подключенным VLAN.

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

Примечание : Эта лабораторная работа предоставляет минимальную помощь с фактическими командами, необходимыми для настройки маршрутизации между VLAN на основе магистрали.Однако необходимые команды настройки приведены в Приложении А к этой лабораторной работе. Проверьте свои знания, пытаясь настроить устройства, не обращаясь к приложению.

Примечание : Маршрутизаторы, используемые в практических лабораторных работах CCNA, — это маршрутизаторы с интегрированными сервисами (ISR) Cisco 1 941 с Cisco IOS, выпуск 1 5.2 (4) M3 (образ universalalk9). Используемые коммутаторы: Cisco Catalyst 2960 с Cisco IOS, выпуск 1 5.0 (2) (образ lanbasek9). Могут использоваться другие маршрутизаторы, коммутаторы и версии Cisco IOS.В зависимости от модели и версии Cisco IOS доступные команды и полученные выходные данные могут отличаться от того, что показано в лабораторных работах. Правильные идентификаторы интерфейсов см. В сводной таблице интерфейсов маршрутизатора в конце лабораторной работы.

Примечание : Убедитесь, что маршрутизаторы и коммутаторы были стерты и не имеют конфигураций запуска. Если вы не уверены, обратитесь к своему инструктору.

Примечание для инструктора : Процедуры инициализации и перезагрузки устройств см. В Руководстве по лабораторной работе для инструктора.

Необходимые ресурсы

• 1 Маршрутизатор (Cisco 1941 с Cisco IOS, выпуск 15.2 (4) универсальный образ M3 или аналогичный)
• 2 коммутатора (Cisco 2960 с Cisco IOS, версия 15.0 (2), образ lanbasek9 или аналогичный)
• 2 ПК (Windows 7, Vista или XP с программой эмуляции терминала, например Tera Term)
• Консольные кабели для настройки устройств Cisco IOS через консольные порты
• Кабели Ethernet, как показано в топологии
  

Часть 1. Создание сети и настройка основных параметров устройства

В Части 1 вы настроите топологию сети и сконфигурируете основные параметры на хостах ПК, коммутаторах и маршрутизаторе.

Шаг 1: Подключите сеть, как показано в топологии.
Шаг 2: Настройте хосты ПК.
Шаг 3. Инициализируйте и перезагрузите маршрутизатор и коммутаторы при необходимости.
Шаг 4. Настройте основные параметры для каждого коммутатора.
а. Консоль в коммутатор и войдите в режим глобальной конфигурации.
г. Скопируйте следующую базовую конфигурацию и вставьте ее в рабочую конфигурацию коммутатора.

нет IP-поиска домена
сервисное шифрование паролей
включить секретный класс
баннер motd #
Несанкционированный доступ строго запрещен.#
линия con 0
пароль cisco
авторизоваться
регистрация синхронная
строка vty 0 15
пароль cisco
авторизоваться
выход

г.Настройте имя устройства, как показано в топологии.
г. Настройте IP-адрес, указанный в таблице адресации для VLAN 1 на коммутаторе.
e. Настройте шлюз по умолчанию на коммутаторе.
ф. Административно деактивируйте все неиспользуемые порты на коммутаторе.
г. Скопируйте текущую конфигурацию в конфигурацию запуска.

Шаг 5. Настройте основные параметры маршрутизатора.
а. Подключите консоль к маршрутизатору и войдите в режим глобальной конфигурации.
г.Скопируйте следующую базовую конфигурацию и вставьте ее в рабочую конфигурацию маршрутизатора.

нет IP-поиска домена
имя хоста R1
сервисное шифрование паролей
включить секретный класс
баннер motd #
Несанкционированный доступ строго запрещен. #
Линия кон 0
пароль cisco
авторизоваться
регистрация синхронная
строка vty 0 4
пароль cisco
логин

г. Настройте IP-адрес Lo0, как показано в таблице адресов. Не настраивайте субинтерфейсы в настоящее время. Они будут настроены в Части 3.
d. Скопируйте текущую конфигурацию в конфигурацию запуска.

Часть 2: Настройка коммутаторов с VLAN и транкингом

В части 2 вы настроите коммутаторы с VLAN и транкингом.

Примечание : Необходимые команды для Части 2 представлены в Приложении A. Проверьте свои знания, попытавшись настроить S1 и S2, не обращаясь к приложению.

Шаг 1. Настройте VLAN на S1.
а. На S1 настройте VLAN и имена, перечисленные в таблице спецификаций назначения портов коммутатора. Напишите используемые вами команды в отведенном для этого месте.

S1 (конфигурация) # vlan 10
S1 (config-vlan) # имя Студенты
S1 (config-vlan) # vlan 20
S1 (config-vlan) # название факультета
S1 (config-vlan) # выход

г.На S1 настройте интерфейс, подключенный к R1, как магистраль. Также настройте интерфейс, подключенный к S2, как транк. Напишите используемые вами команды в отведенном для этого месте.

S1 (config) # интерфейс f0 / 5
S1 (config-if) # магистраль режима switchport
S1 (config-if) # интерфейс f0 / 1
S1 (config-if) # магистраль режима коммутации

г.На S1 назначьте порт доступа для ПК-A для VLAN 10. Запишите используемые вами команды в отведенном для этого месте.

S1 (config) # интерфейс f0 / 6
S1 (config-if) # доступ к режиму switchport
S1 (config-if) # switchport access vlan 10

Шаг 2. Настройте VLAN на коммутаторе 2.
а. На S2 настройте VLAN и имена, перечисленные в таблице спецификаций назначения портов коммутатора.
г. На S2 убедитесь, что имена и номера VLAN совпадают с именами и номерами на S1. Напишите команду, которую вы использовали, в отведенном для этого месте.

S2 # показать краткое описание vlan
S2 # показать краткое описание vlan
Имя VLAN Статус Порты
—- ——————————— ——— —— —————————
1 активен по умолчанию Fa0 / 1, Fa0 / 2, Fa0 / 3, Fa0 / 4, Fa0 / 5
Fa0 / 6, Fa0 / 7, Fa0 / 8, Fa0 / 9
Fa0 / 10, Fa0 / 11, Fa0 / 12, Fa0 / 13
Fa0 / 14, Fa0 / 15, Fa0 / 16, Fa0 / 17
Fa0 / 18, Fa0 / 19, Fa0 / 20, Fa0 / 21
Fa0 / 22, Fa0 / 23, Fa0 / 24, Gi0 / 1
Gi0 / 2
10 студентов активно
20 Факультет активен
1002 fddi-default активен
1003 token-ring-default активен
1004 fddinet-default активен
1005 trnet-default активен

г.На S2 назначьте порт доступа ПК-B для VLAN 20.
d. На S2 настройте интерфейс, подключенный к S1, как магистраль.

Часть 3: Настройка маршрутизации между VLAN на основе магистрали

В части 3 вы настроите маршрутизатор R1 для маршрутизации к нескольким VLAN, создав подынтерфейсы для каждой VLAN. Этот метод маршрутизации между VLAN называется маршрутизатором на палке.

Примечание : Необходимые команды для Части 3 представлены в Приложении A. Проверьте свои знания, попытавшись настроить маршрутизацию между VLAN на основе магистрали или маршрутизатора на палке, не обращаясь к приложению.

Шаг 1. Настройте подинтерфейс для VLAN 1.
а. Создайте субинтерфейс на R1 G0 / 1 для VLAN 1, используя 1 в качестве идентификатора субинтерфейса. Напишите команду, которую вы использовали, в отведенном для этого месте.

R1 (config) # интерфейс g0 / 1.1

г. Настройте подинтерфейс для работы в VLAN 1.Напишите команду, которую вы использовали, в отведенном для этого месте.

R1 (config-subif) # точка инкапсуляции 1Q 1

г. Настройте подинтерфейс с IP-адресом из таблицы адресов. Напишите команду, которую вы использовали, в отведенном для этого месте.

R1 (config-subif) # IP-адрес 192.168.1.1 255.255.255.0

Шаг 2. Настройте подинтерфейс для VLAN 1 0.
a. Создайте субинтерфейс на R1 G0 / 1 для VLAN 10, используя 1 0 в качестве идентификатора субинтерфейса.
г. Настройте подинтерфейс для работы в VLAN 1 0.
г. Настройте субинтерфейс с адресом из таблицы адресов.

Шаг 3. Настройте подинтерфейс для VLAN 20.
a. Создайте субинтерфейс на R1 G0 / 1 для VLAN 20, используя 20 в качестве идентификатора субинтерфейса.
г. Настройте подинтерфейс для работы в VLAN 20.
c. Настройте субинтерфейс с адресом из таблицы адресов.

Шаг 4. Включите интерфейс G0 / 1.
Включите интерфейс G0 / 1. Напишите используемые вами команды в отведенном для этого месте.

.