Configurarea unei conexiuni ppp. protocolul ppp

PPP este standardul de internet pentru transmiterea de pachete IP prin linii seriale PPP acceptă linii sincrone și asincrone. :vendor/MorningStar/papers/sug91 -cheapIP.ps.Z (hârtie) și sug91-cheapIP.shar.Z (diapozitive pentru retroproiector)

2.2 Caracteristici PPP care pot fi prezente sau nu

Pe ambele părți ale compatibilității cu cadrul PPP de bază, trebuie să știți că multe programe adaugă propriile capacități suplimentare. Este recomandabil să rețineți că nu toate programele distribuite gratuit, precum și programele comerciale, au un set complet de toate capabilitățile.

2.3 Glosar PPP

Fiecare tehnologie capătă acronime în timp... PPP nu face excepție. Deoarece aproape toți termenii sunt folosiți în transcrierea lor engleză/americană, mi se pare că traducerea acestor abrevieri nu are sens.

Informații generale

Point-to-Point Protocol (PPP) a fost dezvoltat pentru a rezolva problemele asociate cu numărul insuficient de mijloace standard de încapsulare a protocoalelor de tip „point-to-point IP”. În plus, PPP a fost, de asemenea, proiectat pentru a simplifica emiterea și gestionarea adreselor IP, încapsularea sincronă asincronă și orientată pe biți, multiplexarea protocolului de rețea, configurarea și testarea calității comunicațiilor, detectarea erorilor și opțiuni pentru stabilirea unor astfel de caracteristici ale stratului de rețea ca adrese de configurare. și setarea compresiei datelor. Pentru a susține calitățile de mai sus, PPP trebuie să ofere control asupra familiei de protocoale extinse LCP (Link Control Protocol) și Network Control Protocols (NCP) care sunt utilizate pentru a stabili parametrii de comunicare. Astăzi, PPP acceptă nu numai IP, ci și alte protocoale, inclusiv IPX și DECNet.

Componente PPP

PPP oferă capacitatea de a transmite datagrame pe linii seriale punct la punct. Are 3 componente:

• O metodă de furnizare a încapsulării datagramelor pe linii seriale PPP utilizând protocolul HDLC (High-Level Data Link Control) pentru împachetarea datagramelor prin comunicații PPP.
• LCP extins (Link Control Protocol) pentru instalare, configurare și testare conexiune fizică(testați conexiunea de legătură de date)
• O familie de protocoale (NCP) pentru stabilirea și gestionarea altor protocoale de rețea, cu alte cuvinte: PPP este proiectat să suporte mai multe protocoale de rețea simultan.

Operațiune generală

Când se stabilește o conexiune PPP, driverul PPP trimite mai întâi pachete LCP pentru a configura și (eventual) a testa legătura de comunicație. După ce comunicațiile și capabilitățile suplimentare au fost stabilite după cum este necesar prin LCP, driverul PPP trimite cadre NCP pentru a modifica și/sau configura unul sau mai multe protocoale de rețea. Când acest proces se încheie, atunci pachete de rețea obține posibilitatea de a fi transmis prin conexiunea stabilită. Acesta va rămâne configurat și activ până când anumite pachete LCP sau NCP închide conexiunea sau până când altele eveniment extern, ceea ce va duce la pierderea conexiunii (de exemplu: temporizator de inactivitate sau intervenția utilizatorului)

Cerințe pentru stratul fizic

PPP este adaptat pentru a funcționa cu orice interfață DTE/DCE, inclusiv EIA/TIA-232-C (RS-232), EIA/TIA-422-C (RS-422), EIA/TIA-423-C (RS-423). ) , ITU-T (CCITT) V.35. Singura cerință hardware impusă de PPP este prezența hardware-ului duplex, fie dedicat sau comutat, care poate funcționa pe pachete asincrone sau orientate pe biți sincrone, transparente PPP.

Stratul de legătură PPP

PPP utilizează principiile, terminologia și structura de pachete descrise în documentele ISO referitoare la HDLC (ISO 3309-1979) și versiunea sa extinsă:

• ISO 3309:1984/PDAD1 „Anexa 1: Pornirea/oprirea transmisiei”.
• ISO 3309-1979: descrie structura pachetelor HDLC pentru utilizare în sisteme sincrone.
• ISO 3309:1984/PDAD1: descrie propuneri de modificări la ISO 3309-1979 care ar permite utilizarea sistemelor asincrone.

Procedurile de control PPP folosesc definiții și câmpuri de control standardizate în documentele: ISO 4335-1979 și ISO 4335-1979/Addendum 1-1979.

Format pachet PPP:

Protocolul de control al legăturii PPP

PPP LCP oferă metode pentru stabilirea, configurarea, întreținerea și testarea conexiunilor punct la punct. LCP este împărțit în 4 faze:

• Configurare și comunicare - Înainte de a transmite orice datagramă (ex. IP), LCP trebuie mai întâi să deschidă o conexiune și să efectueze un schimb inițial de parametri de configurare. Această etapă se termină când un pachet care confirmă configurația a fost trimis și primit înapoi.
• Determinarea calității comunicației - LCP permite (dar nu necesită) adăugarea unei etape de testare a canalului de comunicare, această fază va urma imediat după prima; În această fază, se stabilește dacă conexiunea este capabilă să transporte orice protocol de rețea cu o calitate suficientă. Această fază este opțională. LCP trebuie să întârzie transferul oricărui protocol de rețea până la finalizarea acestei etape.
• Setarea setărilor protocolului de rețea - După ce LCP a încheiat definirea parametrilor de comunicare, protocoalele de rețea trebuie configurate independent de NCP-urile corespunzătoare, care pot fi pornite sau oprite în orice moment.
• Sfârșitul conexiunii - LCP poate încheia conexiunea stabilită în orice moment. Acest lucru se poate întâmpla din cauza cererii utilizatorilor sau din cauza unui eveniment fizic, cum ar fi pierderea operatorului sau expirarea unei perioade permise de timp neutilizat al canalului.

Există trei tipuri de pachete LCP:

• Pachete de stabilire - Folosit pentru a stabili și configura comunicații
• Pachete de întrerupere - Folosit pentru întrerupere conexiunea stabilită
• Pachete de salvare a comunicațiilor - Folosit pentru gestionarea comunicațiilor și diagnosticare

2.4 RFC-uri relevante pentru PPP

Aceasta este o listă de RFC-uri legate de PPP. Unele dintre aceste documente (învechite) sunt depășite...

