Layer 2 Tunneling Protocol (L2TP)
- kalendarbgeu
- Jan 15, 2021
- 5 min read
Updated: Jan 17, 2021
Най-добрите черти на протокола РРТР бяха комбинирани с протокола L2F (Layer 2 Forwarding) на Cisco, за да се създаде L2TP.

L2F беше собствено решение на Cisco, което на практика вече е заменено от L2TP. L2TP е полезен при dialup, ADSL и други сценарии за отдалечен достъп; този протокол разширява използването на РРР, за да даде възможност за VPN достъп на отдалечени потребители. L2TP капсулира РРР кадри, които да се изпащат през Layer 3 IP мрежи или Layer 2 Х.25, Frame Relay или Asynchronous Transfer Mode (ATM) мрежи.
Когато е конфигуриран да използва IP за транспорт, L2TP може да бъде използван като протокол за VPN тунелиране през Интернет. L2TP през IP използва UDP порт 1701 и включва серия от L2TP контролни съобщения за поддръжка на тунела. L2TP използва и UDP, за да изпраща Е2ТР-капсулирани РРР кадри във вид на тунелирани данни.
Капсулираните РРР могат да бъдат криптирани или компресирани. Удостоверяването на L2TP тунела предоставя взаимно удостоверяване между крайните точки на тунела – L2TP access concentrator (LAC) и L2TP network server (LNS), но не защитава контролния трафик или данните за всеки отделен пакет. Освен това механизмът за криптиране на РРР не покрива изисквания за удостоверяване, цялост, защита от атаки с повторение и управление на ключове.
L2TP беше проектиран специално за клиентски връзки към сървъри за достъп до мрежи, както и за връзки шлюз към шлюз. Чрез използването на РРР L2TP печели поддръжка на множество протоколи, например, Internetwork Packet Exchange (IPX) и AppleTalk. РРР също предоставя широка гама от възможности за удостоверяване на потребителя, в това число Challenge Handshake Protocol (CHAP), Microsoft Challenge Handshake Protocol (MS-CHAP), MS-CHAPv2 и ЕАР, който поддържа механизми за удостоверяване с контролни и смарт карти.
L2TP е развит протокол с богато минало в IETF стандартите, който се имплементира от много доставчици.
L2TP/IPSec
L2TP не предоставя самостоятелно никаква цялост на съобщенията. Използва се комбинация L2TP/IPSec, при която L2TP тунелите се явяват полезни данни в IPSec пакети. Установява се ESP връзка в IPsec транспортен режим, последвана от установяването на L2TP канал за контрол и данни. По този начин преноса на данни през VPN се облагодетелства от силната защита на целостта, защита от атаки с повторение, автентичността и поверителността на IPsec, като същевременно посредством РРР получава силно гъвкав начин за удостоверяване на потребителя, тунелно присвояване на адреси, поддръжка на различни протоколи и мултикаст поддръжка. Това е едно добро решение за сигурен отдалечен достъп и сигурни връзки шлюз към шлюз.
Забележка
Стандартът L2TP/IPsec (RFC 3193) дефинира и сценарии, при които се поддържат динамично присвоени IP адреси на L2TP получател и динамично присвоени номера на портове. Това обикновено изисква допълнително договаряне от IPsec IKE фаза 1 и фаза 2, преди да бъде установен контролният L2TP тунел.
Предложена наскоро разработка за L2TP задава метод за компресиране на хедъра при L2TP/IPSec, което спомага за значителното намаляване на натоварването на протокола, като същевременно се запазват предимствата от останалата част от L2TP. Освен това, IPSec в решенията за отдалечен достъп изисква механизмите да поддържат динамичната структура за адресиране на Dynamic Host Configuration Protocol (DHCP) и NAT (Network Address Translation), както и legacy удостоверяване на потребителя.
Удостоверяване
Видът на използваното удостоверяване ще зависи силно от това, дали се изисква идентичност на хоста или идентичност на самия потребител. При процеса на удостоверяване на потребителя на него му се представя покана за включване (login prompt) и от него се изисква да въведе потребителско име и парола. Този вид механизъм е най-широко разпространен и е важно да се наблегне на нуждата да се използват сигурни пароли, които се сменят често. Съществуват и някои алтернативни технологии за удостоверяване, които може да бъдат включени в зависимост от изискванията на мрежата.
Повечето от представляват част от механизмите за удостоверяване, включени в IPSec IKE, или които могат да бъдат използвани с ЕАР. Списъкът включва следните възможности, но далеч не изчерпва всички от тях:
• Еднократни пароли
• Базови контролни карти
• Kerberos
• Електронни сертификати
Често се използва и RADIUS или TACACS+, за да се предостави мащабируемо потребителско удостоверяване, оторизация и бек-енд за отчитане.
Различия между IKE и РРР удостоверяване
L2TP имплементациите използват методи за удостоверяване на РРР, например, CHAP и ЕАР. Въпреки че така се предоставя първоначално удостоверяване, не се предлага потвърждаване на удостоверяването за всеки следващ получен пакет. При IPSec, обаче, след като представящата се страна от ГКЕ е удостоверена, извлечените ключове се използват за удостоверяване, цялост и защита от атаки с повторения на всеки пакет. Различаването на удостоверяването на потребител и устройство е много важно.
Например, ако РРР използва потребителско удостоверяване, а IPSec – удостоверяване на устройството, само устройството се удостоверява чрез пакет и няма никакъв начин да се наложи разделяне. Когато договарянето включва и удостоверяване на потребителя, обаче, ключовете, извлечени за защита на последвалия L2TP/IPSec трафик, ще осигурят удостоверяване на потребителите при всеки пакет.
Удостоверяване чрез сертификати
Тъй като при IPSec протоколът за управление на ключовете (IKE) дава възможност за използване на Х.509 подписани сертификати за удостоверяване, PKI би могъл да предостави схема за мащабируемо разпределено удостоверяване. При VPN сертификатите са по-ограничени, защото се използват само за удостоверяване и поради това водят до по-малко усложнения. Въпреки това, все още няма широко-мащабни имплементации на IPSec VPN с поддръжка на PKI.
Това е така, предимно поради общата сложност и операционна трудност на създаването на инфраструктура за публични ключове, както и поради липсата на взаимодействащи методи, много конкурентни протоколи и някои липсващи компоненти. В момента тече разработка за решаване на тези проблеми. Тази разработка обхваща целия жизнен цикъл на използването на PKI в IPSec преводи: предварителната оторизация на издаването на сертификата, процеса на вписване (заявка и получаване на сертификат), промени и подновявания на сертификати, справки за отнемане, потвърждаване и съхранение.
Когато проблемите бъдат разрешени, VPN операторът ще има възможност да прави следното:
• Да оторизира издаването на серии от сертификати, базирайки се на дефинирани локално критерии.
• Да предоставя PKI-базирана идентификация на потребител и/или машина на VPN участници в голям мащаб по такъв начин, че IPSec участникът да има валидна двойка ключове публичен/личен и PKIX сертификат, който да се използва за изграждане на VPN тунела.
• Да задава съответната политика за оторизация на шлюза и/или клиента при връзки за отдалечен достъп или от тип „сайт към сайт“.
• Да осигурява навреме информация за отнети сертификати, използвани при IKE обмен.
VPN приложение за сигурност
Широко-мащабните VPN изискват предимно използването на протокола IPSec или комбинация от L2TP/IPSec, за да предоставят услуги за сигурност. Някои организации предпочитат да използват само РРТР или L2TP. Тъй като, обаче, IPSec предоставя изчерпателни услуги за сигурност, той би трябвало да се използва при повечето сигурни VPN решения.
Посредством IPSec имате възможност да предоставяте поверителност, цялост и автентичност на мрежовия трафик в следните ситуации:
• Защита на ГР уникаст трафик от краен възел до краен възел, от краен възел до VPN концентратор, от маршрутизатор до маршрутизатор и от краен възел до краен възел с транспортен режим на IPSec.
• Функции за отдалечен достъп на VPN клиенти и шлюзове посредством L2TP, подсигурен от транспортен режим на IPSec.
• Сайт към сайт VPN връзки през външни частни WAN или интернет-базирани връзки посредством тунелен режим на L2TP/IPSec или IPSec.
Comentarios