L2TP

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 21. april 2019; checks kræver 14 redigeringer .

L2TP
Navn	Layer 2 Tunneling Protocol
Niveau (ifølge OSI-modellen )	session
Familie	TCP/IP
Oprettet i	1999
Port/ID	1701/ UDP ,500/ UDP (for IKE, til at administrere krypteringsnøgler),4500/ UDP (for IPSEC NAT-Traversal-tilstand),50/ ESP (for IPSEC),51/ AH (for IPSEC)
Formål med protokollen	opbygning af en VPN
Specifikation	RFC 2661

L2TP ( engelsk Layer 2 Tunneling Protocol - Layer 2 tunneling protocol ) - i computernetværk , en tunnelingsprotokol, der bruges til at understøtte virtuelle private netværk . Den største fordel ved L2TP er, at denne protokol giver dig mulighed for at oprette en tunnel ikke kun i IP-netværk, men også i netværk som ATM , X.25 og Frame Relay [1] .

Selvom L2TP fungerer som en linklagsprotokol af OSI-modellen , er det faktisk en sessionslagsprotokol og bruger den registrerede UDP - port 1701 [2] .

Historie

1996 - 1997 - konkurrence mellem L2F protokoller ( Cisco ) og PPTP ( Microsoft )
1997 - aftale mellem udviklere om fælles udvikling af L2TP -protokollen
1999 - RFC 2661 udgivet , der beskriver L2TP -protokollen

Tæller[ af hvem? ] at L2TP -protokollen har inkorporeret de bedste funktioner fra L2F og PPTP [1] .

Arbejdsplan

Diagrammet viser, hvordan L2TP-protokollen fungerer.

LAN - lokale netværk ( Local Area Network ), som er forbundet via L2TP;
Computer - en eller flere computere, der er forbundet direkte til et lokalt netværk;
LNS - L2TP netværksserver, lokal netværksadgangsserver via L2TP;
LAC - L2TP Access Concentrator, en enhed til gennemsigtig forbindelse af sine brugere til LNS gennem et netværk af en eller anden arkitektur;
Fjernsystem - et system, der ønsker at oprette forbindelse til LAN via L2TP;
LAC-klient - en computer, der fungerer som en LAC for sig selv for at oprette forbindelse til LNS;
PSTN - koblet telefonnetværk (Public Switched Telephone Network);
Internettet, Frame Relay eller ATM er netværk med forskellige arkitekturer.

Målet her er at tunnelere PPP -rammer mellem et eksternt system eller klient-LAC og en LNS hostet på LAN [3] .

Fjernsystemet initierer en PPP-forbindelse til LAC'en over det offentlige telefonnetværk (PSTN). LAC'en tunnelerer derefter PPP-forbindelsen over internettet, Frame Relay eller ATM til LNS og får således adgang til kilde-LAN'et. Adresser til fjernsystemet leveres til kilde-LAN gennem forhandling med PPP NCP . Autentificering, autorisation og regnskab kan leveres af LAN-administrationsområdet, som om brugeren var direkte forbundet til NAS -netværksadgangsserveren .

LAC-klienten (værten, der kører L2TP-programmet) kan også deltage i tunneling til kilde-LAN uden at bruge en separat LAC, hvis værten, der indeholder LAC-klientprogrammet, allerede har en internetforbindelse. En "virtuel" PPP-forbindelse oprettes, og det lokale L2TP LAC-program danner en tunnel til LNS. Som i ovenstående tilfælde vil adressering, autentificering, autorisation og regnskab blive leveret af kontrolområdet for kilde-LAN.

Protokoloversigt

L2TP bruger to slags pakker: kontrol- og datameddelelser. Kontrolmeddelelser bruges ved etablering, vedligeholdelse og afslutning af tunneler og opkald. Informationsmeddelelser bruges til at indkapsle PPP-rammer, der sendes over tunnelen. Kontrolmeddelelser bruger en pålidelig kontrolkanal i L2TP for at sikre levering. Informationsmeddelelser sendes ikke igen, når de går tabt.

Protokolstruktur:

PPP rammer
L2TP-informationsmeddelelser	L2TP-kontrolmeddelelser
L2TP-bærer (upålidelig)	L2TP kontrolkanal (pålidelig)
Pakketransport (UDP, FR, ATM osv.)

Kontrolmeddelelsen har et sekvensnummer, der bruges på kontrolkanalen for at sikre pålidelig levering. Informationsmeddelelser kan bruge sekvensnumre til at omarrangere pakker og detektere rammetab. Alle koder sendes i den rækkefølge, der accepteres for netværk.

Titelformat

L2TP-pakkerne til kontrol- og bærerkanalerne bruger det samme header-format:

0	en	2	3	fire	5	6	7	otte	9	ti	elleve	12	13	fjorten	femten	16	31
T	L	x	x	S	x	O	P	x	x	x	x	Version				Længde (opt.)
Tunnel ID																Sessions ID
Ns (opt.)																Nr (opt.)
Offset størrelse (valgfrit)																Offset pude (opt.)......
nyttelast data

Typebitten (T) karakteriserer typen af pakke.

Den er sat til 0 for informationsmeddelelser og 1 for kontrolmeddelelser.

Hvis længdebitten (L) er 1, er længdefeltet til stede.

For kontrolmeddelelser skal denne bit sættes til 1.

De x bits er reserveret til fremtidig brug.

Alle reserverede bits skal sættes til 0 for udgående meddelelser og ignoreres for indgående meddelelser.

Hvis sekvensbitten (S) er 1, er Ns- og Nr-felterne til stede.

S-bitten for kontrolmeddelelser skal sættes til 1.

Hvis offset-bitten (O) er 1, er offsetværdifeltet til stede.

O-bitten for kontrolmeddelelser skal sættes til 0.

Prioritetsbitten (P) skal sættes til 0 for alle kontrolmeddelelser. For informationsmeddelelser, hvis denne bit er sat til 1, har denne informationsmeddelelse prioritet i køen.
Ver-feltet angiver versionen af L2TP-informationsmeddelelsens header.

Værdien 1 er reserveret til at detektere L2F-pakker, når de blandes med L2TP-pakker. Pakker modtaget med et ukendt Ver-felt slettes.

Feltet Længde (valgfrit) angiver den samlede længde af meddelelsen i oktetter.
Tunnel -id'et indeholder ID'et for kontrolforbindelsen. L2TP-tunnel-id'er har kun en lokal betydning. Det vil sige, at forskellige ender af den samme tunnel skal have forskellige ID'er. Tunnel-id'et i hver besked skal være det, som modtageren forventer. Tunnel-id'er vælges, når tunnelen dannes.
Session- id'et angiver identifikatoren for sessionen i denne tunnel. L2TP-sessioner er navngivet med identifikatorer, der kun har lokal betydning. Sessions-id'et i hver besked skal være det, som modtageren forventer. Sessions-id'er vælges, når sessionen dannes.
Ns-feltet angiver serienummeret på informations- eller kontrolmeddelelsen, startende fra nul og stigende med 1 (modulo 216 ) for hver sendt besked.
Feltet Nr indeholder det forventede sekvensnummer for den næste besked. Således gøres Nr lig med Ns af den sidst modtagne besked plus 1 (modulo 216 ) . I datameddelelser er Nr reserveret og skal, hvis det er til stede (som bestemt af S-bit), ignoreres ved modtagelse.
Feltet Offset Size , hvis det findes, angiver antallet af oktetter efter L2TP-headeren, hvor datafeltet skal begynde. Indholdet af den forskudte pladsholder er udefineret. Hvis et offset-felt er til stede, afsluttes L2TP-headeren efter den afsluttende oktet af offset-udfyldningen.

Typer af kontrolmeddelelser

AVP-meddelelsestypen bestemmer den specifikke type kontrolmeddelelse, der skal sendes.

Styr forbindelsesstyring

0 (reserveret)
1 (SCCRQ) Start-Control-Connection-Request
2 (SCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserveret)
6 (HEJ) Hej

Opkaldsstyring

7 (OCRQ) Udgående-opkald-anmodning
8 (OCRP) Udgående-opkald-svar
9 (OCCN) Udgående-opkald-forbundet
10 (ICRQ) Indgående-opkald-anmodning
11 (ICRP) Indgående-opkald-svar
12 (ICCN) Indgående-opkald-forbundet
13 (reserveret)
14 (CDN) Opkald-Afbryd-Send besked

Fejlmeddelelser

15 (WEN) WAN-Error-Notify

PPP session management

16 (SLI) Set-Link-Info

Protokoloperationer

Den nødvendige procedure for etablering af en L2TP-tunneling PPP-session omfatter to trin:

etablering af en kontrolkanal for en tunnel
dannelse af en session i overensstemmelse med anmodningen om et indgående eller udgående opkald.

Tunnelen og den tilsvarende styrekanal skal dannes, før indgående eller udgående opkald påbegyndes. En L2TP-session skal etableres, før L2TP kan sende PPP-rammer gennem tunnelen. Der kan være flere sessioner i den samme tunnel mellem den samme LAC og LNS.

PPP-tunneling:

Kontrolforbindelse

Er den primære, der skal implementeres mellem LAC og LNS, før du starter en session. Etablering af en kontrolforbindelse omfatter sikker identifikation af peeren, samt bestemmelse af L2TP-versionen, linkmuligheder, framing osv.