• 1717 - Sklower, K.; Lloyd, B.; McGregor, G.; Carr, DProtocolul PPP Multilink (MP). noiembrie 1994; ora 21 p.m. (Format: TXT=46264 de octeți)
• 1663 - Rand, transmisie de încredere DPPP. iulie 1994; 8 seara. (Format: TXT=17281 octeți)
• 1662 - Simpson, W., edPPP în încadrare asemănătoare HDLC. iulie 1994; ora 25 p.m. (Format: TXT=48058 octeți) (RFC 1549 învechit)
• 1661 - Simpson, W., edThe Point-to-Point Protocol (PPP). iulie 1994; 52 p. (Format: TXT=103026 octeți) (RFC 1548 învechit)
• 1638 - Baker, F.; Bowen, R., edsPPP Bridging Control Protocol (BCP). 1994 iunie; ora 28 p.m. (Format:TXT=58477 octeți)
• 1619 - Simpson, WPPP prin SONET/SDH. mai 1994; 4 p.m. Format: TXT=8893 octeți)
• 1618 - Simpson, WPPP prin ISDN. mai 1994; ora 18.00 (Format: TXT=14896 de octeți)
• 1598 - Simpson, WPPP în X.25. martie 1994; 7 seara. (Format: TXT=13835 octeți)
• 1570 - Simpson, W., ed. Extensii PPP LCP. 1994 ianuarie; ora 18 p.m. (Format: TXT=35719 octeți) (Actualizări RFC 1548)
• 1553 - Mathur, S.; Lewis, M. Comprimarea antetelor IPX peste medii WAN (CIPX). 1993 decembrie; ora 23 p.m. (Format: TXT=47450 octeți)
• 1552 - Simpson, W. Protocolul de control al schimbului de pachete de Internetwork PPP (IPXCP). 1993 decembrie; ora 14 p.m. Format: TXT=29174 octeți)
• 1551 - Allen, M. Novell IPX peste diverse medii WAN IPXWAN). 1993 decembrie; ora 22 p.m. (Format: TXT=54210 octeți) (RFC 1362 învechit)
• 1549 - Simpson, W., ed. PPP în cadrul HDLC. 1993 decembrie; ora 18 p.m. (Format: TXT=36353 octeți) Învechit de RFC 1662)
• 1548 - Simpson, W. Protocolul punct-la-punct (PPP). 1993 decembrie; 53 p. (Format: TXT=111638 octeți) (Învechit RFC 1331; Învechit de RFC 1661; Actualizat de RFC 1570)
• 1547 - Perkins, D. Cerințe pentru un protocol standard de internet punct la punct. 1993 decembrie; ora 21 p.m. Format: TXT=49811 octeți)
• 1378 - PPP AppleTalk Control Protocol (ATCP). Parker, B. 1992 noiembrie; ora 16 p.m. (Format: TXT=28496 octeți)
• 1377 - PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D. 1992 noiembrie; ora 22:00 (Format: TXT=22109 octeți)
• 1376 - Protocolul de control de faza IV PPP DECnet (DNCP). Senum, S.J. noiembrie 1992; ora 18.00 (Format: TXT=12448 octeți)
• 1362 - Allen, M. Novell IPX peste diverse medii WAN IPXWAN). 1992 septembrie; ora 18 p.m. (Format: TXT=30220 octeți)
• 1334 - Protocoale de autentificare PPP. Lloyd, B.; Simpson, W.A. 1992 octombrie; ora 16 p.m. (Format: TXT=33248 octeți)
• 1333 - Monitorizarea calității legăturii PPP. Simpson, W.A. mai 1992; ora 15 p.m. (Format: TXT=29965 octeți)
• 1332 - PPP Internet Protocol Control Protocol (IPCP). McGregor, G. 1992 mai; ora 12. (Format: TXT=17613 octeți) (RFC1172 învechit)
• 1331 - Protocol Point-to-Point (PPP) pentru transmiterea de datagrame multi-protocol prin legături punct-la-punct. Simpson, W.A. mai 1992; 66 p. (Format: TXT=129892 octeți) (Învechit RFC1171, RFC1172; învechit de RFC 1548)
• 1220 - Extensii de protocol punct-la-punct pentru crearea de punte. Baker, F., ed. aprilie 1991; ora 18 p.m. (Format: TXT=38165 octeți)
• 1172 - Opțiuni de configurare inițială Point-to-Point Protocol (PPP). Perkins, D.; Hobby, R. 1990 iulie; 38 p. (Format: TXT=76132 octeți) (Învechit de RFC1331, RFC1332)
• 1171 - Protocol Point-to-Point pentru transmiterea de datagrame multi-protocol prin legături Point-to-Point. Perkins, D. 1990 iulie; 48 p. (Format: TXT=92321 octeți) (Învechit RFC1134; Învechit de RFC1331)
• 1134 - Protocol Point-to-Point: O propunere de transmitere multi-protocol a datagramelor prin legături Point-to-Point. Perkins, D. 1989 noiembrie; 38 p. (Format: TXT=87352 octeți) (Învechit de RFC1171)
• 1144 - Comprimarea antetelor TCP/IP pentru legături seriale de viteză redusă. Jacobson, V. 1990 februarie; 43 p. Format: TXT=120959 PS=534729 octeți)

2.1 Introducere

PPP este un standard de internet pentru transmiterea pachetelor IP prin linii seriale. PPP acceptă linii sincrone și asincrone. Pentru unele puncte din discuția despre PPP, precum și PPP versus SLIP, vă sfătuiesc să vă uitați la documentul de pe ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (paper) și sug91- cheapIP.shar.Z (diapozitive pentru retroproiector)

2.2 Caracteristici PPP care pot fi prezente sau nu

Pe ambele părți ale compatibilității cu cadrul PPP de bază, trebuie să știți că multe programe adaugă propriile capacități suplimentare. Este recomandabil să rețineți că nu toate programele distribuite gratuit, precum și programele comerciale, au un set complet de toate capabilitățile.
Apelare la cerere (apelare la cerere) Conectarea unei interfețe PPP și formarea numerelor de telefon. numere la sosirea pachetului. Dezactivarea interfeței PPP după o perioadă de inactivitate.
Redial Conectarea unei interfețe PPP, care nu va fi deconectată ulterior și va păstra întotdeauna canalul conectat la dispoziția sa.
Campling (vezi Redial)
Instalare de scripturi printr-o serie de mesaje sau conexiuni intermediare pentru a stabili o conexiune PPP, mai mult ca secvențele folosite pentru a stabili o conexiune prin UUCP.
Paralel Configurarea mai multor linii PPP pentru aceeași conexiune la gazdă, pentru a distribui uniform traficul între ele. (În proces de standardizare)
Filtrare Selectarea pachetelor care au sens pentru a începe apelarea liniei și care nu. Pe baza tipului de pachet IP sau TCP sau a TOS (Tipul de serviciu) atunci când luați o decizie. De exemplu, ignorați toate pachetele ICMP.
Comprimare antet Comprimarea antet TCP în conformitate cu RFC1144 Nu este necesară atunci când este utilizat pe linii de mare viteză, dar foarte utilă pe linii de viteză mică.
Server Acceptă conexiuni PPP de intrare, care pot necesita, de asemenea, rutare suplimentară.
Tunnelare Construirea de rețele virtuale printr-o conexiune PPP, printr-un flux TCP, printr-o rețea IP existentă. (Construiți o rețea virtuală printr-o legătură PPP printr-un flux TCP printr-o rețea IP existentă.)
Caracterele orientate pe octeți care nu sunt incluse în setul de caractere standard utilizate la stabilirea unei conexiuni pot fi configurate separat, dar nici nu se suprapun cu cele utilizate la stabilirea unei conexiuni; (Caractere de umplutură de octeți în afara mapei asincrone negociate, configurabile în prealabil, dar nu negociabile.)

2.3 Glosar PPP

