L2TP-tunnelinstelling en -uitlijning

Downloadopties

PDF (180.5 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (132.9 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (175.7 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:29 januari 2008

Document-id:23980

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

PPP

L2TP

Summary en L2TP-Flow

De PPP/L2TP-verbindingsvolgorde

Debug overgenomen van LAC die PPP en L2TP Call Setup toont

Debug overgenomen van LNS die PPP en L2TP Call Setup toont

De PPP/L2TP-disconnect-volgorde

Debug die van LAC is overgenomen die toont dat PPP en L2TP worden losgemaakt

Debug die van LNS is overgenomen die toont dat PPP en L2TP worden verbroken

Gerelateerde informatie

Inleiding

Dit document behandelt de installatie en verwijdering van de Layer 2 Tunneling Protocol-tunnelverbinding (L2TP). Het document geeft ook een samenvatting van PPP en L2TP.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco IOS® softwarereleases 12.0(1)T en hoger.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

PPP

PPP is een symmetrisch peer-to-peer protocol dat L2 en Layer 3 (L3) verkeer via point-to-point links transporteert. Er zijn drie hoofdonderdelen:

Insluiting
Link Control Protocol (LCP)
Network Control Protocol (NCP)

Datagrammen zijn ingekapseld in PPP. Met de LCP kan worden onderhandeld over configuratieopties om een link te maken. NCP's worden onderhandeld voor elk van de L3 protocollen die op de link lopen.

Tijdens het leven van een PPP zitting, gaat de link door vier afzonderlijke fasen:

Koppel installatie-als deel van de link die fase instelt, gebruikt PPP een LCP-functie die moet worden voltooid en open verklaard voordat de link de authentificatiefase ingaat, indien van toepassing, en onderhandelt over het openen van de netwerklaag. LCP wordt ook gebruikt om de PPP-link te beëindigen.
Verificatie-De authenticatiefase is implementatiespecifiek en is geen verplicht vereiste voor een overgang van LCP naar NCP. Als overeengekomen en overeengekomen tijdens de LCP fase, moet de externe peer zichzelf identificeren en de overeengekomen authenticatiemethode doorgeven voordat PPP naar de netwerklaag verplaatst.
De laag-NCP onderhandeling van het netwerk waarborgt dat beide peers het over de kenmerken van het L3 protocol eens zijn. In het geval van IP wordt het controleprotocol IP Control Protocol (IPCP) genoemd. Naast de onderhandelingen tussen gelijken is er ook een element van toewijzing. Dit is gebruikelijk voor Microsoft Windows-type afstandstoegangsklanten die geen IP-adres hebben toegewezen en vertrouwen op de serviceprovider om het IP-adres bij de verbinding toe te wijzen.
Koppelbeëindiging: de verbinding beëindigingsfase kan op elk moment tijdens de levenscyclus van de vraag worden ingevoerd. LCP wordt gebruikt om het eindverzoek af te leveren.

L2TP

L2TP breidt de point-to-point aard van PPP uit. L2TP biedt een insluitingsmethode voor het verzenden van getunnelde PPP-frames, waardoor de PPP-endpoints via een pakketgeschakeld netwerk kunnen worden getunneld. L2TP wordt meestal ingezet in scenario's op afstand die het internet gebruiken om intranet-diensten aan te bieden. Het concept is van een Virtual Private Network (VPN).

De twee primaire fysieke elementen van L2TP zijn de L2TP Access Concentrator (LAC) en de L2TP Network Server (LNS):

LAC—De LAC is een peer to the LNS die fungeert als één kant van het tunneleindpunt. LAC beëindigt de externe PPP-verbinding en bevindt zich tussen de afstandsbediening en de LNS. Packets worden verzonden naar en van de externe verbinding via de PPP-verbinding. Packets naar en van de LNS worden doorgestuurd via de L2TP-tunnel.
LNS-The LNS is een peer to the LAC die als één kant van het tunneleindpunt dienst doet. LNS is het eindpunt voor de LAC PPP verbonden sessies. Dit wordt gebruikt om de meerdere LAC-getunneled PPP sessies en ingangen naar het particuliere netwerk te bundelen.

Er zijn twee verschillende berichttypes die L2TP gebruikt:

Control boodschappen—L2TP passeert controle- en gegevensberichten via afzonderlijke controle- en gegevenskanalen. Het in-band controlekanaal passeert gesequentieerd beheer van de controle verbinding, vraagbeheer, foutmelding en sessiecontrole berichten. Het initiëren van de controleverbinding is niet specifiek voor de LAC of de LNS, maar eerder voor de tunnelinitiator en -ontvanger die relevant is voor de controleverbindingsinrichting. Er wordt een methode voor gedeelde geheime controle van de uitdagingen gebruikt tussen de eindpunten van de tunnel.
De gegevensberichten—de gegevensberichten worden gebruikt om de PPP-frames in de L2TP-tunnel in te sluiten.

L2TP gebruikt de geregistreerde User Datagram Protocol (UDP)-poort 1701, en het hele L2TP-pakket is ingekapseld in het UDP-datagram. Zoals bij een normale UDP-operatie selecteert de tunnelinitiator een beschikbare UDP-poort en stuurt hij poort nummer 1701 naar de UDP-bestemming. In het antwoord is het bestemmingspoortnummer hetzelfde als het bronpoortnummer dat in de inkomende UDP-header wordt gebruikt. De bronpoort wordt ingesteld op basis van elke vrije haven die wordt gevonden. Nadat de bron- en doelhavens zijn ingericht, moeten de havens voor de duur van de tunnel gelijk blijven. In Cisco IOS-software worden de bron- en doelpoortnummers altijd ingesteld op UDP poort nummer 1701.

Opmerking: Layer 2 Forwarding (L2F) Protocol en L2TP hebben hetzelfde UDP-poortnummer. Het veld Versie in de header stelt u in staat te discrimineren tussen de twee protocollen. Een waarde van 1 geeft L2F aan en een waarde van 2 geeft L2TP aan.

Summary en L2TP-Flow

Het leggen van de controle verbinding en de sessie moet plaatsvinden voordat de PPP frames door de tunnel kunnen worden doorgestuurd.

Na het succesvol instellen van het controlekanaal, worden de sessies gecreëerd voor elke PPP verbinding. Sessievestiging is gericht, met betrekking tot de LAC en de LNS. Voor inkomende oproepen verzoekt de LAC de LNS de sessie te accepteren. Voor uitgaande gesprekken vraagt de LNS de LAC de sessie te aanvaarden.

Het gedeelte PPP/L2TP-verbindingsvolgorde van dit document bevat details over de PPP- en L2TP-gespreksinstelling wanneer een gebruiker van de externe toegang een oproep naar de LAC doet. Dit voorbeeld gebruikt de gedialed number Identification Service (DNIS) om de L2TP-tunnel te openen, hoewel u ook de domeinnaam voor dit doel kunt gebruiken. De reeks toont het begin van de PPP zitting van een router SOHO 2500, de LCP onderhandeling tussen de ver-toegangsgebruiker en LAC, en de gedeeltelijke authenticatie. De LAC gaat dan verder om de L2TP-tunnel en de sessie binnen de tunnel op te zetten. Er wordt een sessie ingesteld voor elke PPP-verbinding tussen de LAC en de LNS. L2TP gebruikt de peer tunnel en de sessieherkenners in alle uitgaande berichten om te multiplexen en demultiplexen PPP verbindingen. Deze identificatiemiddelen worden toegewezen en uitgewisseld tijdens de respectieve fases van de controle- en sessieinrichting. De tunnel- en sessie-ID's hebben alleen lokale betekenis. De tunneleindpunten hebben verschillende kenmerken voor dezelfde tunnel en sessie.

Opmerking: waarde 0 heeft een unieke betekenis en wordt alleen gebruikt wanneer de tunnel- en sessidentificatiecode nog moet worden toegewezen.

Na het opzetten van de tunnel voltooit het PPP-verificatieproces tussen de gebruiker van de toegang op afstand en de LNS. De LAC blijft PPP-frames ontvangen. De link-vormgeving en cyclische redundantie controle (CRC) worden verwijderd, ingekapseld in LT2P en naar de tunnel doorgestuurd naar LNS. Daar wordt het L2TP-pakket ontvangen en behandeld alsof het op een lokale PPP-interface is afgesloten. De onderhandeling van PPP NCP komt voor, en dan wordt IPCP open verklaard. De verbinding is voltooid.

De PPP/L2TP-verbindingsvolgorde

Dit is de verbindingsvolgorde van gebeurtenissen:

De externe gebruiker start een PPP-verbinding. De LAC accepteert de verbinding. Er wordt een PPP-link ingesteld.
LCP wordt overeengekomen tussen de externe gebruiker en LAC. LAC levert een Challenge Handshake Authentication Protocol (CHAP)-uitdaging om een gedeeltelijke verificatie van de externe gebruiker uit te voeren. Het antwoord wordt tijdens de zittingsinstelling naar de LNS gestuurd. Het antwoord wordt verstuurd als attribuut-value pair (AVP) 33 proxy-authenticatie respons in de inkomende-Call-Connected (ICCN).
De DNIS wordt gebruikt om te bepalen of de gebruiker een virtuele privé inbelnetwerk (VPDN) client is.
Omdat er geen bestaande tunnel is voor het nummer (614629) is het noodzakelijk een nieuwe tunnel te creëren. RADIUS wordt gevraagd en de tunnelinformatie wordt gedownload naar de LAC.
De besturingsverbinding wordt gestart. De tunnel bevindt zich in een onbevangen staat:
- De tunnelinitiator (in dit geval de LAC) stuurt een Start-Control-Connection-Application (SCCRQ) naar de LNS. SCCRQ bevat een AVP 11 uitdaging, die erop wijst dat LAC de tunnel met een CHAP-stijl authenticatie wil authenticeren. Hetzelfde geheim is bekend bij beide tunneleindpunten. De tunnel is nu in een WAIT-CTL-REPLY toestand.
- LNS kan de tunnel omhoog brengen zodat LNS met een Start-Control-Connection-Reactie (SCCRP) antwoordt. Het SCCRP bevat een AVP 11-uitdaging en een AVP 13-protestreactie in antwoord op het SCCRQ. De tunnel is nu in een WAIT-CTL-REPLY toestand.
- De LAC reageert met een SCN-bericht (Start-Control-Connected Grid). Het SCCCN bevat een AVP 13 in antwoord op het SCCRP. De tunnel bevindt zich nu in een gevestigde staat.
- De LNS stuurt een ZLB-bericht (ZLB) naar de LAC. Het ZLB-bericht is een sequentiële bevestiging. De tunnel bevindt zich nu in een gevestigde staat.
De tunnelechtheidscontrole is nu voltooid en de tunnel is opgezet. De zitting bevindt zich nu in een onrustige staat.
Nu de tunnel bestaat, wordt er een drievoudige uitwisseling voor het opzetten van sessies binnen de tunnel uitgevoerd:
- LAC stuurt een Inkomend-Call-Aanvraag (ICRQ) met de parameter informatie voor de sessie. De zitting is nu in een Wake Reantwoordstatus.
- LNS stuurt een inkomende-Call-antwoord (ICRP) dat de sessie-ID bevat. De sessie is nu in een Wachten Connect-status.
- De LAC stuurt een ICCN en verstrekt de LNS aanvullende informatie voor de beantwoorde oproep. Deze informatie omvat de LCP informatie van de onderhandeling die de LAC en de externe gebruiker hebben uitgevoerd. De vergadering is nu in een gevestigde staat.
- De LNS stuurt een ZLB-bericht, dat een gesequendeerde bevestiging is, naar de LAC. De vergadering is nu in een gevestigde staat.
Na het opzetten van de sessie wordt er een virtuele access interface gecreëerd op de LNS. De LCP-configuratieinformatie die in de ICN is geleverd, wordt op de virtuele access interface-PPP-stack gedwongen. Deze informatie omvat de gedeeltelijke authenticatie informatie.
De LNS leidt tot een authenticatieprobleem. De proxy-authenticatie respons AVP 33, die werd geleverd in de ICCN, wordt weergegeven.
Normale authenticatie, autorisatie en accounting (AAA) of PPP authenticatie en autorisatie plaatsvinden.
Een RADIUS-toegangsverzoek wordt verzonden voor verificatie en autorisatie per gebruiker.
Er wordt een RADIUS-toegangscontrole ontvangen.

Opmerking: RADIUS is geconfigureerd om het IP-adres toe te staan dat de externe gebruiker heeft aangeboden in de inkomende IPCP configuratie-aanvraag.
Een succesbericht van CHAP wordt naar de externe gebruiker verzonden.
PPP IPCP-onderhandeling wordt voltooid en OPEN verklaard. Een host-route is geïnstalleerd op de externe interface. De externe gebruiker is nu verbonden en de verkeersstroom kan starten.

PPP en L2TP-verbinding, Call Flow