Создание избыточности с помощью маршрутизации вызова по требованию

Опубликовано: 24 Марта, 2023

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


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


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


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


Хотя в целом это хорошее решение, есть некоторые проблемы, которые необходимо рассмотреть перед реализацией такого проекта. Для начала, если вы используете для связи выделенные линии, то такая схема будет дороже, чем схема без резервирования. Если бы воображаемая компания, которую я только что описал, использовала топологию «звезда» без резервирования (главный офис имеет соединение с A, B и C), то потребовалось бы в общей сложности три выделенных линии. Напротив, описанная ранее топология с резервным кольцом потребует четырех арендованных линий. Учитывая стоимость арендованных линий, разница в стоимости между двумя проектами может быть существенной.


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


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


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


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


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


Я понимаю, что в некоторых организациях низкая скорость маршрута дозвона по требованию может стать серьезной проблемой даже в чрезвычайной ситуации. К счастью, есть некоторые вещи, которые можно сделать, чтобы ускорить маршрут дозвона по требованию. Одним из вариантов является использование многоканального. Multilink — это технология, которая распределяет пакеты по нескольким модемам и нескольким телефонным линиям для достижения более высокой пропускной способности, чем обычно достигается при коммутируемом соединении. Другой вариант — использовать ISDN-соединение. ISDN (цифровая сеть с интегрированными услугами) — это цифровая телефонная линия, которая может устанавливать сеансы коммутируемого доступа со скоростью до 128 Кбит/с.


Преимущество маршрутизации по требованию заключается в том, что даже если ваш маршрутизатор ее не поддерживает, она все равно доступна для вас. Вы можете настроить Windows 2000 или Windows 2003 Server для работы в качестве маршрутизатора вызова по требованию. Если вы выберете этот маршрут, вам потребуется сервер на каждом конце соединения WAN. Один сервер будет выступать в роли маршрутизатора для набора номера, а другой — в качестве отвечающего маршрутизатора.


Настройка маршрутизатора набора номера


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


Чтобы настроить вызывающий маршрутизатор, откройте консоль маршрутизации и удаленного доступа (RRAS) Windows Server 2003, выбрав ее в меню «Администрирование» сервера. То, что вы будете делать дальше, действительно зависит от того, активен ли в данный момент RRAS на сервере или нет. Для целей этой статьи я предполагаю, что RRAS в настоящее время не используется.


Когда откроется консоль RRAS, вы увидите свой сервер в списке под разделом «Состояние сервера». Щелкните правой кнопкой мыши на своем сервере и выберите параметр «Настроить и включить маршрутизацию и удаленный доступ» в контекстном меню. Теперь Windows запустит мастер установки RRAS. Щелкните Далее, чтобы пропустить экран настройки мастера. Теперь вы увидите экран с вопросом, для какой роли вы хотите, чтобы мастер настроил RRAS. Маршрутизация вызова по требованию не указана на этом экране, поэтому вместо этого выберите параметр «Пользовательская конфигурация» и нажмите «Далее». Теперь вы увидите другой экран с вопросом, какие службы вы хотите настроить на сервере. Установите флажок «Соединение по требованию» и нажмите «Далее», а затем «Готово». Теперь вы увидите сообщение о том, что RRAS установлен. Далее в сообщении спрашивается, хотите ли вы запустить службу RRAS. Нажмите Да, и вы в деле.


Теперь, когда первоначальная установка завершена, вы должны настроить интерфейс вызова по требованию. Для этого перейдите по дереву консоли к контейнеру «Сетевые интерфейсы» под вашим сервером. Щелкните правой кнопкой мыши контейнер «Сетевые интерфейсы» и выберите команду «Новый интерфейс вызова по требованию» в появившемся контекстном меню. Когда вы это сделаете, Windows запустит мастер интерфейса вызова по требованию. Нажмите «Далее», чтобы пропустить вводный экран.


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


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


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


Нажмите «Далее», и вы увидите экран, в котором вас спросят, какие задачи вы хотите выполнить, чтобы завершить настройку. По крайней мере, вы должны выбрать опцию Route IP Packets on This Interface. Я также рекомендую использовать простой текстовый пароль. Да, я знаю, что простые текстовые пароли представляют угрозу безопасности, но Windows не будет использовать обычный текстовый пароль, если только она не сможет подключиться каким-либо другим способом. На мой взгляд, если ситуация сбоя настолько серьезна, что устанавливается маршрут набора по требованию, то последнее, чего вы хотите, — это сбой маршрута набора по требованию только из-за несовместимого формата пароля.


В этот момент вы увидите экран, который запрашивает IP-адрес маршрутизатора, к которому вы будете подключаться. Нажмите «Далее» после ввода этой информации, и вам будет предложено ввести набор учетных данных для исходящих звонков. Причина, по которой необходимы учетные данные для набора номера, заключается в том, что отвечающий маршрутизатор является не чем иным, как сервером удаленного доступа. Как вы, возможно, знаете, Windows требует, чтобы пользователи, подключающиеся к серверу удаленного доступа, имели разрешения на подключение к этому серверу. Маршрутизатор вызова по требованию не совсем типичный клиент Windows, но отвечающий маршрутизатор не знает об этом. Это потребует от маршрутизатора набора по требованию предоставить набор учетных данных для аутентификации, как и для любого другого пользователя. Мой совет — создать специальную учетную запись, единственными разрешениями которой является вход на сервер удаленного доступа. Затем вы можете использовать эту учетную запись для маршрутизатора вызова по требованию. Просто не забудьте настроить учетную запись так, чтобы ее пароль никогда не истекал, иначе вас может ожидать неприятный сюрприз в один прекрасный день, когда маршрутизатору потребуется установить соединение. Нажмите «Далее», а затем «Готово», и интерфейс вызова по требованию готов к работе.


Вывод


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