Fiecare tehnologie capătă acronime în timp... PPP nu face excepție. Deoarece aproape toți termenii sunt folosiți în transcrierea lor engleză/americană, mi se pare că traducerea acestor abrevieri nu are sens.
ack Recunoaștere
AO Active Open (a devenit recent parte a FSM în RFC1331)
C Închide
Protocolul de autentificare CHAP Challenge-Handshake (RFC1334)
D Stratul inferior în jos
Protocolul de introducere a datelor DES
Arhitectura rețelei digitale DNA
Grupul operativ IETF Internet Engineering.
IP Internet Protocol
IPCP IP Control Protocol.
IPX Internetwork Packet Exchange (stiva de rețea Novell)
Secvența de verificare a cadrelor FCS
FSA Finite State Automation
Mașină cu stări finite FSM
Protocolul de control al legăturii LCP.
Raport de calitate a legăturii LQR.
MD4 Algoritmul de semnătură digitală MD4
MD5 Algoritmul de semnătură digitală MD5
Unitate maximă de recepție MRU
Unitate de transmisie maximă MTU
nak Recunoaștere negativă
Protocolul de control al rețelei NCP.
Codificare NRZ Non-Return to Zero Bit. (SYNC ppp implicit din cauza disponibilității)
Codificare de biți inversată NRZI non-return to zero. (SYNC ppp alternativa preferată la NRZ)
Interconectarea sistemelor deschise OSI
Protocolul de autentificare prin parolă PAP (RFC1334)
Unitate de date protocol PDU (la fel ca pachetul)
PO Pasiv deschis
Protocol PPP punct la punct (RFC1548 /RFC1549,1332,1333,1334,1551,1376,1377,1378)
RCA Receive Configure-Ack
RCJ Primire Cod-Reject
RCN Receive Configure-Nak sau -Reject
RCR+ Primește o cerere de configurare bună
RER Primire Echo-Request
Solicitare RFC pentru comentarii (standard de internet)
RTA Primește Terminate-Ack
RTR primire cerere de terminare
RUC Primește cod necunoscut
sca Trimite Configurare-Ack
scj Trimite cod-Reject
scn Trimiteți Configure-Nak sau -Reject
scr Trimite Configurare-Solicitare
ser Trimite Echo-Răspuns
sta Trimite Terminate-Ack
str Trimitere Terminate-Request
ST-II Stream Protocol
TO+ Timeout cu contor > 0
TO- Timeout cu contorul a expirat
VJ Van Jacobson (algoritm de compresie antet RFC1144)
Servicii de rețea XNS Xerox
Informații generale

Point-to-Point Protocol (PPP) a fost dezvoltat pentru a rezolva problemele asociate cu numărul insuficient de mijloace standard de încapsulare a protocoalelor de tip „point-to-point IP”. În plus, PPP a fost, de asemenea, proiectat pentru a simplifica emiterea și gestionarea adreselor IP, încapsularea sincronă asincronă și orientată pe biți, multiplexarea protocolului de rețea, configurarea și testarea calității comunicațiilor, detectarea erorilor și opțiuni pentru stabilirea unor astfel de caracteristici ale stratului de rețea ca adrese de configurare. și setarea compresiei datelor. Pentru a susține calitățile de mai sus, PPP trebuie să ofere control asupra familiei de protocoale extinse LCP (Link Control Protocol) și Network Control Protocols (NCP) care sunt utilizate pentru a stabili parametrii de comunicare. Astăzi, PPP acceptă nu numai IP, ci și alte protocoale, inclusiv IPX și DECNet.

Componente PPP

PPP oferă capacitatea de a transmite datagrame pe linii seriale punct la punct. Are 3 componente:

* O metodă de furnizare a încapsulării datagramelor pe linii seriale PPP utilizând protocolul HDLC (High-Level Data Link Control) pentru ambalarea datagramelor prin comunicații PPP.
* LCP extins (Protocol de control al legăturii) pentru stabilirea, configurarea și testarea conexiunii fizice (testați conexiunea legăturii de date)
* O familie de protocoale (NCP) pentru stabilirea și gestionarea altor protocoale de rețea, cu alte cuvinte: PPP este proiectat să suporte mai multe protocoale de rețea simultan.

Operațiune generală

Când se stabilește o conexiune PPP, driverul PPP trimite mai întâi pachete LCP pentru a configura și (eventual) a testa legătura de comunicație. După ce comunicațiile și capabilitățile suplimentare au fost stabilite după cum este necesar prin LCP, driverul PPP trimite cadre NCP pentru a modifica și/sau configura unul sau mai multe protocoale de rețea. Când acest proces se încheie, pachetele de rețea pot fi transmise conexiunea stabilită. Acesta va rămâne configurat și activ până când anumite pachete LCP sau NCP închid conexiunea sau până când apare un eveniment extern care duce la pierderea conexiunii (de exemplu: un cronometru de inactivitate sau intervenția utilizatorului)
Cerințe pentru stratul fizic

PPP este adaptat pentru a funcționa cu orice interfață DTE/DCE, inclusiv EIA/TIA-232-C (RS-232), EIA/TIA-422-C (RS-422), EIA/TIA-423-C (RS-423). ) , ITU-T (CCITT) V.35. Singura cerință hardware impusă de PPP este prezența hardware-ului duplex, fie dedicat sau comutat, care poate funcționa pe pachete asincrone sau orientate pe biți sincrone, transparente PPP.
Stratul de legătură PPP
—————

PPP utilizează principiile, terminologia și structura de pachete descrise în documentele ISO referitoare la HDLC (ISO 3309-1979) și versiunea sa extinsă:

* ISO 3309:1984/PDAD1 „Anexa 1: Pornirea/oprirea transmisiei”.
* ISO 3309-1979: descrie structura pachetelor HDLC pentru utilizare în sisteme sincrone.
* ISO 3309:1984/PDAD1: descrie propuneri de modificări la ISO 3309-1979 care ar permite utilizarea sistemelor asincrone.

Procedurile de control PPP folosesc definiții și câmpuri de control standardizate în documentele: ISO 4335-1979 și ISO 4335-1979/Addendum 1-1979.

Format pachet PPP:
1 1 1 2 Variabila 2 sau 4
Flag Protocolul de control al adresei DATE FCS

