Анализ программных решений для создания интернет-шлюзов. Как раздать интернет на все компьютеры локальной сети средствами Windows

Применимо к:Windows Server 2012 R2

В этом разделе, предназначенном для специалистов в сфере информационных технологий (ИТ), представлена общая информация о шлюзе Windows Server, в частности о возможностях и характеристиках шлюза Windows Server.

Кто может заинтересоваться шлюзом Windows Server?

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

Вы используете или планируете использовать System Center 2012 R2, что является обязательным условием для развертывания шлюза Windows Server.

Вы проектируете или поддерживаете ИТ-инфраструктуру для организации, которая использует или планирует использовать технологию Hyper-V для развертывания виртуальных машин в виртуальных сетях.

Вы проектируете или поддерживаете ИТ-инфраструктуру для организации, которая развертывает или планирует развертывание облачных технологий.

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

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

Версии маршрутизатора в Windows Server 2012 R2

В Windows Server 2012 R2 доступны две различные версии шлюзов-маршрутизаторов - мультитенантный шлюз RRAS и шлюз Windows Server. Несмотря на то что маршрутизаторы имеют одинаковые функции и возможности, для управления каждым из них можно использовать разные методы, в зависимости от того, используют ли они System Center 2012 R2.

Мультитенантный шлюз RRAS . Мультитенантный шлюз-маршрутизатор RRAS можно использовать для мультитенантного или немультитенантного развертывания; он представляет собой полнофункциональный BGP-маршрутизатор. Для развертывания мультитенантного шлюза-маршрутизатора RRAS необходимо использовать команды Windows PowerShell. Дополнительные сведения см. в разделе и Руководство по развертыванию мультитенантного шлюза RRAS Windows Server 2012 R2 .

Для развертывания шлюза Windows Server необходимо использовать System Center 2012 R2 и Virtual Machine Manager (VMM). Шлюз-маршрутизатор Windows Server предназначен для использования в мультитенантных средах. При использовании шлюза-маршрутизатора диспетчера виртуальных машин System Center 2012 R2 в интерфейсе программного обеспечения диспетчера виртуальных машин доступен лишь ограниченный набор параметров настройки BGP-протокола, в том числе "Локальный IP-адрес BGP" и "Номер в автономной системе (ASN)", "Список IP-адресов партнеров BGP" и "ASN, значения". Тем не менее вы можете использовать команды удаленного доступа Windows PowerShell для BGP, чтобы настроить все остальные функции шлюза Windows Server. Дополнительные сведения см. в разделах Windows Server Gateway и .

Что такое шлюз Windows Server?

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

Примечание

Шлюз Windows Server поддерживает протоколы IPv4 и IPv6, включая переадресацию IPv4 и IPv6. При настройке шлюза Windows Server с функцией преобразования сетевых адресов (NAT) поддерживается только NAT44.

Виртуальные сети создаются с помощью виртуализации сети Hyper-V; эта технология была впервые использована в Windows Server® 2012.

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

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

В Windows Server 2012 R2 шлюз Windows Server осуществляет маршрутизацию сетевого трафика между физической сетью и ресурсами виртуальных машин независимо от местоположения ресурсов. Шлюз Windows Server можно использовать для маршрутизации сетевого трафика между физическими и виртуальными сетями, физически расположенными в одном и том же месте или в нескольких разных местах. Например, если физическая и виртуальная сети физически расположены в одном месте, то вы можете установить компьютер с Hyper-V, на котором виртуальная машина шлюза Windows Server будет выполнять функции перенаправляющего шлюза и осуществлять маршрутизацию трафика между физическими и виртуальными сетями. Другой пример. Если ваши виртуальные сети существуют в облаке, то поставщик облачных служб может развернуть шлюз Windows Server, чтобы вы могли создать VPN-подключение "сеть - сеть" между вашим VPN-сервером и шлюзом Windows Server поставщика облачных служб. После того как связь будет установлена, вы сможете подключаться к виртуальным ресурсам в облаке через VPN-подключение.

Интеграция шлюза Windows Server и технологии виртуализации сети Hyper-V

Шлюз Windows Server интегрирован с технологией виртуализации сети Hyper-V и может эффективно осуществлять маршрутизацию сетевого трафика в ситуации со множеством различных клиентов - или тенантов, - которые имеют изолированные виртуальные сети в том же центре обработки данных.

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

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

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

Примечание

Дополнительные сведения о технологии виртуализации сети Hyper-V и виртуальном коммутаторе Hyper-V в Windows Server 2012 см. в разделах Обзор виртуализации сети Hyper-V и Обзор виртуального коммутатора Hyper-V в технической библиотеке Windows Server 2012.

Кластеризация шлюза Windows Server для обеспечения высокой доступности