L2TP inkluderer et enkelt, valgfrit, CHAP -lignende tunnelgodkendelsessystem under etablering af kontrolforbindelse.

Session etablering

Efter vellykket etablering af en kontrolforbindelse kan der dannes individuelle sessioner. Hver session svarer til én PPP-trafik mellem LAC og LNS. I modsætning til etablering af kontrolforbindelse, er sessionsetablering asymmetrisk med hensyn til LAC og LNS. LAC'en anmoder LNS'en om at få adgang til sessionen for indgående anmodninger, og LNS'en anmoder LAC'en om at starte en session for udgående anmodninger.

Når tunnelen er dannet, bliver PPP-frames fra fjernsystemet modtaget af LAC strippet for CRC'er, linkheadere osv. indkapslet i L2TP og videresendt gennem den passende tunnel. LNS modtager L2TP-pakken og behandler den indkapslede PPP-ramme, som om den var blevet modtaget gennem den lokale PPP-grænseflade.

Afsenderen af en meddelelse, der er knyttet til en bestemt session og tunnel, placerer sessions- og tunnel-id'erne (specificeret af peeren) i de relevante overskriftsfelter for alle udgående meddelelser.

Brug af sekvensnumre i en datakanal

Sekvensnumrene, der er defineret i L2TP-headeren, bruges til at organisere pålidelig transport af kontrolmeddelelser. Hver peer opretholder en separat nummerering for kontrolforbindelsen og for hver informationssession i tunnelen.

I modsætning til L2TP-kontrolkanalen bruger L2TP-trafikkanalen meddelelsesnummerering ikke til gentransmission, men til at detektere pakketab og/eller gendanne den oprindelige sekvens af pakker blandet under transport.

LNS kan påbegynde undertrykkelse af meddelelsesnummerering på et hvilket som helst tidspunkt under sessionen (inklusive den første informationsmeddelelse).

Keepalive (Hej) mekanismen

Keepalive-mekanismen bruges af L2TP til at skelne mellem nedetid i tunnelen og lange perioder uden kontrol eller informationsaktivitet på tunnelen. Dette gøres med Hej kontrolmeddelelser, efter at der er gået et nærmere angivet tidsrum siden sidste gang, der blev modtaget en kontrolmeddelelse gennem tunnelen. Hvis Hello-meddelelsen ikke leveres, erklæres tunnelen nede, og systemet vender tilbage til sin oprindelige tilstand. Mekanismen til nulstilling af transportmediet ved at introducere Hello-meddelelser sikrer, at et linkbrud mellem LNS og LAC detekteres i begge ender af tunnelen.

Sessionsafbrydelse

Sessionsafslutning kan initieres af LAC eller LNS og opnås ved at sende en CDN-kontrolmeddelelse. Efter den sidste session er afsluttet, kan kontrolforbindelsen også afsluttes.

Afbrydelse af kontrolforbindelsen

Afslutningen af en kontrolforbindelse kan initieres af LAC eller LNS og udføres ved at sende en enkelt StopCCN kontrolmeddelelse.

Implementering af L2TP gennem et specifikt medie

L2TP-protokollen er selvdokumenterende og kører oven på transportlaget. Der er dog behov for nogle detaljer[ hvad? ] forbindelse til miljøet, for at sikre kompatibiliteten af div[ hvad? ] implementeringer.

Sikkerhedshensyn

L2TP-protokollen står over for adskillige sikkerhedsproblemer i dens drift. Nogle tilgange til løsning af disse problemer diskuteres nedenfor.

Sikkerhed for enden af tunnelen

Tunnelender kan valgfrit autentificere hinanden ved etablering af en tunnel. Denne godkendelse har de samme sikkerhedsattributter som CHAP og har rimelig beskyttelse mod genafspilning og spoofangreb under tunneletableringsprocessen. For at implementere godkendelse skal LAC'er og LNS'er dele en delt hemmelighed.

Sikkerhed på pakkeniveau

At sikre L2TP-sikkerhed kræver, at transportmiljøet er i stand til at levere datakryptering, meddelelsesintegritet og tjenestegodkendelse for al L2TP-trafik. L2TP er selv ansvarlig for fortroligheden, integriteten og autentificeringen af L2TP-pakker inde i tunnelen.

L2TP og IPsec

Når du kører over IP , giver IPsec (sikker IP) sikkerhed på pakkeniveau. Alle L2TP-kontrol- og informationspakker i en bestemt tunnel vises for IPsec-systemet som almindelige UDP/IP-informationspakker. Ud over IP-transportsikkerhed definerer IPsec en driftstilstand, der gør det muligt at tunnelere IP-pakker, samt adgangskontroller, der er nødvendige for applikationer, der understøtter IPsec. Disse værktøjer giver dig mulighed for at filtrere pakker baseret på egenskaberne af netværket og transportlagene. I L2TP-tunnelmodellen udføres lignende filtrering på PPP eller netværkslaget over L2TP.