Flag: Un octet care indică începutul sau sfârșitul unui pachet. Câmpul flag conține secvența binară: 01111110.
Adresă: Un octet care conține secvența binară: 11111111, Adresă de difuzare standard. PPP nu acceptă unificarea stației.
Control: Un octet care conține secvența binară: 00000011, care este trimis pentru a transmite datele utilizatorului în pachete nedivizate. (pentru transmiterea datelor utilizatorului într-un cadru nesecvențial.
Protocol: 2 octeți codifică protocolul împachetat în timpul protocolului PPP. Valorile protocolului pot fi găsite în documentul Solicitare pentru comentarii (RFC) de numere atribuite.
Date: 0 sau mai mulți octeți care alcătuiesc datagrama protocolului specificat în câmpul „Protocol”. Sfârșitul câmpului de informații este determinat prin găsirea secvenței de sfârșit și a secvenței de 2 octeți în câmpul FCS. În mod implicit, lungimea maximă a câmpului de informații este de 1500 de octeți. Cu toate acestea, de comun acord, ținând cont de utilizarea PPP, pot fi utilizate alte lungimi de câmp
Secvență de verificare a cadrelor (FCS): De obicei, 16 biți (2 octeți). Cu toate acestea, prin acord reciproc, poate fi utilizat controlul integrității pachetelor pe 32 de biți (4 octeți).

Protocolul de control al legăturii PPP

PPP LCP oferă metode pentru stabilirea, configurarea, întreținerea și testarea conexiunilor punct la punct. LCP este împărțit în 4 faze:

* Configurare și comunicare - Înainte de a transmite orice datagramă (ex. IP), LCP trebuie mai întâi să deschidă o conexiune și să efectueze un schimb inițial de parametri de configurare. Această etapă se termină când un pachet care confirmă configurația a fost trimis și primit înapoi.
* Determinarea calitatii comunicarii - LCP permite (dar nu impune) adaugarea unei faze de testare a canalului de comunicare, aceasta faza urmând imediat dupa prima. În această fază, se stabilește dacă conexiunea este capabilă să transporte orice protocol de rețea cu o calitate suficientă. Această fază este opțională. LCP trebuie să întârzie transferul oricărui protocol de rețea până la finalizarea acestei etape.
* Stabilirea setărilor protocolului de rețea - După ce LCP-ul a încheiat definirea parametrilor de comunicare, protocoalele de rețea trebuie configurate independent de către NCP-urile corespunzătoare, care pot fi pornite sau oprite în orice moment.
* Sfârșitul conexiunii - LCP poate încheia conexiunea stabilită în orice moment. Acest lucru se poate întâmpla din cauza cererii utilizatorilor sau din cauza unui eveniment fizic, cum ar fi pierderea operatorului sau expirarea unei perioade permise de timp neutilizat al canalului.

Există trei tipuri de pachete LCP:

* Pachete de stabilire - Folosit pentru a stabili și configura comunicații
* Pachete de întrerupere - Folosit pentru a întrerupe o conexiune stabilită
* Pachete de salvare a comunicațiilor - Folosit pentru gestionarea comunicațiilor și diagnosticare

2.4 RFC-uri relevante pentru PPP

Aceasta este o listă de RFC-uri legate de PPP. Unele dintre aceste documente (învechite) sunt depășite...

* 1717 - Sklower, K.; Lloyd, B.; McGregor, G.; Carr, DProtocolul PPP Multilink (MP). noiembrie 1994; ora 21 p.m. (Format: TXT=46264 de octeți)
* 1663 - Rand, transmisie de încredere DPPP. iulie 1994; 8 seara. (Format: TXT=17281 octeți)
* 1662 — Simpson, W., edPPP în încadrare asemănătoare HDLC. iulie 1994; ora 25 p.m. (Format: TXT=48058 octeți) (RFC 1549 învechit)
* 1661 — Simpson, W., edThe Point-to-Point Protocol (PPP). iulie 1994; 52 p. (Format: TXT=103026 octeți) (RFC 1548 învechit)
* 1638 - Baker, F.; Bowen, R., edsPPP Bridging Control Protocol (BCP). 1994 iunie; ora 28 p.m. (Format:TXT=58477 octeți)
* 1619 - Simpson, WPPP prin SONET/SDH. mai 1994; 4 p.m. Format: TXT=8893 octeți)
* 1618 - Simpson, WPPP prin ISDN. mai 1994; ora 18.00 (Format: TXT=14896 de octeți)
* 1598 - Simpson, WPPP în X.25. martie 1994; 7 seara. (Format: TXT=13835 octeți)
* 1570 — Simpson, W., ed. Extensii PPP LCP. 1994 ianuarie; ora 18 p.m. (Format: TXT=35719 octeți) (Actualizări RFC 1548)
* 1553 - Mathur, S.; Lewis, M. Comprimarea antetelor IPX peste medii WAN (CIPX). 1993 decembrie; ora 23 p.m. (Format: TXT=47450 octeți)
* 1552 - Simpson, W. Protocolul de control al schimbului de pachete de Internetwork PPP (IPXCP). 1993 decembrie; ora 14 p.m. Format: TXT=29174 octeți)
* 1551 - Allen, M. Novell IPX peste diverse medii WAN IPXWAN). 1993 decembrie; ora 22 p.m. (Format: TXT=54210 octeți) (RFC 1362 învechit)
* 1549 — Simpson, W., ed. PPP în cadrul HDLC. 1993 decembrie; ora 18 p.m. (Format: TXT=36353 octeți) Învechit de RFC 1662)
* 1548 - Simpson, W. The Point-to-Point Protocol (PPP). 1993 decembrie; 53 p. (Format: TXT=111638 octeți) (Învechit RFC 1331; Învechit de RFC 1661; Actualizat de RFC 1570)
* 1547 - Perkins, D. Cerințe pentru un protocol standard de internet punct la punct. 1993 decembrie; ora 21 p.m. Format: TXT=49811 octeți)
* 1378 - PPP AppleTalk Control Protocol (ATCP). Parker, B. 1992 noiembrie; ora 16 p.m. (Format: TXT=28496 octeți)
* 1377 - PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D. 1992 noiembrie; ora 22:00 (Format: TXT=22109 octeți)
* 1376 - PPP DECnet Phase IV Control Protocol (DNCP). Senum, S.J. noiembrie 1992; ora 18.00 (Format: TXT=12448 octeți)
* 1362 - Allen, M. Novell IPX peste diverse medii WAN IPXWAN). 1992 septembrie; ora 18 p.m. (Format: TXT=30220 octeți)
* 1334 - Protocoale de autentificare PPP. Lloyd, B.; Simpson, W.A. 1992 octombrie; ora 16 p.m. (Format: TXT=33248 octeți)
* 1333 - Monitorizarea calității legăturii PPP. Simpson, W.A. mai 1992; ora 15 p.m. (Format: TXT=29965 octeți)
* 1332 - PPP Internet Protocol Control Protocol (IPCP). McGregor, G. 1992 mai; ora 12. (Format: TXT=17613 octeți) (RFC1172 învechit)
* 1331 - Protocol Point-to-Point (PPP) pentru transmiterea de datagrame multi-protocol prin legături punct-la-punct. Simpson, W.A. mai 1992; 66 p. (Format: TXT=129892 octeți) (Învechit RFC1171, RFC1172; învechit de RFC 1548)
* 1220 - Extensii de protocol Point-to-Point pentru bridge. Baker, F., ed. aprilie 1991; ora 18 p.m. (Format: TXT=38165 octeți)
* 1172 - Opțiuni de configurare inițială Point-to-Point Protocol (PPP). Perkins, D.; Hobby, R. 1990 iulie; 38 p. (Format: TXT=76132 octeți) (Învechit de RFC1331, RFC1332)
* 1171 - Protocol Point-to-Point pentru transmiterea de datagrame multi-protocol prin legături Point-to-Point. Perkins, D. 1990 iulie; 48 p. (Format: TXT=92321 octeți) (Învechit RFC1134; Învechit de RFC1331)
* 1134 - Protocol Point-to-Point: O propunere pentru transmiterea multi-protocol a datagramelor prin legături Point-to-Point. Perkins, D. 1989 noiembrie; 38 p. (Format: TXT=87352 octeți) (Învechit de RFC1171)
* 1144 - Comprimarea antetelor TCP/IP pentru legături seriale de viteză redusă. Jacobson, V. 1990 februarie; 43 p. Format: TXT=120959 PS=534729 octeți)

PPP (protocol de rețea)

PPP(Engleză) Protocol punct la punct) - protocol punct-la-punct al stratului de legătură de date (Data Link) al modelului de rețea OSI. Folosit de obicei pentru a stabili o comunicație directă între două noduri de rețea, poate oferi autentificarea conexiunii, criptarea (folosind ECP, RFC 1968) și compresia datelor. Folosit pe multe tipuri rețele fizice: cablu modem nul, linie telefonică, celulară etc.

Adesea, există subtipuri ale protocolului PPP, cum ar fi Protocolul Point-to-Point peste Ethernet (PPPoE), utilizat pentru conectarea prin Ethernet și, uneori, prin DSL; și Point-to-Point Protocol over ATM (PPPoA), care este utilizat pentru conexiuni prin ATM Adaptation Layer 5 (AAL5), care este principala alternativă la PPPoE pentru DSL.

PPP este o întreagă familie de protocoale: Protocolul de control al legăturii (LCP), Protocolul de control al rețelei (NCP), Protocoalele de autentificare (PAP, CHAP), PPP Multilink (MLPPP).

Principalele caracteristici

Protocolul PPP a fost dezvoltat pe baza HDLC și a adăugat câteva caracteristici care se găseau anterior doar în protocoalele proprietare.

Configurare automată

Odată ce conexiunea a fost stabilită, o rețea suplimentară poate fi configurată deasupra acesteia. În mod obișnuit, este utilizat Protocolul de control al protocolului Internet (IPCP), deși Protocolul de control al schimbului de pachete Internetwork (IPXCP) și Protocolul de control AppleTalk (ATCP) au fost cândva populare. Protocolul de control al protocolului Internet versiunea 6 (IPv6CP) va deveni mai răspândit în viitor, atunci când IPv6 înlocuiește IPv4 ca protocol principal al nivelului de rețea.

Suport multi-protocol