Развертывание шлюза Windows Server осуществляется на специальном компьютере, на котором устанавливается система виртуализации Hyper-V и создается одна виртуальная машина. Затем эта виртуальная машина настраивается как шлюз Windows Server.

Для обеспечения высокой доступности ресурсов сети вы можете развернуть шлюз Windows Server в отказоустойчивой конфигурации с использованием двух физических серверов, на каждом из которых установлена система виртуализации Hyper-V и работает виртуальная машина, сконфигурированная как шлюз. Затем виртуальные машины шлюза необходимо настроить как кластеры, чтобы обеспечить отказоустойчивость и защиту от отказов сети и сбоев оборудования.

При развертывании шлюза Windows Server серверы узлов Hyper-V и виртуальные машины, которые вы настроили как шлюзы, должны работать под управлением Windows Server 2012 R2.

Следующий значок представляет два узла Hyper-V, на каждом из которых работает виртуальная машина, настроенная как шлюз Windows Server (если на рисунках, представленных в следующих разделах, не указано иное). Кроме того, на обоих серверах работает система Hyper-V, а виртуальные машины на каждом сервере работают под управлением Windows Server 2012 R2. Виртуальные машины шлюза кластеризованы.

Использование шлюза Windows Server в качестве шлюза для переадресации в частных облачных средах

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

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

Для предприятий, предпочитающих локальное развертывание частного облака, шлюз Windows Server может выполнять функции шлюза переадресации и осуществлять маршрутизацию трафика между виртуальными и физическими сетями. Например, если вы создали виртуальные сети для одного или нескольких отделов (скажем, для отдела исследований и разработки и бухгалтерского отдела), но многие из ваших основных ресурсов (такие как доменные службы Active Directory, SharePoint или DNS) находятся в физической сети, шлюз Windows Server может осуществлять маршрутизацию трафика между физической и виртуальной сетями для обеспечения доступа сотрудников, работающих в виртуальной сети, ко всем службам, которые им необходимы.

На следующем рисунке физическая и виртуальные сети физически расположены в одном месте. Шлюз Windows Server используется для маршрутизации трафика между физической сетью и виртуальными сетями.

Шлюз Windows Server как VPN-шлюз "сеть - сеть" для гибридных облачных сред

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

На следующем рисунке поставщик облачных служб предоставляет доступ по сети нескольким клиентам, некоторые из которых имеют несколько узлов в Интернете. В данном примере клиенты используют на узлах своего предприятия VPN-серверы сторонних производителей, тогда как поставщик облачной службы использует шлюз Windows Server для предоставления VPN-подключений "сеть - сеть".

Мультитенантное преобразование сетевых адресов (NAT) для доступа в Интернет с виртуальных машин

На следующем рисунке домашний пользователь, использующий веб-браузер на своем компьютере, совершает покупку через Интернет на веб-сервере Contoso, который представляет собой виртуальную машину в виртуальной сети компании Contoso. В процессе оформления покупки веб-приложение проверяет информацию кредитной карты, предоставленную домашним пользователем, подключившись к финансовой службе компании через Интернет. Описанная возможность подключения к ресурсам в Интернете из виртуальной сети предоставляется, если на шлюзе Windows Server у поставщика облачных служб включена функция NAT.

Мультитенантные VPN-подключения удаленного доступа

На следующем рисунке администраторы используют коммутируемые VPN-подключения для управления виртуальными машинами в своих виртуальных сетях. Администратор из Contoso инициирует VPN-подключение в филиале, подключенном к Интернету, и подключается к виртуальной сети Contoso через шлюз Windows Server поставщика облачных служб.

Аналогичным образом администратор Northwind Traders устанавливает VPN-подключение из домашнего офиса для управления виртуальными машинами в виртуальной сети Northwind Traders.

Глава 30 Организация шлюза в Интернете для локальной сети

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

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

Начальные установки

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

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

Networking support (поддержка сетевых свойств);

TCP/IP networking (поддержка TCP/IP);

IP forwarding/gatewaying (поддержка IP-маршрутизации);

IP multicasting (поддержка специфических свойств IP-протокола);

IP firewalling (поддержка брадмауэров);

IP accounting (поддержка управления IP);

Network device support (поддержка сетевых устройств).

Помимо этого, ядро операционной системы должно уметь работать с сетевыми картами, установленными на вашем компьютере, и поддерживать протокол РРР (Point-to-Point Protocol).

Само собой, следует правильно настроить сетевое оборудование, IP-адреса и т. п.

Связь с провайдером

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

В первом случае выход в Интернет осуществляется при помощи стандартного для Linux набора программ – pppd, chat и, возможно, еще нескольких скриптов. Происходит это следующим образом – вначале маршрутизатор дозванивается до провайдера и устанавливает с ним связь по протоколу РРР или по протоколу SLIP, который сейчас используется крайне редко. После установления соединения полученным каналом может пользоваться любой компьютер в вашей локальной сети (при соответствующей настройке). Канал удерживается до тех пор, пока не выключится ваш маршрутизатор или администратор явным образом не разорвет соединение.

