Метки: L2tp opensuse, l2tp wiki, ошибка 809 l2tp windows 7, l2tp beeline, l2tp kerio beeline, l2tp адрес сервера.
Название: |
Layer 2 Tunneling Protocol |
---|---|
Уровень (по модели OSI): |
Канальный |
Семейство: | |
Создан в: |
1999 г. |
Порт/ID: | |
Назначение протокола: |
построение VPN |
Спецификация: |
RFC 2661 |
L2TP (англ. Layer 2 Tunneling Protocol — протокол туннелирования второго уровня) — в компьютерных сетях туннельный протокол, использующийся для поддержки виртуальных частных сетей. Главное достоинство L2TP состоит в том, что этот протокол позволяет создавать туннель не только в сетях IP, но и в таких, как ATM, X.25 и Frame Relay.[1]
Несмотря на то, что L2TP действует наподобие протокола Канального уровня модели OSI, на самом деле он является протоколом Сеансового уровня и использует зарегистрированный UDP-порт 1701.[2]
Считается, что протокол L2TP вобрал в себя лучшие черты PPTP и L2F.[1]
На диаграмме показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC (L2TP Access Concentrator) и LNS (L2TP Network Server), размещенной в LAN.[3]
Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN (Public Switched Telephone Network). LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, и таким образом осуществляется доступ к исходной LAN. Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккаунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.
LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC, если ЭВМ, содержащая программу LAC-клиента, уже имеет соединение с Интернет. Создается «виртуальное» PPP-соединение, и локальная программа L2TP LAC формирует туннель до LNS. Как и в вышеописанном случае, адресация, аутентификация, авторизация и аккаунтинг будут обеспечены областью управления исходной LAN.
L2TP использует два вида пакетов: управляющие и информационные сообщения. Управляющие сообщения используются при установлении, поддержании и аннулировании туннелей и вызовов. Информационные сообщения используются для инкапсуляции PPP-кадров, пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку. Информационные сообщения при потере не пересылаются повторно.
Структура протокола:
PPP кадры | |
L2TP информационные сообщения | L2TP управляющие сообщения |
L2TP информационный канал (ненадёжный) | L2TP канал управления (надёжный) |
Транспортировка пакетов (UDP, FR, ATM и т.д.) |
Управляющее сообщение имеет порядковый номер, используемый в управляющем канале для обеспечения надежной доставки. Информационные сообщения могут использовать порядковые номера, чтобы восстановить порядок пакетов и детектировать потерю кадров. Все коды посылаются в порядке, принятом для сетей.
Пакеты L2TP для контрольного и информационного каналов используют один и тот же формат заголовка:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 31 | |||||
T | L | x | x | S | x | O | P | x | x | x | x | Версия | Длина(опц) | |||||||||
ID туннеля | ID сессии | |||||||||||||||||||||
Ns (опц) | Nr (опц) | |||||||||||||||||||||
Offset Size (опц) | Offset Pad (опц)...... | |||||||||||||||||||||
Payload data |
Он устанавливается равным 0 для информационных сообщений и 1 — для управляющих.
Для управляющих сообщений этот бит должен быть равен 1.
Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих.
Бит S для управляющих сообщений должен быть равен 1.
Бит O для управляющих сообщений должен быть равен 0.
Значение 1 зарезервировано для детектирования пакетов L2F в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver, отбрасываются.
Тип сообщения AVP определяет специфический тип посылаемого управляющего сообщения.
Управление контрольным соединением
Управление вызовами (Call Management)
Сообщения об ошибках
Управление сессией PPP
Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:
Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.
PPP-туннелирование:
Является первичным, которое должно быть реализовано между LAC и LNS перед запуском сессии. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т. д.
L2TP включает в себя простую, опционную, CHAP-подобную систему аутентификации туннеля в процессе установления управляющего соединения.
После успешного установления управляющего соединения могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.
Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков и т. п., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.
Отправитель сообщения, ассоциированный с определенной сессией и туннелем, помещает ID сессии и туннеля (специфицированные партнером) в соответствующие поля заголовка всех исходящих сообщений.
Порядковые номера, определенные в заголовке L2TP, используются для организации надежной транспортировки управляющих сообщений. Каждый партнер поддерживает отдельную нумерацию для управляющего соединения и для каждой информационной сессии в пределах туннеля.
В отличие от канала управления L2TP, информационный канал L2TP использует нумерацию сообщений не для повторной пересылки, а для детектирования потерь пакетов и/или восстановления исходной последовательности пакетов, перемешанных при транспортировке.
LNS может инициировать запрет нумерации сообщений в любое время в ходе сессии (включая первое информационное сообщение).
Механизм keepalive используется L2TP для того, чтобы различать простои туннеля и длительные периоды отсутствия управления или информационной активности в туннеле. Это делается с помощью управляющих сообщений Hello после заданного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. При недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путем введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля.
Прерывание сессии может быть инициировано LAC или LNS и выполняется путем посылки управляющего сообщения CDN. После того как последняя сессия прервана, управляющее соединение может быть также разорвано.
Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN.
Протокол L2TP является самодокументируемым, работающим поверх уровня, который служит для транспортировки. Однако, необходимы некоторые детали подключения к среде, для того чтобы обеспечить совместимость различных реализаций.
Протокол L2TP сталкивается при своей работе с несколькими проблемами безопасности. Ниже рассмотрены некоторые подходы для решения этих проблем.
Концы туннеля могут опционно выполнять процедуру аутентификации друг друга при установлении туннеля. Эта аутентификация имеет те же атрибуты безопасности, что и CHAP, и обладает разумной защитой против атак воспроизведения и искажения в процессе установления туннеля. Для реализации аутентификации LAC и LNS должны использовать общий секретный ключ.
Обеспечение безопасности L2TP требует, чтобы транспортная среда могла обеспечить шифрование передаваемых данных, целостность сообщений и аутентификацию услуг для всего L2TP-трафика. Сам же L2TP ответственен за конфиденциальность, целостность и аутентифицированность L2TP-пакетов внутри туннеля.
При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы IPsec, как обычные информационные UDP/IP-пакеты. Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты, а также средства контроля доступа, которые необходимы для приложений, поддерживающих IPsec. Эти средства позволяют фильтровать пакеты на основе характеристик сетевого и транспортного уровней. В модели L2TP-туннеля аналогичная фильтрация выполняется на PPP-уровне или сетевом уровне поверх L2TP.
Это заготовка статьи о компьютерных сетях. Вы можете помочь проекту, дополнив её. |
Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP) | |
---|---|
Физический | |
Канальный |
Ethernet • PPPoE • PPP • L2F • 802.11 Wi-Fi • 802.16 WiMax • Token ring • ARCNET • FDDI • HDLC • SLIP • ATM • CAN • DTM • X.25 • Frame relay • Shortest Path Bridging • SMDS • STP • ERPS |
Сетевой | |
Транспортный | |
Сеансовый | |
Представления | |
Прикладной | |
Другие прикладные |
Bitcoin • OSCAR • CDDB • Multicast FTP • Multisource FTP • BitTorrent • Gnutella • Skype |
Виртуальные частные сети (VPN) | |
---|---|
Технологии |
IPsec • L2TP • PPTP • Split tunneling • Layer 2 Forwarding Protocol • DirectAccess |
Программное обеспечение |
Tags: L2tp opensuse, l2tp wiki, ошибка 809 l2tp windows 7, l2tp beeline, l2tp kerio beeline, l2tp адрес сервера.