PPP permite ca mai multe protocoale de nivel de rețea să funcționeze pe un singur canal de comunicație. Cu alte cuvinte, fluxurile de date ale diferitelor protocoale de rețea (, Novell IPX etc.), precum și datele de protocol, pot fi transmise într-o conexiune PPP strat de legătură retea locala. Pentru fiecare protocol de rețea se folosește Network Control Protocol (NCP), care îl configurează (negociază niște parametri de protocol).

Detectarea legăturilor în buclă

PPP detectează loopback-urile folosind o caracteristică care include numere magice. Când un nod trimite mesaje PPP LCP, acestea pot include un număr magic. Dacă linia este în buclă, nodul primește un mesaj LCP cu propriul său mesaj număr magicîn loc să primească un mesaj cu numărul magic al clientului.

Cele mai importante caracteristici

• Link Control Protocol stabilește și termină conexiunile, permițând nodurilor să definească setările de conexiune. De asemenea, acceptă atât codificări orientate pe octeți, cât și pe biți.
• Protocolul de control al rețelei este utilizat pentru a defini setările stratului de rețea, cum ar fi adresă de rețea sau setările de compresie după ce conexiunea a fost stabilită.

Opțiuni de configurare PPP

Deoarece PPP include protocolul LCP, puteți controla următorii parametri LCP:

• Autentificare. RFC 1994 descrie Protocolul de autentificare prin strângere de mână Challenge (CHAP), care este protocolul de autentificare preferat pentru PPP, deși uneori este încă folosit Protocolul de autentificare cu parolă (PAP). O altă opțiune pentru autentificare este Extensible Authentication Protocol (EAP).
• Comprimare. Mărește efectiv debitul unei conexiuni PPP prin comprimarea datelor din cadru. Cei mai cunoscuți algoritmi de compresie a cadrelor PPP sunt Stacker și Predictor.
• Eroare detectata. Include Quality-Protocol și ajută la identificarea buclelor de feedback prin Magic Numbers RFC 1661.
• Multicanal. Multilink PPP (MLPPP, MPPP, MLP) oferă metode de distribuire a traficului pe mai multe legături fizice în timp ce partajează o singură conexiune logică. Această opțiune permite un debit crescut și asigură echilibrarea sarcinii.

cadru PPP

Fiecare cadru PPP începe și se termină întotdeauna cu steag 0x7E. Acesta este urmat de un octet de adresă și un octet de control, care sunt întotdeauna egali cu 0xFF și, respectiv, 0x03. Datorită probabilității de potrivire a octeților într-un bloc de date cu steaguri rezervate, există un sistem pentru corectarea automată a datelor „problematice” cu recuperarea ulterioară.

Câmpurile Flag, Address and Control (HDLC frame header) pot fi omise și nu transmise, dar asta dacă PPP negociază acest lucru în timpul configurării (folosind LCP). Dacă PPP este încapsulat în pachete L2TP, atunci câmpul Flag nu este transmis.

Tip de cadru de date PPP

Câmpul „Date”, cadru PPP, la rândul său, este împărțit în alte două câmpuri: steag-ul de protocol (care determină tipul de date până la sfârșitul cadrului) și datele în sine.

• Indicatoarele de protocol de la 0x0XXX la 0x3XXX identifică protocoalele de nivel de rețea. De exemplu, protocolul popular corespunde steagului 0x0021 și Novell IPX - 002B.
• Semnalele de protocol de la 0x4XXX la 0x7XXX identifică protocoalele cu trafic redus.
• Indicatoarele de protocol de la 0x8XXX la 0xBXXX identifică protocolul de control al rețelei (NCP).
• Steaguri de protocol de la 0xCXXX la 0xEXXX identifică protocoalele de control. De exemplu, 0xC021 indică faptul că cadrul conține date LCP Link Control Protocol.

Activări și faze ale canalului PPP

Fazele PPP conform RFC 1661 sunt enumerate mai jos:

• Link Dead. Această fază are loc atunci când conexiunea este întreruptă sau una dintre părți a indicat să nu se conecteze (de exemplu, utilizatorul a întrerupt conexiunea modemului.)
• Faza de stabilire a legăturii. În această fază, Link Control este configurat. Dacă configurarea a avut succes, controlul trece la faza de autentificare sau la faza de protocol Network-Layer, în funcție de necesitatea autentificarea.
• Faza de autentificare. Această fază este opțională. Permite părților să se verifice reciproc înainte de a stabili o conexiune. Dacă verificarea are succes, controlul intră în faza Network-Layer Protocol.
• Faza protocolului de nivel de rețea. În această fază, este apelat NCP pentru protocolul dorit. De exemplu, IPCP este utilizat pentru a stabili servicii IP. Transferul de date pentru toți are succes protocoale stabilite are loc și în această fază. În această fază este inclusă și închiderea protocoalelor de rețea.
• Faza de terminare a conexiunii. Această fază închide legătura. Este apelat în cazul eșecurilor de autentificare, dacă au existat atât de multe erori de sumă de control încât ambele părți au decis să închidă conexiunea, dacă conexiunea s-a terminat în mod neașteptat sau dacă utilizatorul s-a deconectat. Această fază încearcă să închidă totul cât mai bine posibil, în condițiile date.

Documente RFC

Protocolul PPP definit în RFC 1661 (The Point-to-Point Protocol, iulie 1994). Au fost scrise un număr de RFC-uri înrudite pentru a defini modul în care diferite protocoale de rețea, inclusiv TCP/IP, DECnet, AppleTalk, IPX și altele, funcționează cu PPP.

• RFC 1661, Standard 51, Protocol punct la punct (PPP)
• RFC 1662, Standard 51, Utilizarea HDLC în dezvoltarea PPP
• RFC 5072, IPv6 și PPP

Note

Vezi si

• P.L.I.P. (Engleză) Rusă

• Autentificare. Routerele conectate schimbă mesaje de autentificare. Sunt disponibile două opțiuni de autentificare: bazată pe PAP și bazată pe CHAP.

• Comprimare. Această caracteristică mărește debitul efectiv al conexiunilor PPP prin reducerea cantității de date per cadru transmise prin legătură. Protocolul decomprimă cadrul la destinație. Există două protocoale de compresie disponibile pe routerele Cisco: Stacker și Predictor.

• Eroare detectata. Această funcție detectează condițiile de defecțiune. Parametrii Calitate și Numărul Magic ajută la asigurarea unui canal de transmisie de date fiabil, fără bucle. Câmpul Magic Number este utilizat pentru a detecta canalele care au o buclă. Până la finalizarea cu succes a negocierii parametrului de configurare Magic-Number, va fi transmisă o valoare nulă pentru acest parametru. Sunt generate valorile parametrilor Magic-Number la întâmplare la fiecare capăt al conexiunii.

• PPP apel invers. Reapelarea PPP este utilizată pentru a îmbunătăți securitatea. Prin utilizarea acestei opțiuni de protocol LCP, routerul Cisco poate acționa ca client sau server sună din nou. Clientul efectuează apelul inițial, solicită serverului un apel invers și finalizează apelul inițial. Routerul de apel invers răspunde la apelul inițial și efectuează un apel invers către client pe baza comenzilor de configurare. Comanda folosită este apel invers ppp [ Accept | cerere ] .

După setarea parametrilor, valoarea câmpului corespunzătoare este inserată în câmpul parametru al protocolului LCP.

Comenzi de bază de configurare PPP

Pornirea PPP pe o interfață

Pentru a configura PPP ca metodă de încapsulare utilizată de interfața serială, utilizați comanda de configurare a interfeței încapsulare ppp .

Următorul exemplu activează încapsularea PPP Interfață serială 0/0/0.

R3# configurați terminalul

R3(config)# interfață serială 0/0/0

R3(config-if)# încapsulare ppp