Второй вариант – модификация первого, в англоязычной литературе он носит название dial on demand (звонок по требованию). Для его организации дополнительно используется программа diald, с помощью которой можно организовать работу таким образом, что если в течение заранее обусловленного времени не происходит обмена данными между локальной сетью и Интернетом, то diald разрывает соединение. При первой же попытке пользователя подключиться к Интернету diald снова дозванивается и устанавливает связь.

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

Схема организации подключения локальной сети

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

Возможность доступа в Интернет – модем, телефонный номер и подключение к провайдеру.

Набор программ для организации связи – pppd, chat и diald.

Средство для управления брандмауэром – утилиты ipchains или iptables.

Средство для ограничения трафика (если необходимо).

Программное обеспечения для организации proxy-сервера.

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

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

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

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

Настройка программ

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

Настройка связи с провайдером

Настроим подсистему дозвона и соединения с провайдером. Для удобства разобьем работу на два этапа:

1. Настройка РРР-соединения.

2. Установка и конфигурирование демона дозвона по требованию (diald).

Настройку модемного соединения мы здесь рассматривать не будем, поскольку это достаточно простая задача, и очень подробно рассмотрена в работе одного из отечественных патриархов Linux – В. Водолазкого "Установка РРР-соединения в Linux".

Почему мы используем протокол РРР? Основные преимущества протокола РРР по сравнению с протоколом SLIP состоят в следующем:

Назначение IP-адресов в РРР реализуется с помощью демона pppd, что значительно упрощает процесс конфигурирования при использовании динамических IP-адресов;

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

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

Таблица 30.1. Необходимые данные для настройки модемного соединения

Процесс установления связи между вами и провайдером состоит из следующих этапов:

Соединения с компьютером провайдера с помощью модема;

Регистрации пользователя в удаленной системе;

Установки РРР-соединения.

Для решения этих задач в Linux используется небольшой набор скриптов, каждый из которых выполняет какую-то небольшую функцию. А поскольку это набор скриптов – никто не мешает на их базе определить именно те действия, которые необходимы вам при установлении или обрыве РРР-соединения.

Размещение скриптов зависит от настройки и предпочтений вашего дистрибутива. В современных версиях дистрибутива Red Hat используется два места – каталоги /etc/ррр и /etc/sysconfig/network-scripts. Наименования скриптов так же могут быть произвольными и очень часто зависят от предпочтений сборщика дистрибутива или системного администратора.

/etc/ppp/chap-secrets – этот файл используется для аутентификации пользователя провайдером по протоколу chap. Обычно содержит имя и пароль пользователя для входа к провайдеру. В нашем случае это будет выглядеть следующим образом:

/etc/ppp/pap-secrets – этот файл используется для аутентификации пользователя провайдером по протоколу рар. Обычно содержит имя и пароль пользователя для входа к провайдеру. В нашем случае это будет выглядеть следующим образом:

/etc/ppp/ip-up – данный скрипт используется для соединения с провайдером. Зачастую этот файл содержит только следующую строку:

Здесь можно настроить установление модемом соединения с провайдером или вызвать необходимый скрипт или программу;

/etc/ppp/ip-down – этот файл используется для разрыва соединения с провайдером;

/etc/ppp/options – это, пожалуй самый сложный и ответственный файл. Он определяет параметры нашего модема, скорость передачи по последовательному интерфейсу данных, настройки программы pppd и некоторые другие параметры. Обычно файл /etc/ppp/options оставляют неизменным, а для конфигурирования параметров соединения создают копию файла с именем /etc/ppp/options.ttySX, где ttySX – имя последовательного порта, к которому подключен наш модем. Пусть для определенности модем подключен к ttyS0 (СОМ1).

# Устройство

# Скорость

# наш интерфейс: удаленный интерфейс

192.168.0.100:192.168.0.101

# маска подсети

netmask 255.255.255.0

chap-interval 15

defaultroute

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

192.168.0.100:192.168.0.101

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

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

Таблица 30.2. Основные команды программы pppd

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

Настройка diald

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

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

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

Теперь перейдем непосредственно к конфигурированию. Этот процесс состоит из трех частей:

Создание скрипта соединения – файл /etc/diald/connect;

Настройка основной конфигурации – файл /etc/diald.conf;

Настройка правил тайм-аутов – файл /etc/diald/standard.filter.

Создание скрипта соединения: /etc/diald/connect

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

Ниже приведен вариант файла /etc/diald/connect.

NIT="ATZ" # Строка инициализации модема

PHONE="223322" # Телефон провайдера

ACCOUNT="myname" # логин

PASSWORD="vasya" # пароль

# Определяем функцию для посылки