Noter

↑ 1 2 Vælg VPN-protokol . Hentet 14. marts 2022. Arkiveret fra originalen 23. januar 2022. (ubestemt)
↑ Liste over porte Arkiveret 4. juni 2001 på Wayback Machine på IANA 's websted
↑ L2 Network Layer Tunnel Protocol (L2TP) Arkivkopi dateret 29. december 2011 på Wayback Machine / Yu. A. Semyonov . Telekommunikationsteknologier - telekommunikationsteknologier - v. 3.5 - M.: SSC ITEF, 2010

Links

(Russisk) L2TP (Layer Two Tunneling Protocol) hos Microsoft Technet
(Russisk) Opsætning af L2TP VPN i Windows
(Engelsk) RFC 2661 Layer Two Tunneling Protocol "L2TP".
(Engelsk) RFC 2341 Cisco Layer Two Forwarding (protokol) "L2F". (Forgænger for L2TP.)
(engelsk) RFC 2637 Point-to-Point Tunneling Protocol (PPTP). (Forgænger for L2TP.)
(engelsk) RFC 2809 Implementering af L2TP obligatorisk tunneling via RADIUS.
(engelsk) RFC 2888 Sikker fjernadgang ved hjælp af L2TP.
(engelsk) RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay.
(engelsk) RFC 3145 L2TP Oplysninger om årsag til afbrydelse.
(engelsk) RFC 3193 L2TP-sikkerhed ved hjælp af IPsec.
(engelsk) RFC 3301 Layer Two Tunneling Protocol (L2TP): ATM-adgangsnetværk.
(engelsk) RFC 3308 Layer Two Tunneling Protocol (L2TP) differentierede tjenester.
(engelsk) RFC 3355 Layer Two Tunneling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5).
(Engelsk) RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base.
(Engelsk) RFC 3437 Layer Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation.
RFC 3438 Layer Two Tunneling Protocol ( L2TP) Internet Assigned Numbers: Internet Assigned Numbers Authority (IANA) Overvejelser Opdatering.
(Engelsk) RFC 3573 Signalering af Modem-On-Hold-status i Layer 2 Tunneling Protocol (L2TP).
(engelsk) RFC 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE).
(engelsk) RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3).
(engelsk) RFC 4045 -udvidelser til at understøtte effektiv transport af multicast-trafik i Layer-2 Tunneling Protocol (L2TP).
(engelsk) IANA tildelte numre til L2TP.
(engelsk) L2TP Extensions Working Group (l2tpext) - (hvor fremtidigt standardiseringsarbejde koordineres).
(eng.) L2TP/IPSec fra XP-klient til Windows 2003 Server - L2TP/IPSec fra XP-klient til Windows 2003 Server.

Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen
Fysisk	ethernet RS-232 EIA-422 RS-449 RS-485
kanaliseret	ethernet PPPoE OPP L2F 802.11 WiFi 802.16 WiFi token ring ARCNET FDDI HDLC GLIDE ATM KAN DTM X.25 ramme relæ IEEE 802.1aq SMDS STP ERPS ARP
netværk	IPv4 IPv6 IPsec ICMP IGMP RARP RIP2 OSPF EIGRP GRE IPX
Transportere	TCP ( krypt ) UDP SCTP DCCP RDP/ RUDP RTP SPX TLS 1.3
session	ADSP H.245 iSNS NetBIOS PAP RPC L2TP PPTP RTCP SMPP SCP ZIP SDP
Repræsentation	XDR SSL TLS
Anvendt	BGP HTTP ( S ) DHCP IRC gopher finger SNMP DNS ( SEC ) NNTP XMPP nippe til IPP NTP SNTP E-mail SMTP POP3 IMAP4 _ Filoverførsel FTP TFTP SFTP FTPS webdav SMB Fjernadgang rlogin telnet SSH RDP
Andet anvendt	bitcoin OSCAR MTProto Multicast FTP Multisource FTP bittorrent Gnutella Skype
Liste over TCP- og UDP-porte

Virtual Private Networks (VPN'er)
Teknologi	IPsec L2TP PPTP Split tunneling Lag 2 videresendelsesprotokol Direkte adgang
Software	Hamachi n2n netværksleder NeoRouter åbenvpn rp-pppoe tcpcrypt Vyatta wire vagt
VPN-tjenester	1.1.1.1 ExpressVPN Hotspot Shield Mullvad NordVPN Proton VPN psiphon Surfshark