Echipa încapsulare ppp fara argumente. Amintiți-vă că dacă Router CiscoÎncapsularea PPP nu este configurată, atunci încapsularea HDLC va fi utilizată implicit pentru interfețele seriale.

Figura prezintă routerele R1 și R2 configurate să utilizeze atât o adresă IPv4, cât și o adresă IPv6 pe interfețele lor seriale. PPP este o încapsulare de Layer 2 care acceptă diverse protocoale de Layer 3, inclusiv IPv4 și IPv6.

Comenzi de compresie PPP

Puteți configura compresia software punct la punct pe interfețele seriale după activarea încapsulării PPP. Deoarece în acest mod se numește procesul de compresie în mod programatic, poate afecta performanța sistemului. Dacă traficul constă deja din fișiere comprimate, cum ar fi .zip, .tar sau .mpeg, această caracteristică nu trebuie utilizată. Figura prezintă sintaxa comenzii comprima .

Pentru a configura compresia transmisiei PPP, introduceți următoarele comenzi.

R3(config)# interfață serială 0/0/0

R3(config-if)# încapsulare ppp

R3(config-if)# comprima [ predictor | stac ]

Echipa de monitorizare a calității PPP Link

Rețineți că LCP oferă un pas suplimentar de determinare a calității legăturii. În acest moment, LCP examinează legătura pentru a determina dacă calitatea legăturii este suficientă pentru a suporta protocoalele Layer 3.

Echipă calitate ppp procent se asigură că canalul îndeplinește cerințele de calitate stabilite; altfel canalul este închis.

Procentul este calculat atât pentru direcțiile de intrare, cât și pentru cele de ieșire. Calitatea legăturii în amonte este calculată prin compararea numărului total de pachete și octeți trimiși numărul total pachete și octeți primiți de nodul destinație. Calitatea legăturii de intrare este calculată prin compararea numărului total de pachete și octeți primiți cu numărul total de pachete și octeți trimise de nodul destinație.

Dacă procentul de calitate a canalului nu este acceptat, atunci calitatea canalului este considerată scăzută și canalul este dezactivat. Instrumentul de monitorizare a calității (LQM) implementează un mecanism de întârziere pentru a se asigura că canalul nu suferă activare și dezactivare secvențială.

Următorul exemplu de configurare monitorizează datele trimise către canal și previne buclele de generare a cadrelor (vezi figura).

R3(config)# interfață serială 0/0/0

R3(config-if)# încapsulare ppp

R3(config-if)# calitate ppp 80

Pentru a dezactiva instrumentul LQM, utilizați comanda fara calitate ppp .

Comenzi multilink PPP

Multilink PPP (numit și MP, MPPP, MLP sau Multilink) oferă o metodă de distribuire a traficului prin mai multe legături WAN fizice. Multilink PPP oferă, de asemenea, fragmentarea și reasamblarea pachetelor, secvențierea adecvată, capacitatea între furnizori și echilibrarea încărcării traficului de intrare și de ieșire.

MPPP vă permite să fragmentați pachete și să trimiteți acele fragmente simultan prin mai multe legături punct la punct la aceeași adresă de la distanță. Ca raspuns la definit de utilizator Pragul de încărcare deschide mai multe canale fizice. MPPP poate măsura sarcina numai pe traficul de intrare sau numai pe traficul de ieșire, dar nu și sarcina totală pe ambele traficuri.

Configurarea MPPP este un proces în două etape (vezi figura).

Pasul 1. Crearea unui grup multicanal.

• Interfața multicanal este creată de echipă interfață multilink număr .

• În modul de configurare a interfeței, interfeței multilink i se atribuie o adresă IP. În acest exemplu, atât o adresă IPv4, cât și o adresă IPv6 sunt configurate pe routerele R3 și R4.

• Multilink PPP este pornit pe interfață.

• Interfeței i se atribuie un număr de grup multicanal.

Pasul 2. Atribuirea interfețelor unui grup multicanal.

Următoarele setări sunt făcute pe fiecare interfață care face parte dintr-un grup multicanal.

• Încapsularea PPP este activată.

• Multilink PPP este activat.

• Sunteți atribuit unui grup prin specificarea numărului de grup configurat la pasul 1.

Pentru a dezactiva multilink PPP, utilizați comanda nu ppp multilink .

Verificarea setărilor PPP

Pentru a verifica dacă încapsularea HDLC sau PPP este configurată corect, utilizați comanda arată interfețele seriale . Ieșirea comenzii afișează setarea PPP (vezi figura).

După setarea HDLC în ieșirea comenzii arată interfețele seriale Ar trebui să apară linia de încapsulare HDL C. Dacă PPP este configurat, ar trebui să fie afișate și starea LCP și NCP. Rețineți că protocoalele de control al rețelei IPCP și IPV6CP sunt deschise pentru IPv4 și IPv6, deoarece routerele R1 și R2 au atât adrese IPv4, cât și IPv6 instalate.

În fig. arată o listă de comenzi pentru verificarea PPP.

Echipă arată ppp multilink verifică dacă PPP multilink este activat pe R3 (vezi Figura 3).

Ieșirea arată interfața Multilink 1, numele de gazdă ale punctelor finale locale și la distanță și interfețele seriale incluse în grupul multilink.

Autentificare PPP

PPP definește un protocol LCP extensibil care permite negocierea unui protocol de autentificare pentru a verifica identitatea interlocutorului înainte de a permite protocoalelor de nivel de rețea să transporte date prin legătură. RFC 1334 definește două protocoale pentru autentificare, PAP și CHAP (vezi figura).

PAP (Password Authentication Protocol) este un proces foarte simplu în doi pași. Nu folosește criptare. Numele de utilizator și parola sunt trimise necriptate. Odată primită, conexiunea poate fi stabilită. CHAP (Challenge Handshake Authentication Protocol) are un nivel de securitate mai ridicat decât PAP. Utilizează un schimb de chei secrete partajate în trei pași.

Pasul de autentificare a sesiunii PPP este opțional. Dacă este utilizat, peer-ul este autentificat după ce LCP stabilește un canal și selectează un protocol de autentificare. Dacă este utilizat, autentificarea este efectuată înainte de începerea fazei de configurare a protocolului de nivel de rețea.

Opțiunile de autentificare solicită apelantului să introducă informații de autentificare. Acest lucru asigură că utilizatorul are permisiunea de administrator de rețea pentru a efectua apelul. Routerele conectate schimbă mesaje de autentificare.

Protocolul de autentificare a parolei (PAP)

Una dintre numeroasele funcții ale PPP este de a efectua autentificarea de nivel 2 pe lângă autentificare, criptare, controlul accesului și procedurile generale de securitate la alte straturi.

Inițializarea PAP

Protocolul PAP oferă o metodă simplă de verificare a unui peer printr-o strângere de mână în doi pași. PAP este un protocol non-interactiv. Dacă se folosește comanda autentificare ppp pap , numele de utilizator și parola pot fi trimise ca un singur pachet de date LCP în loc ca serverul să solicite un nume de autentificare și să aștepte un răspuns, așa cum se arată în Fig. 1. După ce PPP termină faza de stabilire a conexiunii, nodul la distanță retrimite perechea nume de utilizator/parolă prin canal până când nodul receptor îl confirmă sau finalizează conexiunea.

Finalizarea PAP

La nodul receptor, numele de utilizator-parola este verificat de serverul de autentificare, care fie permite sau refuza conexiunea. Un mesaj de acceptare sau respingere este returnat solicitantului, așa cum se arată în Figura. 2.

PAP nu este un protocol de autentificare puternic. Cu PAP, parolele sunt trimise necriptate, astfel încât nu există protecție împotriva atacurilor de reluare sau a atacurilor repetate de încercare și eroare. Nodul de la distanță controlează frecvența și momentul încercărilor de a intra în rețea.