# сообщений в системный журнал

# и в FIFO-канал diald

function message ()

[$FIFO] && echo "message $*" >$FIFO

logger -p local2.info -t connect "$*"

# Начинаем процедуру связи

# Инициализируем модем

message "*** Initializing Modem ***"

chat "" $INIT OK ""

message"!!! Failed to initialize modem!!!"

# Пытаемся дозвониться

message "*** Dialing system ***"

ABORT "NO CARRIER"

ABORT "NO DIALTONE"

ABORT ERROR

0) message "*** Connected ***";;

1) message "!!! Chat Error !!!"; exit 1;;

2) message "!!! Chat Script Error !!!"; exit 1;;

3) message "!!! Chat Timeout !!!"; exit 1;;

4) message "!!! No Carrier !!!"; exit 1;;

5) message "!!! Busy !!!"; exit 1;;

6) message "!!! No DialTone !!!; exit 1;;

7) message "!!! Modem Error !!!; exit 1;;

message "*** Send login and password ***"

password: $PASSWORD TIMEOUT 5 ""

if [$? != 0] then

message"!!! Failed to send!!!"

# Все прошло удачно!

message "*** Protocol started ***"

Вышеприведенный скрипт – просто сценарий на языке командной оболочки, который вам необходимо немного адаптировать для ваших параметров. Настройка основной конфигурации: /etc/diald.conf

/etc/diald.conf – основной конфигурационный файл программы diald, в котором задаются параметры устанавливаемого соединения и определяется поведение программы. Набор команд конфигурации у diald достаточно обширен, поэтому в приведенном примере будут использованы только необходимые, а подробную информацию по конфигурационным командам можно посмотреть в документации на программу diald.

Содержимое файла diald.conf:

# Протокол для связи с провайдером

# Вести журнал сеансов связи diald.log

accounting-log /var/log/diald.log

# Для управления демоном из внешних программ

# организовать канал FIFO – diald.ctl.

fifo /etc/diald/diald.ctl

# Для дозвона использовать файл /etc/diald/connect

# Поскольку мы уже определили параметры в /etc/ppp/options,

# то нижеприведенные команды необходимо закомментировать во избежание

# конфликтов в файле /etc/ppp/options

# device /dev/modem

# Назначаем локальный и удаленный адреса нашего

# соединения. Если при связи с провайдером IP-адрес

# для вас выделяется динамически, то здесь можно

# поставить любые свободные адреса из диапазона,

# оговоренного при настройке нашей TCP/IP-сети.

# При запуске РРР diald сам выставит корректные значения

local 192.168.0.100

remote 192.168.0.101

# Провайдер дает нам динамический IP

# Установить маршрут по умолчанию

# на виртуальное соединение

# Максимальное количество неудачных попыток дозвона

dial-fail-limit 10

# Задержка между попытками дозвона

redial-timeout 5

# время ожидания завершения скрипта connect

connect-timeout 120

# Файл с правилами для тайм-аутов

include /etc/diald/standard.filter

Настройка правил тайм-аутов: /etc/diald/standard.filter

Следующее, что вы должны сделать – произвести настройку правил тайм-аутов. Это самый сложный момент настройки diald, т. к. требует знания внутренней структуры IP-пакетов. Однако разработчики diald – люди добрые и стандартный файл standard.filter имеет вполне приемлемые для большинства случаев настройки. Оставив в нем все, как есть, мы получим набор правил, рассчитанный на трехминутную паузу между окончанием активности в Интернете и разрывом связи с провайдером.

Комплексное тестирование

После проделанных манипуляций настало время проверить – правильно ли настроены наши программы. Для этого на компьютере желательно временно отключить все настройки брандмауэра (если вы, конечно, установили его). Затем необходимо запустить программу diald и попытаться выйти в "большой мир". Можно использовать браузер lynx (и зайти, например, на сайт http://www.bhv.ru), можно – программу ping.

Если все было настроено корректно, то после ввода предыдущей команды модем должен начать дозваниваться до провайдера. Через некоторое время связь будет установлена. Однако практически всегда lynx выдает сообщение о том, что не может соединиться с удаленным сервером! В данном случае – это нормальное явление. Дело в том, что при РРР-соединении с динамическими IP-адресами в силу определенных особенностей первый пакет обычно бывает утерян и не доходит до адресата. В результате мы ждем ответа от сервера, а он об этом и не подозревает. Достаточно повторить введенную ранее команду, чтобы все заработало.

Далее нам необходимо убедиться, что модем аккуратно разорвет соединение по прошествии трех минут. Дождавшись конца загрузки Web-страницы, засечем время. Примерно через три минуты diald должен дать команду на разрыв соединения.

Если у вас все прошло именно таким образом, значит система работает как надо. В противном случае проанализируйте последние строки системного журнала (/var/log/messages).

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