Виртуальная частная коммутируемая сеть (Virtual Private Dialup Network (VPDN)) позволяет клиенту подключаться непосредственно к корпоративной ЛВС (к Серверу Доступа - NAS). Например, мобильные пользователи HEWLETT-PACKARD (типа комивояжеров) хотят иметь возможность подключаться к сети HEWLETT-PACKARD где угодно и когда угодно. HP заключил бы договор с поставщиком Internet-сервиса (Internet Service Providers (ISP)), который поддерживал бы VPDN. У этого провайдера должно быть настроено так, что если jsmith@hp.com позвонит на любой телефон провайдера, то NAS автоматически переправит его на локальный шлюз HP. ISP освобожден от управления IP адресами пользователей HP, маршрутизацией, и другими функциями, привязанными к базе пользователей HP. Администрирование провайдером уменьшено до обеспечения IP подключения к шлюзу HP.

Рисунок 1 описывает 'классический' путь, которым пользователь - jsmith - соединяется к NAS, чтобы подключится к внутреним сетям HP.

Рисунок 1: подключение jsmith к Серверу доступа

В терминологии VPDN, ISP является NAS и шлюз HP является шлюзом корпоративной ЛВС.

На Рисунке 2, показана PPP связь - между клиентом (jsmith) и корпоративным шлюзом. Распространение PPP соединения от NAS до корпоративного шлюза поддерживается протоколом L2F.

Следующие секции описывают некоторые аспекты L2F.

2.1 Поток L2F

Здесь описываются перспективы PPP и L2F. Для более подробного изучения данного вопроса обратитесь к RFC L2F.

2.1.1 PPP Авторизация

Последовательность начинается с описания поступающей PPP сессией на NAS от клиента. После фазы LCP обменов, начинается стадия PPP авторизации на NAS. NAS посылает CHAP запросы клиенту. Клиент, в свою очередь, возвращает CHAP ответ.

После получения этого ответа, NAS определяет соответствие имени пользователя конфигурации, по которой нужно использовать VPDN, чтобы переправить PPP-сессию на шлюз корпоративной сети. В этом случае, так как это первая L2F сессия к корпоративному шлюзу, NAS и локальный шлюз обмениваются пакетами L2F туннелирования. Именно на стадии L2F туннель между NAS и корпоративным шлюзом закончен. Когда L2F тунелирование закончено, NAS и корпоративный шлюз обмениваются пакетами(Mid) L2F сессии. Пакеты L2F_OPEN (Mid) от NAS Корпоративному шлюзу несут LCP информацию, CHAP запрос и ответ на него.

В корпоративном шлюзе LCP информация сессии LCP переправляется в виртуальный интерфейс доступа, созданный для L2F сессии. CHAP запрос и ответ заверяются корпоративным шлюзом. Например, послано CHAP сообщение: Auth-OK.

Поскольку, поскольку клиент авторизован, после получения ответа Auth-OK, PPP закончил стадию LCP авторизации. После этого возможен скрытый обменен между клиентом и корпоративным шлюзом. NAS невидим для PPP структуры.

Последующие сеансы PPP ( для того же самого шлюза) повторяют обмен сеанса L2F, т.к. уже существует L2F тунель, сформированный к корпоративному шлюзу.

Рисунок 3. PPP Aвторизация

2.1.2 Авторизация L2F туннелирования

Прежде, чем NAS и корпоративный шлюз открывают L2F туннель, каждый из них подтверждает подлинность другого. NAS посылает L2F_CONF, содержащий имя NAS и случайное число А. Когда корпоративный шлюз получает L2F_CONF, он посылает L2F_CONF назад NAS с именем корпоративного шлюза и случайным числом B. С этим сообщением к NAS передается ключ A' (MD5 кода NAS и значения A).

NAS, после получения L2F_CONF, сравнивает ключ A' с MD5 кода NAS и значения A. Если это соответствует, NAS посылает L2F_OPEN корпоративному шлюзу, на сей раз с ключом B' (MD5 кода корпоративного шлюза и значения B).

Корпоративный шлюз, после получения L2F_OPEN, сравнивает ключ B' с MD5 кода корпоративного шлюза и значения B. Если это соответствует, корпоративный шлюз посылает L2F_OPEN NAS с ключом A' .

Все последующие сообщения от NAS имеют ключ=B', все от корпоративного шлюза имеют ключ=A'.

Рисунок 4. Авторизация L2F туннелирования