Cu toate acestea, există situații în care utilizarea PAP este justificată. De exemplu, în ciuda dezavantajelor sale, PAP poate fi utilizat în următoarele condiții.

• O flotă mare de aplicații client instalate care nu acceptă protocolul CHAP

• Incompatibilitate între implementările CHAP de la diferiți furnizori

Procesul de încapsulare și autentificare PPP

Schema din fig. explică procesul de autentificare PPP atunci când se realizează configurarea PPP. Diagrama prezintă un exemplu vizual al logicii de decizie a protocolului PPP.

De exemplu, dacă o solicitare PPP primită nu necesită autentificare, PPP trece la nivelul următor. Dacă o solicitare PPP primită necesită autentificare, cererea poate fi autentificată folosind fie o bază de date locală, fie un server de securitate. După cum se arată în diagramă, după autentificarea cu succes, procesul trece la nou nivel, iar dacă autentificarea eșuează, conexiunea este încheiată și cererea PPP primită este ignorată.

Urmați pașii din figură pentru a vedea cum R1 stabilește o conexiune PPP autentificată CHAP la R2.

Pasul 1. R1 negociază mai întâi o conexiune de legătură cu R2 folosind LCP, iar cele două sisteme sunt de acord să utilizeze autentificarea CHAP în timpul negocierii PPP LCP.

Pasul 2. R2 generează un ID și un număr aleatoriu, apoi trimite aceste date și numele de utilizator către R1 ca pachet de control CHAP.

Pasul 3. Routerul R1 folosește numele de utilizator al contestatorului (R2) și, pe baza acestui nume, face referințe încrucișate pentru a căuta parola corespunzătoare în baza locala date. R1 generează apoi un hash MD5 folosind numele de utilizator al routerului R2, ID-ul, numărul aleatoriu și partajat parola secreta. În acest exemplu, parola secretă partajată este boardwalk.

Pasul 4. Routerul R1 îi trimite apoi routerului R2 ID-ul pachetului de control, valoarea hash și numele său de utilizator (R1).

Pasul 5. R2 generează propria sa valoare hash folosind ID-ul, parola secretă partajată și numărul aleatoriu trimis inițial către R1.

Pasul 6. R2 compară valoarea sa hash cu valoarea trimisă de R1. Dacă valorile se potrivesc, atunci R2 trimite un răspuns de stabilire a legăturii către routerul R1.

Dacă cererea nu reușește autentificarea, este generat un pachet CHAP cu informații de eroare, format din următoarele componente:

• 04 = Tipul mesajului de eroare CHAP

• id = copiat din pachetul de răspuns

• „Eșec de autentificare” sau mesaj text similar clar pentru utilizator.

Parola secretă partajată trebuie să fie identică pe ambele routere R1 și R2.

Configurarea autentificării PPP

Pentru a specifica ordinea în care sunt solicitate protocoalele CHAP și PAP pe o interfață, utilizați comanda de configurare a interfeței autentificare ppp, așa cum se arată în imagine. Pentru a dezactiva autentificarea, utilizați o versiune respinsă a acestei comenzi ( Nu ).

După ce autentificarea CHAP, PAP sau ambele sunt activate, routerul local solicită dispozitiv la distanță dovezi ale autenticității sale. Pentru a face acest lucru, efectuați următorii pași.

• Autentificarea PAP solicită dispozitivului la distanță un nume de utilizator și o parolă pentru a le compara cu intrarea corespunzătoare din baza de date locală cu nume de utilizator sau baza de date la distanță TACACS/TACACS+.

• Autentificarea CHAP trimite o cerere de control către dispozitivul de la distanță. Dispozitivul la distanță trebuie să cripteze valoarea de control utilizând o cheie secretă partajată și să returneze valoarea criptată și numele acesteia routerului local într-un mesaj de răspuns. Routerul local folosește numele dispozitivului la distanță pentru a căuta cheia secretă corespunzătoare în baza de date locală cu nume de utilizator sau în baza de date la distanță TACACS/TACACS+. Îl folosește pe cel găsit Cheia secretă pentru a cripta valoarea de verificare originală și verifică valorile criptate pentru identitate.

Notă. TACACS este un server dedicat de autentificare, autorizare și contabilitate (AAA) utilizat pentru autentificarea utilizatorilor. Clienții TACACS trimit o cerere către serverul de autentificare TACACS. Serverul autentifică utilizatorul, autorizează acțiunile utilizatorului și urmărește acțiunile utilizatorului.

Puteți activa PAP, CHAP sau ambele protocoale. Dacă ambele metode sunt activate, metoda specificată mai întâi este solicitată în timpul negocierii comunicării. Dacă nodul la distanță sugerează utilizarea celei de-a doua metode sau pur și simplu refuză să folosească prima metodă, se încearcă a doua metodă. Unele dispozitive la distanță acceptă doar CHAP, iar altele acceptă doar PAP. Ordinea în care sunt specificate metodele se bazează pe considerații referitoare la capacitatea dispozitivului de la distanță de a negocia corect metoda adecvată, precum și pe considerente de securitate a legăturii de date. Numele de utilizator și parolele PAP sunt trimise ca linii deschiseși poate fi interceptat și reutilizat. Protocolul CHAP a abordat majoritatea găurilor de securitate cunoscute.

Configurarea PPP cu autentificare

Tabelul descrie procedura de configurare a încapsulării PPP și a protocoalelor de autentificare PAP/CHAP. Este important să configurați acest lucru corect deoarece PAP și CHAP folosesc acești parametri pentru autentificare.

Configurarea autentificării PAP

În fig. Este oferit un exemplu de configurare a autentificării PAP bidirecționale. Fiecare router realizează și trece autentificarea, astfel încât comenzile de autentificare PAP corespunzătoare se oglindesc reciproc. Numele de utilizator și parola PAP trimise de fiecare router trebuie să se potrivească cu cele specificate în comandă nume de utilizator Nume parola parola alt router.

Protocolul PAP oferă o metodă simplă de verificare a unui peer printr-o strângere de mână în doi pași. Acest lucru se face numai după ce canalul este creat inițial. Numele de gazdă de pe un router trebuie să se potrivească cu numele de utilizator configurat pentru PPP pe celălalt router. Parolele trebuie să se potrivească și ele. Specificați parametrii care transmit numele de utilizator și parola în comandă ppp pap trimis-nume utilizator Nume parola parola .

Configurarea autentificării CHAP

CHAP verifică periodic identitatea gazdei la distanță folosind o strângere de mână în trei căi. Numele de gazdă de pe un router trebuie să se potrivească cu numele de utilizator configurat pe celălalt router. Parolele trebuie să se potrivească și ele. Procedura se efectuează după crearea inițială a canalului și poate fi repetată în orice moment după stabilirea conexiunii. În fig. Este dat un exemplu de configurare a CHAP.

PPP (Point-to-Point-Protocol) este un protocol de al doilea strat al modelului OSI utilizat pe legăturile WAN. PPP este un protocol deschis, care îi permite să fie utilizat atunci când este necesară conectarea dispozitivelor Cisco cu dispozitive de la alți producători (spre deosebire de HDLC, în ceea ce privește specificația despre care Cisco are propria părere).

