Несколько PPP--интерфейсов и Kerio Control на Windows 2008 R2 Server.
В чем проблема?
Известно, что в ОС Windows есть определенные сложности в работе с виртуальными интерфейсами типа РРРоЕ, РРТР и проч.. С ними не работает драйвер WinPCAP, как следствие - многие сетевые утилиты - даже nmap, и т.д.. В том числе - есть проблемы в работе Kerio Control практически всех версий, о чем сами кериоты говорят громко, обвиняя Гейтса, и сами гейтсята не скрывают проблему, милостиво выпуская пачти и подчеркивая - это для тупых разработчиков приложений. Однако, имхо, главная проблема не в драйверах и проч. высоких понятиях, а в непонимании большинством пользователей принципов настройки таких соединений и, как следствие - неспособности правильно использовать такие соединения. Поэтому, не сбрасывая со счетов реальные ограничения в работе драйверов, попробуем разобраться в самых-самых основах настройки РРР-интерфейсов для их использования в Kerio Control.
Поставим задачу.
Дано: физический хост с установленной ОС Windows Server 2008 R2 Standard SP1 и Kerio Control 7.4.2 на нем; три физических сетевых интерфейса для трех разных сетей; два провайдера - один предоставляет PPPoE-подключение для выхода в инет, второй - выход в собственную локальную сеть (с доступом в инет - серый адрес) и дополнительно -- белый адрес через VPN-соединение; локальная сеть с доменом АД и своим ДНС-сервером; виртуальная сеть Hyper-V на самом хосте с Kerio Control.
Требуется: обеспечить доступ к Интернет через все три канала с распределением нагрузки для имеющейся локальной сети, включая сеть Hyper-V; обеспечить удаленный доступ к некоторым ресурсам локальной сети из сети Интернет.
Оценим ситуацию.
1. Нам требуется создать виртуальную сеть на основе всех трех сетевых интерфейсов. Здесь трудностей нет - используем штатную оснастку Диспетчера сервера для создания такой сети. При этом заметим, что такое решение явно избыточно - ресурсам локальной сети не требуются интерфейсы с выходов в инет, но мы просто заложим возможность в дальнейшем разворачивать виртуальные машины с возможностью маршрутизации. Например, тот же Kerio Control можно было бы разворачивать не на самом хосте, а на виртуальной машине. Здесь главным аргументом для выбора места установки Kerio Control является наличие физических ресурсов - прежде всего ОЗУ - на хостовой машине: Kerio Control использует заведомо меньше памяти, чем виртуальная машина с ним. Мы пойдем - как всегда - самым трудным путем и оставим Kerio Control на хостовой машине.
2. Первый провайдер (мы возьмем совершенно реальных провайдеров) DOM.RU предоставляет доступ к Интернет через PPPoE-соединение: к нам приходит сетевой кабель без использования протокола TCP (а значит - без локальных ресурсов сети провайдера) и выдается пара логин\пароль для подключения к серверу провайдера. Мы получаем по созданному подключению по DHCP динамический белый IP-адрес в сети Интернет. Скорость - до 50 Мбит\сек.
3. Второй провайдер - Информсвязь-Черноземье - предоставляет более продвинутый способ доступа к сети Интернет. К нам приходит сетевой кабель локальной сети провайдера и мы получаем по DHCP серый адрес этой сети с доступом в Интернет через шлюз провайдера - т.е. мы работаем через НАТ и в Интернет мы выходим с белым адресом шлюза провайдера (вся его локальная сеть под одним адресом) - так и Керио работает. Этот способ односторонний - мы в инет выходим. но из инета к нам доступа провайдер так просто не предоставит (по аналогии с Керио - МАП не предоставляется). Скорость - до 100 Мбит\сек. Для получения удаленного доступа к нам из инета провайдер обеспечивает VPN-подключение через свою же локальную сеть (ту, к которой мы подключены) с предоставлением нам по DHCP собственного белого адреса в Интернет. Скорость - до 70 Мбит\сек.
4. Локальная сеть никаких особенностей не имеет - наш Керио есть шлюз в этой сети, ДНС-сервер - это контроллер домена (или любой другой ДНС-сервер на Windows - или вообще любой другой сервер). Естественно, адрес шлюза в сети статический серый. Скорость - 1 Гбит\сек.
Сделаем выводы из оценки ситуации.
1. Мы имеем три соединения TCP\IP с выставленным по DHCP маршрутом по умолчанию: локальная сеть провайдера Информсвязь (будем называть его FREEDOM), его же VPN-канал и PPPoE-канал провайдера DOM.RU. ОС Windows тут же сообщит нам о возможной проблеме с несколькими шлюзами по умолчанию - примем к сведению.
2. Поскольку у нас несколько исходящих интерфейсов, нам надо выбрать вариант подключения к Интернету для Kerio Control. Учитываем, что нам надо обеспечить и автоматическое переключение при отказе одного из провайдеров, и распределение нагрузки при штатной работе обоих провайдеров. Особенность - отказ локальной сети провайдера FREEDOM означает отказ и VPN-соединения, но не обратное. Отказ VPN от FREEDOM означает потерю удаленного доступа из инета через этого провайдера. Отказ провайдера DOM.RU не означает ничего, кроме факта его недоступности - потерю удаленного доступа через этого провайдера. Мы знаем, что вне зависимости от варианта подключения работают и доступны все интерфейсы в Керио, поэтому выбираем вариант подключения РЕЗЕРВИРОВАНИЕ с назначением основным каналом VPN от FREEDOM, резервным - PPPoE от DOM.RU. Керио поддерживает только два канала для резервирования, поэтому оставшийся канал - НАТ через локальную сеть от FREEDOM - мы задействуем через назначение постоянных маршрутов для некоторых ресурсов. Сетевой интерфейс, через который подключен DOM.RU, нами вообще не используется.
3. Для снижения ненужного (и потенциально опасного) трафика установим ограничения: на всех (кроме локальной сети) интерфейсах отключим протоколы Microsoft, отключим протокол IPv6, отключим NetBios. На интерфейсе, через который включено PPPoE от DOM.RU отключим и протокол IPv4.
4. Локальный ДНС-сервер настроим на прослушивание всех интерфейсов и укажем в качестве серверов пересылки все ДНС-сервера наших провайдеров. Проверим правильность его настройки и будем указывать его адрес для всех наших не РРР интерфейсов.
В целом ситуация ясна и проста - нам надо создать в дополнение к уже имеющимся интерфейсам новые PPPoЕ и VPN -подключения и подкорректировать их параметры. При этом мы должны использовать как инструменты ОС, так и инструменты Kerio Control. Замечание: безусловно, инструменты Kerio Control - это всего лишь настройка над ОС, но мы будем использовать готовенькое, не забивая себе голову высоким полетом cкриптомании линуксоидов :)
ВНИМАНИЕ: мы сейчас рассматриваем ситуацию, которую в жизни надо стараться всячески избегать: не устанавливать Керио на хостовой машине - использовать виртуалку, не поднимать РРР-соединения непосредственно на Керио - использовать модемы, не поднимать несколько РРР-соединений на одном хосте - опять же разнести их по модемам. Но жизнь оказывается сложнее всяких советов и потому рассматриваемая ситуация - не исключение. Кроме того, мы рассматриваем работу Керио на ОС Windows - на линуксовых ОС поведение Керио будет несколько отличаться в части управления маршрутами, но это отдельный вопрос.
Эта страница расположена в закрытой зоне сайта, доступ к которой ограничен.
Подробности смотреть здесь.
Удачи !
