Опубликован: 28.11.2014 | Уровень: для всех | Доступ: платный | ВУЗ: Московский государственный университет имени М.В.Ломоносова
Лекция 5:

Технологии тунеллирования

Протокол шифрования МРРЕ Microsoft

Протокол предназначен для шифрования РРР-пакетов. В протоколе ис-пользуется поточный алгоритм шифрования RC4. О длине ключа ведутся переговоры. МРРЕ (Microsoft Point-to-Point Encryption) поддерживает 40-битные, 56-битные и 128-битные ключи. Ключи сессии меняются часто, частота смены ключей зависит от установленных опций.

Инициатор переговоров указывает в опциях все алгоритмы, которые он поддерживает.

Переговоры об используемой длине ключа

Рис. 5.7. Переговоры об используемой длине ключа

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

Завершение переговоров об используемой длине ключа

Рис. 5.8. Завершение переговоров об используемой длине ключа

Для того, чтобы передавать МРРЕ-пакеты, протокол РРР должен перейти в состояние пересылки дейтаграмм сетевого уровня. В информаци-онное поле РРР инкапсулируется одна МРРЕ-дейтаграмма. Для всех зашифрованный дейтаграмм в поле Protocol указан тип 0х00FD.

Обмен зашифрованными дейтаграммами в протоколе РРР

Рис. 5.9. Обмен зашифрованными дейтаграммами в протоколе РРР
Протокол конфигурирования IP - IPCP

Протокол управления IP (Internet Protocol Control Protocol – IPCP) предназначен для конфигурирования IP-протокола на обоих концах канала точка-точка. IPCP использует тот же самый механизм обмена пакетами, что и протокол управления каналом LCP. Обмен IPCP-пакетами начинается в состоянии обмена дейтаграммами сетевого уровня. IPCP отличается от LCP следующим:

  • Поле протокола данных канального уровня. Единственный пакет инкапсулирован в информационное поле РРР-данных канального уровня.
  • Поле кодов. Используются следующие коды:
    • Configure-Request – запрос конфигурации.
    • Configure-Ack – подтверждение на запрос конфигурации.
    • Configure-Nak – негативное подтверждение.
    • Configure-Reject – отклонение конфигурацию.
    • Terminate-Request – завершение запроса.
    • Terminate-Ack – подтверждение завершения.
    • Code-Reject – код отклонения.

Перед тем, как посылать любые IP-пакеты, протокол IPCP должен перейти в открытое состояние. Максимальная длина IP-пакета, передаваемого по РРР-каналу, та же самая, что и максимальная длина информационного поля РРР-данных канального уровня. IP-дейтаграммы большего размера будут фрагментированы. Если необходимо избежать фрагментирования и последующего сбора пакетов, то следует использовать опции ТСР Maximum Segment Size и MTU discovery.

Конфигурационные опции IPCP позволяют вести переговоры о требуемых параметрах IP. IPCP использует тот же самый формат конфигурацион-ных опций, что и LCP.

Задание диапазона IP-адресов, которые будут выдаваться клиенту

Рис. 5.10. Задание диапазона IP-адресов, которые будут выдаваться клиенту
  1. Протокол сжатия IP

    Данный параметр позволяет договориться об использовании конкрет-ного протокола сжатия. По умолчанию сжатие не требуется.

    .
  2. IP-адрес.

    Данный параметр предоставляет способ ведения переговоров об IP-адресе, который будет назначен локальной стороне канала. Он позволяет отправителю Configure-Request указать желаемый IP-адрес или запросить противоположную сторону выдать ему IP-адрес. Противоположная сторона может предоставить данную информацию в параметре Nak, указав IP-адрес, который будет использоваться.

  3. Адреса DNS-серверов и узлов NetBIOS Name Серверов (NBNS) в удаленной сети.

    Могут быть указаны IP-адреса первичного и вторичного DNS-серверов. Возможность использования информации об адресах DNS-серверов зависит от топологии удаленной сети и от приложения на локальной стороне.

    Параметры позволяют договориться об IP-адресах первичного и вторичного DNS-серверов, которые будут использоваться на локальной стороне.

Назначение IP-адреса клиенту

Рис. 5.11. Назначение IP-адреса клиенту
Андрей Викторов
Андрей Викторов
Россия, Санкт-Петербург, Северо-Западный заочный технический университет, 2007
Мария Шахрай
Мария Шахрай
Украина, НТУУ КПИ, 2013