Merită să facem imediat o notă importantă: protocolul PPP este multifuncțional și larg răspândit, în același timp, în cadrul cursului CCNA, se ia în considerare doar o singură modalitate de utilizare: conectarea a două routere între ele printr-un cablu serial. De fapt, domeniul de aplicare al protocolului nu se limitează la aceste cazuri. PPP poate funcționa printr-un cablu de modem nul, linie telefonică, V comunicatii celulare. Alte utilizări populare ale PPP sunt încapsularea acestuia în alte protocoale de nivel 2. Permiteți-mi să explic: PPP în sine se află la al doilea nivel al modelului OSI și oferă o conexiune directă între două dispozitive, dar dacă este încapsulat într-un alt protocol de nivel al doilea - Ethernet (PPP over Ethernet - PPPoE), atunci ethernetul va furniza cadre. de la adresa MAC a expeditorului la destinatarul adresei MAC, apoi destinatarul va decapsula cadrul PPP din Ethernet și apoi pentru protocoalele ambalate în PPP (IPv4, IPX, ...) se va crea o „iluzie” completă că conexiunea este punct la punct. În acest caz, PPP însuși se va ocupa de lucruri precum autentificarea și comprimarea traficului. Există și alte moduri de a utiliza PPP, de exemplu PPP peste ATM - PPPoA, Microsoft Windows folosește pentru Crearea VPN Protocolul PPTP, care este, de asemenea, un add-on la PPP. Dar aceasta este o digresiune lirică pentru a clarifica de ce să studiezi PPP. În cursul CCNA Accesarea la WAN, PPP este un protocol pentru conectarea a două routere printr-un cablu serial.

Ce poate face PPP în comparație cu HDLC?

1. Controlul calității liniei (PPP deconectează legătura dacă numărul de erori depășește valoarea specificată).
2. Autentificare folosind PAP sau CHAP.
3. Multilink este o tehnologie care amintește de Etherchannel în Ethernet: mai multe legături diferite sunt combinate într-una singură, cu o viteză egală cu suma legăturilor incluse în ea.
4. PPP Callback este o tehnologie folosită pentru a îmbunătăți securitatea: clientul stabilește o conexiune cu serverul, serverul întrerupe conexiunea și stabilește una nouă, la rândul său - la client.

De fapt, la transmiterea datelor de la router la router, PPP este încapsulat în HDLC, care realizează funcțiile de „transport” pentru cadrele PPP. Puteți citi mai multe despre HDLC în articolul „Protocol HDLC - exemplu de configurare și descriere”. PPP – are o structură stratificată, când un cadru PPP vine din rețea, acesta se ridică prin substraturile interne PPP de jos în sus:

1. Primul substrat al HDLC - primește cadrul, verifică adresa destinatarului, suma de control și transmite informații utile în continuare.
2. Substratul LCP (Link Control Protocol), după cum sugerează și numele, gestionează conexiunea, trimite și primește diverse steaguri de serviciu, monitorizează starea conexiunii (conectat/deconectat), monitorizează calitatea liniei și monitorizează consistența configurației. parametri între puncte.
3. Substratul NCP (Network Control Protocol) este format din cantitate mare module, fiecare dintre acestea comunicând cu un protocol specific al treilea strat (IPv4, IPv6, IPX, AppleTalk, ...). Datorită acestui fapt, într-o conexiune PPP stabilită cu o singură autentificare și parolă, este posibil să se transmită trafic de diferite protocoale de nivel de rețea.

Stabilirea unei conexiuni între două routere folosind protocolul PPP are loc în straturi de jos în sus, întreruperea conexiunii are loc de sus în jos.

Adică, comunicarea se stabilește în această ordine: LCP, NCP, sarcină utilă de nivel al treilea. Și se rupe: sfârșitul transmisiei de date utile, NCP, LCP. După cum puteți vedea, HDLC nu stabilește și nu întrerupe conexiuni, deoarece PPP utilizează cadre HDLC fără confirmarea livrării.

Structura cadrului PPP este următoarea:

1. FLAG este un semn al începutului unui cadru, o secvență specială de zerouri și unu („01111110”), care îi spune destinatarului că va urma corpul cadrului.
2. ADRESĂ – adresa destinatarului, protocolul PPP utilizează întotdeauna transmisia „11111111”.
3. CONTROL – câmpul conține valoarea „00000011”
4. PROTOCOL – un câmp care conține numărul protocolului de nivel al treilea, al cărui pachet este „înfășurat” în acest cadru.
5. DATE – câmp cu date utile ale protocoalelor superioare.
6. FCS verifica suma, care se calculează la trimiterea cadrului și se compară cu recalcularea rezultată, care se face atunci când se primește cadrul. Ca urmare, dacă sumele nu se potrivesc, cadrul este considerat „rupt” și aruncat.
7. FLAG – un semn al sfârșitului unui cadru, conține aceeași valoare ca și semnul începutului unui cadru.

Se activează PPP Echipamente Cisco, după cum am menționat deja, cursul CCNA nu este dificil. Se executa pe interfata:

1. Selectați algoritmul de compresie folosind comanda compress
2. Setăm calitatea liniei, care va fi considerată acceptabilă (dacă numărul de erori este mai mare de conexiunea dată va izbucni). Comanda pentru aceasta este calitate ppp.
3. Selectăm metoda de autentificare PAP sau CHAP (mai multe informații despre aceasta găsiți în articolul „Care este diferența dintre PAP și CHAP”. Metoda de autentificare este setată prin comandă autentificare ppp.
4. Este necesar să configurați utilizatorul sub care routerul nostru se va conecta la altul. Aici comenzile sunt diferite pentru CHAP și PAP. Utilizatorul însuși este adăugat prin comandă nume de utilizator<имя> parola<пароль>, iar acest lucru ar trebui făcut nu pe interfață, ci în modul de configurare globală, dar în cazul utilizării PAP, trebuie să utilizați și comanda de pe interfață ppp pap trimis-nume utilizator <имя> parola<пароль>.

Utilizarea PAP în configurații reale nu este recomandabilă, așa că ne vom limita la un exemplu de configurare CHAP. Deci, să presupunem că topologia este după cum urmează, trebuie să configurați PPP cu autentificarea CHAP. Configurarea pe primul router:

Router#configure terminal Introduceți comenzile de configurare, una pe linie. Încheiați cu CNTL/Z. Router(config)#hostname R1 R1(config)#username R2 parola 123456789 R1(config)#interfață serial 0/3/0 R1(config-if)#en R1(config-if)#encapsulation ppp R1(config-if) )#ppp authentication chap R1(config-if)#ip address 192.168.0.1 255.255.255.0 R1(config-if)#no shutdown %LINK-5-CHANGED: Interfață Serial0/3/0, starea schimbată în jos

Configurarea celui de-al doilea router:

Router#configure terminal Introduceți comenzile de configurare, una pe linie. Încheiați cu CNTL/Z. Router(config)#hostname R2 R2(config)#username R1 parola 123456789 R2(config)#interface serial0/3/0 R2(config-if)#capsulation ppp R2(config-if)#ppp autentificare cap R2(config- if)#adresa ip 192.168.0.2 255.255.255.0 R2(config-if)#no shutdown %LINK-5-CHANGED: Interfață Serial0/3/0, starea schimbată în sus %LINEPROTO-5-UPDOWN: Protocol de linie pe Interfață Serial0 /3/0, starea schimbată în sus

Vă rugăm să rețineți că utilizatorul pe care îl creăm pe routerul R1 are numele R2, iar pe R2 - R1. Acest lucru este necesar, deoarece atunci când un router se conectează la altul, acesta indică numele său, în consecință, celălalt trebuie să cunoască acest nume (vezi-l în lista sa utilizatorii locali). Un alt detaliu important: parolele pentru utilizatorii R1 și R2 trebuie să se potrivească.

Pentru a verifica, putem rula comanda:

R2#sh ip inter brief Interfață Adresa IP OK? Metodă Stare Protocol... Serial0/3/0 192.168.0.2 DA manual sus...

Dacă starea este „sus” și protocolul este „jos”, atunci aceasta înseamnă de obicei că există unele probleme cu PPP - autentificare incorectă, parolele nu se potrivesc, calitatea liniei este mai mică decât cea comandată, etc. În acest caz, va trebui să verificați configurațiile și să rulați debug ppp, ceea ce nu mi-aș dori inamicului meu.