Оффлайн
Apollon
Заблокирован
- Регистрация
- 07.09.17
- Сообщения
- 5.317
- Реакции
- 1.007
- Репутация
- 1.625
L2TP – туннельный протокол, используемый для создания виртуальных сетей. Главное его достоинство – возможность создания виртуальных сетей не только поверх сетей IP, но и в сетях Frame Relay, Х.25 и АТМ. Несмотря на схожесть с протоколом канального уровня OSI, L2TP – протокол сеансового уровня, использующий порт UDP 1701.
Начало разработки протокола можно отнести к 1997 г., а в 1999 г. появился стандарт RFC2661, описывающий его. Считается, что L2TP объединил в себе лучшие четы L2F и PPTP.
Схема работы
Для установления соединения удаленная система через телефонную сеть PSTN инициирует соединение PPP с LAC. Далее для PPP-соединения LAC прокладывает туннель через LNS, Frame Relay, ATM или Internet, осуществляя доступ к исходной локальной сети. Удаленная система получает адреса от исходной LAN путем согласования с NCP. Авторизация и аутентификация предоставляются таким образом, как если бы удаленный пользователь был напрямую соединен с сервером NAS.
LAC-клиент, использующий программу L2TP, может подключиться к туннелю до исходной локальной сети если машина с LAC-клиентом уже подсоединена к Internet, при этом использование отдельного LAC необязательно. В данном случае создается виртуальное соединение PPP, в котором локальная L2TP LAC создает туннель до LNS. Как и в предыдущем случае, авторизация, адресация и аутентификация будут обеспечиваться областью управления исходной локальной сети.
Обзор протокола
В протоколе L2TP используется 2 типа пакетов: информационные и управляющие сообщения. Первые используются для инкапсуляции кадров РРР, которые пересылаются по туннелю. Вторые – при установлении, поддержании и уничтожении вызовов и туннелей. Для гарантии доставки управляющие сообщения пользуются надежным контрольным каналом в рамках самого L2TP, а информационные сообщения в случае потери посылаются повторно. Дополнительно для обеспечения гарантированной доставки управляющим сообщениям присваивается порядковый номер. Информационные сообщения используют порядковые номера для определения потери кадров и восстановления порядка пакетов.
Формат заголовка
Информация из данного блока может быть интересна специалистам. В познавательных целях этот блок можно пропустить, и сразу приступить к чтению следующего.
И контрольный, и информационный канал L2T0050 используют единый формат заголовка. Перечислим вкратце значения битов в 32-битной последовательности:
0 – бит (T) типа пакета характеризует его разновидность и ему присваивается значение 0 для информационных и 1 – для контрольных сообщений.
1 – бит (L) длины пакета. Если он равен 1 (обязательно для управляющих сообщений), то в пакете присутствует поле «Длина» (с 16 по 31 бит).
2-3 – эти биты зарезервированы и должны устанавливаться в 0 для исходящих и игнорироваться во входящих пакетах.
4 – бит (S) последовательности. В управляющих сообщениях он равен 1. В этом случае в пакете присутствуют поля Nr и Ns.
5 – бит зарезервирован
6 – бит (O) смещения. Если он равен 1, то присутствует поле, определяющее величину смещения.
7 – бит (Р) приоритета. Для управляющих сообщений он равен 0. Если он равен 1 для информационного сообщения, то в очереди оно получает приоритет.
8-11 – биты зарезервированы12-15 – поле «Версия» (Ver) определяет версию заголовков информационных сообщений L2TP. При этом значение 1 предназначено для определения пакетов L2F, если они идут вперемешку с пакетами L2TP. Пакеты с неизвестными значениями Ver должны отбрасываться.
16-31 – поле длины пакета, указывающее (в октетах) длину сообщения.
В поле ID туннеля содержится идентификатор соединения. Они имеют локальное значение, поэтому разные концы туннеля имеют различные идентификаторы. При этом ID туннеля для каждого сообщения должно быть именно таким, каким его ждет получатель. Создается этот идентификатор при формировании туннеля передачи данных.
В поле ID сессии определяется идентификатор сессии туннеля. Идентификаторы сессий также имеют локальное значение и должно быть именно таким, каким его ждет получатель. Создается этот идентификатор при формировании сессии передачи данных.
В поле Ns содержится порядковый номер управляющего или информационного сообщения от 0 и увеличиваясь далее на 1 для каждого следующего сообщения. В поле Nr содержится порядковый номер, следующего ожидаемого сообщения. Следовательно, Nr равен Ns последнего пришедшего сообщения плюс 1.
Если в пакете присутствует поле «Величина смещения», оно определяет место начала поля данных, при этом содержимое заполнения смещения не определяется.
Протокольные операции
Процедура установления РРР-сессии туннелирования L2ТР состоит из двух этапов:
Управляющее соединение
Перед началом сессии между LАС и LNS должно быть реализовано управляющее соединение, которое включает безопасную идентификацию партнеров и определение версии L2ТР, а также возможностей канала и т.д. В процессе установления этого соединения производится простая CHAP-подобная аутентификация.
Установление сессии
После того, как управляющее соединение установлено, компьютеры могут формировать индивидуальные сессии. Каждая из них соответствует одному РРР-потоку между LАС и LNS. При этом LАС запрашивает у LNS доступ для входных запросов, тогда как LNS запрашивает LAC запуск сессии для обработки исходящих запросов.
После формирования туннеля, РРР-кадры из удаленной системы, которые получает LAC, освобождаются от канальных заголовков, CRC и т.д., инкапсулируются в L2ТР, а затем передаются через туннель. Затем LNS получает L2ТР-пакет, извлекает РРР-кадр и работает с ним, словно он пришел через локальный РРР-интерфейс.
Отправитель сообщения, связанный с определенным туннелем и сессией, помещает в соответствующие спецификации поля заголовка ID туннеля и сессии во всех сообщениях.
Нумерация в канале данных
Для надежной передачи управляющих сообщений используются порядковые номера в заголовке L2TP. Каждый из партнеров поддерживает свою нумерацию, как для управляющего соединения, так и для информационных сессий в пределах данного туннеля.
Информационный канал L2ТР, в отличие от управляющего, использует нумерацию не для повторной пересылки, а для определения потерь пакетов, а также для восстановления их последовательности.
Keepalive
L2TP использует механизм keepalive для различения между простоями туннеля и длительными периодами отсутствия управления либо активности в нем. Механизм реализуется при помощи Hello - управляющих сообщений, передаваемых через фиксированные временные отрезки. При неполучении сообщения Hello L2TP считает туннель нерабочим и возвращает систему в исходное состояние. Механизм keepalive гарантирует, что обрыв соединения между LАС и LNS будет определен с обеих сторон туннеля.
Окончание сессии
Сессию может прервать как LAC, так и LNS путем посылки сообщения CDN. После прерывания последней сессии может быть разорвано и управляющее соединение.
Безопасность
Известно, что в протоколе L2TP существует ряд проблем безопасности. Ниже мы перечислим некоторые подходы к их решению.
Безопасность на концах туннеля
При установлении туннеля его концы могут аутентифицировать друг друга. Такая аутентификация подобна CHAP, обладая при этом защитой против атак искажения и воспроизведения в ходе установления туннеля. Для аутентификации LАС и LNS обязаны использовать единый секретный ключ.
Безопасность на уровне пакетов
L2TP обеспечивает конфиденциальность, аутентификацию и целостность пакетов внутри туннеля. Шифрование данных, а также обеспечение целостности передаваемых сообщений и аутентификацию производимых услуг L2ТР-траффика должна обеспечивать транспортная среда.
L2ТР и IPsec
Известно, что IPsec, работая поверх IP, обеспечивает безопасность на пакетном уровне. При этом все информационные и управляющие пакеты L2ТР в туннеле выглядят для IPsec как обычные пакеты UDP/IP. Кроме транспортной безопасности, IPsec создает режим работы, позволяющий туннелировать пакеты IP, а также инструменты контроля доступа для приложений, поддерживающих программу IPsec. Эти инструменты позволяют осуществлять фильтрацию пакетов по характеристикам транспортного и сетевого уровня. В модели туннеля L2TP подобная фильтрация выполняется на уровне PPP или поверх L2TP.
Начало разработки протокола можно отнести к 1997 г., а в 1999 г. появился стандарт RFC2661, описывающий его. Считается, что L2TP объединил в себе лучшие четы L2F и PPTP.
Схема работы
Для установления соединения удаленная система через телефонную сеть PSTN инициирует соединение PPP с LAC. Далее для PPP-соединения LAC прокладывает туннель через LNS, Frame Relay, ATM или Internet, осуществляя доступ к исходной локальной сети. Удаленная система получает адреса от исходной LAN путем согласования с NCP. Авторизация и аутентификация предоставляются таким образом, как если бы удаленный пользователь был напрямую соединен с сервером NAS.
LAC-клиент, использующий программу L2TP, может подключиться к туннелю до исходной локальной сети если машина с LAC-клиентом уже подсоединена к Internet, при этом использование отдельного LAC необязательно. В данном случае создается виртуальное соединение PPP, в котором локальная L2TP LAC создает туннель до LNS. Как и в предыдущем случае, авторизация, адресация и аутентификация будут обеспечиваться областью управления исходной локальной сети.
Обзор протокола
В протоколе L2TP используется 2 типа пакетов: информационные и управляющие сообщения. Первые используются для инкапсуляции кадров РРР, которые пересылаются по туннелю. Вторые – при установлении, поддержании и уничтожении вызовов и туннелей. Для гарантии доставки управляющие сообщения пользуются надежным контрольным каналом в рамках самого L2TP, а информационные сообщения в случае потери посылаются повторно. Дополнительно для обеспечения гарантированной доставки управляющим сообщениям присваивается порядковый номер. Информационные сообщения используют порядковые номера для определения потери кадров и восстановления порядка пакетов.
Формат заголовка
Информация из данного блока может быть интересна специалистам. В познавательных целях этот блок можно пропустить, и сразу приступить к чтению следующего.
И контрольный, и информационный канал L2T0050 используют единый формат заголовка. Перечислим вкратце значения битов в 32-битной последовательности:
0 – бит (T) типа пакета характеризует его разновидность и ему присваивается значение 0 для информационных и 1 – для контрольных сообщений.
1 – бит (L) длины пакета. Если он равен 1 (обязательно для управляющих сообщений), то в пакете присутствует поле «Длина» (с 16 по 31 бит).
2-3 – эти биты зарезервированы и должны устанавливаться в 0 для исходящих и игнорироваться во входящих пакетах.
4 – бит (S) последовательности. В управляющих сообщениях он равен 1. В этом случае в пакете присутствуют поля Nr и Ns.
5 – бит зарезервирован
6 – бит (O) смещения. Если он равен 1, то присутствует поле, определяющее величину смещения.
7 – бит (Р) приоритета. Для управляющих сообщений он равен 0. Если он равен 1 для информационного сообщения, то в очереди оно получает приоритет.
8-11 – биты зарезервированы12-15 – поле «Версия» (Ver) определяет версию заголовков информационных сообщений L2TP. При этом значение 1 предназначено для определения пакетов L2F, если они идут вперемешку с пакетами L2TP. Пакеты с неизвестными значениями Ver должны отбрасываться.
16-31 – поле длины пакета, указывающее (в октетах) длину сообщения.
В поле ID туннеля содержится идентификатор соединения. Они имеют локальное значение, поэтому разные концы туннеля имеют различные идентификаторы. При этом ID туннеля для каждого сообщения должно быть именно таким, каким его ждет получатель. Создается этот идентификатор при формировании туннеля передачи данных.
В поле ID сессии определяется идентификатор сессии туннеля. Идентификаторы сессий также имеют локальное значение и должно быть именно таким, каким его ждет получатель. Создается этот идентификатор при формировании сессии передачи данных.
В поле Ns содержится порядковый номер управляющего или информационного сообщения от 0 и увеличиваясь далее на 1 для каждого следующего сообщения. В поле Nr содержится порядковый номер, следующего ожидаемого сообщения. Следовательно, Nr равен Ns последнего пришедшего сообщения плюс 1.
Если в пакете присутствует поле «Величина смещения», оно определяет место начала поля данных, при этом содержимое заполнения смещения не определяется.
Протокольные операции
Процедура установления РРР-сессии туннелирования L2ТР состоит из двух этапов:
- Установление канала управления для туннеля.
- Создание сессии по запросу исходящего или входящего вызова.
Управляющее соединение
Перед началом сессии между LАС и LNS должно быть реализовано управляющее соединение, которое включает безопасную идентификацию партнеров и определение версии L2ТР, а также возможностей канала и т.д. В процессе установления этого соединения производится простая CHAP-подобная аутентификация.
Установление сессии
После того, как управляющее соединение установлено, компьютеры могут формировать индивидуальные сессии. Каждая из них соответствует одному РРР-потоку между LАС и LNS. При этом LАС запрашивает у LNS доступ для входных запросов, тогда как LNS запрашивает LAC запуск сессии для обработки исходящих запросов.
После формирования туннеля, РРР-кадры из удаленной системы, которые получает LAC, освобождаются от канальных заголовков, CRC и т.д., инкапсулируются в L2ТР, а затем передаются через туннель. Затем LNS получает L2ТР-пакет, извлекает РРР-кадр и работает с ним, словно он пришел через локальный РРР-интерфейс.
Отправитель сообщения, связанный с определенным туннелем и сессией, помещает в соответствующие спецификации поля заголовка ID туннеля и сессии во всех сообщениях.
Нумерация в канале данных
Для надежной передачи управляющих сообщений используются порядковые номера в заголовке L2TP. Каждый из партнеров поддерживает свою нумерацию, как для управляющего соединения, так и для информационных сессий в пределах данного туннеля.
Информационный канал L2ТР, в отличие от управляющего, использует нумерацию не для повторной пересылки, а для определения потерь пакетов, а также для восстановления их последовательности.
Keepalive
L2TP использует механизм keepalive для различения между простоями туннеля и длительными периодами отсутствия управления либо активности в нем. Механизм реализуется при помощи Hello - управляющих сообщений, передаваемых через фиксированные временные отрезки. При неполучении сообщения Hello L2TP считает туннель нерабочим и возвращает систему в исходное состояние. Механизм keepalive гарантирует, что обрыв соединения между LАС и LNS будет определен с обеих сторон туннеля.
Окончание сессии
Сессию может прервать как LAC, так и LNS путем посылки сообщения CDN. После прерывания последней сессии может быть разорвано и управляющее соединение.
Безопасность
Известно, что в протоколе L2TP существует ряд проблем безопасности. Ниже мы перечислим некоторые подходы к их решению.
Безопасность на концах туннеля
При установлении туннеля его концы могут аутентифицировать друг друга. Такая аутентификация подобна CHAP, обладая при этом защитой против атак искажения и воспроизведения в ходе установления туннеля. Для аутентификации LАС и LNS обязаны использовать единый секретный ключ.
Безопасность на уровне пакетов
L2TP обеспечивает конфиденциальность, аутентификацию и целостность пакетов внутри туннеля. Шифрование данных, а также обеспечение целостности передаваемых сообщений и аутентификацию производимых услуг L2ТР-траффика должна обеспечивать транспортная среда.
L2ТР и IPsec
Известно, что IPsec, работая поверх IP, обеспечивает безопасность на пакетном уровне. При этом все информационные и управляющие пакеты L2ТР в туннеле выглядят для IPsec как обычные пакеты UDP/IP. Кроме транспортной безопасности, IPsec создает режим работы, позволяющий туннелировать пакеты IP, а также инструменты контроля доступа для приложений, поддерживающих программу IPsec. Эти инструменты позволяют осуществлять фильтрацию пакетов по характеристикам транспортного и сетевого уровня. В модели туннеля L2TP подобная фильтрация выполняется на уровне PPP или поверх L2TP.