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

Используем описанный выше сценарий для того, чтобы рассмотреть процесс установки соединения с вызовом по требованию. Для определенности будем считать, что хост с адресом 173.75.73.5 пытается получить доступ к ресурсам хоста с адресом 173.75.72.10. При этом выполняется следующая последовательность действий:
1. Пакеты от 173.75.73.5, предназначенные для 173.75.72.10, передаются Маршрутизатору 1.
2. Маршрутизатор 1 получает пакет от 173.75.73.5 и проверяет собственную таблицу маршрутизации. Маршрут к 173.75.72.10 предписывает передавать пакеты через интерфейс DD_SPb.
3. Маршрутизатор 1 проверяет состояние интерфейса DD_SPb и обнаруживает его в разъединенном состоянии.
4. Маршрутизатор 1 извлекает информацию о конфигурации интерфейса DD_SPb с вызовом по требованию.
5. Полученная информация используется Маршрутизатором 1 для инициации соединения с вызовом по требованию. Маршрутизатор 1 использует модем, подключенный к СОМ1, чтобы набрать номер (812)765-4321.
6. Маршрутизатор 2 отвечает на входящий вызов.
7. Маршрутизатор 2 запрашивает идентификационную информацию по входящему соединению.
8. Маршрутизатор 1 посылает имя учетной записи пользователя "DD_Moscow" и соответствующий ей пароль.
9. После получения идентификационной информации Маршрутизатор 2 проверяет имя пользователя и пароль в базе данных системы безопасности Windows и определяет, что Маршрутизатор 1 имеет разрешение на установление входящего соединения.
10. Теперь Маршрутизатор 2 должен определить, является ли субъект, установивший входное соединение, сетевым клиентом или маршрутизатором, устанавливающим соединение с вызовом по требованию. Маршрутизатор 2 просматривает список интерфейсов с вызовом по требованию и ищет интерфейс, который соответствует имени пользователя, посланному Маршрутизатором 1 как часть идентификационной информации. Маршрутизатор 2 находит интерфейс с вызовом по требованию "DD_Moscow", который соответствует имени пользователя.
11. Маршрутизатор 2 переводит интерфейс с вызовом по требованию от DD_Moscow в состояние "соединен".
12. Маршрутизатор 1 передает пакет от пользователя с адресом 173.75.73.5 через соединение с вызовом по требованию на Маршрутизатор 2.
13. Маршрутизатор 2 получает пакет и пересылает его хосту с адресом 173.75.72.10.
14. Хост с адресом 173.75.72.10 отправляет на Маршрутизатор 2 ответ на запрос об установлении соединения, сделанный хостом с адресом 173.75.73.5.
15. Маршрутизатор 2 получает пакет, предназначенный для 173.73.75.5, и проверяет таблицу маршрутизации: маршрут к 173.75.73.5 найден, используется интерфейс DD_Moscow.
16. Маршрутизатор 2 проверяет состояние интерфейса DD_Moscow и определяет, что он находится в состоянии "соединен".
17. Маршрутизатор 2 передает пакет Маршрутизатору 1.
18. Маршрутизатор 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 теряются.