Процесс установки соединения с вызовом по требованию
Используем описанный выше сценарий для того, чтобы рассмотреть процесс установки соединения с вызовом по требованию. Для определенности будем считать, что хост с адресом 173.75.73.5 пытается получить доступ к ресурсам хоста с адресом 173.75.72.10.
При этом выполняется следующая последовательность действий:
- Пакеты от 173.75.73.5, предназначенные для 173.75.72.10, передаются Маршрутизатору 1.
- Маршрутизатор 1 получает пакет от 173.75.73.5 и проверяет собственную таблицу маршрутизации. Маршрут к 173.75.72.10 предписывает передавать пакеты через интерфейс DD_SPb.
- Маршрутизатор 1 проверяет состояние интерфейса DD_SPb и обнаруживает его в разъединенном состоянии.
- Маршрутизатор 1 извлекает информацию о конфигурации интерфейса DD_SPb с вызовом по требованию.
- Полученная информация используется Маршрутизатором 1 для инициации соединения с вызовом по требованию. Маршрутизатор 1 использует модем, подключенный к СОМ1, чтобы набрать номер (812)765-4321.
- Маршрутизатор 2 отвечает на входящий вызов.
- Маршрутизатор 2 запрашивает идентификационную информацию по входящему соединению.
- Маршрутизатор 1 посылает имя учетной записи пользователя "DD_Moscow" и соответствующий ей пароль.
- После получения идентификационной информации Маршрутизатор 2 проверяет имя пользователя и пароль в базе данных системы безопасности Windows и определяет, что Маршрутизатор 1 имеет разрешение на установление входящего соединения.
- Теперь Маршрутизатор 2 должен определить, является ли субъект, установивший входное соединение, сетевым клиентом или маршрутизатором, устанавливающим соединение с вызовом по требованию. Маршрутизатор 2 просматривает список интерфейсов с вызовом по требованию и ищет интерфейс, который соответствует имени пользователя, посланному Маршрутизатором 1 как часть идентификационной информации. Маршрутизатор 2 находит интерфейс с вызовом по требованию "DD_Moscow", который соответствует имени пользователя.
- Маршрутизатор 2 переводит интерфейс с вызовом по требованию от DD_Moscow в состояние "соединен".
- Маршрутизатор 1 передает пакет от пользователя с адресом 173.75.73.5 через соединение с вызовом по требованию на Маршрутизатор 2.
- Маршрутизатор 2 получает пакет и пересылает его хосту с адресом 173.75.72.10.
- Хост с адресом 173.75.72.10 отправляет на Маршрутизатор 2 ответ на запрос об установлении соединения, сделанный хостом с адресом 173.75.73.5.
- Маршрутизатор 2 получает пакет, предназначенный для 173.73.75.5, и проверяет таблицу маршрутизации: маршрут к 173.75.73.5 найден, используется интерфейс DD_Moscow.
- Маршрутизатор 2 проверяет состояние интерфейса DD_Moscow и определяет, что он находится в состоянии "соединен".
- Маршрутизатор 2 передает пакет Маршрутизатору 1.
- Маршрутизатор 1 передает пакет пользователю по адресу 173.75.73.5.
Если имя пользователя в идентификационной информации не совпадают с именем соответствующего интерфейса с вызовом по требованию, объект вызова определяется как сетевой клиент, что может привести к проблемам маршрутизации.
Допустим, в рассмотренном выше примере Маршрутизатор 1 использует строку "DialUpRouterl" в качестве имени учетной записи пользователя, передаваемого в процессе аутентификации пользователя (предположим также, что DialUpRouterl реально существующая учетная запись, имеющая разрешение на установление входящего соединения). В этой ситуации Маршрутизатор 1 будет распознан как сетевой клиент, а не как маршрутизатор. Пакеты от хоста с адресом 173.75.73.5 будут отправляться хосту с адресом 173.75.72.10, так же как и было описано ранее. Однако ответные пакеты от 173.75.72.10 к 173.75.73.5 не будут доставлены, поскольку Маршрутизатор 2 после проверки таблицы маршрутизации определит, что интерфейс, который необходимо использовать, – DD_Moscow. Но DD_Moscow находится в разъединенном состоянии.
В соответствии с конфигурацией для DD_Moscow должен использоваться порт COM2. Однако COM2 в настоящее время используется Маршрутизатором 2 для сетевого клиента (за который ошибочно был принят Маршрутизатор 1). Следовательно, процесс установки соединения для DD_Moscow оканчивается неудачей, и ответные пакеты от 173.75.72.10 к 173.75.73.5 теряются.