InterIntranet2014 Manual Bolun

Ion Bolun, Victor Andronatiev
Internet şi Intranet
Punct de acces Internet
Mijloace utilizator 1 Mijloace utilizator n
Wi ox
nB
tă
ox nB
Wi
ar
Ruter Ruter
Po
Cablu UTP ∙∙∙∙∙∙∙∙ Cablu UTP
Fig. 4.11. Schema reţelei de calculatoare de creat.
Chişinău 2014
Academia de Studii Economice din Moldova
Institutul Dezvoltării Societăţii Informaţionale
Ion Bolun, Victor Andronatiev
Internet şi Intranet
Chişinău 2014
2
CZU 004.7(075.8)
B 66
Bolun Ion, Andronatiev Victor. Internet şi Intranet.
Chişinău: Editura ASEM, 2014. - 456 p.
În lucrare sunt descrise arhitectura, protocoalele şi serviciile de bază ale
Internet. Sunt elucidate conceptul Intranet, tehnologiile de acces, aspectele
adresării entităţilor de reţea, barierele informatice, punţile, tunelarea şi
reţelele private virtuale. Este definită esenţa şi caracterizată folosirea
serverelor proxy, accesul imediat la resurse prin Hotspot, securitatea
funcţionării şi asigurarea calităţii serviciilor. Aspectele practice de
configurare a componentelor de reţea sunt exemplificate în baza
mijloacelor de reţea MiroTik RouterBoard şi RouterOS.
Manualul este destinat studenţilor ce studiază cursurile Internet şi
Intranet şi Reţele informatice sau similare, dar poate fi util, de asemenea,
tuturor celor interesaţi în însuşirea fundamentelor practice de funcţionare şi
administrare a reţelelor de calculatoare de tehnologie TCP/IP.
Manualul a fost recomandat de catedra Cibernetică şi informatică
economică (pr. verbal nr.11 din 3 iunie 2014) şi aprobat de Senatul ASEM
(pr. verbal nr. 8 din 27 iunie 2014) .
Recenzenţi: prof.univ. Ilie Costaş, prof.univ. Anatol Popescul, conf.univ.
Ştefan Berzan.
Descrierea CIP a Camerei Naţionale a Cărţii
Bolun, Ion
Internet şi Intranet /Ion Bolun, Victor Andronatiev; Acad. de Studii
Econ. din Moldova, Inst. Dezv. Soc. Inform. – Ch.: Dep. Ed.-Poligr. al
ASEM, 2014. – 456 p.
Bibliogr.: p. 435-436 (21 tit.). – 50 ex.
ISBN 978-9975-75-698-3
CZU 004.7(075.8)
B 66
Toate drepturile rezervate autorilor:

 Ion Bolun: cap. 1-11, A1-A6.
 Victor Andronatiev: ss. 4.2-4.9, 5, 6.2-6.6, 7, 8.4-8.8, 9, 11.3-11.5.
All rights reserved.
3
C U P R I N S
INTRODUCERE ............................................................................................. 15
1. INTERNET: GENERALITĂŢI ....................................................................... 16
1.1. Internet – noţiuni generale ............................................................. 16
1.2. Structura Internet ........................................................................... 18
1.3. Modelul de referinţă OSI ISO .......................................................... 19
1.3.1. Descrierea generală a modelului OSI ...................................... 19
1.3.2. Nivelele modelului OSI ............................................................ 23
1.4. Modelul arhitectural şi protocoale TCP/IP ...................................... 26
1.4.1. Modelul arhitectural de reţea TCP/IP ..................................... 26
1.4.2. Protocoale de nivel Aplicaţie ................................................... 27
1.4.3. Protocoale de nivel Transport ................................................. 29
1.4.3.1. Caracterizare generală..................................................... 29
1.4.3.2. Protocolul de control al transmisiei TCP ......................... 29
1.4.3.3. Protocolul datagramă utilizator UDP............................... 30
1.4.4. Protocoale de nivel Internet.................................................... 31
1.4.4.1. Caracterizare generală..................................................... 31
1.4.4.2. Protocolul Internet .......................................................... 33
1.4.4.3. Protocolul ICMP ............................................................... 34
1.4.4.4. Protocolul de notificare explicită a congestiei ECP ......... 35
1.4.5. Protocoale de nivel Legătură................................................... 35
1.4.5.1. Caracteristica generală .................................................... 35
1.4.5.2. Protocolul PPP ................................................................. 36
1.4.5.3. Protocolul MLPPP ............................................................ 41
1.4.5.4. Protocolul MCPPP ............................................................ 42
1.4.5.5. Protocolul ARP ................................................................. 43
1.5. Adresarea în Internet ...................................................................... 44
1.5.1. Adrese IPv4 .............................................................................. 44
1.5.1.1. Adrese şi scheme de adrese IP ........................................ 44
1.5.1.2. Schema 1 de adrese IP ..................................................... 44
1.5.1.3. Schema cu clase de adrese IP .......................................... 45
1.5.1.4. Schema de adrese cu subreţele ....................................... 46
1.5.1.5. Schema CIDR.................................................................... 47
1.5.1.6. Divizarea în subreţele CIDR ............................................. 49
1.5.1.7. Atribuirea de blocuri CIDR ............................................... 49
1.5.2. Adrese IPv4 private ................................................................. 50
4
1.5.3. Adrese IPv4 partajabile ........................................................... 51
1.5.4. Adrese IPv4 legături-locale ...................................................... 51
1.5.5. Adrese IPv4 speciale ................................................................ 51
1.5.6. Caracterizare generală a protocolului IPv6 ............................. 52
1.5.7. Adrese IPv6.............................................................................. 54
1.5.8. Trecerea de la IPv4 la IPv6....................................................... 62
1.5.9. Adrese fizice ale entităţilor de reţea ....................................... 63
1.6. Conectarea la Internet .................................................................... 66
1.6.1. Alternative de conectare ......................................................... 66
1.6.2. Mijloace informatice necesare ................................................ 68
1.6.3. Tehnologii de acces ................................................................. 69
1.7 Servicii în Internet ............................................................................ 75
1.7.1. Accesul şi execuţia de sarcini la distanţă ................................. 75
1.7.1.1. Serviciul de acces şi execuţie de sarcini la distanţă ......... 75
1.7.1.2. Protocolul de terminal de reţea Telnet ........................... 76
1.7.1.3. Protocolul de conectare la distanţă rlogin ...................... 77
1.7.1.4. Protocolul de execuţie de comenzi la distanţă Rexec ..... 78
1.7.1.5 Protocolul de execuţie de proceduri la distanţă RPC ....... 78
1.7.1.6 Protocolul de execuţie de comenzi la distanţă SHELL ...... 78
1.7.1.7 Protocolul de execuţie de comenzi la distanţă SSH .......... 79
1.7.2. Acces, gestiune şi transfer de fişiere la distanţă ..................... 80
1.7.2.1 Serviciul de acces, gestiune şi transfer de fişiere ............. 80
1.7.2.2 Protocolul de transfer de fişiere FTP ................................ 81
1.7.2.3 Protocolul trivial de transfer de fişiere TFTP .................... 81
1.7.3. iPoşta ....................................................................................... 82
1.7.3.1. Serviciul de ipoştă ............................................................ 82
1.7.3.2. Protocolul de accesare a mesajelor Internet IMAP ......... 83
1.7.3.3. Protocolul oficiilor poştale POP ....................................... 84
1.7.3.4. Protocolul de mesagerie extinsă şi prezenţă XMPP ........ 84
1.7.3.5. Protocolul simplu de transfer al ipoştei SMTP ................ 84
1.7.4. Accesul şi transferul de hipertexte WWW .............................. 85
1.7.4.1. Serviciul Web ................................................................... 85
1.7.4.2. Protocolul de transfer de hipertexte HTTP ...................... 86
1.7.4.3. Protocolul de transfer securizat de hipertexte HTTPS..... 87
1.7.5. Ştiri în reţea ............................................................................. 88
1.7.5.1. Serviciul de ştiri în reţea .................................................. 88
1.7.5.2. Protocolul de transfer al ştirilor prin reţea NNTP ............ 88
1.7.6. Forumuri şi teleconversaţii în timp real .................................. 88
5
1.7.6.1. Serviciul de forumuri şi teleconversaţii Internet ............. 88
1.7.6.2. Protocolul de forumuri Internet IRC ................................ 88
1.7.7. Transferul de date în timp real ................................................ 89
1.7.7.1. Serviciul VoIP ................................................................... 89
1.7.7.2. Serviciul de videoconferinţe ............................................ 93
1.7.7.3. Serviciul TV IP .................................................................. 94
1.7.7.4. Protocoalele de transfer date în timp real RTP şi RTCP ... 96
1.7.7.5. Protocolul de gestiune a sesiunilor în timp real RTSP ..... 96
1.7.7.6. Protocoalele de iniţiere a sesiunii SIP şi SIPS ................... 96
1.7.7.7. Protocolul de gestiune a porţilor multimedia MGCP ...... 97
1.7.8. Serviciul SNMP ........................................................................ 97
1.7.9. Securizarea accesului şi a transferului de date ....................... 98
1.7.9.1. Esenţa securizării informaţionale în reţele ...................... 98
1.7.9.2. Protocolul de securizare a conexiunilor SSL .................. 102
1.7.9.3. Protocolul de securizare a conexiunilor TLS .................. 102
1.7.9.4. Protocolul de securizare socluri SOCKS ......................... 103
1.7.10. Sistemul numelor de domenii DNS ..................................... 104
1.7.11. Configurarea dinamică a staţiilor DHCP .............................. 106
1.7.12. Sincronizarea timpului în reţea ........................................... 107
1.7.12.1. Protocoalele de timp în reţea NTP şi SNTP .................. 107
1.7.12.2. Protocolul de timp Time .............................................. 107
2. CONCEPTUL INTRANET ......................................................................... 108
2.1 Esenţa intranet ............................................................................... 108
2.2. Avantaje intranet ........................................................................... 108
2.3. Caracteristici importante ale intranet ........................................... 109
2.4. Funcţionalităţi de bază ale intranet............................................... 112
2.5. Aspecte de creare şi dezvoltare a intranet .................................... 113
3. MIJLOACE DE REȚEA MIKROTIK .................................................................. 115
3.1. Compania MikroTik ....................................................................... 115
3.2. Echipamente de reţea MikroTik .................................................... 115
3.3. Sistemul de operare MikroTik RouterOS ....................................... 123
3.4. Licențe RouterOS........................................................................... 125
3.5. Sistemul de operare MikroTik SwOS ............................................. 128
3.6. Monitorul de rețea Dude .............................................................. 128
4. INTRODUCERE ÎN FOLOSIREA ROUTEROS .................................................... 129
4.1. Accesarea RouterOS ...................................................................... 129
4.1.1. Aspecte generale de accesare şi gestiune a RouterOS .......... 129
4.1.2. Conectarea fizică PC-ruter ..................................................... 129
6
4.1.3. Descărcarea iprogramelor Mikrotik ...................................... 130
4.1.4. Descrierea generală a WinBox .............................................. 130
4.1.4.1. Destinația WinBox ......................................................... 130
4.1.4.2. Prima conectare la ruter folosind WinBox .................... 131
4.1.4.3. Interfaţa de lucru a WinBox........................................... 135
4.1.4.4. Zona de lucru și ferestrele derivate ale WinBox ............ 135
4.1.4.5. Gestiunea RouterOS din linia de comandă Terminal ..... 136
4.1.4.6. Regimul Safe Mode ....................................................... 137
4.1.5. Utilita WebFig ........................................................................ 138
4.1.6. Accesul şi gestiunea RouterOS de la consolă ........................ 140
4.1.6.1. Noţiuni generale ............................................................ 140
4.1.6.2. Accesul la ruter folosind Telnet ..................................... 140
4.1.6.3. Accesul la ruter folosind SSH ......................................... 141
4.1.6.4. Sistemul de comenzi al RouterOS .................................. 141
4.2. Conectarea la Internet prin ruter .................................................. 144
4.2.1. Reţeaua de calculatoare de configurat ................................. 144
4.2.2. Configurarea cartelei de rețea a calculatorului ..................... 146
4.2.3. Configurarea legăturii calculator-ruter utilizator .................. 148
4.2.4. Configurarea legăturii ruter utilizator-poartă implicită......... 150
4.2.5. Configurarea legăturii calculator-Internet ............................ 153
4.2.6. Reguli de respectat şi unele nereguli posibile ....................... 155
4.2.7. Identitatea ruterului .............................................................. 156
4.3. Gestiunea utilizatorilor .................................................................. 156
4.4. Gestiunea serviciilor RouterOS ..................................................... 158
4.5. Gestiunea fişierelor în RouterOS ................................................... 159
4.6. Monitorizarea timpului folosind NTP ............................................ 160
4.6.1. Aspecte generale ................................................................... 160
4.6.2. Clientul NTP ........................................................................... 161
4.6.3. Setarea orei locale folosind Clock ......................................... 162
4.6.4. Serverul NTP .......................................................................... 162
4.7. Actualizarea şi reconfigurarea RouterOS ....................................... 163
4.7.2. Actualizarea RouterOS .......................................................... 163
4.7.3. Declasarea RouterOS ............................................................. 166
4.7.4. Gestiunea sistemului de module ........................................... 166
4.8. Crearea şi folosirea copiilor de rezervă ale RouterOS ................... 168
4.8.2. Crearea şi folosirea copiilor de rezervă binare ...................... 169
7
4.8.3. Crearea şi folosirea copiilor de rezervă textuale ................... 171
4.9. Instalarea, resetarea şi reinstalarea RouterOS .............................. 172
4.9.1. Resetarea RouterOS .............................................................. 172
4.9.2. Instalarea RouterOS de pe CD ............................................... 173
4.9.3. Instalarea RouterOS folosind utilita Netinstall ...................... 173
4.10. Gestiunea licenţei RouterOS ....................................................... 174
4.10.1. Vizualizarea licenţei RouterOS ............................................ 174
4.10.2. Actualizarea licenţei RouterOS ............................................ 174
4.10.3. Cheia licenţei şi declasarea RouterOS ................................. 174
4.10.4. Schimbarea nivelului licenţei .............................................. 175
4.10.5. Folosirea licenţei ................................................................. 175
5. IBARIERELE – FIREWALLS ........................................................................... 176
5.1. Esenţa i-barierelor ......................................................................... 176
5.1.1. Noţiuni generale .................................................................... 176
5.1.2. iBarierele de nivel reţea ........................................................ 177
5.1.3. iBarierele de nivel Aplicaţie ................................................... 177
5.1.4. iBarierele proxy ..................................................................... 178
5.1.5. iBariere RouterOS .................................................................. 178
5.2. Filtrarea pachetelor ....................................................................... 179
5.2.1. Lanţuri de transfer date ........................................................ 179
5.2.2. Reguli de filtrare: caracteristici, procesare ........................... 180
5.2.3. Protecţia ruterului la intrare – reguli de filtrare input .......... 182
5.2.4. Protecţia clienţilor de tranzit – reguli de filtrare forward ..... 185
5.2.5. Procesarea pachetelor generate de ruter – reguli output .... 186
5.3. Monitorizarea conexiunilor ........................................................... 186
5.3.1. Reguli log de înregistrare ...................................................... 186
5.3.2. Lanțuri create de utilizator .................................................... 187
5.3.3. Reguli folosind starea conexiunilor ....................................... 187
5.4. Liste de adrese .............................................................................. 190
5.5. Sistemul de translatare a adreselor NAT ....................................... 192
5.5.1. Noţiune NAT .......................................................................... 192
5.5.2. NAT sursă .............................................................................. 193
5.5.3. NAT destinaţie ....................................................................... 195
5.5.4. Limitări NAT ........................................................................... 197
5.6. Alte informaţii privind folosirea i-barierelor ................................. 198
6. CALITATEA SERVICIILOR – QOS ................................................................... 200
6.1. Aspecte generale QoS ................................................................... 200
6.1.1. Noţiune QoS .......................................................................... 200
8
6.1.2. Funcţionalităţi QoS în RouterOS............................................ 200
6.1.3. Cozi şi discipline în RouterOS ................................................ 201
6.1.4. Tipuri de cozi în RouterOS ..................................................... 204
6.1.5. Sistemul de cozi HTB ............................................................. 205
6.2. Marcarea diferitelor categorii de trafic ......................................... 210
6.2.1. Esența marcării Mangle ......................................................... 210
6.2.2. Definirea de reguli de marcare Mangle................................. 211
6.3. Cozi simple .................................................................................... 213
6.3.1. Esența cozilor simple ............................................................. 213
6.3.2. Configurarea de cozi elementare .......................................... 215
6.3.3. Transferuri de date în rafale .................................................. 220
6.3.4. Prioritizarea traficului ............................................................ 221
6.4. Cozi arbore .................................................................................... 222
6.4.1. Esența cozilor arbore ............................................................. 222
6.4.2. Configurarea de cozi arbore .................................................. 222
6.5. Esenţa şi folosirea disciplinei PCQ ................................................. 223
6.5.1. Esenţa PCQ ............................................................................ 223
6.5.2. Exemple de aplicare a PCQ .................................................... 226
6.6. Monitorizarea QoS ........................................................................ 231
6.6.1.Testarea vitezei de transfer date – Bandwidth Test............... 231
6.6.2. Monitorizarea traficului folosind utilita Traffic ..................... 233
6.6.3. Monitorizarea traficului folosind Torch ................................ 234
6.6.4. Monitorizarea utilizării resurselor folosind Graphing ........... 234
6.6.5. Monitorizarea şi gestiunea reţelei folosind SNMP ................ 238
7. GESTIUNEA LOCALĂ A REŢELELOR .............................................................. 242
7.1. Protocolul ARP în RouterOS .......................................................... 242
7.1.1. Funcţionalităţi ARP în RouterOS ............................................ 242
7.1.2. Configurarea ARP .................................................................. 243
7.2. Configurarea dinamică a staţiilor – DHCP ..................................... 245
7.2.1. Configurarea clienţilor DHCP ................................................. 245
7.2.2. Configurarea serverelor DHCP .............................................. 246
7.2.2.1. Înscrieri DHCP ordinare ................................................. 246
7.2.2.2. Înscrieri DHCP statice .................................................... 247
7.2.3. Relee DHCP ............................................................................ 248
7.3. Accesul imediat autorizat la resurse – Hotspot ............................. 249
7.3.1. Esenţă Hotspot ...................................................................... 249
7.3.2. Instalarea serverelor Hotspot ............................................... 253
7.3.3. Crearea profilurilor utilizatorilor ........................................... 255
9
7.3.4. Crearea profilurilor serverelor .............................................. 255
7.3.5. Crearea conturilor utilizatorilor ............................................ 256
7.3.6. Configurarea perimetrelor de acces...................................... 258
7.3.7. Sistemul de adrese IP obligatorii – IP binding ....................... 259
7.4. Folosirea proxy .............................................................................. 260
7.4.1. Esenţă proxy .......................................................................... 260
7.4.2. Setarea proxy HTTP ordinar .................................................. 261
7.4.3. Setarea proxy transparent .................................................... 262
7.4.4. Setarea i-barierelor HTTP în baza proxy ................................ 263
7.4.5. Evidenţa paginilor Web ......................................................... 266
7.5. Stocarea de date ........................................................................... 267
7.6. Unele instrumente Router OS ....................................................... 268
7.6.1. Utilita Email ........................................................................... 268
7.6.2. Utilita Ping ............................................................................. 269
7.6.3. Utilita Traceroute .................................................................. 271
7.6.4. Utilita Netwatch .................................................................... 272
7.6.5. Utilita Profile ......................................................................... 273
7.6.6. Utilita Packet Sniffer .............................................................. 273
8. REŢELE FĂRĂ FIR....................................................................................... 276
8.1. Reţele fără fir: aspecte generale ................................................... 276
8.1.1. Noţiune şi clasificarea reţelelor fără fir ................................. 276
8.1.2. Particularităţile accesului la mediul fără fir ........................... 277
8.1.3. Caracteristica generală a IEEE 802.11 ................................... 279
8.1.4. Unele particularităţi ale standardului IEEE 802.11n ............. 282
8.1.5. Arhitectura reţelelor IEEE 802.11 .......................................... 285
8.1.5.1. Setul de servicii de bază BSS .......................................... 285
8.1.5.2. Categoriile de bază de reţele IEEE 802.11 ................... 285
8.1.5.3. Reţele IBSS..................................................................... 285
8.1.5.4. Reţele ESS ...................................................................... 285
8.1.5.5. Reţele MBSS .................................................................. 286
8.1.6. Moduri de operare şi setarea reţelelor IEEE 802.11 ............. 288
8.1.6.1. Modurile de operare a reţelelor fără fir ........................ 288
8.1.6.2. Modul ad-hoc de operare a reţelelor fără fir ................ 288
8.1.6.3. Modul infrastructură de operare a reţelelor fără fir ..... 288
8.1.6.4. Mecanismele de securizare a reţelelor fără fir .............. 288
8.1.6.5. Punţile în reţele fără fir ................................................. 288
8.1.6.6. Sistemele de distribuire fără fir WDS ............................ 288
8.1.6.7. Modalităţile de operare a punctelor de acces............... 290
10
8.1.7. Securitatea reţelelor fără fir .................................................. 290
8.1.7.1. Aspecte generale ........................................................... 290
8.1.7.2. Autentificarea IEEE 802.1x ............................................ 292
8.1.7.3. Protocolul WEP .............................................................. 293
8.1.7.4. Protocolul WPA ............................................................. 293
8.1.7.5. Protocolul WPA2 ........................................................... 294
8.1.7.6. Autentificarea cu chei pre-partajate PSK ...................... 296
8.2. RouterOS în reţele 802.11 ............................................................. 296
8.2.1. Funcţionalităţi RouterOS pentru reţele fără fir ..................... 296
8.2.2. Cartele pentru interfeţe fără fir ............................................ 297
8.2.3. Opţiunile de bază de configurare a WNIC ............................. 297
8.2.4. Instrumente de monitorizare WLAN ..................................... 299
8.2.4.1. Utilita Scanner ............................................................... 299
8.2.4.2. Utilita Frequency Usage................................................. 300
8.2.4.3. Utilita Alignment ........................................................... 300
8.2.4.4. Utilita Wireless Sniffer ................................................... 300
8.2.4.4. Utilita Snooper ............................................................... 301
8.2.5. Modurile de operare a interfeţelor fără fir ........................... 302
8.2.6. Selectarea benzii şi a lăţimii de bandă a canalului ................ 305
8.2.7. Selectarea frecvenţei canalului ............................................. 307
8.2.8. Opţiunile avansate de configurare a WNIC ........................... 307
8.2.9. Conformarea reglementărilor naţionale în domeniu ............ 309
8.2.10. Selectarea protocolului de acces la mediul fără fir ............. 309
8.3. Conectarea fără fir la AP a unei LAN cablate ................................. 312
8.3.1. Conexiunea de creat.............................................................. 312
8.3.2. Configurarea minimă a ruterului-staţie client ....................... 313
8.3.3. Configurarea adiţională a ruterului folosind Connect List ..... 314
8.4. Crearea unei reţele iBSS simple .................................................... 315
8.4.1. Reţeaua iBSS de creat............................................................ 315
8.4.2. Configurarea minimă a ruterului-punct de acces .................. 316
8.4.3. Tabelul interfeţelor fără fir conectate la ruter ...................... 317
8.4.4. Conectarea fără fir a unei staţii la AP .................................... 317
8.4.5. Configurarea puterii semnalului de acces la AP .................... 318
8.5. Gestiunea ataşării staţiilor la AP în baza adreselor MAC ............... 318
8.5.1. Autentificarea implicită a staţiilor ......................................... 318
8.5.2. Înaintarea implicită a pachetelor .......................................... 319
8.5.3. Lista de acces a AP de către staţii .......................................... 319
8.5.4. Lista de conectare a staţiei la AP ........................................... 321
11
8.6. Securitatea în rețele fără fir RouterOS .......................................... 324
8.6.1. Funcționalități de securitate fără fir ale RouterOS ................ 324
8.6.2. Configurarea parametrilor de securitate .............................. 326
8.7. Setări specifice 802.11n ................................................................ 327
8.8. Setarea protocoalelor fără fir MikroTik ......................................... 328
8.8.1. Configurarea operării semiduplex ......................................... 328
8.8.2. Configurarea operării duplex folosind Nstreme Dual ........... 329
9. FOLOSIREA PUNŢILOR ÎN REŢELE ................................................................ 331
9.1. Punţile MAC – privire de ansamblu ............................................... 331
9.2. Puntarea interfeţelor Ethernet ...................................................... 335
9.3. Puntarea transparentă a unei legături fără fir ............................... 336
9.4. Crearea unui sistem WDS .............................................................. 339
9.5. Puntarea reţelelor fără fir la distanţă ............................................ 340
10. RUTAREA PACHETELOR ........................................................................... 341
10.1. Esenţă şi metode de rutare ......................................................... 341
10.2. Conceptul rutării pachetelor în Internet ..................................... 343
10.2.1. Protocoale de rutare în Internet ......................................... 343
10.2.2. Tabele de rutare .................................................................. 343
10.2.3. Ruta cea mai specifică ......................................................... 344
10.2.4. Ruta şi poarta implicite ....................................................... 345
10.2.5. Distanța rutei....................................................................... 345
10.2.6. Rute statice şi rute dinamice ............................................... 346
10.2.7. Rute multicale ..................................................................... 346
10.2.8. Alți parametri ai rutelor ...................................................... 347
10.2.9. Un exemplu de definire a rutelor statice ............................ 347
10.3. Protocoale de rutare ................................................................... 349
10.3.1. Protocolul informaţiilor de rutare RIP ................................. 349
10.3.2. Protocolul OSPF ................................................................... 350
10.3.2.1. Caracterizare generală a OSPF..................................... 350
10.3.2.2. Zone OSPF.................................................................... 352
10.3.2.3. Rutere OSPF ................................................................. 353
10.3.2.4. Metrica căilor OSPF ..................................................... 356
10.3.2.5. Tipuri de mesaje OSPF ................................................. 356
10.3.2.6. Descoperirea vecinilor ................................................. 357
10.3.2.7. Anunţuri stare-legături ................................................ 358
10.3.2.8. Sincronizarea LSDB ...................................................... 362
10.3.2.9. Exemplu de configurare a zonelor AS .......................... 363
10.3.2.10. Tabelele de rutare şi structura lor ............................. 369
12
10.3.2.11. Calcularea tabelelor ruterelor AS monozonă ............ 371
10.3.2.12. Calcularea tabelelor ruterelor AS multizonă ............. 374
10.3.2.13. Formatul pachetelor OSPF......................................... 376
10.3.2.14. Extensii OSPF ............................................................. 376
10.3.2.15. Avantaje şi dezavantaje OSPF faţă de RIP ................. 377
10.3.3. Protocolul IS-IS .................................................................... 377
10.3.4. Protocoalele IGRP şi EIGRP .................................................. 378
10.3.5. Protocolul BGP .................................................................... 381
10.3.6. Protocolul MME .................................................................. 382
10.4. Rutarea pachetelor în RouterOS ................................................. 383
10.4.1. Baza informaţiilor de rutare – RIB ....................................... 383
10.4.2. Tipurile, originea și starea rutelor ....................................... 385
10.4.3. Rute conectate .................................................................... 385
10.4.4. Rute cu porţi interfaţă ......................................................... 386
10.4.5. Selectarea rutelor ................................................................ 387
10.4.6. Baza informaţiilor de înaintare – FIB ................................... 390
10.4.7. Parametrii rutelor ................................................................ 391
10.5. Implementarea rutării statice în reţele simple ............................ 393
10.6. Implementarea OSPF pe un singur domeniu .............................. 395
11. FOLOSIREA TUNELELOR ÎN REŢELE ............................................................ 397
11.1. Caracteristica generală a tunelării în reţele ................................ 397
11.1.1. Aspecte de bază .................................................................. 397
11.1.1.1. Esenţa tunelării ............................................................ 397
11.1.1.2. PPP ca protocol L2 pentru tunele ................................ 397
11.1.2. Tipuri de tunele ................................................................... 398
11.1.3. Tunele EoIP .......................................................................... 399
11.1.4. Tunele GRE .......................................................................... 399
11.1.5. Tunele IPIP ........................................................................... 400
11.1.6. Tunele PPTP ......................................................................... 400
11.1.7. Tunele L2TP ......................................................................... 403
11.1.8. Tunele PPPoE....................................................................... 406
11.1.8.1. Esenţa PPPoE ............................................................... 406
11.1.8.2. Adresarea punct-la-punct PPPoE................................. 408
11.1.9. Serviciul MLPPPoE ............................................................... 409
11.1.10. Tunele şi reţele private virtuale IPsec ............................... 410
11.1.11. Tunele SSTP ....................................................................... 414
11.1.12. Tunele OpenVPN ............................................................... 416
11.1.13. Reţele locale virtuale – VLAN ............................................ 417
13
11.1.14. Reţele locale virtuale private – VPLS ................................. 418
11.1.15. Alegerea tipului de tunel ................................................... 420
11.2. Configurarea tunelelor în RouterOS ............................................ 421
11.3. Configurări PPP în RouterOS ....................................................... 422
11.3.1. Sistemul PPP ........................................................................ 422
11.3.2. Configurarea fondului de adrese IP – IP Pool ...................... 422
11.3.3. Configurarea PPP Profiles .................................................... 423
11.3.4. Configurarea PPP Secrets .................................................... 425
11.3.5. Configurarea serverului PPP ................................................ 426
11.3.6. Configurarea clientului PPP ................................................. 426
11.3.7. Starea conexiunilor PPP ...................................................... 427
11.4. Tunelarea în reţele locale şi de acces la ISP................................. 427
11.4.1. Funcţionalităţi PPPoE RouterOS .......................................... 427
11.4.2. Configurarea PPPoE Client .................................................. 428
11.4.3. Configurarea PPoE Server ................................................... 429
11.5. Comunicarea securizată între reţele la distanţă .......................... 431
11.5.1. Configurarea tunelelor PPTP ............................................... 431
11.5.1.1. Funcţionalităţi PPTP RouterOS .................................... 431
11.5.1.2. Configurarea PPTP Client ............................................. 431
11.5.1.3. Configurarea şi lansarea PPTP Server .......................... 433
11.5.1.4. Definirea de rute pentru tunele PPTP ......................... 433
11.5.2. Configurarea tunelelor L2TP ............................................... 434
BIBLIOGRAFIE ..................................................................................................................... 435
Anexa 1. Unele echipamente de reţea MikroTik (în baza [2]).................. 437
Anexa 2. Funcționalități ale unor echipamente de reţea Mikrotik ........... 441
Anexa 3. Numere de porturi ale soclurilor Internet .................................. 442
Anexa 4. Lista exemplelor ......................................................................... 445
Anexa 5. Lista sarcinilor practice ............................................................... 448
Anexa 6. Abrevieri ..................................................................................... 449
14
Introducere
Infrastructura Societăţii informaţionale este constituită din reţele
informatice (i-reţele) interconectate. O reţea informatică include reţeaua
de calculatoare respectivă şi aplicaţiile şi serviciile implementate folosind
resursele acesteia.
În lume în 2008 funcţionau peste 1 mld de calculatoare, iar în 2014
numărul acestora va depăşi 2 mld. Cea mai mare parte a calculatoarelor
sunt interconectate în reţele. Anual, la dezvoltarea celor existente şi
crearea de noi reţele se cheltuiesc sute de miliarde de dolari SUA. Devine
evidentă importanţa creării raţionale şi valorificării eficiente a resurselor
acestora.
Lucrarea de faţă este concepută ca suport didactic pentru studierea
unor aspecte teoretice şi formarea de deprinderi practice de bază privind
funcţionarea şi administrarea reţelelor de calculatoare de tehnologie
TCP/IP (Internet şi intranet). Activităţile practice se bazează pe folosirea
mijloacelor de reţea MikroTik RouterBoard şi RouterOS [1], iar conţinutul
lor cuprinde şi subiectele programei „MTCNA training outline” a Mikrotikls
SIA (http://www.mikrotik.com/pdf/MTCNA_Outline.pdf). De aceea lucra-
rea poate fi folosită şi pentru pregătirea către obţinerea certificatului
internaţional Mikrotik Certified Network Associate – MTCNA.
În cele 11 capitole ale cărţii sunt descrise arhitectura Internet, modelul
de referinţă OSI ISO, modelul de reţea TCP/IP şi unele protocoale Internet.
O deosebită atenţie este acordată adresării entităţilor de reţea,
tehnologiilor de acces şi serviciilor de bază în Internet. Pornind de la faptul
folosirii largi a tehnologiei TCP/IP în reţele corporative, este elucidat
conceptul Intranet. Ulterior este dată o caracteristică generală a
mijloacelor de reţea MiroTik şi, prin exemple, aplicarea practică a lor la
crearea de reţele, inclusiv: conectarea la Internet prin ruter; esenţa,
configurarea şi folosirea barierelor informatice (firewall), a punţilor şi a
reţelelor private virtuale; asigurarea calităţii serviciilor; gestiunea locală a
reţelelor; accesul imediat la resurse prin Hotspot; funcţionalităţile şi
folosirea serverelor proxy şi a unor instrumente RouterOS. Aspectele
practice de configurare a reţelelor fără fir este precedată de caracterizarea
particularităţilor lor, descrierea arhitecturii reţelelor IEEE 802.11 şi a
aspectelor de securitate a funcţionării acestora.
Conţinutul este ilustrat cu 249 de figuri şi include 43 de tabele, iar
aspectele practice cuprind 73 de exemple şi 32 de sarcini concrete.
1. INTERNET: GENERALITĂŢI
1.1. Internet – noţiuni generale
Internet este o comunitate globală de reţele de calculatoare
interconectate între ele în baza tehnologiei de reţea TCP/IP (suitei de
protocoale Internet). Aceasta conţine resurse informatice imense şi oferă o
gamă largă de servicii. În Internet sunt interconectate zeci de milioane de
reţele, peste 1 mld de staţii-gazdă de pe toate continentele [11]. În 2013 de
serviciile acestuia se foloseau cca. 2,8 mld de utilizatori (internauţi) [9].
Resursele de uz comun din Internet sunt constituite din:
 servere – calculatoare-gazdă la care operează aplicaţii, se stochează
informaţii şi care prestează diverse servicii informatice mai multor
utilizatori;
 miliarde de fişiere, baze de date în cadrul serverelor cu informaţii din cele
mai diverse domenii;
 subsistemul de comunicaţie, care asigură interconectarea şi transferul de
date între staţii.
Accesul la resursele Internet se efectuează de la calculatoare, în mare
parte de uz individual, şi alte staţii terminale (telefoane, camere de luat
vederi, imprimante, etc.) interconectate în reţea. Gama de servicii Internet se
dezvoltă continuu, perfecţionându-se serviciile în funcţiune şi fiind
implementate altele noi. La acestea se referă:
 teleconectarea de la staţii locale, accesul la baze de date şi execuţia de
sarcini la alte calculatoare din reţea;
 teletransferul de fişiere între calculatoare;
 poşta electronică (i-poşta, e-mail);
 serviciul Web;
 teleconversaţia în timp real, inclusiv teleconferinţe;
 difuzarea de ştiri;
 telefonia IP;
 video IP, inclusiv televiziunea IP;
 afaceri online, inclusiv de comerţ (i-comerţ, e-commerce);
 aplicaţii şi sisteme de căutare a informaţiilor.
Bogăţia informaţiilor, gama largă şi calitatea înaltă a serviciilor şi
simplitatea utilizării au atras atenţia savanţilor, profesorilor, studenţilor şi
elevilor, a politicienilor, producătorilor şi furnizorilor de produse şi servicii, a
oamenilor de cultură, a maselor largi ale populaţiei. Internet a devenit de mai
16
mulţi ani un mediu puternic de recreaţie, activităţi de afaceri, instruire şi
cercetare ştiinţifică: „cine cunoaşte informaţia – stăpâneşte situaţia”.
Fiind o comunitate de reţele, Internet este descentralizată, nu aparţine
vreunei oarecare organizaţii, nu are un organism administrativ strict în
înţelesul obişnuit. Nu există o organizaţie, care să impună anumite reguli pe
Internet, cu excepţia standardelor şi anumitor convenţii general acceptate; în
cadrul fiecărei reţele constituente pot fi folosite regulile şi standardele proprii.
Totuşi, pentru gestionarea generală a Internet, în 1979 este creat Internet
Configuration Control Board – ICCB, acesta fiind redenumit în 1984 în Internet
Advisory Board (IAB), în 1986 – cu cel Internet Activities Board, iar în 1989 – cu
cel Internet Arhitecture Board [10]. Iniţial ICCB, iar apoi IAB supraveghează
funcţionarea tehnică şi dezvoltarea Internet, inclusiv aprobă standardele,
convenţiile şi adresele ce ţin de Internet.
În 1986 în cadrul IAB sunt create comitetele Internet: Internet Engineering
Task Force (IETF) şi Internet Research Task Force (IRTF). Comitetul IETF este
responsabil de dezvoltarea seturilor de specificaţii şi standardelor, organizarea
întrunirilor pe probleme operaţionale şi tehnice.
Principala documentație tehnică privind Internet (şi ARPA) este publicată în
formă de RFC-uri (Request for Comments), disponibile la adresa
www.ietf.org/rfc. Primul RFC ce ține de Internet este publicat în decembrie
1974 (RFC 675 „Specification of Internet Transmission Control Program”;
V.Cerf, Y.Dalal, C.Sunshine) (primul RFC pentru reţeaua ARPA, RFC 1, a fost
publicat la 7 aprilie 1969). RFC-urile cuprind o varietate largă de documente
Internet, inclusiv: propuneri de standarde, proiecte de standarde, standarde
aprobate, cele mai bune practici, protocoale experimentale, istorii ș.a. RFC-
urile pot fi elaborate de specialiști aparte sau de grupuri informale de
specialiști, dar majoritatea acestora sunt rezultatul activității unor grupuri de
lucru (Working Group) formate de IETF.
Comitetul IRTF se ocupă cu problemele de cercetare de perspectivă în
domeniul interconectării de reţele.
În 1988 este creată instituţia de atribuire a adreselor IP – Internet Assigned
Numbers Authority (IANA), în funcţiile căreia intră: alocarea de adrese IP,
alocarea de numere pentru sistemele autonome, gestiunea zonelor de rutare
în cadrul Sistemului Numelor de Domenii (Domain Name System – DNS),
stabilirea identificatoarelor formatelor de fişiere (MIME types, eng.) şi a altor
simboluri şi numere pentru protocoalele Internet. Din 1998 IANA activează ca
departament în cadrul ICANN (Internet Corporation for Assigned Names and
Numbers). Pe lângă funcţiile IANA, compania ICANN se ocupă şi cu stabilirea
de reguli (policies) pentru funcţionarea Internetului.
17
În sfârşit, în 1992 este formată organizaţia utilizatorilor Internet –
Societatea Internet (Internet SOCiety – ISOC, www.isoc.org) cu funcţii de
administrare generală a Internet, comitetul IAB fiindu-i subordonat. Odată cu
crearea ISOC, administrarea Internet trece de la entităţi ale Guvernului SUA
(Departamentul Apărării, apoi Departamentul Comerţului) la o entitate
internaţională publică.
Începând cu anul 1969, Internet se dezvoltă continuu, crescând numărul de
noduri de comunicaţie, de calculatoare şi terminale, extinzându-se aria ei de
cuprindere. Numărul de calculatoare gazdă, anunţate în DNS în perioada 1969-
2014, este prezentat în tabelul 1.1.
Tabelul 1.1. Calculatoare-gazdă (hosts) în DNS (Internet) [11]
Data Gazde Data Gazde
12/1969 4 01/1998 29 670 000
12/1970 13 01/1999 43 230 000
04/1971 23 01/2000 72 398 092
10/1972 31 01/2001 109 574 429
01/1973 35 01/2002 147 344 723
06/1974 62 01/2003 171 638 297
03/1977 111 01/2004 233 101 481
12/1979 188 01/2005 317 646 084
08/1981 213 01/2006 394 991 609
10/1985 1 961 01/2007 433 193 199
01/1989 80 000 01/2008 541 677 360
01/1990 180 000 01/2009 625 226 456
01/1991 376 000 01/2010 732 740 444
01/1992 727 000 01/2011 818 374 269
01/1993 1 313 000 01/2012 888 239 420
01/1994 2 217 000 07/2012 908 585 739
01/1995 4 852 000 01/2013 963 518 598
01/1996 9 472 000 01/2014 1 010 251 829
01/1997 16 146 000
1.2. Structura Internet

Arhitectura unei reţele este determinată de două aspecte principale:
 structura funcţională a reţelei, având în vedere componentele majore,
funcţiile de bază şi interconectarea lor;
 ansamblul de nivele cu serviciile şi protocoalele acestora, realizate în cadrul
serverelor şi a nodurilor de comunicaţie ale reţelei (modelul arhitectural).
18
Internet constă din reţele de tehnologie TCP/IP, interconectate prin rutere,
ce operează ca porţi de comunicare (gateway) cu alte reţele (figura 1.1).
Componentele de bază ale Internet sunt:
 calculatoare şi alte staţii terminale – staţii de lucru, prin intermediul
cărora se realizează accesul la resursele Internet;
 calculatoare-servere – staţii de uz comun, care prestează servicii
informatice utilizatorilor;
 noduri de comunicaţie (rutere, comutatoare, etc.);
 canale şi trunchiuri de transfer date între staţii şi nodurile de
comunicaţie.
G LANF
G
LANB
G
Ruter G
WANA G WANC
G
Poartă
G
LANE G
G
WAND G
MANF G
G
WANH
Internet
Fig. 1.1. Interconectarea reţelelor în Internet.

După cum se vede din figura 1.1, reţelele din Internet pot fi de diverse
categorii: locale (LAN), metropolitane (MAN) sau de arie largă (WAN). De
asemenea, la Internet pot fi conectate şi reţele de tehnologii ce diferă de cea
TCP/IP (în fig. 1.1, reţelele LANF şi WANH).
1.3. Modelul de referinţă OSI ISO

1.3.1. Descrierea generală a modelului OSI
Modelul de referinţă OSI (Open System Interconnection – Interconectarea
sistemelor deschise) al Organizaţiei Internaţionale de Standardizare
(International Standard Organization – ISO) a fost elaborat în scopul
standardizării aspectelor generale de realizare şi interconectare a reţelelor de
calculatoare. El este descris în specificaţia ISO/IEC 7498 şi în Recomandarea
19
X.200 a CCITT (ITU-T) – documente identice, aprobate în 1984 şi ulterior
dezvoltate. Versiunile recente ale acestor documente sunt ITU-T Rec. X.200
(1994 E) şi ISO/IEC 7498-1, aprobate în 1994.
Cooperarea resurselor staţiilor unei reţele de calculatoare, în scopul
deservirii cererilor utilizatorilor privind diversele procesări de date, necesită
îndeplinirea anumitor funcţii de comunicaţie (transferuri de date) între
acestea. Modelul de referinţă OSI defineşte în linii mari şi partiţionează aceste
funcţii într-o structură verticală pe şapte nivele: Fizic – 1, Legătură de date – 2,
Reţea – 3, Transport – 4, Sesiune – 5, Prezentare – 6 şi Aplicaţie – 7 (fig. 1.2).
Funcţiile sunt astfel grupate în nivele, ca:
 fiecare nivel (funcţiile aferente) să deservească doar nivelul de deasupra
lui şi, la rândul său, să fie deservit doar de nivelul de sub el;
 funcţiile mai apropiate să fie referite la acelaşi nivel;
 să fie cât mai puţine înteracţiuni între funcţiile nivelelor învecinate, adică
interfeţele între nivele să fie cât mai simple;
 modificarea conţinutului şi a realizării funcţiilor din cadrul unui nivel să
nu afecteze sau cât mai puţin să afecteze alte nivele ş.a.
Fiecare nivel realizează un subset de funcţii de comunicaţie, bazându-se pe
nivelul imediat inferior şi oferind, la rândul său, o serie de servicii nivelului
imediat superior. Totodată, în reţelele locale, nivelul Legătură de date include
două subnivele: subnivelul inferior de Control al accesului la mediu (Medium
Acces Control – MAC) şi subnivelul de Control al legăturii logice (Logical Link
Control – LLC).
Funcţiile primelor trei nivele (nivelele 1-3), denumite şi inferioare, se
realizează atât în cadrul staţiilor, cât şi în cadrul ruterelor, pe când ultimele
patru (nivelele 4-7), denumite şi superioare, – doar în cadrul staţiilor. Entităţile
de date cu care se operează, denumite generic PDU (Processing Data Unit),
sunt specifice fiecărui nivel: cele de la nivelele 5-7 se numesc, pur-şi-simplu,
date; cele de la nivelul Transport – segmente; cele de la nivelul Reţea –
pachete, cele de la nivelul Legătură de date – cadre, iar la nivelul fizic se
operează cu şiruri de biţi.
Conform figurii 1.2, dacă aplicaţia A a staţiei A iniţiază transmisia unui
mesaj către aplicaţia B a staţiei B, aceasta implică realizarea unor funcţii de
nivel 7. Folosind un protocol de nivel 7, nivelul 7 al staţiei A stabileşte o relaţie
egal-la-egal cu nivelul 7 al staţiei B. Ulterior, protocol în cauză solicită anumite
servicii de la nivelul 6, pentru oferirea cărora cele două entităţi de nivel 6
folosesc un protocol propriu şi tot aşa, consecutiv, sunt implicate şi celelalte
nivele până la nivelul Fizic, care şi transmite, efectiv, biţi prin mediul de
transmisie.
20
Staţia A Staţia B
Aplicaţia A Aplicaţia B
Mesaj Mesaj
7 Date
Mesaj 7 Mesaj
Nivele inferioare Nivele superioare

A7 A7
Aplicaţie
6 Date
A6 PDU-7 Prezentare 6 A6 PDU-7
5 Date
A5 PDU-6 Sesiune 5 A5 PDU-6
4 Segmente
A4 PDU-5 Transport 4 A4 PDU-5
Ruter Ruter
3 Pachete
A3 PDU-4 Reţea 3 ∙∙∙ 3 3 A3 PDU-4
Cadre
A2 PDU-3 SC 2
Leg. de date 2 ∙∙∙ 2 2 A2 PDU-3 SC
1 Biţi
PDU-2 1 ∙∙∙ 1 1 PDU-2
Fizic
∙∙∙
CTD
Fig. 1.2 Schema modelului de referinţă OSI ISO.

Notări: A7 – antetul entităţii de date de nivel Aplicaţie (informaţii de serviciu, adăugate la mesaj de protocolul de nivel Aplicaţie);
A6 – antet de nivel Prezentare; A5 – antet de nivel Sesiune;
A4 – antetul segmentului de nivel Transport; A3 – antetul pachetului de nivel Reţea;
A2 – antetul cadrului de nivel Legătură de date; SC – suma de control;
PDU-i – entitatea de date de nivel i, i = 2,3, …, 7; CTD – canal de transfer date.
21
De menţionat că nu există o comunicare directă între perechi de nivele
cu excepţia celei de nivel Fizic. Fiecare din celelalte nivele transmite date
către nivelul imediat inferior, la sursă, şi – în direcţia inversă, la destinaţie.
Modelul OSI foloseşte noţiunile de protocol şi serviciu. În linii mari, un
serviciu specifică ce anume se cere, iar un protocol – care acţiuni şi cum
acestea de realizat, pentru a oferi serviciul în cauză. Sub noţiunea de
protocol se are în vedere un set de conveniențe, cerinţe, reguli şi acţiuni de
efectuat, pentru realizarea uneia sau a mai multor funcţii. Fiecare serviciu,
la rândul său, este definit prin primitive şi parametri. O primitivă specifică
funcţia de realizat, iar parametrii sunt folosiţi pentru a caracteriza
condiţiile transferului datelor şi a informaţiilor de serviciu. De menţionat că
primitivele sunt dependente de implementări; ca exemplu ar putea servi
apelul unei proceduri.
Sunt prevăzute patru tipuri de primitive: REQUEST, INDICATION,
RESPONSE şi CONFIRM. Primitiva REQUEST este emisă de către un
utilizator de servicii, în scopul invocării unui serviciu şi, de asemenea,
pentru definirea parametrilor necesari la specificarea serviciului solicitat.
Primitiva INDICATION este emisă de un furnizor de servicii în scopul
indicării că o procedură a fost invocată de către utilizatorul pereche al
serviciului, pentru prescrierea parametrilor asociaţi sau în scopul informării
utilizatorului serviciului despre o acţiune iniţiată de furnizor. Primitiva
RESPONSE este emisă de către un utilizator de servicii, pentru a confirma
sau completa unele proceduri, invocate anterior de către o indicaţie către
acest utilizator. Primitiva CONFIRM este emisă de către un furnizor de
servicii, pentru a confirma sau completa unele proceduri, invocate anterior
de către o cerere a utilizatorului de servicii.
Transmiterea unui mesaj de la staţia A către cea B, conform figurii 1.2,
are loc în modul următor. La staţia sursă a mesajului, fiecare nivel adaugă
la entitatea de date, primită de la nivelul imediat superior, un antet cu
informaţii de serviciu, necesare pentru realizarea funcţiilor respective. Mai
mult ca atât, nivelul Legătură de date, adaugă, la sfârşitul pachetului
recepţionat de la nivelul Reţea, şi un câmp remorcă (trailer) cu suma de
control, pentru detectarea sau chiar corectarea erorilor. Procesul în cauză,
de adăugare a informaţiilor de serviciu la entităţile de date recepţionate de
la nivelul superior, poartă denumirea de încapsulare, iar procesul invers se
numeşte dezîncapsulare.
Spre deosebire de celelalte nivele, nivelul Fizic nu adaugă careva
informaţii la cadrul recepţionat de la nivelul Legătură de date; el doar
transmite bit cu bit, prin mediul de transmisie, şirul de biţi ai cadrului, fără
22
careva modificări. Bineînţeles, la codificarea fizică a biţilor cadrului, nivelul
Fizic poate insera elemente de semnal speciale – elemente, care nu se vor
regăsi în şirul de biţi ce se va transmite nivelului Legătură de date de
nivelul Fizic al nodului adiacent.
La necesitate, nivelul Transport împarte în fragmente entitatea de date,
recepţionată de la nivelul Sesiune, şi la fiecare fragment adaugă antetul de
nivel Transport, formând astfel, de fiecare dată, un segment. Procesul de
împărţire a unei entităţi de date de nivel superior în fragmente se numeşte
fragmentare, iar procesul invers se numeşte defragmentare. În mod
similar, fragmentarea respectivă se efectuează şi la nivelul Reţea, dacă, de
exemplu, de la un ruter-poartă al altei reţele la ruterul-poartă al reţelei
date soseşte un pachet de dimensiune prea mare. Evident, la nivelul
respectiv al nodului pereche (staţie sau ruter, în funcţie de situaţie) are loc
defragmentarea entităţilor de date de acest nivel cu formarea entităţii de
date pentru nivelul superior.
La fiecare ruter, nivelul Fizic transmite şirul de biţi, recepţionaţi din
mediul de transmisie, nivelului Legătură de date, fără careva modificări.
Nivelul Legătură de date, în baza analizei sumei de control, întreprinde
acţiunile necesare de control al erorilor. Ulterior, elimină din cadru
informaţiile de serviciu de nivel Legătură de date (antetul şi suma de
control – remorcă) şi pachetul obţinut îl transmite nivelului Reţea. Nivelul
reţea actualizează antetul pachetului şi transmite pachetul nivelului
Legătură de date, care procesează pachetul ca şi în cazul unei staţii sursă.
La fel procesează cadrul şi nivelul Fizic.
La staţia destinaţie a mesajului, datele sunt procesate în mod invers de
la nivelul Fizic până la cel Aplicaţie, cu eliminarea informaţiilor de serviciu
ce ţin de fiecare din nivele.
Mai detaliat, funcţiile celor şapte nivele OSI sunt descrise în s.1.3.2.
1.3.2. Nivelele modelului OSI
Nivelul Aplicaţie este responsabil de asigurarea interacţiunii dintre
aplicaţiile utilizatorilor şi programele de reţea şi, de asemenea, de gestiunea
folosirii resurselor reţelei. Pentru oferirea serviciilor necesare aplicaţiilor
utilizatorilor, el realizează aşa funcţii ca: identificarea utilizatorilor;
determinarea calităţii acceptabile a serviciului (de exemplu, timpul de
răspuns, rata erorilor, costul); determinarea disponibilităţii resurselor;
sincronizarea aplicaţiilor cooperante; stabilirea responsabilităţilor pentru
tratarea erorilor; stabilirea aspectelor de securitate; selectarea modului de
dialog; transferul de date, etc.
23
Nivelul Prezentare – definirea formatului datelor ce se transmit,
transformarea necesară a reprezentării datelor, asigurând entităţilor de
nivel Aplicaţie ale perechii de staţii independenţa faţă de diferenţele de
sintaxă în reprezentarea datelor; cifrarea şi descifrarea datelor.
Nivelul Sesiune – cooperarea entităţilor de date de nivel Prezentare
(entităţilor-prezentare) ale celor două staţii, pentru realizarea comunicării
între aplicaţii: stabilirea, administrarea şi încheierea conexiunii (sesiunii);
transferul de date; controlul dialogului (duplex, semiduplex); împărţirea
şirului de mesaje în grupuri, denumite activităţi, şi gestiunea acestora;
definirea şi identificarea unor puncte de sincronizare; resetarea conexiunii
la o stare definită; controlul fluxului ş.a.
Nivelul Transport – asigurarea unui transfer transparent de date între
entităţile-sesiune ale perechii de staţii, scutindu-le de la orice preocupare
privind modul detaliat, în care se realizează transferul fiabil şi eficient de
date. El optimizează selectarea şi folosirea serviciului-reţea adecvat, pentru
asigurarea performanţei necesare fiecărei entităţi-sesiune, şi, de
asemenea, gestiunea calităţii serviciului (disponibilitate, productivitate,
întârziere de transmisie, erori netratate ş.a.). Nivelul Transport identifică în
mod unic, printr-o adresă-transport, fiecare entitate-sesiune.
În modul orientat pe conexiune, serviciul-transport oferă mijloace
pentru stabilirea, menţinerea şi desfiinţarea conexiunilor-transport,
fiecăreia din acestea fiindu-i atribuit identificatorul propriu. Conexiunile-
transport realizează transferuri de date semiduplex între perechea de
entităţi-sesiune. Între o pereche de adrese-transport pot fi stabilite mai
multe conexiuni-transport, realizând astfel multiplexarea conexiunilor.
În modul orientat pe conexiune, funcţiile nivelului Transport sunt:
maparea adreselor-transport în adrese-reţea; multiplexarea conexiunilor-
transport (staţie-staţie) în conexiuni-reţea; stabilirea, administrarea şi
desfiinţarea conexiunilor-transport; segmentarea entităţilor-sesiune şi
reasamblarea entităţilor-transport; controlul secvenţei staţie-staţie pentru
fiecare conexiune; transferul de date; detectarea şi recuperarea erorilor;
monitorizarea calităţii serviciului; controlul fluxului pentru fiecare
conexiune ş.a.
La funcţiile nivelului Transport, în modul neorientat pe conexiune, se
referă: maparea adreselor-transport în adrese-reţea; maparea
transmisiunilor neorientate pe conexiune de nivel Transport în
transmisiuni neorientate pe conexiune de nivel Reţea; transferul de date;
detectarea erorilor şi monitorizarea calităţii serviciului; delimitarea unităţii
de date a serviciului de nivel Transport ş.a.
24
Nivelul Reţea – adresarea logică, determinarea căii şi transferul
transparent de date între entităţile-transport ale staţiilor sursă şi
destinaţie, eventual prin noduri intermediare; interconectarea reţelelor de
arhitecturi diferite, asigurând nivelelor superioare (4-7) independenţa de
tehnologia de transfer date şi de comutare, utilizate pentru
interconectarea sistemelor.
La funcţiile nivelului Reţea se referă: rutarea şi comutarea; stabilirea,
multiplexarea şi desfiinţarea conexiunilor-reţea de tip punct-la-punct (între
aceeaşi pereche de entităţi-transport pot fi mai multe conexiuni-reţea);
segmentarea; secvenţierea; selectarea serviciului; transferul de date;
detectarea şi recuperarea erorilor; controlul fluxului; maparea între
adresele-reţea şi adresele-legătură-de-date; maparea transmisiunilor
neorientate pe conexiune de nivel Reţea în transmisiuni neorientate pe
conexiune de nivel Legătură de date; convertirea din serviciul orientat pe
conexiune de nivel Legătură de date în serviciul orientat pe conexiune de
nivel Reţea; extinderea serviciului neorientat pe conexiune de nivel
Legătură de date pentru oferirea unui serviciu orientat pe conexiune de
nivel Reţea ş.a.
Nivelul Legătură de date – adresarea fizică, stabilirea şi gestiunea
conexiunilor-legătură-de-date şi transferul de date între entităţile-reţea ale
perechii de noduri adiacente, cu sincronizarea necesară, controlul
accesului, al erorilor şi al fluxului.
Nivelul Fizic – transmisia transparentă, între entităţile-legătură-de-date
ale perechii de noduri adiacente, prin mediul fizic, de şiruri de biţi,
păstrând ordinea biţilor şi garantând anumiţi parametri de calitate a
serviciului: disponibilitatea serviciului, rata transmisiei, rata erorilor,
întârzierea ş.a., dar fără a garanta corectitudinea transmisiei. Se ocupă de
caracteristicile mecanice, electrice, funcţionale şi procedurale de activare,
menţinere şi dezactivare a conexiunilor-fizice pentru transmisia de şiruri de
biţi. În cadrul unui singur circuit de date pot fi create, opţional, două sau
mai multe conexiuni-fizice, realizând astfel multiplexarea.
Fiecare din funcţiile şi serviciile nivelelor modelului OSI poate fi
realizată, de obicei, în mai multe moduri. Realizările concrete ale acestora
sunt definite în protocoalele de reţea. Protocol de reţea se numeşte un set
de convenţii şi reguli pentru schimbul de mesaje între staţiile unei reţele.
Totalizând funcţiile celor şapte nivele ale modelului OSI, descrise mai sus,
se poate constata că la funcţiile de bază ale protocoalelor de comunicaţie
se referă: formatul datelor de transmis; formatul adreselor pentru
schimbul de date; maparea (convertirea) adreselor dintr-un sistem în altul;
25
rutarea sau comutarea unităţilor de date; detectarea erorilor de
transmisie; confirmarea recepţionării corecte a pachetelor de date;
pierderea de date, pauze şi reluarea transmisiei; controlul secvenţei
unităţilor de date; controlul fluxului ş.a.
1.4. Modelul arhitectural şi protocoale TCP/IP

1.4.1. Modelul arhitectural de reţea TCP/IP
Modelul arhitectural de bază în Internet este TCP/IP. Schematic acesta
este prezentat în figura 1.3. Modelul TCP/IP cuprinde 4 nivele (Legătură
sau Acces, Internet, Transport şi Aplicaţie), acoperind cele 7 niveluri ale
modelului arhitectural de reţea OSI şi anume: Legătură (OSI 1-2), Internet
(OSI 3), Transport (OSI 4), Aplicaţie (OSI 5-7). După cum se vede există mai
multe deosebiri între modelul TCP/IP şi cel OSI:
 la nivelul Legătură se unifică comunicarea între diversele reţele,
realizându-se posibilitatea interconectării unor reţele de tehnologii
diferite;
 nivelul Aplicaţie al TCP/IP incorporează şi funcţiile nivelelor Sesiune şi
Prezentare ale OSI.
Diversele funcţii de reţea sunt definite în cadrul protocoalelor
respective. În figura 1.3 sunt specificate o parte din cele circa o sută de
protocoale ale TCP/IP.
Nivele Protocoale
TELNET
FINGER
SNMP
Rexec
SMTP
NNTP
DHCP
BGP*
HTTP
Aplicaţie
TFTP
RIP*
●●●
DNS
NTP
FTP
Transport TCP, UDP, DCCP, SCTP, RSVP

Internet IP, ICMP, ECN, RIP*, OSPF, BGP*, IGMP, IPsec
LLC
Frame Relay
IEEE 802.11
Token Ring
Legătură
Ethernet
(Acces)
FDDI
●●●
●●●
X.25
SLIP
PPP
*Îndeplinesc funcţii ce ţin atât de nivelul Internet, cât şi de cel Aplicaţie.

Fig. 1.3 Modelul arhitectural TCP/IP.
Un factor decisiv, în folosirea largă a Internet, a fost încorporarea
TCP/IP în 1981 în sistemul de operare UNIX, utilizat pe diferite clase de
26
calculatoare – de la cele personale şi până la supercalculatoare. Ulterior,
TCP/IP a fost încorporat şi în alte sisteme de operare, inclusiv Microsoft
Windows NT, Windows 95/98/Me/2000/XP/Vista/7/8.
Transmisia unui mesaj (unul sau mai multe fişiere, un mesaj de i-poştă
etc.), folosind modelul TCP/IP, se realizează, în linii mari, în modul următor.
Protocolul de nivel Aplicaţie respectiv transmite mesajul la unul din
protocoalele nivelului Transport – TCP (Transmission Control Protocol) sau
UDP (User Datagram Protocol). La nivelul Transport, mesajul este divizat în
blocuri de date; fiecare asemenea bloc este completat cu anumite
informaţii de control, formând un segment de date, care se transmite la
nivelul Internet. La nivelul Internet, la fiecare segment de asemenea se
adaugă informaţii de control respective, formând un pachet-datagramă, se
determină ruta de transmisie şi apoi datagrama se transmite la nivelul
Legătură (Acces).
La nivelul Legătură, la fiecare datagramă se adaugă noi informaţii de
control, formând un cadru (frame), care ulterior se transmite nodului de
comunicaţie adiacent sau nemijlocit staţiei-destinaţie. La staţia destinaţie,
procesul decurge în ordine inversă: la fiecare nivel se analizează informaţia
de control respectivă şi, dacă totul e în ordine, aceasta se elimină, iar
unitatea de date obţinută se transmite la nivelul nemijlocit superior.
Schimbul de date realizat este duplex.
După cum a mai fost menţionat, pentru tehnologia TCP/IP, subreţelele
(reţelele interconectate) pot fi diverse (fig. 1.1), deosebindu-se şi
protocoalele implementate.
1.4.2. Protocoale de nivel Aplicaţie
Protocoalele nivelului Aplicaţie asigură funcţiile necesare programelor
de aplicaţie cu accesul şi utilizarea resurselor Internet, folosind şi serviciile
nivelului Transport, pentru transferul datelor între staţiile reţelei. Ele
cuprind toate funcţiile, pe care le pot solicita aplicaţiile: identificarea
utilizatorilor, stabilirea calităţii serviciului, sincronizarea aplicaţiilor
cooperante, stabilirea responsabilităţilor pentru tratarea erorilor, etc.
Unităţile de date, cu care se operează la acest nivel, se numesc mesaje sau,
pur-şi-simplu, date.
Deosebesc două categorii de protocoale de nivel Aplicaţie: protocoale
utilizator şi protocoale de suport. Protocoalele utilizator oferă servicii
direct utilizatorilor, iar cele de suport îndeplinesc funcţii de sistem. Lista
unor protocoale de nivel Aplicaţie este dată în tabelul 1.2.
27
Tabelul 1.2 Lista unor protocoale TCP/IP de nivel Aplicaţie
Abre- Denumire desfăşurată
viere în engleză în română
Dynamic Host Configuration Protocolul de configurare dinamică a
DHCP
Protocol staţiilor
DNS Domain Name System Sistemul numelor de domenii
Finger Finger Finger
FTP File Transfer Protocol Protocolul transferului de fişiere
HTTP Hipertext Transfer Protocol Protocolul transferului de hipertexte
IMAP Internet Message Access Protocol Protocolul de acces al mesajelor Internet
IRC Internet Relay Chat Conversaţii prin Internet
Lightweight Directory Access
LDAP Protocolul de acces al directoarelor
Protocol
MGCP Media Gateway Control Protocol Protocolul de control al porţilor de media
NNTP Network News Transfer Protocol Protocolul transferului ştirilor în reţea
NTP Network Time Protocol Protocolul timpului în reţea
POP Post Office Protocol Protocolul oficiului de poştă
Remote Command Execution Protocolul de execuţie la distanţă a
Rexec
Protocol comenzilor
Rlogin Remote Login Protocol Protocolul de conectare la distanţă
RPC Remote Procedure Call Chemarea procedurilor la distanţă
RTP Real-time Transport Protocol Protocolul de transport în timp real
RTCP RTP Control Protocol Protocolul de control al RTP
RTSP Real Time Streaming Protocol Protocolul de flux în timp real
Protocolul de interfaţă utilizator la
SHELL Remote Shell Protocol
distanţă
SIP Session Initiation Protocol Protocolul de iniţiere a sesiunii
SMTP Simple Mail Transfer Protocol Protocol de transfer poştă ordinară
Simple Network Management
SNMP Protocolul simplu de gestiune a reţelei
Protocol
SOCKS SOCKet Secure Soclu (sochet) securizat
SSH Secure Shell Interfaţă securizată
Telnet Network Terminal Protocol Protocolul terminalului de reţea
TFTP Trivial FTP Protocolul trivial de transfer de fişiere
Time Time Protocol Protocolul de timp
Transport Layer Security/ Securitatea nivelului Transport/Nivelul
TLS/SSL
Secure Sockets Layer de socluri securizate
Extensible Messaging and Protocolul de mesagerie şi prezenţă
XMPP
Presence Protocol extensibile
Fiecărui protocol al nivelului Aplicaţie îi este specificat atât un nume
special de port (well-known number), cât şi un nume special de protocol
28
şi serviciu (well-known name and service). În sistemul UNIX aceste
informaţii sunt înregistrate în fişierele /etc/services şi etc/protocols.
O bună parte din aceste protocoale sunt descrise, în linii mari, în s. 1.7.
1.4.3. Protocoale de nivel Transport
1.4.3.1. Caracterizare generală
Protocoalele nivelului Transport asigură transferul de date sigur între
două staţii cu recuperarea erorilor pentru legătura staţie-staţie şi controlul
calităţii serviciului (productivitate, întârziere de transmisie, erori netratate
ş.a.); realizează, de asemenea, multiplexarea conexiunilor. În acest scop,
mesajul de transmis este divizat în blocuri de date. La fiecare asemenea
bloc se adaugă un antet cu informaţii de serviciu, formând unitatea de date
denumită segment. Comunicarea între două aplicaţii se face prin
intermediul unor porturi de protocol aplicaţie de pe perechea de staţii
respectivă.
Lista unor protocoale de nivel Transport este dată în tabelul 1.3.
Tabelul 1.3. Lista unor protocoale TCP/IP de nivel Transport
Protocolul de Control al
TCP Transmission Control Protocol
Transmisiei
UDP User Datagram Protocol Protocolul Datagramă Utilizator
Datagram Congestion Control Protocolul de Control al Congestiei
DCCP
Protocol Datagramelor
Stream Control Transmission Protocolul de Transmisie şi Control
SCTP
Protocol al Fluxului
Protocolul de rezervare a
RSVP Resource Reservation Protocol
resurselor
Reliable User Datagram Protocolul Datagramă Utilizator
RUDP
Protocol Fiabil (nu este standard Internet)
1.4.3.2. Protocolul de control al transmisiei TCP
Protocolul TCP (Transmission Control Protocol) este unul din
protocoalele de bază ale suitei de protocoale a Internet. El asigură
transferul fiabil şi controlul fluxului de date între aplicaţiile sursă şi
destinaţie prin intermediul porturilor de protocol asociate acestor aplicaţii,
asigurând interacţiunea „staţie-staţie”.
29
O conexiune între două programe de aplicaţie este identificată printr-o
pereche de socluri (sockets) Internet. Fiecare soclu este specificat de un
număr de port şi adresa IP a gazdei în cauză. Numerele de porturi folosite
sunt grupate în trei categorii: porturi bine cunoscute (well-known
numbers), folosite pentru servicii bine cunoscute; porturi înregistrate
(registered ports), folosite pentru servicii înregistrate de autoritatea IANA
(Internet Assigned Numbers Authority), şi porturi dinamice (dynamic ports)
sau private (private ports), care nu sunt destinate în mod oficial pentru
anumite servicii şi pot fi folosite în diverse scopuri.
Numerele de porturi sunt identificatoare pe 16 biţi: porturile bine-
cunoscute sunt reprezentate prin numere de la 0 până la 1023, cele
înregistrate – de la 1024 până la 49151 şi cele dinamice sau private – de la
49152 până la 65536. Responsabil de menţinerea şi atribuirea numerelor
de porturi este autoritatea IANA (www.iana.org).
Unele numere de asemenea porturi, folosite de protocoalele de nivel
Transport, sunt prezentate în tabelul A2.1. În acesta cazurile cu porturi
marcate suriu specifică protocoalele şi porturile folosite de serviciile
MikroTik RouterOS.
TCP este un protocol orientat pe conexiune, operarea căruia poate fi
împărţită convenţional în trei etape: 1) stabilirea conexiunii cu staţia
distanţă; 2) transferul datelor de transmis; 3) desfiinţarea conexiunii cu
staţia distanţă, eliberând resurselor respective. Conexiunea TCP este
gestionată de sistemul de operare de reţea respectiv prin intermediul
interfeţei de programare care reprezintă punctul terminal al conexiunii –
soclul Internet.
Dimensiunea mesajelor de transferat nu este limitată. În caz de
necesitate, mesajul este divizat în fragmente, la care se adaugă informaţii
de serviciu ale nivelului Transport, obţinând astfel unităţile de date
denumite segmente. Dimensiunea unui segment TCP este de 1024 - 8192
octeţi, de la caz la caz. Transferul segmentelor este garantat: în caz de
erori, pierderi, etc., segmentele respective sunt recuperate. În acest scop
se foloseşte confirmarea recepţionării reuşite a fiecărui segment în parte,
în caz contrar segmentul se retransmite. Fiecare segment conţine un
număr de secvenţă, utilizat pentru ordonarea segmentelor în cadrul
mesajului respectiv.
1.4.3.3. Protocolul datagramă utilizator UDP
Protocolul UDP (User Datagram Protocol) prevede transferul, fie şi
nefiabil, al datelor între aplicaţiile sursă şi destinaţie prin intermediul
30
porturilor de protocol ale acestor aplicaţii. Serviciul utilizat este neorientat
pe conexiune – de tip datagramă. Astfel, pentru transferul de date, nu se
formează mai întâi conexiunea cu staţia distanţă. Livrarea mesajelor,
denumite în acest caz şi datagrame, nu se garantează şi nu se face
controlul fluxului de date. Deşi se calculează o sumă de control a
datagramei, care poate fi utilizată de către aplicaţii, pentru asigurarea
livrării corecte a mesajului.
Protocolul UDP este mai simplu şi asigură transmisia mai rapidă a
datelor, comparativ cu TCP. Se utilizează pentru transmisia de mesaje de
dimensiuni mici (sub 8 Ko în sistemele UNIX), iar durata reţinerii datelor în
reţea este importantă sau în cazurile când veridicitatea transferului de
date nu este critică sau aceste funcţii se realizează în cadrul aplicaţiilor
(anexa 3). UDP este deseori folosit de către aplicaţiile critice faţă de
reţinerea datelor, deoarece pierderea de pachete este preferabilă faţă de
întârzierea lor.
UDP convine în anumite circumstanţe şi anume:
 fiind orientat la tranzacţii, este potrivit pentru protocoale simple de
tip cerere-răspuns ca DNS şi NTP;
 oferă datagrame, potrivite pentru modelarea altor protocoale, cum ar
fi tunelarea IP, RPC şi NFS (Network File System);
 este simplu, potrivit pentru scopuri de lansare sau alte scopuri ce nu
necesită o stiva de protocoale completă, cum ar fi DHCP şi TFTP;
 este neutru, potrivit pentru un număr foarte mare de clienți, cum ar fi
aplicaţiile media de tip flux, de exemplu TV IP;
 lipsa unor întârzieri de retransmisie, îl face potrivit pentru aplicaţii în
timp real, cum ar fi voce prin IP (VoIP), jocuri online şi mai multe
protocoale ce folosesc RTSP (Real Time Streaming Protocol);
 funcţionează bine în comunicarea unidirecţională, potrivită pentru
difuzarea de informații, cum ar fi, în multe tipuri de identificare
automată de echipamente şi servicii oferite de acestea (service
discovery) şi informaţii partajate, cum ar fi difuzarea orei sau RIP
(Routing Information Protocol).
1.4.4. Protocoale de nivel Internet

1.4.4.1. Caracterizare generală
Funcţiile nivelului Internet constau în asigurarea transferului de date
între perechi de noduri de comunicaţie sau staţii ale reţelei, fie şi
neadiacente, realizând nivelelor superioare independenţa de tehnologia de
31
transmisie date şi de comutare, utilizată pentru conectarea sistemelor. În
acest scop, la nodul de transmisie se realizează conversia segmentelor de
date, provenite de la nivelul Transport, în pachete de date (la fiecare
segment se adaugă informaţii de serviciu proprii nivelului Internet, etc.),
rutarea pachetelor de date şi transferul ultimelor către protocoalele
nivelului Legătură de date. La nodul destinaţie are loc procedura inversă de
conversie a pachetelor în segmente şi transmiterea segmentelor către
nivelul Transport. Unităţile de date, cu care se operează la acest nivel, se
numesc pachete sau datagrame, deoarece metoda de comutare pachete
folosită în Internet este cea datagramă.
Sisteme autonome. În scopul facilitării rutării pachetelor în reţele cu
foarte multe rutere, acestea se împart în entităţi denumite sisteme
autonome (autonomous system – AS) sau intermediare (intermediate
system – IS). Sistem autonom Internet se numeşte o parte a Internet, în
care pentru distribuirea informaţiilor de rutare a pachetelor se foloseşte
unul şi acelaşi protocol. Astfel, se poate întâmpla ca o reţea corporativă să
fie constituită din mai multe sisteme autonome, îndeosebi dacă acestea
sunt despărţite geografic de sisteme autonome ce ţin de alte autorităţi
administrative. Fragmentul Internet, în care se utilizează unul şi acelaşi
protocol pentru distribuirea informaţiilor de rutare a pachetelor, se mai
numeşte şi domeniu de rutare al protocolului respectiv, de exemplu
domeniu OSPF.
Categoriile de protocoale IGP şi EGP. Protocoalele, folosite pentru
distribuirea informaţiilor de rutare a pachetelor în cadrul unuia şi aceluiaşi
SA, ţin de categoria de protocoale pentru porţi interioare (Interior Gateway
Protocol – IGP), iar cele folosite pentru distribuirea informaţiilor de rutare
între două sau mai multe AS – de categoria de protocoale pentru porţi
exterioare (Exterior Gateway Protocol – EGP). Astfel, protocoalele IGP sunt
protocoale de rutare intraSA, iar cele EGP – protocoale de rutare extraAS.
Fiecare sistem autonom foloseşte un singur IGP. Diferite sisteme
autonome pot folosi diferite IGP:
Protocoale de rutare pentru reţele IP. Pentru distribuirea informaţiilor
de rutare, IP foloseşte aşa protocoale intraAS ca RIP (Routing Information
Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate System to
Intermediate System) şi EIGRP (Enhanced Interior Gateway Routing
Protocol) şi protocolul extraSA BGP (Border Gateway Protocol).
Lista unor protocoale de nivel Internet este dată în tabelul 1.4.
Protocoalele IS-IS, RIP, OSPF şi BGP sunt descrise în s. 10.3, cel IPsec – în s.
11.1.10, iar o parte din celelalte protocoale – în ss. 1.4.4.2-1.4.4.4.
32
Tabelul 1.4. Lista unor protocoale de nivel Internet
IP Internet Protocol Protocolul Internet
Internet Control Mesage Protocolul mesajelor de control
ICMP
Protocol Internet
ECN Explicit Congestion Notification Notificarea explicită a congestiei
Internet Group Management Protocolul de gestiune a
IGMP
Protocol grupurilor Internet
IPsec Internet Protocol Security Securitatea protocolul Internet
Intermediate System to Sistem intermediar către sistem
IS-IS
Intermediate System intermediar
RIP* Routing Information Protocol Protocolul informaţiilor de rutare
Deschide mai întâi calea cea mai
OSPF Open Shortest Path First
scurtă
BGP* Border Gateway Protocol Protocolul de poartă marginală
*Îndeplinesc funcţii ce ţin atât de nivelul Internet, cât şi de cel Aplicaţie.
1.4.4.2. Protocolul Internet
Protocolul IP (Internet Protocol) este principalul protocol de
comunicare responsabil de rutarea pachetelor între staţii, în baza adreselor
acestora, a tabelelor de rutare şi a altor informaţii. În cazul unor segmente
ce depăşesc o limită anume, de rând cu rutarea IP realizează fragmentarea
la sursă şi reasamblarea unor asemenea segmente la destinatar, ţinând
cont de ordinea urmării fragmentelor în segmente. Protocolul oferă
serviciul datagramă (fără conexiune). Livrarea pachetelor, denumite şi
datagrame, nu este garantată (este nefiabilă) – nu se cere confirmarea de
recepţie reuşită.
Istoric, IP a fost realizat, împreună cu serviciul orientat pe conexiune, în
1974 în cadrul Programei de Control al Transmisiei (Transmission Control
Program). Ulterior, în 1977, Programa de Control al Transmisiei a fost
divizată în protocoalele IP şi TCP. Primele trei versiuni ale IP (IPv1 – IPv3)
au fost lansate şi consecutiv folosite în perioada 1977-1979.
Prima versiune majoră a IP, este a 4-a – IPv4, cea mai folosită încă şi în
2014. Totodată, din ce în ce lai larg se implementează IP versiunea 6 (IPv6).
Principala deosebire a IPv6 de IPv4 constă în înlocuirea adreselor de 32 biţi
cu adrese de 128 biţi.
33
Rutarea este efectuată de staţii şi rutere, folosind protocoale de poartă
interioară (IGP) sau/şi, în funcţie de caz, protocoale de poartă exterioară
(EGP). Fiind un protocol, bazat pe metoda datagramă de comutare
pachete, este rapid, dar din contul fiabilităţii, care se manifestă prin
pierderi de pachete, livrări de pachete într-o altă ordine, decât acestea
urmează în mesajul transmis ş.a. Totuşi, în IPv4 este realizată verificarea la
erori a antetului pachetului; dacă acesta este cu erori, atunci pachetul
respectiv este eliminat din reţea. Însă în IPv6 este deja abandonată
verificarea la erori, în favoarea sporirii vitezei de transfer date. Dacă este
necesară transmiterea de date fără erori, atunci de aceasta trebuie să aibă
grijă protocoalele de nivel superior.
Un pachet IPv4 constă din antet şi date şi nu poate depăşi 2 16 octeţi. La
formarea segmentelor, protocolul TCP ţine, iar cel UDP nu ţine cont de
această restricţie. De aceea IPv4 în mod automat fragmentează
segmentele, care depăşesc limita în cauză la sursă, şi realizează
reasamblarea acestora, ţinând cont de ordinea urmării fragmentelor în
segmentele fragmentate, la destinatar.
În câmpul „Protocol” al antetului pachetului IPv4 şi câmpul „Next
Header” al pachetului IPv6, se specifică numărul de protocol, denumit şi
număr IP (IP number), stabilit de către autoritatea IANA, al protocolului de
nivel următor, folosit în partea de date a pachetului IP. La asemenea
protocoale se referă (cu numărul de protocol respectiv) [19]: (0) IPv6 Hop-
by-Hop Option (RFC 2460); (1) ICMP (RFC 792); (2) IGMP (RFC 1112); (3)
Gateway-to-Gateway Protocol (RFC 823); (4) IPv4 (encapsulation, RFC 791);
(5) Internet Stream Protocol (RFC 1190, RFC 1819); (6) TCP (RFC 793); (8)
EGP (RFC888); (9) IGP; 17) UDP (RFC768); (33) DCCP (RFC4340); (41) IPv6
(encapsulation, RFC 2473, RFC 3056); (46) RSVP (RFC 2205); (50)
Encapsulating Security Payload (RFC 4303); (51) Autentification Header
(RFC 4302); (55) IP Mobility (Min Encap, RFC 2004); (56) TLS; (63) Orice
reţea locală; (70) Visa Protocol; (75) Packet Video Protocol; (80) ISO-IP; (88)
EIGRP; (89) OSPF (RFC 1583); (115) L2TP (Layer 2 Tunneling Protocol
Version 3, RFC 3931); (132) SCTP; (133) Fibre Channel; (137) IP MPLS (RFC
4023) ş.a.
Protocoalele IPv4 şi IPv6 sunt descrise parţial în s. 1.5.
1.4.4.3. Protocolul ICMP
Protocolul mesajelor de control în Internet (Internet Control Message
Protocol – ICMP, RFC 792) asigură schimbul de informaţii de control,
inclusiv a celor de testare, între nodurile reţelei (staţii sau rutere) privind
34
operarea IP. Informaţiile în cauză sunt furnizate protocolului IP la adresa
sursei pachetului şi se referă la:
 accesibilitatea unui nod al reţelei;
 diverse probleme apărute în transmisia sau recepţia de date;
 sincronizarea de ceas;
 obţinerea adreselor Internet şi a măştilor de reţea.
Exemplul 1.1. Fie, în rezultatul reducerii cu o unitate, câmpul TTL al
antetului unui pachet IPv4, sosit la un ruter de tranzit, a devenit egal cu
„0”. În asemenea caz, pachetul în cauză este eliminat din reţea, iar ICMP
transmite un mesaj „TTL exeeded in tranzit” către „Adresa sursă” a
pachetului.
Se bazează pe ICMP mai multe utilite de reţea, cum ar fi: traceroute,
ping, pathping ş.a.
La transmisie, fiecare mesaj ICMP este încapsulat într-un pachet IP.
Astfel, antetul ICMP urmează în pachet după antetul IP. Fiecare mesaj
ICMPv4 are un antet pe 8 octeţi şi o secţiune pentru date de lungime
variabilă. Primii 4 octeţi ai antetului conţin: tipul mesajului ICMP (1 octet),
codul (subtipul) mesajului ICMP (1 octet), suma de control al întregului
mesaj ICMP (2 octeţi). Conţinutul celorlalţi 4 octeţi ai antetului variază în
funcţie de tipul şi codul mesajului ICMPv4.
1.4.4.4. Protocolul de notificare explicită a congestiei ECP
Protocolul ECP (Explicit Congestion Notification), aprobat în 2001 (RFC
3168), permite notificarea staţie-staţie a congestiei de reţea fără
eliminarea de pachete. Funcţionalitatea oferită de ECP este una opţională.
În mod obişnuit, reţelele TCP/IP semnalizează congestia prin eliminarea
de pachete. ECN, în caz de congestie, setează respectiv câmpul ECN pe doi
biţi din antetul IP. Cele patru stări ale acestor doi biţi sunt: 00 – specifică
faptul că pachetul nu foloseşte ECN; 01 – congestie lipseşte; 11 – există
congestie. Receptorul unui pachet cu biţii ECN în starea 11, identifică
starea de congestie şi remite emiţătorului informaţia respectivă. În baza
acestei informaţii, emiţătorul reduce rata transmisiei.
1.4.5. Protocoale de nivel Legătură
1.4.5.1. Caracteristica generală
Nivelul Legătură (Link layer, RFC 1122), denumit şi nivelul Acces (Access
layer, RFC 908), realizează funcţiile unui transfer corect de date prin mediul
fizic între două noduri adiacente, transmiţând unităţi de date, denumite
cadre, cu sincronizarea necesară, controlul erorilor şi al fluxului. În acest
35
scop, la pachetul de date, recepţionat de la nivelul Internet, se adaugă
informaţii de serviciu de nivel Legătură, obţinând astfel unitatea de date
denumită cadru (frame), care se transmite ulterior în mediul de fizic de
transfer date, la sursă, şi procedura inversă – la destinatar. Dacă de
comparat cu modelul de reţea OSI/ISO, atunci nivelul Legătură al TCP/IP
îmbină funcţiile primelor două nivele ale modelului OSI ISO: Legătură de
date şi Fizic.
Lista unor protocoale de nivel Legătură este dată în tabelul 1.5. De
menţionat că în cazul de reţele IPv6, la nivelul Legătură se referă şi aşa
protocoale ca OSPF şi IS-IS. De asemenea, în cadrul modelului OSI/ISO,
protocolul ARP se consideră de nivel reţea şi nu Legătură de date.
Tabelul 1.5. Lista unor protocoale TCP/IP de nivel Legătură
ARP Address Resolution Protocol Protocolul de rezoluţie a adresei
Inverse Address Resolution Protocolul de rezoluţie inversă a
InARP
Protocol adresei
Reverse Address Resolution Protocolul de rezoluţie reversă a
RARP
Protocol adresei
NDP Neighbor Discovery Protocol Protocolul de descoperire a vecinilor
PPP Point-to-Point Protocol Protocolul punct-la-punct
Protocolul Internet pentru linii
SLIP Serial Line Internet Protocol
seriale
CSLIP Compressed SLIP Protocolul SLIP cu compresie
1.4.5.2. Protocolul PPP
Protocolul PPP (Point-to-Point Protocol – protocol punct-la-punct),
publicat în 1989 (RFC 1134) şi ulterior dezvoltat (RFC 1171, RFC 1331, RFC
1548, RFC 1661 – a. 1994), este un protocol de Nivel 2 OSI, elaborat ca
standard Internet pentru transferuri de date duplex multiprotocol pe
canale „punct-la-punct”. Prevede transmisii de date, atât sincrone cât şi
asincrone, cu posibilităţi de autentificare la stabilirea conexiunii, cifrare,
compresie, detecţie a erorilor şi livrare sigură a datelor. El se conformează
standardelor OSI ISO, este mai robust, dar şi mai complex, decât SLIP
(Serial Line Internet Protocol). Poate opera cu numeroase protocoale de
Nivel 3 OSI, inclusiv: IP, TRILL (Transparent Interconnection of Lots of Links,
RFC 6325), IPX (Internetwork Packet Exchange), NBF (NetBIOS Frames) şi
Apple Talk.
36
PPP înlocuieşte treptat implementările existente ale SLIP, dar şi cele
LAPB (Link Access Procedure, Balanced – Protocolul de acces balansat al
legăturii) al suitei de protocoale X.25. El este folosit la transmisia de date
prin cabluri seriale, linii telefonice, trunchiuri de canale, telefoane celulare,
canale radio specializate şi fibre optice, de exemplu SONET/SDH
(Synchronous Optical Network, Synchronous Digital Hierachy), ş.a. mijloace,
inclusiv de acces la Internet. De asemenea, două forme încapsulate ale
PPP, PPPoE (PPP over Ethernet, RFC 2516) şi PPPoA (PPP over ATM, RFC
2364) sunt folosite, de obicei, de furnizorii de servicii Internet pentru
stabilirea de conexiuni DSL (Digital Subscriber Line – Linie de abonat
numerică) cu abonaţii.
PPP oferă:
1) o metoda de încapsulare a pachetelor multiprotocol;
2) Protocolul de gestiune a legăturii (Link Control Protocol – LCP)
pentru stabilirea, configurarea şi testarea conexiunii punct-la-punct.
Suportă circuite sincrone şi asincrone, orientate atât pe bit, cât şi pe
caracter;
3) o familie de protocoale de gestiune a reţelei (Network Control
Protocol – NCP) pentru negocierea, stabilirea şi configurarea
opţiunilor diferitelor protocoale de nivel Reţea.
Încapsularea PPP defineşte multiplexarea simultană a diferitelor
protocoale de Nivel 3 prin aceiaşi legătură. Pentru încapsularea unui
pachet, sunt necesari de la 2 până la 8 octeţi (implicit) suplimentari.
Antetul implicit şi câmpurile pentru informaţii trebuie să fie multipli ai 32
biţi, pe când pentru câmpul de sfârşit (trailer) al cadrului nu este necesară
o asemenea constrângere.
Protocolul LCP serveşte pentru convenirea asupra opţiunilor de
încapsulare, manevrarea diferitelor limite privind lungimea pachetelor,
detectarea buclelor locale şi a altor erori de configurare şi, de asemenea,
pentru desfiinţarea conexiunii. El iniţiază şi desfiinţează conexiunile,
permiţând staţiilor să negocieze opţiunile acestora. De asemenea, LCP
efectuează configurarea automată a interfeţelor (lungimea datagramei,
caracterele ESC, numerele magice), la fiecare din cele două capete ale
conexiunii, şi selectarea autentificării opţionale.
Numerele magice sunt folosite pentru opțiunile de calitate și, de
asemenea, pentru identificarea buclelor locale (transmisie sie-şi) și a altor
anomalii de nivel Legătură. Atunci, când un nod transmite mesaje LCP PPP,
aceste mesaje pot conţine un număr magic, specific fiecărui nod. Dacă
transmisia se efectuează printr-o buclă locală, atunci nodul în cauză
37
recepţionează mesaje LCP cu propriul număr magic, identificând uşor
faptul în cauză.
LCP operează deasupra PPP, cu numărul de protocol PPP 0xc021. De
aceea mai întâi se stabileşte conexiunea fizică PPP şi doar apoi LCP o
configurează.
PPP prevede o configurare implicită a conexiunilor, care poate fi, la
implementare, îmbunătăţită, în funcţie de situaţie, pentru configurări
automate a legăturilor respective. Totodată, şi operatorul poate configura
explicit opţiunile, necesare pentru operarea legăturii în condiţii specifice. O
asemenea configurare se efectuează printr-un mecanism extensibil de
negociere a opţiunilor, în cadrul căruia fiecare capăt al legăturii descrie
celuilalt capabilităţile şi cerinţele proprii. LCP include următoarele opţiuni:
 Autentificarea – ruterele perechi schimbă mesaje de autentificare. În
acest scop poate fi folosit protocolul PAP (Password Authentification
Protocol, RFC 1334), cel CHAP (Challenge Handchake Authentification
Protocol, RFC 1334, RFC 1994) sau cel EAP (Extensible Authentification
Protocol, RFC 2284);
 Compresia – compresia datelor conform RFC 1962;
 Detectarea erorilor – identificarea condiţiilor de căderi, erori, folosind
numerele de calitate şi magice;
 Legături multiple (multilink) – echilibrarea încărcării mai multor
interfeţe, folosite de PPP prin Multilink PPP (MLPPP, RFC 1990).
Protocoalele NCP au menirea de a gestiona necesităţile specifice ale
diverselor protocoale de nivel Reţea, inclusiv cele de atribuire şi gestiune a
adreselor IP. Pentru fiecare protocol de nivel Reţea folosit, se aplică un
NCP aparte. Acesta încapsulează unitatea de date şi, după stabilirea
conexiunii, negociază opţiunile respective, inclusiv adresele de reţea şi de
compresie a datelor. De exemplu, IP foloseşte în acest scop NCP, denumit
IP Control Protocol – IPCP, iar IPX foloseşte NCP, denumit IPX Control
Protocol – IPXCP. Fiecare NCP conţine câmpuri pentru specificarea tipului
şi a altor parametri ai protocolului de nivel Reţea, pe care conexiunea PPP
îl încapsulează.
Arhitectura PPP este prezentată în figura 1.4. Câmpurile-componente
ale PPP sunt marcate în culoare sură. HDLC (High-Level Data Link Control –
HDLC) este un protocol bit-orientat sincron de nivel Legătură de date,
elaborat de ISO în baza protocolului SDLC (Synchronous Data Link Control)
al IBM. POS (Packet over SONET/SDH, RFC 2615) este un protocol pentru
transmiterea de pachete în format PPP prin SDH sau SONET, ambele fiind
protocoale standard pentru comunicaţii numerice prin fibra optică.
38
IP, IPX
LCP, inclusiv: CHAP, PAP, EAP IPCP, IPXCP, …
Încapsularea PPP
Încadrarea similară HDLC PPPoE PPPoA
POS
RS-232 SONET/SDH Ethernet ATM
Fig. 1.4. Arhitectura PPP.
Formatul cadrelor PPP este prezentat în figura 1.5.
Fanion Adresa Control Protocol Informaţie Suma de control Fanion
8 biţi 8 biţi 8 biţi 8 sau 16 Variabilă 16 sau 32 biţi 8 biţi
Fig. 1.5. Formatul cadrelor PPP.
În figura 1.5, câmpul „Fanion” (Flag) are valoarea 01111110, serveşte
pentru identificarea începutului şi, de asemenea, a sfârşitului cadrului şi
este folosit ca şi la HDLC. Câmpul „Adresa” este întotdeauna 11111111,
indicând faptul că toate staţiile trebuie să accepte cadrul. Aceasta permite
evitarea necesităţii de atribuire de adrese legăturii de date.
Câmpul „Control” are, pentru cadrele nenumerotate, valoarea
00000011, specificând faptul că PPP nu foloseşte, implicit, numere de
secvenţă a cadrelor şi confirmările respective şi deci nu oferă o transmisie
sigură. În mediile de transmisie de calitate joasă (de exemplu, cele fără fir),
poate fi utilizată transmisia sigură cu folosirea numerelor de secvenţă a
cadrelor conform RFC 1663. Deoarece, în configuraţiile implicite, valorile
câmpurilor „Adresa” şi „Control” sunt constante, LCP furnizează
mecanismul de negociere a omiterii acestora – opţiunea ACFC (Address-
and-Control-Field-Compression – Compresia câmpurilor Adresa şi Control).
Câmpul „Protocol” specifică tipul pachetului „Informaţie utilă”
(payload), de exemplu: LCP, NCP, IP, IPX, Apple Talk, etc. Dacă valoarea
câmpului începe cu bitul 0, atunci este vorba de protocoale de nivel reţea
(IP, IPX, CLNP, etc.), iar dacă aceasta începe cu bitul 1, atunci se are în
vedere negocierea altor protocoale (LCP şi NPC specific fiecărui protocol de
reţea suportat). Dimensiunea implicită a câmpului este de 2 octeţi, dar ea
poate fi negociată la 1 octet, folosind LCP.
Câmpul „Informație” (≥ 0, ≤ MTU) conține sarcina utilă PPP, volumul
căreia poate varia, dar nu poate depăși valoarea MTU; valoarea implicită a
MTU este de 1500 octeți. Dacă este necesar, informaţia utilă este
completată cu un număr de octeţi respectiv.
39
Câmpul „Suma de control” (Frame Check Sequence – FSC) serveşte
pentru determinarea, dacă cadrul este eronat. Valoarea FSC se calculează,
pentru câmpurile „Adresa”, „Control”, „Protocol”, „Informaţie” şi
„Completare”, conform codului CRC-CCITT sau al celui CRC-32 (RFC 1662).
Implicit se foloseşte CRC-CCITT cu polinomul generator x16 + x12 + x5 + 1.
Fazele stabilirii, funcţionării şi desfiinţării conexiunilor PPP sunt
prezentate, în formă de dreptunghiuri, în schema din figura 1.6 (RFC 1661).
Nu
Conexiunea Desfiinţarea Faza protocolului Da Autentificare

lipseşte conexiunii de nivel Reţea reuşită?
Nu
Stabilirea Conexiunea a Da Este necesară Da Autentificarea

conexiunii fost stabilită? autentificarea? conexiunii
Nu
Fig. 1.6. Schema stabilirii şi desfiinţării unei conexiuni PPP.

Fig. 2.xx20. Schema stabilirii, funcţionării şi defiinţării unei conexiuni PPP.
Fazele schemei din figura 1.6 au următoarea semnificaţie:
 „Conexiunea lipseşte” – apare în situaţia, când conexiunea a căzut sau
este desfiinţată la iniţiativa unuia din cele două noduri de la capetele
acesteia;
 „Stabilirea conexiunii” – LCP negociază stabilirea conexiunii;
 „Autentificarea conexiunii” – este o fază opţională, care permite
autentificarea reciprocă a perechii de noduri respective, înainte de
finalizarea stabilirii conexiunii;
 „Faza protocolului de nivel Reţea” prevede implicarea protocolului
respectiv NCP, de exemplu al celui IPCP pentru stabilirea serviciului IP.
Tot la această fază, după stabilirea serviciilor de reţea necesare, are
loc şi transferul de date pentru toate protocoalele, care au fost cu
succes startate cu implicarea protocoalelor NCP respective.
Dezactivarea protocoalelor de reţea are loc tot la această fază;
 „Desfiinţarea conexiunii” poate fi în cazul unei autentificări nereuşite,
depăşirii pragului de erori admise, căderii accidentale a conexiunii sau
la iniţiativa unuia din cele două noduri de la capetele conexiunii.
Operarea PPP. Operarea punct-la-punct poate fi necesară între o staţie
şi un nod de comunicaţie (comutator sau ruter) sau între două noduri de
40
comunicaţie. Fie că de la un calculator personal, conectat, printr-un canal
de transfer date (un canal vocal comutat şi două modeme la capetele
acestuia), la ruterul unui furnizor de servicii Internet (ISP), se doreşte
accesarea unor resurse de la un server din Internet.
În acest scop, aplicaţia respectivă, de exemplu exploratorul Web, din
cadrul PC-ului iniţiază stabilirea conexiunii cu acel server. Aceasta implică
diverse procese la nivel Aplicaţie (protocolul HTTP), la nivel Transport
(protocolul TCP), la nivel Internet (protocolul IP). Apoi, la nivel Legătură,
PPP apelează, prin intermediul canalului de transfer date, ruterul ISP. După
stabilirea conexiunii fizice, PC-ul trimite ruterului un şir de pachete LCP, în
câmpul “Informaţie” al unuia sau al mai multor cadre PPP. Informaţia din
aceste pachete specifică cerinţele, iar răspunsurile la ele confirmă
selectarea anumitor parametri PPP ce vor fi utilizaţi la schimbul de date
între cele două noduri.
După stabilirea parametrilor legăturii de date, se configurează nivelul
Reţea, folosind schimbul de cadre NCP, inclusiv: obţinerea dinamică a unei
adrese IP (dacă PC-ul nu are o adresă IP publică). Ulterior, poate fi efectuat
schimbul de informaţii utile între PC şi staţiile solicitate din Internet. După
încheierea schimbului de date, NCP întrerupe conexiunea la nivel Reţea,
eliberând adresa IP. Apoi LCP întrerupe conexiunea la nivel Legătură de
date şi, în sfârşit, conexiunea este întreruptă şi la nivel Fizic, eliberând şi
resursele canalului de transfer date.
1.4.5.3. Protocolul MLPPP
Protocolul PPP legături multiple (Multilink PPP – MLPPP), publicat în
1994 (RFC 1717) şi dezvoltat în 1996 (RFC 1990), defineşte transferul de
date între două noduri pe mai multe canale distincte PPP paralele. Este un
exemplu de protocol de agregare a legăturilor, care coordonează
funcţionarea multiplelor canale independente între o pereche de noduri,
obţinând o legătură de date virtuală cu o lăţime de bandă mai mare, decât
fiecare din componentele constituente.
Legăturii agregate, denumite şi trunchi, i se atribuie un nume,
determinat de perechea de identificatoare a celor două noduri
interconectate. Identificatorul unui nod poate conţine informaţia, generată
la autentificarea PPP, şi informaţia, generată de negocierea LCP. Canalele
unui trunchi pot fi diferite, de exemplu: canale asincrone, canale ISDN,
canale X.25 sau canale Frame Relay. Mai mult ca atât, o parte din canale
pot fi comutate asincrone, iar altele pot fi dedicate sincrone. MLPPP poate
fi folosit, de exemplu, pentru conectarea unei reţele locale a unei companii
41
la un ruter al furnizorului de servicii Internet, folosind două linii telefonice
închiriate, mai multe canale ale trunchiurilor BRI sau PRI ISDN, etc.
La transmisia unui flux de date pe mai multe canale paralele, se poate
întâmpla ca acele cadre de date formate la sursă să ajungă la destinaţie
într-o altă ordine, decât ele urmează în fluxul de date al sursei. De aceea
MLPPP trebuie să numeroteze cadrele, pentru a fi posibilă reordonarea lor
la destinatar. Mai multe sisteme de operare suportă MLPPP, inclusiv Cisco
IOS Release 11.1 şi superioare.
Regimul de legături multiple se configurează la negocierea opţiunilor
LCP iniţiale şi anume se identifică dacă:
1) nodul poate agrega mai multe canale în cadrul unei legături de date
logice;
2) nodul este capabil să recepţioneze unităţi de date ale protocolului
(processing data unit – PDU) de nivel superior, fragmentate folosind
antetul de legături multiple şi reasamblarea ulterioară a
fragmentelor în PDU original;
3) nodul este capabil să recepţioneze PDU-uri de N octeţi, unde N este
specificat ca parte a opţiunii, chiar dacă N este mai mare, decât
unitatea maximă de recepţie (Maximum Receive Unit – MRU)
pentru o singură legătură fizică.
După negocierea reuşită a regimului de legături multiple, nodul sursă
poate transmite PDU-uri încapsulate şi/sau fragmentate cu antetul de
legături multiple.
1.4.5.4. Protocolul MCPPP
Protocolul PPP clase multiple (Multiclass PPP – MCPPP), publicat în
1999 (RFC 2686), este o extensie a MLPPP, care defineşte o soluţie
orientată-fragment pentru formatul de încapsulare în timp real a
transferurilor de date între două noduri. El permite sursei să fragmenteze
pachetele de diverse priorităţi în fragmente de multiple clase şi
transmiterea, după necesitate, a pachetelor de priorităţi mai înalte printre
pachetele de priorităţi mai joase.
Scopul MCPPP constă în minimizarea reţinerilor fluxurilor de date
multimedia în timp real, transmise prin canale de capacitate joasă. Pentru
aceasta el trebuie să fie în stare să reţină orice pachet (timp-real sau nu),
asigurând transmisia unui pachet mai urgent. Totodată, vor fi rare cazurile
când un pachet timp-real va cere suspendarea unui alt pachet timp-real,
dacă ultimul nu va avea o lungime de cel puţin două ori mai mare.
42
Ţinând cont că valoarea implicită a MTU este de 1500 octeţi, iar cele
mai mici pachete de înaltă prioritate au lungimea de 22 octeţi (pachete
compresate RTP/G723.1), obţinem raportul 1500/22 ≈ 68. Deoarece 26 <
68 < 27, pot fi cel mult 8 nivele de suspendare a pachetelor de prioritate
mai joasă: 7 + 1, unde se ţine cont că mai există un nivel de suspendare a
pachetelor non-timp-real de pachetele timp-real. De exemplu, pentru
modeme de 56 Kbps, poate fi rezonabilă folosirea a cel puţin două nivele
de suspendare: pachetele audio suspendă orice pachet video, iar pachetele
video suspendă orice pachet non-timp-real.
1.4.5.5. Protocolul ARP
Pachetele IP sunt adresate folosind adrese IP – adrese de Nivel 3 OSI.
Dar, pentru transmisia efectivă de date între staţiile unei reţele, este
necesară folosirea adreselor fizice ale acestora – adrese de Nivel 2 OSI.
Protocolul de rezoluţie a adresei (Address Resolution Protocol – ARP),
definit în RFC 826 (a. 1982) şi dezvoltat în RFC 5227 şi RFC 5494, este un
protocol standard Internet (STD 37), destinat translatării adreselor IP,
conţinute în pachetele de date, în adrese MAC – adrese fizice unice de
echipamente din Internet. O asemenea translatare este iminentă în
reţelele multiacces. Pentru protocoalele, care asigură conexiuni punct-la-
punct, cum ar fi PPP şi SLIP, ARP nu este necesar. De asemenea, în reţelele
IPv6, funcţiile ARP sunt realizate de protocolul NDP (Neighbor Discovery
Protocol).
ARP este folosit, de asemenea, pentru detectarea folosirii în reţea a
unei anumite adrese IPv4 (RFC 5227). Acest lucru este necesar la iniţierea
folosirii în reţea a unei asemenea adrese (aceasta ar putea fi deja
atribuită). În acest scop, în reţea se trimite, prin difuzare, un mesaj ARP de
probă, la care staţia, căreia îi corespunde adresa IP specificată în mesaj,
comunică adresa MAC respectivă.
ARP poate fi încă folosit ca un protocol simplu de anunţuri, pentru
actualizarea unei adrese IP sau MAC în cadrul tabelelor ARP ale celorlalte
staţii ale reţelei. Un asemenea anunţ, denumit şi mesaj ARP gratuit, este,
de obicei, trimis prin difuzare ca o cerere ARP, care conţine adresa de
protocol a emiţătorului (Sender Protocol Address – SPA) în cadrul câmpului
adresei de protocol a destinaţiei (Target Protocol Address – TPA), TPA =
SPA, iar adresa echipamentului destinaţiei (Target Hardware Address –
THA) setată la 0 (THA = 0). O alternativă este difuzarea unui răspuns ARP,
cu specificarea adreselor echipamentului şi de protocol ale emiţătorului
(SHA şi SPA), repetate în câmpurile respective ale destinaţiei (TPA = SPA şi
43
THA = SHA). La anunţul ARP nu se cere vreun răspuns de la staţiile, care l-
au recepţionat. De menţionat, de asemenea, că multe sisteme de operare
de reţea aplică anunţurile ARP gratuite la startare.
ARP este un protocol cerere-răspuns, informaţiile căruia se transmit
doar în cadrul unei singure subreţele, fiind încapsulate într-un cadru. El
operează la nivelul Legătură al modelului TCP/IP, pe când în modelul OSI
este deseori descris ca operând între nivelele 2 şi 3 OSI, fiind încapsulat de
protocoalele de Nivel 2.
1.5. Adresarea în Internet

1.5.1. Adrese IPv4
1.5.1.1. Adrese şi scheme de adrese IP
Protocolul IPv4 foloseşte adrese pe 32 de biţi, ceea ce limitează
diapazonul de adrese la 232. Pentru comoditate, acestea se prezintă şi în
formă zecimală prin 4 numere cu valori între 0 şi 255, separate prin punct.
De exemplu, adresa IPv4 11000000 01001010 00100011 00111101 (în
realitate este fără spaţii) în formă zecimală va fi 192.74.35.61.
O adresă IP constă din identificatorul (ID) reţelei şi identificatorul staţiei
în această reţea. De menţionat că, la drept vorbind, o adresă IP se referă la
o interfaţă de comunicaţie a unei staţii, comutator/punte sau ruter al
reţelei respective. De aceea termenul „ID staţie” este folosit în sens mai
larg, referindu-se şi la interfeţele de comunicaţie ale comutatoarelor/
punţilor şi cele ale ruterelor. Mai mult ca atât, dacă staţiile au, de regulă, o
singură interfaţă de conectare la mediul de transmisie, atunci
comutatoarele/punţile şi ruterele au cel puţin două asemenea interfeţe.
Astfel, numărul total de adrese IP, necesare pentru identificarea unică a
staţiilor, comutatoarelor şi ruterelor unei reţele, este mai mare, decât
numărul total de asemenea componente ale reţelei respective.
Istoric, au fost propuse şi folosite patru scheme de adrese: 1) ID reţea,
specificat prin cei mai semnificativi 8 biţi ai adresei, şi ID staţie, reprezentat
prin ceilalţi 24 de biţi (inferiori) ai adresei IP (1974); 2) schema cu clase de
adrese (1981); 3) schema cu subreţele (1985) şi 4) schema CIDR (Classless
Inter-Domain Routing) din 1993.
1.5.1.2. Schema 1 de adrese IP
Schema 1 de adrese IP (1974) este una cu ID reţea, specificat prin cei
mai semnificativi 8 biţi ai adresei, şi ID staţie, reprezentat prin ceilalţi 24 de
biţi (inferiori) ai adresei IP. O asemenea schemă putea fi folosită pentru
44
doar până la 254 reţele (256 – 2); două adrese, toţi biţii „0” (adresa acestei
gazde) şi toţi biţii „1” (difuzare în reţeaua curentă) – sunt adrese speciale.
Această schemă, folosită în primii ani de funcţionare a Internet, şi-a epuizat
rapid resursele.
1.5.1.3. Schema cu clase de adrese IP
Odată cu extinderea Internet, a devenit necesară creşterea numărului
de adrese de reţea, realizată de schema cu clase de adrese (1981, RFC 791)
din figura 1.4. În dezvoltarea schemei 1, aceasta prevede separarea, la
începutul câmpului identificatorului de reţea, a unui subcâmp, în care se
specifică clasa adresei (fig. 1.7). Sunt definite cinci clase de adrese: A, B, C,
D şi E. Structura lor este prezentată în figura 1.7.
0………………........................ ……………………………….…....31
Structura
Clasă adresă ID reţea ID gazdă
generală
0 1………..........7 8..................….………..…………….….......31
0 ID reţea ID gazdă Clasa A
01 2…..…………..…….........15 16………......……………......…31
10 ID reţea ID gazdă Clasa B
0123 ……….……….....………………………...23 24……...….....31
110 ID reţea ID gazdă Clasa C
01234………………………………….....………………………..…...31
1110 Adresă multiadresat (multicast) Clasa D
012345………………….…………….....………………..……..…...31
11110 Rezervat pentru utilizare viitoare Clasa E
Fig. 1.7. Structura adreselor IPv4.
Folosind datele din figura 1.7, se poate calcula numărul de
identificatoare de reţea şi al celor de gazdă posibile pentru fiecare clasă de
adrese. Rezultatele obţinute sunt sistematizate în tabelul 1.6.
Cunoscând primul număr zecimal al unei adrese IPv4, se poate
identifica clasa acestei adrese (vezi coloanele 1 şi 4 ale tabelului 1.6). Ştiind
clasa adresei, se poate uşor separa ID reţea şi ID staţie în cadrul acesteia.
45
Exemplul 1.2. Fie adresa IPv4 192.74.35.61. Această adresă este de
clasa C, deoarece primul număr zecimal aparţine intervalului [192; 223].
Fiind adresă de clasa C, ID reţea este 192.74.35.0, iar ID staţie este
0.0.0.61.
Tabelul 1.6. Caracteristici ale claselor de adrese Internet
Clasă Numărul de identificatoare disponibile Intervalul de valori ale
adrese de reţea de staţie primului număr din adresă
A 27 – 2 = 126 224=16777216 1-126
14 16
B 2 = 16384 2 = 65536 128-191
21 8
C 2 =2097152 2 = 256 192-223
Notă. Este necesară o atenţie deosebită la lansarea unor cereri de difuzare. Fiind
adresate tuturor staţiilor din reţeaua specificată, ele o încarcă respectiv.
1.5.1.4. Schema de adrese cu subreţele
Schema cu subreţele (1985, RFC 950) este utilă în cazurile când o reţea
este rezonabil, din raţionamente de administrare sau tehnice, de divizat în
două sau mai multe subreţele. Esenţa acestei scheme constă în aceea că ID
staţie se interpretează ca ID subreţea (biţii superiori respectivi) şi noul ID
staţie (biţii inferiori respectivi), cum este prezentat în figura 1.5. Toate
staţiile ce aparţin de o subreţea pot fi adresate prin grupul lor comun de
cei mai semnificativi biţi, constituit din biţii „ID reţea” + „ID subreţea” (fig.
1.8), denumit şi „prefix de subreţea”.
ID reţea ID staţie
ID reţea ID subreţea ID staţie
Fig. 1.8 Crearea unei subreţele prin fragmentarea ID staţie.
Pentru separarea prefixului de subreţea de „ID staţie”, serveşte masca

de subreţea de lungime variabilă. O mască de subreţea este reprezentată,
în binar, printr-un şir de biţi „1”, numărul cărora este egal cu numărul de
biţi superiori ai prefixului de subreţea. Cunoscând cei 32 biţi ai adresei IP şi
masca de subreţea a acesteia, separarea prefixului de subreţea de ID staţie
se efectuează aplicând operaţia logică ŞI între biţii de acelaşi ordin ai
adresei IP şi cei ai măştii de subreţea. Rezultatul operaţiei este prefixul de
46
subreţea, iar restul este ID staţie. Evident, masca de subreţea poate fi
reprezentată şi prin patru numere zecimale delimitate prin punct, ca şi o
adresă IP în formă zecimală.
Exemplul 1.3. Fie adresa IPv4 de clasa C 192.168.42.180; masca de
reţea a acesteia este 255.255.255.0, ID reţea este 192.168.42.0 şi ID staţie
este 0.0.0.180. Să împărţim această reţea în 8 subreţele a câte 30 de staţii
fiecare. În acest scop, formăm prefixul de subreţea din ID reţea şi trei biţi
superiori (23 = 8) ai ID staţie, obţinând 192.168.42.160, iar noul ID staţie
devenind 0.0.0.20. Informaţiile respective, inclusiv în formă binară, sunt
prezentate în tabelul 1.7.
De menţionat că, în cadrul fiecăreia din cele 8 subreţele formate în
acest exemplu, cei 5 biţi pentru ID staţie subreţea permit 2 5 = 32 adrese.
Însă două din acestea şi anume „x.x.x.0” şi „x.x.x.1”, având funcţii speciale
nu pot fi folosite în calitate de adrese pentru interfeţe. De aceea într-o
subreţea pot fi până la 32 – 2 = 30 adrese pentru interfeţe.
1.5.1.5. Schema CIDR
În 1993, pentru a reduce dimensiunea tabelelor de rutare şi, de
asemenea, pentru a reduce din deficitul de adrese IPv4, sistemul cu clase
de adrese Internet este oficial înlocuit cu cel CIDR (Classless Inter-Domain
Routing). Schema CIDR (RFC 1518, RFC 1519, RFC 4632) prevede stabilirea
hotarului între ID reţea şi cel ID staţie la nivel de bit, folosind măştile de
reţea ca şi în cazul schemei cu subreţele. Astfel, câmpul „Clasă adresă” (fig.
1.7), folosit în schema cu clase de adrese nu mai este necesar, însă devine
obligatorie folosirea măştilor de reţea.
Sintaxa CIDR a adresei IPv4 include adresa IPv4 specificată prin patru
numere zecimale delimitate prin punct, urmată de o oblică dreapta şi
numărul biţilor superiori (toţi biţii inferiori sunt „0”) pentru ID reţea –
număr, care poate fi interpretat ca o formă mai scurtă de notare a măştii
de reţea.
Exemplul 1.4. Adresa IPv4 în notare CIDR 192.74.35.61/29 se referă la
staţia cu ID staţie 0.0.0.5 din reţeaua cu ID reţea 192.74.35.56, iar adresa
173.29.42.132/28 se referă la staţia cu ID staţie 0.0.0.4 din reţeaua cu ID
reţea 173.29.42.128.
De menţionat că notarea CIDR „/x”, unde „x” arată numărul biţilor
superiori ai ID reţea/subreţea, cei inferiori fiind „0”, determină lungimea în
biţi a prefixului de reţea/subreţea şi deseori se mai numeşte şi, pur şi
simplu, „prefix de reţea/subreţea”, omiţând cuvântul „lungimea”. De
asemenea, la referirea unei reţele/subreţele care are prefixul /x, se
47
foloseşte şi sintagma prescurtată „reţea/subreţea /x”. Mai mult ca atât,
uneori această notare (/x) serveşte şi pentru specificarea blocului de
adrese CIDR, disponibil într-o reţea/subreţea /x.
Tabelul 1.7. Exemplu de divizare a unei reţele de clasa C în 8 subreţele
Forma binară Forma .zecimală
Adresa IP 11000000 10101000 00101010 192.168.42.180
10110100
Starea iniţială – o reţea de clasa C
Masca reţea 11111111 11111111 11111111 255.255.255.0
00000000
ID reţea 11000000 10101000 00101010 192.168.42.0
00000000
ID staţie 00000000 00000000 00000000 0.0.0.180
10110100
Divizarea în 8 subreţele a câte 30 de adrese de interfeţe fiecare
Masca subreţea 11111111 11111111 11111111 255.255.255.224
11100000
Prefixul subreţea 5 10101101 00011101 00101010 192.168.42.160
10100000
ID staţie subreţea 00000000 00000000 00000000 0.0.0.20
00010100
Alte 7 prefixe de subreţea
00000000
00100000
01000000
01100000
10000000
11000000
11100000
Pentru iniţierea în folosirea sistemului CIDR, pot fi utile informaţiile
tabelului 1.8.
48
Tabelul 1.8. Unele caracteristici ale sistemului CIDR
Bloc de adrese Număr maxim de
Masca de reţea
CIDR adrese de interfeţe
/32 255.255.255.255 1
/31 255.255.255.254 2* (RFC 3021)
/30 255.255.255.252 4–2=2
/29 255.255.255.248 8–2=6
/28 255.255.255.240 16 – 2 = 14
/27 255.255.255.224 32 – 2 = 30
/26 255.255.255.192 64 – 2 = 62
/25 255.255.255.128 128 – 2 = 126
/24 255.255.255.0 256 – 2 = 254
/23 255.255.254.0 512 – 2 = 510
/22 255.255.252.0 1024 – 2 = 1022
/21 255.255.248.0 2048 – 2 = 2044
/20 255.255.240.0 4196 – 2 = 4194
*Aplicabilă doar pentru legături punct-la-punct (P2P);
specificarea adreselor de reţea şi multiadresat nu este
necesară.
Conform RFC 3061, în cazul unor legături punct-la-punct, cele două
adrese disponibile în blocul de adrese CIDR /31 (tabelul 1.8) trebuie
interpretate ca adrese de interfeţe; adică deja ele nu se interpretează una
ca fiind adresă de reţea, iar cealaltă ca fiind adresă de difuzare.
1.5.1.6. Divizarea în subreţele CIDR
De menţionat că în cadrul unui bloc de adrese CIDR (unei reţele definite
în notare CIDR) tot pot fi create două sau mai multe subreţele ca şi în cazul
folosirii „schemei cu subreţele” şi clase de adrese (vezi s. 1.5.1.4),
modalitatea creării acestora fiind aceeaşi. În cazul general de n biţi pentru
ID staţie subreţea, numărul disponibil de adrese de interfeţe într-o
subreţea este egal cu 2n – 2.
Unele informaţii, privind divizarea unei reţele cu prefixul /24 (de clasa
C) în subreţele de diferite dimensiuni, sunt prezentate în tabelul 1.9.
1.5.1.7. Atribuirea de blocuri CIDR
Menirea CIDR constă în alocarea adreselor IPv4 rămase în blocuri de
dimensiune variabilă (tabelul 1.9), fără a ţine cont de clase. Structura
ierarhică de adrese IP în format CIDR este gestionată de IANA şi cinci
49
registre Internet regionale (Regional Internet Registers – RIR), inclusiv, în
Europa, Orientul Apropiat şi Asia Centrală, de cel RIPE NCC (Reseaux IP
Europeens Network Coordination Centre).
Tabelul 1.9. Date referitoare la subreţelele unei reţele cu prefixul /24
Lungime Număr
Număr Număr total
prefix Masca subreţea interfeţe în
subreţele interfeţe
subreţea o subreţea
/25 255.255.255.128 2 126 252
/26 255.255.255.192 4 62 248
/27 255.255.255.224 8 30 240
/28 255.255.255.240 16 14 224
/29 255.255.255.248 32 6 192
/30 255.255.255.252 64 2 128
/31 255.255.255.254 128 2* 256
*Aplicabilă doar pentru legături punct-la-punct; specificarea adreselor
de reţea şi multiadresat nu este necesară.
IANA distribuie registrelor RIR blocuri de adrese mari (cu prefixe de
reţea scurte, cum ar fi, de exemplu, 56.0.0.0/8). RIR împart aceste blocuri
în subreţele, pe care le alocă registrelor Internet locale (local Internet
registers – LIR). LIR, la rândul său, poate împărţi o asemenea subreţea în
subreţele mai mici, pe care le alocă autorităţilor responsabile de nivel mai
jos. Acest proces se poate repeta de un număr rezonabil de ori. Astfel,
reţelele terminale obţin subreţele de dimensiunea preconizată a acestor
reţele într-un viitor nu prea îndepărtat. De asemenea, pentru reţelele
terminale, IETF recomandă conectarea la un singur furnizor de servicii
Internet.
În funcţie de utilizare, deosebesc două categorii de adrese IP ce nu se
intersectează: rutabile global şi speciale. Fiecare adresă IP rutabilă global,
denumită şi absolută, se referă în mod univoc la o interfaţă de comunicaţie
concretă din Internet; aceeaşi adresă absolută poate fi folosită doar pentru
o interfaţă de comunicaţie din Internet. La adresele IP speciale se referă
adresele IP: private, partajabile, legături-locale ş.a., descrise mai jos în ss.
1.5.2-1.5.5.
1.5.2. Adrese IPv4 private
O altă modalitate de extindere a posibilităţilor de alocare a adreselor
IPv4, de rând cu cea CIDR, constă în folosirea adreselor private şi a
sistemului de translatare a adreselor de reţea (Network Address
50
Translation – NAT). În acest scop, IANA a rezervat următoarele diapazoane
de adrese private (RFC 1918, RFC 4193):
1) 10.x.y.z
2) 172.16.x.y – 172.31.x.y
3) 192.168.x.y
unde „x”, „y” şi „z” pot avea orice valoare în diapazonul [0; 255].
Adresele IP private se folosesc, de obicei, în reţele locale, în care
utilizarea de adrese IP rutabile global nu este obligatorie. Adresele private
au semnificaţie doar locală şi pot fi folosite, după propriul plac, fără a fi
necesară obţinerea unui asemenea drept de la vreo autoritate RIR. Pentru
a conecta la Internet o reţea locală, în care sunt folosite adrese IP private,
este necesară o poartă NAT sau un server proxy (mandatar), care ar avea
grijă de interpretarea univocă a adreselor în cauză.
1.5.3. Adrese IPv4 partajabile
În 2012, IANA (RFC 5735, RFC 6598) a rezervat, de asemenea, un spaţiu
de adrese IPv4 partajabile (Shared Address Space) pentru furnizorii de
servicii Internet şi anume cel cu adresa de reţea 100.64.0.0/10, care
conţine 222 adrese. În esenţă, aceste adrese sunt similare celor private –
ele au semnificaţie doar locală, nefiind rutabile global. Acest spaţiu de
adrese este destinat folosirii în cadrul reţelelor furnizorilor de servicii
Internet.
1.5.4. Adrese IPv4 legături-locale
Adrese IPv4 legături-locale (RFC 3927, RFC 5735) sunt cele orientate
pentru folosirea doar în cadrul unui segment de reţea locală (toate staţiile
conectate la un comutator/punte sau la o reţea locală fără fir) sau în cadrul
unei conexiuni punct-la-punct cu o staţie. Ruterele nu înaintează pachetele
cu adrese legături-locale.
Asemenea adrese sunt atribuite interfeţelor de către staţie în mod
local, în cazurile când alte mijloace de atribuire a adreselor (de exemplu,
DHCP) nu sunt disponibile. În IPv4 pentru adrese legături-locale este
rezervat blocul 169.254.0.0/16, cu excepţia primei şi a ultimei subreţele de
tip /24 (169.254.0.0/24 şi 169.254.255.0/24), adică diapazonul de adrese
disponibile este: 169.254.1.0 – 169.254.254.255.
1.5.5. Adrese IPv4 speciale
Adrese IPv4 speciale (RFC 3330, RFC 5735, RFC 6598) sunt adresele
IPv4, diferite de cele rutabile global, inclusiv cele deja descrise mai sus în
51
această secţiune: private, partajabile, legături-locale. Lista acestora este
prezentată în tabelul 1.10.
Tabelul 1.10. Adrese IPv4 speciale conform RFC 5735, 6598
Blocul de adrese Folosire RFC
0.0.0.0/8 Reţeaua curentă (staţia curentă) RFC 1122
10.0.0.0/8 Reţele de uz privat (adrese private) RFC 1928
100.64.0.0/10 Spaţiu de adrese partajat RFC 6598
127.0.0.0/8 Buclă locală (transmisie sie-şi) RFC 1122
169.254.0.0/16 Legături locale RFC 3927
192.0.0.0/24 IETF Protocol Assignments RFC 5736
192.0.2.0/24 TEST-NET-1 RFC 5737
192.88.99.0/24 6to4 Relay Anycast RFC 3068
198.18.0.0/15 Network Interconnect Device Benchmark RFC 2544
Testing
198.51.100.0/24 TEST-NET-2 RFC 5737
203.0.113.0/24 TEST-NET-3 RFC 5737
224.0.0.0/4 Multiadresat RFC 3171
240.0.0.0/4 Reservat pentru utilizări viitoare RFC 1112
255.255.255.255/32 Difuzare în reţeaua curentă RFC 919, RFC 922
De menţionat că adresa IPv4 0.0.0.0 este folosită de staţii atunci când

acestea sunt pornite, iar adresele IPv4 cu 0 ca ID reţea se referă la reţeaua
curentă. Aceasta permite staţiilor să refere propria reţea, cunoscând doar
blocul de adrese al acesteia (numărul de biţi „1” ai măştii de reţea), nu şi
ID-ul concret al acesteia.
Adresele de forma 127.x.x.x pot fi folosite doar pentru testări în buclă
locală (transmisii sie-şi). Pachetele trimise către o asemenea adresă sunt
prelucrate doar local, fiind, totodată, tratate ca pachete sosite. Adresele,
care conţin doar biţi „1”, permit difuzarea în reţeaua curentă. Alte utilizări
speciale pot fi consultate în RFC-urile respective din tabelul 1.6.
1.5.6. Caracterizare generală a protocolului IPv6
Protocolul IP versiunea 6 (IPv6) a fost aprobat de IETF în 1996 (RFC
1883) şi ulterior dezvoltat (RFC 2460 – RFC 2466 ş.a.). Având aceeaşi
destinaţie ca şi IPv4, el se deosebeşte de acesta, în principal, prin înlocuirea
adreselor IP de 32 biţi cu adrese de 128 biţi, în scopul depăşirii deficitului
de adrese IPv4. Astfel, IPv6 dispune de 2128 ≈ 3,4  1038 adrese, adică de
52
cca. 7,9  1028 ori mai multe, decât IPv4. Adresele IPv6 constau din opt
grupuri a câte patru cifre hexazecimale separate prin caracterul două
puncte „:”, de exemplu
1998:0ab2:34c6:1235:3ac0:7de2:4325:0430.
De menţionat că în februarie 2011, IANA a alocat celor cinci registre
Internet regionale ultimul set din cinci blocuri de adrese IPv4 /8.
Totodată, IPv6 realizează şi noi funcţionalităţi. El simplifică aspectele ce
ţin de atribuirea adresei (autoconfigurarea adresei independent de stare –
stateless address autoconfiguration-SLAAC), reenumerarea reţelelor şi
anunţarea ruterelor la schimbarea furnizorilor de conectare în reţea.
Dimensiunea subreţelelor IPv6 este standardizată prin fixarea dimensiunii
ID staţie la 64 biţi; aceasta facilitează mecanismul automat de formare a ID
staţie, în baza informaţiei de adresare a mediului de transmisie la nivel
Legătură de date (adresa MAC). În IPv6 sunt, de asemenea, integrate
funcţionalităţile ce ţin de securitate în reţea, inclusiv cele IPsec.
Deşi IPv6 nu este interoperabil cu IPv4, el permite crearea unei reţele
paralele. Pentru schimbul de trafic între reţele IPv6 şi Ipv4, sunt necesare
porţi translatoare speciale. Dar acest lucru nu este obligatoriu în cazurile,
când funcţionalităţile respective sunt implementate în cadrul sistemelor de
operare ale staţiilor şi aplicaţiile respective; tot în acest scop se poate
folosi, de către sistemele de operare, un protocol de tunelare de tipul celor
6to4, 6in4 sau Teredo.
Antetul IPv6 este semnificativ diferit de cel IPv4. Totuşi, IPv6 este, în
mare parte, o extensie a IPv4. Majoritatea protocoalelor de nivel Transport
şi de cel Aplicaţie nu necesită sau necesită puţine modificări pentru a opera
cu IPv6. Excepţie sunt doar protocoalele de nivel Aplicaţie, care
încorporează adrese de nivel Internet, cum ar fi FTP şi NTPv3.
Lipsa interoperabilităţii protocoalelor IPv4 şi IPv6 face lentă trecerea de
la IPv4 la IPv6. Deşi a fost aprobat în 1996, la 20 aprilie 2014 traficul IPv6
era de circa 3 % [12].
Particularităţi ale IPv6. La conectarea în reţea, staţiile IPv6 se pot
autoconfigura (SLAAC), folosind Protocolul de regăsire a vecinului
(Neighbor Discovery Protocol – NDP) prin mesaje ICMPv6 de regăsire a
ruterului. La prima conectare în reţea, staţia trimite prin legătura locală o
cerere multiadresat ruterului, solicitând parametrii de configurare. Ruterul
răspunde cu un pachet de informare, care conţine parametrii de configu-
rare de nivel reţea. Dacă o aplicaţie nu suportă SLAAC IPv6, atunci poate
folosi pentru configurare DHCPv6 sau staţia poate fi configurată manual.
53
În IPv6 nu sunt definite adrese de difuzare ca în IPv4. Pentru transmiteri
multiadresat în IPv6, pachetul respectiv se trimite către toate nodurile
grupului multiadresat legătură-locală la adresa ff02::1, care este similară
multiadresării IPv4, folosind adresa 224.0.0.1.
Antetele pachetelor IPv6, având mai puţine câmpuri (8 obligatorii)
comparativ cu cele IPv4 (13 obligatorii), necesită, de obicei, mai puţine
procesări de către rutere. De asemenea, ruterele IPv6 nu efectuează
fragmentarea segmentelor primite de la nivelul Transport. Staţiile IPv6
trebuie să identifice lungimea maximă a pachetelor ce pot fi înaintate pe o
cale anume (path MTU identifier), pentru a beneficia de posibilitatea de a
transmite pachete mai mari de 1280 octeţi (acestea pot fi de până la (2 16 –
1) octeţi)), şi să efectueze, în caz de necesitate, fragmentarea punct-la-
punct a mesajelor la nivelul Transport sau să transmită segmente ce s-ar
încadra în pachete IPv6 de lungime de până la 1280 octeţi (la IPv4 aceasta
este de 576 octeţi).
Totuşi, opţional, un pachet-jumbogramă IPv6 poate avea lungimea de
până la (232 – 1) octeţi, pe când un pachet-datagramă IPv4 – de până la (216
– 1) octeţi. Jumbograme se numesc pachetele IPv6 care depăşesc lungimea
de (216 – 1) + 40 octeţi. Pentru a opera eficient cu jumbogramele, un nod
IPv6 trebuie să suporte opţiunea „Jumbo Payload” (informaţii utile jumbo,
RFC 2675).
IPv6 nu prevede folosirea sumei de control nici pentru pachet în
ansamblu, nici pentru antet. Funcţiile respective revin nivelelor Legătură
de date şi Transport.
Câmpul TTL al IPv4 a fost redenumit, la Ipv6, în „Limita de salturi” (Hop
Limit), ţinând cont de faptul că de la rutere nu se cere calcularea timpului
reţinerii pachetelor în cadrul acestora.
1.5.7. Adrese IPv6
O adresă IPv6 (RFC 4291) serveşte pentru identificarea unică a
interfeţei de reţea a unei staţii sau a altui nod al unei reţele IPv6.
Clasificarea adreselor IPv6. Adresele IPv6 pot fi: monoadresat
(unicast), oriceadresat (anycast) şi multiadresat (multicast). O adresă
monoadresat specifică o singură interfaţă de reţea, pe când una
oriceadresat este atribuită unui grup de interfeţe, ce aparţin, de obicei,
diferitor noduri. În ambele cazuri, pachetele se livrează la o interfaţă, doar
că în primul caz fără alternative, iar în al doilea – la una din interfeţele
grupului respectiv, de obicei la cea mai apropiată. Adresele oriceadresat au
54
acelaşi format ca şi cele monoadresat, fiind diferite doar prin prezenţa lor
în mai multe puncte (la mai multe interfeţe).
O adresă multiadresat se referă la un grup de staţii, iar pachetele
trimise la o asemenea adresă sunt livrate tuturor interfeţelor grupului
respectiv. De menţionat că IPv6 nu foloseşte adrese de difuzare ca IPv4.
Difuzarea IPv4 este substituită de adresarea multiadresat către toate-
nodurile legătură-locală ale grupului multiadresat ff02::1. Totuşi, folosirea
grupurilor toate-nodurile nu este recomandată şi majoritatea
protocoalelor IPv6 folosesc un grup multiadresat legătură-locală dedicat
pentru evitarea perturbării fără rost a fiecărei interfeţe în reţea.
Formatul adreselor IPv6. După cum a fost menţionat în s. 1.5.6,
adresele IPv6 au lungimea de 128 biţi. Formatul acestora depinde de tipul
lor: monoadresat, oriceadresat sau multiadresat. Adresele monoadresat şi
oriceadresat au acelaşi format constituit din prefixul reţelei, folosit pentru
rutare, şi identificatorul interfeţei, folosit pentru identificarea interfeţei de
comunicaţie în cadrul reţelei (fig. 1.9). Spre deosebire de schemele pentru
adrese IP pe 32 biţi, la IPv6 hotarul dintre prefixul reţelei şi ID interfaţă
este unul fix: cei mai semnificativi 64 de biţi ţin de prefixul reţelei, iar
ceilalţi 64 de biţi – de ID interfaţă. Prefixul reţelei constă din prefixul de
rutare şi ID subreţea. Dimensiunea prefixului de rutare poate varia, odată
cu care se modifică respectiv şi dimensiunea ID subreţea.
Câmp Prefixul de rutare ID subreţea ID interfaţă
Biţi 48 sau mai mulţi 16 sau mai puţini 64
Fig. 1.9. Formatul adreselor monoadresat şi oriceadresat.
ID interfaţă este generat în mod automat, în baza adresei MAC a
interfeţei, folosind formatul EUI-64 modificat, sau este obţinut de la un
server DHCPv6, sau este stabilit automat aleatoriu, sau este atribuit
manual.
O adresă legătură-locală este un caz particular de adresă monoadresat
şi este constituită din prefixul de reţea pe 10 biţi, urmat de 54 de biţi „0” şi
apoi – de ID interfaţă pe 64 biţi (fig. 1.10). Prefixul folosit este 1111111010.
Astfel, prefixul de reţea, constituit din câmpurile „prefix” şi cei 54 de biţi
„0”, este acelaşi pentru toate adresele legătură-locală, acestea astfel fiind
nerutabile.
Câmp Prefixul Zerouri ID interfaţă

Biţi 10 54 64
Fig. 1.10. Formatul adreselor legătură-locală.
55
Formatul adreselor multiadresat depinde de aplicaţie, la forma
generală prezentat în fig. 1.11.
Câmp Prefixul Fanion Sc ID group

Biţi 8 4 4 112
Fig. 1.11. Formatul general al adreselor multiadresat.
Prefixul folosit este întotdeauna 11111111. Cei 4 biţi ai câmpului
„Fanion” specifică situaţii aparte privind prefixul de reţea ş.a. Câmpul
„Domeniu” (Scope – Sc) de 4 biţi este folosit pentru specificarea cazurilor,
în care adresa este validă şi unică.
Există şi adrese multiadresat speciale.
Adresele IPv6 sunt reprezentate prin 8 grupuri de patru cifre
hexazecimale specificate cu majuscule nesemnificative (case-insensitive),
separate prin caracterul două puncte („:”), de exemplu
1998:0ab2:34c6:1235:3ac0:7de2:4325:0430.
Evident, fiecare din cele 8 grupuri se reprezintă în binar pe 16 biţi (2
octeţi), câte 4 biţi pentru fiecare cifră hexazecimală aparte. Totodată, deşi
este permisă şi reprezentarea cifrelor hexazecimale mai mari de 9 cu
majuscule, se recomandă, totuşi, folosirea în asemenea cazuri doar a
reprezentării cu minuscule. Astfel, grupul ACD0 este mai bine de specificat
acd0.
La reprezentarea adreselor IPv6, sunt permise şi abrevieri, inclusiv:
a) eliminarea şirurilor din una sau mai multe cele mai semnificative
cifre 0 în cadrul fiecăruia din cele 8 grupuri de patru cifre, de exemplu
grupul 0032 poate fi înlocuit cu cel 32;
b) grupurile de patru cifre hexazecimale egale cu 0 pot fi reprezentate
printr-o singură cifră 0, de exemplu 2006:ab2:0:0:0:7de2:0:430;
c) grupurile succesive de 0 pot fi reprezentate prin două separatoare de
grupuri consecutive, de exemplu 2006:ab2::7de2:0:430, 0:0:0:0:0:0:0:1 =
::1 şi 0:0:0:0:0:0:0:0 = ::; totodată, în cadrul unei adrese, o asemenea
înlocuire poate fi folosită doar o singură dată (de exemplu, adresa
1:20::b2:acd1 este valabilă, însă cea 1:20::aec2::3:bc1 nu este valabilă);
d) notare quad-punctată folosită pentru redarea adreselor IPv6 mapate
IPv4 şi compatibile celor IPv4. În acest scop, ultimii 32 de biţi ai unei adrese
IPv6 se scriu în notarea folosită la IPv4. De exemplu, adresa IPv6 mapată
IPv4 ::ffff:c002:320 se scrie de obicei, ca ::ffff:194.1.3.32, exprimând, astfel,
clar adresa originală IPv4 ce a fost mapată în una IPv6.
56
Pentru delimitarea prefixului de rutare de cel ID subreţea (fig. 1.9) într-
o adresă IPv6, se foloseşte notarea CIDR. De exemplu, prefixul de rutare
2006:ab2:234::/48 se referă la blocul de adrese ce începe cu adresa
2006:ab2:234:0:0:0:0:0 şi se încheie cu cea
2006:ab2:234:ffff:ffff:ffff:ffff:ffff.
Blocul de adrese în cauză conţine 2128-48 = 280 adrese.
Pentru a exclude conflictul dintre separatorul „:” folosit în adrese IPv6
şi caracterul „:”, folosit în cadrul URI şi URL înainte de numărul de port,
adresele IPv6 literale sunt cuprinse în paranteze pătrate, de exemplu:
http://[2006:ab2:234:a2:c1:da:12:af3]/
sau
http://[2006:ab2:234:a2:c1:da:12:af3]:324/
în ultima adresă fiind specificat numărul de port 324.
Alocarea adreselor IPv6. IANA (iana.org) alocă celor 5 RIR-uri blocuri de
adrese de la /23 până la /12. RIR-urile atribuie LIR-urilor blocuri de adrese,
de obicei, de la /32 până la /19, care, la rândul lor, le distribuie
companiilor/utilizatorilor în blocuri de la /56 până la /48. Deoarece spaţiul
disponibil de adrese este foarte larg, decade necesitatea în folosirea
nodurilor de translatare a adreselor de reţea (NAT).
În scopul asigurării posibilităţii de schimbare a furnizorului de servicii
Internet (Internet Service Provider – ISP) fără renumerotare, RIR-urile pot
aloca companiilor/utilizatorilor spaţii de adrese independente de furnizorul
de servicii Internet din şirul 2001:678::/29. Comunicarea cu ISP se
efectuează prin Puncte de schimb Internet (Internet Exchange Points –
IXPs) cărora le sunt alocate adrese speciale din şirul 2001:7f8::/29.
Adrese IPv6 oriceadresat rezervate. Prima adresă (cea mai mică) în
cadrul fiecărui prefix de subreţea (ID interfaţă conţine doar grupuri 0) este
rezervată ca adresă oriceadresat „subreţea-ruter” (RFC 4291). Această
adresă poate fi folosită de aplicaţii pentru comunicare cu oricare din
ruterele disponibile.
Ultima (cea mai mare) adresă (128) în cadrul fiecărui prefix de subreţea
/64 este rezervată pentru folosirea în calitate de adresă oriceadresat (RFC
2526). La aceste adrese, primii 57 de biţi ai ID interfaţă sunt 1, următorii 7
biţi constituind ID oriceadresat.
Adrese IPv6 speciale (RFC 5156). La adresele IPv6 speciale se referă:
a) adrese monoadresat:
1) nespecificate (unspecified) ::/128 (corespunde celei IPv4 0.0.0.0/32).
Aceasta nu trebuie atribuită la vreo interfaţă, având destinaţia de
57
folosire doar în aplicaţii, înainte ca acestea să fi identificat adresa
gazdei sursă adecvate pentru o conexiune în aşteptare. Ruterele nu
trebuie să înainteze pachete cu asemenea adrese. Aplicaţiile trebuie
să asculte una sau mai multe interfeţe specifice privind conexiunile de
intrare, arătate în listele de conexiuni Internet active pentru o adresă
Internet specifică. Când este arătată o adresă nespecificată, înseamnă
că o aplicaţie ascultă conexiunile de intrare pe toate interfeţele
disponibile;
2) rută implicită ::/9 – adresa rutei monoadresat implicite (corespunde
celei IPv4 0.0.0.0/0));
3) locale ::1/128 şi fe80::/10. Adresa buclă locală ::1/128 este o adresă
monoadresat staţie-locală. Dacă o aplicaţie a unei staţii trimite
pachete la o asemenea adresă, suita de protocoale va îndrepta aceste
pachete înapoi către aceeaşi interfaţă virtuală (corespunde adresei
IPv4 127.0.0.0/8). Adresele fe80::/10 în prefixul legătură-locală sunt
valide şi unice în cadrul unei singure legături. În cadrul prefixului este
alocată o singură subreţea (54 de biţi 0), obţinând efectiv un prefix de
reţea fe80::/64. Cei mai puţin semnificativi 64 biţi reprezintă, de
obicei, adresa interfeţei determinate în baza adresei MAC EUI-64
modificate (vezi s. 1.5.9). O adresă legătură-locală este solicitată
pentru orice interfaţă IPv6, adică aplicaţiile se pot baza pe existenţa
unei adrese legătură-locală chiar şi atunci când nu există rutarea IPv6.
Aceste adrese sunt comparabile cu adresele IPv4 autoconfigurabile
169.254.0.0/16;
4) unice locale fc00::/7, destinate pentru comunicare locală. Ele sunt
rutabile doar în cadrul unui set de situri cooperabile (similare cu
blocurile de adrese private IPv4 10.0.0.0/8, 172.16.0.0/12 şi
192.168.0.0/16). În prefixul de rutare, adresele includ un număr
pseudoaleatoriu pe 40 de biţi, pentru reducerea riscului de conflicte,
în cazul de fuzionare de situri sau de pachete rutate eronat. Pentru
adrese atribuite local, RFC 4193 defineşte doar prefixul fc00::/8;
5) de tranziţie de la IPv4 ::ffff:0:0/96, ::ffff:0:0:0/96, 64:ff9b::/96 şi
2002::/16. Prefixul ::ffff:0:0/96 este pentru adrese IPv6 mapate IPv4.
Aplicaţiile server necesită doar deschiderea un singur soclu de
ascultare pentru gestionarea conexiunilor de la clienţi folosind IPv6
sau IPv4. Clienţii Ipv6 vor fi gestionaţi implicit, iar cei IPv4 apar ca
clienţi IPv6 la adrese IPv6 mapate IPv4. Prefixul ::ffff:0:0:0/96 este
folosit pentru adrese IPv4-translate, care sunt folosite de protocolul
SIIT (Stateless IP/ICMP Translation) (RFC 4213). Prefixul „bine-
58
cunoscut” 64:ff9b::/96 este folosit în adrese pentru translatare
automată IPv4/IPv6 (RFC 6052). Prefixul 2002::/16 este folosit pentru
adresarea 6to4;
6) de destinaţie specială 2001::/32, 2001:2::/48 şi 2001:10::/28. Blocul
de adrese 2001::/32 este folosit pentru tunelarea Teredo. Blocul de
adrese 2001:2::/48 este folosit pentru evaluarea comparativă
(benchmarking) a IPv6 (RFC 5180). Blocul de adrese nerutabile
2001::/28 este folosit pentru ID de haşare criptografici (Cryptographic
Hash Identifiers) (RFC 4843).;
7) pentru documentaţie 2001:db8::/32. Adresele trebuie să fie folosite
oriunde se aduc exemple de adrese IP6 sau se descriu scenarii model
de reţele (corespund la cele IPv4 192.0.2.0/24, 198.51.100.0/24 şi
203.0.113.0/24) (RFC 5737);
b) adrese multiadresat:
1) ff00::0/8. Adresele acestui bloc sunt rezervate de IANA şi nu pot fi
atribuite nici unui grup multiadresat (RFC 4291);
2) adrese obişnuite multiadresat – unele sunt prezentate în tabelul 1.11;
3) nod-solicitat. Cei mai puţin semnificativi 24 de biţi ai ID-ului grupului
de adrese multiadresat nod-solicitat sunt completaţi cu cei mai puţin
semnificativi 24 de biţi ai adresei monoadresat sau oriceadresat a
interfeţei. Aceste adrese permit rezoluţia adresei de nivel Legătură de
date prin NDP (Neighbor Discovery Protocol) fără a deranja toate
nodurile reţelei locale. Staţiei i se cere să adere la un grup
multiadresat nod-solicitat pentru fiecare adresă a sa monoadresat
sau oriceadresat configurată.
Autoconfigurare adrese fără stare (RFC 4862). La lansarea sistemului
de operare, nodul creează în mod automat, la fiecare din interfeţele IPv6
active, o adresă legătură-locală cu prefixul fe80::/64, chiar dacă adresele
rutabile global sunt configurate manual sau obţinute prin protocoale de
configurare speciale, cum ar fi DHCPv6. Această operaţie se realizează, fără
vreo oarecare configurare prealabilă, de către SLAAC (Stateless address
autoconfiguration – Autoconfigurare adresă fără stare), folosind o
componentă a NDP (Network Discovery Protocol). Adresa este obţinută ca
răspuns la cererea staţiei de solicitare a ruterului (RFC 4861).
Identificatorul interfeţei se determină în mod automat de către staţie, în
baza adresei MAC a interfeţei de reţea (RFC 4291, vezi s. 1.5.9). În acest scop,
dacă adresa MAC este una pe 48 biţi (EUI-48, Extended Unique Identifier-48,
sau MAC-48), atunci aceasta se transformă, mai întâi, în una pe 64 biţi (EUI-
64) prin inserarea secvenţei FFFE (2 octeţi) după primii trei octeţi ai EUI-48
59
(MAC-48). A doua transformare se referă la MAC adrese EUI-64 (originale
sau obţinute din cele EUI-48, MAC-48): bitul U/L – al doilea cel mai puţin
semnificativ bit al celui mai semnificativ octet al EUI-64 este inversat fiind
setat în „1”, ceea ce la IPv6 semnifică „Adresă administrată universal” – „U”
(la EUI-64 dacă acesta este „0”, atunci adresa este administrată universal, iar
dacă este „1”, atunci este administrată local – „L”).
Tabelul 1.11. Adrese IPv6 obişnuite multiadresat
Adresă Descriere Domeniu disponibil
ff0X::1 Identifică grupul tuturor ff01::1 – toate nodurile
nodurilor IPv6 interfaţă-locală;
ff02::1 – toate nodurile
legătură-locală
ff0X::2 Toate ruterele ff01::2 – toate ruterele
interfaţă-locală;
ff02::2 – toate ruterele
legătură-locală;
ff05::2 – toate ruterele sit-
local
ff02::5 OSPF IGP 2 (legătură-locală)
Rutere desemnate OSPF
ff02::6 2 (legătură-locală)
IGP
ff02::9 Rutere RIP 2 (legătură-locală)
ff02::a Rutere EIGRP 2 (legătură-locală)
ff02::d Toate ruterele PIM 2 (legătură-locală)
Disponibilă tuturor
ff0X::fb mDNSv6
domeniilor
Disponibilă tuturor
ff0X::101 Toate serverele NTP
domeniilor
ff02::1:1 Nume legătură 2 (legătură-locală)
ff02::1:2 Toţi-agenţii-dhcp 2 (legătură-locală)
Rezoluţia numelui
ff02::1:3 multiadresat legătură- 2 (legătură-locală)
locală
ff05::1:3 Toate-serverele-dhcp 5 (sit-local)
Adresa multiadresat nod-
ff02::1:ff00:0/104 2 (legătură-locală)
solicitat
Interogări informaţionale
ff02::2:ff00:0/104 2 (legătură-locală)
nod
60
Exemple:
a) adresa MAC EUI-48 00:12:5D:E5:6B:40 se transformă în ID interfaţă
IPv6 02:12:5D:FF:FE:E5:6B:40;
b) adresa MAC EUI-64 00:12:5D:FF:FE:E5:6B:40 se transformă în ID
interfaţă IPv6 02:12:5D:FF:FE:E5:6B:40.
De menţionat, totodată, că folosirea adreselor IPv6, bazate pe adresa
MAC de format EUI-64, nu este obligatorie, îndeosebi în scopuri de
confidenţialitate a utilizatorului. Chiar dacă adresa de interfaţă IPv6 nu
este bazată pe adresa MAC EUI-64, oricum aceasta, spre deosebire de
adresele IPv4, este, de regulă, una globală, ceea ce facilitează identificarea
utilizatorului în baza adresei. Pentru a depăşi asemenea situaţii, sunt
destinate extensiile de confidenţialitate IPv6. La extensii de
confidenţialitate activate (enabled), sistemul de operare generează adrese
IP efemere, concatenând ID staţie generat aleatoriu cu ID reţea (prefixul de
reţea) (RFC 4941). Asemenea adrese efemere se folosesc doar pentru
comunicare cu staţii distante şi nu pot fi, practic, folosite pentru
identificarea activităţii Internet a utilizatorului de către terţe părţi,
deoarece adresa în cauză nu este una constantă.
Timpul de viaţă al adreselor IPv6. Implicit, timpul de viaţă al adreselor
IPv6 pentru interfeţe nu este limitat, cu excepţia cazurilor de setare
specială a acestora. Există două cazuri de limitare prin setare specială a
timpului de viaţă al unei adrese de interfaţă: preferat şi valid. Iniţial adresa
atribuită interfeţei are un timp de viaţă „preferat”; când acesta expiră,
statutul adresei devine „învechită” (deprecated) şi adresa nu mai poate fi
folosită pentru crearea de noi conexiuni; când expiră şi timpul de viaţă
„valid”, atunci adresa devine nevalidă, este ştearsă din interfaţa dată şi
poate fi atribuită unei alte interfeţe din Internet.
Selectarea implicită a adresei IPv6 (RFC 6724). O interfaţă de reţea
IPv6 poate avea mai multe adrese IPv6, de exemplu, o adresă legătură-
locală, una globală, una temporară, etc. Aceste adrese pot fi folosite
diferenţiat, în funcţie de situaţie, staţia destinaţie ş.a. Selectarea unei
adrese într-o situaţie concretă se efectuează conform unui tabel de
preferinţe configurabil pentru utilizator. Tabelul implicit, propus în RFC
6724, este prezentat în tabelul 1.12 şi este valabil atât pentru staţii, cât şi
pentru rutere.
În tabelul 1.12, fiecărui prefix de rutare îi este asociat un nivel de
precedenţă şi o etichetă. Nivelul de precedenţă este folosit pentru sortarea
adreselor destinaţie: adresa cu valoarea nivelului de precedenţă mai mare
este preferabilă faţă de cea cu valoarea acestuia mai mică. Valoarea
61
etichetei serveşte pentru determinarea preferinţei folosirii prefixului unei
adrese sursă cu prefixul unei adrese destinaţie: este de preferat folosirea
adresei sursă S cu adresa destinaţie D, dacă Eticheta (S) = Eticheta (D).
Tabelul 1.12. Selectarea implicită a adresei IPv6 (RFC 6724)
Prefixul Precedenţa Eticheta
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Conform acestui tabel, este preferabilă:
a) folosirea adreselor destinaţie cu un domeniu cât mai restrâns; de
exemplu: folosirea adreselor sursă locale cu adrese destinaţie locale;
comunicări legături-locale faţă de căi rutabile global;
b) folosire adrese sursă 6to4 cu adrese destinaţie 6to4;
c) comunicarea folosind adrese IPv6 faţă de cele IPv4 ş.a.
1.5.8. Trecerea de la IPv4 la IPv6
Lipsa interoperabilităţii IPv6 cu IPv4 face mai dificilă şi lentă trecerea de
la IPv4 la IPv6. În acest scop sunt elaborate diverse mecanisme, unele din
care sunt definite în RFC 4213 ş.a., inclusiv:
a) folosirea tunelării pentru încapsularea traficului IPv6 în reţele IPv4
sau invers conform protocolului 41 al Internet (vezi câmpul „Protocol” al
antetului pachetului IPv4 în s. 2.3.2, RFC 2473). Aceasta este o soluţie nu
prea reuşită, deoarece poate conduce la creşterea latenţei şi, de
asemenea, la dificultăţii cu determinarea MTU a căii (Path MTU). De
asemenea, unele rutere sau noduri NAT pot bloca protocolul 41 al Internet.
De aceea tunelarea în acest scop poate fi folosită doar ca o soluţie
temporară;
b) implementarea stivei duale IP, care prevede implementarea paralelă
a IPv4 şi IPv6 (RFC 4213). Ambele protocoale rulează în infrastructura de
reţea şi atunci nu este nevoie de a încapsula trafic IPv6 în reţele IPv4 sau
invers folosind tunelarea. Însă aplicarea acestei căi nu întotdeauna este
posibilă, deoarece unele echipamente de reţea depăşite nu suportă IPv6
62
sau nu este încă efectuată actualizarea (upgrade) produselor program
respective;
c) tunelarea automată, care permite determinarea automată, de către
infrastructura de rutare, a punctelor terminale ale tunelului, din care: 6to4,
Teredo şi ISATAP. Tunelarea 6to4 este definită în RFC 3055 şi foloseşte
încapsularea conformă protocolului 41 al Internet. Este cea mai aplicată în
prezent şi prevede determinarea punctelor terminale ale tunelului,
folosind la partea distanţă o adresă IPv4 oriceadresat (anycast) bine-
cunoscută şi incorporarea informaţiei privind adresa IPv4 în adresele IPv6
ale părţii locale. Tehnica Teredo foloseşte încapsularea UDP şi poate
traversa mai multe noduri NAT. ISATAP este un mecanism de tunelare
locală, în cadrul unei organizaţii;
d) tunelarea configurată şi automată 6in4 necesită ca punctele
terminale ale tunelului să fie configurate explicit manual de un
administrator, de sistemul de operare sau de un serviciu automat cunoscut
ca broker de tunel. Tunelarea configurată este, de obicei, mai uşor de
verificat, decât cea automată;
e) 6rd (RFC 5569, RFC 5969) foloseşte maparea fără stare a adreselor
între IPv4 şi IPv6 şi transmite pachete IPv6 prin tunele formate automat,
care urmează aceleaşi rute optimizate între staţiile clienţilor ca şi cele ale
pachetelor IPv4;
f) NAT64 (RFC 6052, RFC 6146) permite staţiilor IPv6 ale utilizatorilor să
comunice cu servere IPv4. Serverul NAT64 este punct terminal pentru cel
puţin o adresă IPv4 şi un segment de reţea IPv6 de 32 biţi. Clientul IPv6
incorporează adresa IPv4, cu care doreşte să comunice, folosind aceşti biţi
şi transmite pachetele sale la adresa rezultantă. Serverul NAT64, care a
creat o mapare NAT între adresa IPv6 şi IPv4, le permite să comunice.
1.5.9. Adrese fizice ale entităţilor de reţea
Pentru realizarea transferului de date, entităţile respective ale unei
reţele trebuie să fie posibil de identificat şi adresat în mod univoc. Unele
dispozitive de reţea au o singură legătură cu alte dispozitive, altele – două
sau mai multe. O singură legătură au, de obicei, staţiile, iar mai multe –
nodurile de comunicaţie (ruterele, comutatoarele, etc.).
Distingerea diverselor legături ale unui dispozitiv cu alte dispozitive de
reţea, necesită adresarea aparte a fiecăreia dintre acestea. Fiecare
asemenea legătură se realizează prin intermediul unei cartele de interfaţă
de reţea (network interface controller sau network interface card – NIC),
denumită şi interfaţă de reţea (în multe cazuri interfaţa de reţea este
63
integrată în cadrul plăcii de bază) a dispozitivului în cauză. Deci, pentru
identificarea univocă, este necesară o adresă aparte pentru fiecare
interfaţă de reţea a dispozitivelor acesteia. O asemenea adresă se numeşte
adresă fizică, denumită și adresă MAC. Adresele MAC sunt folosite în reţele
de diverse tehnologii, inclusiv cele Ethernet.
Adresele MAC se formează în conformitate cu regulile uneia din cele
trei spații de nume de numerotare, gestionate de către IEEE (Institute of
Electrical and Electronics Enginears): MAC-48, EUI-48 și EUI-64, unde EUI
este abrevierea pentru Extended Unique Identifier (Identificatorul unic
extins), iar 48 şi, respectiv, 64 specifică numărul de biţi al adresei. Formatul
adreselor MAC-48 este prezentat în figura 1.11.
6 octeţi
a) 1 2 3 4 5 6
Octeţi mai semnificativi
3 octeţi 3 octeţi
b) Identificatorul unic al organizaţiei Extensia identificatorului
8 biţi 0 – monoadresat
1 – multiadresat
b1 b2 b3 b4 b5 b6 b7 b8
Biţi mai semnificativi 0 – unic global (U)

1 – administrat local (L)
Fig. 1.11. Formatul unei adrese MAC-48: a) general; b) cu detalierea octetului 1.
Conform standardului IEEE 802, pentru perceperea umană mai uşoară,

se foloseşte şi o formă de reprezentare a adreselor MAC prin grupuri de
două cifre hexazecimale, separate de caracterul cratimă (-) sau cel două
puncte (:), în ordinea transmisiei.
Exemple de adrese MAC: 00:12:5d:e5:6b:40; 00:12:5d:ff:fe:e5:6b:40;
00-12-5d-e5-6b-40.
Uneori, pentru adresele MAC-48, se foloseşte reprezentarea în formă
de trei grupuri a câte patru cifre hexazecimale, separate prin punct, de
exemplu: 0012.5de5.6b40. De asemenea, cifrele mai mari decât 9 se
64
recomandă de reprezentat prin caractere minuscule, deşi este admisă
folosirea în acest scop şi a caracterelor majuscule respective ca în
exemplul: 00:12:5D:E5:6B:40.
Toate aceste trei sisteme de numerotare, MAC-48, EUI-48 și EUI-64,
folosesc același format, deosebindu-se doar prin lungimea
identificatorului. Adresele MAC pot fi adrese administrate universal sau
adrese administrate local. O adresă MAC administrată universal (U) este în
mod univoc atribuită unui dispozitiv de către producător. Primii trei octeți
(în ordinea transmisiei identifică organizația, care a eliberat identificatorul,
și formează OUI (Organizationally Unique Identifier – identificatorul unic al
organizației). Următorii trei, pentru MAC-48 și EUI-48, sau cinci, pentru
EUI-64, octeți sunt atribuiți de către organizație după propriul plac, dar în
mod univoc. De menţionat că cei mai puţin semnificativi doi biţi ai celui
mai semnificativ octet al OUI au o destinaţie specială, specificată în fig.
1.11 şi descrisă mai jos în această secţiune.
O adresă MAC administrată local (L) este atribuită unui dispozitiv de
către administratorul de reţea, înlocuind adresa specificată de producător.
Asemenea adrese nu conţin OUI.
Pentru a deosebi o adresă administrată local de una administrată
universal, se setează respectiv al doilea cel mai puţin semnificativ bit al
celui mai semnificativ octet al adresei, denumit şi bitul U/L
(Universal/Local): 0 – pentru adresa administrată universal şi 1 – pentru
adresa administrată local (fig. 1.11).
Exemplul 1.5. Fie adresa MAC-48 03:12:5d:e5:6b:40. Cel mai
semnificativ octet al acesteia este 0316, forma binară a lui este 00000011,
în care al doilea cel mai puţin semnificativ bit este 1. Astfel, adresa în cauză
este una locală.
Dacă cel mai puţin semnificativ bit al celui mai semnificativ octet al
adresei (fig. 1.11) este 0, atunci cadrul, cu o asemenea adresă destinaţie,
este menit să fie recepţionat de o singură interfaţă de reţea. Un asemenea
tip de transmisie se numeşte monoadresat (unicast). Un cadru
monoadresat este transmis tuturor nodurilor unui domeniu de coliziuni –
fragment de reţea, mărginit de interfaţa de reţea a celui mai apropiat
comutator (punte) sau ruter. Dar, din toate aceste noduri, doar nodul
destinaţie va accepta cadrul, celelalte ignorându-l.
Dacă cel mai puţin semnificativ bit al celui mai semnificativ octet al
adresei (fig. 1.11) este 1, atunci cadrul poate fi acceptat de mai multe
noduri, în funcţie de anumite criterii, de exemplu, în baza unei liste
65
configurabile de adrese MAC multiadresat. Un asemenea tip de transmisie
se numeşte multiadresat (multicast).
Adresele de format MAC-48 se folosesc în reţele de aşa tehnologii ca:
IEEE 802.3 (Ethernet), IEEE 802.11 (reţele fără fir), IEEE 802.5 (Token Ring),
FDDI, ATM, Fibre Channel, G.hn ş.a.
Deosebirea între EUI-48 şi MAC-48 era una pur nominală:
identificatoarele MAC-48 erau folosite pentru echipamente de reţea, pe
când cele EUI-48 – pentru identificarea unor alte dispozitive şi, de
asemenea, a produselor program. Din acest punct de vedere, un
identificator EUI-48 nu este, de fapt, o adresă MAC. Totuşi,
identificatoarele EUI-48 sunt sintactic indistinctibile de cele MAC-48 şi se
atribuie din acelaşi spaţiu de numerotare.
Totodată, lucrurile evoluează. În prezent, IEEE consideră că notarea
MAC-48, propusă de compania Xerox cu mulţi ani în urmă la proiectarea
reţelelor Ethernet şi folosită pentru adresarea interfeţelor fizice în cadrul
reţelelor bazate pe standardele IEEE 802, poate fi considerată ca o aplicare
specifică a EUI-48 şi este depăşită. În locul notării MAC-48 este
recomandată folosirea celei EUI-48.
Adresele de format EUI-64 se folosesc în reţele de aşa tehnologii ca:
IPv6 (EUI-64 modificat, vezi s. 2.3.3), FireWire, ZigBee (WPAN), IEEE
802.15.4 (WPAN), 6LoWPAN (WPAN) ş.a.
Sistemul de numerotare EUI-64 cuprinde, de asemenea, ca şi cazuri
particulare, sistemele MAC-48 şi EUI-48 printr-un mecanism simplu de
translatare. Pentru a converti un identificator MAC-48 în unul EUI-64, se
copie OUI al MAC-48, apoi se adaugă doi octeţi FFFF şi, ulterior, se copie
cealaltă parte a MAC-48 (extensia). Pentru a converti un identificator EUI-
48 în unul EUI-64, se procedează în mod similar, doar că, în loc de secvenţa
FFFF, se foloseşte cea FFFE. Evident, la necesitate, poate fi efectuată uşor şi
convertirea inversă. De menţionat că în adresele IPv6, care folosesc EUI-64
modificat, translatarea atât a identificatoarelor EUI-48, cât şi a celor MAC-
48 se efectuează cu folosirea doar a secvenţei FFFE, dar nu şi a celei FFFF.
IEEE recomandă folosirea, în produse noi, doar a identificatoarelor EUI-
64, renunţând la cele EUI-48.
1.6. Conectarea la Internet

1.6.1. Alternative de conectare
Accesul la serviciile Internet se realizează pentru staţii aparte
(calculatoare, camere de luat vederi, imprimante, telefoane mobile, etc.) şi
66
reţele de calculatoare. Accesul poate fi total sau limitat. Accesul total
permite folosirea întregii game de servicii, a tuturor facilităţilor comenzilor
aplicabile în Internet. Pentru accesul total este necesară o conexiune
dedicată la Internet. Conexiunea dedicată este mai rapidă, dar şi mai
costisitoare. Mai puţine cheltuieli implică o conexiune comutată, folosind
canale telefonice. Însă în acest caz se realizează, de obicei, doar un acces
limitat – la o gamă redusă de servicii cu viteze de transfer date relativ
joase. Această formă de acces se practică doar pentru staţii aparte şi,
începând cu sfârşitul anilor 1990’, se foloseşte din ce în ce mai rar, cu
excepţia serviciilor de telefonie mobilă. Serviciile de telefonie mobilă
permit accesul la Internet cu viteze de la sute de Kbps până la zeci de
Mbps.
Dacă se cere accesul la Internet de la o singură staţie, atunci ea poate fi
conectată, fie şi la distanţă, la un ruter al furnizorului de servicii. Pentru
conectarea unei reţele locale, la aceasta se instalează un ruter. Prin acest
ruter reţeaua locală se conectează, folosind o conexiune dedicată, la
ruterul furnizorului de servicii Internet. Furnizorii de servicii stabilesc o
anumită taxă pentru serviciile lor.
Conectarea, folosind canale telefonice comutate, se face prin furnizorii
de servicii Internet sau prin alte servicii de reţea. Legătura este stabilită
având un cont telefonic. Când este necesar accesul la Internet, se apelează
telefonic serviciul respectiv. Apelul poate fi făcut şi automat de către staţie,
conform unui orar prestabilit. Printr-o conexiune telefonică comutată sunt
posibile două modalităţi de acces la Internet:
 utilizând un cont Internet telefonic;
 utilizând un cont Internet dedicat.
În cazul unui cont Internet telefonic, abonatul obţine acces la Internet
prin intermediul unui calculator gazdă Internet al furnizorului de servicii.
Acesta este un acces limitat. Abonatul nu dispune de un nume de domeniu,
de o adresă Internet. Calculatorul lui nu are statut de calculator gazdă
Internet, deci nu poate fi adresat direct din Internet. Pe calculatorul gazdă
respectiv al furnizorului de servicii este stabilit un cont telefonic pentru
abonat. Adică este stabilit identificatorul utilizatorului (user ID), denumit şi
nume de conectare (login name), parola şi numărul telefonic de acces ale
acestuia.
În cazul unui cont Internet dedicat, abonatul dispune de propriul nume
de domeniu, de o adresă Internet. Calculatorul abonatului are statut de
calculator gazdă Internet şi este conectat la un ruter al furnizorului de
servicii. Serviciile furnizorului se reduc la rutarea traficului de date prin
67
reţea. Furnizorul de servicii stabileşte, de asemenea, identificatorul, parola,
adresa Internet şi numărul telefonic de acces ale utilizatorului. Contul
dedicat Internet permite un acces mai larg la serviciile Internet, în funcţie
de programele client instalate pe calculatorul abonatului.
1.6.2. Mijloace informatice necesare
Pentru a realiza o conexiune Internet, sunt necesare anumite
echipamente şi produse program. Vom deosebi cerinţele faţă de
echipamente, pentru realizarea conexiunii la Internet, şi cele necesare
pentru rularea unor aplicaţii utilizator sau a unor interfeţe utilizator
speciale, cum ar fi o interfaţă grafică.
Pentru conectarea unei staţii aparte la Internet, resursele de
echipamente necesare sunt determinate de produsele program de
comunicaţie ale serviciilor de aplicaţie utilizate. Însă, pentru a realiza o
conexiune simplă, care ar permite accesul la facilităţile de bază, inclusiv e-
mail, ftp, telnet, nu sunt necesare resurse deosebite.
Totuşi, performanţele staţiei şi ale canalului de comunicaţie sunt
importante. Pentru un lucru intens în Internet, transferul fişierelor de mari
dimensiuni, afişarea imaginilor şi transmiterea secvenţelor video, sunt
necesare performanţe mai înalte ale staţiei şi ale canalului de transfer date
utilizate. Unele tehnologii de acces la reţea sunt descrise succint în s. 1.6.3.
Programele de comunicaţie, pentru conectarea unor staţii la un
calculator sau un nod de comunicaţie al unei reţele, realizează o facilitate
denumită emulare de terminal. Aceasta prezintă staţia utilizatorului către
reţea ca un terminal, folosind doar o parte din posibilităţile staţiei
respective, deşi suportând şi alte funcţii mai evoluate, precum schimbul de
fişiere.
Produsele program pentru conexiuni PPP şi SLIP, conexiuni
caracteristice pentru Internet, realizează protocoalele de nivel Legătură cu
acelaşi nume. De regulă, produsele program, care realizează protocoalele
PPP şi SLIP, încorporează şi componente pentru asigurarea mai multor
servicii de aplicaţie ale suitei de protocoale TCP/IP. Treptat produsele SLIP
se înlocuiesc cu cele PPP, protocolul PPP fiind mai robust, cu facilităţi mai
bogate, mai rapid.
Sistemele de operare, inclusiv cele Windows 95/98/Me/NT/2000/XP/
Vista/7/8/Server 2012, de tip UNIX (Linux, BSD, OS X, Android, iOS,) şi z/OS,
au incorporate utilitarele pentru gestiunea conectării la Internet.
68
1.6.3. Tehnologii de acces
Accesul la Internet este necesar pentru diverse staţii fixe, portabile sau
mobile şi reţele de calculatoare. În funcţie de situaţie şi performanţele
necesare ale conexiunii, se folosesc diverse tehnologii de acces. Acestea
diferă îndeosebi prin mediul de acces:
 linii de abonat telefonice comutate (una sau mai multe);
 canalele reţelelor numerice cu servicii integrate (Integrated Services
Digital Network – ISDN);
 canale (linii) de comunicaţie dedicate;
 reţele de cabluri coaxiale TV;
 linii de abonat numerice xDSL (DSL, ADSL, SDSL, HDSL şi VDSL);
 fibră optică – FTTx (FTTB, FTTC, FTTD, FTTH, FTTN, FTTP);
 linii electrice;
 reţele locale fără fir (Wi-Fi);
 WiMax;
 prin satelit;
 prin telefonia mobilă;
 serviciul local distribuit multipunct (Local Multipoint Distribution
Service – LMDS).
Pentru accesul la Internet, folosind o linie de abonat telefonică
analogică comutată, la staţie (accesul se foloseşte doar pentru staţii, nu şi
pentru reţele locale) se instalează un modem ce se conectează la această
linie. Linia, la rândul său asigură, prin intermediul reţelei telefonice,
conexiunea la unul din modemele nodului de comunicaţie al reţelei
furnizorului de servicii Internet. Viteza de transfer date printr-un asemenea
acces poate fi de până la 56 Kbps.
Accesul la Internet poate fi realizat şi folosind concomitent două sau
mai multe linii de abonat telefonice analogice comutate (bonding). În
asemenea cazuri, la staţie se instalează un număr de modeme egal cu
numărul de linii, câte unul pentru fiecare linie; la fel se procedează şi la
nodul de comunicaţie al reţelei furnizorului de servicii Internet, care
trebuie să suporte serviciul multilegătură. Astfel, se realizează un trunchi
de transfer date din două sau mai multe canale paralele, asigurând o viteză
sumară de transfer date mai mare respectivă. Echipamente pentru
asemenea transferuri de date au lansat companiile Diamond, Ascend, U.S.
Robotics, Angia Communications ş.a. Folosirea acestei tehnologii decade
odată cu implementarea tehnologiilor xDSL, ISDN, modeme pentru cabluri
coaxiale TV ş.a.
69
Reţelele ISDN, prima din care a fost NUMERIS, lansată în Franţa în
1988, sunt reţele telefonice comutate, care transmit atât voce cât şi date în
formă numerică cu viteza de la 2x64 Kbps până la (prin agregare) 30x64
Kbps (23x64 Kbps în SUA şi Canada).
Canalele (liniile) de comunicaţie dedicate ale reţelelor telefonice
publice sau ale altor furnizori se folosesc îndeosebi pentru conectarea
reţelelor locale la Internet. Acestea pot fi fire cablate, fibre optice sau
canale radio. Liniile purtător-E (E-carrier) oferă 32 de canale de 64 Kbps în
cadrul unui trunchi E1 (2 Mbps), 64 canale de 64 Kbps sau 4 canale E1 în
cadrul unui trunchi E2 (8 Mbps) şi 512 canale de 64 Kbps sau 16 canale E1
sau 4 canale E2 în cadrul unui trunchi E3 (34 Mbps).
La viteze mai mari se folosesc canale OS-1 de 51,84 Mbps, OC-3 de
155,52 Mbps, OC-12 de 622,08 Mbps, OS-48 de 2,488 Gbps, OC-192 de
9,953 Gbps şi OC-768 de 39,823 Gbps.
Accesul prin modeme pentru cablu coaxial TV prevede folosirea
reţelelor de TV prin cablu, iar mai recent şi a celor de TV prin fibră optică,
complementate cu modeme speciale. Viteza de transfer date poate fi de la
staţie (ruterul local) către Internet de până la 20 Mbps, iar de la Internet
către staţie (ruterul local) de până la 400 Mbps.
Liniile de abonat numerice (Digital Subscriber Line – DSL) ale reţelelor
telefonice pot fi folosite şi pentru transferuri de date de viteză înaltă.
Tehnologiile folosite în acest scop se numesc generic xDSL. La acestea se
referă tehnologiile:
 ADSL (Asynchronous DSL - DSL asincronă);
 IDSL (ISDN DSL);
 HDSL (High speed DSL - DSL de viteză înaltă);
 SDSL (Single line DSL - DSL dintr-o singură linie);
 VDSL (Very high speed DSL - DSL de viteză foarte înaltă).
Unele din tehnologiile enumerate au avut şi alte denumiri sau au
dezvoltări cu alte denumiri. De exemplu, sunt cunoscute asemenea
dezvoltări sau modificări ale ADSL ca: ADSL Lite (G.lite, G.dmt, Splitter less
ADSL) – o extensie a ADSL ce facilitează conectarea sistemului de abonat;
RADSL (Rate Adaptive DSL) – o versiune specifică de firmă; ADSL2 şi
ADSL2+.
Tehnologiile ADSL, ADSL2 şi ADSL2+ sunt asimetrice privind viteza de
transfer date, asigurând o viteză de transmisie a datelor de la staţie către
Internet de până la 0,9 Mbps cea ADSL şi de până la 3,5 Mbps cele ADSL2 şi
ADSL2+ şi o viteză de transmisie a datelor de la Internet către staţie de
70
până la 9 Mbps cea ADSL, de până la 12 Mbps cea ADSL2 şi de până la 24
Mbps cea ADSL2+.
Tehnologiile HDSL şi SDSL. HDSL este o tehnologie orientată la
realizarea unui canal E1/T1, folosind liniile de abonat pe perechi de fire
torsadate (trei linii pentru E1 şi două pentru T1) de lungime de până la 4
km. SDSL este pur şi simplu o versiune a HDSL, dar pe o singură linie (o
pereche de fire torsadate) cu lungimea de până la 3 km.
Tehnologia VDSL este o altă dezvoltare a tehnologiei ADSL. Deşi
standardele iniţiale pentru tehnologia ADSL au fost aprobate încă în 1997,
pentru VDSL sunt propuse mai multe specificaţii, dar doar în decembrie
2000-ianuarie 2001 au fost aprobate primele standarde de către ETSI, ANSI
şi ITU-T. Spre deosebire de ADSL, tehnologia VDSL prevede operarea atât în
mod asimetric, cât şi în cel simetric. Sunt propuse mai multe rate de
transfer, valorile cărora sunt cuprinse în intervalele:
 pentru regimul de operare asimetric: în direcţia către staţia
abonatului – de la 6 Mbps până la 52 Mbps; în direcţia de la staţia
abonatului – de la 1,3 Mbps până la 16 Mbps;
 pentru regimul de operare simetric – de la 6 Mbps până la 52 Mbps.
Tehnologia VDSL2 este una simetrică cu viteza de transfer date de 100
Mbps în fiecare din cele două direcţii.
Tehnologia de acces FTTx (Fiber-to-the-x – Fibră-către-x) include
alternativele:
 FTTB (Fiber-to-the-building – Fibră-până-la-clădire);
 FTTC (Fiber-to-the-curb – Fibră-până-la-margine);
 FTTD (Fiber-to-the-desk – Fibră-până-la-birou);
 FTTH (Fiber-to-the-home – Fibră-până-la-locuinţă);
 FTTN (Fiber-to-the-node – Fibră-până-la-nod);
 FTTP (Fiber-to-the-premises – Fibră-până-la-sediu).
Fiecare din aceste alternative prevede transferul de date prin fibră
optică până în apropierea staţiei sau a reţelei locale a utilizatorului final,
deosebindu-se între ele doar prin gradul de apropiere. Folosirea fibrei
optice permite, de obicei, viteze de transfer date mai înalte. Nemijlocit
până la staţia utilizatorului se aplică, prin comutatoare sau rutere, alte
tehnologii de acces, cum ar fi DSL, modeme pentru cabluri, LAN, etc.)
Tehnologia de acces la Internet prin linii electrice prevede transferul de
date prin liniile pentru curentul electric. Viteza de transfer date prin linii
electrice poate fi:
 în cadrul unor reţele locale domestice, de până la 1 Gbps şi este
prevăzută de tehnologia G.hn, elaborată sub auspiciul ITU.
71
Standardele respective, G.9960 şi G.9961, sunt aprobate în 2009 şi,
corespunzător, 2010, iar prima demonstrare a produselor, conforme
acestor standarde, a avut loc în ianuarie 2012 [13];
 la distanţe mai mari, în afara unor reţele locale (Broadband over
power line – BPL), viteza de transfer date poate fi de la 500 Kbs până
3 Mbps. În acest scop se folosesc modeme speciale, care se
conectează între priza liniei electrice şi portul Ethernet al staţiei [14].
Accesul la Internet prin reţele locale fără fir (Wireless LAN – Wi-Fi) este
conform standardului IEEE 802.11. Staţiile reţelelor locale fără fir (wireless
LAN – WLAN) pot fi fixe, portabile sau mobile. Staţiile portabile pot fi
relocalizate, dar accesul lor la reţea este fix. Staţiile mobile pot obţine
accesul la reţea şi în mişcare.
Mediul înconjurător, folosit în reţelele WLAN ca mediu de transmisie,
este considerabil diferit, din punctul de vedere al transferului de date, de
mediile cablate [15]:
 nu are hotare distincte de acoperire pentru staţii;
 nu este protejat contra interferării cu alte semnale ce îl partajează;
 este mai puţin fiabil;
 are topologie dinamică;
 are proprietăţi de propagare a semnalului asimetrice şi variabile în
timp ş.a.
Faptul că mediul fără fir nu are hotare distincte de acoperire pentru
staţii, conduce, de exemplu, la aşa probleme specifice ca: problema
staţiei ascunse (hidden station problem) şi problema staţiei expuse
(exposed staion problem).
Problema staţiei ascunse. Fie staţiile A, B şi C sunt amplasate astfel,
că în aria de acoperire a staţiei B intră ambele staţii A şi C, pe când staţia
C nu intră în aria de acoperire a staţiei A şi vice verso. Într-un asemenea
caz, dacă B iniţiază o transmisie, ambele staţii A şi C află acest lucru,
sesizând starea ocupată a mediului, ceea ce este comun şi pentru mediile
de transmisie cablate. Totodată, dacă staţia B nu transmite, atunci atât
staţia A, cât şi cea C, nesesizând starea ocupată a mediului, pot să iniţieze
o transmisie către B. Astfel, la receptorul staţiei B va avea loc o coliziune
de semnale, de care nici A şi nici C nu pot afla, fără folosirea unui
mecanism de confirmare a recepţiei de la B. Dacă o staţie nu poate
detecta un potenţial competitor la mediu (staţie ascunsă), atunci ea se
confruntă cu problema staţiei ascunse.
Problema staţiei expuse. Fie staţiile A, B şi C din exemplul precedent
şi încă o staţie D, în zona de acoperire a căreia este doar staţia C. Dacă
72
staţia B transmite către A, atunci C, chiar dacă şi are de transmis date
către D, nu va iniţia transmisia, deoarece sesizează starea ocupată a
mediului de către transmisia staţiei B. Totodată, staţia D nu este în aria
de acoperire a staţiei B, deci receptorul acesteia nu este, practic,
influenţat de transmisia staţiei B. De asemenea, chiar dacă staţia C şi este
în aria de acoperire a staţiei B, semnalul transmis de către C este mult
mai puternic, decât cel recepţionat de la B, ultimul fiind treptat atenuat
odată cu creşterea distanţei de la sursă; de aceea transmisia staţiei C
către D ar fi relativ calitativă. Într-o asemenea situaţie, staţia C (staţia
expusă) se confruntă cu problema staţiei expuse.
O altă particularitate, comparativ cu interfeţele de reţea pentru medii
de transmisie cablate, constă în faptul că majoritatea interfeţelor de
reţea pentru medii de transmisie fără fir sunt semiduplex, adică nu pot
transmite şi recepţiona semnale concomitent. Aceasta face imposibilă
folosirea în reţele fără fir a metodei de acces la mediu CSMA/CD.
Există şi alte particularităţi ale mediului de transmisie fără fir.
Totodată, subnivelul MAC al reţelelor fără fir nu trebuie să difere, pentru
nivelele superioare (subnivelul Legătură de date – LLC), de cel al reţelelor
cablate. De aceea mobilitatea staţiilor este realizată în cadrul
subnivelului MAC. Din aceleaşi considerente, într-o Asociaţie de reţea cu
securitate robustă (Robust security network association – RSNA),
subnivelul MAC trebuie să asigure şi cerinţele de fiabilitate a funcţionării.
În acest scop, IEEE 802.11 defineşte funcţiile de protecţie a cadrelor, iar
IEEE 802.1X-2004 – autentificarea şi un Port controlat, IEEE 802.11 şi
802.1X-2004 colaborând, totodată, în scopuri de gestiune. Toate staţiile
unei RSNA au o entitate 802.1X-2004, care se ocupă de aceste servicii.
În cazul unor aplicaţii cu cerinţe de calitate speciale, LAN IEEE 802.11
realizează o legătură în cadrul unui mediu QoS staţie-la-staţie, care poate
fi stabilită şi gestionată de entităţile nivelelor superioare. Pentru
asigurarea unor performanţe de calitate, comparabile cu cele ale
reţelelor locale cablate, subnivelul MAC IEEE 802.11 incorporează
facilităţi suplimentare, netradiţionale pentru acest nivel.
Unele caracteristici ale reţelelor conforme standardului IEEE 802.11
sunt prezentate în tabelul 1.13.
Tehnologia WiMax (Worldwide Interoperability for Microwave Access –
Interoperabilitate mondială pentru accesul prin microunde), conformă
standardului IEEE 802.16, este una fără fir propusă în 2001 pentru staţii cu
acces fix (Fixed WiMax) la viteza de transfer date de până la 40 Mbps.
73
Aceasta a fost dezvoltată în 2011, asigurând o viteză de transfer date,
pentru staţii cu acces fix, de până la 1 Gbps.
Tabelul 1.13. Unele caracteristici ale reţelelor IEEE 802.11
Standardul Anul Frecvenţa, la care Viteza de transfer
lansării operează, GHz date (maximă), Mbps
IEEE 802.11 1997 2,4 1; 2
IEEE 802.11a 1999 5 6-54
IEEE 802.11b 1999 2,4 5,5; 11
IEEE 802.11g 2003 2,4 6-54
IEEE 802.11n 2009 2,4; 5 600
IEEE 802.11ac 2014* 5 433-6930
IEEE 802.11ad 2010 60 7000
*Se preconizează lansarea la începutul a. 2014.
Tehnologia WiMax mobilă (Mobile WiMax), conformă standardului IEEE
802.16e-2005, este una fără fir propusă în 2005 pentru staţii mobile,
asigurând o viteză de transfer date de până la 37 Mbps. Aceasta a fost
dezvoltată în 2011 (802.16m-2011), asigurând o viteză de transfer date de
până la 370 Mbps. Distanţa la care operează este de până la 50-70 km,
viteza de transfer date scăzând odată cu creşterea distanţei de conectare.
Accesul la Internet prin satelit poate fi de la staţii fixe, portabile sau
mobile şi este mai scump, de regulă, decât alte modalităţi de acces. De
aceea un asemenea acces este oportun pentru locaţii, în care folosirea
altor modalităţi de acces este ineficientă, din punct de vedere economic,
sau imposibilă la moment (arii puţin populate, munţi, etc.). Transferul de
date este, de obicei, asimetric, folosindu-se viteze de transfer către staţie
de până la 1 Gbps şi de la staţie de până la 10 Mbps.
Accesul la Internet prin telefonia mobilă este posibil atât de la
telefoane mobile (celulare) respective, cât şi de la alte categorii de staţii,
inclusiv calculatoare, dotate cu modeme corespunzătoare. De la prima
implementare, au fost dezvoltate diverse tehnologii de telefonie mobilă.
Caracteristicile unora din acestea este dată în tabelul 1.14.
Accesul la Internet prin serviciul local distribuit multipunct (LMDS)
este o tehnologie fără fir pentru staţii fixe, care operează la frecvenţe în
diapazonul 26-29 GHz. Iniţial aceasta a fost lansată pentru transmisia TV
numerică, dar poate fi folosită şi pentru transferuri de date în general.
Asigură conexiuni punct-la-punct şi punct-la-multipunct la distanţe de până
2-8 km şi viteze de transfer date de la 64 Kbps până la 155 Mbps [16].
74
1.7 Servicii în Internet
Serviciile de bază oferite în Internet sunt enumerate în s. 1.1. Unele din
acestea, ca Acces şi execuţie de sarcini la distanţă, Teletransfer de fişiere, i-
poştă, Web, Teleconversaţie în timp real, Căutare a informaţiilor, Telefonie
IP, Video IP (inclusiv televiziunea IP), i-afaceri, inclusiv i-comerţ, sunt
succint descrise în această secţiune.
Tabelul 1.14. Caracteristicile unor sisteme de telefonie mobilă
Viteza (maximă) de transfer date,
Tehnologia Generaţia Mbps
către staţie de la staţie
GSM CSD 2G (1991) 0,0096 0,0096
GDPD 2G 0,0192 0,0192
GSM GPRS 2,5G 0,056-0,115 0,056-0,115
GSM EDGE 2,75G 0,237 0,237
UMTS W-CDMA 3G (2001) 0,4 0,4
UMTS HSPA 3G 14,4 5,8
UMTS TDD 3G 16 16
CDMA2000 1xRTT 3G 0,3 0,15
CDMA2000 EV-DO 3G 2,5-4,9 0,15-1,8
GSM EDGE-Evolution 3G 1,6 0,5
HSPA+ 4G (2006) 21-672 5,8-168
LTE 4G 100-300 50-75
LTE-Advanced, la mobilitate 4G 100 100
înaltă
LTE-Advanced, la mobilitate 4G 1000 1000
joasă
MBWA (802.20) 4G 80 80
1.7.1. Accesul şi execuţia de sarcini la distanţă

1.7.1.1. Serviciul de acces şi execuţie de sarcini la distanţă
Teleconectarea este, se vede, primul serviciu creat în sistemele de
calcul, în scopul folosirii la distanţă a resurselor unui calculator sau cluster
de calculatoare. El a fost realizat încă în sistemele de teleprelucrare
centralizată a datelor, în rezultatul extinderii facilităţii de conectare locală
a mai multor terminale la un singur calculator sau cluster de calculatoare.
Serviciul de acces şi execuţie de sarcini la distanţă gestionează
conectarea, de la staţia locală a utilizatorului, la un alt calculator din
75
Internet, fie şi la distanţă, şi accesul la resursele acestuia. Pe staţia-gazdă,
la care s-a conectat, utilizatorul poate folosi, dacă are autorizaţia
respectivă, diferite servicii şi resurse, oferite de gazdă staţiilor de lucru,
terminalelor locale, inclusiv pentru execuţia de programe de aplicaţie după
necesitate. Staţia utilizatorului devine un terminal, în caz general, distant,
posibil şi "inteligent" – adică cu facilităţi extinse de procesare a datelor, al
calculatorului gazdă în cauză. În acest mod se pot utiliza, de exemplu,
resursele unui supercalculator de la Cray Research Institute de către un
cercetător, aflat într-o expediţie ştiinţifică pe o navă în Oceanul Indian.
Modalităţile de realizare a acestui serviciu este definită în protocoalele,
în mare parte similare, Telnet, rlogin, rexec, RPC, SHELL şi SSH, descrise în
ss. 3.2.2-3.2-7.
1.7.1.2. Protocolul de terminal de reţea Telnet
Protocolul Telnet (Network Terminal Protocol; RFC 15 (1969), RFC 854,
RFC 2946 ş.a.) defineşte modalitatea de conectare de la o staţie locală la o
staţie gazdă de la distanţă şi de accesare a resurselor acesteia, folosind o
conexiune de terminal virtual.
Ideea de terminal virtual a fost aplicată pentru prima dată în
subreţeaua TELNET din ARPA, pentru a ţine cont de caracteristicile diferite
ale terminalelor utilizate în reţea. Conceptul respectiv se foloseşte pentru a
crea o independenţă relativă a programelor faţă de particularităţile
diferitelor modele de echipamente terminale. Terminalul virtual
reprezintă, în esenţă, o structură de date, ce reflectă în mod abstract
comportarea terminalului. Ea este actualizată prin operaţii-standard ale
programului, pe de o parte, şi prin acţiunile unui modul de corespondenţă
cu terminalul real, pe de altă parte.
Telnet foloseşte portul 23 prin TCP. Structura protocolului este de tip
client-server. Partea client este implementată în programele telnet, tn ş.
a., în funcţie de sistemul de operare, iar partea server – în programul
telnetd (telnet daemon). De exemplu, în UNIX şi Microsoft Windows
acestea sunt programele telnet şi telnetd.
Programul client telnet la lansare, lucru care în UNIX se face aplicând
comanda cu acelaşi nume, efectuează următoarele operaţiuni:
 creează o conexiune TCP cu serverul specificat;
 acceptă intrările din partea utilizatorului într-o manieră convenabilă;
 reformatează datele de intrare într-un format standard anumit şi le
trimite către server;
 acceptă datele trimise de server în formatul standard;
76
 reformatează datele recepţionate şi le afişează utilizatorului.
Pe sistemele UNIX, programele telnetd rulează tot timpul în fundal
(background). Ele sunt în aşteptare şi se activează la solicitarea serviciului
Telnet. La solicitare şi dacă oferirea serviciului se acceptă de server,
telnetd îndeplineşte următoarele acţiuni:
 comunică programelor de reţea disponibilitatea de a realiza
conexiunea;
 aşteaptă o cerere formulată în formatul standard;
 deserveşte cererea;
 trimite rezultatele înapoi către programul client telnet în formatul
standard.
Protocolul Telnet nu prevede cifrarea datelor transmise prin reţea,
inclusiv cele privind parolele, ceea ce face posibilă interceptarea
neautorizată a acestora de la ruterele, comutatoarele, concentratoarele
sau porţile de tranzit şi identificate cu un analizor de pachete. Acesta are şi
alte neajunsuri. De aceea, pentru conexiuni la distanţă securizate, este
propus şi se foloseşte protocolul SSH (vezi s. 1.7.1.7).
1.7.1.3. Protocolul de conectare la distanţă rlogin
Protocolul rlogin (Remote Login Protocol; RFC 1282) defineşte
modalitatea de conectare a terminalului unei gazde locale la o gazdă de la
distanţă. Are o structură de tip client-server, fiind implementat, în UNIX, în
programele rlogin – partea client şi rlogind (rlogin daemon) – partea
server.
Fiecare gazdă îşi poate defini o lista de alte gazde, utilizatorii înregistraţi
ai cărora se pot conecta la ea, fără să li se ceară parola; aceste informaţii
sunt stocate în fişierul /etc/hosts.equiv. Mai mult ca atât, poate fi definită
şi o listă de utilizatori, pentru care se permite executarea de comenzi pe
gazda locală fără a furniza numele de utilizator şi parola. Această
specificaţie se face în fişierul $HOME/.rhosts.
Protocolul rlogin este similar, în mare parte, celui Telnet, cu deosebirea
că nu este la fel de personalizabil și, de asemenea, permite conectarea
doar la staţii UNIX. Totodată, deoarece rlogin este o comandă proprie,
sistemul UNIX lucrează cu ea mai eficient. Pentru studierea facilităţilor şi a
modului de utilizare a comenzii rlogin în UNIX, se poate consulta manualul
electronic al sistemului UNIX, folosind comanda:
$ man rlogin
77
1.7.1.4. Protocolul de execuţie de comenzi la distanţă Rexec
Protocolul de execuţie de comenzi la distanţă (Remote Command
Execution Protocol sau Remote Process Execution) rexec, denumit şi Exec, a
fost pentru prima dată implementat în sistemul de operare 4.2BSD şi
defineşte execuţia la distanţă a comenzilor. Are o structură de tip client-
server. Este implementat în programele rexec – partea client şi rexecd
(rexec daemon) – partea server. Pentru conexiuni la distanţă securizate,
este propus şi se foloseşte protocolul SSH (vezi s. 3.2.7).
1.7.1.5 Protocolul de execuţie de proceduri la distanţă RPC
Protocolul RPC (Remote Procedure Call; RFC 1057, RFC 1831, RFC 5531)
defineşte apelul şi execuţia la calculatoare de la distanţă de proceduri
(subprograme) cu parametri specificaţi. Este un protocol de tip client-
server. Mesajul de apel RPC conţine trei câmpuri, ce servesc pentru
specificarea, în mod univoc, a procedurii apelate – numărul programului de
la distanţă, numărul versiunii programului de la distanţă şi numărul
procedurii de la distanţă, conţinutul cărora specifică în mod univoc
procedura apelată. Programul de la distanţă este acela, care gestionează
apelarea procedurii necesare la staţia de la distanţă.
RPC prevede şi facilităţi de autentificare. Mesajul de apel al procedurii
conţine două câmpuri de autentificare: de acreditare şi de verificare, iar cel
de răspuns conţine un singur câmp – de verificare.
Deoarece RPC este, practic, un protocol de pasare de mesaje, el poate
fi utilizat, în asemenea scopuri, şi cu alte protocoale. De exemplu, el poate
fi folosit pentru transmisia prin TCP a unei secvenţe de mesaje de apel
către un server. Într-un asemenea caz, clientul nu aşteaptă nici un răspuns
de la server la nici un mesaj de apel şi nici serverul nu transmite asemenea
răspunsuri. Totuşi, secvenţa de apeluri ale lotului se încheie de o operaţie
RPC obişnuită respectivă şi confirmarea pozitivă a recepţiei lotului.
1.7.1.6 Protocolul de execuţie de comenzi la distanţă SHELL
Protocolul SHELL (Remote Shell Protocol), denumit şi rsh, este parte a
pachetului Rlogin în sistemul de operare 4.2BSD şi defineşte conectarea şi
execuţia unei singure comenzi pe o gazdă de la distanţă. El are o structură
de tip client-server, fiind implementat în UNIX prin comenzile rsh – partea
client şi rshd (rsh daemon) – partea server. Pentru conexiuni la distanţă
securizate, poate fi folosit protocolul SSH (vezi s. 3.2.7).
78
1.7.1.7 Protocolul de execuţie securizată de comenzi la distanţă SSH
În anii 1990’ încă se practica larg folosirea accesului şi execuţiei de
sarcini la distanţă, în mod nesecurizat. Ulterior, însă, administratorii au fost
nevoiţi să interzică un asemenea acces, din cauza unor pierderi
semnificative. Pentru accesul şi execuţia securizate de sarcini la distanţă, în
1995 a fost propus protocolul SSH (SSH-1), ulterior dezvoltat în SSH-1, iar
apoi SSH-2.
Protocolul SSH (Secure Shell; RFC 4250-RFC 4256, RFC 4335, RFC 4344,
RFC 4345, RFC 4419, RFC 4432, RFC 4716, RFC 5656 ş.a.) este unul
criptografic de securizare a transferurilor de date, a accesului şi execuţiei
de comenzi la distanţă şi a altor servicii de reţea între două staţii; acesta
interconectează, printr-un canal securizat, creat în cadrul unei reţele fie şi
nesigure, aplicaţia client şi aplicaţia server respective. El este un protocol
de tip client-server şi a fost proiectat pentru înlocuirea unor aşa protocoale
nesigure cu funcţii similare ca Telnet, Rsh, Rexec, care transmit
informaţiile, inclusiv parolele, în text clar, fapt ce le face susceptibile la
interceptare și divulgare folosind analiza de pachete.
Pentru autentificarea staţiei distante şi, totodată, pentru ai permite
acesteia autentificarea staţiei utilizatorului, SSH foloseşte criptografia cu
chei publice. Aplicarea acesteia necesită cunoaşterea, referitor la celălalt
respondent, din cei doi ce comunică, doar a cheii lui publice. Se presupune
că cheile publice ale utilizatorilor sunt cunoscute sau pot fi uşor aflate de
toţi doritorii. Totodată, fiecare cheie privată este cunoscută şi folosită doar
de deţinătorul acesteia.
Înainte de a valida tranzacţia solicitată, SSH verifică autenticitatea
deţinătorului cheii publice, adică dacă cheia publică în cauză într-adevăr se
asociază cu entitatea respectivă. În sistemele de operare de tip UNIX, lista
cheilor de autorizare este stocată în dosarul rădăcină al utilizatorului, cu
acces liber de la distanţă, fişierul ~/.ssh/authorized_keys. Acest fişier poate fi
accesat doar prin ssh şi nu poate fi actualizat decât de proprietar şi
administratorul cu drepturi de root.
SSH-2 permite stabilirea de multiple sesiuni shell în cadrul unei singure
conexiuni SSH.
De obicei, SSH este folosit pentru accesul (logarea) securizat al unei
staţii distanţe, dar suportă, de asemenea, tunelarea, înaintarea de porturi
TCP şi conexiuni X11. Versiunile de protocoale SSH File Transfer (SFTP) sau
cea Secure Copy (SCP) definesc, de asemenea, transferul de fişiere.
79
Procesarea nor tot foloseşte tunelarea SSH pentru stabilirea unor
conexiuni client-server securizate, unde aplicaţia server rulează pe un
calculator virtual.
O sesiune SSH include trei faze de bază [7]:
 conectarea la staţia distantă;
 efectuarea operaţiilor necesare de procesare a datelor la staţia
distantă;
 încheierea sesiunii de lucru.
În sistemele UNIX, protocolul SSH este implementat de programul
client ssh şi programul server sshd. Programul client ssh este lansat prin
aplicarea comenzii cu acelaşi nume, care are formatul
$ ssh [-opţiune] [adresă_server|utilizator@adresă_server]
Cele mai utilizate opţiuni ale comenzii ssh sunt:
-l – pentru indicarea utilizatorului cu care se doreşte conectarea la
server;
-p – pentru indicarea portului, la care trebuie de conectat (se foloseşte
în cazul utilizării unui port nestandard pe server).
De exemplu:
$ ssh –l ion cie.ase.md
În cazul, când anterior utilizatorul nu s-a mai conectat la server de pe
calculatorul curent, serverul îi va livra cheia publică pentru a putea începe
mesageria reciprocă. Pentru a accepta, trebuie introdus de la tastatură
cuvântul yes, după care se introduce parola de acces.
1.7.2. Acces, gestiune şi transfer de fişiere la distanţă
1.7.2.1 Serviciul de acces, gestiune şi transfer de fişiere
În reţelele de calculatoare există calculatoare, la care se păstrează
diverse informaţii în formă de fişiere pentru o mare varietate de aplicaţii.
Asemenea calculatoare se numesc servere de fişiere sau depozite de
fişiere. Ele sunt dotate cu capacităţi extinse de memorare, pe care le pun,
la cerere, la dispoziţia celorlalte staţii din reţea.
Pentru accesul, gestiunea şi transferul de fişiere (FTP), la serverele de
fişiere sunt realizate servicii speciale. În gestiunea fişierelor se foloseşte
modelul de fişier virtual. Acesta asigură o interfaţă standardizată cu
utilizatorii, care cuprinde o structură cunoscută, comună întregii reţele, şi
un set standard de operaţii. Corespondenţa cu fişierele originale ale
serverului este realizată de module, aparţinând nivelului aplicaţie, care
80
ascund particularităţile echipamentelor utilizate, creând astfel un sistem
omogen de fişiere.
Serviciul FTP include funcţiile de conectare la distanţă, anumite operaţii
asupra directoarelor şi fişierelor de la serverul de la distanţă şi transferul
de fişiere între serverul local şi cel de la distanţă şi invers.
Exista mai multe mii de servere FTP accesibile prin Internet. Pentru a
accesa un server FTP, trebuie să fie specificat un cont de utilizator. Există şi
servere publice FTP anonime (anonymous), care permit accesul la baze de
date publice, fără a fi nevoie de un cont special. Majoritatea arhivelor
publice oferă acces prin FTP anonim.
Modalitatea de realizare a serviciului este definită în protocoalele FTP
(File Transfer Protocol – Protocolul de transfer de fişiere) şi TFTP (Trivial
FTP – FTP trivial), descrise în ss. 3.3.2 şi 3.3.3.
1.7.2.2 Protocolul de transfer de fişiere FTP
Protocolul FTP este descris iniţial în RFC 114 (1971), iar ulterior
dezvoltat în RFC 765, RFC 959, RFC 2228 pentru IPv4 şi RFC 2428 pentru
IPv6. Transmisia comenzilor şi recepţionarea rezultatului execuţiei acestora
se realizează, folosind o conexiune Telnet. Pentru transferul de date, FTP
foloseşte portul 20 al TCP, iar pentru transferul de comenzi portul 21 al
TCP. Structura protocolului este de tip client-server.
În UNIX, protocolul este implementat de programele ftp (partea client)
şi ftpd (partea server). Pot fi transferate atât fişiere ASCII, cât şi fişiere
binare. Este bine cunoscută aplicaţia client CuteFTP pentru sistemele de
operare Windows și OS X.
Protocolul FTP, securizat cu SSL/TLS (vezi s. 1.4.2), este denumit FTPS,
iar cel securizat cu SSH (vezi s. 1.7.1.7) este denumit SFTP.
1.7.2.3 Protocolul trivial de transfer de fişiere TFTP
Protocolul TFTP (Trivial FTP; RFC 1350) defineşte un subset de funcţii,
din cele definite de FTP, este deci mai simplu, utilizează ca suport de
comunicaţie protocolul UDP şi, respectiv, este mai rapid decât FTP.
Prevede transferul de fişiere numai din directoare publice, nu oferă
mecanisme de protecţie a accesului prin parolă (autentificare). Are o
structură tip client-server, partea client fiind implementată de programul
tftp, iar cea server – de programul tftpd (tftp daemon).
81
1.7.3. iPoşta
1.7.3.1. Serviciul de ipoştă
Poşta electronică este unul din cele mai folosite servicii în reţele.
Serviciul de i-poştă permite transferul mesajelor între utilizatorii reţelei în
mod indirect, folosind “cutiile poştale” electronice. Nu este neapărat
necesar ca adresatul să fie activ (în sistem) în momentul sosirii mesajului.
Fiecărui utilizator îi este deschisă o cutie poştală la calculatorul-gazdă, pe
care acesta are un cont. Cutia poştală este specificată printr-o adresă de i-
poştă, pentru adresarea destinatarului respectiv. În diferite reţele aceste
adrese se pot forma diferit.
Modelul arhitectural de i-poştă include trei categorii de entităţi:
 utilizatorul, care poate fi expeditorul sau destinatarul mesajelor;
 agentul utilizator (AU), cu funcţiile de interfaţă-utilizator (compunere
de mesaje, expediere, recepţie, gestiune de cutii poştale);
 agentul de transfer al mesajelor (AGTM), care, împreună cu alţi
AGTM, formează un sistem de transfer al mesajelor. Acest sistem
asigură transferul de mesaje de la AU sursă la AU destinatar.
Principiul de funcţionare al AGTM este asemănător cu cel al oficiilor
poştale tradiţionale. Un mesaj poate parcurge, până la destinatar, mai
multe AGTM. Fiecare AGTM examinează adresa destinatarului mesajului.
Dacă ea se referă la o cutie poştală (informatică) locală, mesajul este livrat
acesteia, generând eventual o înştiinţare către expeditor. În caz contrar,
mesajul este transmis mai departe.
Poşta electronică are mai multe avantaje faţă de poşta tradiţională. Ea
este mai ieftină, mai rapidă (transferă mesajul în câteva secunde, cel mult
minute), simplifică transmiterea corespondenţei internaţionale, permite
difuzarea de mesaje mai multor adresaţi simultan. Mai mult ca atât, i-poşta
oferă o gamă largă de facilităţi suplimentare, inclusiv:
 facilitarea compunerii mesajelor, cum ar fi includerea în mesajele ce
se perfectează a unor fişiere text existente, de exemplu a semnăturii
expeditorului;
 crearea dosarelor (salvarea în mod organizat a mesajelor pentru o
utilizare ulterioară);
 tipărirea mesajelor, obţinându-se copii pe hârtie;
 reexpedierea automată a mesajelor către alţi utilizatori, conform unei
liste prestabilite;
 transmiterea unui mesaj către mai mulţi destinatari simultan;
82
 folosirea unor nume prescurtate - pseudonime, alături de
echivalentele lor cu adrese de i-poştă obişnuite;
 răspuns (replică – replay) la un mesaj recepţionat;
 transmiterea automată a unor răspunsuri anumite, atunci când
destinatarul lipseşte;
 transmiterea mesajelor cu priorităţi;
 protecţia mesajelor prin cifrare;
 transmiterea fişierelor, inclusiv binare (alternativă la ftp).
Serviciul de i-poştă are şi dezavantaje. Se poate întâmpla ca
destinatarul să nu citească mai mult timp mesajul din cutia poştală. Uneori
un apel telefonic este mai rapid decât i-poşta. Nu întotdeauna se asigură o
securitate înaltă a mesajelor – ele pot fi interceptate de către persoane
neavizate, administratorii de sistem. La necesitate însă poate fi folosită i-
poşta securizată, care asigură confidenţialitatea respectivă.
De menţionat, că serviciul de i-poştă este realizat atât în reţelele de arie
largă, cât şi în reţelele locale. În mare măsură, aplicaţiile de i-poştă
realizează funcţii similare. Însuşirea programelor cu interfeţe grafice este
mai uşoară. De obicei cunoaşterea modalităţilor de folosire a unui sistem
de i-poştă face uşoară însuşirea altuia.
Modalitatea transferului de mesaje în reţea prin serviciul de postă
electronică este specificată de protocoalele de i-poştă. Există mai multe
protocoale de i-poştă, inclusiv (pentru reţele de diferite tehnologii): SMTP
(Simple Mail Transfer Protocol) – pentru transmiterea mesajelor, UNIX
UUCP mail, X.400, MHS, MOTIS, EARN NJE mail, IBMMVS WYLBUR mail,
etc. Pentru extragerea mesajelor de la serverul de i-poştă, în Internet se
folosesc protocoalele standard POP şi IMAP. Cele IMAP, POP, XMPP şi
SMTP sunt descrise în ss. 1.7.3.2-1.7.3.6.
1.7.3.2. Protocolul de accesare a mesajelor Internet IMAP
Protocolul IMAP (Internet Message Access Protocol; RFC 1064, RFC
3501), de rând cu cel POP (Post Office Protocol), este unul din cele mai
folosite protocoale de accesare a i-poştei de pe un server. În acest scop,
protocolul foloseşte portul 143, iar cel IMAP securizat (IMAPS) – portul
993, ambele prin TCP. Majoritatea aplicaţiilor de i-poştă suportă protocolul
SMTP, pentru transmiterea mesajelor, iar cele POP şi IMAP – pentru
extragerea acestora de la serverul de poştă. De exemplu, deşi aplicaţia
client Microsoft Outlook foloseşte un protocol de firmă pentru
comunicarea cu serverul Microsoft Exchange, aceasta suportă, totodată, şi
83
protocoalele standard ale Internet POP, IMAP şi SMTP. Aceasta asigură
compatibilitatea diverselor produse de i-poştă.
Spre deosebire de protocolul POP, cel IMAP permite accesul simultan al
mai multor utilizatori la cutia poştală de pe server, de aceea clienţii IMAP
pot fi conectaţi la cutia poştală o perioadă îndelungată. De asemenea,
clienţii IMAP pot crea, redenumi sau şterge cutii poştale (prezentate de
obicei ca dosare aparte) pe server şi, la necesitate, pot copia mesaje de la o
cutie poştală la alta.
1.7.3.3. Protocolul oficiilor poştale POP
Protocolul POP (Post Office Protocol; POP1 – RFC 918, POP2 – RFC 937,
POP3 – RFC 1081, RFC 2449), de rând cu cel IMAP, este unul din cele mai
folosite protocoale de accesare a ipoştei de pe un server. În acest scop,
protocolul POP2 foloseşte portul 109, cel POP3 – portul 110, iar cel POP3
securizat (POP3S) – portul 995, toate prin TCP. Majoritatea aplicaţiilor de i-
poştă suportă protocolul SMTP pentru transmiterea mesajelor, iar cele
POP şi IMAP – pentru extragerea acestora de la serverul de poştă. Alte
detalii sunt descrise în s. 1.7.3.2.
1.7.3.4. Protocolul de mesagerie extinsă şi prezenţă XMPP
Protocolul XMPP (Extensible Messaging and Presence Protocol; RFC
3920 – RFC 3923, RFC 6120 – RFC 6122) este un protocol pentru
infrastructuri informatice (middleware) bazate pe XML (Extensible Markup
Language), care susţin transmiterea şi recepţia de mesaje (mesageria
instantanee) între sisteme distribuite. Acesta a fost definit într-un standard
deschis (open standard).
Arhitectura de reţea a XMPP este similară celei de i-poştă; oricine
poate să lanseze propriul server XMPP.
1.7.3.5. Protocolul simplu de transfer al ipoştei SMTP
Protocolul SMTP (Simple Mail Transfer Protocol; RFC 821, FRC 5321)
specifică transmisia de i-poştă prin Internet. Foloseşte portul 25 prin TCP.
Protocolul pentru transmisia mesajelor (Mail Submission Agent – MSA),
recepţionate de la agentul de i-poştă al utilizatorului (Mail User Agent –
MUA), este practic acelaşi ca şi SMTP, doar că foloseşte portul 587.
Conexiunile SMTP securizate prin SSL/TLS sunt conexiuni SMTPS.
SMTP este folosit de servere de poştă şi alţi agenţi de transfer de poştă
pentru transmisia şi recepţia mesajelor de poştă, pe când aplicaţiile client
de poştă folosesc SMTP doar pentru transmisia mesajelor către un server
84
de poştă. Pentru recepţia poştei, aplicaţiile client folosesc protocolul POP
sau cel IMAP sau sisteme particulare de firmă, de exemplu, Microsoft
Exchange.
1.7.4. Accesul şi transferul de hipertexte WWW
1.7.4.1. Serviciul Web
Serviciul World Wide Web (Pânză de Păianjen Mondială), numit şi
WWW sau Web, este implementat în 1991 la CERN (Centre European de
Recherche Nucleaire), Elveţia. Este cel mai flexibil şi popular serviciu de
organizare, acces şi transfer de informaţii în Internet.
WWW este bazat pe tehnologia hipertext. Aceasta prevede organizarea
informaţiei în formă de documente – pagini hipertext denumite şi pagini Web;
în fiecare document sunt specificate unul sau mai multe cuvinte cheie. Fiecărui
cuvânt cheie, la rândul său, îi este asociată o legătură către alte documente –
documente înrudite, în care se tratează subiecte referitoare la acest cuvânt.
Asemenea legături se numesc legături hipertext sau hiperlegături. Astfel, într-
un sistem hipertext, documentele înrudite, adică documentele în care se
tratează subiecte comune, sunt conexate prin legături hipertext, asociate unor
cuvinte cheie respective. Ulterior au fost realizate tehnici de încadrare în
paginile Web şi a informaţiilor multimedia: secvenţe audio sau/şi video. De
aceea se vorbeşte, de asemenea, de documente multimedia şi respectiv –
tehnologia hipermedia.
În scopul localizării informaţiilor necesare, este posibilă deplasarea
orientată, prin mulţimea de documente hipertext, urmând schema:
document  cuvânt_cheie  legătură  document  ...
Serviciul WWW are o structură client-server. Programele client WWW
sunt numite şi exploratoare (browsers) pentru accesul şi transferul
hipertextului. Exploratorul WWW suportă atât protocolul hipertextului –
HTTP (Hyper Text Transfer Protocol), cât şi alte protocoale cum ar fi FTP,
NNTP (Network News Transfer Protocol), MAILTO, TELNET, FILE. Astfel,
exploratorul WWW are acces la informaţii, aflate atât la servere WWW, cât
şi la servere FTP, NNTP, Telnet ş.a. Este foarte semnificativ faptul că pentru
toate aceste servere WWW asigură o interfaţă unică şi comodă cu
utilizatorul.
Pentru adresarea unui document hipertext, protocolul HTTP utilizează o
formă standard de adresare a resurselor Internet, denumită URL (Uniform
Resource Locator), cu sintaxa:
schema://gazdă_domeniu[:port]/cale/nume_fişier
85
unde: schema - reprezintă metoda (protocolul) de acces - http, ftp, file,
nntp, mailto sau telnet. Schema file este prevăzută pentru
utilizarea locală a serviciului WWW;
gazdă_domeniu - este adresa Internet a gazdei, ce păstrează
documentul;
port - indică portul de acces utilizat, este argument opţional;
/cale/nume_fişier - este numele absolut al fişierului, ce conţine
documentul.
Când utilizatorul activează (prin clic cu butonul stâng al şoricelului) un
cuvânt cheie într-un document hipertext, programul client WWW
determină URL-ul documentului respectiv, stabileşte conexiunea cu
serverul WWW şi îi transmite cererea de transfer a acestui document,
indicând URL-ul lui. Serverul transmite copia documentului solicitat şi
încheie conexiunea.
Există mai multe exploratoare WWW. Ele pot fi grupate în două categorii:
 exploratoare textuale orientate pe linie de caractere (sunt depăşite),
ce pot rula şi pe calculatoare cu performanţe mai modeste;
 exploratoare grafice.
Primele exploratoare WWW au fost textuale, inclusiv Line Mode
Browser, elaborat la CERN, şi Lynx. Primul explorator Web grafic, Mosaic, a
fost lansat în 1993. Sunt larg cunoscute exploratoarele grafice Chrome,
Mozilla Firefox, Internet Explorer ş.a. Exploratoarele grafice necesită mai
multe resurse, uneori sunt şi mai lente. Însă sunt, de regulă, mai comode.
În multe cazuri cu exploratoarele grafice se poate lucra şi în regim text.
Serviciul Web operează conform protocoalelor HTTP, HTTP Secure
(HTTPS), Secure HTTP (S-HTTP) şi ) şi HTTP/1.1 Upgrade header. Primele
două din acestea sunt descrise, în linii mari, în ss. 1.7.4.2-1.7.4.3.
1.7.4.2. Protocolul de transfer de hipertexte HTTP
Protocolul HTTP (Hipertext Transfer Protocol; RFC 1945 – HTTP V1.0,
RFC 2068 – HTTP V1.1, RFC 2616) defineşte modalitatea de operare a
sistemelor informaţionale hipermedia distribuite pentru schimbul şi
transferul de hipertexte. Structura protocolului este de tip client-server.
Aplicaţia client este http, iar cea server – httpd. Resursele HTTP sunt
identificate şi localizate în reţea în baza URL (vezi s. 1.7.4.1). URL şi
hiperlegăturile în limbajul de marcare a documentelor (Hipertext Markup
Language – HTML) formează ansamble de documente hipertext
interconexate denumite şi Web.
86
1.7.4.3. Protocolul de transfer securizat de hipertexte HTTPS
Pentru conexiuni HTTP securizate, sunt definite trei protocoale: HTTP
Secure (HTTPS, RFC 2818), Secure HTTP (S-HTTP, RFC 2660) şi HTTP/1.1
Upgrade header. Însă ultimele două nu se suportă, de obicei, de
exploratoarele Web. Astfel, predominant în acest scop se foloseşte
protocolul HTTPS.
HTTPS, îmbină protocolul HTTP şi cel de securitate SSL/TLS (Secure
Sockets Layer/Transport Layer Security), adăugând funcţionalităţile SSL/TLS
la cele HTTP. Ideea principală a HTTPS constă în crearea unui canal
securizat în cadrul unei reţele nesecurizate. HTTPS efectuează
autentificarea sitului (serverului) Web şi, de asemenea, cifrarea tuturor
informaţiilor ce se transmit între server şi exploratorul Web, inclusiv a
celor de serviciu (URL, parametrii cererii, anteturile, etc.).
Pentru cifrarea informaţiilor, atât la calculatorul client, cât şi la cel
server se foloseşte câte un „certificat SSL”, denumit şi „certificat numeric”
(digital certificate). Un asemenea certificat conţine cheia publică respectivă
şi informaţii despre autoritatea de certificare a acesteia. Deţinătorul poate
partaja cheia sa publică cu oricine este nevoie. Această cheie este folosită
de ceilalţi utilizatori pentru a cifra mesajele de transmis către deţinătorul
cheii în cauză. La cifrarea mesajelor de transmis se foloseşte şi cheia
privată a sursei, care nu trebuie să devină cunoscută altor utilizatori.
Totodată, la descifrarea mesajelor recepţionate, se foloseşte şi cheia
privată a destinatarului, care de asemenea nu trebuie să devină cunoscută
altor utilizatori. Procedura de schimb de chei publice între respondenţi
folosind certificatele SSL este denumită Infrastructură de chei publice
(Public Key Infrastructure – PKI).
Exploratoarele Web identifică siturile web HTTPS în baza certificatului
numeric al acestuia. În acest scop în cadrul exploratorului Web sunt
preinstalate informaţii despre autorităţile de certificare. Astfel, dacă
certificatul este emis de o autoritate de certificare cunoscută (de exemplu
VeriSign), atunci exploratorul Web consideră că conexiunea cu serverul în
cauză este sigură. Un utilizator poate fi sigur privind o conexiune HTTPS
doar dacă:
1) utilizatorul este sigur că exploratorul web realizează corect
protocolul HTTPS cu datele despre autorităţile de certificare
preinstalate veridice;
2) utilizatorul are încredere în autoritatea de certificare privind
certificatul eliberat sitului Web în cauză;
87
3) situl Web prezintă un certificat valabil, adică unul semnat de către o
autoritate de certificare de încredere;
4) certificatul corect identifică situl Web specificat în adresa URL
respectivă;
5) traseul prin Internet între staţiile comunicante este sigur sau
utilizatorul este sigur în nivelul de cifrare al protocolului (TLS/SSL).
La recepţionarea unui certificat nevalabil, majoritatea exploratoarelor
Web afişează un mesaj de prevenire a utilizatorului. Dacă certificatul este
considerat valabil, majoritatea exploratoarelor Web modifică, în câmpul
adresei, http în https, deseori suplimentar fundalul câmpului pentru
adresă.
1.7.5. Ştiri în reţea
1.7.5.1. Serviciul de ştiri în reţea
Serviciul de ştiri permite citirea şi trimiterea unor mesaje actuale către
utilizatorii reţelei pe domenii de interes. El operează conform protocolului
NNTP, descris succint în s. 1.7.5.2.
1.7.5.2. Protocolul de transfer al ştirilor prin reţea NNTP
Protocolul NNTP (Network News Transfer Protocol; RFC 977, RFC 3977)
specifică regulile de transport al ştirilor între serverele de ştiri şi, de
asemenea, cele de acces şi plasare a articolelor de ştiri de către aplicaţiile
client ale utilizatorilor. Este un protocol de tip client-server, creat pe baza
SMTP şi care foloseşte portul 119 prin TCP, iar în cazul unor conexiuni
securizate prin TLS (NNTPS) – portul 563 prin TCP.
1.7.6. Forumuri şi teleconversaţii în timp real
1.7.6.1. Serviciul de forumuri şi teleconversaţii Internet
Serviciul de forumuri şi teleconversaţii permite discutarea în comun de
două sau mai multe persoane, aflate fie şi la distanţa, a unor chestiuni
stringente. El operează conform protocolului IRC, descris în s. 1.7.6.2.
1.7.6.2. Protocolul de forumuri Internet IRC
Protocolul IRC (Internet Relay Chat; RFC 1459, RFC 2810-RFC2813)
defineşte conversaţiile textuale (chat) în timp real între grupuri de
utilizatori – forumuri de discuţii, denumite canale, permiţând, totodată,
comunicări unu-la-unu prin mesaje particulare şi transferuri de date.
Structura protocolului este de tip client-server, în UNIX fiind implementat
88
de programele irc (partea client) şi ircd (partea server). Un server irc se
poate conecta la alte servere irc, extinzând reţeaua IRC. Topologia
standard pentru o reţea de servere IRC este arbore.
1.7.7. Transferul de date în timp real
Primul document Internet, în care este abordată transmisia de date în
timp real prin Internet este RFC 508 (L.Pfeifer, mai 1973). În acesta sunt
discutate unele aspecte ale transmiterii de secvenţe audio şi video în
cadrul unor conferinţe. Primele asemenea experimente, în condiţii
specifice, au fost efectuate de către MIT (SUA) în 1971, concluzia fiind că
deja la viteze de 10-20 Kbps şi încărcări joase ale ARPANET transmiterea,
cu anumite rezerve, a vocii prin ARPANET, este posibilă. În RFC 508 sunt
descrise mijloacele folosite şi rezultatele transmiterii vocii prin Internet
într-un experiment din 1973, în condiţii mai apropiate de realitate. Este
menţionată stocasticitatea, cu dispersie relativ mare, a duratei intervalelor
între pachetele de date transmise. Această durată poate fi de până la
câteva secunde, ceea ce face practic imposibilă transmiterea calitativă a
vocii.
Ulterior sunt dezvoltate diverse mijloace şi create diferite sisteme de
transfer date în timp real, de calitate necesară, prin reţele cu comutare de
pachete. La serviciile Internet ce ţin de transferul de date în timp real se
referă: transmiterea vocii (VoIP), videoconferinţelor (Video IP), TV IP ş.a.
Unele din acestea sunt descrise în această secţiune.
1.7.7.1. Serviciul VoIP
Transmiterea vocii prin Internet (Voice over Internet Protocol – VoIP),
denumită şi telefonie IP, a devenit posibilă odată cu creşterea vitezelor de
transfer date în reţele şi dezvoltarea unor mijloace adecvate, inclusiv
protocoale şi i-aplicaţii. La protocoalele VoIP se referă: H.323, MGCP, SIP,
H.248, RTP, RTCP, RTSP ş.a. (vezi s. 1.4.2).
Unul din primele protocoale VoIP a fost cel H.323. Totodată, cele MGCP
şi SIP, propuse mai târziu, au funcţionalităţi mai performante.
Primele experimente de transmisie a vocii printr-o reţea cu comutare
de pachete au avut loc în 1971 şi, ulterior, în 1973 (reţeaua ARPANET din
SUA). În 1993 Charles Klein (Universitatea Illinois, SUA) lansează programul
Maven pentru transferul vocii prin reţea folosind calculatorul personal.
Prima lansare a unui produs pentru telefonia IP a avut loc în februarie
1995 în Israel: compania VocalTec Communications a propus pe piaţă
aplicaţia Internet Phone ce rulează pe calculatoare personale. Aceasta însă
89
opera doar în regimul semiduplex (transmisie în ambele direcţii, dar alternat),
ceea ce rezulta cu o calitate joasă a serviciului. Dar deja în septembrie 1995
în Dallas (Texas, SUA) este lansată aplicaţia DigiPhone ce opera în regim
duplex (transmisie concomitentă în ambele direcţii). Mai mult ca atât, în
1996 companiile VocalTec Communications şi Dialogic au lansat prima
poartă (gateway) între o reţea telefonică şi Internet, asigurând
posibilitatea efectuării unor convorbiri între utilizatorii ce deţineau
calculatoare personale sau aparate de telefon ordinare. Poarta asigură
conversiile necesare între Internet şi reţelele telefonice tradiţionale.
Deşi calitatea serviciului VoIP este, deseori, încă inferioară faţă de cea a
telefoniei tradiţionale, extinderea telefoniei IP este recunoscută ca una din
principalele căi de reducere a costurilor pentru convorbirile telefonice şi
treptat ponderea acesteia creşte. Compania Forrester Research estimează că
ponderea telefoniei IP pentru corporaţii va atinge 100 % către 2020.
Din 2001 acest serviciu este oferit şi în R.Moldova.
Scenariile de implementare a telefoniei IP se determină de
echipamentele de terminaţie (staţiile) folosite la utilizatori. Acestea pot fi:
 staţii universale VoIP (SVoIP) – dispozitive ce pot rula o aplicaţie pentru
serviciul VoIP standard, de exemplu un PC, un aparat telefonic IP (T IP)
sau „un aparat telefonic ordinar + un adaptor VoIP universal” (T AU);
 staţii specializate VoIP – staţii ce constau dintr-un aparat telefonic
ordinar + un adaptor specializat, care rulează o aplicaţie pentru
serviciul VoIP specializat (TA);
 aparate de telefon ordinare (T).
În cazul staţiilor SVoIP şi T, pentru adresarea interlocutorilor se folosesc
adrese IP şi numerele de telefon ordinare, stabilite în mod obişnuit în
Internet, şi reţeaua telefonică publică (RTP) respectivă. Totodată, în cazul
staţiilor de tip T, procedura de formare a numărului este precedată de
culegerea unor simboluri suplimentare (numărul de acces) pentru
diferenţierea serviciului VoIP de cel de telefonie tradiţională. Fiind
conforme standardelor internaţionale, staţiile de acest tip sunt compatibile
între ele în ce priveşte oferirea serviciului VoIP.
Staţiile de tip TA au funcţii reduse, neasigurând compatibilitatea cu
staţiile de tip SVoIP şi T, dar sunt mai ieftine.
Astfel, la moment se folosesc cinci modalităţi (scenarii) de transmisie a
vocii prin Internet (fig. 1.12):
1) staţie VoIP – staţie VoIP (SVoIP  SVoIP);
2) telefon – telefon (T  T);
3) staţie VoIP  telefon (SVoIP  T);
90
4) telefon  staţie VoIP (T  SVoIP);
5) telefon cu adaptor – telefon cu adaptor (TA-TA).
Staţie T Staţie T
RT Poartă Poartă
RT
P RTP RTP P
Poartă Poartă
FSTI FSTI
Reţea de acces
Reţea de acces
Ruter Internet Ruter

FSI FSI
Staţie VoIP Staţie VoIP
Poartă Poartă
FSI FSI
RT RT
P P
Ad.VoI Ad.VoI
P P
Staţie TA Staţie TA
1 – scenariul „SVoIP  SVoIP”; 4 – scenariul „T  SVoIP”;

2 – scenariul „T  T”; 5 – scenariul „TA-TA”.
3 – scenariul „SVoIP  T”;
Fig. 1.12. Alternative de realizare a telefoniei IP.
Pentru convorbiri prin Internet, utilizatorul poate folosi: a) un aparat

telefonic ordinar (T) – cazurile (2) şi (4); b) un aparat telefonic ordinar + un
adaptor VoIP specializat (TA) – cazul (5); c) o staţie universală VoIP (un
91
calculator personal sau un aparat de telefon IP sau „un aparat telefonic
ordinar + un adaptor VoIP universal”) – cazurile (1) şi (3).
Din punctul de vedere al necesităţii implicării unor operatori speciali de
servicii VoIP, cele cinci modalităţi pentru telefonie IP pot fi grupate în două
categorii:
1) modalităţile ce necesită implicarea unor terţi operatori – operatori
speciali de IP telefonie care, prin intermediul unei porţi-server
telefonic, realizează parţial (într-o singură direcţie – modalităţile „T
 SVoIP” şi „SVoIP  T”) sau complet (în ambele direcţii – modalitatea
„T  T”) interacţiunea „RPT – Internet” pentru VoIP;
2) modalităţile ce nu necesită implicarea unor terţi operatori, nu
necesită folosirea unor porţi intermediatoare „Internet-RTP”: „SVoIP
 SVoIP” şi „TA  TA”, acestea fiind transparente pentru operatorii
RTP.
Una din problemele majore ale telefoniei IP, în special în primii ani de la
lansarea pe piaţă, consta în incompatibilitatea produselor oferite de către
diferite firme: aplicaţii şi adaptoare VoIP. În acest scop ulterior au fost
propuse standarde internaţionale pentru telefonia IP: H.323 elaborat de
către ITU (Uniunea Internaţională de Telecomunicaţii) şi aprobat în 1996;
SIP (Session Initiation Protocol) elaborat de către Comitetul IETF şi aprobat
în 1999. Folosirea echipamentelor şi a produselor program pentru
telefonia IP conforme cu standardele H.323 şi SIP permite compatibilitatea
acestora, oferind posibilitatea de a transmite voce, video şi facsimile între
interlocutorii ce posedă telefon ordinar, aparat de telefon cu adaptor VoIP
standard, calculator personal sau telefon IP.
De rând cu reducerea costurilor, există şi multe alte avantaje ale VoIP,
îndeosebi cele ce ţin de crearea unor noi aplicaţii aferente, inclusiv:
 folosirea unei singure platforme de mesagerie pentru toate tipurile
de comunicări. În loc ca mesajele de i-poştă să fie recepţionate în
aplicaţia respectivă din PC, mesajele vocale – la telefon, faxurile – la
aparatul de fax, iar paging-urile – la pager, serviciul de VoIP poate
gestiona toate aceste mesaje împreună;
 folosirea uneia şi aceleiaşi linii de abonat atât pentru acces Internet,
cât şi pentru teleconvorbiri;
 extinderea capacităţilor de telelucru, inclusiv la domiciliu;
 redirectarea automată a informaţiilor în funcţie de locul de aflare a
adresatului ş.a.
92
Dintre dezavantajele telefoniei IP principalele sunt: calitatea mai joasă,
uneori, comparativ cu telefonia tradiţională şi incompatibilitatea unor
produse. Problema incompatibilităţii unor produse se poate considera,
practic, rezolvată. În ce priveşte calitatea, din punctul de vedere al
întârzierilor transmisiei, în Recomandaţia G114 a ITU-T sunt definite patru
clase (nivele) de calitate pentru convorbirile telefonice:
1) calitate foarte bună (clasa 1) – la întârzieri ce nu depăşesc 0,15 s;
2) calitate bună (clasa 2) – la întârzieri în intervalul 0,15-0,3 s, calitate
considerată încă acceptabilă pentru convorbirile de afaceri;
3) calitate suficientă (clasa 3) – la întârzieri în intervalul 0,3-0,7 s,
calitate considerată acceptabilă pentru convorbiri nu de afaceri;
4) clasa 4 – la întârzieri peste 0,7 s, calitate suficientă doar pentru
convorbiri în regim semiduplex pentru utilizatori experimentaţi (de
exemplu, în sisteme militare).
Calitate conformă clasei 1 estre stabilită pentru reţelele telefonice
tradiţionale. Internet-ul introduce o reţinere a pachetelor de la 0,05 s până
la 0,5 s, în funcţie de starea reţelei. La transmisia convorbirilor telefonice,
Internet asigură calitate de nivelele 2-3, iar furnizorii de telefonie IP, ce
operează folosind canale de comunicaţie dedicate, pot asigura calitate de
nivelele 1-2.
Esenţa unor protocoale pentru VoIP este descrisă în s. 1.7.7.4-1.7.7.7.
1.7.7.2. Serviciul de videoconferinţe
Serviciul de videoconferinţe, denumit şi serviciu de colaborare vizuală
la distanţă, permite desfăşurarea de conferinţe cu participarea de
persoane aflate în două sau mai multe localităţi, folosind transmisiuni
audio şi video. Acesta diferă de telefonia video, prin aceea că la
videoconferinţe participă mai mult de două persoane. Respectiv diferă şi
mijloacele folosite în acest scop.
Prima reţea de telefonie video a fost lansată în 1936 în Germania.
Încercările de videoconferinţe, realizate de AT&T în anii 1950’, au fost
nereuşite, iar lansarea sistemului Picturephone în SUA în anii 1970’ nu a
avut succes din cauza costurilor înalte. Primul sistem reuşit de
videoconferinţe a fost lansat în 1984 în SUA. A facilitat implementarea
unor asemenea sisteme crearea de reţele ISDN, care permiteau viteze
transfer date de cel puţin 128 Kbps prin comutarea de canale. În sfârşit, au
fost dezvoltate tehnologii mai avansate de compresie a datelor şi mijloace
pentru videoconferinţe prin Internet. În 1992 este lansat programul CU-
SeeMe de videoconferinţe pentru calculatoare Macintosh (Universitatea
93
Cornell, SUA), iar în 1995 a avut loc prima videoconferinţă publică între
America de Nord (San Francisco) şi Africa (Cape Town). Ulterior,
videoconferinţele se bucură de o popularitate din ce în ce mai mare.
În domeniu, ITU a aprobat trei standarde:
 ITU H.320 – pentru reţele standard de telefonie publică prin comutare
de canale (Public Switched Telephone Networks – PSTN) sau ISDN;
 ITU H.264 Scalable Video Coding (SVC) – pentru compresia
informaţiilor video;
 ITU V.80 – pentru compatibilizarea videoconferinţelor cu standardul
H.324 pentru videotelefonie punct-la-punct prin linii telefonice
analogice.
Tehnologia de bază folosită pentru videoconferinţe este compresia
numerică (coder/decoder – codec) în timp real a fluxurilor de informaţie
audio şi video. Sunt atinse rate de compresie de până la 1:500.
Pe lângă codecuri, un sistem pentru videoconferinţe include: cameră
video – pentru intrarea de informaţii video; monitor, TV sau proiector –
pentru redarea de informaţii video; microfon sau casetofon – pentru
intrarea de informaţii audio; difuzoare, etc. – pentru redarea de informaţii
audio; mijloace de transfer date; calculator.
Disting două sisteme de videoconferinţe de bază: dedicate sau desktop.
Sistemele dedicate conţin toate componentele necesare în cadrul unui
echipament integrat şi o video cameră. Sistemele desktop sunt constituite
din mai multe componente interconectate, inclusiv PC.
Serviciul de videoconferinţe, îndeosebi cel IP, a extins considerabil
posibilităţile de comunicare umană, având un impact benefic considerabil
în societate, inclusiv în instruire, medicină, afaceri, mass-media ş.a.
1.7.7.3. Serviciul TV IP
De rând cu tehnologiile pentru VoIP şi videoconferinţe via Internet, în
1995 este lansată o i-aplicaţie pentru transferul, prin Internet, de trafic
video de înaltă calitate, folosind protocoalele monoadresat şi multiadresat
RTP şi RTCP. Ulterior, serviciul TV IP, inclusiv video la cerere (Video-on-
Demand – VoD), a cunoscut o implementare largă în diverse ţări, îndeosebi
în Europa şi America de Nord, atingând în 2013 cca. 83 mln abonaţi.
Un sistem TV IP include:
 staţia-sursă TV, în cadrul căreia canalele TV în direct sunt codificate,
cifrate şi livrate în formă de fluxuri IP multiadresat;
 platforma VoD, în cadrul căreia produsele video la cerere sunt stocate
şi livrate la cererea utilizatorului;
94
 portalul interactiv, pentru posibilitatea de navigare de către utilizator
a diverselor servicii TV IP (catalogul VoD);
 reţeaua de livrare – reţea cu comutare de pachete care transportă
pachetele IP (monoadresat şi multiadresat);
 poarta (gateway) de la domiciliu – echipamentul de la domiciliul
utilizatorului care încheie legătura de acces de reţeaua de livrare;
 decoderul utilizatorului – echipament instalat la domiciliu pentru
decodificarea şi descifrarea informaţiei TV şi VoD şi redarea acesteia
către aparatul TV.
Arhitectura serverului video poate fi una centralizată sau distribuită.
Cea centralizată convine, de obicei, unor servicii VoD relativ mici.
Compresia video se efectuează conform standardului H.263 sau al celui
H.264 cu compresie audio MDCT (Modified Discrete Cosine Transform),
datele fiind ulterior încapsulate în fluxuri de transport MPEG sau pachete
RTP.
Principalele protocoale folosite pentru serviciul TV IP sunt:
1. Transmisiuni ale furnizorului de servicii:
 IGMP – pentru abonarea la un flux multiadresat în direct (canal TV) şi,
de asemenea, pentru trecerea de la un flux multiadresat în direct la
altul (Schimbarea canalului TV);
 PIM (Protocol Independent Multicast) – pentru rutarea IP
multiadresat cu setarea distribuirii fluxurilor multiadresat (canalelor
TV) pe calea sursă-destinaţie cu duplicarea pachetelor recepţionate,
la necesitate. Conţinutul la cerere foloseşte o conexiune monoadresat
negociată;
 RTP peste UDP sau H.222 peste TCP – pentru încapsularea datelor.
2. Transmisiuni în direct şi VoD doar monoadresat bazate pe Web:
 Adobe Flash Player preferă RTMP peste TCP cu setare şi control via
tranzacţii în format AMF (Action Message Format), XML (Extensible
Markup Language) sau JSON (JavaScript Object Notation);
 Apple iOS foloseşte transmisii adaptabile la rata de biţi HLS (HTTP Live
Streaming) peste HTTP cu setare şi control via un fişier MP3
încorporat;
 Microsoft Silverlight foloseşte transmisii adaptabile la rata de biţi
peste HTTP
3. Transmisiuni în direct şi VoD doar multiadresat bazate pe Web:
 RTP peste UDP sau TCP cu setare şi control folosind RTSP peste TCP.
95
4. Aparatele TV, console pentru jocuri, codecuri la utilizator,
înregistratoare video personale de reţea (Network Personal Video
Recorder – NPVR):
 UPnP AV (Universal Plug and Play Audio and Video) pentru
monoadresat via HTTP peste TCP sau multiadresat în direct RTP peste
UDP;
 Conţinutul Web este prezentat prin plugin-uri Web sau o i-aplicaţie
specială ce foloseşte MPEG-5.
La avantajele TV IP se referă posibilitatea integrării diverselor servicii IP,
funcţionalităţi mai performante, un conţinut mai larg cu posibilităţi
comode de selectare a informaţiilor, interactivitate, video la cerere ş.a.
(triple play)
1.7.7.4. Protocoalele de transfer date în timp real RTP şi RTCP
Protocolul RTP (Real-time Transport Protocol; RFC 1889, RFC 3550) este
destinat transferului de fluxuri de date punct-la-punct sau punct-la-
multipunct în timp real, definind în acest scop şi formatul standard al
pachetelor pentru audio şi video IP. Este folosit împreună cu protocolul
RTCP (RTP Control Protocol; RFC 1889, RFC 3550), ultimul specificând
monitorizarea transmisiei şi calitatea serviciului (Quality of Service – QoS)
şi, de asemenea, sincronizarea multiplelor fluxuri de date. Portul RTP
trebuie să fie par, iar cel RTCP – următorul port impar. Ele folosesc, de
obicei, porturi UDP neprivilegiate (1024 – 65535).
1.7.7.5. Protocolul de gestiune a sesiunilor în timp real RTSP
Protocolul RTSP (Real Time Streaming Protocol, RFC 2326) este destinat
pentru stabilirea şi gestiunea sesiunilor multimedia între staţii, pe când
funcţiile de transmisie şi gestiune a fluxurilor de date înseşi revin
protocoalelor RTP şi RTCP. El foloseşte portul 554 prin TCP.
1.7.7.6. Protocoalele de iniţiere a sesiunii SIP şi SIPS
Protocolul SIP (Session Initiation Protocol; RFC 2543, RFC 3261) este
unul de semnalizare, folosit la stabilirea, controlul, modificarea şi
desfiinţarea de sesiuni de comunicare monoadresat (unicast) sau
multiadresat (multicast) pentru apeluri de voce sau video IP. O sesiune
poate consta din unul sau mai multe fluxuri media. La nivelul transport
(portul 5060 – sesiuni nesecurizate, portul 5061 – sesiuni securizate),
acesta poate folosi protocoalele TCP, UDP sau SCTP (Stream Control
Transmission Protocol). Pentru sesiuni securizate cu TLS se foloseşte SIPS.
96
1.7.7.7. Protocolul de gestiune a porţilor multimedia MGCP
Protocolul MGCP (Media Gateway Control Protocol; RFC 2805, RFC
3435) specifică regulile de gestiune a porţilor multimedia între reţelele IP şi
cele telefonice publice cu comutare de canale, pentru asigurarea
interoperabilităţii acestora la prestarea de servicii VoIP. Este succesorul
protocolului SGCP (Simple Gateway Control Protocol), propus anterior de
companiile Cisco şi Bellcore. Este un protocol de tip master-slave care
asigură conversia semnalelor de voce cu multiplexare în timp (TDM) în
voce prin IP şi invers. Pentru pachetele MGCP, este folosit portul 2427 prin
UDP.
1.7.8. Serviciul SNMP
Serviciul SNMP se realizează conform Protocolului simplu de gestiune a
reţelei (Simple Network Management Protocol – SNMP, RFC 1065-RFC
1067, RFC 1155-RFC 1157, RFC1213, RFC 1441-RFC 1452, RFC 3411-
RFC3418 ş.a.). SNMP este un protocol standard Internet, care specifică
aspectele gestiunii dispozitivelor reţelelor IP, în scopul valorificării eficiente
a resurselor acestora. El prevede administrarea folosirii resurselor reţelei
printr-o colecţie de staţii de administrare a reţelei şi anumite elemente de
reţea, cum ar fi gazdele, porţile, serverele, comutatoarele, imprimantele
ş.a. Staţiile de administrare a reţelei monitorizează elementele respective
de reţea. Aceste elemente ale reţelei conţin, în acest scop, agenţi de
administrare. O dezvoltare a SNMP este SNMPv2 (RFC 1441-RFC 1452).
SNMP poate fi aplicat în utilite concrete pentru configurarea, dar şi
pentru colectarea, stocarea şi reprezentarea, inclusiv grafică, a diverşilor
parametri de funcţionare a dispozitivelor de reţea. La utilite cu asemenea
funcţii se referă: CACTI, MRTG, Dude ş.a. Datele colectate se stochează în
Baza informaţiilor de gestiune (Management Information Base – MIB).
Suportă SNMP, de obicei, aşa dispozitive de reţea ca: ruterele,
comutatoarele, calculatoarele, imprimantele ş.a.
O reţea gestionată conform SNMP include trei categorii de
componente: (1) dispozitivele de gestionat; (2) agenţii de administrare; (3)
sistemul de gestiune a reţelei (Network Management System – NMS).
Fiecare dispozitiv de gestionat, denumit şi element de reţea,
implementează o interfaţă SNMP pentru accesul monodirecţional (doar
pentru citire) sau bidirecţional (pentru citire şi scriere) a NMS la
informaţiile specifice dispozitivului. La asemenea elemente se pot referi:
rutere, comutatoare, concentratoare, calculatoare, imprimante, telefoane
IP, camere video IP ş.a.
97
Agentul de administrare reprezintă o utilită ce operează în cadrul unui
dispozitiv gestionat. Acesta determină, utilizează şi comunică NMS
informaţia locală de gestiune, constituită din valori ale unor variabile.
Pentru accesare, informaţia în cauză se organizează în formă ierarhică,
constituind, împreună cu alte metadate, Baza informaţiilor de gestiune
(Management Information Base – MIB). Folosind informaţiile MIB, NMS
execută aplicaţii de monitorizare şi control al dispozitivelor gestionate.
Într-o reţea pot opera una sau mai multe NMS şi, respectiv, MIB.
SNMP înseşi nu defineşte ce anume informaţii (variabile) trebuie să fie
în MIB. Totodată, acesta prevede posibilitatea creării unor aplicaţii, în care
să fie posibil de descris variabilele necesare. MIB descrie structura datelor
de gestiune pentru dispozitive, folosind un spaţiu ierarhic de nume ce
conţin identificatori de obiecte (Object Identifier – OID). Fiecare OID
identifică o variabilă aparte. În MIB se folosesc notările definite de
Structura informaţiilor de gestiune (Structure of Management Information
– SNMP), conform RFC 2578.
SNMP operează la nivelul Aplicaţie al modelului de reţea TCP/IP. NMS
trimite cereri către agenţii de administrare la portul 161 al UDP. Agentul
răspunde NMS la portul sursă a cererii respective. De asemenea, NMS
recepţionează notificări, generate de agenţi, la portul 162 al UDP.
1.7.9. Securizarea accesului şi a transferului de date
1.7.9.1. Esenţa securizării informaţionale în reţele
Din cauza numărului mare de utilizatori şi a facilităţilor puternice de
acces la servicii, datele pot fi mai vulnerabile în reţelele de calculatoare,
decât oriunde în altă parte. Cu cât aplicaţiile au o arie mai largă de
utilizare, cu atât este mai acută necesitatea unor măsuri speciale pentru
securizarea datelor.
Mesajele importante trebuie protejate pentru a nu fi dezvăluite unor
persoane neautorizate, împotriva modificărilor frauduloase, ştergerii,
inserării de mesaje noi, repetării mesajelor vechi, mascării unui utilizator
dându-se drept un alt utilizator sau mascării unui serviciu dându-se drept
un alt serviciu, etc.
În multe ţări legislaţia cere asigurarea unui grad anumit de securitate
pentru informaţiile care circulă prin reţele. Folosirea metodelor de
securitate fizică nu este, practic, raţională în sisteme aşa de întinse cum
sunt reţelele de comunicaţii folosite pentru transferul datelor – costurile
necesare sunt foarte înalte. De aceea au fost elaborate diverse metode de
securitate logică a datelor.
98
Sunt cunoscute asemenea măsuri de securizare a informaţiilor în reţele,
ca: formarea de reţele virtuale, instalarea şi configurarea de i-bariere
(firewall), utilizarea de sisteme criptografice; separarea centrelor şi a
reţelelor informatice în fragmente cu funcţii specializate ş.a. La cerinţe
înalte de securitate, mijloacele de securizare folosite la staţii se pot îmbina
cu cele folosite la nodurile de comunicaţie ale reţelelor.
Domeniul de activitate cu elaborarea şi spargerea cifrurilor se numeşte
criptologie, cel ce ţine de elaborarea cifrurilor – criptografie, iar cel cu
spargerea cifrurilor – criptanaliza. Modelul de bază al folosirii cifrurilor
pentru securizarea informaţiilor este prezentat în fig. 1.13.
Cheia de cifrare e Cheia de descifrare d
Text clar Text clar

Cifrare Cifrogramă Descifrare
Intrus
Fig. 1.13. Modelul de bază al folosirii cifrurilor.

Mesajul ce trebuie cifrat, numit şi text clar, este supus unei
transformări (cifrare) parametrizate de cheia de cifrare e, obţinându-se un
text cifrat, numit şi criptogramă sau cifrogramă, mai rar codogramă. Textul
cifrat este transmis prin mediul de comunicaţie către destinatar.
Destinatarul, pentru a obţine textul clar, efectuează transformarea inversă
a cifrogramei, folosind o cheie de descifrare d.
În timpul transmisiei, un intrus (străin) poate intercepta cifrograma din
mediul de comunicaţie. Dacă intrusul cunoaşte sau reuşeşte să determine
cheia d, atunci el poate obţine (prin descifrare) textul clar şi, ulterior,
beneficia de informaţiile respective în folosul propriu. Mai mult ca atât,
dacă intrusul reuşeşte să determine şi cheia de cifrare e, atunci el poate
cifra şi transmite propriile mesaje.
Problema de criptanaliză (de spargere a cifrurilor) are 3 variante de
complexitate, variante ce se deosebesc prin informaţiile pe care le deţine
criptanalistul (specialistul ce se ocupă cu spargerea cifrurilor):
99
 criptanaliză cu text cifrat cunoscut, în care se cunoaşte doar un text
cifrat;
 criptanaliză cu text clar cunoscut, în care se cunosc atât textul cifrat,
cât şi cel clar;
 criptanaliză cu text clar ales, în care se cunoaşte modul de cifrare al
anumitor porţiuni de text alese de criptanalist. Aceasta este cea mai
convenabilă pentru criptanalist variantă.
Două probleme majore ale securizării informaţiilor sunt protecţia şi
autentificarea. Protecţia (confidenţialitatea) cere ca intrusul să nu poată
reconstitui textul clar dintr-unul cifrat interceptat, deci ca acesta să nu
poată determina cheia de descifrare d. Autentificarea cere ca intrusul să nu
poată cifra şi transmite propriile mesaje fără ca acest lucră să fie detectat,
deci ca acesta să nu poată determina cheia de cifrare e. Astfel, pentru
asigurarea securităţii informaţiilor, folosind sisteme de tipul celor din fig.
3.1, denumite şi sisteme criptografice simetrice (cheile e şi d coincid sau
este relativ uşor de dedus o cheie din cealaltă pereche) este necesară
ţinerea în secret a ambelor chei e şi d.
Pentru cifrarea informaţiilor sunt propuşi aşa algoritmi simetrici ca:
DES, AES ş.a.
Pentru asigurarea securităţii informaţiilor, folosind sisteme de tipul
celor din fig. 3.1, este necesară ţinerea în secret a ambelor chei e şi d. Însă
distribuţia cheilor între respondenţi a fost şi este punctul vulnerabil al
multor criptosisteme (sisteme criptografice). Aceste probleme se
soluţionează în cadrul sistemului criptografic cu chei publice, descris de
Whitfield Diffie şi Martin Hellman într-o publicaţie din 1976. Ulterior a
devenit cunoscut că sistemul cu chei publice a fost propus în 1969 în cadrul
Serviciul Secret al Marii Britanii, dar nu a fost publicat, fiind considerat
secret militar [21].
Sistemul propus prevede folosirea unui sistem criptografic asimetric. La
sistemele criptografice asimetrice cheia de descifrare este diferită de cea
de cifrare şi nu poate fi, practic, dedusă din aceasta. Pentru ca un sistem
criptografic asimetric să asigure atât protecţia cât şi autenticitatea
informaţiei, se cere ca algoritmul de cifrare E şi cel de descifrare D să
satisfacă trei cerinţe:
1) D(E(M)) = E(D(M)) = M. Aici M este textul clar, care trebuie cifrat şi
transmis;
2) este mai mult decât dificil a se deduce D din E;
3) E nu poate fi spart prin criptanaliză cu text clar ales.
100
În sistemul în cauză, numit sistem criptografic cu chei publice, se
presupune că cheia de cifrare se face cunoscută tuturor – cheie publică, pe
când cheia de descifrare se ţine în secret – cheie privată. Modelul
funcţionării sistemului este prezentat în fig. 1.14.
În acest sistem fiecare utilizator U, care doreşte să primească mesaje
confidenţiale, face publică cheia sa de cifrare EU şi păstrează în secret cheia
sa de descifrare DU. Pentru a transmite un mesaj confidenţial M
Utilizatorul A
M DA(M EB(DA( C
) M))
Reţea
C DB(C) EA(DB(C M
))
Utilizatorul B
Fig. 1.14. Modelul sistemului criptografic cu chei publice.

utilizatorului B, utilizatorul A transformă mesajul M folosind cheia sa
secretă DA (aplicând astfel “semnătura electronică” asupra mesajului), apoi
îl transformă din nou folosind cheia publică EB a utilizatorului B. Textul
cifrat (cifrograma) C astfel obţinut este transmis utilizatorului B prin mediul
de comunicaţie. Utilizatorul B mai întâi transformă cifrograma C, folosind
cheia proprie de descifrare DB, apoi textul obţinut îl transformă din nou,
folosind cheia publică EA a utilizatorului A. Rezultatul este textul clar M.
De menţionat că textul cifrat C poate fi transformat în text clar M doar
cunoscând cheia secretă DB (pereche cu cheia EB folosită la cifrarea
mesajului M). Deci nici chiar autorul A al mesajului M nu poate descifra
cifrograma C. De asemenea, utilizatorul B este sigur că anume utilizatorul A
este sursa mesajului M, deoarece doar acesta posedă cheia secretă DA
(pereche cu cheia EA), folosită la transformarea (aplicarea „semnăturii
electronice”) mesajului M.
Pentru realizarea în practică a unui sistem criptografic cu chei publice,
se cere elaborarea unor algoritmi, care ar satisface cele trei cerinţe
101
enumerate mai sus. Sunt propuşi mai mulţi asemenea algoritmi, o mare
parte din care au la bază folosirea unor funcţii greu inversabile.
O funcţie y = f(x) este greu inversabilă, dacă cunoscând valoarea
argumentului x este relativ uşor de calculat valoarea funcţiei y; dar acest
lucru nu se poate afirma despre operaţia inversă – cunoscând valoarea
funcţiei y este foarte dificil de calculat valoarea argumentului x = f -1(y). Ca
funcţii greu inversabile pot servi: funcţia exponenţială discretă, logaritmii
discreţi, problema rucsacului ş.a.
Sunt bine cunoscuţi asemenea algoritmi pentru sistemele criptografice
cu chei publice ca:
 algoritmul RSA propus de Ron Rivest, Adi Shamir şi Leonard
Adleman în 1978. Securitatea acestuia se bazează pe dificultatea
factorizării numerelor mari;
 algoritmul propus de Ralph Merkle în 1978. Securitatea acestuia se
bazează pe dificultatea determinării conţinutului unui rucsac
cunoscând greutatea (volumul) lui;
 algoritmul propus de Taher Elgamal în 1985 şi cel propus de Schnorr
în 1991 se bazează pe dificultatea calculului logaritmilor discreţi;
 algoritmul bazat pe curbe eliptice propus de Alfred J. Menezes şi
Scott A. Vanstone în 1993;
 algoritmul DSA (Digital Signature Algorithm) propus de David
Kravitz.
Pentru securizarea informaţiilor în Internet se foloseşte crearea de i-
bariere (vezi cap. 5), tunelarea (vezi cap. 11), dar şi aşa protocoale ca: SSH,
SSL, TLS, SOCKS, IPsec ş.a. Protocolul SSH, de acces şi execuţie securizată
de comenzi la distanţă, este descris în s. 1.7.1.7, iar cel IPsec, de securizare
a comunicărilor IP (pentru orice aplicaţie), – în s. 11.1.10. În ss. 1.7.9.2-
1.7.9.4 sunt descrise protocoalele SSL, TLS şi SOCKS.
1.7.9.2. Protocolul de securizare a conexiunilor SSL
Protocolul SSL (Secure Socket Layer) este lansat de compania Netscape
Communications în 1995, pentru securizarea comunicării prin Internet.
Ulterior, acesta a fost înlocuit cu cel TLS (vezi mai jos în această secţiune).
1.7.9.3. Protocolul de securizare a conexiunilor TLS
Protocolul TLS (Transport Layer Security; RFC 2246, RFC 4346, RFC
5246) – o îmbunătăţire a protocolului SSL, este unul criptografic de
securizare a comunicării prin Internet. Acesta, ca şi SSL, cifrează
102
segmentele de conexiuni de rețea la nivelul Aplicaţie pentru nivelul
Transport, folosind criptografia cu chei publice pentru schimbul de chei,
cifrarea simetrică pentru asigurarea confidenţialităţii şi coduri de
autentificare a mesajelor (message autentification code) – pentru
integritatea mesajelor.
Codul de autentificare a mesajelor (CAM) este un mic fragment de
informații, folosit pentru autentificarea unui mesaj, oferind garanții de
integritate și autenticitate a acestuia. Asigurarea integrităţii se bazează pe
detectarea schimbărilor accidentale sau intenționate ale mesajului, pe
când asigurarea autenticităţii se bazează pe detectarea originii mesajului.
CAM diferă de semnătura numerică prin aceea că ambele valori ale MAC
sunt generate şi verificate, folosind aceeaşi cheie secretă (criptografie
simetrică). Algoritmii CAM au la bază funcţii criptografice de haşare
(dispersie), de exemplu cel HMAC, sau folosesc algoritmi de cifrare bloc, ca
cei OMAC, CBC-MAC şi PMAC. Totuşi, cei mai rapizi algoritmi CAM sunt
UMAC şi VMAC, bazaţi pe haşarea universală.
Protocolul TLS permite comunicarea aplicaţiilor client-server prin
Internet, combătând interceptarea clară de părţi terţe a conţinutului
acesteia şi detectând accesul neautorizat la informaţiile respective.
Pentru implicarea TLS, este necesar de specificat serverului, dacă
aplicaţia client iniţiază stabilirea unei conexiuni TLS sau non-TLS. Acest
lucru poate fi efectuat în două moduri: 1) pentru conexiunile TLS se
foloseşte un port (de exemplu portul 443 pentru HTTPS), diferit de cel
pentru conexiunile non-TLS; 2) se foloseşte portul ordinar, dar aplicaţia
client va genera o cerere către server ca acesta să stabilească o conexiune
TLS.
TLS este, de obicei, implementat de asupra oricărui protocol de nivel
Transport, începând cu TCP şi continuând cu cele orientate datagramă:
UDP şi DCCP. Astfel, el se foloseşte cu protocoalele de nivel Aplicaţie HTTP,
FTP, SMTP, NNTP şi XMPP şi, de asemenea, cu cel SIP. El poate fi folosit şi
pentru crearea de VPN ca în cazul OpenVPN. În ce priveşte crearea de VPN,
TLS are anumite avantaje faţă de tehnologia IPsec, inclusiv în ce priveşte
traversarea protectoarelor (firewalls) şi a translatoarelor de adrese de
reţea (Network Address Translation – NAT).
1.7.9.4. Protocolul de securizare socluri SOCKS
Protocolul SOCKS (SOCKet Secure; RFC 1928, RFC 1929) este unul de tip
client-server şi defineşte transmiterea pachetelor între două staţii ale
reţelei prin intermediul unui server proxy de nivel circuit (nivel sesiune OSI
103
ISO) – proxy SOCKS. Acesta este diferit de serverele proxy ordinare, care
sunt proxy de aplicaţii, de exemplu cel HTTP proxy. Suplimentar, versiunea
SOCKS5 efectuează autentificarea, astfel că doar utilizatorii autorizaţi pot
să acceseze un server.
În esenţă, un server SOCKS defineşte o conexiune TCP către o oarecare
adresă IP, oferind astfel un mijloc de înaintare prin reţea a pachetelor de
date. Astfel, protocolul SOCKS ca şi cum creează un tunel IP cu un
protector (firewall – zid de protecţie), iar cererile de protocol sunt apoi
inițiate de protector. Aplicaţia client contactează serverul proxy SOCKS şi,
prin schimbul de mesaje conforme protocolului SOCKS, negociază o
conexiune proxy. Când conexiunea este stabilită, aplicaţia client comunică
cu serverul SOCKS, folosind protocolul SOCKS. Serverul extern comunică cu
cel SOCKS ca şi cum acesta ar fi fiind aplicaţia client în cauză.
SOCKS este un standard de facto pentru porţi de nivel circuit (circuit-
level gateway), ultimele fiind un tip de protector şi operând la Nivelul 5
(sesiune) OSI ISO. Informaţia către un calculator distant, tranzitată printr-o
poartă de nivel circuit, pare că provine de la o poarta de acces (gateway).
Aceasta este util pentru ascunderea informaţiei despre reţelele protejate.
Astfel, porţile de nivel circuit permit ascunderea informaţiei despre
reţelele private, pe care le protejează.
SOCKS este, de asemenea, un instrument care permite ocolirea filtrării
Internet privind accesarea unor anume conținuturi, în mod obişnuit
blocate (de guverne, etc.). Unele aplicaţii client SSH suportă înaintarea de
porturi dinamice (dynamic port forwarding), care permite utilizatorului
crearea unui proxy SOCKS local. De exemplu, fie că internautul A doreşte să
comunice prin Internet cu internautul B, dar în reţeaua internautului A
există un protector, prin care A nu are autorizaţie de acces la Internet.
Atunci A se conectează la serverul proxy SOCKS din reţeaua sa şi îi
transmite acestuia informaţii despre conexiunea, pe care doreşte să o
stabilească cu internautul B. Serverul proxy SOCKS va deschide conexiunea
respectivă prin protector, asigurând astfel comunicarea între internauţii A
şi B.
1.7.10. Sistemul numelor de domenii DNS
Adresele Internet (adresele IP) se specifică în formă numerică (vezi s.
1.5.1). Însă utilizarea acestora într-o asemenea formă nu întotdeauna este
comodă. De aceea este implementată şi adresarea entităţilor de reţea în
formă de nume – nume Internet, pentru folosirea cărora este necesară
convertirea numelor Internet în adrese IP (în formă numerică) şi invers.
104
Administrarea unor asemenea nume se efectuează de Sistemul Numelor
de Domenii (Domain Name System – DNS). Sistemul DNS este definit de
protocolul DNS (RFC 882, RFC 883), propus în 1983, iar ulterior revăzut şi
completat în mai multe documente Internet (RFC 920, 1032-1035, 1101,
1123, …, 6196 ş.a.).
Sistemul DNS este ierarhizat pe nivele. Fiecare nivel alcătuieşte un
domeniu. Un nume Internet constă din mai multe nume de domenii
separate prin punct. De exemplu: csie.ase.md; rtfm.edu; gan.ncc.go.jp. În
primul nume din acest exemplu, domeniul md specifică Republica
Moldova, domeniul ase – Academia de Studii Economice din Moldova
(ASEM) şi domeniul csie – numele unui server din reţeaua ASEM.
Pentru specificarea unui nume Internet, pot fi folosite până la 127 de
nume de domenii, însă în realitate nu se folosesc mai mult de cinci. Fiecare
nume de domeniu poate conţine până la 63 de caractere cu condiţia că un
nume Internet să nu depăşească 253 de caractere. Numele de domenii
urmează în numele Internet de la stânga la dreapta, în ordinea creşterii
ariei de cuprindere – din ce în ce mai generală. De exemplu:
 nume_local_gazdă;
 nume_departament_în_cadrul_organizaţiei, nume_subreţea;
 nume_organizaţie sau nume_reţea;
 nume_ţară.
Conform unei convenţii, domeniile de nivelul cel mai înalt în adresele IP
sunt codurile standard de ţară, definite în documentul ISO 3166. Excepţie
este SUA, pentru care erau stabilite anterior mai multe domenii de nivel
superior şi anume:
.com – organizaţii comerciale;
.edu – instituţii educaţionale, instruire;
.gov – organizaţii guvernamentale non-militare;
.int – instituţii internaţionale;
.mil – organizaţii militare;
.net – resurse de reţea.
.org – alte organizaţii;
Totuşi, din 2002 şi în SUA este folosit din ce în ce mai larg domeniul de
nivel superior .us, acesta fiind gestionat de către compania Neustar
(www.neustar.us).
De menţionat, totodată, că domeniile com, int şi net de mai mulţi ani
se folosesc larg şi pentru servere amplasate în alte ţări. Mai mult ca atât,
lista acestora din an în an se completează cu noi domenii de nivel superior
(Top-Level Domain – TLD). Ca exemple ar putea servi domeniile: .aero, .biz,
105
.coop, .info, .museum, .name, .pro (2000); .jobs, .mobi, .travel (2005), .asia
(2007), .tel (2009) ş.a.
Protocolul DNS este destinat implementării serviciului de server de
nume în cadrul unei reţele aparte din Internet. Acest serviciu se realizează
la o gazdă din reţeaua în cauză. El gestionează adresele Internet ale
gazdelor domeniului (reţelei). În cadrul unei reţele pot fi organizate şi
subdomenii pentru gestionarea independentă a adreselor Internet în
cadrul unor fragmente de reţea.
Serverul de nume furnizează, în mod independent de alte domenii,
adresa Internet a gazdelor din domeniul respectiv. Dacă un server de nume
nu deţine informaţii referitoare la o adresă Internet (o gazdă din alt
domeniu), atunci el interoghează alte servere de nume pentru deservirea
cererii recepţionate.
DNS este susţinută de un sistem distribuit de baze de date, care
foloseşte tehnologia client-server. DNS foloseşte, de obicei, portul 53 al
UDP. Dacă datele depăşesc 512 octeţi sau în cazul unor sarcini speciale,
atunci DNS foloseşte protocolul TCP.
1.7.11. Configurarea dinamică a staţiilor DHCP
Protocolul de configurare dinamică a staţiilor (Dynamic Host
Configuration Protocol – DHCP, RFC 1531), propus în 1993 ca o extensie a
protocolului BOOTP, este folosit de stații (clienți DHCP) pentru obținerea
adreselor IP și a altor informații de configurare de rețea de la serverul
DHCP respectiv. Astfel, se simplifică adăugarea de noi echipamente în
rețea. Nu sunt necesare adrese IP statice (permanente) pentru staţii.
Acestea se obţin doar la necesitate.
Versiunea curentă a DHCP pentru rețele IPv4 este descrisă în RFC 2131,
iar pentru cele IPv6 (DHCPv6) – în RFC 3315 şi, ulterior, dezvoltat în RFC
3633 şi 6603.
Când o stație se conectează la rețea, clientul DHCP al acesteia trimite,
în mod automat, o solicitare, privind informația necesară, serverului
DHCP. Serverul DHCP gestionează o rezervă de adrese IP și informații
despre configurarea unor așa parametri ai clienților DHCP, ca: poarta
implicită, numele domeniului, serverul DNS, serverul de timp ș.a. În baza
unor asemenea informaţii, serverul DHCP pregăteşte şi comunică clientului
DHCP parametrii solicitaţi, pe care ultimul îi aplică la configurarea staţiei
client respective.
Alocarea de către serverul DHCP a adreselor IP stațiilor poate fi
dinamică, automată sau statică. La alocarea dinamică, adresa IP este
106
atribuită stației pe o perioada determinată, cu posibilitatea de realocare, la
necesitate, a acesteia. Alocarea automată este similară celei dinamice, dar
serverul DHCP păstrează un tabel cu alocările de adrese IP anterioare,
astfel încât să poată atribui preferențial pentru o stație aceeași adresă IP,
pe care aceasta a avut-o anterior. La alocarea statică, adresa IP este
atribuită stației în baza unui tabel cu perechi „adresa MAC-adresa IP",
acestea fiind completate din timp manual.
Folosirea DHCP se recomandă doar în reţele protejate.
1.7.12. Sincronizarea timpului în reţea
1.7.12.1. Protocoalele de timp în reţea NTP şi SNTP
Protocolul NTP (Network Time Protocol; RFC 1305, RFC 5905) serveşte
pentru sincronizarea de ceas în reţea. Foloseşte portul 123 prin UDP şi
poate asigura o exactitate de zeci de milisecunde în reţelele de arie largă şi
de o milisecundă în reţelele locale.
Un protocol mai simplu cu aceeaşi destinaţie este SNTP (Simple NTP;
RFC 1361, RFC 1769, RFC 2030, RFC 4330), folosit, de obicei, în
echipamente încorporate, care nu necesită o exactitate atât de înaltă.
1.7.12.2. Protocolul de timp Time
Protocolul Time (Time Protocol; RFC 868) defineşte coordonarea de
ceas şi dată a gazdelor din reţea. El are o structură de tip master-slave.
Sincronizarea de ceas a gazdelor din reţea se face periodic ca urmare a
mesajelor respective recepţionate de la master şi generate de procesul
timed (time daemon).
107
2. CONCEPTUL INTRANET
2.1 Esenţa intranet
Prin intranet se are în vedere orice reţea corporativă (a unei companii,
instituţii, organizaţii), care operează în baza tehnologiei de reţea TCP/IP. O
reţea intranet poate fi de arie locală (LAN), metropolitană (MAN) sau de
arie largă (WAN).
Intranet se asociază, în mare parte, cu folosirea serviciilor Web, primul
sit Web intranet fiind lansat în 1991. Ulterior, îndeosebi odată cu lansarea
primului explorator Web grafic (Mosaic, 1993) şi dezvoltarea comerţului
electronic, serviciile Web au cunoscut o dezvoltare spectaculoasă.
O noţiune, cu tangenţă la intranet, este cea de extranet. Prin extranet
se subînţelege acea parte a intranet, acces la care pot avea clienţii,
furnizorii sau alte persoane autorizate din afara organizaţiei deţinătoare a
intranet. Astfel, o parte din intranet poate fi accesată, posibil reglementat,
doar de colaboratorii organizaţiei, iar o altă parte (extranet) – şi de
persoane autorizate din afara organizaţiei.
Pentru accesul diferenţiat la resursele intranet, se folosesc diverse
mijloace de acces reglementat şi protecţie contra accesului neautorizat,
inclusiv: de autentificare, autorizare, contorizare şi cifrare; bariere
informatice de protecţie (firewall); reţele private virtuale ş.a.
2.2. Avantaje intranet

Avantajele intranet pot fi grupate în două categorii: (1) avantajele
informatizării diverselor activităţi ale unităţii economice faţă de operarea
cu informaţiile în mod tradiţional; (2) avantajele folosirii tehnologiilor
intranet faţă de aplicarea altor tehnologii de reţea în cadrul unităţii
economice. Avantajele ce ţin de prima categorie nu se referă la tematica
cursului, dar şi sunt, de obicei, bine cunoscute.
Oportunitatea creării intranet se lămureşte prin nivelul avansat de
dezvoltare al mijloacelor Internet. Folosirea mijloacelor respective în cadrul
reţelelor de calculatoare ale companiilor, instituţiilor, organizaţiilor
permite crearea de i-reţele performante la costuri reduse, ceea ce conduce
la eficienţa înaltă a acestora. Din beneficiile intranet în ansamblu ar putea
fi menţionate:
108
 creşterea productivităţii muncii în baza folosirii de către lucrători a
unor mijloace avansate de regăsire, procesare şi redare a
informaţiilor relevante activităţilor acestora, astfel îmbunătăţind
condiţiile şi fortificând capacităţile respective ale acestora, îndeosebi
la luarea de decizii reuşite în diverse situaţii;
 asigurarea lucrătorilor cu informaţii actuale, relevante, în mod
selectiv la momentul potrivit – „cine cunoaşte informaţia –
stăpâneşte situaţia”;
 un mijloc puternic, comod şi eficient de comunicare între lucrători,
inclusiv prin tehnologiile Web ş.a.
La avantajele specifice ale folosirii intranet se referă:
 reducerea costurilor cu procurarea, imprimarea şi distribuirea
informaţiilor pe hârtie, inclusiv privind diversele ghiduri şi instrucţiuni
de serviciu, produse, noutăţi şi evenimente aferente, etc.;
 uşor de folosit, de obicei nu sunt necesare cursuri speciale;
 costuri reduse cu crearea şi exploatarea;
 tehnologii bine dezvoltate şi larg folosite, compatibile cu cele folosite
de multe alte unităţi economice, ceea ce permite crearea de sisteme
extranet eficiente ş.a.
Totodată, implementarea şi folosirea intranet poate implica eforturi
suplimentare:
 este necesar un program bine chibzuit privind activităţile de
informatizat, asigurând eficienţa scontată;
 actualizarea conţinutului informaţional necesită eforturi şi timp;
 asigurarea nivelului de securitate adecvat necesită implicarea de
personal calificat ş.a.
2.3. Caracteristici importante ale intranet

Caracteristicile unei reţele pot fi privite atât din punctul de vedere al
utilizatorului, cât şi sub aspectul intern al reţelei înseşi. Anume a doua
categorie de caracteristici şi asigură, până la urmă, performanţele
serviciilor oferite utilizatorilor. Ea include caracteristici ale componentelor,
dar şi caracteristici de ansamblu, cum ar fi topologia reţelei. Aceste
caracteristici sunt de domeniul de interes mai cu seamă al grupurilor de
proiectare şi de administrare a reţelei. În continuare se vor prezenta unele
caracteristici din prima categorie.
Fiecare utilizator solicită servicii de la o reţea prin cereri (interogări)
concrete, formulate în conformitate cu anumite reguli. De aceea, pentru
109
utilizator, performanţele reţelei sunt reflectate de caracteristicile deservirii
cererilor sale. Dacă ţinem cont de mulţimea utilizatorilor în ansamblu,
atunci o reţea se caracterizează, din punctul de vedere al utilizatorilor, prin
gama, calitatea şi costul serviciilor oferite. La rândul său, calitatea prestării
serviciilor se caracterizează de aşa parametri ca: durata de răspuns la
cerere; siguranţa deservirii cererilor ş.a. Calitatea prestării serviciilor
depinde, în mare măsură, de capacitatea (productivitatea) de servire a
reţelei, iar siguranţa prestări serviciilor – de pierderile de date şi fiabilitatea
funcţionării reţelei. În multe cazuri, utilizatorul este cointeresat în
păstrarea confidenţialităţii serviciilor informatice.
Ca exemple de servicii de reţea poate servi gama de servicii Internet
specificată în s. 1.1.
Capacitatea caracterizează puterea reţelei de deservire a cererilor
utilizatorilor şi se determină de volumul lucrărilor, ce pot fi îndeplinite într-
o unitate de timp. Deseori ea se apreciază prin numărul total al
utilizatorilor, ce pot fi deserviţi, sau cel al cererilor, ce pot fi procesate într-
o unitate de timp. Capacitatea reţelei se determină de performanţele
serverelor, cele ale nodurilor de comunicaţie şi cele ale canalelor de
transfer date între acestea şi, de asemenea, de aşa factori ca topologia
reţelei, aria de cuprindere, tehnologiile de cooperare a resurselor folosite
ş.a. La capacităţi joase şi trafic de cereri neuniform, calitatea prestării
serviciilor, în perioadele de vârf, poate fi joasă.
Costul serviciilor depinde de costul total al reţelei şi resursele concrete
ale acesteia, implicate în oferirea serviciilor respective. Costul reţelei se
determină ca suma costurilor componentelor acesteia. În ce priveşte
resursele, implicate în oferirea unor servicii concrete, acestea depind de
tipul serviciului şi alţi factori. De exemplu, poşta electronică nu impune
cerinţe deosebite privind transferul mesajelor, cum ar fi operativitatea
livrării sau cea de trafic izocron (viteză de transfer date constantă în timp).
De aceea atât resursele implicate sunt relativ joase, cât şi, respectiv,
costurile prestării serviciului de poştă electronică sunt relativi mici. Din
contra, serviciul video trebuie să fie prestat în timp real, implică trafic de
date izocron şi necesită capacităţi relativ mari de transfer date (de
exemplu, pentru TV – de ordinul a 4-12 Mbps). De aceea resursele
implicate sunt relativ înalte şi, respectiv, costurile prestării serviciului sunt
relativi mari.
Durata de răspuns, numită, uneori, şi întârziere sau reţinere se
determină de intervalul de timp de la momentul lansării cererii în reţea
până la apariţia primului caracter al mesajului de răspuns. Cerinţele către
110
această caracteristică deviază, în funcţie de regimul de interacţiune a
utilizatorului cu reţeaua: dialog, cerere-răspuns (eng. request-answer) sau
„pe loturi” (eng. batch). O interacţiune "utilizator - reţea" constă din două
etape:
 pregătirea şi lansarea de către utilizator a cererii în reţea;
 deservirea şi redarea de către reţea a mesajului de răspuns.
Durata medie de răspuns nu trebuie să depăşească, de regulă:
 pentru cererile de dialog – 2-3 s, cel mult 15 s;
 pentru cererile în regimul cerere-răspuns – 30-90 s, cel mult 3-5 min;
 pentru cererile pe loturi – poate fi câteva ore sau chiar câteva zile.
Există şi cazuri, când la soluţionarea unei probleme sunt necesare
săptămâni sau chiar luni, dar acestea sunt cazuri ieşite din comun.
Regimul de dialog presupune atingerea scopului scontat (soluţionarea
unei probleme, examinarea unui document, consultarea unei baze de date)
în rezultatul unei secvenţe de interacţiuni "utilizator - reţea" dependente
între ele – formularea următoarei cereri, în funcţie de răspunsurile la cele
precedente. De exemplu, perfectarea unui document în Microsoft Office
365, instalat la un server distant.
Regimul cerere-răspuns presupune independenţa cererilor între ele şi
atingerea scopului scontat în rezultatul unei singure interacţiuni "utilizator
- reţea". De exemplu, lansarea în execuţie a unei aplicaţii de soluţionare a
unei probleme, instalate în Google Apps Drive.
Regimul „pe loturi” presupune executarea mai multor sarcini (de
exemplu, soluţionarea unui set de probleme independente) în rezultatul
unei singure interacţiuni "utilizator - reţea" (fig. 2.1). În acest scop într-un
lot, ce formează cererea, sunt grupate mai multe sarcini independente.
Cerere
Staţie utilizator: pregătirea Reţea
şi lansarea cererii în reţea
pentru procesare
Răspuns
Fig.
Fig.2.1 Interacţiune„utilizator
x.1.Interacţiune - reţea".
"utilizator – reţea”.
Durata medie de răspuns nu trebuie să depăşească, de regulă:
 pentru cererile de dialog – 2-3 s cel mult 15 s;
 pentru cererile în regimul cerere-răspuns – 30-90 s cel mult 3-5 min;
 pentru cererile „pe loturi” – câteva ore sau chiar câteva zile.
111
Fiabilitatea este capacitatea reţelei de a-şi îndeplini funcţiile în
condiţiile date, disponibilitatea serviciilor oferite pentru utilizatorii săi. Ea
poate fi apreciată prin raportul duratei medii ponderate de funcţionare
normală a serviciilor în reţea la durata totală de funcţionare a reţelei
(durata funcţionării normale + durată restabilirii serviciilor căzute). În ce
priveşte transferul de date, deseori cerinţa de fiabilitate se înaintează
printr-o cerinţă pentru o anumită conectivitate de noduri în reţea. De
exemplu, pentru reţeaua ARPA iniţial a fost stabilită cerinţa de a asigura cel
puţin două căi independente de transfer date între orişice pereche de
noduri ale ei.
În unele situaţii, de exemplu la congestionarea reţelei pe unele
segmente (fragmente) sau căderi ale unor componente (servere, canale,
noduri de comunicaţie), pot avea loc pierderi de pachete care conduc la
creşterea duratei de răspuns sau chiar la refuzuri în deservirea cererilor
utilizatorilor.
2.4. Funcţionalităţi de bază ale intranet

În cadrul intranet pot fi distinse patru categorii de funcţionalităţi:
1) suportul informatic al activităţilor de bază ale unităţii economice şi al
gestiunii acestora;
2) comunicare şi colaborare;
3) publicare Web;
4) administrarea, gestiunea şi dezvoltarea intranet.
Suportul informatic al activităţilor unităţii economice şi al gestiunii
acestora include aşa activităţi ca:
 pregătirea de alternative relevante şi susţinerea luării de decizii;
 controlul executării deciziilor;
 susţinerea activităţilor curente;
 accesul la baze de date.
Comunicare şi colaborare:
 trimitere şi recepţionare i-poştă, faxuri;
 forumuri de discuţii;
 conferinţe audio şi video;
 întruniri şi şedinţe virtuale, inclusiv colaborarea la proiecte colective
ş.a.
Dezvoltarea şi publicarea de documente Web:
 cataloage de produse;
 buletine informative;
112
 manuale şi materiale pentru instruire, etc.
Gestiunea şi dezvoltarea intranet include:
 administrarea funcţionării mijloacelor tehnice şi a aplicaţiilor
informatice;
 gestiunea accesului utilizatorilor la resursele intranet;
 actualizarea informaţiilor privind necesităţile utilizatorilor şi folosirea
resurselor intranet;
 integrarea tehnologiilor şi dezvoltarea intranet.
2.5. Aspecte de creare şi dezvoltare a intranet

Cooperarea resurselor informatice în cadrul unei intranet are mari
avantaje faţă de folosirea izolată a resurselor staţiilor componente.
Totodată, cuprinderea tuturor activităţilor în cadrul organizaţiei, oportune
de informatizat, implică resurse considerabile. De aceea creării reţelelor
intranet eficiente i se acordă o atenţie pe măsură.
La proiectarea unei intranet se iau în consideraţie aşa aspecte ca.
 scopul şi obiectivele i-reţelei;
 activităţile informatice de acoperit;
 serviciile informatice de reţea de elaborat şi implementat;
 definirea cerinţelor şi implementarea măsurilor de securitate;
 configurarea fizică şi logică a componentelor şi a reţelei în ansamblu,
îmbinând eficient oportunităţile de concentrare şi distribuire a
resurselor informatice;
 eşalonarea în timp a lucrărilor;
 administrarea datelor, serviciilor şi a i-reţelei;
 subdiviziunile şi persoanele responsabile de crearea şi implementarea
reţelei ş.a.
La crearea aplicaţiilor informatice pentru intranet se pot folosi aşa
produse program ca Microsoft SharePoint, IBM Websphere, Lotus Notes,
Oracle Fusion Middleware, Open text, Bitrix24, Drupal, Hyperoffice,
Drupal, Jumla ş.a.
La configurarea mijloacelor de i-reţea se vor folosi, în măsura
necesităţilor, funcţionalităţile privind: i-barierele; asigurarea calităţii
serviciilor; folosirea serverelor proxy; accesul diferenţiat, reglementat al
utilizatorilor la resurse; securizarea transferurilor de date; folosirea
reţelelor fără fir; folosirea punţilor şi a tunelelor, etc.
În cele ce urmează, cap. 3-11, ca exemplu de mijloace ce ar putea fi
folosite la crearea de intranet, sunt descrise mijloacele de reţea ale
113
companiei Mikrotik. Mai întâi este caracterizată compania înseşi (s. 3.1),
apoi sunt descrise în linii mari echipamentele de reţea (s. 3.2), sistemele de
operare RouterOS (s. 3.3, 3.4) şi SwOS (s. 3.5) şi monitorul de reţea Dude
(s. 3.6).
Ulterior, în cap. 4-11 sunt descrise funcţionalităţile şi diverse aspecte
practice de configurare şi folosire a sistemului RouterOS la crearea şi
administrarea de reţele intranet, inclusiv: instalare, configurare,
conectarea la Internet, licenţe, actualizare, gestiunea serviciilor, i-bariere,
asigurarea calităţii serviciilor, gestiune, reţele fără fir, puntare (bridging),
rutare, tunelare ş.a.
114
3. MIJLOACE DE REȚEA MikroTik
3.1. Compania MikroTik
Compania MikroTik (www.mikrotik.com) a fost fondată în 1995 în Riga,
Letonia. Domeniul de activitate al companiei: producerea și dezvoltarea
mijloacelor de rețea de calculatoare. Livrează echipamente şi produse
program de reţea pentru reţele de calculatoare la domiciliu, companii mici
şi mijlocii şi, de asemenea, pentru acces la Internet.
Din istoria dezvoltării companiei Mikrotik, se pot evidenția următoarele
evenimente:
 1995 – fondarea companiei;
 1997 – lansarea sistemului de operare de reţea RouterOS pentru PC
x86;
 2002 – lansarea fabricaţiei liniei de echipamente de reţea
RouterBOARD;
 2006 – prima conferință a utilizatoruilor MikroTik (MikroTik User
Meeting – MUM, Praga);
 2011 – lansarea Academiei Mikrotik.
Astfel, compania Mikrotik fabrică echipamente de reţea RouterBOARD
şi dezvoltă sistemul de operare RouterOS – mijloace descrise, în linii mari,
în ss. 3.2, 3.3.
În cei 18 ani de activitate compania Mikrotik;
 a livrat milioane de echipamente de reţea în majoritatea ţărilor lumii;
 a pregătit şi certificat circa 25000 de ingineri RouterOS;
 menţine o reţea mondială de consultanţi certificaţi;
 dispune de mii de pagini de documentaţie, exemple şi ghiduri;
 a organizat 55 de conferinţe MUM în 27 de ţări de pe toate
continentele [2]. Prima conferinţă MUM în Republica Moldova a fost
organizată în august 2013.
3.2. Echipamente de reţea MikroTik

Echipamentele de reţea MikroTik includ o gamă relativ largă de rutere,
comutatoare, puncte de acces fără fir, interfeţe, carcase şi accesorii.
Ruterele şi comutatoarele pot fi atât în formă de soluţii integrate, cât şi în
formă de componente aparte. Echipamentele de reţea MikroTik sunt
115
grupate, de asemenea, în serii, după setul de instrucţiuni al procesoarelor
utilizate:
1) mipsbe: RB4xx, RB7xx, RB9xx, RB2011, SXT, OmniTik, Groove, Metal,
SEXTANT;
2) ppc: RB3xx, RB600, RB800, RB1xxx;
3) x86: PC/X86, RB230;
4) mipsle: RB1xx, RB5xx, RB Crossroads;
5) tile: CCR (cloud core routers).
În denumirile produselor RouterBOARD, RB semnifică RouterBOARD,
iar formatul denumirilor este [1]:
[nume] [caracteristici]-[cartelă fără fir încorporată]-[tip
conector]-[tip carcasă]
Pentru [nume] se folosesc trei tipuri:
1) număr din trei cifre:
 prima cifră specifică seria;
 a doua cifră specifică numărul de interfeţe posibile pentru cabluri
(Ethernet, SFP, SFP+);
 a treia cifră specifică numărul de interfeţe fără fir posibile
(încorporate, sloturi mPCI şi mPCIe);
2) cuvânt: OmniTIK, Groove, SXT, SEXTANT şi Metal. Dacă produsul a
fost modificat substanţial (de exemplu, un alt procesor), la sfârşit se
adaugă numărul versiunii;
3) excepţii: 600, 800, 1000, 1100, 1200 şi 2011, care sunt unicii
reprezentanţi ai seriei sau conţin mai mult de 9 interfeţe pentru
cabluri. Ultimul caz (2011) specifică anul lansării produsului.
Pentru [caracteristici] se folosesc opţiunile (în ordinea folosirii):
U – are cel puţin un port USB;
P – injecție de putere cu controler;
i – un singur port cu injecție de putere fără controler;
A – mai multă memorie şi, de obicei, cu licența de nivel mai înalt;
H – procesor mai performant;
G – Gigabit (poate include „U”, „A”, „H”, dacă nu se foloseşte cu „L”);
L – ediţie simplificată;
S – port SFP (se folosesc, de obicei, în echipamente cu SwOS);
e – cartela PCIe de extensie a interfeţei;
x<N> – unde N este numărul de nuclee a procesorului (x2, x16, x36,
etc.).
116
Dacă produsul are încorporate funcţionalităţi fără fir, atunci
caracteristicile respective [cartelă fără fir încorporată] sunt specificate în
formatul:
[bandă][putere_pe_cale][protocol][număr_de_căi]
Pentru [bandă] se folosesc opţiunile:
5 – 5 GHz;
2 – 2,4 GHz;
52 – bandă duală: 5 GHz şi 2,4 GHz.
Pentru [putere_pe_cale] (chain – lanţ, cale, canal) se folosesc opţiunile:
(nu se foloseşte) – „Normal” (putere normală) – [23 dBm la 6 Mbps
802.11a; [24 dBm la 6 Mbps 802.11g;
H – „High” (putere medie) – 23-24 dBm la 6 Mbps 802.11a; 24-27 dBm
la 6 Mbps 802.11g;
HP – „High Power” (putere înaltă) – 25-26 dBm at 6Mbps 802.11a; 28-
29 dBm at 6Mbps 802.11g;
SHP – „Super High Power” (putere foarte înaltă) – 27+ dBm at 6Mbps
802.11a; 30+ dBm at 6Mbps 802.11g.
Pentru [protocol] se folosesc opţiunile:
(nu se foloseşte) – pentru cartele cu suport doar 802.11a/b/g;
n – pentru cartele cu suport 802.11n;
ac – pentru cartele cu suport 802.11ac.
Pentru [număr_de_căi] se folosesc opţiunile:
(nu se foloseşte) – o singură cale;
D – două căi;
T – trei căi.
Pentru [tip_conector] se folosesc opţiunile:
(nu se foloseşte) – doar o opţiune de conector pentru produs;
MMCX – conector de tip MMCX;
u.FL – conector de tip u.FL.
Pentru [tip carcasă] se folosesc opţiunile:
(nu se foloseşte) – tipul obişnuit (de bază) de carcasă pentru produs;
BU – unitate placă (fără carcasă) – pentru cazurile când se cere doar
placa, dar produsul de bază se livrează în carcasă;
RM – carcasă ce se montează în şasiu (rack);
IN – carcasă pentru produse în încăperi;
OUT – carcasă pentru produse în spaţiul liber;
SA – carcasă antenă sectorială;
HG – carcasă pentru antenă de mare înălţime;
117
EM – memorie extinsă.
Exemplul 3.1. În notarea RB912UAG-5HPnD-OUT, RB semnifică
RouterBOARD, 9 – seria 9xx, 1 – un port Ethernet (pentru conexiune prin
cablu) şi 2 – două porturi fără fir (încorporat şi miniPCIe), U – port USB, A –
mai multă memorie RAM, G – un port Gigabit Ethernet, 5HPnD – cartelă
fără fir la 5 GHz cu două căi de putere înaltă şi suport 802.11n, OUT –
pentru instalare în spaţiul liber.
Familia de echipamente de reţea CloudCoreRouter sau prescurtat CCR
foloseşte pentru denumirile produselor formatul:
CCR[număr din 4 cifre]-[listă de porturi]-[tip carcasă]
Pentru [număr din 4 cifre] se folosesc opţiunile:
 a doua cifră este rezervată;
 a treia şi a patra cifre specifică numărul de nuclee procesor în ruter.
Pentru [listă de porturi] se folosesc opţiunile:
 -<n>G – numărul de porturi Gigabit Ethernet;
 -<n>S – numărul de porturi SFP;
 -<n>S+ – numărul de porturi SFP+.
Pentru [tip carcasă] se folosesc aceleaşi opţiuni ca şi la produsele
RouterBOARD.
Exemplul 3.2. În notarea CCR1036-12G 4S-EM, CCR semnifică
CloudCoreRouter, 1036 – seria 1xxx, 0 – rezervat, 36 de nuclee procesor,
12G – 12 porturi Gigabit Ethernet, 4S – patru porturi SFP şi EM – memorie
extinsă.
Familia de echipamente de reţea CloudRouterSwitch sau prescurtat
CSR foloseşte pentru denumirile produselor formatul:
CSR[număr din 3 cifre]-[listă de porturi]-[cartela fără fir
încorporată]-[tip carcasă]
Pentru [număr din 3 cifre] se folosesc opţiunile:
 a doua şi a treia cifre specifică numărul de interfeţe pentru
conexiuni prin cablu (Ethernet, SFP, SFP+).
Pentru [listă de porturi] se folosesc opţiunile:
 -<n>G – numărul de porturi Gigabit Ethernet;
 -<n>S – numărul de porturi SFP;
 -<n>S+ – numărul de porturi SFP+.
Pentru [cartela fără fir încorporată] şi, de asemenea, [tip carcasă] se
folosesc aceleaşi opţiuni ca şi la produsele RouterBOARD.
118
Pentru [tip carcasă] se folosesc aceleaşi opţiuni ca şi la produsele
RouterBOARD.
Exemplul 3.3. În notarea CRS125-24G 1S-2HnD-IN, CRS semnifică
CloudRouterSwitch, 125 – seria 1xxx, 25 – numărul de interfeţe pentru
conexiuni prin cablu, 24G – 24 porturi Gigabit Ethernet, 1S – un port SFP,
2HnD – cartelă fără fir la 2,4 GHz cu două căi de putere medie („High”) şi
suport 802.11n, IN – pentru instalare în încăperi.
La 20 aprilie 2014, categoria de echipamente Mikrotik integrate (se
livrează completate cu carcase şi adaptoare de alimentare electrică) livrate
cuprindea dispozitivele:
 rutere Ethernet: RB750; RB750UP; RB750GL; RB2011iL-IN;
RB2011iL-RM; RB2011iLS-IN; RB2011UiAS-IN; RB2011UiAS-
RM; RB1100AHx2-LM; RB1100AHx2; CCR1009-8G-1S; CCR1016-
12G; CCR1016-12S-1S+; CCR1036-12G; CCR1036-12G-4S;
CCR1036-8G-2S+; CCR1036-12G-4S-EM; CCR1036-12G-4S;
CCR1036-8G-2S+EM; RB750G; RB1000; RB1100U; RB1100;
RB1100Hx2; RB1100AN; RB1200;
 comutatoare: RB260GS; RB260GS; CRS125-24G-1S-IN; CRS125-
24G-1S-RM; CRS125-24G-1S-2HnD-IN; CRS226-24G-2S+IN;
RB250GS;
 sisteme fără fir: SXT Lite2; SXT Lite5; Groove 52HPn; GrooveA
52HPn; SXT G-2HnD; SXT 5HPnD; BaseBox5; OmniTIK U-5HnD;
OmniTIK UPA-5HnD; SXT HG; SXT SA; Metal 2SHPn; Metal
5SHPn; SEXTANT G 5HPnD; QRT-2; SXT Sixpack; SXT 5HnD;
SXT G-5HnD;
 sisteme fără fir de domiciliu sau oficiu: RB911-5Hn; RB951-2n;
RB951Ui-2HnD; RB951G-2HnD; RB2011UiAS-2HnD-IN; RB751U-
2HnD; RB751G-2HnD.
Ca exemple, în figura 3.1 sunt prezentate ruterele SXT Lite5, RB951Ui-
2HnD şi CCR1036-12G-4S. Ruterul SXT Lite5 (cod RBSXT5nDr2) operează
conform standardului 802.11 a/n; este unul pentru instalare în spaţiul
liber, dotat cu 64 Mo memorie RAM, un port Fast Ethernet (10/100 Mbps)
şi o antenă cu polarizare duală (Dual Chain – cale duală, lanţ dual) de 16
dBi; poate fi folosit pentru legături punct-la-punct la distanţe de până la
câţiva km sau ca echipament la sediul clientului (customer premises
equipment – CPE) pentru legături punct-la-multipunct.
RB951Ui-2HnD este dotat cu 128 Mo RAM, un punct de acces (access
point – AP) fără fir cu antenă încorporată ce operează conform
standardului 802.11b/g/n, cinci porturi Fast Ethernet (10/100 Mbps) şi un
port USB 2.0. Acesta poate fi folosit în oficii mici sau la domiciliu (small
119
offices and home offices – SOHO) pentru interconectare, inclusiv fără fir, a
unui număr relativ mic de calculatoare.
a) b)
c)
Fig. 3.1. Ruterele SXT Lite5 (a), RB951Ui-2HnD (b) şi CCR1036-12G-4S (c).
Ruterul CCR1036-12G-4S foloseşte procesorul Tilera (36 nuclee);
implicit este dotat cu 4 Go RAM, dar poate folosi până la 16 Go RAM şi mai
mult; conţine 12 porturi Cigabit Ethernet şi 4 porturi SFR (Small form-factor
pluggable) şi operează la viteza de până la 24 mln pachete pe secundă.
Portul SFP este un transiver optic, care poate opera la viteza de până la
câţiva Gbps; el serveşte ca interfaţă între placa de bază a ruterului şi cablul
optic de reţea.
Categoria de echipamente Mikrotik în formă de componente aparte
(rutere integrate mici pe o placă, ce operează sub sistemul de operare
RouterOS; pot fi folosite pentru asamblarea de sisteme proprii, selectând
separat suplimentar carcasa şi interfeţele), la 20 aprilie 2014, include:
RB411; RB411A; RB411AR; RB411AH; RB411L; RB411GL; RB411R; RB411U;
RB411UAHL; RB411UAHR; RB433; RB433AH; RB433UL; RB433L;
RB433UAH; RB433UAHL; RB435G; RB450; RB450G; RB493; RB493G;
RB493AH; RB600A; RB711-2Hn; RB711-5Hn; RB711A-5Hn-M; RB711GA-
5HnD; RB711-5Hn-U; RB800; RB911G-2HPnD; RB911G-5HPnD; RB912UAG-
120
2HPnD; RB912UAG-5HPnD; RB2011L; RB2011LS; RB2011UiAS-2HnD;
CCR1016-12G-BU.
În figura 3.2 sunt prezentate ruterele RB2011L (a) şi RB411UAHR (b).
Ruterul RB2011L are 5 porturi Gigabit Ethernet şi 5 porturi Fast Ethernet,
iar cel RB411UAHR este dotat cu un slot miniPCI-e, un slot SIM pentru
modeme 3G, un port USB 2.0 (pentru ataşarea memoriei externe), un port
Ethernet şi un port 802.11 b/g.
a) b)
Fig. 3.2. Ruterele: a) RB2011L şi b) RB411UAHR.

Carcasele (unele din ele pentru echipamente de instalat în încăperi,
altele pentru cele de instalat în spaţiul liber), confecţionate la 20 aprilie
2014, sunt:
 CA411-711 – din aluminiu, pentru rutere din seriile RB411, RB711 şi
RB91x;
 CA150 – din aluminiu, pentru rutere din seriile RB450 şi RB450G;
 CA433U – din aluminiu, pentru rutere din seriile RB433;
 CA493 – din aluminiu, pentru rutere din seriile RB493;
 CA800 – din aluminiu, pentru rutere RB800;
 CAOTS – din plastic, pentru rutere din seriile RB411 şi RB711;
 CAOTU – din plastic, pentru rutere din seriile RB411, RB433, RB493,
RB711 şi RB800.
Carcasele CA 493 şi CAOTS sunt prezentate în figura 3.3.
Interfeţe (cartele radio fără fir pentru extinderea funcţionalităţilor
dispozitivelor RouterBOARD şi celor ale PC, ce operează sub RouterOS)
fabricate: S-31DLC20D; S-85DLC05D; S-3553LC20D; R11e-2HnD; R11e-
2HPnD; R11e-5HnD; R2SHPn; R5SHPn; RB14e; RB14eU; RB44Ge; R52H;
R52Hn; R52nM; RB502; RB604; RB816; IAMP1, IAMP1E ş.a.
Interfeţele S-31DLC20D, S-3553LC20D şi R52nM sunt prezentate în
figura 3.4. Cea S-31DLC20D este un transiver SFP de 1,25G cu un conector
LC Dual de 1310 nm pentru conexiuni prin fibră optică monomod de până
121
la 20 km. Interfaţa S-3553LC20D este o pereche de transivere SFP pentru
conexiuni prin fibră optică de până la 20 km: S-35LC20D de 1,25G cu un
conector LC, T1310/R1550 nm; S-53LC20D de 1,25G cu un conector LC,
T1550/R1310 nm. Adaptorul de reţea R52nM este o cartelă miniPCI cu doi
conectori MMCX pentru antene externe; el operează conform
802.11a/b/g/n, suportând viteze de până la 300 Mbps de la şi către ruter.
a) b)
Fig. 3.3. Carcasele CA 493 (a) şi CAOTS (b).
a) c)
b)
Fig. 3.4. Interfeţele S-31DLC20D (a), S-3553LC20D (b) şi R52n-M.

Accesoriile includ:
 RB2011 mount – set de instalare pe perete a dispozitivelor din seria
RB2011;
122
 RBPOE-CON-HP – convertor de la 48V PoE (IEEE 602.3af, 802.3at,
Telecom PoE) la 24V PoE pentru dispozitive RouterBOARD;
 18POW – adaptor de alimentare electrică (24V; 0,8A) pentru toate
modelele RouterBOARD;
 24HPOW – adaptor de alimentare electrică (24V; 1,6A) pentru
sistemele cu mai multe cartele fără fir cu consum de energie relativ
mare;
 48POW – adaptor de alimentare electrică (48V) pentru rutere RB800;
 RBPOE – injector de alimentare electrică a dispozitivelor PoE pasive
prin porturile 10/100 Mbps;
 RBGPOE – injector de alimentare
electrică a dispozitivelor PoE pasive
prin porturile 1000 Mbps;
 ACUFL – cablu cu mufă pentru
conectarea unei antene externe la
dispozitivele R52 şi R52H;
 ACMMCX – cablu cu mufă pentru
conectarea unei antene externe la
R52nM, R52Hn R5SHPn şi R52SHPn;
 ACSWI – antena pivotantă 2,4-5,8
GHz cu cablu şi conector pentru R52 Fig. 3.5. Antenă ACSWIM.
şi R52H;
 ACSWIM – antena pivotantă 2,4-5,8 GHz cu cablu şi conector MMCX
pentru R52Hn, R52nM şi R5SHPn (fig. 3.5).
Informații succinte privind unele echipamentele de rețea, fabricate și
livrate de compania Mikrotik, sunt sistematizate în anexele 1 și 2. Din
aceste anexe se poate observa că echipamentele în cauză pot fi folosite în
calitate de: rutere magistrale (CCR1036, CCR1016, RB1200 și RB800),
puncte de acces pentru rețele magistrale fără fir (RB800 și RB493G); rutere
pentru rețele Ethernet, Fast Ethernet și Gigabit Ethernet; diverse puncte de
acces fără fir – de la cele cu capacități reduse și până la cele cu capacități
înalte; echipamente pentru rețele mici în oficii și la domiciliu; unități
pentru legături punct-la-punct și punct-la-multipunct (RB711, RG-411, SXT
Lite).
3.3. Sistemul de operare MikroTik RouterOS

Pentru echipamentele de rețea proprii, Mikrotik a lansat două sisteme
de operare: RouterOS și SwOS. Sistemul SwOS este descris în s. 3.5.
123
Prima versiune a sistemului RouterOS (pentru PC x86) a fost lansată în
1997. În mai 2013 a fost lansată versiunea şase – RouterOS v6.
RouterOS este un sistem de operare de ruter pentru echipamente de
rețea Mikrotik sau PC Intel compatibile. Instalat pe un PC, acesta îl
transformă într-un ruter cu toate funcționalitățile respective: rutare, i-
barieră (firewall), poartă hotspot, server VPN ș.a. [1]. Lista echipamentelor
suportate de RouterOS poate fi accesată la adresa wiki.mikrotik.com/
wiki/Supported_Hardware. Această listă este actualizată după necesitate.
RouterOS este un sistem de operare autonom, bazat pe nucleul
sistemului Linux v3.3.5, și dispune de așa proprietăţi ca:
 compatibilitate cu arhitectura i386;
 suportă procesoare multinucleu și calculatoare multiprocesor;
 memorie RAM necesară de minimum 32 Mo;
 poate fi instalat pe unități de memorie IDE, SATA, USB şi memorie
flash, inclusiv discuri fixe, cartele CF (compact flash) și SD (secure digital),
discuri SDD (solid state disk) ș.a. Pentru instalare este nevoie de spațiu de
memorie de cel puţin 64 Mo;
 suportă interfețe de rețea suportate de Linux v3.3.5, inclusiv cartele
10 Gbps Ethernet, cartele 802.11 a/b/g/n și modeme 3G;
 suportă diverse modalități de configurare: acces local cu tastatură și
monitor; consolă serială cu aplicație terminală; acces Telnet și SSH prin
rețea; un instrument Winbox de configurare GUI personalizată; o interfață
WebFig de configurare simplă Web și o interfață de programare API pentru
alcătuirea de aplicații de control proprii. Susține, de asemenea, o interfață
de configurare din linia de comandă cu capabilități de scripting integrate.
Începând cu versiunea 4 (RouterOS v4), susține limbajul Lua de scripting;
 realizează un set bogat de funcționalități de i-barieră, prevenind
accesul neautorzat la ruter şi reţelele ataşate direct, prin inspectarea şi
filtrarea pachetelor de tranzit și monitorizarea stării conexiunilor de rețea
ce tranzitează ruterul. Suportă, de asemenea, funcţia de translatare a
adreselor de reţea (Network Address Translation – NAT);
 suportă protocoalele de rutare RIP v1, RIP v2, OSPF v2, BGP v4 pentru
IPv4 şi cele RIPng, OSPF v3 şi BGP pentru IPv6. Suportă, de asemenea,
rutarea şi înaintarea virtuală (Virtual Routing and Forwarding – VRF),
inclusiv în baza MPLS (Multiprotocol Label Switching), rutarea bazată pe
politici (policy based routing), rutarea bazată pe interfaţă şi rutarea ECMP;
 înaintarea Nivel2 (Level2 forwarding), inclusiv puntarea (bridging),
plasă (mesh) şi WDS (Wireless Distribution System), folosind şi aşa
protocoale ca HWMP+ şi OpenFlow;
124
 crearea de VPN, inclusiv: IPsec; tunelarea punct-la-punct (OpenVPN,
PPTP, PPPoE, L2TP, SSTP); funcţionalităţi ale PPP avansat (MLPPP, BCP);
tunele simple (IPIP, EoIP); tunele 6to4 (IPv6 peste IPv4); VLAN conform
IEEE802.1q; Q-in-Q; VPN bazate pe MPLS;
 crearea de reţele fără fir, inclusiv: clienţi şi puncte de acces IEEE
802.11a/b/g/n; interogarea clienţilor; RTS/CTS; sisteme WDS; puncte de
acces virtuale (Virtual AP); cifrare WEP, WPA şi WPA2; liste de control a
accesului; roaming-ul clienţilor; WMM (Wireless Multimedia); protocolul
HWMP+ pentru reţele MESH; protocolul de rutare fără fir MME ş.a.;
 crearea de porţi HotSpot; suport RADIUS pentru autentificare şi
evidenţă;
 implementarea de servicii de calitate (Quality of Services – QoS),
inclusiv: limitarea ratei de transfer date pentru anumite adrese IP,
subreţele, protocoale, porturi, etc.; prioritizarea unor fluxuri de date;
partajarea echilibrată a traficului de date ş.a.;
 crearea de servere proxy (mandatare), pentru păstrarea de informaţii
privind resursele web accesate, în scopul sporirii operativităţii accesării
acestora, inclusiv: Proxy HTTP ordinar; proxy transparent; listă de acces
după sursă, destinaţie, URL şi metoda solicitată (i-barieră HTTP); listă de
acces cache; listă de acces direct (Direct Access List), pentru a specifica care
resurse de accesat direct şi care printr-un alt server proxy; facilitatea de
evidenţă a conectărilor (logging); suport proxy SOCKS; support proxy
părinte ş.a.
RouterOS dispune, de asemenea, de un set larg de instrumente de
administrare a reţelelor, inclusiv: ping; traceroute; testarea lăţimii de
bandă; detectarea pachetelor; torţă (torch); telnet; SSH; instrumente de
transmisie/recepţie de i-poştă şi SMS; instrumente de execuţie automată a
scripturilor; tabelul conexiunilor active; client şi server NTP; server TFTP;
support de redundanţă VRRP; SNMP pentru realizarea de grafuri şi
statistici; client şi server RADIUS ş.a.
3.4. Licențe RouterOS

Funcționalitățile RouterOS pot fi folosite dispunând de o licență, ce se
identifică printr-un șir de simboluri. Echipamentele Mikrotik au o licență
RouterOS preinstalată. Pentru folosirea RouterOS pe sisteme x86, este
necesară obținerea specială a unei licențe.
La 20 aprilie 2014, erau disponibile șase nivele de licență, specificate
prin numerele 0, 1, 3, 4, 5 și 6. Licența 0 servește pentru folosirea în regim
125
de demonstrare a funcționalităților RouterOS şi este fără plată; cea 1 este
fără plată, dar necesită înregistrarea prealabilă pe situl Web al Mikrotik;
cele 3-6 sunt cu plată. Funcționalitățile RouterOS, accesibile pentru fiecare
din licențele nominalizate, sunt prezentate în tabelul 3.1.
O licenţă este doar pentru o singură instalare, include 15 sau 30 de zile
de suport prin i-poştă, poate folosi un număr nelimitat de interfeţe şi nu
are limită de expirare. Licenţa de nivel 3 este una doar pentru staţii client
fără fir şi poate fi procurată doar în cantităţi relativ mari.
La instalare pe o unitate de memorie, RouterOS va formata partiția
respectivă și va deveni sistemul de operare implicit al dispozitivului în
cauză. Licenţa se stochează în cadrul înregistrării (Master Boot Record –
MBR) sau al sectorului (Master Boot Sector – MBS) de încărcare master a
unităţii de memorie. Dacă este nevoie de o nouă formatare a unui disc, pe
care este instalat RouterOS, atunci licenţa nu se va pierde doar dacă
RouterOS a fost instalat cu utilita Netinstall (vezi s. 4.9.2).
Odată instalat RouterOS pe dispozitiv, ultimul nu poate fi folosit şi în
alte scopuri. De asemenea, unitatea de memorie poate fi mutată de la un
sistem la altul, dar licenţa (vezi s. 3.4) de folosire a RouterOS nu poate fi
mutată pe o altă unitate de memorie. De exemplu, o cartelă CF cu
RouterOS instalat poate fi mutată de la un PC la altul şi RouterOS va
funcţiona, dar licenţa nu poate fi mutată de la o cartelă CF la alta. Dacă
este nevoie de RouterOS pe o altă unitate de memorie, atunci va trebui de
procurat o altă licenţă. În cazul că unitatea de memorie s-a deteriorat,
Mikrotik poate să înlocuiască licenţa pentru un cost nominal.
Realizarea unei singure instalări pentru fiecare licenţă, se asigură prin
generarea identificatorului produsului program (software ID). Generarea
acestui ID are la bază numărul de identificare (number ID) al produsului
program şi date specifice ale unităţii de memorie, pe care produsul (de
exemplu, RouterOS) se instalează.
Actualizarea capabilităţilor RouterOS deja instalate, nefiind limitată în
timp, depinde de versiunea sistemului şi nivelul licenţei. Regulile generale
aplicate în acest scop constau în următoarele: licenţele de nivel 3 (L3) şi 4
(L4) permit actualizarea RouterOS doar până la ultima actualizare a
versiunii următoare a sistemului, iar cele L5 şi L6 – permit folosirea a
următoarelor două versiuni. Astfel, versiunea v3 a RouterOS cu licenţă L3
sau L4 poate fi actualizată la cea v4, dar nu şi la cea v5, pe când versiunea
v3 cu licenţă L5 sau L6 poate fi actualizată atât la versiunea v4, cât şi la cea
v5.
126
Tabelul 3.1 Unele caracteristici ale licențelor RouterOS la 20 aprilie 2014 [1]
Nivelul licenței 0 1 3 (WISP CPE) 4 (WISP) 5 (WISP) 6 (Controller)
Fără Se cere
Preț Pe disc doar $45 $95 $250
cheie înregistrare
Upgrade to - lipsește ROS v7.x ROS v7.x ROS v8.x ROS v8.x
Suport inițial - - - 15 zile 30 zile 30 zile
Punct de acces 24 ore - - da da da
Client și punte fără fir 24 ore - da da da da
Protocoale RIP, OSPF și BGP 24 ore - da* da da da
Tunele EoIP 24 ore 1 fără limită fără limită fără limită fără limită
Tunele PPPoE 24 ore 1 200 200 500 fără limită
Tunele PPTP 24 ore 1 200 200 500 fără limită
Tunele L2TP 24 ore 1 200 200 500 fără limită
Tunele OVPN 24 ore 1 200 200 fără limită fără limită
Interfețe VLAN 24 ore 1 fără limită fără limită fără limită fără limită
Utilizatori activi HotSpot 24 ore 1 1 200 500 unlimited
Client RADIUS 24 ore - da da da da
Fire de așteptare 24 ore 1 fără limită fără limită fără limită fără limită
Proxy Web 24 ore - da da da da
Sesiuni active de gestionate 24 ore 1 10 20 50 fără limită
Numărul utilizatorilor KVM - 1 fără limită fără limită fără limită fără limită
*BGP este inclus doar pentru echipamente RouterBOARD.
127
Alte informaţii privind vizualizarea, obţinerea, actualizarea şi folosirea
licenţelor RuoterOS pot fi regăsite în s. 4.7.
3.5. Sistemul de operare MikroTik SwOS

Sistemul de operare SwOS este destinat gestionării funcţionării
comutatoarelor Mikrotik. Versiunile SwOS suportate pentru comutatoare:
RB250GS – începând cu SwOS v1.0; RB260GS – începând cu SwOS v1.7;
RB260GSP – începând cu SwOS v1.11.
SwOS poate fi configurat printr-un explorator Web. Pe lângă realizarea
funcţionalităţilor unui comutator (switch), SwOS permite gestiunea înaintării
pachetelor port-la-port, controlul fluxurilor de difuzare (broadcast storm
control), aplicarea filtrelor MAC, configurarea VLAN, trafic oglindă, limitarea
lăţimii de bandă şi ajustarea unor câmpuri ale antetelor cadrelor MAC sau
pachetelor IP.
3.6. Monitorul de rețea Dude

Pentru gestionarea eficientă a reţelelor, Mikrotik oferă monitorul de reţea
Dude. Acesta poate rula în mediul Linux Wine, MacOS Darwine şi Windows şi
poate fi preluat fără plată de la adresa www.mikrotik.com/thedude.
Fiind uşor de instalat şi utilizat, Dude dispune de aşa funcţionalităţi ca:
 scanarea automată a tuturor entităţilor unei subreţele specificate cu
identificarea caracteristicilor acestora;
 alcătuirea automată a schemei reţelei în funcţiune;
 adăugarea de componente într-o schemă de reţea în funcţiune şi crearea
de scheme de reţea proprii;
 monitorizarea şi evidenţa serviciilor oferite, a utilizării dispozitivelor şi a
legăturilor între acestea;
 alerta administratorului de reţea în cazuri de probleme cu unele servicii;
 suportă monitorizarea SNMP, ICMP şi DNS a monitorizarea respective;
 accesul direct la instrumente de control distante pentru gestiunea
componentelor reţelei;
 suportă clientul local şi serverul distant Dude.
Toate aceste funcţii Dude le poate îndeplini nu doar referitor la entităţile
gestionate de RouterOS, ci referitor la toate entităţile accesibile prin ping sau
care oferă informaţii SNMP.
Comod, pentru a face cunoştinţă cu funcţionalităţile Dude, este Sistemul
demo Dude al Mikrotik, care poate fi accesat, printr-o conexiune securizată
Dude, la adresa 159.148.147.209.
Alte informaţii privind monitorul Dude pot fi regăsite la adresa
www.mikrotik.com/thedude.
128
4. INTRODUCERE ÎN FOLOSIREA RouterOS
4.1. Accesarea RouterOS
4.1.1. Aspecte generale de accesare şi gestiune a RouterOS
Echipamentele Mikrotik au sistemul RouterOS preinstalat. Reinstalarea
Router OS pe un echipament Mikrotik sau instalarea acestuia pe un PC sunt
descrise în s. 4.9.
Pentru accesarea şi gestiunea/configurarea funcţionalităţilor RouterOS, fie
că acesta este instalat pe un ruter Mikrotik sau pe un PC, acţiunile de urmat
sunt similare. Există câteva alternative în acest scop: folosirea aplicaţiei
WinBox (MAC-WinBox – pentru calculatoarele companiei Apple); folosirea
unui explorator Web (WebFig); din linia de comandă a calculatorului printr-o
interfaţă serială, Telnet sau SSH (Secure Shell) ş.a.
În secţiune sunt descrise acţiunile necesare privind: conectarea fizică a
unui calculator la ruter, inclusiv printr-un cablu Null-Modem; descărcarea
Winbox şi a altor produse program ale Mikrotik; descrierea generală a
WinBox; caracterizarea succintă a utilitei WebFig şi a mijloacelor de acces şi
configurare a funcţionalităţilor ruterului de la consola calculatorului printr-un
port serial, SSH şi Telnet.
4.1.2. Conectarea fizică PC-ruter
Un PC poate fi conectat la un ruter printr-un cablu pentru reţele Ethernet
(UTP sau fibră optică), printr-un cablu Null-Modem printr-o legătură fără fir
respectivă ş.a. Cablul Null-Modem (fig. 4.1) serveşte pentru interconectarea a
două echipamente terminale de date (calculator, terminal, ruter, imprimantă,
etc.) prin intermediul a două porturi seriale. Acesta inversează la capete liniile
de transmitere şi recepţie a datelor, pentru a permite comunicarea directă pe
două căi între echipamentele interconectate, la cerinţe minime de
configurare. Se foloseşte, de obicei, pentru
reinstalarea de produse program şi, de
asemenea, în scopuri experimentale
pentru emularea conexiunii respective; dar
nu poate fi folosit, de exemplu, pentru
conectarea la Internet. Cablul Null-Modem Fig. 4.1. Un cablu Null-Modem.
poate fi aplicat şi pentru reinstalarea RouterOS, folosind utilita Netinstal (vezi
s. 4.9.3).
În această lucrare se va folosi conectarea PC-ruter prin cablu UTP (fig. 4.2).
129
Wi
nB
ox
Ruter
Cablu UTP
Fig. 4.2. Conectarea calculatorului la ruter.
4.1.3. Descărcarea iprogramelor Mikrotik

Pe lângă sistemele de operare RouterOS şi SwOS, Mikrotik livrează şi
diverse instrumente şi utilite, o parte din care sunt specificate în tabelul 4.1.
Tabelul 4.1. Unele instrumente şi utilite Mikrotik
Produs program Destinaţie
WinBox Configurare RouterOS
Netinstal Instalare RouterOS
Dude Monitorizare reţele
Wireless link calculator Calcularea probabilităţii legăturilor fără fir
Trafr Cititor de trafic detectat pentru distribuitorii de Linux
BTest Testarea lăţimii de bandă pentru Windows
Neighbour Detectare vecini pentru Windows
Atheros Drivere pentru cartele fără fir RouterBOARD
Produsele program ale companiei Mikrotik, inclusiv RouterOS şi SwOS, pot
fi descărcate de la adresa www.mikrotik.com/download. Pentru această
lucrare, se va descărca utilita WinBox (fig. 4.3).
Utilita WinBox poate fi descărcată și de pe orice ruter Mikrotik cu adresă IP
publică, la care utilizatorul are acces prin Internet cu drepturi de
administrator. În acest scop, în câmpul pentru URL al exploratorului Web, se
specifică adresa IP a ruterului în cauză. Se va afișa pagina de start a sistemului
RouterOS de pe acel ruter (fig. 4.4).
După specificarea numelui de conectare şi a parolei şi intrarea în sistem,
prin clic pe pictograma Winbox pe calculator se va descărca fişierul
winbox.exe.
4.1.4. Descrierea generală a WinBox
4.1.4.1. Destinația WinBox
WinBox este o utilită, cu interfaţă grafică, de administrare a RouterOS.
Aceasta rulează pe Windows (Win32), dar poate rula şi pe Linux sau MAC OSX
folosind Wine (Windows Emulator, ulterior redenumit Wine Is Not an
130
Descărcare
……………………
Utilita WinBox
Fig. 4.3. Descărcarea produselor program ale Mikrotik.

Emulator)1. Prin WinBox pot fi accesate majoritatea funcţionalităţilor de
configurare a RouterOS, excepţie fiind unele funcţii de configurări avansate, de
exemplu modificarea adresei MAC a unei
interfeţe.
WinBox este un program autonom,
executabil. După descărcare pe calculator
(vezi s. 4.1.3), acesta nu necesită instalare
specială, lansându-se prin dublu-clic pe
numele fişierului winbox.exe (vezi s. 4.1.3).
Funcţiile interfeţei WinBox sunt foarte
apropiate de cele de Consolă RouterOS
Fig. 4.4. Fragment din pagina de
(vezi s. 4.1.6). Mai mult ca atât, prin
referinţă a unui ruter MikroTik.
WinBox poate fi accesat şi regimul
Terminal de gestiune a RouterOS din linia de comandă a acestuia (vezi s
4.1.4.5), cu aceleaşi funcţii ca şi cele de Consolă RouterOS.
Implicit, RouterOS rulează sesiunile WinBox la portul 8291.
4.1.4.2. Prima conectare la ruter folosind WinBox
Către prima încercare de conectare la ruter, ultimul poate să nu fie încă
configurat, privind atribuirea unei adrese IP interfeţei de acces. În asemenea
cazuri, prin WinBox, ruterul poate fi accesat folosind adresa MAC a interfeţei
în cauză.
De menţionat, totodată, că accesul RouterOS, folosind o adresă MAC,
trebuie aplicat doar pentru a atribui o adresă IP interfeţei de acces sau dacă nu
1 Wine este o aplicaţie cu sursă deschisă, care permite rularea pe sistemele de operare
de tip UNIX a aplicaţiilor elaborate pentru sistemul Windows.
131
se cunoaște configurarea ruterului. Nu se recomandă aplicarea acestei căi,
dacă ruterul poate fi accesat folosind o adresă IP. Sesiunile MAC folosesc
difuzarea în reţea şi nu sunt sigure la 100% [1]. După configurarea adresei IP,
este necesar de ieşit din RouterOS şi de accesat ruterul din nou, folosind
adresa IP respectivă. Procedura de atribuire a unei adrese IP interfeței de
acces a ruterului de la PC este descrisă în s. 4.2.2.
Pentru conectarea la ruter după adresa MAC, mai întâi se lansează WinBox,
rezultatul fiind afişarea ferestrei din figura 4.5 de acces a ruterului ce rulează
RouterOS. Dacă ruterul se accesează pentru prima dată, în câmpul Connect To
va lipsi adresa, în câmpul pentru numele utilizatorului (Login) va fi valoarea
implicită admin, înscrisă în mod automat de WinBox, iar câmpul pentru parolă
(Password) va fi vid, necerându-se vreo parolă.
Fig. 4.5. Fereastra WinBox de acces a RouterOS.

Butoanele şi câmpurile ferestrei de acces a ruterului (fig. 4.5) au
următoarea semnificaţie:
 Connect To – adresa IP sau MAC a ruterului de accesat;
 Connect – conectarea la ruter;
 Login – numele utilizatorului pentru autentificare;
 Password – parola utilizată pentru autentificare;
 – descoperirea şi afişarea echipamentelor MNDP sau CDP vecine1
ruterului adiacent la PC. Prin clic pe acest buton (fig. 4.6a), WinBox va
folosi pachete MNDP (Mikrotik Neighbor Discovery Protocol – protocolul
Mikrotik de descoperire a vecinilor) sau CDP (Cisco Discovery Protocol),
trimise de ruter în reţeaua locală, şi va afişa o casetă de dialog, suprapusă
peste fereastra iniţială, cu specificarea în aceasta a unor informaţii
despre ruterele vecine (câte o linie pentru fiecare ruter), inclusiv adresa
MAC a interfeţelor de acces a acestora (fig. 4.6b);
1 Se consideră vecine acele echipamente, care au conectivitate de nivel 2 OSI între ele.
132
 Save – salvarea adresei, a numelui de conectare (login), a parolei şi a
notării privind ruterul, adresa interfeţei căruia este în câmpul Connect To.
Lista unor asemenea înregistrări se va afişa în partea de jos a ferestrei
WinBox de acces (fig. 4.6c);
 Remove – ştergerea înregistrării selectate din lista celor salvate;
 Tools – accesul unor aşa instrumente ca: ştergerea tuturor înregistrărilor
din listă, ştergerea memoriei cache de pe discul local, importul adreselor
din fişierul wbx sau exportul acestora în fişierul wbs;
 Keep Password1 – dacă nu este bifat, parola nu va fi salvată în listă;
 Secure Mode – dacă este bifat, WinBox va folosi cifrarea TLS pentru
securizarea sesiunii;
 Load Previous Session – dacă este marcat, WinBox va încerca să
restabilească toate ferestrele deschise în sesiunea precedentă;
 Note – identitatea (numele de identificare) ruterului ce va fi salvată, la
apăsarea butonului Save, în lista din partea de jos a ferestrei (în fig. 4.6c
– MikroTik). Ca identitate a ruterului ar fi bine de folosit o informaţie
a)
b)
c)
Lista înregistrărilor
salvate
Fig. 4.6. Acţiunile de accesare MAC a ruterului folosind WinBox.

specifică, deoarece aceasta apare în mai multe situaţii.
1 Parolele sunt salvate în text deschis. Oricine cu acces la sistemul de fişiere va putea să
să afle aceste parole.
133
Astfel, în continuare, se va executa clic pe butonul cu puncte de suspensie
(fig. 4.6a), ceea ce va conduce la afişarea de către WinBox a casetei de
dialog, suprapuse peste fereastra iniţială, cu specificarea în aceasta a unor
informaţii despre ruterul vecin RB951-2n, inclusiv a adresei MAC a interfeţei
de acces a acestuia (fig. 4.6b).
Notă. Aici butoanele de acţionat în interfaţa WinBox sunt împrejmuite cu un bloc
, liniile – subliniate cu un segment , iar consecutivitatea acţiunilor –
specificată de săgeţi .
Prin clic pe adresa MAC (fig. 4.6b) sau cea IP (dacă aceasta este în listă),
WinBox va însera în câmpul Connect To adresa respectivă (în cazul dat cea
MAC) a interfeţei de acces a ruterului (fig. 4.6c). Numele implicit de conectare
la ruter prin WinBox este admin și, la prima accesare a ruterului, nu se cere
vreo parolă (câmpul Password este vid şi nu trebuie modificat).
În sfârşit, apăsând butonul Connect, utilizatorul va obţine acces la
RouterOS, afişându-se interfaţa de lucru a WinBox (fig. 4.7).⁪
Adresă Clic dreapta

Nume utilizator pentru a
adăuga noi
câmpuri Modelul RB
Ascunderea parolelor PPP
Traficul WinBox
Modul securizat
Zona de lucru
Bara de meniuri
Fig. 4.7. Interfaţa de lucru a WinBox.

Astfel, pentru conectarea la ruter folosind WinBox, în câmpul Connect To
se specifică adresa IP a ruterului (sau cea MAC dacă adresa IP nu este
cunoscută), în câmpul Login se înscrie numele utilizatorului și în cel Password
– parola, iar apoi se execută clic pe butonul Connect.
134
4.1.4.3. Interfaţa de lucru a WinBox
Interfaţa de lucru a WinBox conţine:
 bara de titlu, în partea de sus, care include informaţii despre ruter;
 bara cu instrumente, urmează imediat mai jos de bara de titlu, în care
utilizatorul poate adăuga aşa câmpuri informaţionale ca folosirea
procesorului (CPU), ora ş.a.;
 bara de meniuri, în partea stângă, care include toate meniurile şi
submeniurile disponibile. Lista acestora se modifică, în funcţie de
pachetele (packages) RouterOS instalate;
 zona de lucru, în care se deschid ferestrele meniurilor activate.
În bara de titlu, informaţia se prezintă pe o singură linie în următorul
format:
[nume utilizator][@[adresa IP sau MAC a ruterului] ([ID ruter]) – WinBox
[versiune RouterOS] on [modelul RouterBoard] ([platforma])
În figura 4.7, ID ruter este MikroTik, modelul RB este RB951-2n, iar
platforma este mipsbe.
Butoanele undo şi redo , din partea stângă a barei cu instrumente,
servesc pentru întoarcerea la pasul precedent sau, respectiv, revenirea la
starea următoare. În partea dreaptă a barei se regăsesc: indicatorul de trafic
WinBox de culoare verde ; indicatorul stării de securizare , care specifică
dacă sesiunea WinBox foloseşte sau nu cifrarea TLS; caseta Hide password
care dacă este bifată, atunci toată informaţia senzitivă, de exemplu parolele
secrete, este înlocuită cu simboluri ‘*’.
4.1.4.4. Zona de lucru și ferestrele derivate ale WinBox
Toate ferestrele derivate ale meniurilor și submeniurilor ferestrei
principale a WinBox se afișează în cadrul zonei de lucru a ultimei (fig. 4.7 din s.
4.1.4.2), fără posibilitatea de tragere a acestora înafara acestei zone. Dacă
părți ale cel puțin uneia din ferestrele derivate sunt în afara granițelor vizibile
ale zonei de lucru, atunci în mod automat va apărea, de obicei, bara de
derulare verticală și/sau cea orizontală, ceea ce va permite vizualizarea tuturor
informațiilor necesare din aceste ferestre (fig. 4.8). Fereastra poate fi, de
asemenea, deplasată prin tragere cu şoricelul, cursorul fiind pe bara de titlu a
ferestrei.
Fiecare fereastră derivată are propria bară cu instrumente, care poate
include așa butoane ca (vezi, de exemplu, fig. 4.14 din s. 4.2.4):
- adăugarea unui element nou în listă;
- ștergerea din listă a elementului selectat;
- activarea (enable) elementului selectat;
135
- dezactivarea (disable) elementului selectat;
- adăugarea sau editarea unui comentariu;
- permiterea sortării elementelor în funcție de diverși parametri.
WinBox foloseşte de asemenea diverse culori pentru specificarea unor stări
aparte ale echipamentelor sau opţiunilor, inclusiv culorile:
 roşie – regula sau opţiunea este nevalabilă (invalid). De exemplu, o
regulă de i-barieră devine nevalabilă după eliminarea interfeţei
respective;
 albastră – ruta inactivă din două rute către aceeaşi destinaţie, cea activă
fiind de culoare neagră;
 aldină – înregistrările, într-o interfaţă fără fir, privind canalele standard
pentru domeniul reglatoriu (regulatory domain) selectat.
O altă particularitate a WinBox constă în folosirea unei casete mici de
formă pătrată alături de unele opţiuni de configurare. Aceasta poate fi
confundată cu o casetă de bifare, care are aceeaşi formă. La încercarea de a
bifa o asemenea casetă, în casetă se va înscrie semnul exclamării ! .
Destinaţia acestei casete constă în negarea logică a opţiunii respective. Un
exemplu este prezentat în figura 5.20 din s. 5.5.3 (parametrul Dst. Address).
Aproape toate ferestrele derivate conțin, în partea dreaptă a barei cu
instrumente, un câmp de intrare pentru căutarea rapidă, în care inițial este
scris Find. Textul, înscris în acest câmp, este căutat și evidențiat în cadrul
tuturor înregistrărilor ferestrei respective (vezi, de exemplu, fig. 4.14 din s.
4.2.3).
WinBox permite gestionarea afișării informațiilor în cadrul ferestrelor
derivate, inclusiv: configurarea listei coloanelor ce se afișează (Show
Columns); setarea modului detaliat de prezentare a informațiilor (Detail
Mode); listarea elementelor înregistrărilor pe categorii (Show Categories) ș.a.
O bună parte din aceste funcționalități devin accesibile prin clic-dreapta pe
elementul în cauză, afișându-se meniul contextual respectiv, din care se va
activa opțiunea necesară.
De asemenea, WinBox permite trimiterea și descărcarea fișierelor către/de
la ruter prin tragere cu şoricelul (drag & drop), monitorizarea în timp real a
traficului la o interfață, fir de așteptare sau i-barieră dată ș.a.
4.1.4.5. Gestiunea RouterOS din linia de comandă Terminal
În unele cazuri, îndeosebi pentru administratorii de reţea experimentaţi,
este mai comodă gestiunea şi configurarea funcţionalităţilor RouterOS din linia
de comandă a acestuia. Mai mult ca atât, unele configurări pot fi realizate doar
din linia de comandă.
136
Configurarea ruterului din linia de comandă se efectuează cu folosirea unei
diversităţi largi de instrucțiuni ale RouterOS (vezi s. 4.1.6). Acest regim de lucru
se foloseşte, de asemenea, pentru a scrie scripturi.
Accesul şi gestiunea RouterOS din linia de comandă (consolă) pot fi
efectuate de la terminale textuale, conectate la distanță, folosind portul serial,
Telnet sau SSH, sau direct, folosind un monitor și o tastatură (vezi s. 4.1.6).
Aceste funcţii pot fi realizate, de asemenea, prin WinBox, folosind fereastra
Terminal. Prin WinBox, în acest scop, se va executa clic pe meniul New
Terminal, deschizându-se fereastra derivată Terminal cu prompterul liniei de
comandă (fig. 4.8). Acest prompter are formatul
[nume_utilizator@nume_ruter] >,
unde nume_utilizator este numele utilizatorului, folosit pentru autentificare la
accesarea ruterului, iar nume_ruter este numele ruterului, denumit şi
identitatea ruterului (router identity), descris în s. 4.2.6. În exemplul din figura
4.8, aceste nume sunt cele implicite ale RouterOS şi anume admin şi MikroTik,
respectiv.
Fig. 4.8. Activarea/dezactivarea Safe Mode din linia de comandă.
Sistemul de comenzi şi aplicarea lor sunt succint caracterizate în s. 4.1.6.4.

4.1.4.6. Regimul Safe Mode
În bara cu instrumente a interfeţei de lucru a WinBox, după butoanele
undo şi redo urmează butonul Safe Mode (fig. 4.7). Acest buton serveşte
pentru activarea/dezactivarea, prin clic cu şoricelul, a regimului Safe Mode. La
137
activare, culoarea butonului devine mai închisă, iar la dezactivare aceasta
coincide cu cea a fundalului barei cu instrumente.
Toate setările efectuate în acest regim nu se salvează pentru o viitoare
sesiune de lucru. Dacă, în timpul lucrului în regim Safe Mode, au fost efectuate
setări nereuşite, de exemplu ruterul a devenit inaccesibil, utilizatorul
întotdeauna poate reveni la setările sistemului de până la intrarea în Safe
Mode, prin încheierea sesiunii curente şi lansarea unei noi sesiuni de lucru.
Pentru a păstra setările, efectuate în timpul lucrului în regim Safe Mode, este
necesar de a ieşi din acest regim înainte de încheierea sesiunii curente de
lucru în WinBox.
Astfel, regimul Safe Mode poate fi folosit în modul următor. Se activează
Safe Mode, apoi se efectuează setările necesare. Dacă setările sunt nereuşite,
anularea lor se poate efectua prin încheierea sesiunii curente (închiderea
WinBox acţionând Exit sau butonul × din colţul din dreapta sus al barei de
titlu al ferestrei WinBox). Pentru continuarea lucrului, se va lansa o nouă
sesiune. Dacă setările sunt reuşite, atunci pentru salvarea lor se va dezactiva
regimul Safe Mode. prin apăsarea din nou a butonului Safe Mode. Apoi se
poate intra iarăşi în Safe Mode şi efectua noi setări, etc.
Activarea/dezactivarea regimului Safe Mode poate fi efectuată şi din linia
de comandă a utilitei Terminal a RouterOS. În acest scop în interfaţa de lucru a
WinBox, se va executa clic pe meniul New Terminal. Se va deschide fereastra
derivată Terminal cu prompterul liniei de comenzi. Pentru activarea regimului
Safe Mode, se va tasta CTRL+X (trei taste). Pentru salvarea noilor setări şi
părăsirea regimului Safe Mode, se va apăsa din nou CTRL+X. Rezultatul
ambelor acestor acţiuni consecutive este prezentat în figura 4.8.
După prima tastare CTRL+X, se afişează [Safe Mode taken], care
informează activarea regimului Safe Mode, iar după a doua tastare CTRL+X se
afişează [Safe Mode released], care informează dezactivarea regimului Safe
Mode.
Pentru părăsirea regimului Safe Mode, fără păstrarea noilor setări, se va
tasta CTRL+D. Rezultatul va fi închiderea ferestrei Terminal.
Folosirea regimului Safe Mode este îndeosebi oportună pentru începători.
4.1.5. Utilita WebFig
WebFig este o utilită Web a RouterOS, alternativă la WinBox, cu
funcționalități similare şi este independentă de platforma procesorului
ruterului. Folosind WebFig, pot fi realizate aşa acţiuni ca:
 configurarea funcţionalităţilor ruterului;
 monitorizarea ruterului, inclusiv afişarea informaţiei privind starea
curentă, rutarea, diverse statistici, etc.;
 depanarea diverselor situaţii de nereguli în funcţionarea ruterului.
138
Utilita este accesibilă direct pe ruter prin intermediul unui explorator Web
de pe un calculator sau alte dispozitive, inclusiv mobile. Pentru aceasta este
necesară cunoașterea adresei IP, a numelui de utilizator şi parolei de acces a
ruterului respectiv. După deschiderea paginii Web de referinţă a ruterului (fig.
4.4), se vor specifica numele de utilizator şi parola de acces la ruter, ca şi la
folosirea WinBox. Va urma deschiderea ferestrei de lucru a WebFig (fig. 4.9).
Fig. 4.9. Interfaţa utilitei WebFig.
Comparând fig. 4.9 şi 4.7, se poate observa că barele meniurilor principale

la WebFig şi WinBox aproape coincid: suplimentar la WebFig sunt aşa meniuri
ca Design Skin, End-User License şi Graphs, iar la WinBox – cel MetaROUTER.
Se poate afirma cu certitudine că dacă se cunoaşte folosirea WinBox, atunci cu
uşurinţa va fi posibilă adaptarea la folosirea şi a utilitei WebFig.
Alte informații privind funcţionalităţile şi folosirea WebFIG pot fi regăsite la
adresa wiki.mikrotik.com/wiki/Manual:Webfig.
139
4.1.6. Accesul şi gestiunea RouterOS de la consolă
4.1.6.1. Noţiuni generale
Accesul și gestiunea RouterOS de la consolă se realizează cu folosirea unor
terminale textuale, conectate la distanță folosind portul serial, Telnet, SSH sau
fereastra de consolă Terminal în WinBox, sau direct folosind un monitor și o
tastatură. Consola este folosită, de asemenea, pentru a scrie scripturi.
Consola permite configurarea ruterului din linia de comandă, folosind o
diversitate largă de instrucțiuni ale RouterOS.
Pentru conectarea la ruter prin Telnet, SSH sau fereastra Terminal în
WinBox, este necesară cunoașterea adresei IP a ruterului, a numelui de
utilizator și a parolei. Dacă accidental sunt dezactivate toate porturile Ethernet
ale ruterului, accesul la ruter prin Telnet, SSH sau fereastra Terminal în
WinBox nu este posibil. Ultima şansă de conectare la ruter este folosirea
portului serial al PC (RS-232), a unui cablu Null-Modem între PC şi ruter şi a
utilitei de terminal serial a sistemului de operare.
4.1.6.2. Accesul la ruter folosind Telnet
Sistemul de operare Windows dispune de client Telnet. Pentru acces
Telnet în Windows, se va executa /Start/Run/cmd.
Notă. Aici şi în continuare activarea consecutivă, pentru executarea unor funcţii, se
va nota /funcţia1/funcţia2/funcţia3/funcţia4, funcţia5 – valoare5, funcţia7 – valoare7,
funcţia8/…/funcţiak. Aici:
 primul caracter oblică dreapta “/” specifică meniul principal în WinBox, pagina de
referinţă a unui sit Web sau suprafaţa de lucru a sistemului Windows;
 funcţiai este denumirea meniului, a filei unei ferestre, a unei casete de dialog sau
a unui buton activat de către utilizator prin clic cu şoricelul;
 funcţiaj este denumirea unei ferestre sau casete de dialog afişate de către
RouterOS, în rezultatul activării de către utilizator a unei funcţii cu numele
funcţiaj-1 (meniu, înregistrare, buton, etc.) şi funcţiaj ≠ funcţiaj-1, sau este
denumirea unui parametru în cadrul unei ferestre, file sau casete de dialog. Dacă
funcţiaj = funcţiaj-1, atunci aceasta poate să nu fie specificată;
 valoarei este valoarea unui parametru în cadrul unei ferestre, file sau casete de
dialog, scrise sau selectate, de către utilizator, dintr-o listă;
 prin caracterul “/” se delimitează denumirile meniurilor, ferestrelor, filelor şi
casetelor de dialog, iar diversele denumiri de funcţii în cadrul unei ferestre, file
sau casete de dialog se delimitează prin virgulă;
 denumirile de funcţii şi valori sunt unice în fereastra, fila, meniul, caseta de dialog
sau lista derulantă afişată respectivă.
Exemplul 4.1. Fie avem notarea /Wireless/Wireless Tables/Interfaces,
dublu-clic wlan1/Interface <wlan1>/Wireless, Mode – station, Scan/Scanner
(Running), SSID – APprof, Connect.
140
Această notare semnifică activarea de către utilizator a meniului Wireless,
rezultatul fiind afişarea de către RouterOS a ferestrei Wireless Tables. Apoi, în
cadrul acestei ferestre, utilizatorul deschide, prin clic cu şoricelul, fila
Interfaces, în cadrul căreia utilizatorul execută dublu clic pe înregistrarea
wlan1. În rezultat RouterOS afişează fereastra Interface <wlan1>, în cadrul
căreia utilizatorul deschide fila Wireless. Mai apoi, în cadrul acestei file, pentru
parametrul Mode, utilizatorul selectează, dintr-o listă de opţiuni, valoarea
station şi apasă butonul Scan. Router OS afişează fereastra Scanner (Running),
în cadrul căreia, pentru parametrul SSID, utilizatorul selectează valoare
APprof, iar apoi apasă butonul Connect.
Unicitatea denumirilor de funcţii şi valori în fereastra, fila, meniul, caseta
de dialog sau lista derulantă afişată respectivă face ca interpretarea unor
asemenea notari să fie univocă şi relativ uşoară.
Astfel, acţionând /Start/Run/cmd, se va afişa prompterul interpretorului
de comenzi al sistemului Windows. Aplicând la prompter comanda
C :\>telnet 168.92.34.1
se va stabili conexiunea cu ruterul ce are adresa IP 168.92.34.1. După
stabilirea conexiunii, ruterul va solicita informaţiile de autentificare: numele
de utilizator şi parola. La specificarea corectă a acestor informaţii, se va
deschide sesiunea Telnet cu ruterul. Ulterior, la prompter pot fi aplicate
diverse comenzi RouterOS, inclusiv: ping, traceroute, ip route print, interface
print, etc. RouterOS rulează sesiunile Telnet la portul Telnet implicit 23.
De menţionat, totodată, că sesiunile Telnet sunt, de obicei, nesigure,
deoarece nu folosesc cifrarea datelor şi nici a numelui de utilizator sau a
parolei; fiind interceptate, asemenea date pot fi folosite în detrimentul
utilizatorului. Securizate sunt sesiunile SSH.
4.1.6.3. Accesul la ruter folosind SSH
RouterOS rulează sesiunile SSH la portul SSH standard 22. Accesul SSH
presupune folosirea unui client SSH. Un asemenea client textual, cu aplicarea
comenzilor din linia de comandă, există atât în sisteme de tip UNIX, cât şi în
Windows. Folosirea lor pentru acces la RouterOS este similară celui Telnet
(vezi s. 4.1.6.1).
Există şi clienţi SSH fără plată cu interfaţă grafică, inclusiv Putty şi
OpenSSH.
4.1.6.4. Sistemul de comenzi al RouterOS
RouterOS se bazează pe un set larg de instrucţiuni (comenzi). Pentru
facilitarea însuşirii şi folosirii lor, acestea sunt grupate şi organizate într-o
structură ierarhică de meniuri, care corespunde, cu mici excepţii, celei folosite
în WinBox şi WebFig, deşi este mai largă. Numele unui meniu/submeniu
141
reflectă informaţia de configurare accesibilă, de exemplu routing ospf, system
console sau ip firewall. Locul de specificare a comenzii unui submeniu poate fi
accesat succesiv în lanţul de meniuri-submeniuri respectiv, ca apoi comanda să
fie specificată, sau ea poate fi specificată ca o singură comandă, indicând
preliminar lanţul de meniuri-submeniuri în cauză.
Exemplul 4.2. Fie [20_bit@20_ion] > este prompterul liniei de comandă.
Atunci comanda de afişare a rutelor tabelului de rutare poate fi specificată ca
[20_bit@20_ion] > ip route print
sau ca două comenzi consecutive
[20_bit@20_ion] > ip route
[20_bit@20_ion] ip route> print
După lansarea comenzii ip route, sistemul realizează doar deplasarea în
arborele de meniuri, route fiind un submeniu al meniului ip şi nu o comandă
de executat. Totodată, sistemul specifică prin prompter locul curent în
arborele de meniuri, cel [20_bit@20_ion] > fiind înlocuit cu [20_bit@20_ion]
ip route>. De menţionat că în WinBox comenzii ip route îi corespunde lanţul
de meniuri/subemniuri/IP/Routes.
Pentru revenirea, de la starea curentă, în meniul rădăcină al arborelui de
comenzi, la prompter se specifică comanda reprezentată de caracterul oblică
dreapta (/).
Exemplul 4.3:
[20_bit@20_ion] > ip firewall
[20_bit@20_ion] /ip firewall> nat
[20_bit@20_ion] /ip firewall nat> /
[20_bit@20_ion] >
Pentru deplasarea în arbore cu un nivel mai sus, spre meniul rădăcină, la
prompter se specifică comanda reprezentată de două caractere punct (..).
Exemplul 4.4:
[20_bit@20_ion] > ip firewall
[20_bit@20_ion] /ip firewall> nat
[20_bit@20_ion] /ip firewall nat> ..
[20_bit@20_ion] /ip firewall>
Comenzile / şi .. pot fi folosite pentru lansarea în execuţie de comenzi de la
nivelele reprezentate de acestea şi fără deplasarea în arborele de meniuri. În
asemenea cazuri, după / şi .. se specifică comanda de executat. Un exemplu
este prezentat în figura 4.10.
142
Fig. 4.10. Lansarea unei comenzi de la un nivel mai sus în arbore.
După lansarea comenzii /ip firewall> .. address print, sistemul a afişat
adresele IP ale interfeţelor ruterului. Prompterul din ultima linie arată că locul
în arbore nu s-a modificat, este tot /ip firewall>.
RouterOS poate facilita introducerea comenzilor în linia de comandă. În
acest scop, după introducerea începutului unei comenzi, se apasă tasta [Tab].
Dacă acest început este unic pentru setul de comenzi, atunci sistemul va
completa comanda, urmată de un caracter Spaţiu. Dacă însă acest început nu
este unic, atunci prima apăsare a tastei [Tab] nu va avea nici un efect, însă
după a doua apăsare a acesteia, sistemul va afişa toate completările posibile în
formă compactă. Utilizatorul poate selecta varianta necesară.
O altă cale de accelerare a introducerii comenzilor constă în specificarea
doar a începutului unic al acestora şi cel al argumentelor lor în contextul
respectiv. Dacă în specificare nu sunt erori, atunci sistemul va accepta
comanda. Mai mult ca atât, în anumite condiţii, sistemul poate să accepte
şiruri de caractere nu obligatoriu la începutul comenzilor sau ale atributelor
acestora.
De rând cu comenzile specifice, RouterOS include şi un şir de comenzi
comune pentru o mare parte din meniuri, inclusiv: add, comment, disable,
edit, enable, export, get, find, move, print, set şi remove. În linii mari,
destinaţia unora din aceste comenzi este următoarea:
add – adaugă un nou element (înregistrare, item, etc.), cu valoarea
specificată de utilizator, de regulă la sfârşitul listei acestora. Are, de obicei,
aceleaşi argumente ca şi comanda set. Parametri comuni al comenzii sunt:
copy-from – copierea unui element existent;
place-before – amplasarea noului element înaintea unui element existent
specificat;
disabled – gestionează starea activată/dezactivată (enabled/disabled) a
noului element adăugat;
comment – deţine descrierea noului element adăugat;
edit – este asociată cu comanda set. Se foloseşte pentru editarea valorilor
parametrilor, dar îndeosebi ale celor ce conţin mult text, de exemplu ale
scripturilor. Pentru îndeplinirea comenzii, se lansează un editor de texte;
143
find – regăsirea tuturor elementelor cu aceleaşi valori specificate ale
argumentelor. Are, de obicei, aceleaşi argumente ca şi comanda set;
move – modifică ordinea elementelor în listă. Ca parametri servesc:
- primul argument specifică elementele de modificat;
- al doilea argument specifică elementul, înaintea căruia de plasat
elementele de modificat. Dacă al doilea element lipseşte, elementele
de modificat se plasează la sfârşitul listei;
print – afişează informaţiile accesibile, în funcţie de nivelul comenzii în
arborele de meniuri/submeniuri. De exemplu, comanda /system clock print
afişează data şi timpul în sistem, iar cea /ip route print afişează informaţia
privind toate rutele. Parametri comuni ai comenzii sunt:
from – afişează doar elementele specificate;
where – afişează doar elementele ce corespund criteriilor specificate;
brief – forţează folosirea de către comanda print a formei tabelare de
afişare a informaţiilor;
detail – forţează folosirea de către comanda print a formei de afişare
parametru = valoare;
count-only – afişează numărul elementului;
file – copie conţinutul submeniului într-un fişier pe ruter;
interval – actualizează ieşirea comenzii print cu fiece interval ce urmează;
oid – afişează valoarea OID (Object Identifiers) pentru parametrii
(proprietăţile) accesibili de la SNMP;
without-paging – afişează informaţiile fără opriri după fiecare ecran
completat;
remove – şterge din listă elementele specificate;
set – modifică valorile parametrilor generali sau ale celor ale parametrilor
elementului. Are argumente cu nume ce corespund valorilor de modificat.
Pentru vizualizarea listei tuturor parametrilor, după specificarea comenzii se
tastează ? sau dublu [Tab].
RouterOS oferă asistenţă în folosirea comenzilor. Pentru apelare la
aceasta, după specificarea comenzii, se tastează ?.
Alte informații privind accesul și gestiunea RouterOS de la consolă pot fi
regăsite la adresa wiki.mikrotik.com/wiki/Manual:Console.
4.2. Conectarea la Internet prin ruter

4.2.1. Reţeaua de calculatoare de configurat
Pentru studierea de către un grup de utilizatori (grup de studenţi, de
cursanţi, etc.) a aspectelor de bază, privind conectarea unui calculator al unei
reţele locale la Internet, se va realiza o reţea experimentală, schema căreia
144
este prezentată în figura 4.11. În caz particular, grupul poate fi constituit şi
dintr-un singur utilizator.
Punct de acces Internet
Mijloace utilizator 1 Mijloace utilizator n
Wi ox
nB
tă
ox nB
Wi
ar
Ruter Ruter
Po
∙∙∙∙∙∙∙∙
Cablu UTP Cablu UTP
Fig. 4.11. Schema reţelei de calculatoare de creat.
Reţeaua include câte un calculator (PC) şi un ruter la fiecare utilizator şi un

ruter – poartă implicită, pentru conectarea mijloacelor de reţea ale
utilizatorilor la Internet. Calculatorul fiecărui utilizator trebuie conectat, printr-
un cablu UTP, la ruterul lui, iar ultimul se va conecta, printr-o legătură fără fir,
la ruterul-poartă implicită a rețelei locale, care, la rândul său, se va conecta la
Internet. Astfel, ruterul-poartă implicită va îndeplini şi funcţiile de punct de
access (access point – AP). Se va considera că ruterul-poartă implicită este deja
configurat şi a rămas de configurat doar calculatoarele şi ruterele utilizatorilor.
Pentru toţi utilizatorii, calculatoarele şi ruterele se configurează în mod
similar. Configurarea ţine, în primul rând, de adresarea calculatoarelor şi a
ruterelor utilizatorilor. De menţionat, totodată, că la setarea adreselor
dispozitivelor reţelei, se specifică adresa nu a unui calculator, ruter,
comutator, etc., ci a interfeţelor de reţea (adaptoarelor, cartelelor, porturilor)
ale acestora – interfeţe, la care sunt conectate medii (canale) de transfer date.
Mai mult ca atât, pentru ca să fie posibil transferul de date între două
dispozitive adiacente (unităţi conectate direct printr-un mediu de transfer
date), cele două interfeţe, interconectate nemijlocit de mediul de transfer
date respectiv, trebuie să fie în aceeaşi subreţea.
O subreţea cuprinde toate interfeţele dispozitivelor interconectate şi
mediile de transmisie între acestea. În cadrul unei subreţele, transferul de
date se efectuează în conformitate cu protocoalele de Nivel 2 OSI, adică cu
implicarea doar a protocoalelor de comutare (înaintare), dar nu şi al celor de
rutare a pachetelor. De aceea fiecare subreţea constituie un domeniu de
difuzare aparte. Aspectele adresării dispozitivelor unei subreţele de
145
calculatoare sunt descrise în s. 1.5.1. În schema din figura 4.11, mijloacele de
reţea ale fiecărui utilizator constituie o subreţea aparte.
Totodată, dacă schimbul de date între unităţile unei subreţele se
efectuează la Nivelul 2 OSI, atunci schimbul de date între ruterul unei
subreţele şi poarta implicită de conectare la Internet a acesteia se efectuează
la Nivelul 3 OSI, adică cu implicarea protocoalelor de adresare şi rutare IP.
Pentru configurarea mijloacelor de reţea ale unui utilizator al reţelei din
figura 4.11, sunt necesare aşa acţiuni ca:
 configurarea interfeţei de rețea a calculatorului utilizatorului;
 configurarea legăturii calculator-ruter utilizator;
 configurarea legăturii ruter utilizator-poartă implicită Internet;
 configurarea legăturii calculator utilizator-Internet.
În secțiune se vor descrie, pe parcurs, noțiunile și folosirea porții implicite
(default gateway), a clientului DHCP, a Translatorului de adrese de reţea
(Network Address Translation – NAT) ș.a.
4.2.2. Configurarea cartelei de rețea a calculatorului
Pentru setarea conectării PC la ruterul utilizatorului, este necesară
configurarea cartelei de reţea a calculatorului şi a celei a ruterului. În această
secţiune se va descrie configurarea cartelei de reţea a calculatorului, iar cea a
ruterului – în s. 4.2.3.
Dacă configurarea cartelei de reţea a calculatorului va fi una temporară,
experimentală, atunci pentru revenirea la setările anterioare, aceasta trebuie
înregistrată şi păstrată undeva aparte. De asemenea, dacă calculatorul are
configurat un port cu acces fără fir, acesta trebuie dezactivat, pentru a asigura
o singură conexiune PC-reţea.
Notă. La lucrările practice la curs, după încheierea experimentării configurărilor
respective folosind RouterOS, se va reveni la setările anterioare. În acest scop,
configurările se pot efectua în regimul Safe Mode (vezi s. 4.1.4.6).
Pentru a determina configurările de reţea existente la PC, în Windows se
va acţiona /Start/Control Panel/Network and Sharing Center/pictograma
reţelei sau dublu clic pe pictograma reţelei din bara de sarcini Windows, dacă
aceasta este prezentă: se va afişa o casetă de dialog similară celei din figura
4.12 cu starea conexiunii la reţeaua locală. În această casetă se va apăsa
butonul Properties, apoi în caseta ce se va afişa se va selecta opţiunea
Internet Protocol Version 4, iar ulterior se va apăsa butonul Properties. Ca
rezultat se va afişa caseta de dialog cu configurările cartelei de reţea a PC (fig.
4.13).
146
Fig. 4.12. Starea conexiunii PC-LAN. Fig. 4.13. Setarea cartelei de reţea a PC.
Din figura 4.13 se poate afla că:
 adresa IP (IP address) a calculatorului este: 172.20.24.1;
 masca de subreţea (Subnet mask) este 255.255.0.0. Această notare se
folosește în Windows, în UNIX o asemenea mască se notează /16 (în
format CIDR);
 adresa IP a porţii implicite (Default gateway) este 172.20.0.1. Ea
reprezintă adresa serverului sau a interfeței de reţea a ruterului, prin
care calculatoarele din rețeaua locală pot obţine legătura la o altă reţea
(Internet);
 serverul DNS (Preferred DNS Server) are adresa IP 172.20.0.2. Acest
server determină corespondenţa dintre adresa IP prin nume de domenii
(de exemplu, mikrotik.com) şi adresa IP prin numere (159.148.147.196
pentru mikrotik.com).
Pentru experimentări, cartela de reţea a calculatorului utilizatorului se va
configura după cum urmează:
 IP address: 192.168.x.1
 Subnet mask: 255.255.255.0
 Default gateway: 192.168.x.254
 Preferred DNS Server: 192.168.x.254
unde x este numărul ruterului utilizatorului. Astfel, subreţeaua este una de
clasa C cu un număr maxim de 256 adrese IP. În UNIX masca pentru o
asemenea subreţea se notează /24.
La configurarea interfeţelor de reţea, se va ţine cont de anumite reguli. Fie
că avem subrețeaua 192.168.20.0/24. În aceasta sunt disponibile 256 de
147
adrese IP: de la 192.168.20.0 pană la 192.168.20.255. Pentru o asemenea
subreţea, regulile de respectat sunt:
 nu se poate atribui aceeaşi adresă IP la două interfeţe ale subreţelei,
altfel adresarea va fi neunivocă;
 prima din cele 256 de adrese, adică cea 192.168.20.0, este adresa
subrețelei. Aceasta nu poate fi atribuită vreunei interfeţe;
 ultima din cele 256 de adrese, adică cea 192.168.20.255, este adresa de
difuzare (broadcast). Ea tot nu poate fi atribuită vreunei interfeţe;
 astfel, ţinând cont de adresa de subreţea şi cea de difuzare, pentru inter-
feţele de reţea, din cele 256 adrese, putem folosi 256 – 2 = 254 adrese.
Sarcina practică 4.1. Configurarea cartelei de reţea a calculatorului
utilizatorului. De configurat cartela de reţea a calculatorului local, ţinând cont
de informaţiile prezentate mai sus în această secţiune.
4.2.3. Configurarea legăturii calculator-ruter utilizator
Pentru ca să fie posibilă transmiterea directă (fără rutare) a datelor între
calculator şi ruter, este necesar ca ambele interfeţe ale acestei legături să fie
în aceeași subrețea. Deoarece interfaţa calculatorului este deja configurată
(vezi s. 4.2.2), trebuie configurată şi interfaţa respectivă a ruterului.
Exemplul 4.5. Configurarea legăturii calculator-ruter utilizator. Fie că
interfaţa ruterului, la care este conectat cablul UTP conform schemei din
figura 4.11, este ether2 şi acesteia este necesar de atribuit adresa
192.168.x.254/24 (în loc de x se va specifica numărul concret al ruterului
utilizatorului în cauză, în cazul din fig. 4.14 – valoarea 20). Atunci acţiunile de
urmat sunt (fig. 4.14):
1) în meniul IP al interfeţei de lucru a WinBox, activat prin clic, se
selectează submeniul Addresses. Va apare fereastra derivată Address
List şi va dispare lista submeniurilor meniului IP;
2) pentru a adăuga o înregistrare în fereastra Address List, în bara cu
instrumente a acesteia se va apăsa butonul + . Va apare fereastra New
Address;
3) în câmpul Address al ferestrei New Address, se va scrie adresa
192.168.x.254/24, în câmpul Network – adresa 192.168.x.0, iar în lista
Interface se va selecta ether2. Ulterior, se va apăsa butonul OK. Fereastra
New Address va dispare, iar configurările interfeţei de reţea ether2 a
ruterului vor apare ca o nouă înregistrare în fereastra Address List.
Prescurtat, în notarea formulată în s. 4.1.3.2, aceste acţiuni se specifică
astfel: /IP/Addresses/Address List, + /New Address, Address –
192.168.x.254/24, Network – 192.168.x.0, Interface – ether2/OK.
148
Fig. 4.14. Configurarea interfeţei ruterului la x = 20.
Pentru verificarea conexiunii PC-ruter, se poate urmări traficul de date prin

interfaţa ether2 a ruterului sau prin cea de reţea a PC. În acest scop, în primul
caz se va activa, prin clic, meniul /Interfaces, apărând fereastra Interface List,
în care se va deschide fila Interface (fig. 4.15a); în al doilea caz se va activa
meniul /New Terminal, iar în fereastra Terminal ce va apare, la prompter, se
va scrie comanda ping 192.168.x.1 (fig. 4.15b).
a)
b)
Fig. 4.15. Testarea legăturii PC-ruter.

Din fig. 4.15 se poate observa prezenţa traficului de date prin cele două
interfeţe de reţea.
149
Deoarece interfeţei ether2 îi este deja atribuită o adresă IP, în conformitate
cu recomandarea din s. 4.1.4.2, se va închide utilita WinBox (dar, pentru a
salva setările efectuate, mai întâi se va dezactiva regimul Safe Mode, dacă
acesta este activat), iar apoi WinBox se va lansa din nou, realizând conectarea
PC la ruter la fel ca şi în s. 4.1.4.2 (fig. 4.6), doar că deja în baza adresei IP în
cauză şi nu a celei MAC.
Caracterul conexiunii curente PC-ruter, prin adresa MAC sau prin cea IP a
interfeţei ruterului, poate fi observat în titlul interfeţei de lucru a WinBox (fig.
4.16).
Fig. 4.16. Conexiunea curentă PC-ruter este prin adresa IP a interfeţei ruterului.
Sarcina practică 4.2. Configurarea legăturii calculator-ruter utilizator. De
configurat şi de verificat conexiunea calculator-ruter utilizator conform
exemplului 4.5.
4.2.4. Configurarea legăturii ruter utilizator-poartă implicită
Conform schemei din figura 4.11 a s. 4.2.1, ruterul fiecărui utilizator
trebuie conectat, printr-o legătură fără fir, la ruterul AP. Interfaţa fără fir a
acestui AP serveşte ca poartă implicită Internet pentru toate ruterele
utilizatorilor şi se va considera deja configurată.
Pentru conectarea ruterului utilizatorului la AP, trebuie configurată
interfaţa fără fir a primului ca staţie (station). În acest scop, se activează, prin
clic, meniul /Wireless (fig. 4.17). În fereastra Wireless Tables ce se va afişa, se
va deschide fila Interfaces (fig. 4.17), în care se poate observa că interfața
wlan1 nu este activată (înregistrarea privind wlan1 este pală).
Pentru a configura interfața wlan1, în fereastra Wireless Tables se execută
dublu-clic pe înregistrarea wlan1, iar apoi, în fereastra Interface <wlan1> ce va
apare, se deschide fila Wireless, în care în lista de selecţie Mode se selectează
station, iar apoi se apasă butonul Enable sau cel OK (fig. 4.17). Rezultatul va fi
activarea înregistrării privind wlan1 în fereastra Wireless Tables (fig. 4.18).
Prescurtat, în notarea formulată în s. 4.1.4.2, aceste acţiuni se specifică astfel:
/Wireless/Wireless Tables/Interfaces, dublu-clic wlan1/Interface <wlan1>/
Wireless, Mode – station, Enable sau OK
150
Fig. 4.17. Primii paşi la configurarea interfeţei wlan1.
De menţionat că fereastra Interface <wlan1> de configurare a interfeţei
wlan1 a ruterului utilizatorului poate fi afişată şi prin clic-dreapta în cadrul
ferestrei Wireless Tables.
Deşi interfaţa wlan1 este deja
configurată (fig. 4.18), nu este încă stabilită
conexiunea acesteia cu AP-ul subreţelei fără
fir date. În raza de acţiune a interfeţei fără
fir wlan1 pot fi mai multe subreţele fără fir.
Din multitudinea de AP ale acestor subreţele Fig. 4.18. Interfaţa wlan1
este activată.
este necesar de ales unul anume – acel ce
ţine de subreţeaua în cauză.
Subreţelele fără fir se identifică printr-un nume, denumit SSID (service set
identifier). SSID se poate referi la o singură subreţea fără fir ce se conectează
la alte subreţele, cablate sau fără fir, prin intermediul unui punct de acces
(Access Point – AP) sau la mai multe subreţele fără fir, fiecare din care se
conectează cu celelalte printr-un AP, iar AP-urile, la rândul lor, sunt conectate
între ele prin intermediul unui sistem de distribuire (Distribution System – DS)
cablat sau fără fir. Fiecare AP transmite periodic în eter SSID-ul respectiv.
Pentru identificarea AP-ului în cauză, este necesar de scanat mediul.
Scanarea mediului se lansează prin acţionarea butonului Scan din fereastra
Interface <wlan1> (fig. 4.19). În fereastra Scanner (Running) ce se va afişa (un
exemplu este prezentat în fig. 8.6 din s. 8.2.4.1), din lista de înregistrări de
subreţele fără fir (AP), se va selecta subreţeaua cu numele SSID în cauză (în
figura 4.19 – bit1947), apoi se va acţiona butonul Connect, iar ulterior, deja în
fereastra Interface <wlan1>, se va apăsa OK.
151
Fig. 4.19. Stabilirea conexiunii interfeţei wlan1 cu AP.
Notă. Dacă, în bara de submeniuri/file, ultima filă este punctele de suspensie … (fig.
4.19), aceasta înseamnă că o parte din titlurile filelor lipsesc. Lista acestora poate fi
afişată, prin clic pe butonul-puncte de suspensie, iar apoi selectând, prin clic, opţiunea
necesară din listă, denumirea acesteia va apare în bară.
A rămas de atribuit interfeţei wlan1 o adresă IP. În acest scop se va folosi
atribuirea dinamică a adreselor IP. Atribuirea dinamică în cauză are loc, dacă la
AP este activată utilita DHCP server, iar pe interfaţa wlan1 a ruterului
utilizatorului – cea DHCP client. Utilita DHCP server atribuie în mod automat
adrese IP interfeţelor din subreţea pe care sunt activate utilite DHCP client.
Se va considera că utilita DHCP server este deja activată. Pentru activarea
utilitei DHCP client pe interfaţa wlan1, se acţionează /IP/DHCP client, +/New
DHCP Client/DHCP, Interface – wlan1/OK (fig. 4.20).
Fig. 4.20. Activarea DHCP client pe wlan1.
152
Sarcina practică 4.3. De configurat interfaţa wlan1 a ruterului
utilizatorului, pentru a stabili conexiunea cu AP al reţelei locale fără fir ce are
SSID-ul APprof. Interfaţa wlan1 a ruterului utilizatorului, trebuie să folosească
o adresă IP privată, atribuită dinamic de către serverul DHCP al AP:
1. De configurat modul station de operare a ruterului utilizatorului:
/Wireless/Wireless Tables/Interfaces, dublu-clic wlan1/Interface <wlan1>/
Wireless, Mode – station, Enable.
2. De identificat şi de realizat conectarea la AP: în fereastra Interface <wlan1>,
Scan/Scanner, SSID – APprof,
Connect/OK. Numele SSID
trebuie de reţinut.
3. De atribuit interfeţei wlan1 a
unei adrese IP private
dinamice: /IP/DHCP client, Fig. 4.21. Verificarea conexiunii în Address List.
+/New DHCP client/DHCP,
Interface – wlan1/OK (fig. 4.20).
4. De verificat stabilirea conexiunii: (a) folosind instrucţiunea ping către adresa
IP a interfeţei fără fir a AP (/New Terminal/prompter ping
adresa_IP_intefaţa_fără_fir a AP); (b) folosind utilita Traceroute către
adresa IP a interfeţei fără fir a AP (/Tools/Traceroute/Traceroute To:
adresa_IP_intefaţa _fără _fir a AP; (c) în lista de adrese Address List
(/IP/Adresses) – dacă conexiunea a fost stabilită, atunci în fereastra Address
List ce va apare va fi o înregistrare privind interfaţa wlan1, în care simbolul
D specifică faptul obţinerii adresei wlan1 prin DHCP (fig. 4.21).
Conform figurii 4.21, conexiunea ruterului utilizatorului (IP 192.168.1.253)
cu AP-ul reţelei 192.168.1.0, prin interfaţa wlan1, este configurată. Astfel, sunt
deja configurate legăturile PC-ruter utilizator şi ruter utilizator-AP. A rămas de
configurat (fig. 4.11) legătura PC-Internet prin AP.
4.2.5. Configurarea legăturii calculator-Internet
Pentru a configura legătura PC-Internet prin AP, este necesar ca:
1) ruterul utilizatorului să cunoască adresa serverului DNS, altfel ruterul nu
va putea procesa adresele Web. În acest scop trebuie configurat serverul
DNS pe ruterul utilizatorului;
2) calculatorul utilizatorului să cunoască adresa serverului DNS, altfel
calculatorul nu va putea procesa adresele Web;
3) să fie realizată interpretarea univocă a adreselor private din LAN (PC şi
ruterul utilizatorului au adrese private, adică locale – vezi ss. 1.5.1, 1.5.2)
de către dispozitivele de reţea din Internet. Funcţia respectivă revine
translatorului de adrese de reţea (Network Address Translation – NAT),
iar regula aplicată de către NAT în acest scop este masquerade.
153
Sarcina practică 4.4. Configurarea legăturii PC-Internet prin AP:
1. De configurat DNS pe ruterul utilizatorului: /IP/DNS/DNS Settings, Servers –
adresa_serverului_DNS, Allow Remote Requests – bifare, OK. În calitate de
adresa_serverului_DNS se va folosi adresa interfeţei AP, la care este
conectat ruterul utilizatorului (în figura 4.22 – 192.168.1.1). Bifarea opţiunii
Allow Remote Requests este necesară pentru a permite calculatorului
utilizatorului să lanseze instrucţiuni ping prin ruter către WAN, inclusiv în
scopul testării conexiunii PC-Internet.
2. De verificat şi, la necesitate, de
configurat DNS pe calculatorul
utilizatorului conform s. 4.2.2,
specificând în câmpul Preferred
DNS Server adresa IP a interfeţei
ruterului utilizatorului, la care
este conectat calculatorul, adică
192.168.x.254. Acum Fig. 4.22. Setarea DNS la ruterul utilizatorului.
calculatorul are acces la AP prin ruterului utilizatorului, dar încă nu are
acces la Internet, deoarece încă nu este configurată regula masquerade.
3. De configurat regula masquerade la ruterul utilizatorului: /IP/Firewall/NAT,
+/New NAT Rule/fila General, Chain – srcnat, Out Interface – wlan1/fila
Action, Action – masquerade/OK (fig. 4.23).
Fig. 4.23. Setarea regulii masquerade.

4. De testat legătura calculator-Internet: (a) accesarea, de la calculator, a unui
server din Internet, de exemplu www.google.com, folosind un explorator
Web; (b) lansarea, la calculator, din linia de comandă, a instrucţiunii ping
către un server din Internet, de exemplu www.mikrotik.com (în Windows:
/Start/Run/Open – cmd, OK/prompter> ping www.mikrotik.com – figura
4.24).
154
Fig. 4.24. Testarea legăturii calculator-Internet, folosind ping în Windows.
4.2.6. Reguli de respectat şi unele nereguli posibile
La îndeplinirea sarcinilor practice referitoare la conectarea unui calculator
la Internet prin ruterul utilizatorului, este necesar de respectat următoarele
reguli de bază:
 calculatorul trebuie să folosească adresa interfeţei ruterului
utilizatorului, la care acesta este conectat, atât ca adresă de poartă
(gateway), cât și ca adresă de server DNS;
 ruterul utilizatorului trebuie să folosească adresa interfeţei AP, la care
acesta este conectat, atât ca adresă de poartă (gateway), cât și ca adresă
de server DNS;
 pe interfaţa ruterului utilizatorului, la care este conectat calculatorul,
trebuie să fie definită regula masquerade.
Unele nereguli posibile şi cauza lor, la îndeplinirea sarcinilor practice ce ţin
de conectarea unui calculator la Internet prin ruterul utilizatorului:
 ruterul utilizatorului nu execută instrucţiunea ping mai departe de AP. În
acest caz pe interfaţa AP, la care este conectat ruterul utilizatorului, nu
este configurată regula masquerade;
 ruterul nu execută ping cu adrese în formă de nume de domenii. Dacă
ping la careva servere după adresa IP se execută, iar după nume nu,
aceasta înseamnă că nu este corect definit serverul DNS la ruterul
utilizatorului;
 calculatorul nu execută ping mai departe de ruterul utilizatorului. În acest
caz problema poate fi în legătura ruterul utilizatorului-Internet. Este
necesar de verificat configurările la ruter.
 calculatorul nu execută ping cu adrese în formă de nume de domenii.
Dacă ping la careva servere după adresa IP se execută, iar după nume nu,
aceasta înseamnă că nu este corect definit serverul DNS la calculator.
155
4.2.7. Identitatea ruterului
RouterOS permite distingerea identităţii ruterelor prin ID ruter. O
asemenea identificare individuală a ruterelor este utilă, de exemplu, în cazul
administrării a mai multor rutere.
Specificarea ID ruter poate fi efectuată în câmpul Note al ferestrei WinBox
de acces a RouterOS (fig. 4.4) sau în câmpul Identity al ferestrei Identity ce se
va afişa la acţionarea /System/Identity (fig. 4.25).
Sarcina practică 4.5. De specificat identitatea ruterului utilizatorului ca
x_prenume, unde prenume este prenumele utilizatorului.
4.3. Gestiunea utilizatorilor

Este bine cunoscută oportunitatea accesului reglementat la resursele
mijloacelor informatice. În ce priveşte un ruter, dacă un străin află numele de
acces al administratorului ruterului, atunci el poate să reuşească să găsească şi
parola. Ulterior, aceste informaţii pot fi folosite, de exemplu, pentru
reconfigurarea ruterului, asigurând o viteză mai mare de acces la Internet
pentru un anumit utilizator sau chiar închizând accesul la ruter ş.a. În ultimul
caz toată rețeaua gestionată de ruter rămâne fără acces la Internet.
În scopul reglementării accesului, RouterOS prevede trei nivele de drepturi
pentru utilizatori:
1) read – citire. Utilizatorul poate doar face cunoştinţă cu configurările
sistemului, dar nu le poate modifica;
2) write – scriere. Utilizatorul poate citi şi seta anumite configurări ale
ruterului;
3) full – depline. Utilizatorul poate citi şi
seta orice configurări ale ruterului.
Astfel, după drepturile de acces,
RouterOS permite trei grupuri de utilizatori:
read, write şi full. Lista funcţionalităţilor
drepturilor de acces pentru aceste grupuri
pot fi afişate acţionând /System/Users/User Fig. 4.25. Atribuirea ID ruter.
List/Groups, iar apoi dublu clic pe
înregistrarea (coloana Name), respectiv, full (fig. 4.26a), write (fig. 4.26b) sau
read (fig. 4.26c).
156
a) drepturi depline b) drepturi scriere c) drepturi citire
Fig. 4.26. Funcţionalităţile implicite ale drepturilor de acces.

Implicit RouterOS prevede utilizatorul admin cu drepturi de acces depline
şi parola spaţiu (blanc), adică nu este necesar de modificat ceva în câmpul
Password. Totodată, drepturile de acces ale utilizatorului admin, ca şi parola,
pot fi modificate. Mai mult ca atât, nu este oportun de păstrat drepturi
depline pentru utilizatorul admin, deoarece acesta este larg cunoscut. În
acelaşi timp, nu se recomandă eliminarea acestuia, deoarece unele programe
ale ruterului au nevoie de el; acesta poate fi folosit in cazuri excepționale.
Configurările minime recomandate, pentru accesul reglementat la ruter,
constau în:
 adăugarea unui utilizator nou cu drepturi de administrator;
 reducerea drepturilor utilizatorului admin, prin atribuirea drepturilor
doar de citire;
 intrarea în sistem doar cu noul nume de utilizator. Modificări la ruter
pot fi efectuate doar cu noul utilizator. Utilizatorul admin poate fi folosit
doar pentru vizualizarea configurărilor existente.
Sarcina practică 4.5. De adăugat un utilizator nou cu drepturi de
administrator şi de redus drepturile utilizatorului admin:
1. De creat un utilizator nou cu drepturi de administrator: /System/Users/User
List/Users, +/New User, Name – x_nume, Group – full, Password – parola,
Confirm Password – parola, OK (fig. 4.27a), unde x este numărul ruterului (în
cazul din figura 4.27, x = 20). În fereastra User List (aceasta se afişează la
acţionarea /System/Users) va apare o nouă înregistrare cu informaţii despre
utilizatorul x_nume. Atenție: este necesar de reținut bine numele și parola
(se poate nota undeva), deoarece modificările ulterioare vor fi posibile doar
cu acest utilizator.
157
1
2. De accesat ruterul cu numele x_nume.

3. De dezactivat interfața fără fir a ruterului.
a) Adăugarea unui utilizator nou (20_bit) b) Atribuirea drepturilor doar de

cu drepturi depline (full) citire (read) utilizatorului admin
Fig. 4.27. Gestiunea utilizatorilor RouterOS.

4. De verificat, la calculator, posibilitatea accesării Internet.
5. De activat interfața fără fir a ruterului, iar apoi de verificat din nou, la
calculator, posibilitatea accesării Internet.
6. De atribuit utilizatorului admin a drepturilor
doar de citire: /System/Users/ User List,
dublu-clic pe înregistrarea admin/User
<admin>/Group – read, OK (fig. 4.27b).
Modificarea efectuată va apare în
înregistrarea admin din fereastra User List, în
care sunt prezentate informaţii despre toţi
utilizatorii (fig. 4.28).
Fig. 4.28. Lista utilizatorilor
7. De convins că efectuarea de modificări cu
ruterului.
utilizatorul admin nu sunt posibile.
4.4. Gestiunea serviciilor RouterOS

Diferite servicii de reţea folosesc diferite porturi Internet (vezi ss. 1.3.1,
1.4.3). Pentru a închide sau a permite asemenea servicii, trebuie de ţinut cont
de porturile Internet respective. De exemplu: pentru a folosi serviciul de
transfer de fișiere prin ftp, trebuie sa fie deschise porturile 20 (date) și 21
(comenzi); pentru a permite conectarea la ruter prin ssh și telnet, trebuie să
fie deschise porturile, respectiv, 22 și 23 (vezi anexa 3).
158
Lista serviciilor și starea lor în cadrul ruterului poate fi vizualizată accesând
meniul /IP/Services. Se va afişa fereastra IP Service List (fig. 4.29), în care
pentru fiecare serviciu este specificat
numele (Name), portul folosit (Port) şi alte
informaţii. Fiecare din aceste servicii poate
fi activat sau dezactivat.
Pentru a activa, dezactiva sau
reconfigura un serviciu, se execută dublu-
clic pe înregistrarea respectivă din fereastra
IP Service List şi în caseta de dialog IP
Service <nume_serviciu> ce se va afişa (în Fig.4.29. Lista serviciilor.
fig. 4.30 – IP Service <ftp>) se vor efectua
configurările necesare. De exemplu, pentru
a dezactiva un serviciu activat, se va apăsa
butonul Disable, iar pentru activarea unui
serviciu dezactivat – butonul Enable (apare
în locul celui Disable din fig. 4.30). Se poate
modifica numărul portului prin care se va
oferi serviciul (câmpul Port).
De asemenea, se pot restricţiona
adresele IP, pentru care este permis accesul
serviciului. În acest scop, adresele
respective se vor specifica explicit în lista
Available From (fig. 4.30).
După efectuarea tuturor modificărilor
necesare, se va apăsa butonul OK.
Conform figurii 4.29, la ruter sunt
Fig. 4.30. Configurarea ftp.
activate serviciile ftp, ssh, telnet, winbox şi
www şi sunt dezactivate cele api şi www-ssl. Din aceste servicii, cel ftp, folosit
pentru transferul de fişiere către şi de la ruter, ar putea fi dezactivat, funcţiile
respective fiind posibil de realizat folosind alte servicii. Serviciul api oferă o
interfaţă de programare a aplicaţiilor (Application Programming Interface –
API). Ea permite utilizatorului să elaboreze aplicaţii pentru ruter. Serviciul
www-ssl permite accesul securizat al ruterului prin https. Celelalte servicii sunt
bine cunoscute.
4.5. Gestiunea fişierelor în RouterOS

Ca şi în orice alt sistem de operare, informaţiile, cu care operează
RouterOS, sunt organizate în fişiere. Dintre fişierele, cu care este necesar de
operat în RouterOS, pot fi menţionate, în primul rând, fişierele sistemului de
159
pachete al RouterOS (packages), copiile de rezervă ale RouterOS în ansamblu
sau ale unor pachete ale acesteia, diverse fişiere hotspot ş.a.
Pachetele RouterOS de pe ruter sunt listate în fereastra Package List ce se
afişează la acţionarea /System/Packges. Lista acestora poate fi completată de
la www.mikrotik.com/download (tab. 4.1). Copiile de rezervă ale RouterOS
sunt listate în fereastra File List ce se afişează la acţionarea /Files. Tot în File
List pot fi păstrate şi diverse alte fişiere. De asemenea, prin File List se
efectuează copierea pe ruter a diferitelor pachete ale RouterOS (vezi s. 4.6).
Gestiunea fişierelor în RouterOS poate fi prin FTP sau WinBox, mai comodă
fiind, îndeosebi pentru utilizatori mai puţin experimentaţi, utilita WinBox.
Pentru a folosi în acest scop serviciul FTP, la calculator trebuie să fie instalat un
client FTP standard. Stabilirea de la calculator a sesiunii de lucru cu RouterOS
prin FTP este una obişnuită, folosind pentru autentificare numele de utilizator
şi parola deja folosite pentru accesul ruterului.
Copierea prin WinBox a fişierelor de pe calculator în fereastra File List şi
invers se efectuează simplu – prin tragere cu şoricelul. Pentru o copiere mai
sigură, se recomandă folosirea accesului la ruter prin adresa IP şi nu prin cea
MAC a acestuia. Unele exemple de lucru cu fişiere în RouterOS sunt descrise în
ss. 4.6 şi 4.7.
4.6. Monitorizarea timpului folosind NTP

4.6.1. Aspecte generale
Serviciul de timp este larg folosit în calculatoare şi reţele, inclusiv pentru
sincronizare, evidenţa lansării diverselor acţiuni, statistici, etc. Totodată, spre
deosebire de PC, ruterele MikroTik nu sunt dotate cu baterii şi de aceea nu pot
menţine ora curentă, dacă sunt deconectate de la sursa de energie electrică.
Din această cauză este oportună includerea setării timpului în configurarea
standard a ruterului.
Pentru setarea şi menţinerea datei şi orei la ruter, serveşte Protocolul
timpului în reţea (Network Time Protocol – NTP), realizat în utilitele NTP client
şi NTP server. Serverul NTP are grijă de menţinerea în stare actuală a orei şi de
oferire a informaţiilor respective clienţilor NTP prin difuzare sau la solicitare.
Funcţia de bază a NTP client constă în solicitarea sau recepţia mesajelor de
difuzare a orei de la un NTP server din reţea şi setarea acesteia la ruter. Există
un şir de servere NTP publice. Lista lor poate fi accesată la adresa
support.ntp.org/bin/view/Servers/WebHome. În Republica Moldova
funcţionează aşa servere NTP publice ca:
1) de nivel 1: 193.226.65.38, 178.17.160.12, 178.17.161.12, 178.17.162.12;
2) de nivel 2: 193.226.65.2, 89.28.117.120, 89.28.2.250.
160
În versiunea 5 a RouterOS, clientul NTP şi serverul NTP sunt incluse în
pachetul ntp, pachet ce nu face parte din sistemul de pachete standard
(implicit) al RouterOS. Totodată, funcţiile de bază ale clientului NTP sunt
realizate în utilita SNTP (Simple Network Time Protocol), ce intră în sistemul de
pachete standard al RouterOS. Fiind elaborată în conformitate cu standardele
RFC, SNTP nu suportă modul manycast (vezi s. 4.6.2). În cazul instalării pe ruter
a pachetului ntp, setările clientului SNTP se partajează cu cele ale clientului
NTP şi clientul SNTP este în mod automat dezactivat.
4.6.2. Clientul NTP
Clientul NTP foloseşte portul UDP 123 şi poate opera, în funcţie de licenţă,
în 4 moduri:
 unicast – clientul NTP se conectează la serverul NTP specificat. Se
specifică adresa IP a serverului NTP primar şi/sau al celui NTP secundar.
Clientul NTP se sincronizează cu serverul NTP periodic (64-1024 s);
 broadcast – clientul NTP recepţionează mesajele de difuzare ale oricărui
server NTP. După recepţia primului asemenea mesaj, clientul NTP
setează ora, iar apoi aşteaptă următoarele asemenea mesaje;
 multicast – operează ca modul broadcast, doar că în loc de mesaje de
difuzare (adresa IP 255.255.255.255) recepţionează mesaje multiadresat
(adresa IP 224.0.1.1);
 manycast – este modul monoadresat (unicast), dar fără cunoaşterea
adresei IP a serverului NTP. Pentru a descoperi un server NTP, clientul
NTP trimite mesaje multiadresat (adresa IP 239.192.1.1). Dacă serverul
NTP este configurat să recepţioneze asemenea mesaje (este activat
modul multiadresat), el răspunde. După recepţionarea răspunsului,
clientul NTP aplică modul unicast şi sincronizează timpul cu cel al
serverului NTP în cauză. Totodată, în paralel, clientul NTP continuă
descoperirea de servere NTP, trimiţând mesaje multiadresat.
Clientul NTP se configurează, în linii mari, ca şi cel SNTP. În continuare
este descrisă configurarea clientului SNTP. Pentru setarea timpului la
ruter, se acţionează /System/SNTP Client şi în fereastra SNTP Client ce se
va afişa (fig. 4.31a): în lista Mode se selectează modul de operare unicast
(sau broadcast; în cazul clientului NTP pot fi, de asemenea, opţiunile
multicast şi manycast); în câmpul Primary NTP Server se specifică adresa
IP a serverului NTP primar (de exemplu 193.226.65.38); în câmpul
Secondary NTP Server se specifică adresa IP a serverului NTP secundar
(de exemplu 89.28.2.250). Apoi se apasă butonul OK.
161
a) b)
Fig. 4.31. Configurarea clientului NTP şi setarea orei locale.

4.6.3. Setarea orei locale folosind Clock
Setarea clientului NTP nu garantează configurarea corectă a orei locale.
Dacă serverul NTP este în altă zonă orară faţă de cea a ruterului, atunci ora va
corespunde zonei orare a serverului NTP.
Pentru ajustarea orei la cea locală, se acţionează /System/Clock, afişându-
se fereastra Clock. În aceasta, setarea orei poate fi temporară, pentru sesiunea
curentă de lucru a ruterului, sau permanentă. Setarea manuală se efectuează
în fila Manual Time Zone, completând în mod manual câmpurile respective.
Având utilizări specifice, ea nu este recomandată pentru uz ordinar, deoarece
va trebui resetată după fiecare restartare a ruterului.
Pentru setarea permanentă a orei, în fila Time, lista Time Zone Name, se
selectează zona orară: pentru Republica Moldova aceasta este
Europe/Istanbul. Apoi se apasă butonul OK. Dacă acţiunile au fost corecte şi
ruterul are conexiune la Internet, atunci în câmpul Time va apare ora curentă,
iar în cel Date – data (fig. 4.31b).
4.6.4. Serverul NTP
Serverul NTP nu face parte din sistemul de pachete standard al RouterOS.
Dacă din anumite considerente se doreşte configurarea unui server NTP
propriu, atunci este necesară descărcarea pachetului ntp de la
www.mikrotik.com/download şi ulterioara instalare a lui pe ruter:
1) descărcarea fişierului zip all_packages-mipsbe de la www.mikrotik.com/
download;
2) dezarhivarea fişierului pe calculator;
3) copierea pachetului ntp în fereastra File List a meniului Files;
4) restartarea ruterului;
5) acţionarea /System/NTP Server şi, în fereastra de dialog NTP Server ce
se va afişa, bifarea opţiunii Enabled, iar apoi apăsarea butonului OK.
Pe lângă opţiunea Enabled, în fereastra de dialog NTP Server sunt şi
opţiunile Broadcast, Multicast şi Manycast, care pot fi bifate pentru a specifica
modul de oferire a serviciului. După activare, acesta poate fi folosit ca server
NTP în reţea.
162
4.7. Actualizarea şi reconfigurarea RouterOS
Fiecare ruter este livrat de MikroTIK cu RouterOS preinstalat.
Caracteristicile preinstalărilor pot fi accesate la adresa wiki.mikrotik.com/
wiki/Manual:Default_Configurations. De exemplu, pentru ruterele seriei
RB951 acestea sunt: portul WAN – ether1; porturile LAN – ether2-ether5
comutate şi wlan1 puntată cu comutatorul; modul fără fir – AP b/g/n, 2412
MHz; ht chain – 0; ht extension – în afara controlului (above control); serverul
DHCP – pe portul LAN; clientul DHCP – pe portul WAN; i-bariera (firewall) –
accesul la portul WAN blocat; NAT – regula masquerade pe portul WAN;
adresa IP implicită – 192.168.88.1/24; serverul MAC – dezactivat pe portul
WAN.
Totodată, către momentul instalării ruterului, se poate întâmpla ca
MikroTik să lanseze o nouă versiune RouterOS. În asemenea cazuri, înainte de
configurarea ruterului, MikroTik recomandă actualizarea versiunii RouterOS.
Actualizarea versiunii RouterOS poate fi oportună şi pentru extinderea sau
îmbunătăţirea funcţionalităţilor unui ruter în funcţiune, de exemplu pentru
sporirea securităţii funcţionării sau depăşirea unor nereguli de funcţionare a
versiunii curente. Versiunile RouterOS sunt numerotate secvenţial în creştere,
iar versiunea, la care poate actualizată versiunea curentă, depinde de licenţa
deţinută (vezi s. 3.4).
Se pot întâlni şi cazuri când este necesară declasarea (downgrade) versiunii
RouterOS. Cele mai frecvente cazuri însă ţin de modificarea setului de
funcţionalităţi ale RouterOS, în scopul eficientizării valorificării resurselor, prin
folosirea acelor şi doar a acelor funcţionalităţi şi servicii, de care este nevoie în
condiţiile date. Totodată, configurarea reuşită a funcţionalităţilor şi serviciilor
RouterOS necesită cunoştinţe specifice. În acest scop RouterOS permite
gestiunea drepturilor utilizatorilor de configurare a sistemului.
De asemenea, la apariţia unor probleme cu utilizarea RouterOS, uneori
este suficientă reinstalarea acestuia, folosind o copie de rezervă.
Anume asemenea aspecte şi se vor aborda în ss. 4.7.2-4.7-4.
4.7.2. Actualizarea RouterOS
Sistemele RouterOS pot să difere de la un ruter la altul. De aceea trebuie să
avem grijă să selectăm sistemul, în funcţie de ruterul, pe care acesta va fi
instalat. Versiunile disponibile ale RouterOS, ca şi cele ale altor produse
program ale MikroTIK, pot fi descărcate, în anumite condiţii (vezi s. 4.1.3), de
la www.mikrotik.com/download. Opţiunile de descărcare a RouterOS de la
MikroTik, la 20 aprilie 2014, sunt prezentate în figura 4.32.
163
Fig. 4.32. Opţiuni de descărcare a RouterOS de la MikroTik.
După cum se poate observa din figura 4.32, diversele opţiuni de descărcare
a RouterOS de la MikroTik depind de setul de instrucţiuni al procesorului
ruterului (mipsbe, ppc, x86, mipsle sau tile, vezi s. 3.2), versiunea sistemului
(v4.17, v5.26 şi v6.11) şi setul de mijloace/modalitatea (Upgrade package, All
packages, Wireless CAPsMAN, Netinstall, Torrent, Changelog şi MDS), ultimele
semnificând:
 Upgrade package (fişierul .npk), denumit şi “combined package”, – noua
versiune implicită a RouterOS, adică versiune ce se preinstalează pe
ruterele livrate de MikroTik;
 All packages – include toate funcţionalităţile noii versiuni a RouterOS.
Din acestea se pot selecta şi instala pachetele necesare, formând o
configuraţie diferită de cea implicită;
 Wireless CAPsMAN – pachetul de testare fără fir, care include
funcţionalitatea CAPsMAN (Controled AP system manager);
 Netinstall – utilită de instalare a RouterOS prin reţea;
 Torrent – descărcare prin clientul Bit-Torrent, oportună în cazul unei
viteze de transfer date joase sau necalitative a conexiunii la Internet;
 Changelog – modificările efectuate în RouterOS;
164
 MD5 – aplicaţia ce realizează algoritmul MD5 de calculare a valorii (sumei
de control) pe 128 biţi (16 octeţi) a funcţiei criptografice de haşare. Se
foloseşte pentru verificarea integrităţii transferului de fişiere.
Actualizarea RouterOS poate fi efectuată folosind WinBox, FTP sau Dude.
În secţiune se va descrie folosirea WinBox.
Sarcina practică 4.6. Actualizarea RouterOS pentru ruterul de model YYYY,
după cum urmează:
1. De descărcat pe calculator de la www.mikrotik.com/download a versiunii
noi a fișierului .npk (Upgrade package), pentru modelul de ruter YYYY (în
figura 4.32: setul de instrucţiuni mipsbe, rutere de seria RB7xx, versiunea
v5.26 a RouterOS, Upgrade package – fişierul routeros-mipsbe-5.26.npk);
2. De lansat WinBox (dacă încă nu este lansată), accesând ruterul după adresa
IP (nu cea MAC), acţionarea /Files şi copierea fișierului .npk, prin tragere cu
şoricelul de pe calculator pe ruter, în corpul ferestrei File List (figura 4.33).
Dacă în listă există dosare, trebuie să fim atenţi să tragem fişierul .npk în
dosarul rădăcină Files, adică în zona liberă a ferestrei File List şi nu în cadrul
vreunui alt dosar, de exemplu al celui
pub sau skins, nepermiţând astfel
actualizarea sistemului. Totodată,
fişierul .npk nu trebuie să fie primul în
lista de fişiere. De aceea, dacă în File
List nu există încă nici un dosar, se Fişierul .backup
poate crea, mai întâi, un fişier-copie
(backup) a versiunii curente a
Fişierul .npk tras cu şoricelul
RouterOS, apăsând butonul Backup al
ferestrei File List (fig. 4.33), şi doar apoi Fig. 4.33. Copierea fişierului .npk.
copiind fişierul .npk;
3. După încheierea copierii fișierului .npk,
se va iniţia reîncărcarea RouterOS,
acţionând /System/Reboot. Sistemul
verifică dacă în Files este vreo versiune
nouă. În cazul că o asemenea versiune
există, sistemul va afişa o casetă de
dialog (fig. 4.34), în care întreabă
utilizatorul dacă acceptă sau nu pachetul .npk
încărcarea noii versiuni. Dacă se
doreşte instalarea noii versiuni, se
apasă butonul Yes. Peste câteva minute
ruterul va opera deja cu noua versiune
Fig. 4.34. Acceptarea actualizării
a RouterOS, fapt ce poate fi observat, RouterOS.
inclusiv în bara de titlu a WinBox (fig.
165
4.35). Astfel, versiunea v5.22 (fig. 4.17) a fost înlocuită cu cea v5.26.
Fig. 4.35. Specificarea noii versiuni, v5.26, a RouterOS în bara de titlu a WinBox.
4.7.3. Declasarea RouterOS
Declasarea RouterOS se efectuează şi mai simplu, decât actualizarea. În
acest scop se acţionează /System/Packages, apoi, în fereastra Package List ce
se va afişa, se selectează toate pachetele, iar ulterior se execută clic pe
butonul Downgrade din bara cu instrumente (fig. 4.36). Sistemul va afişa o
casetă de dialog, solicitând confirmarea necesităţii relansării ruterului. Dacă se
doreşte declasarea RouterOS, se va apăsa butonul Yes. De menţionat,
totodată, că nu se recomandă
declasarea parţială a RouterOS,
adică doar a unor pachete ale
acesteia; aceasta poate conduce
la efecte nedorite.
Notă. În câmpul ferestrei se pot
adăuga/elimina coloane prin clic pe
triunghiul de culoare neagră din
ultima coloană (fig. 4.36), apoi clic pe
opţiunea Show Columns şi, în sfârşit, Pachetele selectate
clic pe titlul parametrului respectiv.
Fig. 4.36. Declasarea RouterOS.
4.7.4. Gestiunea sistemului
de module
RouterOS suportă diverse funcţionalităţi, dar pentru fiecare implementare
concretă poate să fie necesară doar o parte din acestea. Pentru configurarea
setului de funcţionalităţi necesare, RouterOS foloseşte aşa numitul sistem de
module (package system). Modulele (packages) de programe necesare pot fi
descărcate de la adresa www.mikrotik.com/download.
Modulele RouterOS, disponibile la data de 14.11.2013, sunt prezentate în
tabelul 4.1.
De menţionat că nu toate aceste module rulează pe toate platformele
RouterBOARD. Concretizările respective pot fi preluate de la adresa
wiki.mikrotik.com/wiki/Manual:System/Packages.
Pentru a vedea ce pachete (module) de programe sunt pe ruter, se
accesează meniul /System/Packges (fig. 4.37). În total în lista din figura 4.37
sunt 11 module, din care două, cele ipv6 şi mpls sunt dezactivate.
166
Tabelul 4.1. Modulele RouterOS (la 14.11.2013)
Denumire
modul Funcţionalităţi
advanced-tools Instrumente avansate ping, netwatch, ip-scan, sms tool, wake-on-LAN
calea Instrumente de colectare a datelor de uz special
dhcp Client şi server DHCP
gps Suport al dispozitivelor GPS (Global Positioning System)
hotspot Gestiunea utilizatorilor porţii HotSpot
ipv6 Suportul adresării IPv6
mpls Suportul MPLS
multicast Protocol Independent Multicast - Sparse Mode;Internet Group Managing Protocol - Proxy
ntp client MlPPP, PPP, PPTP, L2TP, PPPoE, clienţi şi servere PPP ISDN
routerboard Accesarea şi gestiunea RouterBOOT. Informaţie specifică RouterBOARD
routing Protocoale de rutare dinamică ca RIP, BGP, OSPF şi utilite de rutare ca BFD, filtre pentru
rute
security IPsec, SSH, WinBox securizat
m Funcţionalităţi de bază ale ruterelor ca rutarea statică, adrese IP, SNTP, Telnet, API, fire
de aşteptare, i-barieră, proxy Web, mamorie imediată DNS TFTP, depozit de adrese IP
(IP pool), SNMP, scanare de pachete (packet sniffer), trimitere i-poştă, construirea de
grafice, testarea lăţimii de bandă, torţă (torch), EoIP, IPIP, puntare, VLAN, VRRP, etc.)
ups APC ups

user-manager gestiume utilizatori MikroTik
wireless suportul interfeţelor fără fir
arlan Suportul moştenirii Arlan Aironet
n suportul ISDN
lcd suportul panoului LCD
radiolan Suportul cartelelor RadioLan
synchronous Suportul FarSync
xen Virtualizare XEN
kvm Virtualizare KVM
routeros-mipsle Modul combinat pentru platforma mipsle (RB100, RB500) (include: system, hotspot,
wireless, ppp, security, mpls, advanced-tools, dhcp, routerboard, ipv6, routing)
routeros- Modul combinat pentru platforma mipsbe (RB400) (include: system, hotspot, wireless,
mipsbe ppp, security, mpls, advanced-tools, dhcp, routerboard, ipv6, routing)
routeros- Modul combinat pentru platforma powerpc (RB300, RB600, RB1000) (include: system,
powerpc hotspot, wireless, ppp, security, mpls, advanced-tools, dhcp, routerboard, ipv6, routing)
routeros-x86 Modul combinat pentru platforma x86 (Intel/AMD PC, RB230) (include: system, hotspot,
wireless, ppp, security, mpls, advanced-tools, dhcp, routerboard, ipv6, routing)
mpls-test Suportul modernizărilor MPLS
routing-test Modernizările protocoalelor de rutare (RIP, OSPF, BGP)
La necesitate, lista modulelor de pe ruter poate fi completată sau din ea

pot fi excluse unele pachete.
Pentru a completa lista, de la
www.mikrotik.com/download
se descarcă pe calculator
fişierul zip All Packages, apoi
acesta se dezarhivează; ulterior
modulele necesare se
selectează şi se copie, prin
tragere (drag&drop) cu
şoricelul, în meniul /Files/File
List al WinBox. Pentru ca noile
module să se instaleze, este Fig. 4.37. Pachetele disponibile pe ruter.
167
necesar de reîncărcat (reboot) sistemul.
Notă: Nu se recomandă de folosit module de diferite versiuni ale RouterOS. Dacă la
ruter este o versiune mai veche, este oportun de actualizat, mai întâi, RouterOS, iar
apoi de activat/dezactivat modulele respective.
Sarcina practică 4.7. De dezactivat şi reactivat modulul wireless:
1. De dezactivat pachetul wireless: în meniul /System/Packages, fereastra
Package List, se selectează, prin clic, wireless, iar apoi se apasă butonul
Disable.
2. De verificat dacă la calculator este acces la Internet. Nu ar trebui să fie.
3. De reactivat modulul wireless: în meniul /System/Packages, fereastra
Package List, se selectează wireless, iar apoi se apasă butonul Enable.
Pentru eficienţa folosirii resurselor ruterului, se recomandă de păstrat
active doar modulele necesare; celelalte se dezactivează. Un set de module
suficient, în multe cazuri, ar fi: advanced-tools, dhcp, ppp, routerboard,
routing, security, system şi wireless.
4.8. Crearea şi folosirea copiilor de rezervă ale

RouterOS
Copiile de rezervă (backup) permit selectarea unor configurări mai reuşite
sau chiar folosirea lor în cazuri de efecte nedorite ale configurării curente a
RouterOS. Exemple:
 au fost efectuate configurări nereuşite a RouterOS. Restabilirea copiei de
rezervă ar salva situația;
 este nevoie de administrat mai multe rutere cu aceeaşi configurare,
diferite fiind doar adresele IP şi numele (Identity) lor. Se încearcă, se
salvează copii de rezervă şi se compară mai multe configurări, selectând
configurarea mai convenabilă. Ulterior, configurarea selectată poate fi
copiată pe toate ruterele cu modificarea doar a adreselor IP şi a numelui
ruterelor.
Copia de rezervă se poate crea acţionând /Files/Backup sau, din linia de
comandă a /New Terminal, folosind instrucţiunea system backup sau cea
export. În primele două cazuri se salvează o copie de rezervă binară a tuturor
configurărilor RouterOS, copie ce nu poate fi redactată; în cazul al treilea – una
textuală, ce poate fi parţială (de exemplu, doar i-bariera) şi, de asemenea,
poate fi redactată. Ultima poate fi restabilită pe echipamente de diferite
platforme, la simple redactări folosind un editor de texte, de exemplu
Notepad din Windows.
Copiile de rezervă create, atât cele binare, cât şi cele textuale, se listează în
fereastra File List. Ele pot fi uşor distinse după extensia numelui. Numele
168
copiilor de rezervă binare au extensia .backup, iar cele ale copiilor de rezervă
textuale au extensia .rsc.
Pot fi utile atât copiile de rezervă binare, cât şi cele textuale. De exemplu,
cele binare pot fi folosite la configurări nereuşite ale RouterOS pe aceleaşi
echipamente sau la înlocuirea echipamentelor căzute cu altele similare
funcţionale. Copiile textuale pot fi preferate la trecerea de la un ruter la altul
ce diferă, de exemplu, doar prin numărul de porturi sau doar prin adresele IP
şi nume.
Alte particularităţi de creare şi folosire a copiilor de rezervă binare şi
textuale pot fi regăsite în ss. 4.8.2-4.8.3.
4.8.2. Crearea şi folosirea copiilor de rezervă binare
Pentru crearea unei copii de rezervă binare a configurărilor curente ale
RouterOS la ruter, se execută /Files/Backup sau, acţionând /New Terminal,
din linia de comandă se lansează instrucţiunea system backup.
La acţionarea /Files/Backup, în fereastra File List va apare o nouă
înregistrare cu unele caracteristici ale fişierului .backup respectiv (fig. 4.38).
Ulterior este oportun de copiat acest fişier, prin tragere cu şoricelul, într-un
dosar de pe calculator, pentru păstrare în siguranţă şi nu doar. Deoarece
fişierele astfel formate au o denumire în mare parte asemănătoare, este utilă
redenumirea sugestivă a lor, inclusiv cu specificarea datei creării fiecăruia din
ele pentru o utilizare ulterioară.
Exemplul 4.6. Restabilirea unei copii de rezervă binare:
1. Dacă fişierul respectiv este pe calculator, atunci acesta se copie, prin tragere
cu şoricelul, în /Files (fereastra File List);
2. Se selectează, prin clic, înregistrarea cu fişierul-copie de rezervă de restabilit
din fereastra File List (fig. 4.38);
3. Se apasă butonul Restore din bara cu instrumente a ferestrei File List. La
această acţiune, ruterul va afişa caseta de dialog Restore (fig. 4.38),
solicitând de la utilizator confirmarea necesităţii de restabilire a configuraţiei
salvate în copia de rezervă şi reîncărcarea (reboot) RouterOS. Dacă
restabilirea este necesară, se apasă butonul Yes.
4. După restabilirea copiei de rezervă,
se poate întâmpla să fie nevoie de a
activa interfeţele fără fir.
Exemplul 4.7. Salvarea în formă
binară şi ulterioara restabilire a
configurării ruterului din linia de
comandă (/New Terminal), folosind
instrucţiunea system backup, este
Fig. 4.38. Restabilirea copiei binare.
prezentată în figura 4.39.
169
Fig. 4.39. Salvarea binară şi restabilirea configurării ruterului din linia de comandă.
Conform figurii 4.39, mai întâi, folosind comanda system backup save
name=test, este creată copia de rezervă a configurării RouterOS salvată în
fişierul test. Apoi, prin comanda file print, sunt afişate fişierele din meniul Files
(fereastra File List). În total în File List sunt 5 fişiere, din care 3 de tip backup,
inclusiv cel test.backup. Ulterior, prin comanda system backup load
name=test, este iniţiată restabilirea configurării RouterOS conform fişierului
test. În sfârşit, la solicitarea sistemului Restore and Reboot? [y/N]:, prin
răspunsul y, a fost lansată restabilirea configurării RouterOS. Încheierea
restabilirii sistemul o informează prin System configuration restored şi, de
asemenea, acesta informează că este gata să înceapă restartarea ruterului
(rebooting now) afişând, totodată, şi o casetă de dialog cu butonul OK. După
apăsarea pe acest buton, sistemul începe restartarea ruterului.
Unele particularităţi ale copiilor de rezervă binare:
 includ toate configurările curente la ruter ale RouterOS;
 nu pot fi redactate;
 pot fi păstrate mai multe versiuni de configurare a RouterOS. Fiecare din
acestea poate fi, la necesitate, reinstalată.
Unele oportunități de folosire a copiilor de rezervă binare:
 la configurări ulterioare nereuşite a RouterOS pe ruter, se poate reinstala
una din copiile de rezervă salvate anterior;
 la înlocuirea echipamentelor căzute cu altele similare funcţionale (de
exemplu, placa de bază);
 la instalarea unor noi echipamente similare. După reinstalarea RouterOS,
se vor efectua resetările suplimentare necesare, ceea ce poate fi realizat
mult mai ușor decât configurarea ruterului de la cea implicită.
Sarcina practică 4.8. De creat, modificat și reinstalat o copie de rezervă
binară a configurărilor curente ale RouterOS:
1. De creat o copie de rezervă binară a configurărilor curente ale RouterOS,
acţionând /Files/Backup, conform exemplului 4.6.
170
2. De efectuat careva configurări ale ruterului, de exemplu de modificat
numele SSID.
3. De salvat o copie de rezervă binară a noii configurări a RouterOS, de
confirmat salvarea şi, ulterior, de restabilit configurarea anterioară din linia
de comandă a /New Terminal, folosind comenzile system backup save, file
print și system backup load, conform exemplului 4.7 (fig. 4.39);
4. De verificat dacă s-au restabilit configurările iniţiale ale ruterului, de
exemplu numele SSID.
4.8.3. Crearea şi folosirea copiilor de rezervă textuale
Copiile de rezervă textuale pot fi efectuate doar din linia de comandă a
New Terminal folosind comanda export. În acest scop, se acţionează /New
Terminal, iar apoi în fereastra Terminal ce se va afişa, la prompter, se va scrie
comanda
export file=[nume_fişier]
unde [nume_fişier] este numele fişierului de salvat şi poate fi scris fără
extensie. Fişierul salvat va apare în File List.
Dacă este necesar de efectuat careva modificări în fişier, acesta se copie
(prin tragere cu şoricelul) din File List pe calculator. Apoi pe calculator, folosind
un editor de texte, de exemplu Notepad din Windows, pot fi efectuate
modificările necesare. Bineînţeles, pentru a efectua asemenea modificări sunt
necesare cunoştinţe respective.
Ulterior, fişierul modificat se copie înapoi în File List. Pentru instalarea
fişierului din File List, pe ruter, la prompter, se aplică comanda
import file=[nume_fişier],
unde [nume_fişier] este numele (cu extensie) al fişierului de restabilit.
Exemplul 4.8:
/export file=conf-sept2013
/ip firewall filter export file=firewall-conf-sept2013
/file print
/import [Tab]
În acest exemplu, comanda:
 din prima linie – salvează toată configurarea ruterului;
 din a doua linie – salvează doar regulile firewall;
 din a treia linie – afişează informaţia despre fişierele din File List;
 din a patra linie – startează restabilirea de configurări la alegere.
Unele particularităţi ale copiilor de rezervă textuale:
 în copii pot fi incluse doar o parte din configurările RouterOS, de exemplu
cele ce țín de pachetul firewall;
 configurările copiilor de rezervă pot fi redactate;
171
 parolele nu se salvează. După reinstalarea copiei de rezervă, sistemul va
folosi numele de utilizator și parola implicite.
Folosirea copiilor de rezervă binare poate fi oportună:
 în cazurile necesității creării unor copii de rezervă doar a unor pachete
ale RouterOS;
 în cazurile trecerii de la un ruter la altul ce diferă, de exemplu, doar prin
numărul de porturi sau doar prin adresele IP şi nume. Redactările
suplimentare necesare se efectuează după instalarea copiei de rezervă;
 în cazurile instalării RouterOS pe mai multe rutere de diferite platforme,
la simple redactări folosind, de exemplu, utilita Notepad din Windows.
4.9. Instalarea, resetarea şi reinstalarea RouterOS

4.9.1. Resetarea RouterOS
După cum a fost deja menţionat, ruterele MikroTik se livrează cu RouterOS
preinstalat, versiunea implicită a acestuia nesolicitând vreo parolă şi folosind
ca nume de utilizator admin. Totodată, se recomandă ca utilizatorul, pe lângă
setarea ulterioară a configurărilor necesare ale ruterului, să modifice şi datele
de autentificare. Uneori însă poate fi oportună resetarea configurărilor
RouterOS la cele implicite, de exemplu dacă utilizatorul nu-şi poate aminti
parola. La configurările actuale ale RouterOS, resetarea parolei, dacă nu se
cunoaşte parola curentă, nu este posibilă. Stabilirea unei parole noi poate fi
doar după eliminarea configurărilor curente ale sistemului şi revenirea la cele
implicite sau după reinstalarea RouterOS, folosind utilita Netinstall (pentru
x86, de pe CD).
Resetarea simplă a configurărilor curente, cu revenirea la cele implicite ale
RouterOS, poate fi efectuată (datele de autentificare, numele de utilizator şi
parola, se pierd cu revenirea la numele admin şi fără parolă):
 din linia de comandă, lansând instrucţiunea system reset-configuration,
(vezi exemplul 4.9). Pentru aplicarea comenzii, trebuie sa avem acces la
RouterOS;
 aplicând regula 30/30/30: butonul RES al ruterului se ţine apăsat cel
puţin 30 s cu alimentare electrică, apoi încă 30 s fără alimentare şi, în
sfârşit, încă 30 s iarăşi cu alimentare. Resetarea este posibila chiar şi fără
a avea acces la ruter. Aceasta este îndeosebi de utilă, în cazurile uitării de
către utilizator a numelui de utilizator sau/şi a parolei.
Pentru resetarea parolei [1]: (a) de deconectat ruterul de la alimentarea
electrică; (b) de ținut apăsat butonul RES; (c) de aplicat alimentarea electrică și
de așteptat până când LED-ul utilizatorului începe să clipească, apoi de eliberat
butonul RES, pentru a şterge configurările curente. Dacă se va aștepta până
172
când LED-ul va înceta să clipească, și doar apoi se va elibera butonul RES,
atunci se va lansa modul Netinstall, pentru a reinstala RouterOS.
Exemplul 4.9. Resetarea configurării ruterului din linia de comandă
Terminal a WinBox:
În exemplul 4.9, după lansarea de către utilizator a comenzii system reset-

configuration, sistemul îl previne că această comandă este periculoasă şi
solicită confirmarea ([y/N]), la care utilizatorul răspunde negativ (n). Astfel,
sistemul nu a resetat RouterOS (action cancelled). Dacă însă s-ar fi confirmat
acţiunea (y), atunci sistemul ar fi resetat RouterOS la configurările implicite cu
numele de utilizator admin şi fără parolă.
4.9.2. Instalarea RouterOS de pe CD
Dacă este necesară instalarea RouterOS pe un echipament x86 (PC, etc.),
atunci se foloseşte instalarea de pe CD sau utilita Netinstall.
Nota. La instalarea RouterOS pe PC, se vor șterge toate datele de pe HDD;
RouterOS va fi unicul sistem de operare ce va lucra pe PC. De aceea discurile fixe cu
date necesare se vor elimina din calculator.
Pentru instalarea RouterOS pe PC de pe CD, acesta trebuie să fie dotat cu
un HDD și un CD-ROM. De asemenea, la instalare, pe lângă chitul de instalare a
RouterOS, este nevoie de încă un PC cu CD-ROM și o aplicație de înscriere pe
CD.
Instalarea RouterOS pe PC include mai multe acţiuni, descrise la adresa
wiki.mikrotik.com/wiki/Manual:CD_Install.
4.9.3. Instalarea RouterOS folosind utilita Netinstall
Netinstall este un program ce rulează în Windows şi este destinat instalării
sau reinstalării RouterOS pe un PC sau un ruter MikrotTik printr-o reţea
Ethernet. Toate dispozitivele RouterBOARD suportă instalarea prin reţea PXE
(Pre eXecution Environment – PXE network booting). Pentru aceasta este
necesar un cablu serial intre calculator si ruter.
Dacă ruterul nu are nici un port serial şi nici nu este acces la RouterOS,
atunci startarea modului de instalare PXE se poate efectua prin apăsarea
butonului de restartare a ruterului RES.
Netinstal poate, de asemenea, instala RouterOS direct pe un disc
(USB/CF/IDE/SATA), conectat la un calculator pe care rulează Windows. După
173
instalarea RouterOS pe disc, acesta poate fi conectat la un PC, de pe care
RouterOS poate fi instalat pe ruter sau un alt calculator.
Alte informatii, privind folosirea Netinstall pentru instalarea RouterOS, pot
fi regăsite la adresa wiki.mikrotik.com/wiki/Manual:Netinstall.
4.10. Gestiunea licenţei RouterOS

4.10.1. Vizualizarea licenţei RouterOS
După cum a fost menţíonat în s. 3.4, ruterele Mikrotik sunt livrate cu
licenţa RouterOS preinstalată. În funcţie de nivelul licenţei, la ruter sunt
disponibile anumite funcţionalităţi. Licenţa curentă a RouterOS poate fi
vizualizată:
 acţionând /System/License. Se va afişa fereastra License (fig. 4.40);
 din linia de comandă Terminal (se afişează acţionând /New Terminal),
lansând comanda system license print.
4.10.2. Actualizarea licenţei RouterOS
Cu timpul versiunile RouterOS se actualizează, acestea dispunând de
funcţionalităţi îmbunătăţite. Pentru beneficierea de aşa îmbunătăţiri, poate fi
necesară actualizarea licenţei curente la ruter. Începând cu versiunea 3.25,
MikroTik a introdus un format nou de identificare (SoftID) a RouterOS, şi
anume xxxx-xxxx (un exemplu vezi X8PS-PJNT în fig. 4.40). Chiar dacă
RouterOS a fost actualizat, dar nu a fost actualizată licenţa, sistemul va lucra
ca şi versiunea precedentă. Pentru a beneficia de îmbunătăţirile noii versiuni a
RouterOS, este necesară actualizarea respectivă a licenţei.
Pentru actualizarea licenţei, în fereastra License (fig. 4.40) se va apăsa
butonul Update License Key. WinBox va contacta serverul www.mikrotik.com,
comunicându-i identificatorul SoftID
vechi. După analiza acestui
identificator, serverul va genera o
nouă cheie, înlocuind cheia
precedentă. WinBox va primi cheia
nouă și va atribui ruterului noua
licență. Pentru ca noua licență să intre
în vigoare, este necesară reîncărcarea Fig. 4.40. Actualizarea cheii licenţei.
RouterOS.
4.10.3. Cheia licenţei şi declasarea RouterOS
Dacă este necesară declasarea RouterOS (vezi s. 4.7.2), atunci trebuie mai
întâi de activat cheia veche a licenţei. Atunci, când RouterOS aplică cheia nouă
a licenţei, cheia veche este salvată într-un fişier din dosarul Files (fişierul poate
fi accesat în fereastra File List).
174
4.10.4. Schimbarea nivelului licenţei
Trecerea la o licenţă RouterOS de nivel mai înalt este posibilă doar procu-
rând-o. O licenţă poate fi procurată direct de la MikroTik (www.mikrotik.com)
prin intermediul Account Server sau de la distribuitorii locali.
Pentru a se folosi de serviciile Account Server, utilizatorul trebuie mai întâi
să se înregistreze pe acest server. Acccount Server poate fi accesat direct pe
pagina Web principală a MikroTik (www.mikrotik.com). Pentru a se înregistra,
utilizatorul va apăsa butonul account din bara de meniuri (fig. 4.41). Apoi, în
pagina ce se va afișa, va executa clic pe referința Register. Ulterior, în noua
pagină ce se va afișa, va specifica unele informații despre sine și va încheia prin
clic pe noua referință Register.
Fig. 4.41. Accesul pentru crearea unui cont pe Account Server.
4.10.5. Folosirea licenţei

Unele informații privind licențele RouterOS și folosirea lor sunt prezentate
în s. 3.4. Acele informații sunt completate, în această secțiune, cu noi aspecte.
Formatarea discului cu licența. Dacă licența este stocată pe un disc, atunci
formatarea acestuia, folosind instrumente non-MikroTik (ca cele DD sau Fdisk,
de exemplu), va conduce la pierderea licenței. În acest scop se recomandă
folosirea instrumentelor Netinstall sau CD-install (vezi ss. 4.9.1, 4.9.2) ale
MikroTik, instrumente ce pot fi descărcate fără plată de la
www.mikrotik.com/downlooad.
O licență poate fi folosită doar cu un singur calculator. Licența este
integrată în cadrul discului calculatorului (vezi s. 3.4). Astfel, ea poate fi
folosită doar cu calculatorul, în cadrul căruia funcționează acest disc. Dacă se
dorește folosirea licenței cu un alt calculator, este necesar de transferat discul
cu licența la acel calculator. Oricum, în fiecare moment de timp licența poate fi
doar la un singur calculator – la acela, la care este discul cu licența respectivă.
Discul cu o licența RouterOS nu poate fi folosit și în alte scopuri – pe
acesta este instalat și acesta poate fi folosit doar pentru rularea RouterOS.
Trecerea licenței pe un alt disc fix, dacă discul cu licența s-a defectat, este
posibilă folosind o cheie de replasare (Replacement Key). O asemenea cheie
poate fi solicitată, cu plată (10$, la 20 aprilie 2014), de la Echipa de suport a
MikroTik, cu prezentarea de dovezi că discul s-a defectat.
175
5. iBARIERELE – FIREWALLS
5.1. Esenţa i-barierelor
5.1.1. Noţiuni generale
Având ieşire la Internet de la calculator prin ruter (vezi s. 4.2), este posibilă
şi accesarea resurselor calculatorului (subreţelei de calculatoare ce au ieşire la
Internet prin acest ruter) din Internet, care nu întotdeauna poate fi
acceptabilă. Sunt cunoscute multe cazuri de acces nereglementat la i-resurse
cu pierderi, uneori, considerabile. De aceea au fost propuse diverse metode şi
create i-mijloace de securizare a resurselor i-reţelelor. Unul din acestea este
bariera informatică (firewall).
Bariera informatică (i-bariera), denumită şi paravan de protecţie, serveşte
pentru protejarea reţelei de la accesul neautorizat la resurse şi, de asemenea,
de la tranzitarea reţelei de trafic nedorit sau inutil. Ea reprezintă un sistem
informatic de securitate, care monitorizează traficul datelor de intrare/ieşire
în/din reţea şi, în baza unor reguli predefinite, permite sau blochează
tranzitarea fluxurilor de pachete respective. Astfel, acestea stabilesc o barieră
între o reţea internă, de obicei de încredere, şi celelalte reţele, la care prima
este conectată. În acest scop, i-bariera se instalează în cadrul unuia sau a mai
multor rutere ale reţelei.
Mai mult ca atât, o i-barieră poate fi setată şi în cadrul unui calculator
aparte, folosind funcţionalităţile respective ale sistemului de operare al
acestuia. În asemenea cazuri, i-bariera protejează calculatorul de la pericolele
respective din Internet.
Prima publicaţie referitoare la i-bariere a apărut în 1988. În aceasta era
descris un sistem de filtrare a pachetelor, care opera până la al treilea nivel al
modelului OSI (i-bariere de primă generaţie). În anii 1989-1990 sunt lansate i-
bariere de generaţia a doua – i-bariere ce operează până la Nivelul 4 al
modelului OSI, ţinând cont de conexiunile dintre staţii. Apoi, în 1994 sunt
lansate i-bariere de generaţia a treia – i-bariere ce operează până la Nivelul 7
al modelului OSI şi care ţin cont de aplicaţiile sursă şi destinaţie ale fluxurilor
de pachete. În sfârşit, în 2012 sunt lansate i-bariere de aşa numita următoarea
generaţie (next-generation firewall – NGFW), care realizează inspectarea mai
detaliată a aspectelor ce ţin de nivelul aplicaţie al modelului OSI (sisteme de
prevenire a intruziunilor, i-bariere pentru aplicaţii Web ş.a.).
În funcţie de locul de comunicare, locul de interceptare a comunicării,
starea monitorizată ş.a., disting diferite tipuri de i-bariere, inclusiv:
 i-bariere de nivel reţea, denumite şi filtre de pachete;
 i-bariere de nivel aplicaţie;
176
 i-bariere proxy.
Esenţa acestora este descrisă în ss. 5.1.2-5.1.4.
5.1.2. iBarierele de nivel reţea
iBarierele de nivel reţea permit trecerea doar a pachetelor, care corespund
anumitor reguli implicite sau definite de administrator. Asemenea i-bariere
pot fi de două tipuri: stare-completă (stateful) şi fără-stare (stateless).
iBarierele stare-completă țin evidența stării conexiunilor de transfer date
(cum ar fi fluxurile TCP, comunicările UDP), efectuând filtrarea dinamică a
pachetelor. Ele permit trecerea doar a pachetelor ce ţin de conexiunile
cunoscute. La stabilirea unei conexiuni noi, se verifică corespunderea acesteia
politicii de securitate definite. Ulterior, toate pachetele sesiunii curente, ce ţin
de această conexiune, sunt acceptate.
iBarierele fără-stare, care au precedat celor de stare-completă, tratează
fiecare pachet aparte de alte pachete (izolat), fără a ţine cont de conexiuni,
analizând doar antetul pachetului. Din această cauză asemenea i-bariere sunt
vulnerabile la atacuri de substituire frauduloasă (spoofing) a i-programelor
(programelor informatice), când un i-program este prezentat ca un alt i-
program. Totodată, i-barierele fără-stare necesită mai puţină memorie şi pot fi
mai rapide.
iBarierele mai recente pot filtra traficul de pachete, în baza unor aşa
caracteristici ca: adresa IP şi portul sursă, adresa IP şi portul destinaţie,
serviciul oferit (de exemplu WWW, FTP), valoarea TTL (time to live – timpul de
viaţă) ş.a.
5.1.3. iBarierele de nivel Aplicaţie
iBarierele de nivel Aplicaţie interceptează pachetele ce ţin de o anumită
aplicaţie (explorator Web, client sau server FTP, etc.), blocând (de obicei le
elimină) toate celelalte pachete. În baza inspectării pachetelor privind un
conținut necorespunzător, i-barierele pot restricționa sau chiar împiedica
răspândirea în rețea a i-viruşilor (viruşilor informatici). De menţionat,
totodată, că adăugarea unor criterii de inspecție a pachetelor poate rezulta cu
creşterea latenței transferului pachetelor către destinație.
iBarierele de nivel aplicaţie îşi îndepinesc funcţiile prin captarea apelurilor
către socluri (socket), pentru a filtra conexiunile între nivelul Aplicaţie şi
celelalte nivele ale modelului OSI. Asemenea i-bariere se mai numesc şi filtre
de socluri. Astfel, i-barierele de aplicaţii operează, în mare parte, ca filtre de
pachete, dar aplicând regulile de filtrare în bază de procese, în loc de a filtra
conexiunile în bază de porturi. Totuşi, în majoritatea cazurilor i-barierele de
aplicaţii operează în îmbinare cu un filtru de pachete.
177
5.1.4. iBarierele proxy
Un server proxy este un server cu funcţii de intermediar al cererilor
aplicaţiilor client în căutare de resurse de la alte servere. Acesta serveşte ca o
poartă, de la o reţea la alta, pentru anumite aplicaţii de reţea, în beneficiul
utilizatorilor. Aplicaţia client se conectează la un server proxy, solicitând
anumite servicii, de exemplu un fişier, o conexiune sau o pagină Web,
disponibile pe un alt server. Serverul proxy analizează cererea, în scopul
deservirii acesteia. Majoritatea serverelor proxy facilitează accesul la
informaţiile Web din Internet. Un server proxy poate avea aşa destinaţii ca:
 asigurarea anonimatului staţiilor din spatele lui;
 creşterea vitezei de acces a resurselor. Serverele proxy Web, de exemplu,
se folosesc îndeosebi pentru stocarea paginilor Web accesate frecvent;
aceasta permite sporirea operativităţii accesării ulterioare a unor
asemenea pagini şi prevenirea descărcării multiple a aceluiaşi conţinut;
 scanarea informaţiilor de transmis, pentru blocarea/eliminarea
transferurilor frauduloase;
 restricţionarea accesului la anumite resurse ş.a.
Astfel, un server proxy poate îndeplini şi funcţii ce ţin de i-bariere, inclusiv:
asigurarea anonimatului staţiilor din spatele lui; restricţionarea accesului la
anumite resurse; blocarea/eliminarea transferurilor frauduloase de date ş.a.
5.1.5. iBariere RouterOS
Orice i-barieră trebuie să permită trecerea fluxurilor de date acceptabile şi
să blocheze trecerea celor neacceptabile. În asemenea acțiuni, i-bariera
folosește anumite filtre. Filtrele, la rândul lor, operează conform unor reguli.
Fiecare regulă prevede anumite acţiuni în baza unor criterii, cărora
corespunde sau nu pachetul examinat. Adică acţiunile asupra unui pachet
concret depind de criteriile, cărora acesta corespunde.
Astfel, fiecare regulă constă din două părți: (1) un set de criterii (IF), cărora
trebuie să corespundă pachetul; (2) acțiunea (THEN), care definește cum de
procedat cu pachetul. De aceea se mai spune că regulile de filtrare sunt de
tipul IF-Then (Dacă-Atunci), iar filtrele i-barierelor operează conform
principiului IF-Then.
RouterOS include posibilităţi variate de configurare a i-barierelor, inclusiv
[1]:
 inspecția stare-completă a pachetului (stateful pachet inspection);
 detectarea protocoalelor de Nivel 7;
 filtrarea protocoalelor egal-la-egal;
 clasificarea traficului după: adresa MAC a sursei; adresele IP (de reţea sau
listă) şi tipurile de adrese (de difuzare, locale, multiadresat,
monoadresat); porturi; versiunea protocolului IP; opţiunile protocolului
178
(tipul ICMP, fanioanele TCP, opţiunile IP); interfaţa de la care pachetul a
sosit; conţinutul pachetului; rata de sosire a pachetelor şi numerele de
secvenţă; dimensiunea pachetului; timpul de sosire a pachetului ş.a.
Pentru configurarea unei i-bariere în WinBox, se acţionează /IP/Firewall.
Se va deschide fereastra Firewall cu meniurile: Filter Rules, NAT, Mangle,
Service ports, Connections, Address Lists şi Layer7 Protocols (fig. 5.1). Aceste
meniuri au, în linii mari, următoarea destinaţie:
 Filter Rules – definirea regulilor de filtrare;
 NAT – definirea regulilor NAT;
 Mangle – definirea regulilor Mangle;
 Service ports – definirea parametrilor porturilor serviciilor;
 Connections – caracteristicile conexiunilor active la ruter;
 Address Lists – crearea de grupuri de adrese IP cu reguli comune;
 Layer7 Protocols – definirea protocoalelor de nivel Aplicaţie.
Fig. 5.1. Bara de meniuri a ferestrei Firewall.

Folosind opţiunile şi funcţionalităţile meniurilor nominalizate, pot fi
configurate diverse i-bariere, în funcţie de necesităţi. Numerele de porturi și
protocoalele care le folosesc pot fi regăsite în anexa 3.
Notă: La definirea regulilor i-barierelor, trebuie de ţinut cont de faptul că mai întâi
se aplică regulile NAT şi doar apoi celelalte.
Unele din posibilităţile RouterOS de configurare a i-barierelor sunt descrise
în ss. 5.2-5.6.
5.2. Filtrarea pachetelor

iBariera RouterOS aplică filtrarea pachetelor în scop de securizare a
fluxurilor de date către, de la şi prin ruter.
5.2.1. Lanţuri de transfer date
Faţă de i-barieră, pot fi distinse trei categorii de trafic: către i-barieră; de la
i-barieră; prin i-barieră (de tranzit). De aici rezultă şi trei categorii implicite de
lanţuri (chain) de transfer date – lanțuri ce nu pot fi şterse:
 de intrare (input) în ruter;
 de ieşire (output) din ruter;
 de înaintare (forward) prin ruter.
Exemple de asemenea lanţuri sunt prezentate în figura 5.2: input –
comenzi WinBox de la calculator către ruter, output – comenzi ping de la ruter
către staţii sau rutere din Internet şi forward – comenzi www ale unui
explorator Web de pe calculator către servere Web din Internet.
179
Wi
nB
Input (WinBox) Input
ox
Output Ruter Output (ping) Internet
Forward (www)
Fig. 5.2. Categoriile de lanţuri ale i-barierelor.

Pot fi, de asemenea, şi lanţuri ce se creează de utilizator, în scopuri de
organizare şi eficientizare a valorificării resurselor, dar ele, faţă de i-barieră,
tot intră în cele trei categorii. Fiecare asemenea lanţ are un nume, definit de
utilizator. Pentru folosirea unui asemenea lanţ, trebuie de trecut (jump) la
acesta de la unul din cele trei lanţuri predefinite (input, output, sau forward).
Unele aspecte, privind lanţurile ce se creează de utilizator, sunt descrise în s. 5.3.2.
5.2.2. Reguli de filtrare: caracteristici, procesare
Filtrul i-barierelor constă din reguli ce operează conform principiului IF-
Then (vezi s. 5.1.1). Regulile de filtrare, la rândul lor, se definesc şi se
procesează în funcţie de cele trei lanţuri faţă de ruter: input, output şi forward
(fig. 5.2). Unele reguli chain sunt predefinite, altele pot fi definite de utilizator.
La definirea regulilor se folosesc diverse caracteristici/parametri
(properties), inclusiv [1]:
 action (numele acţiunii; implicit: accept) – acţiunea de întreprins, în cazul
că pachetul se potriveşte criteriului regulii, din alternativele:
- accept – acceptarea pachetului;
- add-dst-to-address-list – adăugarea adresei destinaţiei la lista de
adrese specificată de parametrul address-list;
- add-src-to-address-list – adăugarea adresei sursei la lista de adrese
specificată de parametrul address-list, inclusiv pentru determinarea
staţiilor mai active;
- drop – eliminarea (respingerea) pachetului fără înştiinţare;
- jump – trecerea la un alt lanţ definit de utilizator, prin specificarea
valorii parametrului jump-target. Acţiunea este folosită pentru
verificarea conformităţii pachetului unui criteriu dintr-un alt lanţ;
- log – adăugarea, în jurnalul de sistem, a unui mesaj de urmărire a
traficului procesat cu următoarele date: in-interface, out-interface, src-
mac, protocol, src-ip:port->dst-ip:port şi lungimea pachetului. Ulterior
se examinează următoarea regulă. Serveşte pentru monitorizarea
traficului de date;
- passthrough – ignorarea regulii curente şi trecerea la următoarea (este
utilă pentru diagnosticare, statistici);
- reject – respingerea pachetului şi trimiterea unui mesaj ICMP reject;
180
- return – trecerea controlului înapoi la punctul, unde a fost aplicată
acţiunea jump;
- tarpit – capturarea şi deţinerea conexiunilor TCP (la pachetul de intrare
TCP SYN, se răspunde cu SYN/ACK);
 address-list (şir; implicit: ) – numele listei de adrese de folosit;
 chain – (nume; implicit: ) – specifică la ce lanţ de adăugat regula;
 content (şir; implicit: ) – potrivire pachete ce conţin textul specificat;
 dst-address (IP/netmask  diapazon IP; implicit: ) – potrivire pachete, a
căror destinaţie are adresa IP specificată sau se încadrează în diapazonul
de adrese IP specificat;
 dst-address-list (nume; implicit: ) – potrivire adresă destinaţie a
pachetului listei de adrese definite de utilizator;
 dst-port (integer [-integer]: 0..65535; implicit: ) – lista numerelor de
porturi sau a diapazoanelor numerelor de porturi destinaţie;
 in-bridge-port (nume; implicit: ) – interfaţa efectivă prin care pachetul a
intrat în ruter, dacă interfaţa de intrare este de punte;
 in-interface (nume; implicit: ) – interfaţa, prin care pachetul a intrat în
ruter;
 jump-target (nume; implicit: ) – numele lanţului ţintă, la care trebuie de
sărit;
 out-bridge-port (nume; implicit: ) – interfaţa efectivă, prin care pachetul
părăseşte ruterul, dacă interfaţa de ieşire este de punte;
 out-interface (nume; implicit: ) – interfaţa, prin care pachetul părăseşte
ruterul;
 port (integer [-integer]: 0..65535; implicit: ) – potrivirea portului (sursă
sau destinaţie) listei porturilor sau diapazoanelor de porturi specificate;
 protocol (nume sau ID al protocolului; implicit: tcp) – potrivire
protocolului IP anumit, specificat de numele sau numărul protocolului;
 src-address (IP/netmask  diapazon IP; implicit: ) – potrivire pachete, a
căror sursă are adresa IP specificată sau se încadrează în diapazonul de
adrese IP specificat;
 src-address-list (nume; implicit: ) – potrivire adresă sursă a pachetului
listei de adrese definite de utilizator;
 src-port (integer [-integer]: 0..65535; implicit: ) – lista numerelor de
porturi sau a diapazoanelor numerelor de porturi sursă. Este aplicabilă
doar pentru protocoale TCP şi UDP;
 src-mac-address (adresa MAC; implicit: ) – potrivire adresei MAC sursă a
pachetului;
 ttl (integer: 0..255; implicit: ) – potrivire valorii TTL a pachetelor ş.a.
La procesarea regulilor ce ţin de un lanţ, acestea se examinează în ordinea
listării lor, de sus în jos. Dacă pachetul se potriveşte criteriului unei reguli,
181
atunci se aplică acţiunea specificată în ea şi nu mai sunt procesate şi alte reguli
ale lanţului, excepţie fiind doar acţiunile: passthrough şi log. Dacă pachetul nu
se potriveşte nici unui criteriu, atunci el este acceptat.
5.2.3. Protecţia ruterului la intrare – reguli de filtrare input
Lanţurile de intrare (input) sunt monitorizate, în scopul securizării ruterului
înseşi. Pachetele adresate către ruter au în antet, ca adresă destinaţie (dst),
adresa IP a ruterului. Asemenea pachete conţin, de regulă, informaţii de
comunicare privind conexiunile iniţiate de ruter sau informaţii de administrare
şi configurare a ruterului. Acest fapt şi trebuie luat în consideraţie, la stabilirea
de filtre pentru lanţurile de intrare. Oportună, în acest sens, este
monitorizarea [4]:
 protocoalelor şi porturilor folosite pentru administrarea ruterului;
 serviciilor oferite de ruter.
Problema este una relativ complexă, necesitând experienţă. Cel mai simplu
caz constă în securizarea ruterului, blocând tot, în afară de calculatorul propriu
conectat la ruter. Adică toate pachetele, trimise de calculator ruterului, să fie
acceptate, iar toate celelalte pachete să fie blocate (eliminate). În acest scop,
sunt necesare două reguli.
Pentru setarea primei reguli, de acceptare a tuturor pachetelor trimise de
calculator către ruter, se acţionează /IP/Firewall/Firewall/Filter Rules, +/New
Firewall Rule/General. Se va afişa fila General a ferestrei New Firewall Rule, în
lista derulantă Chain a căreia se va selecta, prin clic, lanţul input (fig. 5.3a), iar
în câmpul Src. Address (adresa sursei) se va specifica adresa IP a calculatorului
(în fig. 5.3a, adresa 192.168.20.1). Apoi, în fila Action a ferestrei New Firewall
Rule, lista derulantă Action, se va selecta acţiunea accept, încheind cu
apăsarea butonului OK (fig. 5.3b).
a) b)
Fig. 5.3. Setarea regulii input accept.
Astfel, prima regulă input poate fi descrisă ca {Chain – input, Src. Address –
192.168.20.1, Action – accept}. În scopul verificării păstrării accesului la ruter
de la calculator, se poate lansa un explorator Web și accesa un server din
Internet. Accesul ar trebui să reușească.
Pentru setarea celei de a doua reguli, de eliminare a pachetelor trimise de
la alte adrese IP către ruter, se acţionează /IP/Firewall/FilterRules, +/New
Firewall Rule/General. În lista derulantă Chain a filei General se va selecta
182
lanțul input (fig. 5.4a), iar în lista derulantă Action a filei Action se va selecta
acţiunea drop. Apoi se va apăsa butonul OK (fig. 5.4b).
a) b)
Fig. 5.4. Setarea regulii input drop.
A doua regulă input poate fi descrisă ca {Chain – input, Action – drop}. În
scopul verificării păstrării accesului la ruter de la alte calculatoare, se poate
modifica adresa IP a calculatorului (pentru cazul din figura 5.3, înlocuind adresa
192.168.20.1 cu, cea, de exemplu, 192.168.20.2), lansa un explorator Web și
încerca de a accesa un server din Internet. Încercarea ar trebui să eşueze.
De menţionat că a doua regulă, dacă ar fi de una singură sau ar fi prima în
lista de reguli, ar bloca complet intrările de pachete în ruter. Dar dacă în lista
de reguli, înregistrate în fereastra Filter Rules, mai întâi figurează prima regulă
(accept) şi doar apoi – cea de a doua (drop), atunci scopul formulat mai sus va
fi atins. La recepţia unui pachet, ruterul îl va verifica, mai întâi, conform primei
reguli şi, dacă va corespunde acesteia (va fi de la adresa 192.168.20.1), atunci
pachetul va fi acceptat; dacă însă pachetul nu va corespunde primei reguli,
atunci ruterul îl va verifica conform celei de a doua reguli (orice pachet,
independent de sursă), blocându-l (eliminându-l). Astfel, este importantă şi
ordinea, în care figurează regulile în lista înregistrărilor ferestrei Filter Rules:
conformitatea cu regulile se verifică în ordinea figurării acestora în listă şi dacă
pachetul corespunde regulii curente, atunci nu se mai verifică şi conformitatea
cu regulile ce urmează în listă.
Cele două reguli input pot fi
vizualizate în fila Filter Rules (fig. 5.5) a
ferestrei Firewall sau lansând, în linia de
comandă a ferestrei Terminal, comanda
ip firewall filter print (fig. 5. 6).
Fig. 5.5. Lista regulilor de filtrare.
Fig. 5.6. Afișarea listei regulilor de filtrare din linia de comandă Terminal.
183
Pot servi [1] ca exemple de reguli input de protejare a ruterului, cele
formate prin lansarea din linia de comandă Terminal a comenzii > ip firewall
filter add:
 chain=input connection-state=invalid action=drop
(eliminarea pachetelor ce ţin de conexiuni încă ne stabilite);
 chain=input connection-state=established action=accept
(acceptarea pachetelor ce ţin de conexiuni deja stabilite);
 chain=input protocol=icmp action=accept
(acceptarea pachetelor ICMP);
 chain=input src-address=192.168.20.0/24 action=accept in-interface=!ether1
(acceptarea pachetelor din subreţeaua locală la toate interfeţele
ruterului cu excepţia celei ether1);
 chain=input action=drop
(blocarea tuturor celorlalte pachete).
Sarcina practică 5.1. Definirea de reguli input:
1. De adăugat regula accept doar pentru calculatorul propriu.
2. De adăugat regula drop pentru toate celelalte adrese IP.
3. De încercat accesul la Internet de la calculator, aplicând comanda ping din
linia de comandă Terminal sau printr-un explorator Web. Conectarea ar
trebui să reuşească.
4. De modificat adresa IP la calculator cu o altă adresă din aceeaşi subreţea.
5. De încercat accesul la ruter de la calculator, aplicând, din linia de comandă
cmd a Windows, comanda ping către adresa IP a interfeţei ruterului.
Conectarea nu ar trebui să reuşească.
6. De încercat conectarea de la calculator la ruter prin WinBox, folosind adresa
IP a interfeţei ruterului. Conectarea nu ar trebui să reuşească.
7. De încercat conectarea de la calculator la ruter prin WinBox, folosind adresa
MAC a interfeţei ruterului. Conectarea ar trebui să reuşească, deoarece
filtrul i-barierei se răsfrânge doar asupra adreselor IP.
8. De revenit la adresa IP a calculatorului şi de verificat accesul la Internet.
Notă. La necesitate, pentru o mai mare securitate, se poate dezactiva accesul MAC
la ruter, folosind submeniul MAC Server. Doar că într-un asemenea caz, dacă se
întâmplă că nu este posibilă conectarea la ruter prin IP, ruterul va trebui resetat. Iar dacă
nu a fost creată nici o copie de rezervă a configurărilor ruterului, acestea pot fi pierdute.
Starea interfeţelor ruterului, activată/dezactivată, poate fi vizualizată în
fereastra MAC Server, ce se va afişa la acţionarea /Tools/MAC Server. Pentru
dezactivarea accesului MAC printr-o interfață anume, în fereastra MAC Server,
fila Telnet Interfaces sau cea WinBox Interfaces, se va executa dublu-clic pe
înregistrarea ce ține de interfața respectivă, rezultând afișarea casetei de dialog
MAC Telnet Server sau, respectiv, cea MAC WinBox Server. Dacă înregistrarea
se referă la toate intefeţele, atunci în lista derulantă Interface se va selecta
interfaţa necesară, iar apoi se va apăsa butonul Disable.
184
5.2.4. Protecţia clienţilor de tranzit – reguli de filtrare forward
Regulile de filtrare a înaintării (forward) ţin de lanţul forward şi permit
controlul pachetelor ce tranzitează ruterul de la/către staţiile ce stau în
spatele i-barierei. Aceste pachete sunt monitorizate, în scopul securizării
staţiilor în cauză. La configurarea unor reguli forward, sunt necesare informații
privind numerele de porturi și protocoalele care le folosesc. Unele din acestea
sunt prezentate în anexa 3, iar cele larg folosite de RouterOS – în tabelul 5.1.
Tabelul 5.1. Numere de porturi și protocoale larg folosite
Protocol de nivel Aplicații, protocoale de
Număr port
Transport sau Internet nivel Aplicație, comenzi
20, 21 TCP FTP
22 TCP SSH
23 TCP Telnet
53 TCP/UDP DNS
123 UDP NTP
443 TCP HTTPS, SSL
5678 UDP MNDP
8080 TCP Proxy
8291 TCP WinBox
20561 UDP MAC-WinBox
/1 ICMP ping
Sarcina practică 5.2. Definirea de reguli forward:

1. De adăugat o regulă, care ar bloca portul destinație 80 al TCP pentru
calculatorul utilizatorului. În acest scop se va acționa /IP/Firewall/FIlter
Rules, +. Apoi în fereastra New Firewall Rule ce se va afișa: în fila General,
Chain – forward, Protocol – TCP, Dst. Port – 80; în fila Action, Action –
drop/OK. Rezultatul ar trebui să fie apariția noii reguli în fila Filter Rules (în
figura 5.7 – regula 1).
2. De încercat posibilitatea accesării de la calculator a unui server Web din
Internet, de exemplu a celui www.mikrotik.com. Accesul nu ar trebui să
reușească.
3. De încercat posibilitatea accesării paginii Web a ruterului, la care este
conectat calculatorul (http://192.168.x.254). Accesul ar trebui să reușească.
De ce?
4. De adăugat o regulă, care ar bloca traficul p2p. În acest scop, în fereastra
New Firewall Rule: în fila General, Chain – forward, P2P – all p2p; în fila
Action, Action – drop.
5. De verificat apariția noii reguli în fila Filter Rules (în figura 5.7 – regula 2).
6. De eliminat cele două reguli forward nou create.
185
Fig. 5.7. Regulile 1, 2 create conform sarcinii 5.2.
5.2.5. Procesarea pachetelor generate de ruter – reguli output
Regulile output se folosesc pentru procesarea pachetelor generate de ruter
şi destinate altor dispozitive. Acestea pot pachete ce ţin de comenzi ping de la
ruter, răspunsuri ale ruterului la comenzi ping, crearea de tunele, folosirea
sistemului proxy Web ş.a. Regulile output nu se aplică la procesarea
pachetelor de tranzit prin ruter.
5.3. Monitorizarea conexiunilor

5.3.1. Reguli log de înregistrare
RouterOS poate înregistra (log) o multitudine de evenimente şi informaţii
de stare a diverselor procese. Înregistrările se efectuează pe tematici, inclusiv:
info (implicită), critical, firewall, packet, hotspot, l2tp, ppp, route, account,
pppoe, dhcp, pptp, bgp, error, ipsec, event, isdn, ospf, telephony, wireless, e-
mail, gsm, ntp, rip ş.a. Lista înregistrărilor curente poate fi vizualizată în
fereastra meniului /Log. Regulile log pot fi definite în fereastra Logging ce se
va afişa la acţionarea /System/Logging.
Regulile log pot fi folosite pentru monitorizarea activității utilizatorilor și a
funcționării anumitor servicii. De exemplu, folosind așa reguli, se poate ține
evidența paginilor Web și a orei de accesare a lor pentru fiecare utilizator.
Asemenea informații pot fi utile, inclusiv, pentru identificarea cauzelor
apariției unor situații de căderi în rețea.
Reguli log pot fi definite şi pentru i-bariere.
Exemplul 5.1. Adăugarea unei reguli log ce ar fixa aplicarea comenzilor
ping din partea stațiilor către ruter. Regula log în cauză trebuie să fie înaintea
altor reguli. Comenzile ping de la stații pot fi către ruter sau către stații din
Internet. Cele către ruter țin de lanțul input, iar cele către stații din Internet –
de lanțul forward. Toate ele însă folosesc protocolul ICMP. Astfel, pentru
crearea regulii în cauză, se acţionează /IP/Firewall/Filter Rules, +. Apoi în
fereastra New Firewall Rule ce se va afișa: în fila General, Chain – input,
Protocol – ICMP (fig. 5.8a); în fila Action, Action – log, Log Prefix – ICMP (fig.
5.8b). Rezultatul ar trebui să fie apariția regulii log în fereastra Filter Rules.
186
a) b)
Fig. 5.8. Crearea regulii log ICMP.
Efectul aplicării regulii log poate fi vizualizat în fereastra meniului /Log al
WinBox.
Sarcina practică 5.3. Definirea de reguli log:
1. De adăugat o regulă log, care ar ține evidența trimiterii de comenzi ping
către serverul www.mikrotik.com.
2. De verificat apariția regulii log în Filter Rules.
3. De lansat, din linia de comandă Terminal, comanda ping către serverul
www.mikrotik.com.
4. De vizualizat înregistrările din meniul /Log.
5.3.2. Lanțuri create de utilizator
De rând cu lanțurile de filtrare implicite (input, forward și output),
utilizatorul poate crea lanțuri proprii. Asemenea lanțuri de reguli pot fi
referitoare la i-viruși, protocoalele TCP și UDP ș.a. La o folosire reușită a
posibilităților în cauză, poate fi simplificată structura i-barierei și redusă
încărcarea ruterului.
Pentru trecerea, de la reguli ale lanțurilor implicite, la cele ale lanțurilor
create de utilizator și înapoi, se folosesc acțiunile jump și, respectiv, return (fig.
5.9). Conform figurii 5.9, în anumite condiții, regula 3 a lanțului forward
prevede acțiunea jump de trecere către începutul lanțului de reguli virusi. Se
poate întâmpla ca, după parcurgerea unei părți din regulile acestui lanț (în fig.
5.9 – regula c), să se îndeplinească condiția de întoarcere către lanțul forward,
folosind acțiunea return. Dar este posibil și cazul, când întoarcerea către
următoarea regulă a lanțului forward să fie doar după parcurgerea tuturor
regulilor lanțului virusi (în fig. 5.9 – regula e).
5.3.3. Reguli folosind starea conexiunilor
După cum a fost menţionat în s. 5.1.2, una din căile eficiente de protejare a
reţelelor constă în folosirea, pentru filtrarea pachetelor, a stării (statutului)
conexiunilor de transfer date (cum ar fi fluxurile TCP, comunicările UDP).
Regulile respective pot permite trecerea doar a pachetelor ce ţin de
conexiunile cunoscute. La stabilirea unei conexiuni noi, se verifică
corespunderea acesteia politicii de securitate definite. Ulterior, toate
pachetele sesiunii curente, ce ţin de această conexiune, sunt acceptate.
187
forward virusi
1 Regulă i-barieră .
a Regulă i-barieră
2 Regulă i-barieră b Regulă i-barieră
action=jump
3 jump target=virusi c action=return
.
4 Regulă i-barieră
.
d Regulă i-barieră
Ultima regulă Ultima regulă
5 i-barieră
e i-barieră
Fig. 5.9. Folosirea acțiunilor jump și return.
Pentru folosirea informaţiilor de stare a conexiunilor, ultimele trebuie
caracterizate respectiv. Fiecare conexiune se stabileşte între aplicaţiile
perechii de staţii ce comunică. Staţiile, între care se transferă date, se
identifică prin adresele IP ale interfeţelor de reţea ale lor: adresa sursei (src.
address) şi adresa destinaţiei (dst. address). Concretizează, suplimentar,
conexiunea portul de soclu Internet (vezi anexa 3), prin care se efectuează
transferul de pachete – port specificat prin numărul lui. Astfel, o conexiune se
identifică prin adresa sursei, adresa destinaţiei şi portul de comunicaţie.
Este posibilă, de asemenea, şi concretizarea mai detaliată a conexiunii de
transfer date, specificând protocolul de nivel Transport folosit, protocolul de
nivel Aplicaţie implicat de aplicaţia sursă a pachetelor ş.a. Unele caracteristici
ale conexiunilor folosite de RouterOS pot fi vizualizate în fila Connections a
ferestrei Firewall.
În ce priveşte starea, în RouterOS se disting conexiuni: noi (new), stabilite
(established), aferente (related) şi nevalide (invalid). O conexiune este nouă
(new), dacă setul de valori ale parametrilor ce caracterizează o conexiune nu
se regăseşte printre cele ale conexiunilor cunoscute de staţiile ce comunică şi,
totodată, aceasta corespunde, după anumiţi parametri, politicii de securitate
definite. Starea de conexiune nouă este considerată doar pentru primul
pachet al acesteia. Următoarele pachete, ce ţin de această conexiune, deja se
procesează ca pachete ce ţin de o conexiune stabilită (established). Pachetele,
ce ţin de conexiuni noi şi stabilite, trebuie acceptate.
O conexiune aferentă (related) este una generată (derivată) de o
conexiune stabilită. În cazul unei asemenea conexiuni, un pachet startează o
conexiune nouă, dar asociată cu o conexiune stabilită, aşa ca: transferul de
date FTP sau al unui mesaj de eroare ICMP. O asemenea conexiune poate fi
188
considerată parte a unei conexiuni stabilite, dar cu o parte din valori ale
parametrilor ce o caracterizează diferiţi de cele ale conexiunii stabilite sursă
(părinte). Pachetele ce ţin de conexiuni aferente trebuie acceptate.
O conexiune este nevalidă, dacă aceasta nu este una stabilită şi nici nu
corespunde cerinţelor către o conexiune nouă. Ţine de o conexiune nevalidă
un pachet care are, de exemplu, un număr de secvenţă nevalid; pot să nu
corespundă şi valori ale altor parametri. Pachetele ce ţin de conexiuni nevalide
trebuie eliminate din reţea. Ele pot fi încercări ale unor răuvoitori de a insera i-
viruşi, etc.
Definirea de reguli pentru i-bariere, folosind starea conexiunilor permite
reducerea procesărilor cu pachetele. Astfel, pachetele ce ţin de conexiuni noi,
stabilite şi aferente trebuie acceptate, iar cele ce ţin de conexiuni nevalide –
respinse (eliminate). Mai mult ca atât, din cele acceptate, doar pachetele ce
ţin de conexiuni noi (primul pachet pentru fiecare conexiune) trebuie
procesate referitor la corespunderea acestora politicii de securitate definite.
Pentru celelalte pachete este suficientă identificarea apartenenţei lor uneia
din conexiunile stabilite sau aferente cunoscute.
Sarcina practică 5.4. Definirea de reguli folosind starea conexiunilor:
1. Adăugarea de reguli se face ca şi în sarcinile practice 5.1, 5.2 şi exemplul
5.1. Dacă este necesar, unele reguli din fila Filter Rules a ferestrei Firewall
pot fi dezactivate, selectându-le (prin clic), iar apoi executând clic pe
butonul . Înregistrările active au culoare ordinară, iar cele dezactivate –
culoare sură pală.
2. De adăugat o regulă drop pentru pachetele cu starea invalid: Chain –
forward, Connection State – invalid, Action – drop.
3. De adăugat o regulă accept pentru pachetele cu starea established: Chain –
forward, Connection State – established, Action – accept.
4. De adăugat o regulă accept pentru pachetele cu starea related: Chain –
forward, Connection State – related, Action – accept.
5. De adăugat o regulă accept pentru pachetele cu starea new: Chain –
forward, Connection State – new, Action – accept.
Regulile create ar trebui să fie similare celor 1-4 din figura 5.10.
Fig. 5.10. Patru reguli (1-4), folosind starea conexiunilor.
189
5.4. Liste de adrese
Facilitatea Liste de adrese (Address lists) permite crearea de către utilizator
a unor grupuri de adrese cu reguli de i-barieră comune. Astfel, folosind o
singură regulă pot fi filtrate, de exemplu, toate adresele unei liste. În listele de
adrese pot fi adăugate adrese sursă şi adrese destinaţie în mod automat şi, de
asemenea, la necesitate, acestea pot fi blocate.
Listele de adrese pot fi folosite în reguli de filtrare, mangle şi NAT.
Folosirea listelor de adrese facilitează administrarea şi creează condiţii pentru
creşterea vitezei de lucru a ruterului.
O listă de adrese se caracterizează prin nume şi adresele IP incluse în ea şi
are următorii parametri/proprietăţi (properties):
 address (adresa IP/masca de reţea | IP-IP; implicit: ) – adresa sau şirul
de adrese IP de adăugat la lista de adrese;
 list (şir; implicit: ) – numele listei de adrese IP, în care trebuie de adăugat
adresa sau şirul de adrese IP.
Listele de adrese pot conţine, de rând cu adrese aparte, şi toate adresele
unor subreţele. Pentru crearea (actualizarea) unei liste de adrese, se
acţionează /IP/Firewall/Address Lists, +/ şi, în caseta de dialog New Firewall
Address List ce se va afişa, în lista derulantă Name, se specifică (se selectează,
dacă lista deja este) numele listei (în exemplul din figura 5.11 – Admis), iar în
câmpul Address – adresa IP, adresa de subreţea sau un şir de adrese de
adăugat în listă (în exemplul din figura 5.11 – 192.168.21.6).
În exemplul din figura 5.11, sunt create două liste de adrese Admis şi
Blocare. În lista Admis sunt înregistrate toate adresele ce ţin de subreţeaua
192.168.20.0/24 şi adresa 192.168.21.1; de asemenea, după apăsarea
butonului OK din caseta de dialog New Firewall Address List, în listă se va
adăuga şi adresa 192.168.21.6. În lista Blocare este înregistrat şirul de adrese
192.168.21.2-192.168.21.5.
Fig. 5.11. Crearea de liste de adrese.

Pentru adăugarea automată a unor adrese într-o listă de adrese, în
fereastra New Firewall Rule, fila Action: în lista derulantă Action se selectează
add src to address list (adrese surse) sau add dst to address list (adrese
destinaţie), după necesitate; în lista derulantă Address List se selectează
190
numele listei de adrese; în câmpul Timeout se specifică perioada de timp, pe
parcursul căreia in listă se adaugă adrese (fig. 5.12).
Fig. 5.12. Adăugarea automată de adrese surse în lista Admis.

Adăugarea regulii de acceptare a pachetelor, ce provin de la sursele cu
adresele listei Admis, este prezentată în figura 5.13: în fila Advanced, lista
derulantă Src. Address List, se selectează lista Admis (fig. 5.13a), iar în fila
Action, lista derulantă Admis, se selectează acţiunea accept (fig. 5.13b).
a)
b)
Fig. 5.13. Adăugarea regulii de acceptare pentru lista Admis.

Listele de adrese ale i-barierei pot fi vizualizate, de asemenea, aplicând, din
linia de comandă Terminal, comanda: ip firewall address-list print (fig. 5.14).
Fig. 5.14. Afişarea listelor de adrese din linia de comandă Terminal.

Sarcina practică 5.5. Crearea de liste de adrese şi reguli cu folosirea lor:
1. De creat lista de adrese Admis Internet cu adresele IP ale trei calculatoare
din subreţeaua locală, cărora li se va permite accesul la Internet.
2. De adăugat o regulă accept pentru lista Admis Internet, acţionând
/IP/Firewall/Filter Rules, +/fila General, Chain – forward, In. Interface –
interfaţa_ruterului_la_care_este_conectat_calculatorul (în fig. 5.15 –
ether2)/fila Advanced, Src. Address List – Admis Internet/fila Action, Action
191
– accept. Apoi se apasă butonul OK. Regula adăugată trebuie să fie similară
celei 0 din fig. 5.15.
3. De adăugat o regulă drop pentru toate celelalte adrese IP: fila General,
Chain – forward, In. Interface – interfaţa_ruterului_la_care_este_
conectat_calculatorul/fila Action, Action – drop. Regula adăugată trebuie
să fie similară celei 1 din fig. 5.15.
4. De verificat posibilitatea accesului de la calculator la Internet. Accesul ar
trebui să reuşească.
5. De înlocuit adresa IP a calculatorului cu una ce nu este în lista Admis
Internet. De verificat posibilitatea accesului de la calculator la Internet.
Accesul ar trebui să nu reuşească.
6. De revenit la adresa IP iniţială a calculatorului şi de verificat din nou
posibilitatea accesului de la calculator la Internet.
Fig. 5.15. Folosirea listei de adrese Admis Internet.
5.5. Sistemul de translatare a adreselor NAT

5.5.1. Noţiune NAT
Translatarea adreselor de reţea este necesară, pentru realizarea
schimbului de date cu staţii din Internet a staţiilor unei reţele interne, ce au
adrese IPv4 private (vezi s. 1.5.2). Adresele IPv4 private nu sunt rutabile în
Internet şi de aceea staţiile cu asemenea adrese nu pot efectua, în mod direct,
schimbul de date cu staţii din Internet.
NAT realizează, în funcţie de caz, înlocuirea adresei private IP sursă sau a
celei IP destinaţie cu o adresă IP publică şi a portului sursă sau a portului
destinaţie a fiecărui pachet de tranzit, ascunzând, de mediul exterior, staţiile
reţelei private în spatele uneia sau a mai multe adrese IP publice. Această
ascundere se realizează:
1) la înlocuirea adresei private IP sursă şi a portului sursă, pentru staţiile-
surse de pachete ale reţelei private;
2) la înlocuirea adresei private IP destinaţie şi a portului destinaţie, pentru
staţiile-destinaţie de pachete ale reţelei private, de exemplu servere Web.
Translatarea adreselor de reţea (network address translation – NAT) este
realizată de un i-program ce operează conform protocolului Internet respectiv,
definit în RFC 2663 şi ulterior dezvoltat în RFC 3489 şi RFC 5389. Acesta
192
permite adresarea mai multor dispozitive, ce au adrese IP private, folosind o
singură adresă IPv4 publică. NAT, fiind implementat în cadrul ruterelor,
modifică informaţia ce ţine de adresa IP în antetele pachetelor IPv4.
Există o mare varietate de realizări NAT. Cea mai simplă din ele realizează
traslatarea adreselor IP „una-la-una”. Însă cea mai largă utilizare a cunoscut
NAT „una-la-multe”, adică „o singură adresă IP publică – la mai multe adrese
IP private”. Anume acest tip de NAT este implementat în RouterOS, operarea
lui fiind transparentă, atât pentru staţiile interne, cât şi pentru cele externe.
Când o staţie a reţelei private (internă) transmite un pachet către o staţie
externă, NAT înlocuieşte adresa IP privată, în câmpul Adresa sursei a antetului
pachetului, cu adresa publică a unităţii NAT (interfeţei ruterului către reţeaua
externă). Ulterior, pachetul este transmis către reţeaua externă. Totodată,
NAT introduce, în tabelul de translatare a adreselor, o înregistrare ce conţine
adresa IP internă (privată) şi alte informaţii ce ţin de conexiunea în cauză
(portul sursă, adresă destinaţie, portul destinaţie, etc.). Toate pachetele
ulterioare, ce ţin de aceeaşi conexiune, sunt translatate în mod similar.
Înregistrarea în cauză, în care sunt specificate date privind conexiunea
realizată, este folosită de asemenea şi pentru pachetele de răspuns din
Internet către staţia cu adresa IP privată în cauză, realizând translatarea
inversă necesară.
NAT RouterOS operează conform unor reguli de structură If-Then, ce se
definesc în fila NAT a ferestrei Firewall (/IP/Firewall/NAT). Acţiunile NAT sunt:
accept, add dst to address list, add src to address list, dst-nat, jump, log,
masquerade, netmap, passthrouth, redirect, return şi src-nat. Funţiile
majorităţii acestora sunt descrise în s. 5.2.2. Destinaţia celorlalte este:
 dst-nat – realizarea funcţiei NAT destinaţie (vezi s. 5.5.3);
 masquerade – realizarea funcţiei NAT sursă, când nu se cunoaşte adresa
publică a interfeţei externe (Out. Interface) a ruterului (vezi s. 5.5.2);
 netmap – maparea statică 1:1 a unui set de adrese IP în alt set. Se
foloseşte deseori pentru distribuirea adreselor IP publice staţiilor în
reţele private;
 redirect – înlocuirea adresei destinaţie a pachetelor IP cu una din
adresele locale ale ruterului, redirecţionând pachetele către ruter (vezi s.
5.5.3);
 src-nat – realizarea funcţiei NAT sursă, când se cunoaşte adresa publică a
interfeţei externe (Out. Interface) a ruterului (vezi s. 5.5.2).
5.5.2. NAT sursă
Înlocuirea cu o adresă IP publică a adresei IP private a unei surse, ce
iniţiază un transfer de date către o destinaţie din Internet, se efectuează de
către NAT sursă (src-nat) – fig. 5.16. Asupra pachetelor de răspuns de la staţii
193
externe către sursa iniţiatoare a transferului de date, NAT sursă efectuează o
translatare inversă a adresei IP.
Sursă iniţiatoare Destinaţie
cu adresă IP privată din Internet
src-nat
Private IP Public IP Internet
src-address Ruter src-address
Fig. 5.16. Amplasarea şi funcţia NAT sursă (src-nat).
NAT sursă serveşte pentru reprezentarea în Internet prin adrese IP publice

a staţiilor cu adrese IP private din cadrul unei reţele interne din spatele NAT. El
operează conform regulilor NAT ce ţin de lanţul srcnat.
Una din cele mai simple acţiuni ale regulilor ce ţin de lanţul srcnat, este
masquerade. Aceasta este destinată realizării translatării adreselor IP private
într-o adresă IP publică, dar necunoscută la momentul creării regulii NAT sursă
respective. Asemenea situaţii au loc, de exemplu, atunci, când adresa
interfeţei externe a ruterului (Out. Interface), pe care rulează NAT, este una
dinamică ce se obţine prin DHCP. Procedura definirii regulii masquerade este
descrisă în s. 4.5.2.
Sarcina practică 5.6. Definirea regulii masquerade pentru un port anume:
1. Regula masquarade, descrisă în s. 4.5.2, a fost definită pentru toate
porturile. În unele cazuri este oportun de definit această regulă doar pentru
anumite porturi. Fie că este necesar ca regula masquerade să asigure
accesul doar la servere Web nesecurizate (http). În acest scop este necesar
de folosit protocolul TCP, portul 80 (vezi anexa 3).
2. De dezactivat regula masquerade curentă. Pentru aceasta, se va acţiona
/IP/Firewall/NAT/, se va selecta înregistrarea respectivă şi se va apăsa
butonul ).
3. De adăugat o regulă masquerade, care ar asigura accesul doar la servere
Web nesecurizate. Pentru aceasta, în fila NAT se va acţiona +/fila General,
Chain – srcnat, Protocol – tcp, Dst. Port – 80, Out. Interface – wlan1 (fig.
5.17)/fila Action, Action – masquerade/OK. Înregistrarea noii reguli
maquerade va apare în fila NAT (înregistrarea 1, în fig. 5.18).
4. De verificat accesibilitatea de la calculator a serverului Web
www.yahoo.com. Accesarea ar trebui să reuşească.
5. De verificat accesibilitatea de la calculator a serverului Web https://mail.ru.
Accesarea nu ar trebui să reuşească, deoarece regula masquerade a fost
definită doar pentru servere Web nesecurizate. Pentru servere Web
securizate, se foloseşte tot protocolul TCP, dar portul fiind 443 (nu cel 80).
6. De activat regula masquerade iniţială şi de o eliminat pe cea nouă.
194
Fig. 5.17. Definirea regulii masquerade pentru protocolul TCP, portul 80.
Fig. 5.18. Regula masquerade pentru protocolul TCP, portul 80 în NAT.

Dacă interfaţa externă a ruterului (Out. Interface), pe care rulează NAT,
este una statică, atunci este rezonabil de folosit nu acţiunea masquerade, ci
cea src-nat, care va fi mai rapidă, deoarece aceasta nu necesită procesări
pentru a afla adresa IP externă.
5.5.3. NAT destinaţie
După cum a fost menţionat în s. 5.5.2, la iniţierea de către o sursă cu
adresă IP privată a unui transfer de date către o destinaţie din Internet,
translatarea adresei se efectuează de către NAT sursă. Dar poate fi şi invers,
când o sursă din Internet iniţiază un transfer de date către o destinaţie, ce se
găseşte în spatele NAT şi a cărei adresă IP nemijlocită este una privată; în
asemenea cazuri translatarea adresei staţiei destinaţie se efectuează de către
NAT destinaţie.
Cu alte cuvinte, NAT destinaţie (dst-nat) serveşte pentru reprezentarea în
Internet prin adrese IP publice a staţiilor cu adrese IP private din cadrul unei
reţele interne din spatele NAT (de exemplu, servere Web), când către acestea
195
se iniţiază transferuri de date de către staţii din Internet. El operează conform
regulilor NAT ce ţin de lanţul dstnat (fig. 5.19).
Adresare destinaţie Sursă iniţiatoare
cu adresă IP privată din Internet
dst-nat
Private IP Public IP Internet
dst-address Ruter dst-address
Fig. 5.19. Amplasarea şi funcţia NAT destinaţie (dst-nat).
Exemplul 5.2. Definirea unei reguli dst-nat. Fie adresa IP publică a

interfeţei externe a ruterului este 207.141.24.25 şi din Internet se iniţiază
accesul la un server Web nesecurizat din spatele NAT cu adresa privată
192.168.1.1. Pentru definirea regulii dst-nat în cauză, se acţionează
/IP/Firewall/NAT, +/New NAT Rule/fila General, Chain – dstnat, Dst. Address
– 207.141.24.25, Protocol – tcp, Dst. Port – 80 (fig. 5.20a)/fila Action, Action –
dst-nat, To Address – 192.168.1.1, To Ports – 80/OK (fig. 5.20b).
a) b)
Fig. 5.20. Definirea unei reguli dst-nat.
O formă specifică de NAT destinaţie este redirect. Aceasta este similară
NAT destinaţie în aceeaşi măsură, în care masquerade este similară NAT sursă.
Redirect, ca şi masquerade, nu foloseşte to-adderesses¸ aplicând implicit în
acest scop adresa interfeţei de intrare (In. Interface) a ruterului. Astfel, spre
deosebire de NAT destinaţie, la definirea unei reguli pentru care în fila Action
se completează câmpul To Addresses cu adresa privată a destinaţiei din
spatele NAT, la definirea unei reguli redirect, nu se completează acest câmp,
implicit considerându-se interfaţa de intrare a ruterului. Totuşi, se specifică, în
funcţie de necesitate, câmpul To Ports.
196
redirect
dst-address a
serverului DNS Ruter
dst-address nouă a
cache DNS la ruter
Fig. 5.21. Amplasarea şi funcţia regulii redirect (dstnat).
Exemplul 5.3. Definirea de reguli redirect. Fie că este necesară folosirea de
către staţiile locale a înregistrărilor cache ale DNS de la ruter (se consideră că
pe ruter funcţionează serverul DNS). DNS foloseşte portul 53 (vezi anexa 3),
atât cu protocolul TCP, cât şi cu cel UDP. Deoarece sunt două protocoale, este
nevoie de două reguli redirect: una pentru pachete TCP şi alta pentru pachete
UDP. În scopul definirii regulii redirect pentru protocolul TCP, se acţionează
/IP/Firewall/NAT, +/New NAT Rule/fila General, Chain – dstnat, Protocol –
tcp, Dst. Port – 53 (fig. 5.22a)/fila Action, Action – redirect, To Ports – 53/OK
(fig. 5.22b).
a) b)
Fig. 5.22. Definirea regulii redirect de redirectare la DNS local.
În acelaşi mod, ca în figura 5.22 pentru protocolul TCP, se defineşte şi
regula redirect pentru protocolul UDP, cu deosebirea că în câmpul Protocol al
filei General se va selecta udp şi nu tcp (fig. 5.22).
5.5.4. Limitări NAT
Staţiile, cu adrese IP private din spatele unui ruter cu NAT, nu dispun de
conectivitate staţie-la-staţie reală. Unele protocoale Internet pot să nu lucreze
fiabil prin NAT. Mai mult ca atât, unele protocoale nu sunt compatibile cu
folosirea NAT, de exemplu cel AH (Authentication Header) al suitei IPsec.
Cauza constă în aceea că procedurile NAT examinează doar antetele IP, UDP şi
TCP, nu şi interiorul pachetelor/segmentelor. Pentru ca un asemenea protocol
197
să lucreze corect cu NAT, este necesar un asistent de monitorizare a
conexiunilor (connection tracking)
RouterOS include un şir de asistenţi (helpers) NAT, care permit extinderea
folosirii NAT de către şase protocoale: ftp, h323, irc, pptp, sip şi tftp. Funcţia
lor constă în identificarea pachetelor ce folosesc protocoalele în cauză.
Ulterior, aceste informaţii se folosesc de către NAT, dar şi la monitorizarea
conexiunilor.
Asistenţii NAT devin accesibili acţionând
/IP/Firewall/Service Ports (fig. 5.23). Prin
clic pe înregistrarea respectivă, se va afişa o
casetă de dialog, folosind opţiunile căreia
asistentul poate fi activat sau dezactivat,
după necesitate. De asemenea, asistenţii
permit modificarea portului prin care
operează. Implicit asistenţii sunt activaţi şi,
de obicei, nu este necesar de efectuat
careva modificări, cu excepţia cazurilor, Fig. 5.23. Accesarea asistenţilor NAT.
când vreunul din protocoalele respective se foloseşte cu un alt port.
5.6. Alte informaţii privind folosirea i-barierelor

Pentru facilitarea înţelegerii şi operării cu regulile i-barierei, se recomandă:
1. De a adăuga comentarii la reguli. În acest scop, în fereastra New Firewall
Rule a regulii ce se defineşte, se va apăsa butonul Comment, iar apoi, în caseta
de dialog Comment for New Firewall Rule ce se va afişa, se va specifica
comentariul de context;
2. De a folosi informația de stare
Connection Tracking a tuturor
conexiunilor active, inclusiv: adresele IP
şi porturile sursă şi destinaţie, starea
conexiunii, tipul protocolului ş.a. Ea se
activează pentru reguli Filter şi NAT.
Pentru activarea acestei funcţii, se
acţionează /IP/Firewall/Connections/
Tracking şi, în caseta de dialog
Connection Tracking ce se va afişa, se
bifează caseta Enabled (fig. 5.24); Fig. 5.24. Afişarea şi informaţii
3. De a folosi funcţia Torch de Connection Tracking.
monitorizare a traficului de date printr-o interfaţă anume. Traficul poate fi
clasificat de Torch după protocol, adresa sursei, adresa destinaţiei, port ş.a.
Pentru a accesa Torch, se acţionează /Tools/Torch, iar pentru al lansa, în
198
fereastra Torch (Running) ce se va afişa, se apasă butonul Start (fig. 5.25).
Pentru a opri Torch, se apasă butonul Stop.
Fig. 5.25. Monitorizarea traficului de date folosind Torch.

4. De a consulta exemplele de configurare a i-barierelor pentru protecţia
ruterului şi a staţiilor locale descrise la adresa wiki.mikrotik.com/wiki/
Manual:IP/Firewall/Filter.
199
6. CALITATEA SERVICIILOR – QoS
6.1. Aspecte generale QoS
6.1.1. Noţiune QoS
Una din caracteristicile de performanță de bază ale unei rețele informatice
este calitatea serviciilor (Quality of Services – QoS). Pentru aprecierea
cantitativă a acesteia, se folosesc diverși indicatori, inclusiv: disponibilitatea
serviciilor; durata de răspuns la cerere; rata pierderilor de pachete; rata
erorilor ș.a. Influențează valorile acestor indicatori așa parametri ai
componentelor rețelei ca: productivitatea calculatoarelor; capacitatea
canalelor de transfer date (viteza de transfer date); fiabilitatea funcționării,
etc.
La un surplus de resurse şi valorificarea rezonabilă a acestora, calitatea
necesară a serviciilor se asigură relativ uşor. Dificultăţi apar în cazurile de
deficit de resurse. În asemenea situaţii, o parte din trafic nu poate fi deservit şi
contează abordarea diferenţiată, în funcție de caracteristicile diverselor
categorii de cereri/servicii. În acest scop se folosește deservirea cererilor pe
priorități.
Capabilitatea QoS poate fi definită ca abilitatea de a oferi prioritate diferită
diferitelor cereri sau de a garanta un anumit nivel de performanță fiecărui flux
de cereri. Astfel, sistemul de gestiune a valorificării eficiente a resurselor
rețelei trebuie să fie adaptat la caracteristicile fluxurilor de cereri de deservit,
capacităţile componentelor reţelei, topologia acesteia şi alţi factori.
Deși diverși indicatori de calitate a serviciilor prestate de rețele de
comunicație și cele de calculatoare se folosesc încă de la lansarea primelor
rețele, pentru prima dată un document oficial, în care apare și abrevierea QoS,
este publicat în 1994 de ITU și ulterior actualizat în 2008.
6.1.2. Funcţionalităţi QoS în RouterOS
RouterOS oferă așa funcționalități privind asigurarea calității serviciilor de
transfer date ca:
 limitarea ratei de date pentru anumite adrese IP, subrețele, protocoale și
porturi;
 limitarea traficului punct-la-punct;
 prioritizarea unor fluxuri de date față de altele;
 deservirea în rafale (bursts) a fluxurilor de date, pentru transferuri mai
rapide;
 aplicarea cozilor pe perioade fixe de timp;
200
 partajarea traficului disponibil între utilizatori în mod egal sau în funcție
de încărcarea canalelor ș.a.
De asemenea, RouterOS oferă unele instrumente de testare, analiză și
monitorizare a traficului, care facilitează administrarea eficientă a rețelelor.
Fiecare coadă, adăugată în /Queues/Simple Queues sau /Queues/Queue
Tree, se ataşează la arborele HTB principal, creând, totodată, câte un sistem
HTB în global-in, global-out și global-total.
6.1.3. Cozi şi discipline în RouterOS
La tranzitarea interfeţelor ruterului, pachetele se organizează în cozi.
Implementarea cozilor în RouterOS se bazează pe sistemul HTB (Hierarchical
Token Bucket – cupă ierarhică cu jeton). HTB (vezi s. 6.1.5) permite crearea de
sisteme ierarhice de cozi cu definirea relaţiilor între cozi.
Sistemele de cozi HTB se organizează pentru fiecare interfaţă fizică de
ieşire a ruterului şi, de asemenea, pentru trei interfețe virtuale adiționale:
 global-in – reprezintă toate interfețele de intrare în general (coada de
intrare). Procesările de ordonare a traficului recepţionat de ruter au loc
îndată după cele mangle şi dst-nat, dar înainte de filtrarea pachetelor;
 global-out – reprezintă toate interfețele de ieşire în general (coada de
ieşire). Procesările de ordonare au loc înainte de cele ce ţin de o anumită
interfaţă;
 global-total – reprezintă toate interfeţele de intrare şi de ieşire ale
ruterului împreună. Se foloseşte în cazurile, în care se aplică o singură
limită sumară a ratei, atât pentru traficul de încărcare cât şi pentru cel de
descărcare. Astfel, dacă este setată o limită totală maximală de 256 Kbps,
atunci este posibilă o viteză sumară maximală de transfer date de
încărcare + descărcare = 256 Kbps.
În caz de necesitate, calitatea necesară a transferului diverselor categorii
de trafic se asigură din contul reținerii (de exemplu, la trafic TCP) sau chiar al
aruncării unor pachete de prioritate mai joasă.
Diversele acțiuni de asigurare a QoS, cu limitarea şi prioritizarea fluxurilor
de date, se descriu în termeni ai teoriei așteptării cu anumite concretizări și
anume:
 disciplina de deservire (qdisc) – definește ordinea acumulării, preluării
pentru deservire și aruncării (în cazul lipsei de spațiu pentru stocare)
pachetelor;
 CIR (Committed Information Rate – rata asigurată de informații) – rata de
date garantată, adică traficul de date ce nu depășește această valoare
trebuie să fie livrat în mod obligatoriu; în RouterOS acest parametru este
notat limit-at;
201
 MIR (Maximal Information Rate – rata maximă de informații) – rata de
date maximă ce poate fi transmisă de ruter; în RouterOS acesta este
notat max-limit;
 prioritatea – ordinea de importanță în care va fi procesat traficul de date;
 raportul de dispută (Contention Ratio – CR) – raportul, până la care rata
stabilită de date este partajată între utilizatori (atunci când o anumită
rată de date este alocată la mai mulți utilizatori). Toți utilizatorii ce
participa la disputa au dreptul la aceeași capacitate de transfer date,
limitată de jos de numărul maxim de asemenea utilizatori. Astfel, dacă CR
este 1:3, atunci numărul maxim de utilizatori ce pot partaja aceeași
capacitate de transfer date sumară este 3.
Pentru fiecare coadă HTB pot fi definite două limite de rată: CIR şi MIR.
Chiar dacă este definit parametrul CIR, dar dacă capacitatea disponibilă nu
este suficientă, atunci rata definită nu se va garanta. De exemplu, dacă pentru
fiecare din primii 10 clienţi CIR = 2 Mbps, MIR = 5 Mbps, iar capacitatea totală
disponibilă este de 10 Mbps, atunci rata de 2 Mbps nu li se va garanta. Dacă
însă capacitatea disponibilă este de 30 Mbps, atunci rata de 2 Mbps se va
garanta primilor 10 clienţi, iar celorlalţi, cărora le-a fost definit doar MIR = 5
Mbps (CIR nu le-a fost definit), rata li se va distribui doar din cea rămasă
nefolosită de primii 10 clienţi.
Disciplinele de deservire, care constau îndeosebi în limitarea şi prioritizarea
traficului de date, se realizează în cadrul firelor de aşteptare (cozilor).
Parametrii cozilor, în RouterOS, pot fi setaţi în submeniurile: /Queues/Simple
Queues (cozi simple) şi /Queues/Queue Tree (cozi arbore). Cozile simple
presupun procesări elementare la abordarea diferenţiată a diverselor categorii
de trafic: limitarea traficului unor staţii aparte, limitarea traficului P2P, etc.
Cozile arbore sunt organizate în formă de arbore şi presupun procesări
avansate la abordarea diferenţiată a diverselor categorii de trafic: politici
globale de prioritizare, limitarea traficului pentru grupuri de utilizatori, etc.
Configurarea cozilor arbore necesită marcarea prealabilă a fluxurilor de
pachete, folosind facilitatea mangle (/IP/Firewall/Mangle).
În RouterOS sunt realizate disciplinele [1]:
 BFIFO – Bytes First-In First-Out (octeții: primii sosiți – primii deserviți);
 PFIFO – Packets First-In First-Out (pachetele: primele sosite – primele
deservite);
 MQ PFIFO – Multiple Queues PFIFO (PFIFO pentru cozi multiple);
 RED – Random Early Drop (aruncarea aleatoare timpurie);
 SFQ – Stochastic Fairness Queuing (deservirea stocastică echilibrată);
 PCQ – Per Connection Queue (coadă per conexiune).
Aceste discipline pot fi clasificate după influiența lor asupra fluxului de
pachete:
202
 dispeceri (schedulers) – reordonează pachetele conform algoritmilor
respectivi și aruncă pachetele doar dacă acestea deja nu au loc în coadă,
ceea ce ar trebui să se întâmple rar: PFIFO, BFIFO, SFQ, PCQ (dispecer și
formator), RED;
 formatori (shapers) – de rând cu reordonarea necesară a pachetelor
efectuează, la necesitate, limitarea fluxului, aruncând toate pachetele în
plus la rata limită: PCQ (dispecer și formator), HTB.
Disciplinele BFIFO, PFIFO şi MQ PFIFO se bazează pe disciplina FIFO (First-
In First-Out – primul sosit-primul servit). Deosebirea între disciplinele BFIFO şi
PFIFO constă doar în faptul că BFIFO se măsoară în octeţi, iar PFIFO – în
pachete. Aceste două discipline sunt caracterizate de câte un singur
parametru: pfifo-limit, pentru disciplina PFIFO, şi, respectiv, bfifo-limit, pentru
disciplina BFIFO – parametru care stipulează volumul de date ce poate fi stocat
în coada FIFO. Pachetele, ce nu încap în coadă, sunt eliminate. Creşterea
memoriei cozii conduce la încărcarea mai înaltă a canalului, dar, totodată, şi la
creşterea latenţei.
MQ PFIFO este disciplina PFIFO cu suport pentru cozi multiple de
transmisie. Ea foloseşte parametrul mq-pfifo-limit. Asemenea cozi sunt
oportune pentru sisteme multiprocesor cu interfeţe Ethernet ce susţin cozi
multiple de transmisie.
Disciplina FIFO este rapidă, puţin încarcă procesorul ruterului şi este
oportun de folosit în cazurile lipsei congestiei în reţea.
Disciplina RED este destinată încercării de a evita congestia, în baza
monitorizării dimensiunii medii a cozii (avgq). Dacă mărimea medie a cozii este
mai mică decât red-min-threshold (minth), atunci nu se aruncă nici un pachet.
Când mărimea medie a cozii este cuprinsă între minth şi red-max-threshold
(maxth), RED aruncă pachete în mod aleatoriu cu probabilitatea Pmax(avgq –
minth)/(maxth – minth), unde Pmax ≤ 1. De obicei se foloseşte Pmax = 1. Dacă avgq
este egală sau depăşeşte maxth, atunci RED aruncă toate pachetele ulterioare,
până avgq devine mai mică decât maxth. Deşi este rapidă, disciplina RED se
foloseşte rar.
Disciplina SFQ prevede determinarea următorului pachet pentru
transmitere în mod arbitrar, dar echilibrat. Fluxul de date se identifică în mod
univoc de patru parametri: adresă sursă, adresă destinaţie, portul sursă şi
portul destinaţie. Aceşti parametri sunt folosiţi pentru clasificarea pachetelor
în 1024 de subfluxuri posibile. Apoi capacitatea de transfer date disponibilă se
distribuie tuturor subfluxurilor pe rând, la fiecare rundă oferind sfq-allot octeţi
de trafic. Coada SFQ poate conţine până la 128 pachete. Aceasta permite
echilibrarea traficului de pachete, în condiţiile de saturaţie a încărcării
canalului. Disciplina consumă masiv resursele de procesare ale ruterului.
203
Disciplina PCQ este o dezvoltare a celei SFQ, dar fără natura stocastică a
ultimei. Ea permite alegerea identificatorilor fluxului, din cei patru folosiţi de
disciplina SFQ, şi, de asemenea, atribuirea dimensiunii cozii FIFO şi a limitării
ratei fiecărui subflux aparte. Totodată, începând cu v5 a RouterOS, PCQ
permite şi deservirea în rafală (burst). Disciplina este foarte rapidă, o coadă
putând deservi sute de clienţi. Alte detalii referitoare la disciplina PCQ pot fi
regăsite în s. 6.5.
Unele recomandări, privind folosirea diferitelor discipline QoS în RouterOS,
sunt sistematizate în tabelul 6.1 [3].
Tabelul 6.1. Raţionamente privind folosirea unor discipline QoS [3]
Discip-
Cazuri de folosire Pro Contra
lina
FIFO La limitarea şi gestiunea Simplă, rapidă şi Doar două categorii de
simplă a vitezei de puţine procesări prioritate
transfer date
RED Nu se foloseşte, practic Rapidă Nu apare necesitatea
în facilitatea aleatorie
SFQ La gestionarea foarte Permite 16 nivele de Cele mai multe
eficientă a QoS prioritate pentru procesări
configurarea QoS
PCQ La distribuirea egală a Foarte rapidă, într-o Divizarea unei cozi în
lăţimii de bandă între coadă pot fi sute de multe subcozi cu trafic
mulţi clienţi clienţi de tip şi QoS diferite
devine dificil
6.1.4. Tipuri de cozi în RouterOS

Pentru fiecare interfață fizică a ruterului, în RouterOS este predefinit un
tip de coadă, din cele opt în total. Fiecărui asemenea tip (fig. 6.1) îi corespunde
o anumită disciplină şi valori implicite ale
unor parametri ai acesteia (/Queues/
Queue List/Queue Types):
 default – disciplina PFIFO, pfifo-limit
= 50;
 default-small – disciplina PFIFO,
pfifo-limit = 10;
 ethernet-default – disciplina PFIFO,
pfifo-limit = 50;
 hotspot-default – disciplina SFQ, sfq-
perturb = 5, sfq-allot = 1514;
 multi-queue-ethernet-default – Fig. 6.1. Disciplinele implicite.
disciplina MQ PFIFO, mq-pfifo-limit = 50. Coada poate fi oportun de
204
folosit în sisteme multiprocesor cu interfeţe Ethernet, reducând
procesările cu sincronizarea accesului;
 only-hardware queue – disciplină lipseşte. Interfaţa foloseşte un tampon
de memorie inel, care înseşi operează ca o coadă. Acest bufer poate
stoca cel puţin 100 de pachete. Folosirea unei asemenea cozi este
îndeosebi oportună pentru sisteme multiprocesor, excluzând necesitatea
sincronizării accesului de la diferite procesoare;
 synchronous-default – disciplina RED, red-limit = 60, red-min-thershold =
10, red-max-thershold = 50, red-burst = 20, red-avq-packet = 1000;
 wireless-default – disciplina SFQ, sfq-perturb = 5, sfq-allot = 1514.
Tipul de coadă poate fi
vizualizat şi redefinit în fereastra
de dialog Interface Queue
<nume_interfaţă>, care se va
afișa la acționarea /Queues/
Queue List/Interface Queues,
dublu clic nume-interfaţă (fig.
6.2). Disciplina, ce corespunde
unei cozi de un anumit tip, poate
fi vizualizată în fila Queue Types,
ce se va afişa la acţionarea
/Queues/Queue List/Queue
Types (fig. 6.1).
Utilizatorul poate crea şi Fig. 6.2. Tipurile de cozi în RouterOS.
tipuri de cozi proprii. Noile tipuri
de cozi pot fi apoi folosite în /Queues/Queue List/Simple Queues sau
/Queues/Queue Tree sau /Queues/Queue List/Interface Queues. Totodată,
dacă se adaugă prima regulă a cozii (în /Queues/Queue List/Simple Queues
sau /QueuesQueue List/Queue Tree) pentru o interfață fizică, coada implicită
a acestei interfețe va fi înlocuită cu noua coadă, iar cea definită în
/Queues/Queue List/Interface Queues pentru această interfață va fi
dezactivată.
6.1.5. Sistemul de cozi HTB
După cum a fost menţionat în s. 6.1.3, implementarea cozilor în RouterOS
se bazează pe sistemul HTB (Hierarchical Token Bucket – Cupă ierarhică cu
jeton). HTB permite crearea de sisteme ierarhice de cozi cu definirea relaţiilor
între cozi de genul „părinte-copil” sau „copil-copil”. Sistemele de cozi HTB se
organizează pentru fiecare interfaţă fizică de ieşire a ruterului şi, de asemenea,
pentru trei interfețe virtuale adiționale: global-in, global-out și global-total.
Datele transmise către ruterul local vor folosi cozile NTB global-in și global-
205
total, iar cele de transmis de la ruter vor folosi cozile NTB global-out, global-
total şi coada NTB a interfeţei fizice de ieşire a ruterului.
Fiecare coadă, adăugată în /Queues/Simple Queues sau /Queues/Queue
Tree, se ataşează la arborele HTB respectiv.
Un exemplu de arbore HTB, cu exemplificarea relaţiei între cozi de genul
„părinte-copil”, este prezentat în figura 6.3. În acest exemplu, cozile 1 şi 1.2
sunt cozi părinte, denumite şi interne, iar cele 1.1, 1.2.1 şi 1.2.2 sunt cozi
frunză. De asemenea, Coada 1 are două cozi derivate (copil) – cozile 1.1 şi 1.2,
iar Coada 1.2 – cozile derivate 1.2.1 şi 1.2.2.
Coada 1,
părinte = ether2
Coada 1.2,
părinte = Coada 1
Coada 1.1, Coada 1.2.1, Coada 1.2.2,

părinte = Coada 1 părinte = Coada 1.2 părinte = Coada 1.2
Fig. 6.3. Relaţiile între cozi gen „părinte-copil”.

De menţionat că toate cozile frunză, indiferent de numărul de părinţi
(numărul de nivele ierarhice) până la interfaţa ruterului, se tratează la fel.
Cozile părinte doar distribuie traficul de date către cozile frunză.
Pentru crearea unui sistem HTB, sunt necesare acţiunile:
 identificarea şi marcarea traficului, clasificându-l în diverse categorii după
anumiţi parametri;
 crearea de reguli de marcare a traficului, distribuind diverse categorii de
trafic între anumite cozi şi definind acţiunile asupra fiecărei categorii;
 atribuirea politicii de gestiune a traficului atât pentru toate interfeţele
virtuale globale (global-in, global-out și global-total), cât şi pentru fiecare
interfaţă sau coadă părinte în parte.
Fiecare coadă în HTB are două limite: CIR (limit-at) şi MIR (max-limit). HTB
va satisface, mai întâi, rata limit-at (CIR) pentru toate cozile şi doar după aceea
va aloca cozilor derivate (copil) rate suplimentare de la cozile părinte pentru a
atinge ratele max-limit (MIR). În acest scop, trebuie să se respecte condiţiile:
 limita sumară a ratelor garantate a cozilor derivate nu trebuie să
depăşească limita ratei garantate a cozii părinte
CIR(copil1) + CIR(copil2) + … + CIR(copilN) ≤ CIR(părinte); (6.1)
 rata maximă a oricărei cozi derivate nu trebuie să depăşească rata
maximă a cozii părinte
max{MIR(copili), i = 1, 2, 3, …, N} ≤ MIR(părinte). (6.2)
206
Dacă relaţia (6.1) nu se respectă, atunci, deoarece implicit HTB foloseşte
disciplina FIFO, alocarea de capacitate va păstra raportul
CIR(copil1):CIR(copil2): … :CIR(copilN) (6.3)
între valorile limit-at ale cozilor frunză ale arborelui NTB.
Starea încărcării cozilor în WinBox se specifică diferenţiat prin tei culori:
 0-50 % – verde;
 51-75 % – galbenă;
 76-100 % – roşie.
Sistemul HTB prevede 8 categorii de prioritate pentru toate categoriile de
acelaşi nivel ierarhic, cea mai înaltă fiind prioritatea 1. Pachetele se deservesc
începând cu cele de prioritate mai înaltă de la cel mai jos nivel (nivelul 0, dacă
are pachete) şi încheind cu cele de prioritate mai joasă de la cel mai înalt nivel.
Totodată, priorităţile au efect doar asupra distribuirii, între cozile derivate, a
ratelor cozilor părinte, rămase după distribuirea obligatorie a ratelor limit-at
(CIR) tuturor cozilor derivate. Efectul aplicării priorităţilor constă în aceea că
anume cozile cu prioritate mai înaltă vor atinge mai întâi ratele max-limit.
De menţionat că priorităţile se aplică doar:
 cozilor frunză. Ele nu se aplică cozilor interne (părinte);
 dacă este specificată valoarea parametrului max-limit, diferită de 0.
Atribuirea cozilor a capacităţii de transfer date în cadrul sistemului HTB,
este descrisă în exemplele 6.1-6.4 [1].
Exemplul 6.1. Distribuire conform limit-at. Fie sistemul HTB din figura 6.3
cu următoarele valori ale parametrilor CIR, MIR şi priority (fig. 6.4):
Coada 1,
limit-at = 0 M,
max-limit = 10 M
Coada 1.2,
limit-at = 4 M,
max-limit = 10 M

limit-at = 6 M, limit-at = 2 M, limit-at = 2 M,
max-limit = 10 M, max-limit = 10 M, max-limit = 10 M,
priority = 1 priority = 3 priority = 5
Fig. 6.4. Distribuire conform limit-at.
 Coada 1 – limit-at = 0 Mbps, max-limit = 10 Mbps;
 Coada 1.1 – limit-at = 6 Mbps, max-limit = 10 Mbps, priority = 1;
 Coada 1.2 – limit-at = 4 Mbps, max-limit = 10 Mbps;
 Coada 1.2.1 – limit-at = 2 Mbps, max-limit = 10 Mbps, priority = 3;
207
 Coada 1.2.2 – limit-at = 2 Mbps, max-limit = 10 Mbps, priority = 5.
Distribuirea capacităţii de transfer date a interfeţei ether2, conform HTB
din fig. 6.4, este trivială – toate cozile frunză vor primi valoarea limit-at
proprie:
 Coada 1.1 – 6 Mbps;
 Coada 1.2.1 – 2 Mbps;
 Coada 1.2.2 – 2 Mbps.
Exemplul 6.2. Distribuire cu implicarea max-limit. Fie sistemul HTB din
figura 6.3 cu următoarele valori ale parametrilor CIR, MIR şi priority (fig. 6.5):
Coada 1,
limit-at = 0 M,
max-limit = 10 M
Coada 1.2,
limit-at = 2 M,
max-limit = 10 M

Fig. 6.5. Distribuire cu implicarea max-limit.
din fig. 6.5, este:
 Coada 1.2.1 – 6 Mbps;
 Coada 1.2.2 – 2 Mbps.
Astfel, cozii 1.2.1 îi este distribuită capacitatea de 6 Mbps > 2 Mbps = limit-
at, deoarece are prioritate mai înaltă decât celelalte două cozi frunză.
Exemplul 6.3. Distribuire cu implicarea limit-at a cozilor interne. Fie
sistemul HTB din figura 6.3 cu următoarele valori ale parametrilor CIR, MIR şi
priority (fig. 6.6):
208
Coada 1,
limit-at = 0 M,
max-limit = 10 M
Coada 1.2,
limit-at = 8 M,
max-limit = 10 M

Fig. 6.6. Distribuire cu implicarea limit-at a cozilor interne.
din fig. 6.6, este:
 Coada 1.2.1 – 6 Mbps;
 Coada 1.2.2 – 2 Mbps.
Astfel, deşi coada 1.1 are prioritatea 1, cozii 1.2.1 îi este distribuită
capacitatea de 6 Mbps > 2 Mbps = limit-at, deoarece coada 1.2 (internă) are
limit-at = 8 Mbps, iar, dintre cozile 1.2.1 şi 1.2.2, cea 1.2.1 are prioritate mai
înaltă.
Exemplul 6.4. Distribuire conform limit-at trunchiat. Fie sistemul HTB din
figura 6.3 cu următoarele valori ale parametrilor CIR, MIR şi priority (fig. 6.7):
Coada 1,
limit-at = 0 M,
max-limit = 10 M
Coada 1.2,
limit-at = 4 M,
max-limit = 10 M

Fig. 6.7. Distribuire conform limit-at trunchiat.
209
din fig. 6.7, este:
 Coada 1.1 ≈ 3 Mbps;
 Coada 1.2.1 ≈ 1 Mbps;
 Coada 1.2.2 ≈ 6 Mbps.
După cum se poate observa, interfaţa ether2 dispune de capacitatea de 10
Mbps, care abia este suficientă pentru a acoperi limit-at(Coada 1.1) + limit-
at(Coada 1.2) = 10 Mbps, dar nu este suficientă pentru a acoperi suma
valorilor limit-at ale celor trei cozi frunză (1.1, 1.2.1 şi 1.2.2):
limit-at(Coada 1.1) + limit-at(Coada 1.2.1) + limit-at(Coada 1.2.1) = 20 Mbps.
Deoarece există un deficit de capacitate de 20 Mbps – 10 Mbps = 10 Mbps
şi, implicit, se foloseşte disciplina FIFO, alocarea de capacitate va păstra
raportul 6:2:12 între valorile limit-at ale celor trei cozi frunză, egal cu cel 3:1:6.
Folosirea unora din funcționalitățile QoS ale RouterOS este descrisă în ss.
6.2-6.7.
6.2. Marcarea diferitelor categorii de trafic

6.2.1. Esența marcării Mangle
Pentru a trata în mod diferit diversele categorii de trafic, acestea trebuie
indentificate şi marcate special. Pentru marcarea categoriilor de trafic,
RouterOS folosește facilitatea mangle (/IP/Firewall/Firewall/Mangle). Aceasta
permite marcarea conexiunilor (mark-connection); marcarea pachetelor
(mark-pachet) și marcarea rutării (mark-routing).
În cazul marcării conexiunilor, se foloseşte informaţia de monitorizare a
conexiunilor (connection tracking) – informaţie ce se înregistrează în tabelul
de stare a conexiunilor. Se marcează, practic, întreaga conexiune, folosind
parametrul new-connection-mark. Marcarea pachetelor presupune procesări
aparte cu marcarea fiecărui pachet al conexiunii, folosind parametrul new-
packet-mark, care se înscrie într-un câmp special al antetului. Bineînțeles,
marcarea conexiunilor necesită mai puține procesări de date, decât marcarea
fiecărui pachet al acesteia. Marcarea rutării (mark-routing) se realizează prin
specificarea în cadrul antetului fiecărui pachet a parametrului new-routing-
mark. De obicei marcarea rutării nu se folosește pentru transferuri P2P,
deoarece traficul P2P este întotdeauna rutat prin poarta implicită.
Marcajele mangle nu modifică structura pachetelor (cu excepţia
câmpurilor DSCP şi TTL) şi sunt active doar în cadrul ruterului; ele nu se
transmit prin rețea. În ce privește câmpurile DSCP (Differentiated Services
Code Point) și TTL ale pachetelor IP, facilitatea mangle permite modificarea lor.
210
Pentru configurarea cozilor, în RouterOS pot fi folosite doar marcajele de
pachete (câmpul Packet Marks al filei Advanced a ferestrei New Simple Queue
sau cel similar al filei General a ferestrei New Queue). De aceea, în scopul
reducerii procesărilor, se poate îmbina marcarea pachetelor cu cea a
conexiunilor, denumită și marcare optimală (optimal mangle). Marcarea
optimală constă din două etape:
 marcarea fiecărei conexiuni noi;
 adăugarea marcării de pachete pentru fiecare marcare de conexiune.
În așa fel, se va procesa, practic, cu marcarea doar primul pachet ce ține de
conexiune. Fiecare din aceste două etape se realizează de o regulă mangle
aparte.
Facilitatea mangle poate fi folosită în așa scopuri ca:
 marcarea traficului punct-la-punct (peer-to-peer);
 marcarea traficului după adresa MAC;
 marcarea traficului care necesită reducerea dimensiunii maxime a
segmentelor (maximum segment size – MSS);
 marcarea traficului de diferite categorii pentru stabilirea de priorități,
limite, rutare ș.a.
6.2.2. Definirea de reguli de marcare Mangle
Diversele marcări de trafic se configurează prin reguli mangle. Pentru
definirea unei reguli mangle, se acţionează /IP/Firewall/Firewall/Mangle, + și,
în fereastra New Mangle Rule ce se va afișa, se setează parametrii necesari.
Una din caracteristicile obligatorii ale oricărei reguli mangle este lanţul (chain),
de care ţine fluxul de date. Pentru regulile mangle, de rând cu lanţurile
forward, input şi output, descrise în s. 5.2.1, pot fi şi cele prerouting şi
postrouting. Pentru fluxurile de date ce se transmit prin ruter către exterior,
este oportun, de obicei, de folosit lanţul prerouting.
Exemplul 6.5. Fie este necesar de marcat traficul, ce ţine de calculatorul cu
adresa IP 192.168.20.1, folosind marcajul Mark PC1, şi cel, ce ţine de serverul
cu adresa IP 192.168.20.253, folosind marcajul Mark server. Se va aplica
marcarea optimală. În acest scop:
1. Se creează regula de marcare a conexiunii pentru PC1: /IP/Firewall/
Firewall/Mangle, +/New Mangle Rule/fila General, Chain – forward, Src.
Address – 192.168.20.1 (fig. 6.5a)/fila Action, Action – mark connection,
New Connection Mark – Mark PC1, caseta Passthrough se lasă bifată/OK.
(fig. 6.5b).
211
a) b)
Fig. 6.5. Crearea regulii de marcare a conexiunii pentru PC1.
2. Se creează regula de marcare a pachetelor pentru PC1: /IP/Firewall/
Firewall/Mangle, +/New Mangle Rule/fila General, Chain – forward,
Connection Mark – Mark PC1 (fig. 6.6a)/fila Action, Action – mark packet,
New Packet Mark – PC1, caseta Passthrough se lasă bifată/OK (fig. 6.6b).
a) b)
Fig. 6.6. Crearea regulii de marcare optimală a pachetelor pentru PC1.
3. Se creează regula de marcare a conexiunii pentru server: /IP/Firewall/
Firewall/Mangle, +/New Mangle Rule/fila General, Chain – forward, Src.
Address – 192.168.20.253 (fig. 6.7a)/fila Action, Action – mark connection,
New Connection Mark – Mark server, caseta Passthrough se lasă bifată/OK.
(fig. 6.7b).
a) b)
Fig. 6.7. Crearea regulii de marcare a conexiunii pentru server.
212
4. Se creează regula de marcare a pachetelor pentru server: /IP/Firewall/
Firewall/Mangle, +/New Mangle Rule/fila General, Chain – forward,
Connection Mark – Mark server (fig. 6.8a)/fila Action, Action – mark
packet, New Packet Mark – server, caseta Passthrough se lasă bifată/OK
(fig. 6.8b).
a) b)
Fig. 6.8. Crearea regulii de marcare optimală a pachetelor pentru server.
Cele patru reguli mangle create pot fi vizualizate în fila Mangle a ferestrei
Firewall (fig. 6.9).
Fig. 6.9. Cele 4 reguli de marcare optimală a traficului pentru PC1 și server.
Unele exemple de folosire a marcării mangle sunt descrise în s. 6.3.
6.3. Cozi simple

6.3.1. Esența cozilor simple
Cozile simple (simple queues) au destinaţia de a limita rata de date pentru
entităţi cu anumite adrese IP sau/şi subreţele, denumite adrese ţintă (target
addresses). Dacă nu este posibil de specificat adresele ţintă, atunci se specifică
numele interfeţei sau all (toate interfeţele).
213
Folosind o singură coadă, poate fi limitată aparte rata fluxului de încărcare
(upload, fig. 6.10) de la adresa ţintă şi cea a fluxului de descărcare (download)
către adresa ţintă sau ambele împreună (both – valoarea implicită). Astfel,
coada simplă poate fi una bidirecţională: atât pentru traficul de încărcare, cât
şi pentru cel de descărcare. Dacă limita se referă la o subreţea, atunci toate
staţiile acesteia partajează rata limită în cauză. Ele pot fi folosite, de
asemenea, pentru crearea unor aplicaţii QoS avansate.
Internet
upload
download
Fig. 6.10. Traficul de la (upload) şi către (download) staţia client.
Cozile simple au aşa funcţionalităţi ca:

 ordonarea traficului punct-la-punct;
 aplicarea regulilor cozii pentru intervale stabilite de timp;
 priorităţi în deservire;
 folosirea multiplelor marcaje de pachete configurate în /IP/Firewall/
Firewall/Mangle;
 limitarea sumară de trafic bidirecţional.
Ele se caracterizează de aşa parametri (atribute) ca:
 interface – interfaţa la care se referă coada;
 target-addresses – adresele IP de limitat;
 name (text) – identificatorul cozii. Poate fi folosit ca opţiunea parent
pentru alte cozi;
 time – limitarea efectului cozii la perioada de timp specificată;
 dst-address – permite selectarea fluxului de la adresa ţintă (target-
address) către adresa destinaţie (dst-address);
 packet-marks – lista numelor marcajelor pachetelor de monitorizat
definite în /IP/Firewall/Firewall/Mangle;
Parametri folosiţi în HTB:
 parent – numele cozii părinte în ierarhie. Atribuie coada dată ca derivată
(copil) a unei alte cozi specificate;
 priority – prioritatea cozii: 1 este cea mai înaltă şi 8 – cea mai joasă; nu
lucrează pentru cozile părinte şi nici nu are nimic cu deservirea în rafală;
 queue – numele tipului cozii. Pot fi create în /Queues/Queue List/Queue
Types;
 limit-at (integer) – CIR, limita la;
 max-limit (integer) – MIR (dacă deservirea în rafală nu este activată);
214
 burst-limit (integer) – rata maximă de date ce poate fi atinsă pe parcursul
stării active a deservirii în rafală;
 burst-time (time) – perioada de timp, în secunde, pentru care se
calculează rata medie de date;
 burst-threshold (integer) – limita de sus a ratei medii de date, până la
care este admisă deservirea în rafală. Dacă această limită este depăşită,
atunci limita maximă a ratei de date este scăzută la cea max-limit.
Parametri folosiţi în HTB global-total:
 total-queue – similar parametrului queue;
 total-limit-at (integer) – similar limit-at;
 total-max-limit (integer) – similar max-limit;
 total-burst-limit (integer) – similar burst-limit;
 total-burst-time (time) – similar burst-time;
 total-burst-threshold (integer) – similar burst-threshold.
De menţionat că la configurarea corectă:
 suma valorilor mărimilor limit-at ale cozilor derivate trebuie să nu
depăşească valoarea mărimii limit-at a cozii părinte (vezi (6.1));
 valoarea mărimii max-limit a fiecărei cozi derivate trebuie să nu
depăşească valoarea mărimii max-limit a cozii părinte (vezi (6.2)).
O regulă de configurare în /Queues/Queue List/Simple Queues poate crea
de la 0 până la 3 cozi separate: o coadă în global-in, o coadă în global-out și o
coadă în global-total. Dacă toți parametrii unei cozi au valorile implicite, adică
tipul cozii este cel implicit și nu au fost setate careva limite, și dacă, de
asemenea, coada nu are cozi derivate (copil), atunci aceasta nu este efectiv
creată.
Cozile simple sunt strict ordonate: fiecare pachet trebuie să fie procesat
prin toate cozile, până când acesta va ajunge la coada la care se referă. Deci
dacă o interfață are N cozi și la un pachet se referă coada N, atunci el va fi
procesat de toate cele N cozi.
6.3.2. Configurarea de cozi elementare
Sarcina practică 6.1. Limitarea ratei de acces la Internet pentru
calculator. Fie se cere limitarea ratei de acces la Internet pentru calculator la
încărcare (upload) – 64 Kbps şi descărcare (download) – 128 Kbps. În acest
scop:
1. De acţionat: /Queues/Queue List/Simple Queues, +/New Simple Queue/
fila General, Name – qLimit1, Target Address – 192.168.x.1 (în fig. 6.7,
192.168.20.1), Max Limit Target Upload – 64k şi Max Limit Target Download
– 128k/OK (fig. 6.11). În fereastra New Simple Queue din fig. 6.11, se pot
observa şi listele derulante pentru selectarea valorilor mărimilor Burst Limit,
Burst Threshold şi Burst Time de configurare a deservirii în rafală.
215
Fig. 6.11. Limitarea ratei de la şi către PC folosind Simple Queue.
2. În fereastra Queue List, fila Simple Queue, va apare înregistrarea privind
coada qLimit1 configurată pentru interfaţa ether2, la care este conectat
calculatorul cu adresa 192.168.x.1: Rx Max Limit = 64 Kbps; Tx Max Limit =
128 Kbps (în fig. 6.12 pentru calculatorul 192.168.20.1). Recepţia (Rx) din
partea ruterului corespunde încărcării (upload) din partea calculatorului, iar
transmisia (Tx) din partea ruterului – descărcării (download) din partea
calculatorului (fig. 6.10).
Fig. 6.12. Vizualizarea ratelor de date prin interfeţele ruterului.

3. De verificat respectarea limitelor definite, acţionând /Interfaces/Interface
List/Interface. Fila Interface conţine informaţii despre interfeţele ruterului,
inclusiv Tx şi Rx (fig. 6.12). Conform figurii 6.12, prin interfaţa ether2, la care
este conectat calculatorul cu adresa 192.168.20.1, sunt transmise fluxurile
216
Tx = 112,7 Kbps şi Rx = 38,3 Kbps, ceea ce confirmă respectarea limitelor
stabilite. De menționat că simbolul din fața numelui cozii (qLimit1 în
coloana Name), în înregistrarea din fila Simple Queues a ferestrei Queue
List, are culoare verde, dacă fluxul de date nu a atins rata limită, și –
culoarea roșie, dacă fluxul de date este la rata limită.
Fig. 6.12. Vizualizarea ratelor de date prin interfeţele ruterului.

4. De vizualizat ratele de date între calculator şi ruter folosind Torch
(/Tools/Torch, vezi s. 5.6). Un exemplu, pentru calculatorul cu adresa
192.168.20.1, este prezentat în figura 6.13.
5. De şters, în fereastra Queue List, înregistrarea ce ţine de coada qLimit1.
Fig. 6.13. Vizualizarea ratei de date calculator-ruter folosind Torch.

Sarcina practică 6.2. Limitarea ratei de acces de la calculator la o adresă
dată din Internet. Fie se cere limitarea ratei de acces de la calculator la
217
serverul www.mikrotik.com la: încărcare (upload) – 128 Kbps; descărcare
(download) – 256 Kbps. În acest scop:
1. De identificat adresa IP a serverului www.mikrotik.com folosind ping.
2. De acţionat: /Queues/Queue List/Simple Queues, +/New Simple Queue/
fila General, Name – qLimit2, Target Address – 192.168.x.1, Max Limit
Target Upload – 128k şi Target Download – 256k/fila Advanced, Dst.
Address – 159.148.147.196/OK (fig. 6.14). Astfel, deosebirea faţă de sarcina
practică 6.1, în ce priveşte acţiunile de îndeplinit, constă doar în definirea
adresei IP, schimbul de date cu care de la calculator se limitează; această
adresă se specifică în câmpul Dst. Address al filei Advanced.
3. De şters, la necesitate, în fereastra Queue List, înregistrarea ce ţine de
coada qLimit2. Dacă în listă sunt mai multe înregistrări, atunci ele se execută
pe rând, în ordinea numerotării, de sus în jos.
Fig. 6.14. Limitarea ratei de acces la adresa 159.148.147.196 din Internet.

Din alte posibilităţi de folosire a cozilor simple ar putea fi menţionate:
 folosirea unei adrese din Internet ca adresă sursă, pentru care se
stabilesc limitele de trafic (Target Address);
 adresa Dst. Address poate fi folosită pentru a permite acces nelimitat la
resurse din reţeaua locală;
 poate fi limitat traficul torrent (câmpul P2P din fila Advanced, vezi fig.
6.14), care poate să consume o mare parte din capacităţile de transfer
date, ş.a.
Exemplul 6.6. Limitarea torentelor. La descărcarea de date torent, traficul
poate încarcă toată capacitatea canalului, ceea ce face dificile alte transferuri
de date, inclusiv Web. De aceea este oportună limitarea traficului torent. Fie
se cere limitarea traficului torent pentru calculatorul cu adresa 192.168.20.1 la
încărcare (upload) 128 Kbps şi descărcare (download) 128 Kbps. În acest scop,
se acţionează: /Queues/Queue List/Simple Queues, +/New Simple Queue/fila
General: Name – qLimit3, Target Address – 192.168.20.1, Max Limit Target
218
Upload – 128k şi Target Download – 128k/fila Advanced, P2P – all-p2p/OK
(fig. 6.14).
Cozile simple pot fi configurate şi din linia de comandă. Un exemplu este
prezentat în cele ce urmează.
Exemplul 6.7. Configurarea cozilor simple din linia de comandă. Fie se
cere de limitat rețeaua locală, definită în s. 4.2.2 (reţeaua 192.168.x.0/24,
unde x = 20 este numărul ruterului utilizatorului, calculatorul utilizatorului cu
adresa 192.168.20.1/24 este conectat la interfaţa ether2 a ruterului cu adresa
192.168.20.254/24), la descărcare – 512 Kbps și încărcare – 256 Kbps.
Suplimentar la reţeaua definită, se va considera că în reţeaua 192.168.20.0/24
este un server cu adresa 192.168.20.253/24.
În primul rând, trebuie de exlus limitele pentru server (192.168.20.253/24),
adică Max Limit trebuie să fie unlimited, atât pentru descărcare, cât şi pentru
încărcare; din linia de comandă acest caz se specifică max-limit=0/0. În acest
scop se adaugă regula:
[20_bit@20_ion]> queue simple add name=server-local target-
addresses=192.168.20.253/32 max-limit=0/0
La următorul pas trebuie de adăugat limita pentru rețeaua
192.168.20.0/24:
[20_bit@20_ion]> queue simple add name=retea-locala target-
addresses=192.168.20.0/24 max-limit=256/512
Regulile definite pot fi vizualizate în fila Simple Queues (fig. 6.15)
Fig. 6.15. Regulile server-local şi limitare retea-locală în fila Simple Queues.

sau pot fi afişate din linia de comandă Terminal (fig. 6.16), aplicând comanda
[20_bit@20_ion] > queue simple print
219
Fig. 6.16. Regulile server-local şi limitare retea-locala afişate din linia de comandă.
6.3.3. Transferuri de date în rafale

Pentru transferuri de rată mai înaltă, în decursul unor perioade scurte de
timp, se foloseşte deservirea în rafale (bursts). Fiecare 1/16 parte a perioadei
burst-time (perioadă pentru care se calculează rata medie a traficului), ruterul
calculează rata medie a traficului pe secundele ultimei perioade burst-time.
Dacă această rată este mai mică, decât rata în rafală stabilită (burst-threshold),
atunci se activează regimul în rafală (burst) și rata efectivă este stabilită egală
cu limita în rafală (birst-limit); în caz contrar – rata efectivă este stabilită egală
cu limita maximă (max-limit). De menţionat că birst-limit este cea mai mare
rată limită ce poate fi atinsă în timpul transferurilor în rafale. În general, la
limitarea traficului, trebuie de ținut cont de condiţiile:
burst-threshold < max-limit < burst-limit. (6.4)
Transferurile de date în rafale permit transferul rapid al unor mesaje de
mici dimensiuni, în paralel cu transferurile de mesaje de mari dimensiuni în
derulare.
Exemplul 6.8. Folosirea transferurilor în rafale. Fie max-limit = 256000,
burst-time = 8, burst-threshold =192000, burst-limit = 512000 și utilizatorul
inițiază descărcarea unui fișier din Internet. La început, precedentele 8 s, trafic
nu a fost, deci este permis regimul în rafale. După prima secundă, rata medie
este (0 + 0 + 0 + 0 + 0 + 0 + 0 + 512)/8 = 64 Kbps, care este mai mică decât rata
în rafală stabilită. După a doua secundă, rata medie este (0 + 0 + 0 + 0 + 0 + 0 +
512 + 512)/8 = 128 Kbps, care tot este mai mică, decât rata în rafale stabilită.
Dar după a treia secundă, deja rata medie devine egală cu rata în rafale
stabilită (192 Kbps) și regimul în rafale se întrerupe, iar rata limită cade la
limita maximă (192 Kbps). De menţionat că în acest exemplu sunt prezentate
doar o parte din calcule; în realitate calculele se efectuează la fiecare 8/16 s,
adică la fiece 0,5 s.
220
Configurarea transferurilor în rafale poate fi realizată pentru cozi simple.
Câmpurile pentru cei trei parametri, burst-limit, burst-threshold şi burst-time,
se regăsesc în fila General a ferestrei New Simple Queue (fig. 6.11).
6.3.4. Prioritizarea traficului
Folosirea priorităţilor, în deservirea diferitelor fluxuri de date, este
oportună îndeosebi la mesaje ce diferă considerabil după: operativitate,
dimensiune, importanţă, variaţia în timp a resurselor necesare (trafic izocron
sau nu), trafic în timp real sau ordinar ş.a. Prioritizarea traficului de date se
efectuează, cu rare excepţii, aparte pentru fiecare ruter.
În RouterOS se folosesc 8 categorii de prioritate, numerotate de la 1 până
la 8, în descreşterea priorităţii. Implicit, cozile simple au prioritatea 8, dar la
necesitate aceasta poate fi modificată.
Exemplul 6.9. Atribuirea de priorităţi. Fie se cere de atribuit: prioritatea 2
pentru serverul 192.168.20.253, la trafic nelimitat în ambele direcţii, şi
prioritatea 1 pentru PC 192.168.20.1, la trafic de 256 Kbps la încărcare şi de
512 Kbps la descărcare; ambele calculatoare sunt din subreţeaua locală
192.168.20.0/24. În acest scop:
1. Se configurează coada „server-local” pentru server: /Queues/Queue
List/Simple Queues, +/New Simple Queue/fila General, Name – server-
local, Target Address – 192.168.20.253, Target Upload Max Limit –
unlimited şi Target Download Max Limit – unlimited/fila Advanced, Priority
– 2/OK.
2. Se configurează coada PC1 pentru PC: /Queues/Queue List/Simple Queues,
+/New Simple Queue/fila General, Name – PC1, Target Address –
192.168.20.1, Target Upload Max Limit – 256 şi Target Download Max Limit
– 512/fila Advanced, Priority – 1/OK.
3. Înregistrările cozilor configurate pot fi vizualizate în fila Simple Queues a
ferestrei Queue List (fig. 6.17).
Fig. 6.17. Regulile server-local şi PC1 cu priorităţi în fila Simple Queues.
221
6.4. Cozi arbore
6.4.1. Esența cozilor arbore
Coada arbore (Tree Queue) permite o gestiune mai sofisticată a traficului
de pachete, comparativ cu cozile simple și se foloseşte atunci, când se doreşte
alocarea ratei de date în baza de protocoale, porturi, grupuri de adrese IP, etc.
Pentru folosirea lor, mai întâi se marchează fluxurile de pachete în
/IP/Firewall/Mangle. Apoi marcajul în cauză este folosit ca identificator al
fluxurilor de pachete în cadrul cozilor.
Spre deosebire de cozile simple, care pot fi bidirecţionale (vezi s. 6.3.1),
cozile arbore pot fi doar monodirecţionale – ele creează doar o coadă
monodirecţională în una din sistemele HTB. De aceea nu este necesar de
separat marcajele pentru încărcare de cele pentru descărcarea de trafic: la
interfaţa publică (Public interface) se va prelua doar traficul de încărcare, iar la
cea privată (Private interface) se va prelua doar traficul de descărcare. Dacă în
acelaşi HTB există, atât cozi simple, cât şi coadă arbore, atunci primele vor
primi traficul cozile simple.
Coada arbore nu este ordonată: în cadrul acesteia toate cozile constituente
sunt procesate în acelaşi timp, de aceea aceasta este mult mai rapidă decât
cozile simple.
Coada arbore se caracterizează de parametrii name şi packet-marks şi
aceeaşi parametri folosiţi în HTB ca şi la cozile simple: parent, priority, queue,
limit-at, max-limit, burst-limit, burst-time şi burst-threshold (vezi s. 6.3.1).
6.4.2. Configurarea de cozi arbore
Cozile arbore se aplică în cazurile operării cu mai multe fluxuri de date de
diferite categorii. Pentru configurarea unor asemenea cozi, trebuie să fie
posibilă identificarea aparte a fiecăruia din fluxurile respective – identificare ce
se realizează în baza marcajelor mangle ale lor stabilite anterior. Un exemplu
este descris în cele ce urmează.
Exemplul 6.10. Configurarea cozilor arbore PC1 şi server. Fie cazul
exemplului 6.1 şi se cere de limitat rata: pentru serverul 192.168.20.253 – la
500 Kbps şi pentru PC 192.168.20.1 – la 200 Kbps. Se consideră că fluxurile de
date sunt deja marcate conform exemplului 6.5. În acest scop:
1. Se configurează coada arbore „PC1” pentru calculator: /Queues/Queue
List/Queue Tree, +/New Queue/General, Name – PC1, Parent – ether2,
Packet Mark – PC1, Max Limit – 200/OK (fig. 6.18a).
2. Se configurează coada arbore „server” pentru calculator: /Queues/
Queue List/Queue Tree, +/New Queue/General, Name – server, Parent –
ether2, Packet Mark – server, Max Limit– 500/OK (fig. 6.18b).
222
a) b)
Fig. 6.18. Regulile server şi PC1 cu priorităţi în fila Simple Queues.
3. Cele două cozi create pot fi vizualizate în fila Queue List a ferestrei Queue
Tree (fig. 6.19).
Fig. 6.19. Cozile arbore PC1 şi server în fila N Queues.

De menţionat că deşi cozile PC1 şi server sunt create ca şi cozi arbore,
acestea nu sunt cozi arbore veritabile, fiind constituite doar dintr-un singur
nivel.
6.5. Esenţa şi folosirea disciplinei PCQ

6.5.1. Esenţa PCQ
Disciplina PCQ a fost introdusă pentru eficientizarea sistemelor QoS mari,
în care majoritatea cozilor pentru diferite subfluxuri sunt aceleaşi. De
exemplu, un subflux se poate referi la descărcare sau încărcare pentru o
anumită staţie internă sau conexiune către server.
Ea permite alegerea identificatorilor fluxului, din cei patru folosiţi de către
disciplina SFQ: adresă sursă (încărcare din punctul de vedere al staţiei client),
adresă destinaţie (descărcare din punctul de vedere al staţiei client), portul
sursă şi portul destinaţie. De exemplu, fluxurile pot fi clasificate doar după
adresa sursă; în acest caz, fiecare subflux se va referi la una din staţiile interne
(client). Totodată, PCQ permite atribuirea dimensiunii cozii FIFO şi a limitării
223
ratei fiecărui subflux aparte, folosind opţiunile, respectiv, pcq-limit şi pcq-rate.
Dacă pcq-rate = 0, atunci traficul va fi distribuit între subfluxuri în mod egal.
Disciplina PCQ foloseşte parametrii:
 pcq-classifier – selectarea identificatorilor subfluxurilor din cei: dst-
address, dst-port, src-address şi src-port. Valoarea implicită: lipsă;
 pcq-rate – rata maximală de date disponibilă fiecărui subflux;
 pcq-limit – dimensiunea cozii unui subflux (Ko);
 pcq-total-limit – dimensiunea cozii globale FIFO (Ko).
PCQ permite folosirea, ca identificatori de subfluxuri, nu doar a unor
adrese IP aparte, ci şi a unor adrese de subreţele. Parametrii, folosiţi în acest
scop pentru reţele IPv4, sunt:
 pcq-dst-address-mask (număr) – dimensiunea reţelei IPv4, care va fi
folosită ca identificator de subflux adresă destinaţie (dst-address), de
exemplu 24 pentru subreţeaua locală;
 pcq-src-address-mask (număr) – dimensiunea reţelei IPv4, care va fi
folosită ca identificator de subflux adresă sursă (src-address), de exemplu
24 pentru subreţeaua locală.
De asemenea, începând cu v5 a RouterOS, PCQ permite şi deservirea în
rafală (burst), folosind parametrii similari: pcq-burst-rate, pcq-burst-
threshold şi pcq-burst-time.
Esenţa disciplinei PCQ este prezentată în figura 6.20 [1]:
Fig. 6.20. Esenţa disciplinei PCQ.

Conform fig. 6.20, pachetele fluxului de intrare sunt clasificate în n
grupuri/cozi FIFO, fiecare din care poate stoca până la pcq-limit pachete.
Valoarea pcq-limit se determină ca
pcq-limit = pcq-total-limit/n. (6.5)
Aici pcq-total-limit este numărul total de pachete ce pot fi stocate în cele n
subfluxuri şi care sunt considerate ca făcând parte din coada de ieşire sumară
224
FIFO Total. De exemplu, dacă pcq-total-limit = 2000 pachete şi pcq-limit = 50
pachete, atunci pot fi formate 2000/50 = 40 subfluxuri. Pachetele acestor n
subfluxuri sunt preluate, cu rata pcq-rate fiecare, prin coada de ieşire FIFO
Total. Astfel, PCQ permite înlocuirea a n cozi, ce au o limitare de rată comună,
cu o singură coadă pentru n subfluxuri. Aceasta facilitează lucrările de
administrare şi reduce considerabil procesările ruterului cu transferul datelor.
Una din particularităţile PCQ ţine de folosirea parametrului pcq-rate,
exemplificată în figura 6.21. Astfel, dacă valoarea ratei pcq-rate este definită,
atunci fiecare din cele n subfluxuri obţine o rată limită egală cu (fig. 6.21a)
max{pcq-rate; max-limit/n}. (6.6)
a) pcq-rate = 128000 2 sfluxuri 4 sfluxuri 7 sfluxuri

128K 73K
73K
128K 73K
queue = pcq1 73K
max-limit = 512K
128K 128K 73K
73K
128K 128K 73K
b) pcq-rate = 0 1 flux 2 sfluxuri 7 sfluxuri

73K
256K 73K
73K
queue = pcq1 512K 73K
max-limit = 512K
73K
256K 73K
73K
Fig. 6.21. Alocarea ratei pcq-rate.
Dacă însă valoarea pcq-rate nu este definită, adică pcq-rate = 0, atunci rata
disponibilă max-limit se alocă celor n subfluxuri în mod egal (fig. 6.21b).
Totalizând, disciplina PCQ:
 permite configurarea de cozi avansate;
 poate reduce numărul de cozi, datorită uniformizării cozilor similare;
 facilitează alocarea ratei disponibile între utilizatori în mod egal;
 poate separa traficul după adresa destinaţie, portul destinaţie, adresa
sursă şi portul sursă;
 facilitează lucrările de administrare, datorită reducerii numărului de
reguli de definit;
 micşorează procesările ruterului cu transferul datelor ş.a.
225
6.5.2. Exemple de aplicare a PCQ
Disciplina PCQ poate fi folosită în trei moduri de bază:
 rate egale anumite unor staţii date (vezi exemplele 6.11 şi 6.12);
 distribuirea egală a unei rate anumite între o mulţime de staţii (în fig.
6.21a, 512 Kbps; rata de 512 Kbps se specifică la configurarea regulilor
respective) (vezi exemplul 6.13);
 distribuirea egală a unei rate necunoscute între o mulţime de staţii (în fig.
6.21b este specificată rata de 512 Kbps, dar doar pentru a arăta cum rata
disponibilă se distribuie; aceasta nu se specifică la configurarea regulilor
respective) (vezi exemplul 6.14).
Regulile PCQ se pot aplica folosind cozi simple (vezi exemplele 6.12, 6.13 şi
6.14) sau marcarea mangle şi cozi arbore (vezi exemplul 6.11). Totodată,
pentru a diferenţia traficul de încărcare de cel de descărcare, este necesar de
creat două tipuri de cozi PCQ: una pentru traficul de încărcare (de exemplu,
PCQupload), care va clasifica traficul după adresa sursă (Src. Address) – staţiile
locale (client), şi alta pentru traficul de descărcare (de exemplu,
PCQdownload), care va clasifica traficul după adresa destinaţie (Dst. Address) –
staţiile locale (client).
Exemplul 6.11. Alocarea de rate egale anumite staţiilor unei subreţele.
Fie este necesar ca fiecăreia dintre staţiile subreţelei 192.168.20.0/24,
conectate la interfaţa ether2 a ruterului, să i se aloce o capacitate de transfer
date de 32 Kbps pentru încărcare şi 128 Kbps pentru descărcarea de date din
Internet. De asemenea, se cere ca regulile PCQ să se aplice folosind marcarea
mangle şi coada arbore. Totodată, se va ţine cont că interfaţa publică, de
conectare la Internet, a ruterului este wlan1. În acest scop:
1. Se defineşte regula de marcare a pachetelor traficului de încărcare,
acţionând /IP/Firewall/Mangle, +/New Mangle Rule/fila General, Chain –
prerouting, In. Interface – wlan1/fila Action, Action – mark packet, New
Packet Mark – client upload/OK (fig. 6.22a, 6.22b).
2. Se defineşte regula de marcare a pachetelor traficului de descărcare,
acţionând IP/Firewall/Mangle, +/New Mangle Rule/fila General, Chain –
prerouting, In. Interface – ether2/fila Action, Action – mark packet, New
Packet Mark – client download/OK (fig. 6.22c, 6.22d).
3. Se defineşte tipul de coadă (Queue Type) PCQ pentru încărcare PCQupload,
acţionând /Queues/Queue List/Queue Types, +/New Queue Type, Type
Name – PCQupload, Kind – pcq, Rate – 32, Classifier – bifare Src.
Address/OK (fig. 6.23a).
226
b) client upload
d) client download
a) interfaţa wlan1 c) interfaţa ether2
Fig. 6.22. Crearea regulilor de marcare a pachetelor.
4. Se defineşte tipul de coadă (Queue Type) PCQ pentru descărcare
PCQdownload, acţionând /Queues/Queue List/Queue Types, +/New Queue
Type, Type Name – PCQdownload, Kind – pcq, Rate – 128, Classifier – bifare
Dst. Address/OK (fig. 6.23b).
a) PCQupload b) PCQdownload
Fig. 6.23. Crearea tipurilor de cozi PCQupload şi PCQdownload.
5. Se creează coada arbore PCupload pentru încărcare, acţionând /Queues/
Queue List/Queue Tree, +/New Queue, Name – PCupload, Parent – global-
out, Packet Marks – client upload, Queue Type – PCQupload/OK (fig. 6.24a).
6. Se creează coada arbore PCdownload pentru descărcare, acţionând
Queues/Queue List/Queue Tree, +/New Queue, Name – PCdownload,
Parent – global-in, Packet Marks – client download, Queue Type –
PCQdownload/OK (fig. 6.24b).
227
a) PCupload b) PCdownload
Fig. 6.24. Crearea cozilor arbore PCupload şi PCdownload.
Exemplul 6.12. Similar exemplului 6.11, dar se cere ca regulile PCQ să se
aplice folosind cozile simple. În acest scop:
1. Se definesc tipurile de cozi PCQupload şi PCQdownload, ca la paşii 3 şi 4 ai
exemplului 6.11.
2. Se creează coada simplă PCupload pentru încărcare, acţionând
Queues/Queue List/Simple Queues, +/New Simple Queue/fila General,
Name – PCupload, Target Address – 192.168.20.0/24 /fila Advanced,
Packet Marks – client upload, Queue Type – PCQupload/OK (fig. 6.25a).
a) PCupload b) PCdownload
Fig. 6.25. Crearea cozilor simple PCupload şi PCdownload.
4. Se creează coada simplă PCdownload pentru descărcare, acţionând
Queues/Queue List/Simple Queues, +/New Simple Queue/fila General, Name
– PCdownload, Target Address – 192.168.20.0/24 /fila Advanced, Packet
Marks – client download, Queue Type – PCQdownload/OK (fig. 6.25b).
Înregistrările create pot fi vizualizate în fereastra Queue List, filele Queue
Types şi Simple Queues (fig. 6.26).
Exemplul 6.13. Distribuirea egală a unei rate anumite între staţiile unei
subreţele. Fie este necesar ca ratele de transfer date de 1 Mbps pentru
228
încărcare şi 2 Mbps pentru descărcarea de date din Internet să se distribuie
egal între staţiile subreţelei 192.168.20.0/24. De asemenea, se cere ca regulile
PCQ să se aplice folosind cozile simple.
a) PCQupload şi PCQdownload b) PCupload şi PCdownload

Fig. 6.26. Înregistrările privind regulile PCQ pentru cozi simple.
De menţionat că ratele limită 1 Mbps şi 2 Mbps se specifică în cadrul
cozilor simple, parametrul Max Limit. Astfel:
1. Se definesc tipurile de cozi PCQupload şi PCQdownload, ca la paşii 3 şi 4 ai
exemplului 6.11, cu deosebirea că valoarea parametrului Rate se specifică
nu 32 (PCQupload) sau 128 (PCQdownload) ci, în ambele cazuri, 0.
2. Se creează coada simplă PCupdown pentru încărcare/descărcare, acţionând
Name – PCupdown, Target Address – 192.168.20.0/24, Target Upload Max
Limit – 1M, Target Download Max Limit – 2M/fila Advanced, Target Upload
Queue Type – PCQupload, Target Download Queue Type –
PCQdownload/OK (fig. 6.27).
Fig. 6.27. Crearea cozii simple PCupdown cu limitele 1M/2M.

a) PCQupload şi PCQdownload b) PCupdown

Fig. 6.28. Înregistrările privind PCQupload, PCQdownload şi PCupdown.
229
Exemplul 6.14. Distribuirea egală a unei rate necunoscute între staţiile
unei subreţele. Fie este necesar ca rata de transfer date disponibilă
necunocută pentru încărcare şi descărcarea de date din Internet să se
distribuie egal între staţiile subreţelei 192.168.20.0/24. De asemenea, se cere
ca regulile PCQ să se aplice folosind cozile simple. În acest scop:
1. Se definesc tipurile de cozi PCQupload şi PCQdownload, ca la pasul 1 al
exemplului 6.13.
2. Se creează coada simplă PCupdown pentru încărcare/descărcare, acţionând
Name – PCupdown, Target Address – 192.168.20.0/24, Target Upload Max
Limit – unlimited, Target Download Max Limit – unlimited/fila Advanced,
Target Upload Queue Type – PCQupload, Target Download Queue Type –
PCQdownload/OK (fig. 6.29).
a) PCupdown b) PCQupload şi PCQdownload

Fig. 6.29. Crearea cozii PCupdown la exemplul 6.14.

a) PCQupload şi PCQdownload b) PCupdown

Fig. 6.30. Înregistrările privind regulile PCQ şi coada simplă la exemplul 6.14.
Sarcina practică 6.3. Aplicarea disciplinei PCQ folosind cozi simple:
1. De îndeplinit sarcina exemplului 6.12. Apoi de restabilit starea iniţială a
configurărilor.
configurărilor.
configurărilor.
230
6.6. Monitorizarea QoS
Sistemul RouterOS se livrează cu un set bogat de instrumente pentru
monitorizarea şi eficientizarea valorificării resurselor reţelelor de calculatoare.
La acestea se referă:
 utilita Bandwidth Test de testare a vitezei de transfer date;
 utilita Torch (lanternă) de prezentare în timp real a traficului de date
printr-o interfaţă, cu posibilitatea de sortare a acestuia după adresa IP şi
port;
 utilita Traffic de monitorizare a traficului de date printr-o interfaţă;
 utilita Graphing de monitorizare în timp, evidenţă, stocare şi
reprezentare grafică a diferiţilor parametri ai RouterOS, inclusiv: a
condiţiilor de funcţionare a ruterului (voltajul şi temperatura), a folosirii
capacităţii interfeţelor, a traficului cozilor simple şi a utilizării resurselor
procesoarelor, ale memoriei disc şi ale memoriei RAM;
 utilita SNMP (Simple Network Management Protocol) de monitorizare şi
gestiune a dispozitivelor reţelei. Este foarte utilă pentru depistarea
problemelor în rețea.
6.6.1.Testarea vitezei de transfer date – Bandwidth Test
Pentru testarea vitezei de transfer date între două rutere sau printr-un
anumit ruter MikroTik, inclusiv la distanţă, în RouterOS serveşte utilita
Bandwidth Test. Aceasta realizează un serviciu client-server în baza aplicaţiilor
Bandwidth Test Server şi, respectiv, Bandwidth Test Client cu folosirea
protocoalelor TCP şi UDP. În cazul folosirii protocolului UDP, serviciul de
testare ia în calcule atât datele utilizator, cât şi antetele unităţilor de date. Pe
când la folosirea protocolului TCP, acesta nu ia în calcule antetele segmentelor
TCP şi cele ale pachetelor IP.
Serviciul Bandwidth Test poate fi folosit pentru determinarea capacităţii de
transfer date între două rutere sau cea a unui ruter aparte. În cazul
determinării capacităţii de transfer date a unui ruter aparte, sunt necesare cel
puţin trei rutere interconectate în lanţ: ruterul pe care va rula aplicaţia
Bandwidth Test Client, apoi ruterul testat şi, în sfârşit, ruterul pe care va rula
aplicaţia Bandwidth Test Server.
La aplicarea serviciului Bandwidth Test, trebuie de ţinut cont de faptul că,
pe durata testării, aplicaţiile Bandwidth Test Server şi Bandwidth Test Client
vor folosi întreaga capacitate de transfer date disponibilă între dispozitivele
implicate. Resursele respective nu vor putea fi folosite, în această perioadă, şi
în alte scopuri.
Administratorul poate configura opţiunile aplicaţiei Bandwidth Test Server
acţionând /Tools/Btest Server. Se va afişa caseta de dialog Btest Server
Settings (fig. 6.31), în care poate fi activată (prin bifare Enabled) sau
231
dezactivată (prin debifare Enabled) aplicaţia Btest Server. De asemenea, dacă
este necesar, se poate cere autentificarea utilizatorului ruterului, înainte de
testare, prin bifarea parametrului Autentificate. Pentru autentificare pot fi
folosite şi datele administratorului, predefinit cu numele de conectare admin
şi fără parolă. Deoarece testarea consumă multe resurse, se recomandă
folosirea Btest Server cu autentificarea utilizatorului. Parametrul Max Sessions
specifică numărul de sesiuni de testare; se recomandă folosirea valorii
predefinite a acestuia.
Aplicaţia Bandwidth Test Client se
accesează, acţionând /Tools/Bandwidth
Test. Se va afişa fereastra de dialog
Bandwidth Test (fig. 6.32). În câmpul
Test To al acesteia, se specifică adresa
IP a ruterului, către care se doreşte
testarea capacităţii de transfer date şi Fig. 6.31. Setarea BTest Server.
pe care trebuie să ruleze BTest Server.
Protocolul de utilizat se specifică prin radiobutonul respectiv. Pentru
protocolul UDP poate fi specificată dimensiunea pachetelor de folosit în testări
(Local UDP Tx Size şi Remote UDP Tx Size) şi, de asemenea, direcţia transferului
datelor de testare (în câmpul Direction): recepţie (receive), transmisie (send)
sau ambele (both). Poate fi, totodată, limitată viteza de transfer date (Local Tx
Speed şi Remote Tx Speed). În cazul folosirii protocolului TCP, se foloseşte doar
dimensiunea predefinită a pachetelor, dar poate fi specificat numărul
conexiunilor TCP (TCP Connection Count).
Sarcina practică 6.4. Testarea capacităţii de transfer date către o interfaţă
a ruterului utilizatorului. Fie se cere de determinat capacitatea de transfer
date către interfaţa cu adresa 192.168.x.254 a ruterului utilizatorului, la
transmisia în ambele direcţii, folosind protocolul UDP. În acest scop:
1. De verificat şi, la necesitate, de configurat setările BTest Server în caseta de
dialog Btest Server Settings, care se va afişa la acţionarea /Tools/BTest
Server: opţiunile Enabled şi Autentificate trebuie să fie bifate (fig. 6.31).
2. De acţionat /Tools/Bandwidth Test, Test To – 192.168.x.254 (în exemplu,
192.168.20.254), Protocol – udp, Direction – both, User – nume_utilizator
(în exemplu, 20_bit), Password – parola/Start (fig. 6.32). În partea de jos a
casetei de dialog Bandwidth Test (Running) se vor afişa rezultatele testării:
capacitatea de transmisie Tx şi capacitatea de recepţie Rx a datelor –
valorile curente, inclusiv în formă grafică, valorile medii în ultimele 10 s şi
valorile medii totale.
3. De oprit testarea, apăsând butonul Stop.
232
6.6.2. Monitorizarea traficului folosind utilita Traffic
Pentru monitorizarea traficului pot fi folosite aşa instrumente/
funcţionalităţi ca Traffic, Torch şi Graffing. Traffic serveşte pentru
monitorizarea traficului unei interfeţe a ruterului şi se accesează acţionând
/Interface/Interface List/Interface/dublu click pe înregistrarea_ce_reprezintă
interfaţa_respectivă/Interface <nume_interfaţă>/fila Traffic.
Sarcina practică 6.5. Monitorizarea traficului printr-o o interfaţă a
ruterului utilizatorului. Fie se cere de vizualizat traficul prin interfaţa ether2 a
ruterului utilizatorului. În acest scop:
1. De acţionat /Interface/Interface List/Interface/dublu click pe înregistrarea
ether2/Interface <ether2>/fila Traffic (fig. 6.33).
2. De observat şi interpretat informaţia privind traficul prin interfaţa ether2.
3. De închis fereastra Interface List.
Fig. 6.32. Folosirea Bandwidth Test. Fig. 6.33. Traficul la interfaţa ether2.
233
6.6.3. Monitorizarea traficului folosind Torch
Utilita Torch permite monitorizarea în timp real a traficului de date printr-o
interfaţă anume. Traficul poate fi clasificat şi filtrat de Torch după protocol,
adresa sursei, adresa destinaţiei şi port. Astfel se poate afla pentru ce se
foloseşte capacitatea de transfer date prin interfaţa respectivă.
Pentru a accesa Torch, se acţionează /Tools/Torch sau se execută clic
dreapta pe înregistrarea unei interfeţe sau cea a unei cozi şi, apoi, Torch.
Ulterior, în fereastra Torch ce se va afişa, se specifică/selectează interfaţa şi
parametrii de clasificare/filtrare. Ulterior, apăsând butonul Start, se lansează
Torch. Pentru a opri Torch, se apasă butonul Stop. Două exemple de folosire a
Torch sunt prezentate în s. 5.6 (fig. 5.25) şi s. 6.3.2 (fig. 6.13). Un alt exemplu
este prezentat în cele ce urmează.
Exemplul 6.15. Determinarea sursei traficului de date folosind Torch. Fie
se cere determinarea sursei traficului de date prin interfaţa wlan1 a ruterului,
folosind Torch. În acest scop:
1. Se acţionează /Tools/Torch, Interface – wlan1/Start.
2. De analizat sursele traficului de date în coloana Src. a ferestrei Torch (fig. 6.34).
Din figura 6.34 se poate observa că prin interfaţa wlan1 (adresa IP
192.168.1.100) se transferă date provenite de la sursele cu adresele IP
176.9.54.187, 195.246.242.120, etc.
Fig. 6.34. Determinarea sursei traficului de date folosind Torch.
6.6.4. Monitorizarea utilizării resurselor folosind Graphing

Utlita Graphing este destinată monitorizării în timp a diferiţilor parametri
ai RouterOS şi reprezentării grafice a acestora. Ea permite evidenţa, stocarea
şi vizualizarea grafică a condiţiilor de funcţionare a ruterului (voltajul şi
234
temperatura), a folosirii capacităţii interfeţelor (Interface Graphs), a traficului
cozilor simple (Queue Graphs) şi a utilizării resurselor ruterului (Resource
Graphs), ultimele incluzând procesoarele, memoria disc şi memoria RAM.
Graphing operează în două etape de bază: colectarea datelor şi redarea
datelor preliminar procesate. Colectarea şi forma de redare grafică a datelor
se configurează, în funcţie de dispozitivele concrete implicate. Graficele
obţinute pot fi vizualizate în WinBox sau un explorator Web.
Pentru specificarea graficelor necesare, servesc regulile Graphing, care se
definesc în file aparte (Interface Rules, Queue Rules şi Resource Rules) ale
ferestrei Graphing, pentru fiecare din cele trei categorii de grafice (Interface
Graphs, Queue Graphs şi Resource Graphs). Valoarea implicită, pentru câmpul
Interface, în regulile Interface Graphing, şi pentru câmpul Simple Queue, în
regulile Queue Graphing, este all, ceea ce înseamnă că vor fi monitorizate
toate interfeţele şi toate cozile simple.
În regulile de toate cele trei categorii, poate fi limitat (la o singură staţie
sau la staţiile unei subreţele) setul de staţii, de la care va fi posibilă vizualizarea
graficelor obţinute folosind un explorator Web. În acest scop, în caseta de
dialog de definire a regulii, în câmpul Allow Address se va specifica adresa IP a
staţiei sau cea a subreţelei respective. Totodată, dacă, la definirea unei reguli
de coadă simplă (Simple Queue), în câmpul Target Address va fi specificată
adresa 0.0.0.0/0, atunci oricine va putea accesa graficele de trafic, indiferent
de conţinutul câmpului Allow Address, deoarece implicit graficele cozilor sunt
accesibile şi de la adresa ţintă.
În funcţie de categorie, graficele pot fi construite, la alegere, pentru
anumite perioade:
 Interface Graphs – 5 min (min), 1 oră (hour), 24 ore (hours);
 Resource Graphs – 1 zi (Daily), 1 săptămână (Weekly), 1 lună (Monthly) şi
1 an (Yearly).
În ce priveşte Queue Graphs, graficele, predefinit, se prezintă pentru toate
cele patru perioade: 1 zi (Daily) – media fiind calculată pentru fiecare 5 min; 1
săptămână (Weekly) – media fiind calculată pentru fiecare 30 min; 1 lună
(Monthly) – media fiind calculată pentru fiecare 2 ore; şi 1 an (Yearly) – media
fiind calculată pentru fiecare 1 zi.
Graficele create pot fi stocate în memoria ruterului. Pentru aceasta, în
caseta de dialog de definire a regulii respective, trebuie bifată opţiunea Store
on Disk. Ulterior, acestea pot fi vizualizate în WinBox sau un explorator Web.
Pentru vizualizarea graficelor în WinBox, se activează, prin clic, înregistrarea
graficului concret în fila respectivă a ferestrei Graphing: Interface Graphs,
Queue Graphs sau Resource Graphs.
Într-un explorator Web, graficele Graphing pot fi vizualizate folosind utilita
WebFig a RouterOS. În acest scop, în câmpul pentru URL al exploratorului
235
Web, se specifică adresa IP a ruterului. Se va afişa fereastra de lucru a WebFig.
În meniul principal al acesteia, se va executa clic pe butonul Graphs (fig. 4.9
din s. 4.1.5). Se va afişa lista de grafice disponibile (fig. 6.35), fiecare din care
poate fi accesat prin clic cu şoricelul.
Fig. 6.35. Lista graficelor disponibile la ruter în WebFig.

În exemplul din figura 6.35, sunt disponibile graficele: utilizării resurselor
procesorului (CPU usage), memoriei RAM (Memory usage) şi memoriei disc
(Disk usage); traficului cozilor simple sQueuePC1 şi sQueueServer; traficului
interfeţelor ether1, ether2, ether3, ether4, ether5, ether6 şi wlan1. Pentru
accesarea fiecăruia din acestea, se execută dublu clic pe numele lui.
Exemplul 6.16. Monitorizarea traficului cozilor simple folosind Graphing.
Fie se cere obţinerea şi vizualizarea traficului, utilizat de fiecare din staţiile
subreţelei 192.168.20.0/24, folosind Graphing. Se va considera că în
subreţeaua 192.168.20.0/24 sunt două staţii cu adresele IP: 192.168.20.1 şi
192.168.20.253. În acest scop:
1. Se creează câte o coadă simplă pentru fiecare adresă IP de staţie a
subreţelei 192.168.20.0/24: sQueuePC1 – pentru staţia 192.168.20.1 şi
sQueueServer – pentru staţia 192.168.20.253. Ca adresă ţintă (Target
Address) se va specifica adresa IP 192.168.20.1 şi, respectiv, cea
192.168.20.253. Modalitatea de creare a unor asemenea cozi este descrisă
în exemplul 6.1 din s. 6.3.2, doar că nu se va limita traficul de date (fig. 6.36).
2. Se creează o regulă Queue Graphing, acţionând /Tools/Graphing/fila Queue
Rules, +/New Queue Graphing Rule, Simple Queue – all, Allow Address –
0.0.0.0/0 /OK (fig. 6.37).
3. Pentru vizualizarea graficului cozii sQueuePC1, se acţionează /Tools/
Graphing/fila Queue Graphs/dublu clic pe înregistrarea sQueuePC1. Se va
afişa fereastra Queue Graph <sQueuePC1> cu patru file: Daily, Weekly,
Monthly şi Yearly, în care şi pot fi vizualizate graficele respective.
236
Fig. 6.36. Cozile simple la exemplul 6.16.
Fig. 6.37. Regula Queue Graphing.

Exemplul 6.17. Monitorizarea traficului prin
interfeţele ruterului folosind Graphing. Fie se
cere monitorizarea traficului prin toate
interfeţele ruterului. În acest scop:
1. Se creează o regulă Interface Graphing pentru
toate interfeţele ruterului, acţionând
Fig. 6.38. Graficul traficului
Tools/Graphing/Interface Rules/+/New
prin interfaţa ether2.
Interface Graphing Rule, Interface – all, Allow
Address – 0.0.0.0/0 /OK.
2. Pentru vizualizarea graficului pentru interfaţa, de exemplu, ether2, se
acţionează Tools/Graphing/Interface Graphs/dublu clic pe înregistrarea
ether2. Se va afişa fereastra Interface Graph <ether2> (fig. 6.38).
În acelaşi mod pot fi create regulile pentru monitorizarea resurselor
ruterului. Exemple de vizualizare în WinBox a graficelor de folosire a memoriei
RAM şi a procesorului ruterului sunt prezentate în figurile 6.39 şi 6.40.
237
Fig. 6.39. Utilizarea procesorului. Fig. 6.40. Graficul utilizării RAM.
Două grafice, afişate folosind utilita WebFig, sunt prezentate în figurile
6.41 (folosirea procesorului) şi 6.42 (folosirea memoriei RAM).
Fig. 6.41. Graficul utilizării memoriei RAM, în utilita WebFig.
Din figura 6.41 se poate observa că folosirea memoriei RAM a ruterului

puţin se modifică în timp. Nu se poate spune acelaşi lucru despre traficul de
date prin interfaţa ether2.
6.6.5. Monitorizarea şi gestiunea reţelei folosind SNMP
Serviciul SNMP se realizează conform Protocolului simplu de gestiune a
reţelei (vezi s. 1.7.8), larg utilizat în Internet pentru gestiunea valorificării
eficiente a diverselor resurse. Ca protocol de transport, SNMP foloseşte UDP,
iar la nivelul Reţea (Internet) suportă protocoalele IP, IPX şi Apple Talk.
SNMP este asociat, in general, cu administrarea de rutere, dar poate fi
folosit pentru a administra orice tip de componente care suportă acest
protocol, acceptând comenzi SNMP. Poate fi folosit pentru monitorizarea
traficului atât în reţele locale, cât şi în reţele de arie largă. Este foarte util
238
pentru depistarea problemelor în rețea, dar şi pentru identificarea staţiilor
care descarcă relativ multe date.
Fig. 6.42. Traficul prin interfaţa ether2, în utilita WebFig.

Deoarece ruterele nu au, de obicei, multă memorie, salvarea datelor se
poate face pe un server web. În acest scop, informaţia între ruter și calculator
se transmite prin SNMP.
Serviciul SNMP este implementat şi în RouterOS, fiind, implicit, dezactivat.
Pentru activarea SNMP, se acţionează /IP/SNMP şi, în caseta de dialog SNMP
Settings ce se va afişa (fig. 6.43a), se bifează Enabled. Totodată, se recomandă
ca şi în câmpul Trap Community de modificat valoarea implicită public a
numelui comunităţii ruterului pe o altă comunitate specifică, pentru a îngusta
accesul la SNMP. În acest scop, se va apăsa butonul Communities şi, în
fereastra SNMP Communities ce se va afişa (fig. 6.43b), se va adăuga o nouă
înregistrare (fereastra New SNMP Community), care apoi va fi posibil de
selectat pentru câmpul Trap Community.
Semnificaţiile parametrilor de configurare a SNMP din figura 6.43a sunt:
 Contact Info – informaţia de contact;
 Location – informaţia de localizare;
 Engine ID – pentru SNMPv3, este o parte din identificator;
 Trap Target – adresele IP ale colectorilor de date SNMP, care vor primi
captoare (traps);
 Trap Community – comunitatea folosită la trimiterea captoarelor;
 Trap Version – versiunea protocolului SNMP de utilizat pentru captoare
(există versiunile 1, 2 şi 3, implicit este protocolul SNMPv1);
 Trap Generators – acţiunea care va genera captoare:
239
- interfaces – schimbările în interfeţe;
- start-trap – serverul SNMP ce va starta pe ruter;
 Trap Interfaces – lista interfeţelor de transmitere a captoarelor.
a) setările SNMP b) setarea comunităţii bit

Fig. 6.43. Configurarea serviciului SNMP.
La configurarea comunităţii (Community), în fereastra New SNMP
Community (fig. 6.43b), se definesc drepturile de acces la datele SNMP.
Versiunile SNMPv1 şi SNMPv2 sunt slab securizate, acestea reducându-se,
practic, la limitarea accesului la serviciul SNMP de la o adresă IP anume.
Versiunea SNMPv3 include, de asemenea, autorizarea prin nume de utilizator
şi parolă, securizate folosind MDS/SHA1 şi cifrarea DES. Semnificaţiile
parametrilor de configurare a comunităţii, în fereastra New SNMP Community
(fig. 6.43b), sunt:
 Name – identificatorul (numele) comunităţii;
 Addreses – adresele, de la care se permite conectarea la serverul SNMP,
predefinit este 0.0.0.0/0 (toţi);
 Security – gradul de securitate: autorizată (autorized), fără securizare
(none) sau privată (private);
 Read Access – drepturi de citire (read) pentru comunitate;
 Write Access – drepturi de scriere (write) pentru comunitate;
 Authentification Protocol – protocolul folosit pentru autentificare
(SNMPv3), predefinit este MD5, dar poate fi setat şi cel SHA1;
 Ecryption Protocol – protocolul folosit pentru cifrarea comunicărilor
(SNMPv3), predefinit este DES;
 Authentification Password – parola folosită pentru autentificarea
conexiunii la serverul SNMP (SNMPv3);
 Ecryption Password – parola folosită pentru cifrare (SNMPv3).
Informaţiile de monitorizare se determină de către agenţii de administrare
(vezi s. 1.7.8) şi se păstrează în Baza informaţiilor de gestiune (Management
240
Information Base – MIB). Informaţia din MIB este folosită de către Sistemul de
gestiune a reţelei (Network Management System – NMS). În RouterOS se
folosesc aşa MIB ca [1]: MIKROTIK-MIB, MIB-2, HOST-RESOURCES-MIB, IF-MIB,
IP-MIB, IP-FORWARD-MIB, IPV6-MIB, BRIDGE-MIB, DHCP-SERVER-MIB, CISCO-
AAA-SESSION-MIB, ENTITY-MIB, UPS-MIB şi SQUID-MIB. Fişierul actualizat MIB
al RouterOS poate fi descărcat de la adresa www.mikrotik.com/download/
Mikrotik.mib.
MIB descrie structura datelor de gestiune pentru dispozitive, folosind un
spaţiu ierarhic de nume ce conţin identificatori de obiecte (Object Identifiers –
OID). Fiecare OID identifică o variabilă aparte, care poate fi citită prin SNMP.
Captoarele (traps) trimise de SNMP activează ruterul, privind notificarea
schimbărilor în interfeţe și a modificărilor de stare a serviciilor SNMP. Este
posibil de a trimite captoare cu proprietăţi de securitate în suportul SNMPv1
(care este fără securizare) şi, de asemenea, cele pentru SNMPv2 și SNMPv3, cu
cifrare și autorizare.
Drepturile de scriere (write) SNMP permit modificarea configurării
ruterului, inclusiv pentru securizarea accesului la ruter sau la SNMP a acestuia.
Acestea permit, de asemenea, lansarea de scripturi pe ruter
(/System/Scripts). Prin SNMP poate fi reîncărcat (reboot) ruterul.
RouterOS poate fi configurat şi pentru a folosi MRTG (Multi Router Traffic
Grapher), care serveşte tot pentru monitorizarea şi reprezentarea grafică a
traficului de date prin interfeţele dispozitivelor de reţea ce suportă SNMP.
MRTG lucrează în Unix/Linux, Windows şi Netware şi poate fi descărcat fără
plată de la oss.oetiker.ch/mrtg/download.en.html. Modalitatea de configurare
a MRTG este descrisă la adresa wiki.mikrotik.com/wiki/ SNMP_MRTG.
241
7. GESTIUNEA LOCALĂ A REŢELELOR
7.1. Protocolul ARP în RouterOS
7.1.1. Funcţionalităţi ARP în RouterOS
Pentru translatarea adreselor,
RouterOS menţine un tabel ARP, care
poate fi accesat acţionând /IP/ARP.
Fiecare înregistrare a unui asemenea
tabel conţine: tipul înregistrării ARP
(dinamică – D sau statică – spaţiu), Fig. 7.1. Un tabel ARP.
adresa IP (IP Address) şi adresa MAC
(MAC Address) ale interfeţei, cu care interacţionează interfaţa ruterului, și
numele (Interface) ultimei (fig. 7.1). Astfel, pentru fiecare înregistrare, a doua
şi a treia coloane ale tabelului ARP constituie perechea de adrese „adresa IP –
adresa MAC” ce se referă la aceeaşi interfaţă, potenţială destinaţie.
Predefinit, tabelul ARP se actualizează în mod automat, dinamic, dar poate
fi configurat, parţial sau complet, şi manual, static. Mai mult ca atât, la una şi
aceeaşi interfaţă a ruterului, unele înregistrări ARP pot fi dinamice, iar altele –
statice. Configurarea statică a tabelului ARP permite, uneori, sporirea
securităţii reţelei, dar trebuie de avut grijă de actualizarea la timp a acestuia.
Pentru fiecare interfaţă, ARP poate fi configurat în unul din modurile:
 disabled;
 enabled;
 proxy-arp;
 reply-only.
În modul disabled, funcţionalităţile ARP sunt dezactivate. Ruterul nu va
trimite cereri ARP şi nici nu va răspunde la solicitări ARP din exterior. Uneori se
foloseşte în scopuri de securitate. În asemenea cazuri, înregistrările ARP
necesare trebuie introduse în tabelele ARP în mod manual, la ambele
echipamente de reţea ce interacţionează. Dar există şi echipamente, care nu
permit introducerea manuală a înregistrărilor ARP.
În modul enabled, funcţionalităţile ARP sunt activate. Mesajele ARP se
identifică şi la ele se răspunde în mod automat, iar înregistrările respective în
tabelul ARP se actualizează dinamic. Este modul predefinit şi cel mai folosit;
În modul proxy-arp, RouterOS va funcţiona ca un ARP proxy transparent
între reţelele interconectate direct. Orice solicitare ARP recepţionată, interfaţa
proxy-arp, fie una I, o înaintează către alte interfeţe. Dacă un alt dispozitiv, la
una din alte interfeţe, are adresa IP specificată, acesta va răspunde interfeţei I.
Interfaţa I, la rândul său, va răspunde primei solicitări ARP, comunicând că ea
242
înseşi deţine adresa IP, dar la adresarea respectivă va translata adresa IP la
adresa MAC a interfeţei care a răspuns de la un alt dispozitiv. Astfel, modul
proxy-arp de operare poate fi privit ca translator de adrese de Nivel 2 OSI,
similar cu masquerade pentru nivelul 3 OSI (vezi s. 5.5.1).
În modul reply-only, RouterOS doar va răspunde la cererile ARP,
comunicând, în baza înregistrărilor ARP statice, adresele MAC corespondente
adreselor IP. El înseşi nu va trimite asemenea solicitări şi nici nu va înregistra,
în tabelul ARP propriu, perechile „adresa IP-adresa MAC” ale altor dispozitive.
Aceasta previne posibilitatea comunicării RouterOS cu alte dispozitive ale
subreţelei, deoarece pentru acestea lipsesc înregistrările ARP respective. Acest
mod ARP poate fi oportun, în unele cazuri, în scopuri de securitate. Pentru
staţiile, cu care este necesară, totuşi, comunicarea, înregistrările ARP
respective trebuie introduse în tabelele ARP în mod manual.
Totodată, simplifică implementarea acestui mod, folosirea funcţionalităţii
„Add ARP for Leases” a serverului DHCP. Acesta va înscrie, în mod automat, în
tabelul ARP, înregistrările ARP pentru dispozitivele (adresele IP) gestionate.
Astfel, îmbinând modul ARP reply-only cu opţiunile „Add ARP for Leases” ale
serverului DHCP, ruterul va avea posibilitatea să comunice doar către
dispozitivele, cărora serverul DHCP le-a alocat adrese IP. El nu va avea
posibilitatea să comunice şi către alte dispozitive, fie chiar şi din aceeaşi
subreţea.
7.1.2. Configurarea ARP
Înregistrările ARP dinamice se configurează de RouterOS în mod automat.
În ce priveşte cele statice, acestea pot fi atât înregistrări noi, cât înregistrări
reconfigurate din cele dinamice.
Exemplul 7.1. Configurarea statică a unei noi înregistrări ARP. Fie se cere
crearea unei înregistrări ARP noi statice ce ţine de interfaţa ether2, pentru
interfaţa cu adresa MAC D4:CA:6D:2B:01:03 şi adresa IP 192.168.20.253. În
acest scop:
1. Se afişează fereastra ARP List (tabelul ARP), acţionând /IP/ARP.
2. Fie că în ARP List lipseşte înregistrarea pentru perechea {192.168.20.253;
D4:CA:6D:2B:01:03}. Atunci se creează o nouă înregistrare ARP ce ţine de
ether2, acţionând /ARP List, +/New ARP, IP Address – 192.168.20.253, MAC
Address – D4:CA:6d:2B:01:03, Interface – ether2/OK (fig. 7.2).
3. Se poate observa că în prima coloană
a noii înregistrări din fig. 7.3 lipseşte
caracterul D, ceea ce confirmă că
această înregistrare este una statică.
Exemplul 7.2. Reconfigurarea în
statică a unei înregistrări ARP dinamice. Fig. 7.2. Configurarea ARP statică.
243
Fie se cere reconfigurarea în statică a
înregistrării ARP dinamice existente ce
ţine de interfaţa ether2, pentru interfaţă
cu adresa MAC 00:E0:4d:1A:B4:F7 şi
adresă IP 192.168.20.1. În acest scop:
1. Se afişează fereastra ARP List (tabelul Fig. 7.3. Înregistrarea statică.
ARP), acţionând /IP/ARP.
2. Fie că în ARP List este deja înregistrarea pentru perechea {192.168.20.1;
00:E0:4D:1A:B4:F7} şi aceasta este una dinamică, ceea ce se confirmă prin
prezenţa caracterului D în prima coloană. Atunci aceasta se reconfigurează
în una statică, acţionând clic dreapta pe ea şi în meniul contextual ce se va
afişa selectând opţiunea Make Static. O altă modalitate, cu acelaşi efect,
constă în dublu clic pe înregistrarea ARP cu perechea {192.168.20.1;
00:E0:4d:1A:B4:F7} şi în fereastra de dialog ARP <192.168.20.1> se apasă
butonul Make Static/OK.
3. Se poate observa că în prima
coloana a înregistrării în cauză (fig.
7.3 şi 7.4) a dispărut caracterul D,
ceea ce confirmă că această
înregistrare a devenit una statică.
4. De revenit la configurarea dinamică Fig. 7.4. Noul tabel ARP.
a înregistrării statice recent reconfigurate. În acest scop, înregistrarea în
cauză se şterge. RouterOS de unul singur va avea grijă să o restabilească ca
una dinamică.
Sarcină practică 7.1. Configurarea statică a înregistrărilor ARP. Se cere
reconfigurarea statică a înregistrării ARP dinamice ce ţine de interfaţa de
conectare a calculatorului la interfaţa ether2 a ruterului, fără a modifica
adresa MAC şi cea IP, şi, de asemenea, crearea unei înregistrări noi statice ce
ar ţine de aceeaşi interfaţă ether2.
1. De reconfigurat înregistrarea ARP dinamică ce ţine de interfaţa de
conectare a calculatorului la interfaţa ether2 a ruterului, acţionând
/IP/ARP/ARP List, clic dreapta pe înregistrarea ARP dinamică de reconfigurat
şi, în meniul contextual ce se va afişa, se va selecta opţiunea Make
Static/OK.
2. Se va observa lipsa caracterului D din prima coloană a înregistrării ARP.
3. De dezactivat regimul ARP dinamic pentru interfaţa ether2, acţionând
/Interface/Interface List, dublu clic pe înregistrarea ether2/Interface
<ether2>/General, ARP – reply-only/OK.
3. De modificat adresa IP a calculatorului.
4. De întrerupt şi apoi de reanimat legătura prin cablu cu calculatorul.
244
4. De încercat accesarea unui server din Internet. Accesul ar trebui să nu
reuşească.
5. De revenit la configurările anterioare.
7.2. Configurarea dinamică a staţiilor – DHCP

Protocolul DHCP (vezi s. 1.7.11) este destinat alocării de adrese IP staţiilor,
fiind de arhitectură client-server. RouterOS permite configurarea atât a
serverelor DHCP, cât şi a clienţilor DHCP. Aceştia se configurează pe interfeţele
reale ale ruterului, dar nu mai mult de un sistem DHCP pe o interfaţă.
Totodată, serverul DHCP nu poate fi configurat pe un port de punte, adică pe o
interfaţă ce ţine de o grupă de punte (bridge group). Acesta poate fi configurat
pe o interfaţă de punte, dar nu pe una ce face parte dintr-o grupă de punte.
De obicei se foloseşte un singur server DHCP cu fiece subreţea.
7.2.1. Configurarea clienţilor DHCP
Clientul DHCP se configurează, la necesitate, pe o interfaţă a ruterului. La
solicitarea informaţiilor de la serverul DHCP, clientul DHCP are posibilitatea să
comunice serverului numele sistemului clientului (Hostname) şi identificatorul
clientului (Client ID) – figura 7.5. Dacă parametrul Hostname nu se va specifica,
atunci se va folosi identitatea sistemului clientului, iar dacă parametrul Client
ID nu se va specifica, atunci la server
se va comunica adresa MAC a
interfeţei clientului.
Pentru configurarea clientului
DHCP, se acţionează /IP/DHCP Client.
Se va afişa fereastra DHCP Client, în
fila DHCP a căreia, câmpul Interface,
se selectează interfaţa pe care se
configurează clientul DHCP (în fig. 7.5
– wlan1), iar pentru ceilalţi parametri
Fig. 7.5. Setarea clientului DHCP.
se păstrează, de obicei, valorile
implicite.
Configurările obţinute de la serverul DHCP pot fi vizualizate în fila Status a
ferestrei DHCP Client, inclusiv: adresa IP (IP address) a clientului, poarta
(Gateway), adresa IP a serverului (DHCP Server), intervalul de timp pentru care
sunt alocaţi parametrii obţinuţi (Expires After); adresa serverelor DNS – primar
(Primary DNS) şi secundar (Secondary DNS); serverele NTP – primar (Primary
NTP) şi secundar (Secondary NTP).
245
7.2.2. Configurarea serverelor DHCP
7.2.2.1. Înscrieri DHCP ordinare
Serverul DHCP se configurează pe o interfaţă cu adresă IP, specificând aşa
informaţii ca: interfaţa pe care se configurează serverul DHCP (Interface);
spaţiul de adrese IP ale serverului DHCP (DHCP Address Space), acesta fiind, de
obicei, cel al subreţelei pentru care va fi instalat serverul; adresa IP a porţii
(Gateway for DHCP Network); diapazonul de adrese IP, de folosit pentru
atribuire clienţilor la solicitare (Addresses to Give Out); serverele DNS (DNS
Servers). Toate aceste informaţii se specifică în câmpurile respective, ce se
afişează pe paşi de asistentul DHCP Setup de instalare a serverului DHCP.
Astfel, se acţionează /IP/DHCP Server/DHCP, DHCP Setup/DHCP Setup,
DHCP Server Interface – ether2, Next/DHCP Address Space – 192.168.20.0/24
/Next/Gateway for DHCP Network – 192.168.20.254/Next/Addresses to Give
Out – 192.168.20.1-192.168.20.253/Next/DNS Servers – 192.168.1.1/Next/
Lease Time – 3d 00:00:00/Next/.
În acest exemplu, serverul DHCP este instalat pe interfaţa ether2 de
conectare a calculatorului la ruter. Ca fond de adrese IP, de folosit pentru
atribuire clienţilor la solicitare, este configurat întreg diapazonul disponibil al
subreţelei 192.168.20.0/24, având în vedere că adresa 192.168.20.254 este
cea a interfeţei ether2. Acest fond poate fi însă modificat, la necesitate. În
acest scop, se va acţiona /IP/Pool. Se va afişa fereastra IP Pool cu fondurile
comune de adrese IP, în fila Pools, şi adresele în folosinţă – în fila Used
Addresses. Pentru a modifica un fond de adrese, se execută dublu clic pe
înregistrarea acestuia şi, în fereastra de dialog IP Pool <nume_fond> ce se va
afişa, se vor efectua modificările necesare. Alte informaţii, privind
configurarea fondului comun de adrese IP, pot fi regăsite în s. 11.3.2.
Ca adresă de server DNS, în exemplu este specificată adresa IP
(192.168.1.1) a unui alt ruter, la care este conectat ruterul în cauză prin
subreţeaua 192.168.1.0/24. Dar putea fi specificată şi adresa unei alte
interfeţe a ruterului, la care este conectat calculatorul. Parametrul Lease Time
(timpul de arendă) – specifică durata de timp pentru care sunt valabili
parametrii, obţinuţi de către client de la serverul DHCP. După expirarea
acesteia, clientul DHCP trebuie să trimită o nouă cerere către serverul DHCP.
Informaţiile despre clienţii serverului DHCP instalat pot fi regăsite în fila
Leases a ferestrei DHCP Server (fig. 7.6). Fila Networks conţine înregistrări cu
informaţii despre reţelele DHCP de la ruter, inclusiv: adresa reţelei, poarta
implicită, serverele DNS, serverele NTP ş.a. Dacă careva configurări, ce ţin de o
reţea DHCP concretă, încă nu sunt efectuate, acestea pot fi setate în fereastra
de dialog DHCP Network ce se va afişa la dublu clic pe înregistrarea în cauză.
246
Sarcină practică 7.2. Configurarea serverelor DHCP. Se cere configurarea
serverului DHCP pentru subreţeaua 192.168.x.0/24. Acesta se va configura pe
interfaţa ether2 de conectare a calculatorului la ruter. În acest scop:
1. Se acţionează /IP/DHCP Server/DHCP, DHCP Setup/DHCP Setup, DHCP
Server Interface – ether2, Next. La toate celelalte configurări, se folosesc
valorile implicite şi se apasă butonul Next. Dacă interfața, pe care se
instalează serverul DHCP, este configurată corect (adresa IP, adresa rețea),
atunci nu trebuie sa apară probleme la instalare.
2. De configurat interfaţa calculatorului ca şi un client DHCP, adică “Obtain an
IP address automatically”.
3. De analizat înregistrarea, privind serverul DHCP instalat, în fereastra DHCP
Server, fila DHCP.
4. De consultat parametrii, atribuiţi de RouterOS serverului DHCP, în fereastra
DHCP Server, fila Leases. Un exemplu este dat în figura 7.6. Dacă este
necesar, se pot adăuga/elimina coloane în câmpul ferestrei – vezi nota din
s. 4.7.3. În prima coloană a înscrierii din fig.7.6 este specificat tipul înscrierii
(D – dinamică, spaţiu – statică), iar în coloana Active Host Name – numele
calculatorului, căruia serverul DHCP ia atribuit adresa 192.168.20.1.
5. De verificat legătura ruter-calculator, folosind comanda ping. Aceasta
trebuie să fie valabilă.
6. De verificat accesul la Internet de la calculator. Acesta trebuie să reuşească.
Fig. 7.6. Unii parametri atribuiţi serverului DHCP.
7.2.2.2. Înscrieri DHCP statice

Uneori este necesar ca staţiile unei reţele locale să primească, de la
serverul DHCP, aceleaşi adrese IP. Ca exemple ar putea servi: serverele,
247
telefoanele IP, comutatoarele ş.a. Un aşa rezultat se poate obţine folosind
înscrieri DHCP statice.
La necesitate, orice înscriere dinamică, din fila Leases a ferestrei DHCP
Server, poate fi reconfigurată în una statică. Pentru aceasta, înscrierea
respectivă se selectează (prin clic), iar ulterior se apasă butonul Make Static
din bara cu instrumente a filei Leases (fig. 7.7). Caracterul D din prima coloană
a înregistrării va dispare şi clientul va avea deja o adresă IP statică; lui nu-I voi
mai fi atribuite alte adrese IP .
Deşi serverul DHCP operează, de obicei, cu un fond de adrese IP,
distribuind dinamic, la cerere, adrese IP clienţilor, el poate opera şi fără un
asemenea fond şi doar cu înscrieri statice. În asemenea cazuri, clienţii vor
primi doar adrese IP preconfigurate. Scopul unei asemenea implementări
constă în sporirea securităţii reţelei DHCP respective.
Fig. 7.7. Reconfigurarea în statică a unei înscrieri dinamice.

O cale facilă de creare a unei asemenea reţele constă în configurarea unui
server DHCP standard cu un fond comun de adrese. După ce toate
dispozitivele reţelei au obţinut adresele IP de la serverul DHCP, toate
înscrierile dinamice respective de convertit în statice. În acest scop:
1. În fila Leases a ferestrei DHCP Server, toate înscrierile dinamice, privind
clienţii ce ţin de serverul DHCP în cauză, se reconfigurează în statice, după
cum este descris mai sus în această secţiune.
2. În fila DHCP a ferestrei DHCP Server, se execută dublu clic pe înregistrarea
ce ţine de serverul DHCP în cauză. Se va afişa fereastra de dialog DHCP
Server <nume_DHCP_server>, în câmpul Address Pool al căreia se va selecta
static-only. Astfel, doar dispozitivele reţelei, pentru care au fost create
înscrieri statice, vor putea obţine adrese IP de la serverul DHCP (fig. 7.8).
7.2.3. Relee DHCP
Releu DHCP (DHCP Relay) este mandatarul (proxy), care poate recepţiona
solicitări DHCP şi a le retransmite unui server DHCP real. Pentru instalarea unui
releu DHCP, se acţionează /IP/DHCP Relay, +/. Se va afişa fereastra New DHCP
Relay, în fila General a căreia se configurează releul DHCP,
specificând/selectând aşa informaţii ca (fig. 7.9):
 în câmpul Name – numele releului DHCP;
 în câmpul Interface – interfaţa pe care se creează releul DHCP;
248
 în câmpul DHCP Server – adresa IP a serverului DHCP, căruia releul DHCP
îi va retransmite solicitările clienţilor DHCP.
Fig. 7.8. Setarea fondului de adrese static-only.

Se va configura corespunzător, de asemenea, şi serverul DHCP real cu un
fond de adrese IP respective. Totodată, pentru ca acest server să răspundă
doar la solicitările releu, în fila DHCP a ferestrei DHCP Server, se execută dublu
clic pe înregistrarea ce ţine de serverul DHCP în cauză. Se va afişa fereastra de
dialog DHCP Server <nume_DHCP_server>, în câmpul Relay al căreia (vezi, de
exemplu, fig. 7.8) se va specifica adresa IP a releului DHCP.
Releele DHCP permit centralizarea funcţiilor de alocare a adreselor IP
dispozitivelor unei reţele, folosind un server DHCP şi un fond de adrese IP
comun pentru întreaga reţea. În fiecare
subreţea a reţelei se creează câte un
releu DHCP. Toate releele DHCP
retransmit solicitările clienţilor DHCP
către unicul server DHCP, care şi
răspunde la aceste solicitări. O
asemenea implementare poate
conduce la folosirea mai raţională a Fig. 7.9. Setarea unui releu DHCP.
resurselor.
7.3. Accesul imediat autorizat la resurse – Hotspot

7.3.1. Esenţă Hotspot
Sistemul Hotspot (loc fierbinte) reprezintă o poartă (gateway) de acces
imediat, Plug-and-Play, de la diverse staţii, îndeosebi portabile, la i-reţele
publice cu autentificare, evidenţă şi gestiunea folosirii resurselor de către
249
utilizatori. Accesul se realizează, de obicei, printr-o reţea locală fără fir, dar nu
obligatoriu – poate fi folosită şi o reţea cablată. Pentru acces, utilizatorul nu
are nevoie de instalarea la staţie a vreunor i-programe adiţionale; este
suficientă folosirea unui explorator Web. Hotspot este orientat la autorizarea
accesului la Internet printr-o reţea locală (LAN Internet), dar poate fi
folosit, de asemenea, şi în direcţia inversă – accesarea din exterior a resurselor
unei reţele locale (Internet LAN).
Reţelele locale fără fir cu acces public pentru prima data au fost propuse în
1993 de Henrik Sjodin. Termenul Hotspot a fost iniţial folosit de Deutsche
Telecom în 2001 în denumirea companiei “T-Mobile Hotspot”.
Accesul la Internet prin Hotspot se foloseşte îndeosebi în locuri publice
aglomerate, inclusiv: gări, gări auto, aeroporturi, campusuri universitare,
saloane Internet, spitale, librării, magazine, pieţe, hotele, cafenele, parcuri,
restaurante ş.a.
De obicei Hotspot reprezintă un punct de acces (Access Point) fără fir
nesecurizat, implementat în cadrul unui ruter conectat la Internet. El poate fi,
de asemenea, implementat în cadrul unui calculator, inclusiv PC, cu port Wi-Fi.
Hotspot operează la Nivelul 2 OSI şi se aplică la o interfaţă.
Crearea unui sistem Hotspot implică aşa sarcini ca: asigurarea clienţilor cu
adrese IP; afişarea paginii de logare a clienţilor; accesarea de către utilizatori a
paginilor Web în mod obişnuit folosind numele lor DNS; oferirea unor servicii
fără autentificare; diverse modalităţi de autentificare; contorizarea folosirii
serviciilor ş.a. Un aspect major de funcţionare a Hotspot este securitatea
funcţionării, fiind posibile cel puţin trei direcţii de atac:
 conexiunea fără fir între staţia client şi AP – dacă nu este securizată,
aceasta poate fi uşor accesată de un străin. Pentru securizare, ea trebuie
cifrată;
 Hotspot înseşi – cifrarea WLAN se încheie la interfaţă; datele necifrate
traversează ulterior protocoale superioare, care pot fi vulnerabile;
 conexiunea între AP şi serverul de acces la distanţă în bandă largă
(Broadband Remote Access Server – BRAS) al furnizorului de servicii
Internet.
Cea mai sigură cale de acces la Internet prin Hotspot, dacă nu se cunoaşte
gradul de securitate al acesteia, este cifrarea capăt-la-capăt (end-to-end). Ca
exemple ar putea servi HTTPS şi SSH.
Hotspot-urile pot fi cu acces gratis sau comerciale. Cele cu acces gratis, la
rândul lor, pot fi deschise (cu acces liber) sau închise (cu acces reglementat).
Hotspot-urile cu acces liber nu necesită autentificare, pe când cele închise
folosesc un Sistem de gestiune a Hotspot (Hotspot Management System).
Acest sistem autorizează accesul la Internet doar anumitor utilizatori. De
250
asemenea, el permite diferenţierea deservirii utilizatorilor, inclusiv privind
calitatea serviciilor acordate.
Hotspot-urile comerciale pot include, suplimentar:
 un portal de captare/pagină de conectare, către care utilizatorii sunt
redirecţionaţi pentru autentificare şi plata serviciilor;
 o aplicaţie pentru achitarea plăţilor, folosind cartele de credit, PayPal etc.;
 funcţionalitatea walled garden (perimetru de acces), care permite
accesul fără autentificare şi fără plată la anumite resurse ş.a.
Poarta Hotspot a RouterOS dispune de aşa funcţionalităţi ca:
 şase metode de autentificare a clienţilor;
 evidenţa şi gestiunea utilizatorilor şi a resurselor folosite;
 perimetru de acces (walled garden) la anumite servicii fără autorizare;
 modificarea paginii de conectare la servicii;
 translatarea automată şi transparentă a oricăror adrese IP ale clienţilor în
adrese IP valide ş.a.
Nucleul Hotspot este pagina de redirectare. Orice pagină ar încerca să o
acceseze un utilizator, asociat cu reţeaua fără fir în cauză, sau care se
conectează printr-o conexiune cablată, Hotspot îl va redirecta către pagina de
logare. Această pagină de redirectare este generată de Hotspot, dar poate fi
programată şi aparte în html. După autentificare, utilizatorul poate naviga în
mod obişnuit.
Pentru acces la Hotspot, clientul trebuie să deţină o adresă IP. Aceasta
poate fi statică sau una obţinută de la un server DHCP. Totodată, sistemul
Hotspot poate, în mod automat şi transparent, pentru uz intern temporar, să
schimbe adresa IP a clientului cu una validă dintr-un fond de adrese IP.
Aceasta permite oferirea accesului temporar la reţea unor dispozitive mobile
sau portabile în mod transparent pentru ele, fără a fi necesară modificarea
prealabilă a setărilor lor. Utilizatorii, spre deosebire de rutere, nu vor observa
translatarea de adrese, efectuată de Hotspot. Tehnica în cauză se numeşte
NAT una-la-una (one-to-one NAT) sau “client universal” (Universal Client).
NAT una-la-una acceptă orice adresă IP de intrare de la o interfaţă de reţea
şi o translatează astfel, ca datele să fie posibil de rutat prin reţele IP standard.
Clienţii pot folosi orice adrese IP preconfigurate. Mai mult ca atât, NAT una-la-
una asigură atribuirea clientului uneia şi aceleiaşi adrese IP, indiferent de la ce
staţie acesta accesează Hotspot. Dar pentru aceasta pe interfeţele, pe care se
foloseşte NAT una-la-una, trebuie să fie activat modul ARP.
RouterOS oferă, pentru Hotspot, un sistem de securizare integrat şi, de
asemenea, accesul temporar, de încercare (trial), al utilizatorilor la anumite
resurse. El suportă aşa funcţionalităţi Hotspot ca: contorizarea utilizatorilor,
gestiunea lăţimii de bandă, folosirea i-barierelor, folosirea perimetrelor de
acces, avertizări în anumite situaţii ş.a. De asemenea, RouterOS oferă un
251
sistem de adrese IP obligatorii (IP Bindings system), care permite: configurarea
translatării statice NAT una-la-una a adreselor IP; ocolirea de către anumiţi
clienţi Hotspot a necesităţii de autentificare; blocarea accesului, de la sistemul
Hotspot, la anumite staţii şi subreţele
La activarea Hotspot pe o interfaţă, sistemul automat instalează mijloacele
necesare pentru afişarea paginii de autentificare a clienţilor neconectaţi. În
acest scop se adaugă reguli dinamice NAT destinaţie. Aceste reguli sunt
necesare pentru redirectarea solicitărilor HTTP sau HTTPS de la utilizatorii
neautorizaţi către pagina de autentificare a Hotspot.
Notă:
1) Utilizatorii conectaţi la interfaţa Hotspot vor fi deconectaţi de la Internet. Pentru
a accesa Internet-ul, ei vor trebui să obţină autorizarea Hotspot, autentificându-se.
2) Instalarea Hotspot prevede implicit crearea de configurări adiţionale:
 a unui server DHCP pe interfaţa Hotspot;
 a unui fond de adrese IP pentru clienţii Hotspot;
 de reguli dinamice i-barieră (de filtrare şi NAT).
(3) La orice tentativă de acces a unei pagini Web, utilizatorul este redirecţionat la
pagina de logare a Hotspot. Pentru deconectare de la Hotspot, utilizatorul trebuie să
apeleze la http://router_IP sau http://Hotspot_DNS.
RouterOS oferă 6 metode diferite de autentificare, care pot fi folosite
aparte sau câte mai multe simultan: HTTP PAP, HTTP CHAP, HTTPS, Cookie,
MAC şi Trial.
Cea mai simplă este metoda HTTP PAP. Aceasta afişează pagina de logare
Hotspot cu câmpuri pentru numele de utilizator şi parolă în formă ordinară
(text obişnuit). La transmisia prin reţea, parola nu se cifrează.
Implicită este metoda HTTP CHAP, care este o dezvoltare a celei HTTP PAP,
incluzând, suplimentar, mijloace CHAP MD5 de cifrare a numelui de utilizator
şi a parolei.
Metoda HTTPS este similară celei HTTP PAP, cu deosebirea că foloseşte un
certificat SSL, pentru stabilirea unei conexiuni securizate cu exploratorul Web
al utilizatorului. Astfel toate transmisiile prin reţea sunt cifrate, inclusiv cele
privind numele de utilizator şi parola.
În cazul metodei Cookie (HTTP Cookie), tot implicită împreună cu cea HTTP
CHAP, după autentificarea reuşită a utilizatorului, datele respective sunt
valabile pentru perioada de timp HTTP Cookie Lifetime – implicit 3 zile. Adică,
în această perioadă, la intrarea în sistem, nu se mai cer datele de autentificare.
Metoda poate fi folosită doar împreună cu una sau mai multe din cele HTTP
PAP, HTTP CHAP sau HTTPS.
Metoda MAC (MAC address) prevede folosirea adresei MAC a staţiei
utilizatorului ca şi nume de conectare, ceea ce simplifică procesul de
specificare a informaţiilor de autentificare.
252
La activarea opţiunii Trial, pe pagina de logare Hotspot apare o referinţă
de încercare (Trial link), care permite accesul la servicii fără autentificare
pentru o perioadă limitată de timp – implicit 30 min. O altă încercare va fi
permisă peste intervalul Trial Uptime Reset – implicit 1 zi.
În RouterOS sistemul Hotspot poate fi accesat acţionând IP/Hotspot. Se va
afişa fereastra Hotspot cu filele:
 Servers – serverele Hotspot locale (pe ruter);
 Server Profiles – profilurile de servere Hotspot;
 Users – utilizatorii sistemului Hotspot;
 User Profiles – profilurile de utilizatori ale sistemului Hotspot;
 Active – lista utilizatorilor Hotspot autorizaţi;
 Hosts – lista staţiilor (clienţilor) active Hotspot şi adresele IP obligatorii
ale NAT una-la-una;
 IP Bindings – regulile de atribuire a adreselor IP obligatorii staţiilor pe
interfeţele Hotspot;
 Service Ports – asistenţi (helpers) de translatare a adreselor pentru NAT
una-la-una;
 Walled Garden – regulile perimetrelor de acces la nivel HTTP (nume DNS,
cereri HTTP);
 Walled Garden IP List – regulile perimetrelor de acces la nivel IP (adrese
IP, protocoale IP);
 Cookies – lista dinamică a înregistrărilor cookie HTTP valide.
În cazurile caracteristice, în cadrul filelor respective se realizează nu doar
vizualizarea, ci şi configurarea proprietăţilor respective (servere, profiluri,
utilizatori, adrese IP obligatorii, perimetre de acces, etc.).
7.3.2. Instalarea serverelor Hotspot
Instalarea unui sistem Hotspot
este similară celei a unui server DHCP
– se foloseşte un asistent special, şi
necesită: adrese IP valide la
interfeţele locale respective şi către Fig. 7.10. Lansarea Hotspot Setup.
Internet; adresele serverelor DNS; cel puţin un utilizator Hotspot.
Pentru instalarea unui server Hotspot, se acţionează /IP/Hotspot/ Servers
şi se apasă butonul Hotspot Setup din bara cu
instrumente a filei Servers (fig. 7.10). Se va afişa
fereastra de dialog a asistentului Hotspot Setup
de instalare a Hotspot, în câmpul HotSpot
Interface a căreia este necesar de selectat
interfaţa, pe care se va instala Hotspot (în
exemplul din figura 7.11 – ether1). De reţinut că,
după încheierea instalării Hotspot, toate Fig. 7.11. Hotspot Setup.
253
accesările prin această interfaţă vor necesita autentificare.
Ulterior, se apasă butonul Next, solicitându-se adresa IP locală a reţelei
Hotspot (implicit este propusă adresa IP a interfeţei ether1, deja definită)
Local Address of Network – 192.168.21.254/24 şi apoi Next. În acelaşi mod se
specifică/selectează/acceptă consecutiv şi următorii parametri:
 fondul de adrese IP al reţelei de folosit de către serverul DHCP al Hotspot
– Address Pool of Network – 192.168.21.1-192.168.21.253;
 selectarea certificatului SSL de utilizat pentru logare – Select Certificate –
none. Nu a fost selectat nici un certificat. Logarea va fi fără cifrare;
 adresa IP a serverului SMTP – IP Address of SMTP Server – 0.0.0.0. A fost
păstrată valoarea predefinită, ceea ce semnifică refuzul de a configura un
server SMTP implicit. Dacă se configurează un asemenea server, atunci
toate mesajele de i-poştă din reţeaua Hotspot vor fi redirecţionate către
acest server;
 adresele IP ale serverelor DNS – DNS Servers – 192.168.1.1, 8.8.8.8;
 numele DNS al serverului Hotspot – DNS Name – hotspot1.net. Se
recomandă folosirea unui nume în format DNS, pentru a nu apărea
probleme în lucrul exploratoarelor Web. Totuşi, acesta nu va fi un nume
DNS public valid;
 numele de utilizator – Name of Local HotSpot User – 20_bit şi parola –
Password for the User – xxxxxxx, pentru autentificare la accesarea
Hotspot de către utilizator. Astfel, este creat
contul utilizatorului 20_bit;
 ultima casetă de dialog a asistentului
Hotspot Setup conţine mesajul de instalare
reuşită a Hotspot (fig. 7.12) şi, dacă se
doreşte finalizarea instalării, se apasă Fig. 7.12. Finalizarea
butonul OK. instalării Hotspot.
Astfel, serverul Hotspot a fost instalat pe interfaţa ether1. Caracteristicile
de bază ale fiecărui server Hotspot instalat pe ruter se regăsesc în
înregistrarea respectivă din fila Servers a ferestrei Hotspot, inclusiv (fig. 7.13):
numele (Name), interfaţa (Interface), profilul (Profile), adresa IP a numelui DNS
(IP of DNS Name) ş.a.
Fig. 7.13. Înregistrarea privind serverul hotspot1 instalat pe interfaţa ether1.
254
Când utilizatorul 20_bit va încerca să acceseze vreun sit Web, el va fi invitat
să specifice, mai întâi, în pagina de logare a hotspot1, informaţiile de
autentificare: numele de utilizator şi parola respectivă.
7.3.3. Crearea profilurilor utilizatorilor
Facilitează considerabil gestiunea ansamblului de utilizatori Hotspot,
folosirea profilurilor de utilizatori. Asemenea profiluri permit gruparea
utilizatorilor cu atribute comune, inclusiv: limite de rate; fonduri de adrese;
marcaje de pachete ş.a. Aceste atribute sunt luate în consideraţie la crearea
conturilor şi alte aspecte de gestiune a utilizatorilor. De exemplu, limitele de
rate se pot folosi la diferenţierea plăţilor pentru servicii. Astfel, este oportun
de creat, mai întâi, profilurile de utilizatori şi
doar apoi conturile pentru ei.
Pentru crearea unui profil de utilizatori, se
activează /IP/Hotspot/User profiles, +. Se va
afişa fereastra New Hotspot User Profile cu trei
file (fig. 7.14): General, Advertise şi Scripts. Cele
mai multe atribute se configurează în fila
General, inclusiv: numele profilului – Name;
fondul de adrese DHCP – Address Pool;
numărul de utilizatori ai profilului – Shared
Users; rata limită la recepţie/transmisie – Rate
Limit [rx/tx]; lista de adrese – Address List;
filtrul de intrare – Incoming Filter; filtrul de
ieşire – Outgoing Filter; marcajul pachetelor de
intrare – Incoming Packet Mark; marcajul
pachetelor de ieşire – Outgoing Packet Mark
ş.a. Bineînţeles, se pot configura doar o parte
din aceste atribute. În exemplul din figura 7.14
acestea sunt Name – uprof1 şi Rate Limit –
1M/1M. Fig. 7.14. Setarea unui profil.
7.3.4. Crearea profilurilor serverelor
RouterOS poate gestiona mai multe servere Hotspot, dar nu mai mult de
unul pe interfaţă. Implicit, fiecare server dispune de anumite
proprietăţi/atribute, înglobate în profilul predefinit de server Hotspot; acestea
pot fi, la necesitate, modificate. Pot fi create, de asemenea, şi profiluri noi de
servere. Un asemenea profil, dacă nu este folosit cel implicit (default), se
creează cu fiecare instalare a unui server Hotspot pe o interfaţă, cum a avut
loc la instalarea celui din exemplul descris în s. 7.3.2.
Administrarea serverelor Hotspot se efectuează în cadrul filelor Servers şi
Server Profiles ale ferestrei Hotspot. Fila Servers serveşte pentru instalarea şi
255
vizualizarea parametrilor de bază ai serverelor (vezi s. 7.3.2), iar fila Server
Profiles – pentru instalarea şi vizualizarea parametrilor de bază ai profilurilor
de servere Hotspot folosiţi în cadrul ruterului.
Pentru crearea unui profil de server Hotspot, se acţionează
/IP/Hotspot/Server Profiles, +. Se va afişa fereastra New Hotspot Server
Profile cu trei file: General, Login şi RADIUS. În fila General se
specifică/selectează aşa parametri ca: numele profilului – Name; adresa
serverului – Hotspot Address; numele DNS – DNS Name; ratele limită – Rate
Limit [rx/tx] ş.a. La fel, în fila Login pot
configurate aşa atribute ca (fig. 7.15):
modalitatea de conectare (MAC, Cookie,
HTTP CHAP, HTTPS, HTTP PAP şi Trial, vezi
s. 7.3.1), certificatul SSL de conectare;
durata intervalului de încercare a serviciilor
– Trial Uptime Limit; periodicitatea
resetării intervalului de încercare a
serviciilor – Trial Uptime Reset ş.a.
Caracteristicile de bază ale fiecărui
profil de servere Hotspot, configurat pe
ruter, se regăsesc în înregistrarea
respectivă din fila Server Profiles a ferestrei
Hotspot, inclusiv (fig. 7.16): numele
(Name), numele DNS (DNS Name), Fig. 7.15. Setarea profilului serverului.
directorul HTML (HTML Directory), ratele
limită (Rate Limit [rx/tx]), durata intervalului de încercare a serviciilor (Trial
Uptime Limit), periodicitatea resetării intervalului de încercare a serviciilor
(Trial Uptime Reset) ş.a.
Fig. 7.16. Înregistrările privind profilurile de servere Hotspot.
7.3.5. Crearea conturilor utilizatorilor

La instalarea Hotspot (vezi s. 7.3.2), a fost creat contul unui singur utilizator
(20_bit). Pentru a crea conturi şi altor utilizatori Hotspot, de exemplu celui
user1, se acţionează /IP/Hotspot/Users, +/General, Name – user1, Password
256
– parola (fig. 7.17). Dacă este necesar, se
setează şi alţi parametri, de exemplu profilul
(Profile).
Conturile utilizatorilor pot fi vizualizate în
fila Users a ferestrei Hotspot (fig. 7.18).
Fiecare utilizator este reprezentat printr-o
înregistrare aparte, ce conţine aşa informaţii
ca: numele serverului Hotspot (Server),
numele utilizatorului (Name), adresa IP a
staţiei utilizatorului (Address), profilul
(Profile) ş.a. Fig. 7.17. Crearea unui nou cont.
Sarcină practică 7.3. Configurarea
sistemelor Hotspot. Se cere de creat un sistem Hotspot cu numele hotspot1
pe interfaţa ether1 cu parametrii: un profil de utilizatori cu numele student,
limitele ratelor de descărcare/încărcare de 1M/1M şi numărul de utilizatori
(Shared Users) 15; un cont de utilizator cu numele student, parola student şi
profilul student. În acest scop:
1. De verificat dacă interfeţei ether1 îi
este atribuită o adresă IP. Dacă nu,
atunci de atribuit adresa
192.168.100+x.254.
2. De instalat Hotspot cu numele
hotspot1 pe interfaţa ether1, Fig. 7.18. Conturile utilizatorilor Hotspot.
acţionând
/IP/Hotspot/Servers/Hotspot Setup/Hotspot Setup, Hotspot Interface –
ether1, Next/în continuare, de fiecare dată, se acceptă valorile implicite şi
se apasă butonul Next sau conform exemplului din s. 7.3.2, cu excepţia:
Select Certificate – none, DNS Name – hotspot1.net, Name of Local
HotSpot User – admin1, Password for the User – admin1/OK.
3. De creat profilul student, acţionând /IP/Hotspot/User Profiles, +/New
Hotspot User Profile/General, Name – student, Shared Users – 15, Rate
Limit [rx/tx] – 1M/1M /OK.
4. De creat contul de utilizator student, acţionând /IP/Hotspot/Users, +/New
Hotspot User/General, Server – hotspot1, Name – student, Password –
student, Profile – student/OK.
5. De vizualizat înregistrările privind configurările efectuate în filele Servers,
Server Profiles, Users, User Profiles şi Hosts.
6. De reconectat cablul calculator-ruter de la interfaţa ether2 la cea ether1.
Ruterul deja nu va fi accesibil prin WinBox.
7. De încercat accesarea unei pagini Web din Internet. Exploratorul Web va
afişa pagina de logare a Hotspot din figura 7.19.
257
8. De specificat informaţiile de autentificare
în pagina de logare a Hotspot şi de apăsat
butonul OK. Va urma afişarea paginii Web
solicitate la pasul 7.
9. De consultat statutul utilizatorului student,
accesând pagina Web http://hotspot1.net.
Se va afişa pagina Web, care conţine
informaţii despre utilizatorul student,
inclusiv resursele folosite, şi, de
asemenea, butonul log off de deconectare
de la Hotspot.
10. De apăsat butonul log off. Folosirea
resurselor prin Hotspot va înceta, iar
butonul log off va fi înlocuit cu cel log in, Fig. 7.19. Logarea Hotspot.
păstrând informaţia de stare finală (fig.
7.20). Apăsând butonul log in, iarăşi se va intra în Hotspot, va deveni
accesibil Internet-ul, iar butonul log in va fi înlocuit cu cel log off.
11. Pentru dezactivarea Hotspot, calculatorul se va conecta la ruter din nou la
interfaţa ether2. Se va accesa RouterOS prin Winbox şi se va încerca
accesarea Internet. Accesarea trebuie să reuşească.
7.3.6. Configurarea perimetrelor de acces
Se poate întâmpla ca pentru unele servicii să nu fie necesară autorizarea.
Ca exemplu ar putea servi accesul la informaţia de prezentare a companiei,
inclusiv a produselor şi serviciilor prestate de aceasta. Astfel, în caz general,
este oportun ca pentru unele servicii să fie, iar pentru altele să nu fie necesară
autorizarea Hotspot. În acest scop serveşte
sistemul Walled Garden (Perimetru de acces),
care tine cont de serviciile oferite fără
autentificare Hotspot. Fiecare asemenea
serviciu este specificat printr-o înregistrare
aparte în fila Walled Garden a ferestrei
Hotspot.
Când un utilizator, încă ne conectat prin
Hotspot, se adresează la un serviciu oferit
Fig. 7.20. Pagina log in.
prin Walled Garden, sistemul redirecţionează
cererea către destinaţia iniţială şi aceasta se
deserveşte în mod obişnuit. Dacă însă utilizatorul se adresează la un serviciu,
ce nu se oferă prin Walled Garden, atunci sistemul redirecţionează cererea
către pagina de autentificare Hotspot. Totodată, dacă un utilizator, deja
conectat prin Hotspot, se adresează la un serviciu oferit prin Walled Garden,
atunci acesta se deserveşte în mod transparent pentru utilizator.
258
În funcţie de resursele solicitate şi modalităţile de conectare, RouterOS
oferă două instrumente Walled Garden:
 Walled Garden standard – pentru servicii HTTP şi HTTPS;
 Walled Garden IP – pentru celelalte servicii, inclusiv: Telnet, SSH, WinBox,
etc.
Exemplul 7.2. Fie este necesar ca accesul Hotspot de la staţia cu adresa IP
192.168.20.1 la serverul www.ase.md să fie fără autentificare. În acest scop se
defineşte regula Walled Garden corespunzătoare, acţionând
/IP/Hotspot/Walled Garden, +/New Walled Garden Entry, Action – allow, Src.
Address – 192.168.20.1, Dst. Host – www.ase.md/OK (fig. 7.21).
7.3.7. Sistemul de adrese IP obligatorii – IP binding
După cum a fost deja menţionat
în s. 7.3.1, RouterOS oferă un sistem
de adrese IP obligatorii (IP Bindings
system), care permite: configurarea
translatării statice NAT una-la-una;
ocolirea de către anumiţi utilizatori
Hotspot a necesităţii de autentificare;
blocarea accesului, de la sistemul
Hotspot, la anumite staţii şi Fig. 7.21. Accesul liber la www.ase.md.
subreţele. Translatarea NAT una-la-
una are loc pe ruter, în mod transparent pentru client – ultimul nu resimte
faptul translatării adresei.
Există trei tipuri de acţiuni de IP obligatorii:
 regular – realizează NAT una-la-una, translatând adresa IP originală a
clientului în adresa IP nouă a acestuia;
 bypassed – realizează translatarea NAT una-la-una, ocolind, totodată,
necesitatea de autentificare;
 blocked – translatarea nu se realizează, iar accesul, de la sistemul
Hotspot, este blocat, pachetele respective fiind aruncate;
Ocolirea autentificării Hotspot este oportună, de exemplu, în cazurile unor
utilizatori speciali (administratori, stăpâni, etc.), accesului de la telefoane IP,
imprimante ş.a.
Exemplul 7.3. Fie este necesar ca
accesul Hotspot de la staţia cu adresa IP
192.168.20.1 să fie fără autentificare. În
acest scop se defineşte regula IP Bindings
corespunzătoare, acţionând /IP/Hotspot/
IP Bindings, +/New Hotspot IP Binding,
Address – 192.168.20.1, Type – bypassed/
Fig. 7.22. Ocolirea autentificării.
259
OK (fig. 7.22).
Sarcină practică 7.4. Configurarea accesului Hotspot fără autentificare. În
continuarea sarcinii 7.3, se cere de asigurat accesul fără autentificare: (a)
tuturor utilizatorilor Hotspot cu numele hotspot1 – la serverul www.ase.md;
(b) de la calculatorul cu adresa IP 192.168.1x.1 – la toate resursele Web
publice.
Notă. Pentru îndeplinirea sarcinii (a), se va folosi instrumentul Walled Garden (vezi
s. 7.3.6), dar în câmpul Src. Address al ferestrei New Walled Garden Entry (fig. 7.21) nu
se va specifica nimic, ceea ce ar însemna „toţi utilizatorii”. În ce priveşte sarcina (b), se
va folosi sistemul IP Bindings (vezi exemplul 7.3 din această secţiune).
7.4. Folosirea proxy

7.4.1. Esenţă proxy
Esenţa serverelor proxy (mandatar) este descrisă în s. 5.1.4. Acestea au
funcţii de intermediar al cererilor aplicaţiilor client în căutare de resurse de la
alte servere. Un asemenea server serveşte ca o poartă, de la o reţea la alta,
pentru anumite aplicaţii de reţea, în beneficiul utilizatorilor. El poate fi plasat
în diferite puncte între utilizatori şi serverele destinaţie din Internet.
Serverul proxy depozitează local obiectele Internet accesate (pagini Web,
documente FTP, etc.), iar, la solicitări repetate a acestora, le redă din depozitul
local, la viteza reţelei locale, de obicei mai mare. Aceasta accelerează
accesarea obiectelor Internet şi previne descărcarea multiplă a aceluiaşi
conţinut.
Aplicaţia client se conectează la un server proxy, solicitând anumite
servicii, de exemplu un fişier, o conexiune sau o pagină Web, de pe un alt
server. Serverul proxy analizează cererea şi, dacă este în stare, o deserveşte de
unul singur, iar, dacă nu, o redirecţionează către serverul solicitat de aplicaţia
client. Totodată, serverele proxy îndeplinesc şi alte funcţii (vezi s. 5.1.4),
inclusiv de i-bariere. Există şi cazuri când serverele proxy se folosesc doar ca i-
bariere, fără depozitarea locală de obiecte Internet.
RouterOS permite configurarea şi folosirea de servere proxy cu
următoarele funcţii [1]:
 proxy HTTP ordinar – utilizatorul de unul singur configurează un
asemenea server, incluzând funcţiile necesare;
 proxy transparent – utilizatorul nu se implică şi poate nici să nu cunoască
despre serverul proxy activat;
 listă de acces (Access) după sursă, destinaţie, un subşir al URL sau
metoda de solicitare (i-barieră HTTP);
 listă de acces cache (Cache), specificând ce obiecte de depozitat şi care
nu;
260
 listă de acces direct (Direct), specificând ce resurse de accesat direct şi
care – printr-un alt server proxy;
 facilitatea de evidenţă a conectărilor (Logging) – obţinerea şi
înregistrarea informaţiilor despre operarea serverului proxy;
 suportul de servere proxy părinte (Parent Proxy) – permite specificarea
unui alt server proxy.
Setarea unor asemenea funcţionalităţi se efectuează în cadrul ferestrei
Web Proxy Settings, care se afişează la acţionarea IP/Web Proxy şi este
descrisă, în linii mari, în ss. 7.4.2-7.4.5.
7.4.2. Setarea proxy HTTP ordinar
Serverul proxy HTTP ordinar se activează, acţionând /IP/Web Proxy/
General, Enabled – bifare. Configurările proxy pot fi păstrate cele implicite
sau, la necesitate, pot fi modificate.
De menţionat că starea activată
(Enabled) a proxy nu este implicit
activată. De asemenea, funcţia de
depozitare a obiectelor Internet
accesate tot nu este implicit activată
(Max. Cache Size – none) şi ar fi fost
cazul, de obicei, de activat, selectând
Max. Cache Size – unlimited.
Totodată, proxy ordinar necesită
configurarea respectivă a
exploratorului Web al clientului; de
obicei este suficientă specificarea
adresei IP a serverului proxy şi a
porturilor (pentru http se foloseşte, de
obicei, cel 8080). Alţi parametri,
posibil de configurat, pot fi vizualizaţi
în figura 7.23, inclusiv: Fig. 7.23. Setarea proxy ordinar.
 Src. Address – adresa folosită pentru conectarea la situl Web sau proxy
părinte. Dacă aceasta este 0.0.0.0 (valoarea implicită), atunci se va folosi
adresa IP apropiată din tabelul de rutare;
 Port – portul TCP ce va fi folosit de serverul proxy;
 Parent Proxy – adresa IP a unui alt proxy HTTP, către care se vor
redirecţiona toate cererile utilizatorilor. Dacă aceasta este 0.0.0.0
(valoarea implicită), atunci proxy părinte nu se va folosi;
 Max Client Connections – numărul maximal de conexiuni acceptate de la
clienţi; toate celelalte conexiuni vor fi respinse;
 dacă nu se bifează opţiunea Cache On Disc, informaţiile se vor depozita în
memoria RAM a ruterului. Discul, ce va fi folosit pentru depozitarea
261
informaţiilor, dacă este bifată opţiunea Cache On Disc, se defineşte în
sistemul Store (stocare) – vezi s. 7.5;
 opţiunea Cache hit DSCP permite identificarea datelor accesate din
sistemul de depozitare (nu din Internet), la deservirea cererilor
utilizatorilor.
Fila Status afişează datele statistice privind operarea proxy Web, inclusiv:
durata operării (Uptime); numărul total de cereri deservite (Requests); hits –
numărul de cereri ce s-au potrivit regulilor.
7.4.3. Setarea proxy transparent
În cazul folosirii serverului proxy ordinar (vezi s. 7.4.2), este necesar de
configurat exploratorul Web al clientului. Nu este însă necesar acest lucru, în
cazul folosirii unui server proxy transparent – exploratorul Web va funcţiona
fără vreo configurare specială din partea utilizatorului. Serverul proxy
transparent singur va prelua toate cererile HTTP şi le va redirecţiona către
serviciul local proxy.
Totodată, setarea unui server proxy transparent la ruter necesită,
suplimentar la configurările pentru proxy HTTP ordinar (vezi s. 7.4.2), crearea
unei reguli NAT destinaţie redirect de redirecţionare a traficului HTTP către
proxy, în cadrul ruterului. În acest scop se acţionează /IP/Firewall/NAT, +/
New NAT Rule/General, Chain – dstnat, Protocol – 6(tcp), Dst, Port –
80/Action, Action – redirect, To Ports – 8080 (fig. 7.24).
a) b)
Fig. 7.24. Setarea regulii NAT destinaţie redirect.
Astfel, serverul proxy va prelua pentru deservire toate cererile utilizatorilor
către portul 80.
Serverul proxy transparent poate fi folosit atât ca unul transparent, cât şi
ca unul ordinar, în acelaşi timp. Totodată, este oportun de prevenit accesul
neautorizat la serverul proxy.
262
Exemplul 7.4. Restricţionarea accesului la serverul proxy, folosind i-
bariera. Fie se cere admiterea accesului la serverul proxy doar de la staţiile
subreţelei 192.168.20.0/24. În acest scop:
1. De creat o regulă i-barieră de filtrare, acţionând IP/Firewall/Filter Rules, +/
fila General, Chain – input, Src. Address – 192.168.20.0/24, Protocol –
6(tcp), Dst. Port – 8080/fila Action, Action – accept/OK (fig. 7.25).
Fig. 7.25. Restricţionarea accesului la proxy.

2. De creat o regulă i-barieră de aruncare pentru orice alt trafic către proxy,
acţionând /IP/Firewall/Filter Rules, +/fila General, Chain – input, Protocol
– 6(tcp), Dst. Port – 8080/fila Action, Action – drop/OK.
Astfel, i-bariera va permite accesul la serverul proxy transparent doar de la
staţiile reţelei 192.168.20.0/24 şi va bloca tot traficul de la alte surse.
7.4.4. Setarea i-barierelor HTTP în baza proxy
Lista de acces este o listă de adrese IP, porturi şi protocoale care pot folosi
sistemul de depozitare al serverului Web Proxy. Aceasta serveşte pentru
eficientizarea şi securizarea funcţionării sistemului Web Proxy.
Funcţionalităţile proxy listă de acces (vezi s. 7.4.1) se implementează în
acelaşi mod ca şi regulile de i–bariere. Listele de acces se procesează de
asemenea de sus în jos. Prima regulă de potrivire specifică decizia privind
acţiunea asupra conexiunii. Conexiunile pot fi potrivite după: adresa sursă,
adresa destinație, portul destinație, un subşir al URL sau metoda solicitării.
Dacă nici unul din aceşti parametri nu este specificat, atunci se consideră că
orice conexiune se potriveşte regulii în cauză.
Când conexiunea se potriveşte unei reguli, atunci atributul Action al regulii
specifică dacă conexiunea să fie sau nu permisă. Dacă conexiunea nu se
potriveşte nici unei reguli, atunci ea va fi permisă.
Foarte importantă este reglementarea accesului la sistemul de depozitare
a obiectelor Internet al serverului proxy. În cazul accesului liber, acesta poate
fi folosit de hackeri, încărcând suplimentar capacitatea de transfer date prin
ruter. Pentru securizarea accesului la serverul proxy, acesta poate fi permis
doar de la staţiile subreţelei deservite de server.
263
Exemplul 7.5. Restricţionarea accesului la
serverul proxy de la anumite staţii. Fie se cere
admiterea accesului la serverul proxy, instalat
conform exemplului din s. 7.4.3, doar de la staţiile
subreţelei 192.168.20.0/24. În acest scop, se
acţionează /IP/Web Proxy/Access/Web Proxy
Access, +/New Web Proxy Rule, Src. Address –
192.168.21.0/24, Action – allow (fig. 7.26).
O parte din alte posibilităţi de configurare a i-
barierelor HTTP în baza proxy Web sunt descrise
în exemplele 7.6-7.10.
Exemplul 7.6. Blocarea accesului la anumite Fig.7.26. Admiterea accesului
situri Web. Fie se cere de blocat accesul, prin la proxy doar din reţeaua
ruter, la situl Web www.facebook.com, folosind 192.168.20.0/24.
Web Proxy. În acest scop se acţionează /IP/Web Proxy/Access/Web Proxy
Access, +/New Web Proxy Rule, Dst. Host – www.facebook.com, Action – deny
(fig. 7.27a).
a) prin ruter b) din reţeaua 192.168.12.0/24

Fig. 7.27. Blocarea accesului la situl www.facebook.com.
Exemplul 7.7. Blocarea accesului de la anumite staţii la un sit Web dat. Fie
se cere de blocat accesul, de la staţiile reţelei 192.168.21.0/24, la situl Web
www.facebook.com, folosind Web Proxy. În acest scop se acţionează /IP/Web
Proxy/Access/Web Proxy Access, +/New Web Proxy Rule, Src. Address –
192.168.21.0/24, Dst. Host – www.facebook.com, Action – deny (fig. 7.27b).
Exemplul 7.8. Blocarea accesului de la anumite staţii la situri Web ce
conţin un sub-şir dat de caractere în URL. Fie se cere de blocat accesul, de la
staţiile reţelei 192.168.21.0/24, la siturile Web ce conţin şirul de caractere
„game” în URL, folosind Web Proxy. În acest scop se acţionează /IP/Web
Proxy/Access/Web Proxy Access, +/New Web Proxy Rule, Src. Address –
192.168.21.0/24, Dst. Host – :game, Action – deny (fig. 7.28).
264
Exemplul 7.9. Blocarea descărcării, pentru anumite staţii, a fişierelor cu o
anumită extensie. Fie se cere de blocat descărcarea, pentru staţiile reţelei
192.168.21.0/24, a fişierelor cu extensia .exe, folosind Web Proxy. În acest
scop se acţionează /IP/Web Proxy/Access/Web Proxy Access, +/New Web
Proxy Rule, Src. Address – 192.168.21.0/24, Path – *.exe, Action – deny (fig.
7.28).
Fig. 7.28. Blocarea accesului la Fig. 7.29. Blocarea descărcării

situri Web după sub-şir URL. de fişiere după extensie.
Exemplul 7.10. Redirecţionarea accesului de la un sit Web la altul. Fie se
cere de redirecţionat accesul utilizatorilor de la situl www.games.com la cel
www.ase.md. În acest scop se acţionează /IP/Web Proxy/Access/Web Proxy
Access, +/New Web Proxy Rule, Dst. Host – www.games.com, Action – deny,
Redirect To – www.ase.md (fig. 7.29).
Există şi alte posibilităţi de configurare a i-barierelor cu folosirea listei de
acces Web Proxy [1].
Sarcină practică 7.5. Configurarea proxy. Se cere de configurat: (a) un
proxy HTTP ordinar; (b) proxy de la sarcina (a) de complementat până la unul
transparent; (c) de permis accesul la proxy doar din reţeaua 192.168.x.0/24,
folosind proxy Web; (d) de blocat accesul, din reţeaua 192.168.x.0/24, la situl
Web www.games.com, folosind proxy Web. În acest scop:
1. De setat un proxy HTTP ordinar conform exemplului din s. 7.4.2.
2. De configurat exploratorul Web la calculator, specificând adresa IP a
serverului proxy şi numărul de port 8080.
3. De încercat accesarea unei pagini Web din Internet. Accesarea ar trebui să
reuşească.
4. De creat o regulă Web Proxy pentru admiterea accesului la proxy doar din
reţeaua 192.168.x.0/24, conform exemplului 7.5 din această secţiune.
5. De complementat serverul proxy HTTP ordinar de la pasul 1 până la unul
transparent conform exemplului din s. 7.4.3.
265
6. De eliminat configurările exploratorului Web la calculator, efectuate la pasul 2.
7. De încercat accesarea unei pagini Web din Internet, neaccesate încă în
cadrul sarcinii practice 7.5. Accesarea ar trebui să reuşească.
8. De blocat accesul, din reţeaua 192.168.x.0/24, la situl Web
www.games.com conform exemplului 7.7 din această secţiune.
9. De încercat accesarea sitului Web www.games.com. Accesarea ar trebui să
eşueze.
7.4.5. Evidenţa paginilor Web
Serverul proxy poate înregistra anumite informaţii despre paginile Web
accesate de utilizatori (Web-pages logging) – tematica (Topics) web-proxy.
Înregistrarea poate fi efectuată (Action) în memoria RAM a ruterului
(memory), pe disc (disk) sau pe unităţi de memorie externe (remote). Locul de
înregistrare se alege, ţinând cont de volumul preconizat de date şi resursele
disponibile. De obicei se alege opţiunea remote.
Exemplul 7.11. Setarea evidenţei paginilor Web în memoria RAM. Fie se
cere înregistrarea informaţiilor despre
paginile Web în memoria RAM a ruterului.
În acest scop, se acţionează /Systems/
Logging/Rules, +/New Log Rule, Topics –
web-proxy, Topics – ! debug, Action –
memory/OK (fig. 7.30). Opţiunea „!
debug” va bloca înregistrarea informaţiilor
de depanare.
Înregistrările efectuate pot fi
vizualizate în fereastra Log, care se Fig. 7.30. Evidenţa paginilor Web.
afişează la acţionarea /Log.
Sarcină practică 7.6. Setarea evidenţei paginilor Web. În continuarea
sarcinii 7.5, se cere de creat regula de evidenţă a paginilor Web accesate de
utilizatori, folosind Web Proxy, şi de verificat înregistrarea unor pagini Web
concrete. În acest scop:
1. De creat regula de evidenţă a paginilor Web accesate de utilizatori, conform
exemplului 7.11 din această secţiune.
2. De accesat câteva pagini Web din Internet.
3. De verificat prezenţa înregistărilor privind paginile Web accesate recent în
fereastra Log.
După cum a fost menţionat mai sus în această secţiune, înregistrarea
informaţiilor despre paginile Web este oportun, de obicei, de efectuat pe un
calculator.
Exemplul 7.12. Setarea evidenţei paginilor Web pe un calculator. Fie se
cere înregistrarea informaţiilor despre paginile Web în memoria calculatorului
266
192.168.20.51, care foloseşte aplicaţia syslog cu numele bitsyslog. În acest
scop:
1. Se creează o nouă acţiune de evidenţă, acţionând /System/Logging/
Actions, +/New Log Action, Name – bitsyslog, Type – remote, Remote
Address – 192.168.20.51/OK (fig. 7.31a).
a) b)
Fig. 7.31. Evidenţa paginilor Web pe un calculator.
2. Se creează o nouă regulă de evidenţă, acţionând /System/Logging/Rules, +/
New Log Rule, Topics – web-proxy, Action – bitsyslog/OK (fig. 7.31b).
De menţionat că aplicaţia bitsyslog, instalată pe calculatorul
192.168.20.51, trebuie să fie în stare să recepţioneze mesaje syslog conform
RFC 5424. Aceasta poate fi Kiwi Syslog Server pentru Windows, ce poate fi
descărcată fără plată de la www.solarwinds.com/products/freetools/free-kiwi-
syslog-server.aspx.
7.5. Stocarea de date

Echipamentele de reţea MikroTik dispun, de obicei, de puţină memorie.
Totodată, RouterOS, începând cu versiunea v3.15, conţine sistemul Stores de
gestiune a folosirii memoriei ruterelor bazate pe sisteme x86 şi, de asemenea,
a unităţilor de memorie externe (IDE, SATA, USB, CF, MicroSD) adiţionale,
cuplate la rutere MikroTik.
Sistemul Stores poate fi folosit la stocarea de date pentru Web Proxy, User
Manager şi Dude. El este îndeosebi util dispozitivelor RouterBOARD cu sloturi
SD/CF. Stores permite folosirea unui număr arbitrar de unităţi de memorie
externă.
Pentru accesarea Stores, se acţionează /System/Stores. Se va afişa
fereastra Store List cu două file: Stores şi Disks. Fila Disks conţine câte o
înregistrare pentru fiecare din unităţile de memorie disponibile. Fiecare
asemenea înregistrare include numele unităţii de memorie (Name),
capacitatea totală de memorie (Total Space), capacitatea de memorie liberă
(Free Space) şi starea unităţii de disc (Status). Starea ready semnifică faptul că
unitatea de memorie este funcţională, iar cea unknown – că unitatea de
memorie trebuie formatată. Formatarea unităţii de memorie poate fi
267
efectuată în cadrul acestei file, selectând înregistrarea respectivă şi, ulterior,
apăsând butonul Format Drive.
Fila Stores (fig. 7.32) conţine câte o înregistrare pentru fiecare din
depozitele de date (partiţiile – stores), create în cadrul unităţilor fizice de
memorie. Pentru crearea unui depozit de date, de exemplu PROXY, pentru
Proxy Web, pe discul usb1, se acţionează /System/Stores/Stores List/Stores,
+/New Store, Name – Proxy, Type – web-proxy, Disk – usb1/OK.
Figura 7.32. Păstrarea Cache pe unități externe.
7.6. Unele instrumente Router OS

RouterOS dispune de o varietate relativ mare de instrumente pentru
evidenţa, monitorizarea, controlul, diagnosticul şi eficientizarea valorificării
resurselor de reţea. La acestea se referă: BTest Server, Bandwidth Test, Email,
Flood Ping, Graphing, IP Scan, MAC Server, Netwatch, Packet Shiffer, Ping, Ping
Speed, Profile, SMS, Telnet, Torch, Traceroute, Traffic Generator şi Traffic
Monitor.
Instrumentele Telnet, Torch, BTest Server, Bandwidth Test, Graphing sunt
folosite/descrise, în linii mari, în ss. 4.1.6.2, 6.6. În această secţiune sunt
descrise utilitele Ping, Traceroute, Email, Netwatch şi Profile.
7.6.1. Utilita Email
Utilita Email realizează transmiterea de mesaje de i-poştă de la ruter, în
baza unor evenimente în cadrul RouterOS. Poate fi folosită pentru
transmiterea periodică administratorului reţelei a unor copii de rezervă ale
268
configurărilor RouterOS şi a unor fişiere export. Ea foloseşte autentificarea şi
cifrarea TLS.
Funcţia de i-poştă, realizată de utilita Email, este una configurabilă şi poate
fi folosită de alte funcţii în cadrul RouterOS. Astfel, poate fi scris un script
pentru crearea periodică a unui fişier backup. Asemenea fişiere pot fi
transmise de utilita Email la o adresă de poştă specificată.
Scripturile pot fi scrise în fereastra New Script ce se va afişa la acţionarea
/System/Scripts/Script List/Scripts, +/. Detalii pot
fi regăsite la adresa
wiki.mikrotik.com/wiki/Manual:Scripting.
Pentru a configura funcţia Email, se acţionează
/Tools/Email/Email Settings, Server –
adresă_IP_server.
Exemplul 7.13. Configurarea funcţiei Email.
Fie se cere configurarea funcţiei Email pentru
transmiterea i-poştei către utilizatorul de i/poştă
cu numele bolun şi adresa bolun@ase.md prin
serverul de poştă 172.20.0.3. În acest scop:
1. Se configurează funcţia Email, acţionând /Tools/
Email/Email Settings, Server – 172.20.0.3,
From – r20_ion, User – bolun/Password -
*******/OK (fig. 7.33, sus).
2. Se trimite un mesaj de testare, acţionând
/Tools/Email/Email Settings/Send Email/Send
Email, To – bolun@ase.md, From – r20_ion
@bit.md, Subject – test Email, Body – Test
Email RouterOS, Send Email (fig. 7.33, jos).
În imaginea de jos a figurii 7.33, câmpurile
Address, Port, User şi Password le repetă pe cele
Server, Port, User şi Password din imaginea de sus
a acestei figurii, de aceea ele pot să nu fie
completate. Fig. 7.33. Setarea Email.
7.6.2. Utilita Ping

Utilita Ping serveşte pentru testarea accesibilităţii interfeţelor de reţea în
reţele IP şi, de asemenea, pentru măsurarea duratei dus-întors (Time) a
mesajelor între două interfeţe de reţea. Ea operează prin trimiterea de mesaje
(pachete) ICMP cerere-ecou (echo-request), denumite şi ping, la interfaţa ţintă
şi aşteptarea răspunsului-ecou ICMP, denumit şi pong, măsurând, totodată,
durata de la transmisie până la recepţie. Durata în cauză nu include timpul
necesar pentru stabilirea conexiunii, ea caracterizează durata în cauză pentru
o conexiune deja stabilită a unei sesiuni deschise. Dacă mesajul pong nu a sosit
269
până la sfârșitul unui interval anumit (interval), se consideră că timpul de
testare a expirat (timeout).
Un alt parametru semnificativ raportat este TTL (Time to Live – timpul de
viaţă). Iniţial acestuia i se atribuie o anumită valoare, care, ulterior, se
decrementează cu o unitate la fiecare din ruterele de tranzit către destinaţie.
Dacă pachetul sosit la un ruter are valoarea TTL egală cu 1, atunci acesta este
eliminat din reţea. Pachetul va ajunge la destinaţie, doar dacă valoarea TTL
este mai mare, decât numărul de rutere de tranzit între sursă şi destinaţie.
Funcţia Ping se aplică prin lansarea instrucţiunii ping din linia de comandă a
Terminal sau acţionând /Tools/Ping. Formatul comenzii la prompterul
Terminal este
> ping [address] [properties]
unde address este adresa IP sau cea MAC a interfeţei destinaţie, iar properties
include:
 interval – intervalul de timp de aşteptare a răspunsului la mesajul ping
(valoarea implicită: 1 s);
 size – dimensiunea pachetului de folosit în octeţi (valoarea implicită: 64);
 ttl – valoarea iniţială a TTL (valoarea implicită: ) ş.a.
De menţionat că folosirea adresei MAC pentru ping poate fi doar către
dispozitive, la care este configurat serverul ping MAC.
Exemple:
În ultimul din aceste trei exemple, nu este acces la staţia cu adresa

81.189.68.5, deoarece starea (STATUS) este timeout.
La acţionarea /Tools/Ping, se afişează fereastra Ping cu două file, General
şi Advanced (fig. 7.34). Adresa staţiei (interfeţei) destinaţie se specifică în
270
câmpul Ping To al filei General. Ulterior se apasă butonul Start. Testarea va
continua până la apăsarea butonului Stop.
În fila Advanced pot fi specificate valorile unor aşa parametri ca:
dimensiunea pachetului (Packet Size), valoarea TTL (TTL) ş.a.
Utilita Ping este simplu de folosit şi frecvent aplicată, îndeosebi pentru
depistarea unor neconformităţi. De exemplu:
 dacă ping trece după adresa IP, dar nu trece după nume, atunci nu
lucrează sau nu este configurat DNS;
 dacă ping trece până la furnizorul de
servicii Internet, dar nu trece mai
departe, atunci problema este la
furnizor;
 dacă ping de la ruter către careva
adresă Internet trece, dar nu trece
de la calculator, atunci problema e în
conexiune sau configurarea legăturii
ruter-calculator.
Funcţia Ping este implementată şi în
sistemul de operare Windows şi se aplică
folosind comanda ping. Fig. 7.34. Testarea Ping.
7.6.3. Utilita Traceroute

Utilita Traceroute serveşte pentru identificarea căii parcurse de un pachet
IP de la sursă până la destinaţie. În acest scop ea foloseşte funcţia TTL a
pachetului (vezi s. 7.6.2).
Ea transmite către destinaţie o secvenţă de pachete. Primului pachet al
acestei secvenţe Traceroute îi atribuie o valoare iniţială a TTL egală cu 1, iar
fiecărui pachet următor – o valoare iniţială a TTL cu o unitate mai mare, decât
la pachetul precedent.
Primul ruter, care a recepţionat primul pachet, va răspunde cu un mesaj de
eroare, deoarece el nu va ruta pachetul mai departe către destinaţie. Al doilea
pachet al secvenţei este transmis mai departe de primul ruter, dar al doilea
ruter va răspunde la acesta cu un pachet de eroare şi tot aşa, până când
ultimul din pachetele transmise ajunge la destinaţie şi transmite un pachet
răspuns-ecou.
În baza pachetelor ICMP de răspuns, Traceroute reconstituie secvenţa de
rutere traversate de pachetele transmise către destinaţie.
271
Funcţia Traceroute se lansează,
acţionând /Tools/Traceroute, şi, în câmpul
Traceroute To al filei Traceroute ce se va
afişa, se specifică adresa IP sau numele DNS
al interfeţei destinaţie (fig. 7.35). Ulterior, se
apăsă butonul Start.
Utilita va afişa lista nodurilor parcurse de
pachetele Traceroute. Se poate observa că
până la serverul www.ase.md (81.180.68.5)
sunt cinci noduri.
Funcţia Traceroute este implementată şi
în sistemul de operare Windows. În acesta
ea se aplică, folosind comanda tracert cu
specificarea de asemenea a adresei IP sau a
numelui DNS al nodului destinaţie.
Fig. 7.35. Testarea Traceroute.
7.6.4. Utilita Netwatch
Utilita Netwatch poate monitoriza starea unor staţii ale reţelei,
transmiţând mesaje ping către acestea, şi, totodată, poate executa anumite
comenzi, dacă unele din staţii au devenit inaccesibile. Pentru fiecare din
asemenea staţii, în tabelul Netwatch este câte o înregistrare, care include
adresa IP a staţiei, intervalul transmisiei mesajului ping şi script-uri de consolă.
Principalul avantaj al NetWatch constă în capacitatea de a emite comenzi de
consolă, în funcţie de modificările de stare ale staţiilor monitorizate.
De exemplu, ruterul poate să lucreze o perioadă mare de timp fără
intervenţia administratorului. Dar, pentru aceasta, el trebuie, în unele situaţii,
să se restarteze singur; de exemplu, în cazurile că a căzut accesul la Internet,
din cauza că s-a blocat procesorul sau careva interfaţă la ruter.
Utilita se accesează, acţionând /Tools/Netwatch. Se va afişa fereastra
Netwatch, apăsând butonul + al barei cu instrumente a căreia se va afişa
fereastra New Netwatch Host cu trei file: Host, Up şi Down.
În câmpul Host al filei Host se specifică adresa IP a dispozitivului de
monitorizat, în câmpul Interval – intervalul, peste care de repetat identificarea
stării dispozitivului folosind ping, iar în câmpul Timeout – timpul în secunde,
după expirarea căruia dispozitivul se consideră căzut.
Fila Up conţine un singur câmp – On Up, în care se specifică comanda de
executat, la restabilirea (Up) stării de funcţionare a dispozitivului monitorizat.
Fila Down conţine un singur câmp – On Down, în care se specifică comanda
de executat la căderea (Down) stării de funcţionare a dispozitivului
monitorizat.
272
Exemplul 7.14. Restartarea ruterului la căderea accesului la Internet,
folosind Netwatch. Fie se cere restartarea ruterului la căderea accesului la
serverul DNS public al Google, al cărui adresă IP este 8.8.8.8. În acest scop:
1. Se specifică adresa IP monitorizată, acţionând /Tools/Netwatch, +/New
Netwatch Host/Host, Host – 8.8.8.8 (fig. 7.36a).
2. Se specifică comanda de executat la căderea (Down) accesului la adresa IP
8.8.8.8, în aceeaşi fereastră, în fila Down, On Down – /system reboot/OK
(fig. 7.36b). Aici /system reboot este comanda de restartare a ruterului.
a) specificarea adresei IP b) specificarea comenzii

Fig. 7.36. Setarea restartării ruterului.
Starea curentă a dispozitivelor monitorizate poate fi vizualizată în fereastra
Netwatch care se afişează la acţionarea /Tools/Netwatch.
7.6.5. Utilita Profile
Utilita Profile arată ce procese sunt active şi
cât ele consumă (în %) din resursele
procesorului. Aceasta permite evaluarea
comparativă a folosirii resurselor procesorului de
către diferite procese – informaţie ce poate fi
folosită în diverse scopuri, inclusiv pentru
eficientizarea valorificării funcţionalităţilor
RouterOS. În cazul unor sisteme multinucleu,
utilita permite prezentarea informaţiilor pe
nuclee aparte. Fig. 7.37. Folosirea CPU.
Funcţia Profile nu se configurează.
Pentru vizualizarea consumului de resurse de către procesele active, se
acţionează /Tools/Profile. Se va afişa fereastra Profile (Running) (fig. 7.37). Din
figura 7.37 se poate observa că procesorul este inactiv (idle) cca. 95,5% din
timp, procesul management consumă cca. 2,0%, cel wireless – 1,5%, cel
ethernet – 0,5%, iar celelalte patru procese din listă – mai puţin de 0,0%
fiecare din resursele procesorului.
7.6.6. Utilita Packet Sniffer
Utilita Packet Sniffer (/Tools/Packet Sniffer) serveşte pentru captarea şi
analiza pachetelor către, de la sau care tranzitează ruterul. Procesând
pachetele recepţionate, ea determină valorile anumitor parametri, inclusiv:
273
interfaţa de tranzit, direcţia, adresa IP destinaţie, adresa IP sursă, adresa MAC
sursă, adresa MAC destinaţie, dimensiunea antetului, dimensiunea pachetului,
numărul protocolului IP, timpul sosirii pachetului, IP TTL ş.a.
Pot fi configuraţi aşa parametri ai Packet Sniffer (/Tools/Packet Sniffer/
Packet Sniffer Settins/General, Interface – wlan1, Memory Limit – 100, File
Name – nume_fişier, Memory Limit – 1000) ca (fig. 7.38):
 Interface – interfaţa de tranzit a pachetelor (wlan1);
 Memory Limit – capacitatea memoriei tampon, alocate pentru stocarea
datelor capturate (valoarea implicită 100 KB);
 Only Headers (dacă este bifat – captarea doar a antetelor pachetelor);
 File Name – numele fişierului, în care se vor stoca informaţiile despre
pachetele capturate;
 File Limit – dimensiunea fişierului File
Name (valoarea implicită 1000 KB).
De menţionat că fereastra Packet
Sniffer Settins din fig. 7.38 a utilitei Packet
Sniffer, permite configurarea monitorizării
pachetelor ce tranzitează şi alte interfeţe,
fiecare în parte (opţiunea Interface –
nume_interfaţă) sau toate împreună
(opţiunea Interface – all).
Butoanele Start şi Stop, din fila General,
servesc pentru iniţierea şi stoparea Fig. 7.38. Setarea Packet Sniffer.
procesului de monitorizare, iar cel Packets
(fig. 7.38) – pentru vizualizarea informaţiilor despre pachetele capturate. Un
exemplu este prezentat în figura 7.39.
Fig. 7.39. Informaţii despre pachetele analizate de Packet Sniffer.
Packet Sniiffer determină, de asemenea, cota de pachete în funcţie de

protocol. Pentru a afişa asemenea informaţie, se apasă butonul Protocols din
fila General (fig. 7.38). Un exemplu este prezentat în figura 7.40
274
Fig. 7.40. Cota de pachete în funcţie de protocol.
.
275
8. REŢELE FĂRĂ FIR
8.1. Reţele fără fir: aspecte generale
8.1.1. Noţiune şi clasificarea reţelelor fără fir
Reţele de calculatoare fără fir sunt reţelele, care în calitate de mediu de
transmisie a datelor între nodurile de reţea folosesc spaţiul înconjurător. În
asemenea reţele, sistemele de cabluri electrice şi/sau optice, folosite ca mediu
de transmisie a datelor în reţelele cablate, sunt înlocuite cu sisteme de canale
fără fir ce folosesc frecvenţe radio. Spectrul de frecvenţe radio cuprinde
diapazonul [9 kHz; 3 THz].
Canalele/liniile fără fir prin spaţiul înconjurător pot fi:
 linii terestre cu microunde ce operează în diapazonul de unde ultrascurte
(0,3 GHz – 300 GHz). Ele au capacitate mare şi asigură o protecţie relativ
bună la perturbaţii. Se folosesc inclusiv în comunicaţii punct-la-punct,
realizate în şiruri de staţii de retransmisie, plasate în raza vizuală directă
a antenelor lor (până la 40-50 km);
 linii cu microunde troposferice cu raza de acţiune a unei staţii de până la
800 km. Se folosesc rar;
 liniile cosmice – linii cu microunde ce utilizează retranslatoare, instalate
pe staţii-sateliţi ai Pământului. Banda tipică a unui satelit este de 500
MHz; aceasta este împărţită între mai multe transpondere (unităţi de
recepţie şi retransmisie), fiecare cu o bandă de 40-50 MHz. Capacitatea
de comunicaţie a unui transponder poate fi împărţită în mai multe
canale, folosind divizarea în frecvenţă (Frequency Division Multiple
Access) sau în timp (Time Division Multiple Access);
 canale radio şi canale de spectru larg folosite în telefonia mobilă şi
reţelele locale fără fir (WLAN);
 canale optice prin spaţiu folosite în telecomunicaţii şi reţelele WLAN.
Reţelele fără fir pot fi personale (WPAN), locale (WLAN), metropolitane
(WMAN) şi de arie largă (WWAN). Reţelele WPAN au raza de acţiune de până
la câteva zeci de metri, cele WLAN – de până la câteva sute de metri, cele
WMAN – de până la câteva zeci de kilometri, iar cele WWAN – fără limite.
Asemenea reţele, cu excepţia celor WPAN, au, de obicei, legătură între ele prin
Internet.
Reţelele WPAN cooperează resursele unui grup de echipamente de uz
particular. Acestea sunt, de obicei, echipamente mobile, cu consum mic de
energie. O conexiune în cadrul WPAN implică puţin sau nu implică deloc vreo
infrastructură sau conectivitate directă în afara legăturii date. WPAN se
276
bazează pe standardul IEEE 802.15. Sunt larg cunoscute reţelele WPAN
Bluetooth şi ZigBee.
Reţelele WMAN sunt conforme standardului IEEE 802.16. Tehnologia cea
mai cunoscută pentru asemenea reţele este WiMax, folosită îndeosebi ca
tehnologie de acces de bandă largă la Internet. Viteza de operare este de la
zeci de Mbps până la 1 Gbps.
Reţelele WWAN se folosesc, preponderent, pentru interconectarea de
dispozitive amplasate în oraşe învecinate. Legăturile între punctele de acces
ale acestora sunt, de obicei, linii cu microunde ce folosesc antene parabolice
care operează în banda de 2,4 GHz.
Din categoriile de reţele fără fir menţionate, cele mai folosite sunt reţelele
WLAN. Acestea cooperează resursele dispozitivelor de reţea, folosind o
metodă distribuită de acces la mediul de transmisie fără fir. Staţiile unor
asemenea reţele pot să se deplaseze într-o anumită arie, fără a pierde legătura
cu reţeaua. Majoritatea reţelelor WLAN sunt conforme standardului IEEE
802.11 (vezi s. 8.1.2), denumite şi reţele Wi-Fi.
Prima reţea de calculatoare fără fir a fost reţeaua ALOHAnet, lansată în
1971 la Universitatea din Hawaii (SUA). Primele produse pentru reţele locale
fără fir au fost fabricate la începutul anilor 1990’. Standardul IEEE 802.11 a fost
aprobat în 1997. Acesta a fost ulterior concretizat şi extins de mai multe ori,
fiind aprobate standardele IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE
802.11n, IEEE 802.11ac, IEEE 802.11ad, IEEE 802.11af, IEEE 802.11ah ş.a.
8.1.2. Particularităţile accesului la mediul fără fir
Staţiile reţelelor WLAN pot fi fixe, portabile sau mobile. Staţiile portabile
pot fi relocalizate, dar accesul lor la reţea este fix. Staţiile mobile pot obţine
accesul la reţea şi în mişcare.
Mediul înconjurător, folosit în reţelele WLAN ca mediu de transmisie,
este considerabil diferit, din punctul de vedere al transferului de date, de
mediile cablate [15]:
 nu are hotare distincte de acoperire pentru staţii;
 nu este protejat contra interferării cu alte semnale ce îl partajează;
 este mai puţin fiabil;
 are topologie dinamică;
 are proprietăţi de propagare a semnalului asimetrice şi variabile în timp
ş.a.
Faptul că mediul fără fir nu are hotare distincte de acoperire pentru
staţii, conduce, de exemplu, la aşa probleme specifice ca: problema staţiei
ascunse (hidden station problem) şi problema staţiei expuse (exposed station
problem).
Problema staţiei ascunse. Fie staţiile A, B şi C sunt amplasate astfel, că în
aria de acoperire a staţiei B intră ambele staţii A şi C, pe când staţia C nu
277
intră în aria de acoperire a staţiei A şi vice verso. Într-un asemenea caz, dacă
B iniţiază o transmisie, ambele staţii A şi C află acest lucru, sesizând starea
ocupată a mediului, ceea ce este comun şi pentru mediile de transmisie
cablate. Totodată, dacă staţia B nu transmite, atunci atât staţia A, cât şi cea
C, nesesizând starea ocupată a mediului, pot să iniţieze o transmisie către B.
Astfel, la receptorul staţiei B va avea loc o coliziune de semnale, de care nici
A şi nici C nu pot afla, fără folosirea unui mecanism de confirmare a recepţiei
de la B. Dacă o staţie nu poate detecta un potenţial competitor la mediu
(staţie ascunsă), atunci ea se confruntă cu problema staţiei ascunse.
Problema staţiei expuse. Fie staţiile A, B şi C din exemplul precedent şi
încă o staţie D, în zona de acoperire a căreia este doar staţia C. Dacă staţia B
transmite către A, atunci C, chiar dacă şi are de transmis date către D, nu va
iniţia transmisia, deoarece sesizează starea ocupată a mediului de către
transmisia staţiei B. Totodată, staţia D nu este în aria de acoperire a staţiei
B, deci receptorul acesteia nu este, practic, influenţat de transmisia staţiei B.
De asemenea, chiar dacă staţia C şi este în aria de acoperire a staţiei B,
semnalul transmis de către C este mult mai puternic, decât cel recepţionat
de la B, ultimul fiind treptat atenuat odată cu creşterea distanţei de la sursă;
de aceea transmisia staţiei C către D ar fi relativ calitativă. Într-o asemenea
situaţie, staţia C (staţia expusă) se confruntă cu problema staţiei expuse.
O altă particularitate, comparativ cu interfeţele de reţea pentru medii de
transmisie cablate, constă în faptul că majoritatea interfeţelor de reţea
pentru medii de transmisie fără fir sunt semiduplex, adică nu pot transmite
şi recepţiona semnale concomitent. Aceasta face imposibilă folosirea în
reţele fără fir a metodei de acces la mediu CSMA/CD (IEEE 802.3).
Există şi alte particularităţi ale mediului de transmisie fără fir. Totodată,
subnivelul MAC al reţelelor fără fir nu trebuie să difere, pentru nivelele
superioare (subnivelul Legătură de date – LLC), de cel al reţelelor cablate. De
aceea mobilitatea staţiilor este realizată în cadrul subnivelului MAC. Din
aceleaşi considerente, într-o Asociaţie de reţea cu securitate robustă (Robust
security network association – RSNA), subnivelul MAC trebuie să asigure şi
cerinţele de fiabilitate a funcţionării. În acest scop, IEEE 802.11 defineşte
funcţiile de protecţie a cadrelor, iar IEEE 802.1X-2004 – autentificarea şi un
Port controlat, IEEE 802.11 şi 802.1X-2004 colaborând, totodată, în scopuri
de gestiune. Toate staţiile unei RSNA au o entitate 802.1X-2004, care se
ocupă de aceste servicii.
În cazul unor aplicaţii cu cerinţe de calitate speciale, LAN IEEE 802.11
realizează o legătură în cadrul unui mediu QoS staţie-la-staţie, care poate fi
stabilită şi gestionată de entităţile nivelelor superioare. Pentru asigurarea
unor performanţe de calitate, comparabile cu cele ale reţelelor locale
278
cablate, subnivelul MAC IEEE 802.11 incorporează facilităţi suplimentare,
netradiţionale pentru acest nivel.
8.1.3. Caracteristica generală a IEEE 802.11
IEEE 802.11 este un set de standarde privind nivelul fizic şi subnivelul MAC
al nivelului Legătură de date OSI pentru reţele WLAN, denumite şi Wi-FI.
Predecesorul IEEE 802.11 a fost tehnologia WaveLAN, primele produse ale
căreia au fost lansate pe piaţă în Olanda în 1991. Primul set de standarde
802.11 a fost aprobat în iunie 1997 şi prevedea transferul de date în banda de
2,4 GHz la viteza nominală de 1 sau 2 Mbps. Ulterior, specificaţiile 802.11
iniţiale au fost îmbunătăţite, fiind aprobate cele 802.11 a/b/g/n/ac/af/ah cu
viteza de transfer date de până la cca. 7 Gbps. Unele caracteristici ale acestor
specificaţii sunt prezentate în tabelul 8.1.
Tabelul 8.1. Unele caracteristici ale specificaţiilor 802.11
Anul Frecvenţa deLăţimea Viteza Fluxuri Metoda Distanţa (m)
802.11 lansării GHz bandă maximă de spaţiul
Mbps Mbps MIMO modulare încăperi liber
– 1997 2,4 20 2 1 DSSS,FHSS 20 100
5 35 120
a 1999 20 54 1 OFDM
3,6 – 5000
b 1999 2,4 20 11 1 DSSS 35 140
g 2003 2,4 20 54 1 OFDM,DSSS 38 140
20 4x72,2 70 250
n 2009 2,4/5 4
40 4x150 70 250
20 8x87,6
40 8x200 OFDM
ac 2012 5 8
80 8x433,3
160 8x866,7
ad 2014 2,4/5/60 6912
Familia 802.11 prevede benzile de frecvenţă de 2,4, 3,6, 4,9 GHz, 5 GHz,
5,9 GHz şi 60 GHz, din care larg se folosesc cele de 2,4 şi 5 GHz. Benzile de 3,6
şi 4,9 GHz se folosesc doar în SUA, cea de 5,9 GHz – doar în mijloacele de
transport, îndeosebi vehicule, iar cea de 60 GHz este aprobată relativ recent.
Metodele de modulare aplicate pot să difere de la caz la caz şi sunt: OFDM
(Orthogonal Frequency-Division Multiplexing), DSSS (Direct-Sequence Spread
Spectrum) sau FHSS (Frequency-Hopping Spread Spectrum). Protocolul de
acces la mediu folosit este CSMA/CA (DCF) cu anumite concretizări, completări
şi dezvoltări. Regimul de operare este semiduplex.
Specificaţia 802.11, propusă în 1997, este deja depăşită. Prima specificaţie,
larg acceptată pe piaţă, a fost 802.11b, urmată de cele 802.11a şi 802.11g.
Ulterior, se bucură de o largă popularitate specificaţia 802.11n – prima
279
specificaţie cu modulare multiflux (Multiple-input and Multiple-output –
MIMO). MIMO prevede folosirea mai multor antene şi, respectiv, semnale,
atât la transmiţător, cât şi la receptor, ceea ce permite creşterea vitezei de
transfer date. Numărul de antene la 802.11n este 4, iar la 802.11ac – 8.
De menţionat că specificaţia 802.11g este compatibilă, de sus în jos, cu cea
802.11b, iar specificaţia 802.11n este compatibilă, de sus în jos, cu cele
802.11a şi 802.11g (OFDM). De asemenea, deoarece canalele folosite în banda
de 5 GHz nu interferează, tehnologiile 802.11a şi 802.11n sunt mai puţin
supuse perturbaţiilor. Toate specificaţiile 802.11a/b/g/n realizează selectarea
automată sau fixă a vitezei de transfer date.
Din cauza particularităţilor mediului de transmisie şi a metodei de acces la
mediu folosite, viteza reală de transfer date în reţelele WLAN este de cca. 2 ori
mai joasă decât cea nominală. Astfel, viteza reală de operare este în mediu de
cca.: pentru 802.11a – 20 Mbps; pentru 802.11b – 5 Mbps; pentru 802.11g –
22 Mbps. Mai mult ca atât, dacă dispozitivul de reţea realizează mai multe
standarde, de exemplu 802.11b/g, atunci viteza reală poate scădea şi mai
mult. Totodată, viteza traficului UDP este cu cca. 5-20 % mai mare, decât de
trafic TCP.
În benzile de 2,4 GHz, 3,6 GHz, 4,9 GHz, 5 GHz, 5,9 GHz şi 60 GHz se
folosesc şase game distincte de frecvenţe, divizate în mai multe canale. Din
canalele permise, fiecare ţară selectează mulţimea de canale convenabile şi le
specifică în reglementările locale.
Cele 14 canale, permise pentru banda de 2,4 GHz, ce are o lăţime totală de
2495 MHz – 2401 MHz = 94 MHz, sunt prezentate în figura 8.1. Fiecare din
aceste 14 canale are lăţimea de bandă de 22 MHz. Se poate observa că
maximum trei din aceste 14 canale (1, 6 şi 11) nu interferează. Există însă mai
multe variante a câte două canale ce nu interferează, de exemplu: 1 şi 7; 1 şi 8;
2 şi 8; etc. Adică maximum trei puncte de acces pot funcţiona în aceeaşi arie,
fără ca semnalele respective să interfereze. De menţionat, totodată, că
segmentul de frecvenţe folosit de 802.11b şi 802.11g poate, de asemenea, să
interfereze cu telefoanele fără fir, echipamentele Bluetooth şi cuptoarele cu
microunde.
Din cele 14 canale, prezentate în fig. 8.1, la moment în ţările europene, cu
excepţia Franţei şi Spaniei, se folosesc primele 13, iar în SUA – primele 11.
Fig. 8.1. Canalele benzii de 2,4 GHz (802.11b/g/n).
280
Benzile de 3,6 GHz şi 4,9 GHz (802.11y, aprobat în 2008), după cum a fost
deja menţionat mai sus în această secţiune, se folosesc doar în SUA, iar cea de
Număr canal
Canal turbo de 40 MHz
Canal de 20 MHz
Frecvenţa
Fig. 8.2. Canale în banda 5GHz.

5,9 GHz (802.11p, aprobat în 2010) – doar în mijloace de transport, îndeosebi
vehicule.
Banda de 5 GHz include mai multe canale de 20 MHz în diapazonul de la
4915 MHz până la 5825 MHz, din care doar o parte se folosesc, în funcţie de
ţară. În prezent în SUA se folosesc canale în diapazonul de frecvenţe de 5180-
5825 MHz, iar în UE în diapazonul 5180-5700 MHz. Canalele folosite, 12 canale
a câte 20 MHz sau 5 canale turbo (turbo channel) a câte 2 x 20 MHz = 40 MHz,
nu interferează, teoretic, între ele (fig. 8.2). Comasarea a două canale de 20
MHz în unul de 40 MHz permite creşterea vitezei de transfer date.
.
De rând cu cele deja descrise, se folosesc de asemenea, canale cu lăţimea

de bandă de două (10 MHz) şi de patru ori mai mică (5MHz). Aceasta permite
reducerea interferenţelor între canale învecinate. Însă nu toate produsele
suportă asemenea canale. De asemenea, se reduce respectiv viteza de transfer
date.
De menţionat că dispozitivele 802.11 pot opera la frecvenţe licenţiate de
autorităţile reglatoare naţionale. Totodată, standardul este astfel generalizat
că este independent de tipul licenţei, banda de frecvenţe şi ţara de operare
a reţelelor. Pentru automatizarea furnizării canalului şi a controalelor de
reglementare, necesare staţiilor neînregistrate pentru a opera ca staţii
dependente într-un spectru licenţiat, se folosesc proceduri de activare
dinamică a staţiilor (Dynamic station enablement – DSE). În cazul unor reţele
suprapuse, ce cauzează interferenţa de canale, se foloseşte Protocolul bazat
pe dispute (Contention-Based Protocol – CBP). Acesta asigură fiecărui
transmiţător furnizarea unor oportunităţi rezonabile de operare altor
transmiţătoare.
281
Asupra calităţii transmisiei, au influenţă atât interferenţele canalelor
vecine, cât şi puterea semnalului. Puterea semnalului depinde de distanţa
între transmiţător şi receptor. În funcţie de putere, semnalele se clasifică în
categoriile:
 de la -40 dBm până la -58 dBm – semnal foarte bun. Pentru WLAN,
puterea maximă a semnalului este, practic, în diapazonul de la -10 dBm
(100 μW) până la -30 dBm;
 de la -58 dBm până la -70 dBm – semnal bun;
 de la -70 dBm până la -85 dBm – semnal satisfăcător;
 de la -85 dBm până la -90 dBm – semnal slab;
 < -90 dBm – conexiunea se întrerupe;
 <-95 dBm – se recomandă de a interzice accesul la așa semnal,
deoarece micșorează viteza de lucru la celelalte conexiuni.
Aici valoarea de 0 dBm corespunde puterii semnalului de 1 mW = 1000
μW. Pentru reprezentarea puterii P în waţi prin cea x în dBm, se foloseşte
expresia
P , unde [x] = dBm, [P] = W.
x  10 lg (8.1)
1 mW
O problemă aparte a reţelelor fără fir este securitatea funcţionării. Pentru
securizarea datelor, standardele 802.11 prevăd aşa acţiuni ca:
 Filtrarea MAC – controlul conectării la punctul de acces în baza adreselor
MAC şi a numelui WLAN;
 Cifrarea – folosind protocoalele WEP (Wired Equivalent Privacy), WPA
(Wi-Fi Protected Access) şi WPA2;
 Controlul accesului la mediu – în baza protocolului 802.1x;
 VPN – configurarea VPN deasupra conexiunii fără fir ş.a.
8.1.4. Unele particularităţi ale standardului IEEE 802.11n
Standardul IEEE 802.11n, comparativ cu cele IEEE802.11a/g, prevede aşa
dezvoltări ca: folosirea a până la patru antene, suportând modularea multiflux
(MIMO, până la patru fluxuri de date); posibilitatea folosirii, de rând cu cele
de 20 MHz, şi a canalelor de 40 MHz; agregarea cadrelor; îmbunătăţiri de
securitate ş.a.
IEEE 802.11n prevede operarea atât în banda de frecvenţe de 2,4 GHz, cât
şi în cea de 5 GHz. Pentru atingerea capacităţii maxime, se recomandă
folosirea unei reţele pure 802.11n la banda de 5 GHz, canalele căreia mai puţin
interferează, comparativ cu cele ale benzii de 2,4 GHz. Dacă însă nu toate
dispozitivele suportă 802.11n, atunci poate fi oportună o reţea mixtă
802.11b/g/n. În cazul unei reţele mixte, este mai eficient de folosit un AP dual
(cu două canale) şi de plasat traficul 802.11b/g pe un canal de 2,4 GHz, iar
traficul 802.11n – pe un canal de 5 GHz.
282
Exemple de creare a canalelor de 40 MHz în banda de 5 GHz sunt
prezentate în fig. 8.2. Standardul prevede posibilitatea creării de canale de 40
MHz şi în banda de 2,4 GHz. În asemenea cazuri, este prevăzută folosirea unui
canal primar de 20 MHz şi a unui canal secundar de 20 MHz. Canalul primar
este folosit pentru comunicarea cu clienţii ce nu suportă modul de 40 MHz. În
modul de 40 MHz, frecvenţa centrală este de fapt media canalelor primar și
secundar.
Tehnologia MIMO se realizează folosind multiplexarea spaţială (Spatial
Division Multiplexing – SDM). SDM multiplexează mai multe fluxuri de date
independente în cadrul unui singur canal standard de 20 sau 40 MHz. Fiecare
flux spaţial necesită o antenă aparte, atât la emiţător, cât şi la receptor. De
asemenea, tehnologia MIMO necesită un emiţător/receptor de semnal
frecvenţă radio purtător şi un convertor analogo-numeric la fiecare antenă.
Numărul de fluxuri de date simultane este limitat de numărul de antene
la ambele capete ale legăturii. Pentru a specifica legăturile MIMO, se
foloseşte notarea axb:c, unde: a specifică numărul maxim de antene de
transmisie sau căi de frecvenţă radio (radio-frequency (RF) chain) Tx ce pot fi
utilizate; b – numărul maxim de antene de recepție sau căi de frecvenţă
radio Rx ce pot fi utilizate; c – numărul maxim de fluxuri de date spațiale ce
pot fi folosite. De exemplu, un sistem, ce poate transmite pe două și
recepţiona pe trei antene, dar poate transmite sau recepţiona doar două
fluxuri de date, se notează ca 2x3:2. Valoarea c şi determină rata de transfer
date.
Standardul IEEE 802.11n permite configurări de până la 4x4:4. Frecvent
se folosesc aşa configurări ca: 2x2:2, 2x3:2 şi 3x2:2, toate acestea asigurând
aceiaşi rată de transfer date. Deseori se întâlneşte deja şi configurarea
3x3:3.
Pentru a atinge capacitatea unei legături MIMO, emițătorul şi receptorul
folosesc tehnici de pre-codificare și, respectiv, post-codificare. Pre-
codificarea include formarea fasciculului spațial și codificarea spațială,
formarea fasciculului spațial îmbunătățind calitatea semnalului recepţionat
în faza de decodificare. Codificarea spațială poate crește rata de transfer
date prin multiplexarea spațială și creșterea diapazonului folosit, exploatând
diversitatea spațială prin aşa tehnici cum ar fi codificarea Alamouti.
Standardul IEEE 802.11n defineşte 32 de scheme de modulare şi rate de
codificare reprezentate de schemele de modulare şi codificare (Modulation
and Coding Scheme – MCS), prezentate în tabelul 8.2.
În tabelul 8.2, prin rata de codificare, denumită şi rată informaţională, a
unui cod cu corectarea erorilor la înaintare (forward error correction) se
subînţelege cota fluxului util de date (iredundant). Aceasta se notează k/n,
unde, la fiecare k biţi de informaţie utilă, coderul generează n biţi de date în
283
total, din care n-k sunt redundanţi. De exemplu, rata de codificare a unui cod
cu control de paritate pe 8 biţi este de 7/8.
Tabelul 8.2. Viteza de acces, în funcţie de numărul de fluxuri [1]
Numărul Metoda de Rata de Rata de date, Mbps
Indexul GI = 800 ns GI = 400 ns
de fluxuri
MCS modulare codificare
spaţiale 20 MHz 40 MHz 20 MHz 40 MHz
0 1 BPSK 1/2 6,5 13,5 7,2 15
1 1 QPSK 1/2 13 27 14,4 30
2 1 QPSK 3/4 19,5 40,5 21,7 45
3 1 16-QAM 1/2 26 54 28,9 60
4 1 16-QAM 3/4 39 81 43,3 90
5 1 64-QAM 2/3 52 108 57,8 120
6 1 64-QAM 3/4 58,5 121,5 65 135
7 1 64-QAM 5/6 65 135 72,2 150
8 2 BPSK 1/2 13 27 14,4 30
9 2 QPSK 1/2 26 54 28,9 60
10 2 QPSK 3/4 39 81 43,3 90
11 2 16-QAM 1/2 52 108 57,8 120
12 2 16-QAM 3/4 78 162 86,7 180
13 2 64-QAM 2/3 104 216 115,6 240
14 2 64-QAM 3/4 117 243 130,3 270
15 2 64-QAM 5/6 130 270 144,4 300
16 3 BPSK 1/2 19,5 21,7 40,5 45
17 3 QPSK 1/2 39 43,3 81 90
18 3 QPSK 3/4 58,5 65 121,5 135
19 3 16-QAM 1/2 78 86,7 162 180
20 3 16-QAM 3/4 117 130 243 270
21 3 64-QAM 2/3 156 173,3 324 360
22 3 64-QAM 3/4 175,5 195 364,5 405
23 3 64-QAM 5/6 195 216,7 405 450
24 4 BPSK 1/2 26 28,8 54 60
25 4 QPSK 1/2 52 57,6 108 120
26 4 QPSK 3/4 78 86,8 162 180
27 4 16-QAM 1/2 104 115,6 216 240
28 4 16-QAM 3/4 156 173,2 324 360
29 4 64-QAM 2/3 208 231,2 432 480
30 4 64-QAM 3/4 234 260 486 540
31 4 64-QAM 5/6 260 288,8 540 600
În ce priveşte parametrul GI, acesta este intervalul de protecţie (Guard
Interval) – intervalul între caracterele ce se transmit.
Agregarea cadrelor poate fi de două tipuri:
1) agregarea unităţilor de date de serviciu MAC (MAC service data unit –
MSDU) în partea de sus a subnivelului MAC (MSDU agregation – A-MSDU);
284
2) agregarea unităţilor de date de protocol MAC (MAC protocol data unit –
MPDU) în partea de jos a subnivelului MAC (MPDU agregation – A-MPDU).
Agregarea cadrelor constă în comasarea a unităţi MSDU sau MPDU
multiple într-un cadru, pentru a reduce cota informaţiilor de serviciu ce revine
antetului. Agregarea A-MPDU necesită folosirea confirmării de blocuri de date
BlockAck.
8.1.5. Arhitectura reţelelor IEEE 802.11
8.1.5.1. Setul de servicii de bază BSS
O reţea WLAN este constituită din staţii fără fir, denumite şi clienţi, şi
puncte de acces (access point – AP), interconectate printr-un mediu fără fir.
Punctele de acces se referă, de obicei, tot la staţii fără fir. Atât clienţii, cât şi
punctele de acces sunt dotate cu controloare (adaptoare) de interfeţe de
reţea fără fir (wireless network interface controller – WNIC). Punctele de acces
sunt, de obicei, rutere sau punţi (comutatoare – switch). Clienţii fără fir pot fi
aşa dispozitive mobile ca laptop-uri, asistenţi numerici personali (personal
digital assistant – PDA), telefoane IP şi alte telefoane inteligente şi aşa
dispozitive fixe ca servere, calculatoare desktop, imprimante, etc.
Ansamblul tuturor staţiilor fără fir ce pot comunica între ele se numeşte
Set de servicii de bază (Basic Service Set – BSS). Fiecare BSS are un identificator
(ID), denumit BSSID, care este adresa MAC a punctului de acces ce deserveşte
acest BSS. Aria cuprinsă de un BSS se numeşte Aria serviciilor de bază (Basic
Service Area – BSA).
8.1.5.2. Categoriile de bază de reţele IEEE 802.11
Disting trei categorii de bază de reţele IEEE 802.11: reţele independente
cu servicii de bază – IBSS (Independent BSS), reţele de acoperire extinsă –
ESS (Extended Service Set) şi reţele plasă – MBSS (Mesh BSS). Esenţa acestor
categorii de reţele este descrisă în ss. 8.1.5.3-8.1.5.5.
8.1.5.3. Reţele IBSS
BSS independent (Independent BSS – IBSS) este tipul de bază de reţele
IEEE 802.11. O reţea IBSS constă dintr-un număr arbitrar de staţii, o parte
sau toate din care pot comunica direct, reţeaua nefiind conectată cu alte
reţele. Fiecare staţie poate comunica cu una sau mai multe alte staţii,
comunicarea fiind posibilă doar între staţiile ce comunică direct. IBSS nu
conţine puncte de acces şi se identifică printr-un identificator al setului de
servicii (service set identifier – SSID).
8.1.5.4. Reţele ESS
ESS este un ansamblu de BSS interconectate prin puncte de acces.
Punctele de acces ale ESS sunt conectate între ele de un sistem de distribuire
285
(Distribution System – DS) – fig. 8.3. Fiecare asemenea BSS conţine o staţie-
punct de acces, prin care BSS este conectat la DS, şi se numeşte BSS
infrastructură (iBSS). Setul iBSS este identificat de punctul de acces care o
formează. IEEE 802.11 separă logic mediul fără fir (wireless medium – WM)
de mediul DS (DSM). Aceste medii sunt folosite în scopuri diferite. DS poate
fi creat în baza a diverse tehnologii, inclusiv ale celor pentru reţele locale
cablate IEEE 802.
iBSS1 DS iBSS2
S1 S4
AP AP
S5
S2
WM1 DSM WM2
S3 S5
Fig. 8.3. Relaţiile dintre staţii (S), iBSS, WM, AP, DS şi DSM.
ESS este o uniune de iBSS cu acelaşi identificator SSID, interconectate de
DS, dar neincluzând DS înseşi. Totodată, la subnivelul LLC, o reţea ESS apare
ca şi o reţea IBSS. Adică subnivelul LLC nu face deosebire între categoriile de
reţea ESS şi IBSS; staţiile unei ESS pot comunica între ele şi pot trece de la un
BSS la altul în mod transparent pentru LLC.
Punct de acces (access point – AP) se numeşte orice entitate, care posedă
funcţionalităţi de staţie şi permite staţiilor asociate accesul la DS, prin
intermediul WM, şi viceversa. Relaţiile dintre staţii (S), iBSS, WM, AP, DS şi
DSM sunt prezentate în figura 8.3. Staţiile unei reţele ESS pot realiza
schimburi de date cu staţiile unei reţele cablate. În acest scop se folosesc
entităţi ale DS denumite portaluri. Portalul este o componentă arhitecturală
logică, care serveşte pentru interconectarea sistemului DS şi a unei reţele
locale non-IEEE-802.11. Un exemplu de reţea ESS este dat în figura 8.4.
8.1.5.5. Reţele MBSS
Facilitate plasă (mesh) este un set de funcţii extinse, reguli de acces la
canal, metode de autentificare reciprocă şi obiecte gestionate, folosite
pentru transferul de date între staţiile care operează autonom şi care pot să
nu fie în comunicare directă, printr-o singură instanţă a mediului fără fir, una
cu alta.
286
ESS
S1 S4
AP AP
iBSS1 DS
S5
S2
iBSS2
S3 S5
Fig.
Fig. 8.2
8.4.OOreţea
reţeaESS
ESSdin
diniBSS
iBSS11şişiiBSS
iBSS22..
Reţea MBSS este un BSS ce constă din staţii plasă autonome de acelaşi
profil plasă, o parte din care pot să nu fie în comunicare directă între ele. Ea
nu are o entitate centrală ca punctul de acces al unei iBSS. O staţie plasă nu
poate fi membră a unei reţele IBSS sau iBSS. De aceea staţiile plasă nu
comunică direct cu staţiile non-plasă.
Pentru schimbul de mesaje în cadrul unei reţele MBSS, toate staţiile
stabilesc legături fără fir cu stațiile învecinate. Ulterior, folosind capabilitatea
multe-salt, mesajele pot fi transferate între staţiile, ce nu sunt în comunicare
directă unele cu altele. Astfel, din punctul de vedere al transferului datelor,
staţiile unei reţele MBSS sunt, aparent, interconectate direct la subnivelul
MAC, chiar dacă ele nu sunt în raza de acţiune directă. Mai mult ca atât,
dacă o reţea MBSS are una sau mai multe porţi plasă cu acces la unul şi
acelaşi DS, atunci staţiile MBSS pot fi chiar în arii disjuncte. În asemenea
cazuri, transferul de date între staţii implică resursele DS.
O reţea MBSS poate fi independentă, ca şi una IBSS. Totodată, spre
deosebire de iBSS ce operează în cadrul ESS, MBSS nu are o entitate centrală
(ca AP la iBSS). Totuşi, reţelele MBSS pot fi interconectate cu alte BSS prin
DS, folosind una sau mai multe porţi plasă. În asemenea cazuri, staţiile plasă
pot comunica cu staţii non-plasă. Transferul de date se efectuează conform
schemei: staţie plasă ↔ … staţie plasă ↔ poartă plasă ↔ AP ↔ staţie
non-plasă. Dacă DS, la care este conectată MBSS, este conectată, printr-un
portal, la o reţea cablată, atunci staţiile acestei MBSS pot efectua transferuri
de date şi cu staţiile reţelei cablate.
287
8.1.6. Moduri de operare şi setarea reţelelor IEEE 802.11
8.1.6.1. Modurile de operare a reţelelor fără fir
Standardul IEEE 802.11 prevede două moduri de operare a reţelelor WLAN:
ad-hoc şi infrastructură.
8.1.6.2. Modul ad-hoc de operare a reţelelor fără fir
În modul ad-hoc, staţiile transmit date doar direct staţie-la-staţie (peer-to-
peer – P2P). Pentru asemenea transmisii nu se cere permisiune de la vreo altă
staţie, de exemplu un punct de acces. Este doar necesară identificarea
reciprocă a staţiilor perechii, între care se iniţiază o transmisie. În acest mod
operează reţelele IBSS (vezi s. 8.1.5).
8.1.6.3. Modul infrastructură de operare a reţelelor fără fir
În modul infrastructură, staţiile client comunică prin intermediul unui
punct de acces, care serveşte şi ca punte/poartă către alte reţele, inclusiv LAN
şi Internet. În acest mod operează reţelele iBSS şi ESS (vezi s. 8.1.5).
8.1.6.4. Mecanismele de securizare a reţelelor fără fir
Deoarece mediul de transmisie în reţelele WLAN este unul deschis (prin
spaţiu), standardul 802.11 include şi câteva mecanisme de securizare a
transferurilor de date prin cifrare, inclusiv: WEP (Wired Equivalent Privacy – nu
prea sigur), WPA (Wi-Fi Protected Access), WPA2 ş.a. (vezi s. 8.1.7)
8.1.6.5. Punţile în reţele fără fir
Pentru interconectarea de reţele, fără rutarea de pachete, se folosesc
punţi. De exemplu, o punte Ethernet fără fir poate interconecta o reţea WLAN
802.11 la una Ethernet (vezi cap. 9).
8.1.6.6. Sistemele de distribuire fără fir WDS
Sistemele DS pot fi în totalitate fără fir. Asemenea sisteme se numesc DS
fără fir (Wireless DS – WDS). WDS permite interconectarea fără fir a punctelor
de acces într-o reţea IEEE 802.11. Folosind multiple AP, poate fi creată o reţea
fără fir extinsă. De asemenea, dacă se cere de puntat o legătură fără fir, atunci
este necesar de folosit WDS.
Un avantaj al WDS, faţă de DS cablate, constă în păstrarea adreselor MAC
ale pachetelor client, la transmiterea acestora între punctele de acces ale ESS.
Un punct de acces poate fi staţie de bază principală, una releu sau una
distantă. O staţie de bază principală este conectată, de obicei, la o reţea LAN
cablată. O staţie de bază releu comutează date între staţii de bază distante,
clienţi fără fir sau alte staţii releu şi o staţie de bază principală sau altă staţie
de bază releu. O staţie de bază distantă acceptă conexiuni de la clienţi fără fir
288
şi le transmite către staţii de bază releu sau principale. Conexiunile între
clienţii fără fir sunt realizate folosind adrese MAC.
Toate staţiile de bază ale WDS trebuie să fie configurate pentru folosirea
aceluiaşi canal radio şi partajarea cheilor WEP sau WPA, în cazul că acestea se
folosesc. Totodată, ele pot fi configurate pentru diferite SSID. Evident, toate
staţiile de bază ale WDS trebuie să fie astfel configurate, ca să poată înainta
date către alte staţii via WDS.
WDS poate oferi două modalităţi de conectivitate AP-la-AP:
 puntarea fără fir, în care AP-urile comunică doar între ele şi nu permit
accesul la ele a clienţilor fără fir;
 repetarea fără fir, în care AP-urile comunică atât între ele, cât şi cu clienţi
fără fir.
Există patru moduri de operare WDS: dynamic (dinamic); dynamic-mesh
(dinamic plasă); static şi static-mesh (static plasă). Modurile WDS statice
(static şi static-mesh) presupun configurarea statică (manuală) a interfeţei
WDS a AP şi a tuturor legăturilor interfeţelor WDS puntate ale ruterelor-staţii
client către aceasta. În modurile WDS dinamice (dynamic şi dynamic-mesh),
adăugarea înregistrărilor legăturilor WDS la AP se efectuează în mod dinamic
(automat), odată cu setarea şi puntarea interfeţelor WDS la ruterele-staţii client.
În modurile WDS -mesh (dynamic-mesh şi static-mesh), fiecare AP trebuie să
suporte alte AP ale WDS ca şi clienţi. În modurile WDS non-mesh (dynamic şi
static), schimbul de date între AP se efectuează prin intermediul unui anumit AP.
Pentru securizarea legăturilor WDS pot fi folosite toate funcţionalităţile de
securizare a legăturilor fără fir. Totodată, este necesară configurarea atentă a
parametrilor de securitate. Un singur profil de securitate poate fi folosit
pentru toţi clienţii sau, pentru legături WDS diferite, pot fi folosite profiluri
diferite.
În RouterOS profilurile de securitate sunt specificate în lista de conectare
(connect-list). Înainte de stabilirea legăturii WDS cu un alt AP, punctul de acces
verifică lista de conectare şi configurările de securitate folosite. Legătura WDS
se va stabili doar dacă ambele AP comunicante au setările de securitate
corespunzătoare.
Dacă AP foloseşte profilul de securitate cu modul mode = dynamic-keys,
atunci pentru toate legăturile WDS se va folosi cifrarea. Deoarece
autentificarea WPA şi schimbul de chei nu sunt simetrice, unul din cele două
AP comunicante va opera, în scopul stabilirii unei conexiuni securizate, ca şi
client. La stabilirea unei legături WDS securizate folosind WPA, la ambele AP
trebuie să se potrivească următorii parametri WPA: authentication-
types, unicast-ciphers, group-ciphers. Pentru modurile WDS non-mesh
(dynamic şi static), aceşti parametri trebuie să aibă aceleaşi valori la ambele
289
AP, iar în modurile WDS -mesh (dynamic-mesh şi static-mesh), fiecare AP
trebuie să-l suporte pe celălalt AP al WDS ca şi client.
La dezavantajele folosirii WDS se referă:
 reducerea de circa două ori a capacităţii efective de transfer date după
prima retransmisie (salt – hop). Ca exemplu ar putea servi transferul de
date între două calculatoare, unul din care (CA) este conectat la o
interfaţă Ethernet a AP A, iar celălalt (CB) – la o interfaţă fără fir a AP B. La
transferul de Date între CA şi CB, AP B trebuie mai întâi să recepţioneze,
iar apoi să retransmită aceleaşi date. Dacă însă şi calculatorul C B ar fi fost
conectat la o interfaţă Ethernet a AP B, atunci nu ar fost necesar ca AP B
să retransmită aceleaşi date. Desigur problema în cauză ar putea fi
evitată la folosirea unor AP cu două benzi radio – una pentru accesul
clienţilor şi alta pentru WDS;
 conexiunile WDS nu suportă, de obicei, din cauza lipsei de standarde
respective, atribuirea dinamică prin rotaţie a cheilor de cifrare (WPA,
etc.). Neajunsul se va depăşi, odată cu aprobarea şi implementarea
standardului IEEE 802.11s.
8.1.6.7. Modalităţile de operare a punctelor de acces
Un aspect important al configurării reţelelor 802.11 constă în modalităţile
de operare a punctelor de acces. Există două modalităţi majore de configurare
a AP: ca rutere şi ca punţi.
Un AP ruter conţine mai multe interfeţe, o parte din care pot fi cablate.
Între aceste interfeţe nu există conexiuni de Nivel 2, ci doar de Nivel 3 OSI.
Astfel fluxurile de pachete, transmise între interfeţele unui AP ruter, sunt în
mod obligatoriu rutate (vezi s. 10). Implicit dispozitivele RouterOS operează în
regim de ruter. Pentru ca un AP ruter să opereze în regim de punte, el trebuie
să fie configurat special (vezi s. 9).
Un AP punte conţine de asemenea mai multe interfeţe fizice, dar una sau
toate din acestea sunt cuplate împreună într-o interfaţă logică, denumită
punte. Interfaţa punte uneşte dispozitivele fizice la Nivelul 2 OSI. Astfel,
pachetele se transmit liber între interfeţele fizice, fără rutare, cu excepţia
cazurilor folosirii de i-bariere. Totodată, punţile trebuie folosite cu precauţie.
Nu se recomandă de interconectat două punţi direct sau prin comutatoare
(switch). Este oportun ele de separat prin rutere. Acesta va separa traficul de
difuzare.
8.1.7. Securitatea reţelelor fără fir
8.1.7.1. Aspecte generale
În mod obişnuit, mediul înconjurător, folosit de reţelele fără fir (WNet) ca
mediu de transmisie, este unul complet deschis pentru acces, fără limitări de
290
partajare între diverse staţii cu interfeţe fără fir. Aceasta face mediul fără fir
foarte vulnerabil faţă de acţiunile unor răufăcători. Orice specialist, folosind
mijloacele respective, poate, în aria de acoperire a unei reţele fără fir
nesecurizate, capta şi înregistra traficul de date, obţine acces neautorizat la
resursele de reţea, iar apoi să le folosească în interese proprii – deseori în
detrimentul deţinătorului WNet.
iSpărgătorii (crackers) deseori folosesc vulnerabilitatea reţelelor fără fir,
pentru a sparge reţelele cablate, conectate cu primele. De aceea, pentru
funcţionarea eficientă a reţelelor fără fir, sunt necesare mijloace puternice de
securizare. Securizarea WNet constă în luarea de măsuri de prevenire a
accesului neautorizat sau a deteriorării resurselor acestora. La asemenea
măsuri se referă:
 ascunderea SSID – dezactivarea difuzării identificatorului de reţea SSID,
ceea ce ar face mai dificilă detectarea punctului de acces. Măsura este
simplă, dar inefectivă contra acţiunilor unor specialişti experimentaţi;
 filtrarea adreselor MAC – permiterea accesului doar staţiilor cu anumite
adrese MAC. Totuşi, i-spărgătorii pot, relativ uşor, capta pachetele,
transmise de staţiile autorizate, şi, astfel, pot afla adresele MAC,
acceptate de punctul de acces respectiv;
 adresarea IP statică – folosirea de adrese IP statice şi nu a celor IP
dinamice, obţinute prin DHCP. Este o măsură efectivă doar contra unor i-
spărgători mai puţin experimentaţi;
 autentificarea IEEE 802.1x – folosirea mecanismelor standard de
autentificare ale IEEE pentru reţele LAN sau WLAN – EAPOL, denumit şi
„EAP over LAN” (Extensible Authentication Protocol over IEEE 802);
 cifrarea WEP (Wired Equivalent Privacy) – standardul iniţial de cifrare
pentru reţele 802.11, propus în 1999, dar, după cum s-a constatat, parola
folosită de acesta poate fi relativ uşor spartă. Din 2003 se consideră
depăşit de standardul WPA;
 cifrarea WPA (Wi-Fi Protected Access) – standardul de cifrare pentru
reţele 802.11, propus în 2003, pentru depăşirea neajunsurilor celui WEP;
 cifrarea WPA2 (Wi-Fi Protected Access) – a doua generaţie a WPA;
 VPN – configurarea de reţele private virtuale (Virtual Private Network –
VPN) deasupra conexiunii fără fir, inclusiv tunele PPTP, L2TP, IPsec, SSH
ş.a.
Aceste aspecte sunt descrise, într-o oarecare măsură în: ascunderea SSID –
s. 8.2.3; filtrarea adreselor MAC – ss. 8.5.3, 8.5.4; adresarea IP statică – ss. 1.5,
4.2; autentificarea IEEE 802.1x – s. 8.1.7.2; cifrarea WEP – ss. 8.1.7.3, 8.6.2;
cifrarea WPA – ss. 8.1.7.4, 8.6.2; cifrarea WPA2 – ss. 8.1.7.5, 8.6.2; VPN – s. 9.
291
8.1.7.2. Autentificarea IEEE 802.1x
Standardul IEEE 802.1x oferă un mecanism de autentificare a dispozitivelor
ce solicită ataşarea (conectarea) la o reţea LAN sau WLAN. El defineşte
încapsularea protocolului de autentificare extensibil EAP (Extensible
Authentication Protocol) deasupra IEEE 802, denumit EAPOL sau „EAP over
LAN”, fiind propus în 2001 pentru reţele IEEE 802.3, iar apoi, în 2004, fiind
extins şi pentru reţele IEEE 802.11 şi FDDI (ISO 9314-2);
Autentificarea 802.1x implică trei participanţi: solicitantul (supplicant),
autentificatorul (autenticator) şi serverul de autentificare (authentication
server). Solicitant este dispozitivul de reţea, de exemplu un PC, sau i-
programul, ce solicită ataşarea la LAN/WLAN. Autentificatorul este dispozitivul
de reţea, de exemplu un comutator Ethernet sau un punct de acces fără fir,
prin care solicitantul iniţiază ataşarea la LAN/WLAN. Serverul de autentificare
este dispozitivul, de obicei un calculator, ce rulează un i-program care suportă
protocoalele RADIUS (Remote Authentication Dial In User Service – Serviciu de
autentificare la distanţă a apelului utilizatorului) – acesta se mai numeşte şi
server RADIUS, şi EAP (Extensible Authentication Protocol – Protocol de
autentificare extinsă).
Autentificatorul acţionează ca un agent de securitate al reţelei protejate.
Acesta nu permite accesul solicitantului la partea protejată a reţelei, până
când identitatea ultimului nu este validată şi autorizată. În acest scop,
solicitantul oferă autentificatorului aşa informaţii ca numele de
utilizator/parola sau certificatul numeric, pe care autentificatorul le transmite
serverului de autentificare pentru verificare. Dacă serverul de autentificare
validează aceste informaţii, atunci solicitantul este admis la resursele părţii
protejate a reţelei.
Protocolul EAPOL operează la nivelul Reţea, deasupra nivelului Legătură de
date. Înseşi procedura de autentificare include, de obicei, patru etape:
1. Iniţializarea. Identificând un solicitant nou, portul comutatorului
(autentificatorul) este activat şi setat la starea „neautorizat”. Într-o asemenea
stare, este permis doar traficul 802.1x.
2. Iniţierea. Pentru iniţierea autentificării, autentificatorul transmite
periodic cadre de solicitare a identităţii EAP (EAP-Request Identity) la o adresă
specială de Nivel 2 a segmentului de reţea locală. Solicitantul urmăreşte
această adresă şi, la recepţia cadrului EAP-Request Identity, răspunde cu un
cadru de răspuns privind identitatea EAP (EAP-Response Identity), care conţine
identificatorul utilizatorului (User ID). Autentificatorul încapsulează acest
răspuns privind identitatea într-un pachet RADIUS de solicitare a accesului
(RADIUS Access-Request), pe care îl înaintează către serverul de autentificare.
Solicitantul poate, de asemenea, să iniţieze sau să restarteze autentificarea,
prin transmiterea unui cadru de start EAPOL (EAPOL-Start) către
292
autentificator, care, la rândul său, va răspunde cu un cadru EAP-Request
Identity.
3. Negocierea metodei EAP. Serverul de autentificare trimite, către
autentificator, un răspuns, încapsulat într-un pachet RADIUS de chemare-
acces (RADIUS Access-Challenge). Acesta conţine o solicitare EAP (EAP
Request), care specifică solicitantului metoda EAP necesară pentru
autentificare. Autentificatorul încapsulează EAP Request într-un cadru EAPOL,
pe care îl transmite solicitantului. În baza acestui răspuns, solicitantul poate
începe aplicarea metodei EAP în cauză sau poate răspunde cu o confirmare
negativă NACK (Negative Acknowledgement) şi specificarea metodei EAP, pe
care ar dori să o folosească.
4. Autentificarea. Dacă serverul de autentificare şi solicitantul convin la o
metodă EAP, între aceştia, prin intermediul autentificatorului, sunt transmise
cereri şi răspunsuri EAP, până când serverul de autentificare răspunde cu un
mesaj de succes EAP (EAP-Success) sau un mesaj de respingere EAP (EAP-
Failure), încapsulat într-un pachet RADIUS Access-Reject. Dacă autentificarea
este reuşită, atunci autentificatorul setează portul la starea „autorizat” şi
permite traficul de date obişnuit. În caz contrar, portul rămâne în stare
„neautorizat”.
8.1.7.3. Protocolul WEP
WEP (Wired Equivalent Privacy – Confidenţialitate Echivalentă celei prin
Cablu) este standardul iniţial de cifrare pentru reţele 802.11, introdus în 1999.
Acesta a fost cândva larg folosit în reţelele fără fir, fiind primul în lista
mijloacelor de securitate a instrumentelor de configurare a ruterelor. WEP
foloseşte o cheie de cifrare (parolă) pe 40 sau 104 biți, ce se introduce manual
la punctele de acces fără fir și staţii și care nu se schimbă (este statică).
Pentru cifrare, WEP foloseşte algoritmul RC4, cunoscut şi ca ARC4 sau
ARCFOUR şi folosit, de asemenea, în protocolul TLS (Transport Layer Security).
RC4 este remarcabil prin simplitate și viteza de lucru, dar are şi puncte slabe,
din care cauză utilizarea lui în sisteme noi nu se recomandă.
Deşi intenţia era de a asigura o confidenţialitate, comparabilă cu cea atinsă
în reţelele prin cablu, deja în 2001 s-a constatat, că parola folosită de WEP
poate fi relativ uşor spartă. În 2003, Alianţa Wi-Fi (Wi-Fi Alliance) a anunţat
înlocuirea WEP cu standardul WPA (Wi-Fi Protected Access – Accesul Wi-Fi
Protejat).
8.1.7.4. Protocolul WPA
Protocolul WPA (Wi-Fi Protected Access – Accesul Wi-Fi Protejat), propus
în 2003, este o soluţie intermediară, pentru înlocuirea celui WEP, până la
finalizarea şi introducerea standardului IEEE 802.11i, elementele obligatorii ale
căruia sunt implementate în WPA2. Important este că WPA poate fi aplicat şi
293
cu plăcile de rețea fără fir, proiectate pentru WEP, la actualizări firmware
minore, ceea ce nu este posibil pentru cifrarea IEEE 802.11i. Modernizarea
necesară a echipamentelor, pentru a suporta IEEE 802.11i, ar fi reţinut
semnificativ îmbunătăţirea mijloacelor de securizare a reţelelor fără fir. Cu
toate acestea, din moment ce modificările necesare la punctele de acces fără
fir sunt mai ample, decât cele necesare la plăcile de rețea, cele mai multe AP-
uri pre-2003 nu au putut fi modernizate pentru a suporta WPA.
Protocolul WPA pune în aplicare un subset de funcţionalităţi ale
standardului IEEE 802.11i, inclusiv protocolul TKIP (Temporal Key Integrity
Protocol – Protocolul de Integritate Temporală a Cheii) şi verificarea integrităţii
mesajelor. Spre deosebire de WEP, care foloseşte o cheie statică (vezi s.
8.1.7.3), TKIP foloseşte o cheie dinamică, pentru fiecare pachet generându-se
o nouă cheie de 128 biți; astfel, TKIP previne mai multe tipuri de atacuri ce au
compromis WEP. TKIP este compatibil cu echipamente WEP.
În ce priveşte verificarea integrităţii mesajelor, aceasta combate captarea,
alterarea şi retransmiterea pachetelor de date de către atacatori, înlocuind
verificarea redundanţei ciclice (Cyclic Redundancy Check – CRC), folosite de
către WEP şi care nu asigură suficient de bine integritatea datelor. Pentru
verificarea integrităţii pachetelor, WPA foloseşte algoritmul Michael, care este
mult mai puternic decât cel CRC, dar nu la fel de puternic ca algoritmul folosit
de WPA2.
Totuşi şi protocolul TKIP a fost parțial spart în 2008.
8.1.7.5. Protocolul WPA2
WPA2, denumit şi RSN (Robust Security Network – Reţea Puternic
Securizată), implementează elementele obligatorii ale standardului IEEE
802.11i, aprobat în 2004. În special, acesta introduce CCMP (Counter Mode
Cipher Block Chaining Message Authentication Code Protocol, Counter Mode
CBC-MAC Protocol sau CCM mode Protocol), un nou mod de cifrare AES
(Advanced Encryption Standard – Standard ce Cifrare Avansată) cu siguranță
puternic. Versiunea implementată în RouterOS se numește AES-CCM.
CCMP foloseşte atât chei, cât şi blocuri de date de 128 biţi şi este mult mai
puternic decât TKIP (vezi s. 8.1.7.4). La chei de 128 biţi, pentru spargere sunt
necesare 264 operaţii.
Din 2006, certificarea WPA2 este obligatorie pentru toate dispozitivele noi
ce poartă marca Wi-Fi, înlocuind WPA.
RSN include două protocoale noi: 4-Way Handshake şi Group Key
Handshake. Pentru stabilirea şi modificarea cheilor de cifrare adecvate,
acestea folosesc serviciile de autentificare şi gestiune a accesului portului,
specificate în standardul IEEE 802.1x.
294
RSN permite crearea doar de asociaţii de reţea puternic securizate (Robust
Security Network Associations – RSNA). Perechi de staţii creează o asociaţie
RSNA, dacă autentificarea sau asocierea între ele se efectuează în baza
protocolului 4-Way Handshake.
Protocolul 4-Way Handshake. Procesul de autentificare implică două
considerente: autentificarea punctului de acces (AP) la stația client (STA) şi
obţinerea cheilor de cifrare a traficului. Schimbul EAP sau WPA2-PSK
preliminar oferă cheia secretă partajată PMK (Pariwise Master Key). Această
cheie este valabilă întreaga sesiune de lucru și trebuie să fie expusă cât mai
puțin posibil. Din această cauză, folosind 4-Way Handshake, se obţine o altă
cheie, numită PTK (Pairwise Transient Key – Cheie Pereche Tranzitorie).
Cheia PTK de 64 octeţi este generată prin concatenarea următoarelor
atribute: PMK, AP nonce (ANonce), STA nonce (SNonce), adresa MAC a AP și
adresa MAC a STA. Rezultatul este apoi pus prin PBKDF2-SHA1 ca funcție hash
criptografică. Aici nonce este un număr arbitrar, folosit doar o singură dată
într-o comunicare criptografică. Acesta este adesea un număr aleatoriu, emis
într-un protocol de autentificare, pentru a combate folosirea comunicărilor
precedente în atacuri repetate. PBKDF2 (Password-Based Key Derivation
Function 2 – Funcţie de Derivare a Cheii Bazată pe Parolă 2) este o funcție de
derivare a cheii, conformă RFC 2898.
Autentificarea include patru etape:
1. AP transmite valoarea ANonce către STA. Staţia client astfel dispune de
toate datele pentru a genera cheia PTK.
2. STA transmite valoarea SNonce către AP împreună cu codul de
autentificare şi integritate a mesajului.
3. AP transmite cheia GTK (Group Transient Key – Cheie de Grup
Tranzitorie), un număr de secvenţă şi codul de autentificare şi integritate
a mesajului. Numărul de secvenţă va fi folosit în următorul cadru, astfel
că STA va putea identifica reluarea transmisiei.
4. STA transmite o confirmare către AP.
Toate mesajele enumerate se transmit ca şi cadre EAPOL-Key. Odată
generată, cheia PTK de 64 biţi se împarte în alte cinci chei, din care trei chei a
câte 16 octeţi şi două chei a câte 8 octeţi (3x16 octeţi + 2x8 octeţi = 64 octeţi).
Fiecare din aceste chei are o destinaţie aparte.
Cheia GTK se foloseşte pentru descifrarea traficului multiadresat şi de
difuzare. Are lungimea de 32 octeţi şi constă dintr-o cheie de 16 octeţi şi două
chei a câte 8 octeţi.
Protocolul Group Key Handshake. Se poate întâmpla să fie necesar de
actualizat cheia GTK, de exemplu din cauza expirării duratei de valabilitate a
acesteia sau din cauza părăsirii reţelei de către un dispozitiv. În acest scop, se
foloseşte protocolul Group Key Handshake, care include două etape:
295
1. AP generează şi transmite noua cheie GTK către fiecare STA a reţelei.
2. STA confirmă, către AP, recepţia noii chei GTK.
8.1.7.6. Autentificarea cu chei pre-partajate PSK
Există două alternative de aplicare a protocoalelor WPA şi WPA2:
 WPA/WPA2 Enterprise, care necesită folosirea unui server special de
autentificare IEEE 802.1x (server RADIUS, vezi s. 8.1.7.2). Se foloseşte, de
obicei, pentru reţele relativ mari şi care necesită un grad avansat de
securizare;
 WPA/WPA2 Personal, cunoscut şi ca WPA/WPA2-PSK, care nu necesită
folosirea vreunui server special de autentificare. Se foloseşte, de obicei,
pentru reţele de oficiu sau la domiciliu, în cazul că acestea nu necesită un
grad avansat de securizare.
În cazul modului de autentificare cu chei pre-partajate (Pre-Shared Key –
PSK), fiecare dispozitiv de reţea fără fir cifrează traficul de date, folosind o
cheie de 256 biţi. O asemenea cheie poate fi introdusă ca un şir din 64 cifre
hexazecimale sau ca o frază-parolă din de la 8 până la 63 caractere ASCII. În
cazul folosirii de caractere ASCII, cheia din 256 biţi se calculează prin aplicarea,
asupra frazei-parolă, a funcţiei PBKDF2 de derivare a cheii cu folosirea SSID şi a
4096 de iteraţii HMAC-SHA1.
Comparativ cu modul WPA/WPA2 Enterprise, WPA/WPA2-PSK are aşa
avantaje ca:
 este mai simplu de implementat, deoarece nu necesită un server RADIUS;
 mijloacele de reţea se poate să nu suporte standardul IEEE 802.11x.
Totodată WPA/WPA2-PSK are şi dezavantaje:
 în cazul că un administrator părăsește compania, trebuie de resetat cheia
PSK;
 dacă un utilizator este compromis, atunci toți utilizatorii pot fi atacaţi;
 PSK nu poate efectua autentificarea la fel de puternic ca şi IEEE 802.1x;
 cheile se învechesc, deoarece nu sunt create dinamic, iar administratorii
nu întotdeauna le modifică suficient de frecvent;
 deoarece WPA2-PSK folosește un tip de cifrare mai avansat, aplicarea lui
necesită o putere de procesare a pachetelor mai mare, decât WPA-PSK.
 deoarece WPA2-PSK este un standard mai nou, poate fi necesară
modernizarea firmware a dispozitivelor.
8.2. RouterOS în reţele 802.11

8.2.1. Funcţionalităţi RouterOS pentru reţele fără fir
RouterOS suportă standardele 802.11 a/b/g/n pentru echipamente
MikroTik ce operează în benzile de 2,4 GHz şi/sau 5 GHz. De asemenea, el
296
dispune de aşa funcţionalităţi adiţionale ca: cifrarea WPA, WEP şi AES; sistem
de distribuire fără fir WDS (Wireless Distribution System); Selectarea dinamică
a frecvenţei (Dynamic Frequency Selection – DFS); Punct de acces virtual
(Virtual Access Point – VAP); protocoale de acces la mediul fără fir proprii
Nstreme şi Nv2 ş.a.
O bună parte din echipamentele de reţea MikroTik conţin şi interfeţe fără
fir (vezi anexele 1 şi 2).
8.2.2. Cartele pentru interfeţe fără fir
RouterOS suportă cartele de reţea pentru interfeţe fără fir (Wireless
Network Interface Card – WNIC) de tip miniPCI, dar şi cartele PCI şi PCIe (vezi s.
3.2), ce operează la frecvenţe în unul sau ambele diapazoane: 2312 - 2499
MHz (banda 2,4 GHz) şi 4920 - 6100 MHz (banda 5 GHz). În ambele cazuri,
diapazoanele de funcţionare sunt mai largi, decât cele prevăzute de
specificaţiile 802.11 (vezi s. 8.1.3). În funcţie de ţară, pentru fiecare diapazon
frecvenţele pot fi diferite. Totodată, folosirea frecvențelor, înafara celor
permise de regulamentele naţionale, poate conduce la amendarea
utilizatorului. RouterOS permite selectarea frecvenţelor în funcţie de ţară.
Există cartele care operează doar în banda de 2,4 GHz sau doar în banda de
5 GHz. Dar există şi cartele care pot opera în ambele aceste benzi. Se asigură
compatibilitatea, de sus în jos, a specificaţiei 802.11g cu cea 802.11b, şi a
specificaţiei 802.11n cu cele 802.11a şi 802.11g (OFDM).
8.2.3. Opţiunile de bază de configurare a WNIC
Opţiunile de bază de configurare a WNIC pot fi vizualizate în fila Wireless a
ferestrei Interface. Pentru aceasta, ce acţionează Wireless/Wireless
Tables/Interfaces. Dacă înregistrarea privind interfaţa wlan1 nu este activă,
atunci ea se activează prin clic pe butonul din bara cu instrumente. Apoi se
execută dublu clic pe înregistrarea wlan1. În fereastra Interface <wlan1> ce se
va afişa se va deschide, prin clic, fila Wireless (fig. 8.5).
Opţiuni de bază. La parametrii de bază de configurare a WNIC pentru un
AP se referă: modul de funcţionare a staţiei (Mode); banda de frecvenţe
(Band); lăţimea de bandă a canalului (Channel Width); frecvenţa de lucru a
canalului (Frequency); numele de identificare a reţelei (SSID); profilul de
securitate (Security Profile). Pentru o staţie client, din acest set se exclud
parametrii Channel Width şi Frequency, configuraţi deja la AP. Esenţa acestor
opţiuni este descrisă mai jos în această secţiune.
După cum a fost deja menţionat, o reţea fără fir se identifică prin numele
SSID. În RouterOS se foloseşte şi numele descriptiv al dispozitivelor fără fir –
Radio Name. Implicit acesta este adresa MAC a interfeţei respective.
Opţiuni implicite. Pentru ceilalţi parametri pot fi păstrate valorile implicite,
dacă nu se dorește altceva în mod special. Autentificarea implicită (Default
297
Autentificate) permite conectarea la AP şi a staţiilor cu adrese MAC ce nu sunt
în lista de acces (vezi s. 8.5.3). Înaintarea implicită (Default Forward) permite
comunicarea directă a staţiilor client una cu alta, prin AP. Dacă acest lucru nu
se doreşte, atunci opţiunea se debifează. Următoarea opţiune, ascunderea
SSID (Hide SSID), apare doar pentru modurile de funcționare a staţiei ap
bridge, bridge şi wds slave. Dacă aceasta este bifată, atunci AP nu va transmite
în mediu numele său SSID şi nici nu va răspunde la cererile cu parametrul SSID
„vid”. Astfel, aceasta poate conduce la neincluderea acestei WLAN în lista
reţelelor fără fir identificate de unele aplicaţii client. Totodată, nu se poate
considera că aceasta va îmbunătăţi semnificativ securitatea reţelei WLAN,
deoarece AP oricum va include SSID în unele alte cadre.
Fig. 8.5. Opţiunile de bază de configurare a WNIC.

Parametrul Scan List poate fi folosit doar de AP cu superlicenţă pentru
RouterOS. El permite specificarea unei liste de frecvenţe, cu care poate lucra
298
AP la transferul de date cu clienţii. Clienţii vor avea posibilitatea să aleagă
frecvenţa de lucru din această listă.
Parametrul Wireless Protocol permite selectarea unei opţiuni privind
protocolul de acces la mediul fără fir. Selectarea unei asemenea opţiuni este
descrisă în s. 8.2.10. La o configurare rapidă a interfeţei, poate fi folosită
valoarea implicită a acesteia,
Parametrul Security Profile permite selectarea profilului de securitate
pentru interfaţă, dacă vreunul este deja configurat. Dacă nici un asemenea
profil încă nu este special configurat, atunci poate fi păstrat cel implicit.
Aspectele securizării WLAN sunt descrise în ss. 8.1.7, 8.6.
Parametrul Bridge Mode permite activarea (enabled) sau dezactivarea
(disabled) regimului de operare a AP, în care acesta acceptă clienți setaţi în
modul station-bridge (vezi s. 8.2.5).
Parametrii Default AP Tx Rate şi Default Client Tx Rate pot fi folosiţi pentru
specificarea vitezei de transfer date predefinite la AP şi, respectiv, staţia client.
Butonul Simple Mode/Advanced Mode din partea de jos a coloanei de
butoane din dreapta a filei Wireless permite afişarea setului de parametri de
configurare de bază (Simple Mode) sau a celui extins (Advanced Mode).
Parametrii adiţionali, ce se afişează la apăsarea butonului Advanced Mode, vor
fi descrişi în s. 8.2.4. Pentru aceştia pot fi folosite valorile implicite, dacă nu
este necesar altceva în mod special.
Butonul Reset Configuration, care se găseşte deasupra celui Simple
Mode/Advanced Mode, permite resetarea configurării WNIC la setările
implicite (default) predefinite de producător.
8.2.4. Instrumente de monitorizare WLAN
RouterOS conţine un set de instrumente de lucru cu interfeţele fără fir,
inclusiv: Scan, Frequency Usage, Alignment, Wireless Sniffer, Snooper ş.a.,
unele din care se accesează prin apăsarea butonului cu acelaşi nume din fila
Wireless a ferestrei interfeţei fără fir respective (fig. 8.5).
8.2.4.1. Utilita Scanner
Utilita Scanner permite vizualizarea unor informaţii privind punctele de
acces ce operează în aria acoperită de interfaţa staţiei, inclusiv: adresa MAC,
Fig. 8.6. Unele informaţii redate de utilita Scanner.
299
SSID, banda, lăţimea canalului, frecvenţa canalului, puterea semnalului,
puterea zgomotului ş.a. (fig. 8.6). În baza SSID, poate fi selectat AP, la care se
doreşte conectarea staţiei, iar, ulterior, şi iniţiată conectarea, apăsând butonul
Connect. RouterOS, în mod automat, va seta: modul de operare în station şi
numele SSID şi frecvenţa AP, conforme cu cele ale AP.
8.2.4.2. Utilita Frequency Usage
Utilita Frequency Usage, procesează pachetele recepţionate de interfaţă şi
calculează procentul de folosire (Usage) a fiecăruia din canale (Frequency) şi,
de asemenea, puterea zgomotului (Noise
Floor) (fig. 8.7). În baza acestor informaţii,
poate fi ales canalul convenabil pentru AP.
De obicei se alege canalul cu cea mai
mică utilizare. În exemplul din figura 8.7,
acesta este cel cu frecvenţa 2427.
8.2.4.3. Utilita Alignment
Utilita Alignment serveşte pentru
orientarea antenelor interfeţelor ce
comunică, astfel ca puterea semnalului să
fie pe cât posibil mai mare. Aceşti
parametri pot fi configuraţi în caseta de
dialog Wireless Alignment Settings
(/Wireless/Wireless Tables/Interfaces,
dublu clic wlan1/Interface <wlan1>/
Fig. 8.7. Alegerea canalului.
Alignment/Alignment (Running)/Wireless
Alignment Settings/Wireless Sniffer Settings), iar informaţiile colectate – în
fereastra Alignment (Running).
8.2.4.4. Utilita Wireless Sniffer
Utilita Wireless Sniffer serveşte pentru monitorizarea pachetelor
recepţionate din mediu de interfaţa fără fir. Este una diferită de cea Packet
Sniffer (vezi s. 7.6.6) şi nu pot opera concomitent.
Procesând pachetele recepţionate, Wireless Sniffer determină anumiţi
parametri, inclusiv banda, frecvenţa, adresa MAC a sursei, puterea semnalului
ş.a. În caseta de dialog Wireless Sniffer Settings (/Wireless/Wireless
Tables/Interfaces, dublu clic wlan1/Interface <wlan1>/Sniff…/Wireless
Sniffer/Settings/Wireless Sniffer Settings), pot fi configuraţi aşa parametri ai
Wireless Sniffer ca (fig. 8.8):
 Only Headers (dacă este bifat – captarea doar a antetelor pachetelor);
 Receive Errors – interfaţa de tranzit a pachetelor;
 Channel Time – timpul canalului (valoarea implicită este 0,2 s);
300
Fig. 8.8. Setarea Wireless Sniffer. Fig. 8.9. Fereastra Wireless Sniffer.
 Memory Limit – capacitatea memoriei tampon, alocate pentru stocarea
datelor capturate (valoarea implicită este 10 KiB);
 File Name – numele fişierului, în care se vor stoca informaţiile despre
pachetele capturate;
 File Limit – dimensiunea fişierului File Name (valoarea implicită este 10
KiB) – se aplică, dacă este specificat File Name, ş.a.
Fig. 8.10. Unele informaţii despre pachetele analizate de Wireless Sniffer.
Butoanele Start şi Stop din fereastra Wireless Sniffer (/Wireless/Wireless

Tables/Interfaces, dublu clic wlan1/Interface <wlan1>/Sniff…/Wireless Sniffer)
servesc pentru iniţierea şi stoparea procesului de monitorizare a pachetelor,
iar cel Sniffed Packets (fig. 8.9) – pentru vizualizarea informaţiilor despre
pachetele capturate. Un exemplu este prezentat în figura 8.10.
8.2.4.4. Utilita Snooper
Monitorul Snooper permite vizualizarea informaţiilor despre transferul de
date de către toate staţiile fără fir şi punctele de access din aria acoperită de
staţie, inclusiv: adresa interfeţelor, SSID, puterea semnalului, % de folosire a
canalelor, viteza de transfer pe fiecare canal, numărul de reţele, numărul de
301
Fig. 8.11. Unele informaţii redate de utilita Snooper.
staţii ş.a. (fig. 8.11). Pe durata operării monitorului Snooper, accesul la Internet
este dezactivat. Informaţiile oferite de Snooper pot fi, de asemenea, folosite la
selectarea canalului convenabil pentru AP.
8.2.5. Modurile de operare a interfeţelor fără fir
Dispozitivele fără fir ale MikroTik pot opera ca clienţi (staţii client), puncte
de acces, punţi fără fir ş.a. În funcţie de destinaţie, RouterOS foloseşte mai
multe moduri de operare a interfeţelor fără fir (Mode, fig. 8.5) şi anume:
alignement-only1, ap-bridge, bridge, nstreme-dual-slave, station, station-
bridge, station-pseudobridge, station-pseudobridge-clone, station-wds şi wds-
slave. Modurile ap-bridge, bridge şi wds-slave se folosesc la punctele de acces,
inclusiv punţi, cu anumite particularităţi. Modurile alignement-only şi nstreme-
dual-slave sunt speciale. Celelalte moduri se folosesc la staţiile client.
Modul ap-bridge este modul de bază de funcţionare a AP. El se foloseşte
de către punctele de acces ce operează în regim de acces „punct-la-
multipunct” (P2MP). Acest mod permite conectarea la AP a până la 2007
clienţi, partajând mediul de transmisie. Este posibilă adăugarea WNIC la un
1 Defisul între cuvinte este introdus doar pentru a specifica faptul că, pentru opţiune, se
are în vedere un nume din mai multe cuvinte. Lipseşte acest defis în instrucţiunile
RouterOS (vezi, de exemplu, opţiunile parametrilor Mode şi Wireless Protocol din fig.
8.5, s. 8.2.3).
302
grup punte şi, de asemenea, puntarea WNIC cu interfeţe de alte tipuri.
Interfeţele, ce operează în modul ap-bridge, suportă WDS.
Modul bridge se foloseşte de către punctele de acces ce operează în regim
de acces „punct-la-punct” (P2P). În acest regim, la AP poate fi conectată doar
o singură staţie. Astfel, dacă şi alte staţii încearcă conectarea la AP, cererile
respective sunt ignorate şi nu se procesează. Totodată, dacă este necesar,
interfaţa unui asemenea AP poate fi adăugată la o punte sau un sistem WDS.
Modul wds-slave se foloseşte de către puncte de acces speciale. El este
similar celui ap bridge, dar adiţional scanează punctul de acces cu acelaşi SSID
(AP primar) şi stabileşte legătura WDS cu acesta; odată cu schimbarea
canalului de către AP-ul primar, în mod automat se schimbă corespunzător
canalul şi la AP ce operează în modul wds-slave. Dacă această legătură se
pierde sau nu poate fi stabilită, atunci continuă scanarea. Dacă parametrul DFS
Mode este setat la opţiunea radar detect (fig. 8.12 din s. 8.2.8), atunci
punctele de acces cu Hide SSID activat nu vor fi regăsite pe parcursul scanării.
Interfaţa fără fir, ce operează în regim client, va căuta un AP acceptabil şi
se va conecta la acesta. Caracterul conectării depinde de tipul modului station
folosit, care poate să difere, în funcţie de aplicaţie şi echipament. Deosebirea
este cauzată, în primul rând, de modalitatea procesării şi înaintării prin
legăturile fără fir a adreselor L2. Acest lucru afectează direct abilitatea legăturii
fără fir de a fi parte a infrastructurii puntate (bridged) L2.
Dacă puntarea L2 deasupra legăturii fără fir nu este necesară, ca în cazul
reţelelor rutate sau comutate MPLS, este oportună folosirea modului de bază
mode = station, care va asigura o eficienţă mai înaltă. Disponibilitatea unui
mod particular station depinde de protocolul fără fir folosit (802.11, ROS
802.11, Nstreme sau Nv2). Cazul 802.11 semnifică o reţea „pură” 802.11, în
sensul folosirii oricărui AP, independent de producător, iar cazul ROS 802.11
semnifică folosirea unui AP ce rulează RouterOS. Nstreme este un protocol cu
interogarea staţiilor (polling), elaborat de MikroTik, incompatibil cu alte
protocoale fără fir, iar Nv2 este versiunea a 2-a a Nstreme (vezi s. 8.2.9). Se
poate întâmpla că o conexiune între staţie şi AP să fie stabilită chiar şi în cazul
că modul particular respectiv nu este suportat pentru un protocol concret.
Modurile station (client), disponibile în RouterOS v5rc11 şi mai sus pentru
orice protocol fără fir, sunt prezentate în tabelul 8.3.
Modul station este modul de bază de operare a staţiilor client. Acesta nu
suportă puntarea L2 pe staţie – încercarea de a include interfaţa staţiei în
punte nu va reuşi. Totodată, dacă nu este necesară puntarea L2 pe staţie (vezi
mai sus în această secţiune), acest mod este cel mai eficient.
Modul station-wds este acelaşi ca şi cel station, dar creează o legătură
WDS cu AP. Este conform 802.11. Se foloseşte atunci, când este necesară
crearea unei legături puntate reale cu AP. La acelaşi AP se pot conecta, în
303
acest mod, şi două sau mai multe staţii client. El funcţionează doar cu AP
RouterOS. Configurarea AP trebuie să permită legături WDS cu staţia client. La
AP, pentru o staţie dată, se creează, în rezultatul negocierii conexiunii, o
interfaţă WDS aparte. Această interfaţă poate fi considerată ca o conexiune
punct-la-punct între AP şi staţia client, indiferent că transmisia se efectuează
de la AP către staţie sau invers. Modul poate fi folosit pentru puntarea L2 şi
oferă mai multe posibilităţi de administrare a AP în baza interfeţelor WDS
separate, de exemplu folosirea i-barierei de punte.
Tabelul 8.3. Modurile station (client) de operare fără fir ale RouterOS
Protocolul
Modul
802.11 ROS 802.11 Nstreme Nv2
station + + + +
station-bridge + + +
station-pseudobridge + + +
station-pseudobridge-clone + + +
station-wds + + +
Modul station-pseudobridge tot permite puntarea L2, ca şi cel station-
wds, dar una limitată şi nu este conform 802.11. El, în ce priveşte conexiunea
fără fir, este acelaşi ca şi cel station, dar adiţional efectuează translatarea
adreselor MAC a traficului de date. Permite puntarea interfeţei. El are un
suport limitat al puntării L2 prin mijloacele unor servicii implementate în
cadrul staţiilor şi anume:
 translatarea adreselor MAC pentru pachete IPv4 – staţia menţine tabelul
de mapare IPv4→MAC şi, la transmisia unui cadru către AP, substituie
adresa MAC sursă cu cea proprie;
 translatarea singulară a adreselor MAC pentru celelalte protocoale –
staţia reţine adresa MAC sursă de la primul cadru non-IPv4 înaintat şi îl
foloseşte la translatarea reversă – această adresă MAC este folosită
pentru înlocuirea adresei MAC destinaţie pentru cadrele recepţionate de
la AP.
Acest mod limitează puntarea L2 la un singur dispozitiv conectat la staţie
(prin mijloacele translatării singulare a adreselor MAC). De asemenea este
posibil doar accesul IPv4 a staţiei din partea AP – pentru celelalte protocoale
se va folosi translatarea singulară a adreselor MAC şi cadrele nu va fi posibil să
fie recepţionate de staţie înseşi. Se recomandă evitarea, pe cât posibil, a
folosirii acestui mod.
Modul station-pseudobridge-clone tot permite puntarea L2, ca şi cel
station-wds, dar una limitată şi nu este conform 802.11. El este același ca şi cel
station-pseudobridge, cu deosebirea că realizează conexiunea la AP folosind
adresa MAC „clonată”. Adresă clonată este adresa configurată în parametrul
304
station-bridge-clone mac (dacă acesta este configurat) sau adresa sursă a
primului cadru înaintat. Aceasta apare, preponderent, pe AP atunci, când
dispozitivul utilizatorului final este conectat la stația conectată la AP
Modul station-bridge este propus de MikroTik, funcționează doar cu AP
RouterOS și oferă suport pentru puntarea L2 transparentă pe staţii
independentă de protocol. AP RouterOS acceptă clienți în modul station-
bridge doar atunci, când el este activat (enabled) utilizând parametrul Bridge
Mode (fig. 8.5). În acest mod, AP menține tabelul de înaintare cu informații
referitoare la ce adrese MAC sunt accesibile pentru fiecare stație. Acest mod
se recomandă de folosit pentru puntarea L2 atunci, când nu este oportun de
folosit modul station-wds.
Modul alignement-only realizează transmisia continuă a semnalului de
către interfaţă. El se foloseşte doar pentru poziţionarea antenelor, în scopul
identificării celei mai bune orientări a acestora.
Modul nstreme-dual-slave permite interfeţei să fie folosită în regimul de
configurare nstreme-dual.
8.2.6. Selectarea benzii şi a lăţimii de bandă a canalului
Benzile de operare ale WLAN 802.11 sunt descrise în s. 8.1.3, iar cartelele
WNIC pentru RouterOS – în s. 8.2.2. În această secţiune doar se concretizează
şi caracterizează opţiunile, pentru benzile de frecvenţe (Band, vezi fig. 8.5), ce
pot fi folosite în RouterOS: 2GHz-b; 2GHz-only-g; 2GHz-b/g; 2GHz-only-n;
2GHz-b/g/n; 5GHz-a; 2GHz-only-n; 2GHz-a/n. Acestea depind de interfaţă şi, la
ruterul RB951-2n, de exemplu, ele sunt: 2GHz-b; 2GHz-only-g; 2GHz-b/g;
2GHz-only-n şi 2GHz-b/g/n. Unele informaţii suplimentare, pentru diverse alte
echipamente, pot fi regăsite în anexele 1, 2 şi s. 3.2.
De banda de frecvenţe utilizată depind ratele de transfer date şi, de
asemenea, frecvenţa şi lăţimea de bandă a canalelor ce pot fi folosite.
Informaţiile respective sunt prezentate în tabelul 8.4.
Tabelul 8.4. Ratele de transfer date posibile, în funcţie de bandă
Rate de transfer date,
Parametru
Banda Mbps
RouterOS
posibile implicită
5GHz; 5GHz-10MHz; 5GHz-5MHz; 5GHz- 6; 9; 12; 18;
basic rate a/g turbo; 2,4GHz-b/g; 2,4GHz-only-g; 2GHz- 24; 36; 48; 6
10MHz, 2GHz-5MHz; 2.4GHz-g-turbo 54
basic rate b 2.4GHz-b, 2.4GHz-b/g, 2.4GHz-only-g 1; 2; 5,5; 11 1
În tabelul 8.4, banda de 5GHz semnifică şi folosirea unui canal standard de
20 MHz, iar benzile 5GHz-turbo şi 2.4GHz-g-turbo – şi folosirea unui canal de
40 MHz. O staţie client se va conecta la AP doar dacă aceasta suportă toate
ratele de bază anunţate de AP pentru banda dată. De asemenea, un AP va
305
stabili o legătură WDS (Wireless Distributed System – Sistem de distribuire fără
fir) doar dacă el suportă toate ratele de bază ale altor AP.
Parametrii basic rate a/g şi basic rate b au efect doar în modul AP de
operare a ruterului şi doar în cazul că este setată valoarea parametrului rate
set.
La selectarea benzii, pot fi utile şi informaţiile tabelului 8.1 din s. 8.1.3.
Unele recomandări, privind selectarea benzii (Band), ar fi:
 dacă traficul de date este relativ mic, atunci nu prea contează opţiunea
aleasă;
 dacă nu se cunoaşte configurarea staţiilor cu care se va efectua schimbul
de date, atunci este oportun de folosit o opţiune cu mai multe
specificaţii, de exemplu cea b/g/n;
 dacă este posibil, de folosit opţiunea cu o singură specificaţie, în funcţie
de caz: a, b, g sau n. Aceasta ar permite reducerea procesărilor şi
creşterea vitezei efective de transfer date. Pentru staţiile reţelelor ESS şi
AP P2P, acest lucru este mai simplu, ceea ce nu se poate afirma pentru
cele ale IBSS, MBSS şi punctele de access P2MP;
 dacă este critică raza de acţiune sau/şi este foarte importantă siguranţa
de funcţionare, atunci de preferat este specificaţia n.
Bineînţeles, importanţi sunt şi alţi factori, inclusiv costurile mijloacelor de
reţea.
În ce priveşte lăţimea de bandă a canalului (Channel Width), sunt posibile
opţiunile: 5MHz, 10MHz, 20/40MHz HT Above, 20/40MHz HT Below, 20 MHz
şi 40MHz Turbo. Opţiunile 20/40MHz HT Above şi 20/40MHz HT Below se
folosesc doar pentru specificaţia 802.11n şi permit folosirea unui canal extins
cu 20 MHz mai sus (Above) sau mai jos (Below) de cei 20 MHz de bază,
obţinându-se astfel un canal de 40 MHz.
Unele orientări, privind selectarea opţiunii pentru parametrul Channel
Width, ar fi:
 dacă sunt puţine informaţii privind condiţiile de funcţionare a WLAN,
atunci se va selecta lăţimea 20MHz;
 dacă canalele de interferenţă se folosesc foarte puţin, atunci se va
selecta lăţimea 20/40MHz HT Above sau 20/40MHz HT Below, ţinând
cont de următoarele: canalul cu cea mai mică folosire va fi cel de bază, iar
cel vecin cu cea mai mică folosire se va folosi ca extensia de sus (Above)
sau de jos (Below), în funcţie de situaţie;
 dacă canalul se foloseşte puţin, iar canalele vecine se folosesc relativ
înalt, atunci se va selecta lăţimea 20MHz;
 dacă traficul de date este mic şi canalele de interferenţă se folosesc
foarte înalt, atunci se va selecta lăţimea 5MHz sau 10MHz.
306
Bineînţeles, la alegerea opţiunilor se va ţine cont de condiţia ca staţiile, cu
care se va efectua schimbul de date, să suporte opţiunea selectată.
8.2.7. Selectarea frecvenţei canalului
Frecvenţele de lucru pentru canalele fără fir sunt descrise în s. 8.1.3.
Selectarea frecvenţei de lucru (Frequency) este necesară doar la configurarea
punctelor de acces şi, de asemenea, a staţiilor reţelelor IBSS şi MBSS. Pentru
staţiile reţelelor ESS se foloseşte frecvenţa de lucru a AP.
La selectarea frecvenţei de lucru este oportun de ţinut cont de
reglementările naţionale în domeniu – reglementări luate în consideraţie în
RouterOS (vezi s. 8.2.9). Utile pot fi, de asemenea, şi considerentele selectării
benzii şi a lăţimii de bandă a canalului, descrise în s. 8.2.6.
Dacă în aria, acoperită de AP, nu sunt şi alte AP, atunci este, de obicei,
oportun de ales unul din canalele 1, 6 sau 11, pentru cazul configurării şi a
altor AP proprii. Dacă însă în aria acoperită de AP sunt şi alte AP, atunci se
alege canalul cu cea mai joasă folosire. Ar fi bine de identificat un diapazon de
frecvenţe de folosire joasă şi lăţime suficientă pentru canalul necesar.
Pentru vizualizarea gradului de folosire a canalelor, se pot folosi
instrumentele Frequency Usage (mai simplu) sau Snooper (o gamă mai bogată
de informaţii), descrise în ss. 8.2.4.2 şi 8.2.4.3.
8.2.8. Opţiunile avansate de configurare a WNIC
Parametrii de configurare avansată a interfeţelor fără fir se afişează
apăsând butonul Advanced Mode din fila Wireless a ferestrei Interface (vezi
fig. 8.5 din s. 8.2.3). La parametrii de configurare de bază (vezi fig. 8.5 din s.
8.2.3) se vor adăuga parametrii: Radio Name, Frequency Mode, Country,
Antenna Gain, DFS Mode, Proprietary Extensions, WMM Support şi Multicast
Helper (fig. 8.12).
Radio Name serveşte pentru specificarea numelui interfeţei, valoarea
implicită fiind adresa MAC a acesteia. De obicei este mai comod de lucrat cu
un nume sugestiv.
Frequency Mode setează modul în care se stabileşte frecvenţa de operare a
interfeţei, având trei opţiuni: manual tx power, regulatory domain şi
superchannel. Opţiunea regulatory domain presupune conformarea
reglementărilor naţionale privind canalele de folosit şi puterea semnalului;
este folosită împreună cu parametrul Country. Modul manual tx power
(implicit) este similar celui regulatory domain, cu deosebirea că nu se limitează
puterea semnalului. Modul superchannel permite toate canalele suportate de
interfaţă. Lista tuturor canalelor disponibile, pentru fiecare bandă, inclusiv a
celor interzise de reglementările naţionale, poate fi afişată, aplicând comanda:
307
/wireless info print
Fig. 8.12. Opţiunile avansate de setare a WNIC.
Country serveşte pentru selectarea ţării, în care se instalează WLAN, atunci

când se doreşte respectarea reglementărilor naţionale privind benzile
disponibile, frecvenţele de folosit şi puterea permisă a semnalului pentru
fiecare frecvenţă. Specifică, de asemenea, valoarea implicită a listei de scanare
(scan-list). Valoarea no_country_set corespunde setului de canale a FCC
(Federal Communications Commission) – Comisia Federală de Comunicaţii a
SUA.
Antenna Gain specifică puterea de recepţie a antenei.
DFS (Dynamic Frequency Selection) Mode are efect doar în modul AP şi
setează modul de selectare dinamică a frecvenţei, având trei opţiuni: none,
no-radar-detect şi radar-detect. Opţiunea none (implicit) dezactivează DFS.
Modul no-radar-detect selectează, din scan-list, canalul cu cel mai mic număr
308
de reţele detectate; în modul wds-slave, opţiunea nu are efect. Modul radar-
detect selectează canalul cu cel mai mic număr de reţele detectate şi, dacă pe
acest canal timp de 60 s nu este detectat nici un radar, atunci îl foloseşte; în
caz contrar, selectează un alt canal.
Proprietary Extensions stabileşte tipul informaţiilor de serviciu de introdus
în cadrele de gestiune şi are două opţiuni: pre-2.9.25 şi post-2.9.25. Opţiunea
pre-2.9.25 specifică folosirea de informaţii de serviciu de tip mai vechi; chiar
dacă şi se asigură interoperabilitatea cu versiuni mai noi de RouterOS,
interoperarea cu unii clienţi poate fi imposibilă. Opţiunea post-2.9.25
(implicită) specifică folosirea de informaţii de serviciu standard compatibile cu
clienţi fără fir mai noi.
WMM Support serveşte pentru setarea folosirii priorităţilor, la transferul
de date multimedia prin interfaţă. El aplică patru clase de prioritate.
Multicast Helper stabileşte modul de transmitere a pachetelor
multiadresat, având trei opţiuni: disabled, full şi default. Opţiunea disabled
realizează transmiterea pachetelor multiadresat cu adresa MAC destinaţie
multiadresat. În cazul opţiunii full, înainte de transmiterea pachetelor,
adresele MAC ale pachetelor multiadresat sunt modificate în adrese MAC
monoadresat. Opţiunea default este setată la realizarea valorii disabled; în
realizările viitoare ale RouterOS această valoare poate fi modificată.
8.2.9. Conformarea reglementărilor naţionale în domeniu
La selectarea frecvenţei de lucru a canalului fără fir pentru WLAN, trebuie
respectate reglementările naţionale în domeniu. Aceste reglementări sunt
implementate în RouterOS, ceea ce permite configurarea respectivă a WNIC.
În acest scop servesc parametrii Country şi Frequency Mode: în cel Country se
selectează ţara, iar în cel Frequency Mode – opţiunea regulatory domain (fig.
8.12).
8.2.10. Selectarea protocolului de acces la mediul fără fir
RouterOS suportă protocoalele de acces la mediul fără fir ale 802.11
(CSMA/CA cu anumite concretizări, completări şi dezvoltări – în continuare
CSMA/CA) şi cele proprietare ale MikroTik – Nstreme, Nstreme Dual şi Nv2.
Protocolul CSMA/CA este descris în standardul IEEE 802.11 şi diverse alte
surse. Cele Nstreme, Nstreme Dual şi Nv2 sunt descrise, în linii mari, în cele ce
urmează în această secţiune. Ulterior, sunt descrise opţiunile aferente de
configurare a interfeţelor fără fir.
Protocolul Nstreme este elaborat de MikroTik, pentru a depăşi unele
constrângeri ale celui CSMA/CA şi a creşte productivitatea legăturilor fără fir
P2P şi P2MP în anumite condiţii. Poate fi folosit doar dacă acesta este la
ambele capete ale legăturii. Nstreme efectuează compresia de date, foloseşte
309
interogarea staţiilor şi nu limitează distanţa transmisiei. De obicei, Nstreme
creşte debitul de date, dar şi, puţin, reţinerea medie a pachetelor.
Protocolul Nstreme Dual, la fiecare din cele două capete ale legăturii
punct-la-punct, folosește două cartele de interfață fără fir, pentru a crea o
legătură fără fir duplex punct-la-punct. În acest scop, aceste două cartele
trebuie să fie setate la modul Nstreme-Dual-Slave, operând, astfel, în regimul
simplex, deşi fiecare din ele poate fi setată ca una de transmisie (Tx) sau ca
una de recepţie (Rx). În baza acestor două interfeţe, ce operează în regim
simplex, ulterior se creează o nouă interfaţă, ce operează în regim duplex.
Evident, la fiecare din capetele legăturii punct-la-punct, o cartelă trebuie
doar să transmită, iar alta – doar să recepţioneze semnale la o frecvenţă
diferită de cea de transmisie. Bineînţeles, frecvenţa, la care un nod transmite,
trebuie să fie egală cu cea, la care celălalt nod al legăturii punct-la-punct
recepţionează semnalul. Pentru a reduce interferenţele, diferenţa dintre
frecvenţa de transmisie Tx Freq şi cea de recepţie Rx Freq trebuie să fie de cel
puţin 200 MHz.
Totodată, pentru canalele Tx şi Rx pot fi folosite diferite benzi, din cele
2GHz-b, 2GHz-g, 2GHz-n, 5GHz-a şi 5GHz-n; de exemplu, pentru Tx – cea 2GHz-
g, iar pentru Rx – cea 2GHz-b.
De menţionat, de asemenea, că pentru interfeţe fără fir duplex nu poate fi
folosit WDS.
Configurarea interfețelor fără fir duplex, folosind Nstreme Dual, este
descrisă în s. 8.8.
Protocolul Nv2 este versiunea a 2-a a Nstreme. Este un protocol TDMA
(Time Division Multiple Access – multiacces cu divizarea în timp), implementat
în RouterOS începând cu versiunea 5. Nv2 este imun faţă de problema staţiei
ascunse (vezi s. 8.1.2), creşte debitul de date, reduce durata reţinerii
pachetelor, îndeosebi în reţele P2MP, şi nu limitează distanţa transmisiei.
Nv2 poate fi folosit doar dacă acesta este la ambele capete ale legăturii; nu
este compatibil nici cu Nstreme. Există anumite cerinţe şi către WNIC. La
01.12.2013, el este suportat doar de cartele Atheros, începând cu cele AR5212
şi mai sus.
În linii mari, protocolul operează în modul următor. Timpul este divizat în
„perioade” de dimensiune fixă, care, la rândul lor, se împart dinamic în
porţiunile descendentă (date ce se transmit de la AP către staţia client) şi
ascendentă (date ce se transmit de la staţia client către AP), în baza stării cozii
la AP şi clienţi. În continuare, porţiunea ascendentă este împărţită între clienţii
conectaţi, în funcţie de cerinţele lor către viteza de transmisie.
La începutul fiecărei perioade, AP difuzează clienţilor programul de
transmisie, care specifică ora şi durata posibilă a transmisiei pentru fiecare din
ei. Clienţii transmit date, unul după altul, conform acestui program.
310
Pentru a permite conectarea unor clienţi noi, AP atribuie periodic, în cadrul
legăturii ascendente, timp pentru un client "nespecificat". Acest interval de
timp este folosit de noul client pentru iniţierea înregistrării la AP. Apoi AP
estimează durata propagării semnalului între AP şi client şi include clientul în
lista clienţilor înregistraţi.
Nv2 implementează selecția dinamică a vitezei de transfer date, în funcţie
de client. De asemenea, în scopul sporirii QoS, Nv2 implementează cozi cu un
număr variabil de priorităţi.
Nv2 suportă cel mult 511 clienţi.
Principalele deosebiri ale Nv2 de 802.11 sunt:
 AP programează accesul la mediu a staţiilor, ceea ce elimină problema
staţiei ascunse şi permite implementarea unei politici centralizate de
acces la mediu. El controlează timpul folosit de fiecare client şi, în locul
accesului concurent al clienţilor la mediu, poate aloca clienţilor timp
conform unei anumite politici;
 întârzierea de propagare a informaţiilor de serviciu redusă, deoarece nu
se folosesc cadrele de confirmare a recepţiei (ACK/NACK). Aceasta
permite creşterea debitului de transfer date, îndeosebi la distanţe relativ
mari;
 informaţiile de serviciu reduse, datorită implementării agregării şi
fragmentării cadrelor, ceea ce permite creşterea folosirii utile a mediului;
 nu se limitează distanţa;
 nu există penalizări cauzate de distanţe mari.
Principalele deosebiri ale Nv2 de Nstreme sunt:
 informaţiile de serviciu pentru interogări (polling) reduse – în loc să
interogheze fiece client, AP Nv2 difuzează tuturor clienţilor concomitent
programul de transmisie, adică realizează o „interogare de grup”. Aceasta
permite creșterea debitului de transfer date, îndeosebi în reţele P2MP;
 întârzierea de propagare a informaţiilor de serviciu redusă, deoarece se
interoghează nu fiece client în parte, ci toţi concomitent. Aceasta
permite creșterea debitului de transfer date, îndeosebi în reţele P2MP;
 un control mai avansat al reţinerii pachetelor – informaţii de serviciu
reduse, dimensiunea reglabilă a perioadelor de timp ş.a.
Opţiunile RouterOS de selectare a protocolului de acces la mediul fără fir
(Wireless Protocol) sunt prezentate în tabelul 8.5.
Unele orientări, privind selectarea opţiunii pentru parametrul Wireless
Protocol la configurarea AP, ar fi:
 dacă mijloacele de reţea suportă Nv2, atunci de selectat nv2;
 dacă sunt necesare distanţe mai mari, decât cele admise la 802.11, şi la
staţiile client se foloseşte nstreme, atunci de selectat nstreme;
 în celelalte cazuri poate fi folosit any, nstreme sau 802.11.
311
Tabelul 8.5. Opţiunile parametrului Wireless Protocol şi esenţa folosirii lor [1]
Valoarea AP Clientul
802.11 stabilirea unei reţele conectarea doar la reţele 802.11
802.11
any stabilirea unei reţele scanarea tuturor reţelelor ce se potrivesc,
Nstreme sau 802.11 fără a ţine cont de protocol; conectarea
în baza vechii setări folosind protocolul reţelei alese
nstreme
nstreme stabilirea unei reţele conectarea doar la reţele Nstreme
Nstreme
nv2 stabilirea unei reţele conectarea doar la reţele Nv2
Nv2
nv2 stabilirea unei reţele scanarea reţelelor Nv2 şi dacă vreuna se
nstreme Nv2 potriveşte, atunci conectarea. În caz contrar,
scanarea reţelelor Nstreme şi dacă vreuna se
potriveşte, atunci conectarea
nv2 stabilirea unei reţele scanarea reţelelor Nv2 şi dacă vreuna se
nstreme Nv2 potriveşte, atunci conectarea. În caz contrar,
802.11 scanarea reţelelor Nstreme şi dacă vreuna se
potriveşte, atunci conectarea. În caz contrar,
scanarea reţelelor 802.11 şi dacă vreuna se
potriveşte, atunci conectarea
unspecified ca la valoarea any conectarea la reţele Nstreme sau 802.11 în
baza vechii setări nstreme
Bineînţeles, asupra alegerii opţiunii parametrului Wireless Protocol poate
să înrâurească condiţiile alegerii benzii şi lăţimii de bandă a canalului şi, de
asemenea, a frecvenţei canalului, descrise în s. 8.2.6 şi 8.2.7.
Unele orientări, privind selectarea opţiunii pentru parametrul Wireless
Protocol la configurarea staţiilor client, ar fi:
 dacă staţia client trebuie să se conecteze la o anumită reţea WLAN, caz
frecvent întâlnit, atunci la staţie se va seta opţiunea folosită în acea
reţea, dacă ea se cunoaşte. Dacă opţiunea folosită în reţea nu se
cunoaşte, atunci se va selecta opţiunea any;
 dacă în zonă sunt mai multe WLAN şi nu se cere ca staţia să se conecteze
la una anume din ele, atunci se va selecta opţiunea nv2 nstreme 802.11.
Aspectele configurării protocoalelor Nstreme şi Nv2 sunt descrise în s.
8.8.1, iar a celui Nstreme Dual – în s. 8.8.2.
8.3. Conectarea fără fir la AP a unei LAN cablate

8.3.1. Conexiunea de creat
Fie o reţea locală, staţiile căreia sunt conectate prin cablu la un ruter,
denumit ruterul utilizatorului. Prin acest ruter este necesar de realizat o
312
conexiune la un ruter-AP, conectat la Internet. Astfel, ruterul utilizatorului va
fi, pentru AP, o staţie client. Conexiunea se va realiza între interfeţele wlan1
ale celor două rutere. O conexiune de aşa gen a fost deja configurată în s. 4.2.
În s. 8.3.2, 8.3.3, configurările respective se vor relua cu unele dezvoltări.
Se va considera că la calculatorul utilizatorului, conectat la interfaţa ether2
a ruterului-staţie client, configurările necesare ale cartelei de reţea Ethernet
sunt deja efectuate şi corespund celor din s. 4.2.2, adică:
 IP address: 192.168.x.1
 Subnet mask: 255.255.255.0
 Default gateway: 192.168.x.254
 Preferred DNS Server: 192.168.x.254
unde x este numărul ruterului utilizatorului.
Dacă ambele rutere nu sunt încă configurate, atunci mai întâi trebuie de
configurat punctul de acces, de care depind mai multe lucruri, inclusiv
alegerea reuşită a canalului. Se va considera, totuşi, că ruterul-AP este deja
configurat şi are parametrii: SSID – APprof, adresa IP a interfeţei ether1 –
172.20.25.49, adresa IP a interfeţei wlan1 – 192.168.1.1, adresa MAC a
interfeţei wlan1 – D4:CA:6D:2F:9E:47, banda – 2GHz-B/G/N.
În configurări, pentru ruterul-staţie client se vor seta parametrii: Radio
Name – x_prenume, adresa IP a interfeţei ether2 – 192.168.20.254/24, adresa
IP a interfeţei wlan1– privată obţinută prin DHCP de la AP, regula masquerade
se va configura pe interfaţa wlan1. Totodată, frecvenţa canalului trebuie să fie
una reglementară, iar puterea semnalului – de putere pe cât posibil mai mare.
8.3.2. Configurarea minimă a ruterului-staţie client
Fie AP este deja configurat. Dacă interfaţa ether2 a ruterului-staţie client
încă nu este configurată, atunci accesul de la calculatorul utilizatorului la ruter
prin WinBox se va efectua, folosind adresa MAC a ether2, iar ulterior se va ieşi
din RouterOS şi acesta se va accesa din nou, folosind adresa IP respectivă (vezi
s. 4.1.4.2).
Exemplul 8.1. Ruterul-staţie client poate fi configurat în modul următor:
1. Se atribuie adresa IP 192.168.20.254/24 interfeţei ether2, acţionând
/IP/Addresses/Address List, + /New Address, Address –
192.168.20.254/24, Network – 192.168.20.0/24, Interface – ether2/OK.
2. Se verifică conexiunea PC-ruter, lansând comanda ping 192.168.20.1 din
linia de comandă a ferestrei Terminal (/New Terminal).
3. Se va ieşi din WinBox şi ruterul se va accesa din nou, folosind adresa IP a
interfeţei ether2 (vezi s. 4.2.3).
4. Se configurează interfaţa wlan1. Un set redus de parametri de configurat
este: modul de operare (Mode), banda (Band), SSID şi protocolul fără fir
(Wireless Protocol). Dacă SSID nu se cunoaşte, atunci se foloseşte scanarea
313
mediului (Scan); dacă SSID se cunoaşte, atunci acesta se specifică şi
scanarea nu este necesară. Protocolul fără fir poate fi folosit cel implicit.
Astfel, se acţionează /Wireless/Wireless Tables/Interfaces, (dacă
înregistrarea privind interfaţa wlan1 nu este activă atunci ea se activează
prin clic pe butonul din bara cu instrumente), dublu clic wlan1/Interface
<wlan1>/Wireless, Mode – station, Band – 2GHz-B/G/N, SSID – APprof
(Scan/Scanner/SSID – APprof, Connect)/OK (vezi s. 4.2.4). Dacă accesul la
AP nu este securizat, atunci ruterul-staţie client se va conecta la AP.
Aspectele de securizare sunt descrise în ss. 8.1.7, 8.6.
5. Se atribuie interfeţei wlan1 o adresă IP privată în mod dinamic: /IP/DHCP
client, +/New DHCP client/DHCP, Interface – wlan1/OK (vezi s. 4.2.4).
6. Se configurează DNS pe ruterul-staţie client, acţionând /IP/DNS/DNS
Settings, Servers – 192.168.1.1, Allow Remote Requests – bifare, OK.
7. Se configurează regula masquerade pe ruterul-staţie client: /IP/Firewall/
NAT, +/New NAT Rule/fila General, Chain – srcnat, Out Interface –
wlan1/fila Action, Action – masquerade/OK.
Astfel, ruterul staţie-client este configurat: interfaţa ether2 – pentru
conectarea staţiilor reţelei locale (PC, etc.) şi interfaţa wlan1 – pentru
conectarea la AP. Faptul conectării ruterului-staţie client la AP se confirmă prin
apariţia caracterului R în prima coloană a înregistrării ce ţine de wlan1 în fila
Interfaces a ferestrei Wireless Tables (/Wireless/Wireless Tables/Interfaces).
8.3.3. Configurarea adiţională a ruterului folosind Connect List
Lista de conectare (Connect List) conţine reguli, care specifică ruterului-
staţie client, la care AP şi cum de conectat. Aceasta permite depăşirea unor
situaţii nedorite.
De exemplu, conectarea ruterului-staţie client la un anumit AP, conform
configurării descrise în s. 8.3.2, se bazează pe specificarea identificatorului
SSID al acestuia (WLAN). Dacă, la configurarea staţiei, SSID nu se specifică,
atunci staţia se va conecta la punctul de acces cu cel mai puternic semnal. Mai
mult ca atât, acelaşi efect va fi şi în cazul că în zona de acoperire respectivă
funcţionează mai multe AP cu acelaşi SSID. Totodată, accesul la un asemenea
AP ar putea fi reglementat.
Pentru ca ruterul-staţie client să se
conecteze la AP-ul preferat, trebuie să fie
debifat parametrul Default Autentificate
(/Wireless/Wireless Tables/Connection
List, +/Interface <wlan1>/Wireless,
Default Autentificate – debifare, vezi fig.
8.5) sau să fie creată o regulă drop
Fig. 8.13. Crearea unei reguli
specială. Esenţa parametrului Default Connect List.
314
Autentificate este descrisă în s. 8.5.1.
În scopul creării unei reguli de conectare a ruterului-staţie client la AP, se
acţionează: /Wireless/Wireless Tables/Connection List, +/New Station
Connect Rule, Interface – wlan1, MAC Address - D4:CA:6D:2F:9E:47, Connect –
bifare, SSID – IPprof (fig. 8.13). Astfel, la conectare se va folosi nu doar numele
SSID ci şi adresa MAC a AP. Totodată, dacă în regula de conectare a ruterului-
staţie client se specifică doar numele SSID, atunci staţia se va conecta la orice
AP cu acest SSID.
De menţionat că, în caseta de dialog New Station Connect Rule, pot fi setaţi
şi alţi parametri de restricţionare a conectării ruterului-staţie client la AP,
inclusiv: diapazonul puterii acceptate a semnalului (Signal Strength Range),
Protocolul fără fir (Wireless Protocol) de folosit; profilul de securitate (Security
Profile). În ce priveşte puterea semnalului, este oportun de ţinut cont de
categoriile de semnale, descrise în s. 8.1.1; unele sugestii sunt descrise în s.
8.4.4.
Pentru a seta şi numele interfeţei (Radio Name), se acţionează
/Wireless/Wireless Tables/Interfaces, dublu clic pe înregistrarea wlan1/
Interface <wlan1>/Wireless/dacă modul avansat de configurare (vezi s. 8.2.8)
nu este activat, se apasă butonul Advanced Mode/Radio Name – x_prenume,
OK.
Sarcina practică 8.1. La datele inițiale specificate în s. 8.3.1, de configurat
ruterul utilizatorului ca staţie client, conform acţiunilor descrise în s. 8.3.2 şi
mai sus în această secţiune.
8.4. Crearea unei reţele iBSS simple

8.4.1. Reţeaua iBSS de creat
Fie este necesar de creat o reţea ESS cu un singur AP, adică o reţea ESS
dintr-un singur iBSS. Într-o asemenea reţea staţiile comunică între ele fără fir
prin intermediul unui AP (fig. 8.14).
Se va considera că ruterul-AP se
conectează la Internet (WAN) prin
interfaţa ether1, iar pentru conectarea
AP
fără fir a staţiilor la AP se foloseşte
interfaţa wlan1. De asemenea, un PC
se conectează la interfaţa ether2 a AP;
configurările necesare ale cartelei de Staţii fără fir
reţea Ethernet a PC sunt deja
efectuate şi corespund celor din s.
8.3.1. Fig. 8.14. Reţea fără fir ESS = iBSS.
315
În configurări, pentru AP se vor seta parametrii: SSID – APprof, numele
interfeţei wlan1 (Radio Name) – 20_ion, adresa IP a interfeţei ether1 –
172.20.25.49, adresa IP a interfeţei ether2 – 192.168.20.254/24, adresa IP a
interfeţei wlan1 – 192.168.1.1, banda – 2GHz-B/G/N, regula masquerade se va
configura pe interfaţa wlan1. Staţiilor, ce se vor conecta la interfaţa wlan1, li
se vor atribui adrese IP private, în mod dinamic, de către serverul DHCP.
Totodată, frecvenţa canalului trebuie să fie una reglementară, iar puterea
semnalului – de putere pe cât posibil mai mare.
8.4.2. Configurarea minimă a ruterului-punct de acces
Exemplul 8.2. Pentru configurarea ruterului-AP, ţinând cont de aspectele
descrise în ss. 8.2.4-8.2.7 şi sarcina definită în s. 8.4.1, se poate proceda în
modul următor:
1. Se atribuie adresa IP 172.20.25.49/16 interfeţei ether1, adresa IP
192.168.x.254/24 interfeţei ether2, şi adresa IP 192.168.1.1 interfeţei
wlan1, iar, ulterior RouterOS se va accesa folosind adresa IP (vezi, de
exemplu paşii 1-3 din s. 8.3.2).
2. Se configurează, pe interfaţa wlan1, serverul DHCP pentru subreţeaua
192.168.1.0/24 (vezi sarcina 7.2 din s. 7.2.2.1).
3. Se accesează modul avansat de configurare /Wireless/Wireless Tables/
Interfaces, (dacă înregistrarea privind interfaţa wlan1, nu este activată,
atunci ea se activează – vezi s. 8.3.2.1), dublu clic wlan1/Interface <wlan1>/
Wireless/Advanced Mode.
3. În modul avansat al filei Wireless (fig. 8.12), se setează modul de operare
(Mode), banda (Band), reglementările naţionale (Frequency Mode şi
Country), SSID şi numele interfeţei (Radio Name): Mode – ap bridge, Band –
2GHz-B/G/N, Frequency Mode – regulatory domain, SSID – APprof, Radio
Name – x_prenume, Country – moldova. Valorile pentru parametrii Band şi
Channel Width pot fi folosite cele implicite, dacă nu sunt rezonabile alte
valori. Parametrii Frequency Mode şi Country sunt setaţi la opţiunile de
conformare reglementărilor naţionale ale Republicii Moldova.
4. Se selectează frecvenţa de lucru a AP conform s. 8.2.7. Dacă în aria AP nu
sunt şi alte AP, atunci este, de obicei, oportun de ales unul din canalele 1, 6
sau 11, pentru cazul configurării şi a altor AP proprii. Pentru vizualizarea
folosirii canalelor, se apasă butonul Freq. Usage… Se va afişa fereastra Freg.
Usage (Running), în care în coloana Usage este dată folosirea canalelor, în
%. Se va identifica canalul cu cea mai joasă folosire (în fig. 8.7 – cel 2427),
care, de regulă, şi se va selecta în câmpul Frequency al filei Wireless.
Informaţii mai bogate privind canalele folosite (adresa interfeţelor, SSID,
puterea semnalului, % de folosire, viteza de transfer, numărul de reţele,
numărul de staţii ş.a., fig. 8.11) prezintă utilita Snooper, care se lansează
apăsând butonul cu acelaşi nume din fila Wireless.
316
5. Valorile celorlalţi parametri, la o configurare simplă, pot fi păstrate cele
implicite, inclusiv profilul de securitate (Security Profile). Dacă se doreşte
acceptarea configurărilor deja definite, se apasă butonul OK.
8.4.3. Tabelul interfeţelor fără fir conectate la ruter
Tabelul interfeţelor fără fir (Registration Table) conţine diverse informaţii
privind interfeţele fără fir conectate la cea a ruterului, inclusiv: numele (Radio
Name); adresa MAC a interfeţei fără fir (MAC Address); este sau nu staţia un
AP (AP); metoda de autentificare folosită (Authentification Type); se foloseşte
sau nu compresia de date la transmisie (Compression); este activat sau nu
regimul WMM (WMM Enabled); algoritmul de cifrare folosit (Encryption);
versiunea RouterOS (RouterOS Version); puterea medie a semnalului
recepţionat de AP (Signal Strengths); foloseşte sau nu clientul wds (WDS); rata
limită de transmisie a clientului (Client Tx Limit), rata de transmisie şi rata de
recepţie (Tx/Rx Rate) ş.a.
Pentru a accesa informaţia din acest tabel, se acţionează Wireless/Wireless
Tables/Registration (fig. 8.15).
Fig. 8.15. Vizualizarea interfeţelor fără fir conectate la cea wlan1.

Sarcina practică 8.2. De configurat ruterul utilizatorului ca punct de acces,
conform acţiunilor descrise mai sus în această secţiune, la următoarele date
inițiale: SSID – APx_prenume, numele interfeţei wlan1 (Radio Name) –
x_prenume, adresa IP a interfeţei ether1 – adresa IP a calculatorului
utilizatorului, adresa IP a interfeţei ether2 – 192.168.x.254/24, adresa IP a
interfeţei wlan1 – 192.168.100+x.1, banda – 2GHz-B/G/N, regula masquerade
se va configura pe interfaţa wlan1. Staţiilor, ce se vor conecta la interfaţa
wlan1, li se vor atribui adrese IP private, în mod dinamic, de către serverul
DHCP. Totodată, frecvenţa canalului trebuie să fie una reglementară, iar
puterea semnalului – de putere pe cât posibil mai mare.
8.4.4. Conectarea fără fir a unei staţii la AP
Conectarea fără fir a unei staţii la AP se efectuează prin dublu clic pe
numele SSID al AP (WLAN), din lista de nume de reţea identificate de către
interfaţa fără fir a staţiei, şi specificarea numelui de utilizator şi al parolei, dacă
asemenea informaţii se solicită.
317
8.4.5. Configurarea puterii semnalului de acces la AP
La configurarea punctelor de acces este oportun de a nu permite
conectarea staţiilor cu semnal slab (vezi s. 8.1.3), adică mai slab de -85 dBm.
Faptul se lămureşte prin aceea că staţiile cu semnal slab vor reduce eficienţa
transferului de date prin AP şi pentru alte staţii, din cauza retransmiterii
multiple de pachete recepţionate cu erori.
Configurarea respectivă a AP se efectuează prin crearea unei reguli de
conectare a staţiilor, în fila Connect List: /IP/Wireless/Wireless Tables/Connect
List, +/New Station Connect Rule, Signal Strength Range – -85..120 (fig. 8.16
din s. 8.5.3).
La configurarea AP sunt importante şi multe alte aspecte, inclusiv cele
privind filtrarea adreselor MAC ale staţiilor, cifrarea datelor în scopuri de
securizare, setarea protocoalelor de acces la mediul fără fir, abordate în ss.
8.5-8.8.
8.5. Gestiunea ataşării staţiilor la AP în baza

adreselor MAC
O cale relativ simplă, dar relativ uşor de ocolit de către hackerii
experimentaţi, de securizare a ataşării staţiilor client la AP (WLAN) pentru
transferuri de date, constă în folosirea adreselor MAC, denumită filtrare MAC
(MAC filtering). Folosind filtrarea MAC, atât AP poate restricţiona ataşarea
staţiilor, cât şi staţiile pot selecta un anume AP, pentru a se asocia (înregistra)
la WLAN. În acest scop, respectiv, la AP se foloseşte Lista de acces (Access List),
iar la staţiile client – Lista de conectare (Connect List), descrise în ss. 8.5.3,
8.5.4. Dar, mai întâi, în s. 8.5.1 este descris parametrul de autentificare
implicită (Default Autenticate), care complementează folosirea regulilor acestor
două liste de filtrare MAC, iar în s. 8.5.2 – parametrul de înaintare implicită
(Default Forward).
8.5.1. Autentificarea implicită a staţiilor
Parametrul de autentificare implicită (Default Autenticate) are semnificaţie
aparte pentru AP şi staţiile client.
La AP, parametrul Default Autenticate este folosit, în procesul iniţierii
procedurii de asociere a staţiei, doar pentru clienţii ce nu corespund nici uneia
din regulile de asociere a staţiilor din Access List (vezi s. 8.5.2) şi are valoarea
parametrului Autentication din Access List (vezi s. 8.5.2). În stare activată
(bifat, vezi fig. 8.5 din s. 8.2.3), către solicitarea de asociere a clientului, se
aplică procedura de autentificare, specificată în profilul de securitate (Security
Profile) al AP. În cazul stării dezactivate (nebifat), clientului i se refuză asocierea.
318
La staţia client, parametrul Default Autenticate este folosit, în procesul
iniţierii procedurii de conectare a staţiei, doar pentru punctele de acces ce nu
corespund nici uneia din regulile de conectare din Connect List (vezi s. 8.5.4) şi
are valoarea parametrului Connect din Connect List (vezi s. 8.5.4). În stare
activată (bifat, vezi fig. 8.5 din s. 8.2.3), staţia client va selecta, pentru
asociere, punctul de acces cu cel mai bun semnal şi securitate compatibilă. În
cazul stării dezactivate (nebifat), clientul nu va solicita conectarea nici la un AP.
Implicit, parametrul Default Autenticate este în stare activată. Dacă este
necesară dezactivarea lui, atunci se acţionează /Wireless/Wireless Tables/
Interfaces/dublu clic wlan1/Interface <wlan1>/Wireless, Default Autenticate -
debifare).
8.5.2. Înaintarea implicită a pachetelor
Parametrul de înaintare implicită (Default Forward) se foloseşte doar de
către AP şi doar pentru clienţii ce nu corespund nici uneia din regulile de
asociere a staţiilor din Access List; el are valoarea parametrului Forwarding din
Access List (vezi s. 8.5.3). În stare activată (bifat, vezi fig. 8.5 din s. 8.2.3),
clientul poate trimite cadre către alte staţii asociate aceluiaşi AP. În cazul stării
dezactivate (nebifat), clientul nu poate trimite cadre către alte staţii asociate
aceluiaşi AP, dar le poate trimite către staţii asociate unui alt AP.
Implicit, parametrul Default Forward este în stare activată. Dacă este
necesară dezactivarea lui, adică să nu se permită comunicarea între clienţii, ce
nu corespund nici uneia din regulile de asociere a staţiilor din Access List,
atunci se acţionează /Wireless/Wireless Tables/Interfaces/dublu clic wlan1/
Interface <wlan1>/Wireless, Default Forward - debifare).
8.5.3. Lista de acces a AP de către staţii
Lista de acces (Access List) este folosită de către AP, pentru a restricţiona
conexiunile admise cu alte staţii şi, de asemenea, pentru a gestiona parametrii
conexiunilor. Operează, în baza unor reguli, în modul următor:
 regulile Listei de acces sunt verificate secvenţial, începând cu prima;
 regulile dezactivate sunt ignorate;
 se aplică doar prima regulă ce se potriveşte;
 dacă nu se potriveşte nici o regulă pentru conectarea staţiei client, atunci
sunt folosite valorile implicite ale configurării interfeţei fără fir;
 dacă staţia client se potriveşte regulii, care are valoarea no a
parametrului authentication (opţiunea Authentication nu este bifată, fig.
8.14), atunci stabilirea conexiunii, solicitate de staţia client, este respinsă.
Regulile Listei de acces pot include aşa parametri ca:
MAC Address – adresa MAC a clientului. Valoarea implicită este
00:00:00:00:00:00, care este acceptată;
319
Interface – o interfaţă fără fir a AP anume. Valoarea implicită este all, care
specifică toate interfeţele fără fir;
Signal Strength Range – diapazonul admis al puterii semnalului clientului;
AP Tx Limit – limita ratei de transmisie AP → client, în bps. Valoarea
implicită este 0, care semnifică „fără limită”;
Client Tx Limit – cere clientului să limiteze rata de transmisie client → AP la
cea specificată, în bps. Valoarea implicită este 0, care semnifică „fără
limită”;
Authentication – starea activată (bifat) specifică folosirea procedurii de
autentificare setată în profilul de securitate (Security Profile) a interfeţei,
iar starea dezactivată (nebifat) – respingerea asocierii staţiei;
Forwarding – starea activată (bifat) specifică faptul, că clientul poate
trimite cadre către alte staţii asociate aceluiaşi AP, iar starea dezactivată
(nebifat) – faptul, că clientul nu poate trimite cadre către alte staţii
asociate aceluiaşi AP, dar le poate trimite către staţii asociate unui alt AP;
Time – diapazonul admis al timpului de acces al clientului;
parametri de securitate ş.a.
La crearea regulilor de acces, unicul parametru obligatoriu este adresa
MAC a clientului, pentru ceilalți parametri pot fi păstrate valorile implicite,
deşi nu întotdeauna aceasta este rezonabil.
Exemplul 8.3. Fie se cere de creat următoarele reguli de asociere la AP prin
interfaţa wlan1:
1) asocierea staţiei cu adresa MAC 2A:47:54:B2:15:1F, la următoarele valori
ale unor parametri: diapazonul puterii semnalului – -85..120; limita ratei
de transmisie client → AP – 5 Mbps;
2) interzicerea asocierii staţiei cu adresa MAC 2A:47:54:A2:B5:2F;
3) interzicerea asocierii tuturor staţilor ce nu sunt în Access List.
Pentru crearea acestor reguli de acces la AP, se acţionează:
1. Crearea primei reguli: /Wireless/Wireless Tables/Access List, +/New AP
Access Rule/MAC Address – 2A:47:54:B2:15:1F, Interface – wlan1, Signal
Strength Range – -85..120, Client Tx Limit – 5 Mbps/OK (fig. 8.16).
2. Crearea celei de a doua reguli: /Wireless/Wireless Tables/Access List, +/
New AP Access Rule/Interface – wlan1, MAC Address – 2A:47:54:A2:B5:2F,
Authentication – debifare, Forwarding – debifare/OK (fig. 8.17).
3. Crearea celei de a treia reguli: /Wireless/Wireless Tables/Interfaces/dublu
clic wlan1/Interface <wlan1>/Wireless, Default Authenticate – debifare
Default Forward – debifare) (fig. 8.18).
Pentru a uşura manipularea cu adresele MAC, se pot selecta cele ale
interfeţelor staţiilor deja asociate. De exemplu, din Registration sau Connect
List; se apasă butonul drept al şoricelului pe înregistrarea ce ţine de interfaţa
respectivă, iar apoi se selectează, prin clic, Copy to Access List (fig. 8.19).
320
Sarcina practică 8.3. De creat trei reguli de acces la AP prin interfaţa
wlan1, similare celor din exemplul 8.3, dar cu adrese MAC ale interfeţelor
ruterelor a doi colegi, pentru a verifica setările.
Fig. 8.16. Crearea primei reguli Fig. 8.17. Crearea celei de a doua
Access List, la exemplul 8.3. reguli Access List, la exemplul 8.3.
8.5.4. Lista de conectare a staţiei la AP

Lista de conectare (Connect List) este folosită pentru configurarea
priorităţii şi securităţii conexiunilor cu puncte de acces distante şi, de
asemenea, pentru restricţionarea conexiunilor în cauză, în baza unor reguli
speciale. Fiecare regulă din Connect List este ataşată la o anumită interfaţă,
fiind imposibilă ataşarea acesteia la toate interfeţele (all), ca la Access List. O
regulă poate include aşa parametri ai punctului de acces distant ca: adresa
MAC (MAC Address); diapazonul puterii acceptate a semnalului (Signal
Strength Range); Protocolul fără fir
(Wireless Protocol) de folosit; profilul
de securitate (Security Profile) ş. a.
Operează în modul următor:
 regulile Connect List sunt
verificate secvenţial, începând cu
prima;
 regulile dezactivate sunt
ignorate;
 se aplică doar prima regulă ce se
potriveşte;
 dacă nici un AP distant nu se
potriveşte nici unei reguli, atunci
se folosesc valorile implicite ale
configurării interfeţei fără fir; Fig. 8.18. Crearea celei de a treia
 dacă AP se potriveşte regulii, care reguli Access List, la exemplul 8.3.
321
are valoarea no a parametrului connect (opţiunea Connect nu este bifată,
vezi fig. 8.20), atunci nu se va solicita asocierea cu acest AP;
 dacă AP se potriveşte regulii, care are valoarea yes a parametrului
connect (opţiunea Connect este bifată, vezi fig. 8.13), atunci se va solicita
asocierea cu acest AP. Dacă asemenea AP sunt mai multe, atunci se va
solicita asocierea cu punctul de acces ce se potriveşte cu regula mai
apropiată de începutul listei de reguli. Dacă şi asemenea AP sunt mai
multe, atunci din ele se va selecta punctul de acces cu cel mai puternic
semnal;
 dacă nici un AP distant nu se potriveşte nici unei reguli, care are valoarea
yes a parametrului connect (opţiunea Connect este bifată), atunci se va
folosi valoarea parametrului Default Authenticate. Dacă acesta este
activat (bifat), atunci se va selecta punctul de acces cu cel mai puternic
semnal şi securitatea compatibilă; în caz contrar, staţia nu se va solicita
asocierea cu nici un AP;
 în modul AP, Connect List se va verifica înainte de stabilirea legăturii WDS
cu dispozitivul distant. Dacă nici un AP distant nu se potriveşte nici unei
reguli din Connect List, atunci se foloseşte valoarea parametrului Default
Authenticate.
Fig. 8.19. Copierea parametrilor interfeţei staţiei din fila Registration.

Regulile din Connect List pot include aşa parametri ca:
Interface – fiecare regulă din Connect List se aplică doar la o interfaţă fără
fir anume a staţiei – interfaţă, definită de acest parametru;
MAC Address – adresa MAC a AP. Valoarea implicită este
00:00:00:00:00:00, care este acceptată;
Connect – dacă este activat (bifat), atunci se va iniţia conectarea la punctul
de acces ce se potriveşte regulii în cauză, iar în caz contrar (nebifat) - nu
se va iniţia conectarea la punctul de acces ce se potriveşte acestei reguli;
322
SSID – identificatorul WLAN (AP);
Area Prefix – regula se potriveşte, dacă valoarea ariei (area) a AP începe cu
valoarea specificată ;
Signal Strength Range – diapazonul admis al puterii semnalului AP;
Wireless Protocol – protocolul de acces la mediu folosit;
Security Profile – numele profilului de securitate, folosit pentru conectarea
la punctele de acces ce se potrivesc. Se aplică doar la operarea în modul
station; la operarea în modul AP nu se foloseşte. Regulii i se vor potrivi
doar acele AP, care suportă profilul de securitate în cauză. Dacă valoarea
acestui parametru este none, atunci se va folosi profilul de securitate
specificat în configurarea interfeţei.
Connect List se foloseşte pentru:
 restricţionarea conexiunilor staţiei doar cu anumite AP;
 interzicerea conexiunilor cu anumite AP;
 selectarea punctelor de acces preferate;
 restricţionarea stabilirii conexiunilor WDS.
Exemplul 8.4. Fie se cere de creat următoarele reguli de conectare a staţiei
la AP, prin interfaţa wlan1:
1) conectarea staţiei doar la AP cu următoarele valori ale unor parametri:
adresa MAC – 2A:47:54:B2:15:1F, SSID – APprof, Signal Strength Range –
-85..120;
Fig. 8.20. Crearea primei reguli Fig. 8.21. Crearea celei de a doua
Connect List, la exemplul 8.4. reguli Connect List, la exemplul 8.4.
2) interzicerea asocierii staţiei la AP, care are adresa MAC 2A:47:54:A2:B5:2F.
Pentru crearea acestor reguli de conectare a staţiei la AP, se acţionează:
1. Crearea primei reguli: /Wireless/Wireless Tables/Connect List, +/New
Station Connect Rule, Interface – wlan1, MAC Address – 2A:47:54:B2:15:1F,
Connect – bifare, SSID – APprof, Signal Strength Range – -85..120/OK (fig.
8.20). De asemenea, se dezactivează parametrul Default Authenticate:
/Wireless/Wireless Tables/Interfaces, dublu clic wlan1/Interface <wlan1>/
Wireless, Default Authenticate – debifare, vezi fig. 8.5.
323
2. Crearea celei de a doua reguli: /Wireless/Wireless Tables/Connect List,
+/New Station Connect Rule/Interface – wlan1, MAC Address –
2A:47:54:A2:B5:2F, Connect – debifare/OK (fig. 8.21).
Un alt exemplu de regulă Connect List este prezentat în s. 8.3.3.
8.6. Securitatea în rețele fără fir RouterOS

8.6.1. Funcționalități de securitate fără fir ale RouterOS
În RouterOS sunt aplicabile toate măsurile de securitate, nominalizate în s.
8.1.7.1, inclusiv: ascunderea SSID (vezi s. 8.2.3), filtrarea adreselor MAC (vezi
ss. 8.5.3, 8.5.4), adresarea IP statică (vezi ss. 1.5, 4.2). Totodată, după cum a
fost menţionat şi în s. 8.1.7.1, cele trei măsuri, enumerate mai sus în acest
alineat, nu prezintă obstacole serioase pentru atacatori. Configurarea reţelelor
VPN este descrisă în cap. 11, iar setarea WEP, WPA-PSK şi WPA2-PSK şi
autentificarea IEEE 802.1x, folosind EAP şi servere RADIUS, – în această
secţiune.
Parametrii privind WEP, WPA-PSK, WPA2-PSK, EAP şi clienţii RADIUS se
configurează în cadrul profilurilor de securitate (Security Profiles), fiecare din
care poate fi aplicat aparte, la orice interfaţă a punctelor de acces şi a staţiilor.
Fiecare profil de securitate a RouterOS se caracterizează prin nume (name) şi
modul de operare (mode). Se folosesc patru moduri de operare:
 dynamic keys – modul WPA, inclusiv WPA2;
 none – cifrarea nu se foloseşte; respectiv, cadrele cifrate nu se acceptă.
Este modul implicit;
 static keys optional – modul WEP. Suportă cifrarea şi descifrarea, dar
permite, de asemenea, recepţia şi trimiterea cadrelor necifrate.
Dispozitivul va trimite cadre necifrate atunci, când algoritmul de cifrare
este specificat ca none. Staţia, ce operează în acest mod, nu se va
conecta la un AP, ce operează în modul static keys required;
 static keys required – modul WEP. Nu acceptă şi nu trimite cadre
necifrate. Staţia, ce operează în acest mod, nu se va conecta la un AP, ce
operează în modul static keys optional.
Modul WPA (Wireless/Wireless Tables/Security Profiles/General)
foloseşte aşa parametri ca:
 Authentication Types – bifarea tipurilor de autentificare suportate, din
cele patru posibile: WPA PSK, WPA2 PSK, WPA EAP și WPA2 EAP; implicit
nu este specificat nici unul. AP va informa clienții despre tipurile de
autentificare suportate, iar clienții se vor conecta la AP doar dacă suportă
oricare din tipurile suportate de AP;
 Unicast Ciphers – bifarea cifrurilor monoadresat suportate, din cele două
posibile: tkip (vezi TKIP în s. 8.1.7.3) și aes-ccm (vezi AES-CCM în s.
324
8.1.5.4); implicit nu este specificat nici unul. AP va informa clienții despre
cifrurile suportate, iar clienții vor încerca să se conecteze doar la AP ce
suportă cel puțin unul din cifrurile specificate. Unul din cifruri va fi folosit
pentru cifrarea cadrelor monoadresat trimise între AP și client;
 Group Ciphers – bifarea cifrului multiadresat și de difuzare suportat, din
cele două posibile: tkip și aes-ccm; implicit nu este specificat nici unul. AP
va informa clienții despre cifrul suportat, iar clienții vor încerca să se
conecteze doar la AP ce suportă unul din cifrurile de grup specificate;
 WPA Pre-Shared Key, WPA2 Pre-Shared Key – specificarea cheilor
prepartajate ale modului WPA-PSK și, respectiv, ale celui WPA2-PSK.
Toate dispozitivele unui set BSS trebuie să folosească una și aceeași cheie
secretă. Valoarea cheii poate fi un text arbitrar;
 Group Key Update – specificarea intervalului de timp de reactualizare a
cheii de grup – cheie ce servește pentru cifrarea la AP a tuturor cadrelor
multiadresat și de difuzare. Poate avea valoare în diapazonul 30s..1h;
implicit este 5m. Acest parametru nu are efect în modul station.
Modul WPA-EAP (Wireless/Wireless Tables/Security Profiles/EAP), care se
aplică în cazurile, când modul de operare este dynamic keys, iar tipul de
autentificare este WPA EAP sau WPA2 EAP; foloseşte aşa parametri ca:
 EAP Methods – selectarea metodei EAP de autentificare, din cele două
posibile: passthrough și EAP-TLS. În cazul metodei passthrough, AP va
direcționa autentificarea către serverul RADIUS; valoarea este ignorată în
cazul modului station. În cazul metodei EAP-TLS, se va folosi
autentificarea EAP-TLS; se suportă certificate atât client, cât și server
(vezi parametrii TLS Mode și cei TLS Certificate);
 TLS Mode – selectarea unuia din modurile TLS (Transport Layer Security):
dont verify certificate, no certificates sau verify certificate; implicită este
no certificates. În modul dont verify certificate, AP nu va cere de la client,
pentru autentificare, nici un certificat. În modul no certificates, nu se vor
folosi certificate; sesiunea TLS se va stabili, folosind schimbul anonim de
chei Diffie-Hellman de 2048 biți. În modul verify certificate, clientul va
prezenta un certificat, validitatea căruia va fi verificată de AP, inclusiv
dacă acesta este semnat de o autoritate de certificare cunoscută;
 TLS Certificate – specificarea numelui certificatului (name) sau none,
dacă certificat nu se folosește; valoarea implicită este none.
 Supplicant Identity – identitatea (numele) EAP; implicit este numele
ruterului-solicitant. Este trimisă de client la inițierea autentificării EAP.
Modul Management Protection (Wireless/Wireless Tables/Security Profiles/
General), propus de MikroTik, implementează un algoritm de protecție a
cadrelor de gestiune, în baza unui secret partajat. Acesta permite verificarea
325
sursei fiecărui cadru de gestiune, validându-l sau, din contra, nevalidându-l.
Pot fi selectate una din trei valori:
 allowed – folosirea modului Management Protection, dacă acesta este
suportat de partea distantă;
 disabled – folosirea modului Management Protection este dezactivată; este
valoarea implicită;
 required – stabilirea asocierii doar cu dispozitive distante ce suportă
modul Management Protection.
Secretul partajat al modului Management Protection este configurat prin
specificarea cheii Management Protection Key.
8.6.2. Configurarea parametrilor de securitate
La configurarea parametrilor de securitate, trebuie de ţinut cont că:
1) aceștia să fie aceiași la ambele interfețe ale conexiunii. În general, în
cadrul unui set BSS toate interfeţele trebuie să deţină aceiaşi parametri
de configurare;
2) folosirea serverelor RADIUS permite o securizare mai puternică;
3) dacă viteza de procesare este suficientă, atunci este de preferat WPA2
faţă de WPA şi AES-CCM faţă de TKIP;
4) protecţia cadrelor de gestiune îmbunătăţeşte securitatea funcţionării
reţelelor fără fir.
Exemplul 8.5. Fie se cere de creat și aplicat profilul de securitate profilsec1
la ruterul-staţie client, prin interfaţa wlan1, folosind modurile WPA-PSK,
WPA2-PSK și cheia prepartajată cursinternetintranet. În acest scop:
1. Se creează profilul profsec1: /Wireless/Wireless Tables/Security Profile, +/
New Security Profile/General, Name – profilsec1, Mode – dynamic key,
WPA PSK – bifare, WPA2 PSK – bifare, Unicast Cipher aes ccm – bifare, WPA
Pre-Shared Key – cursinternetintranet, WPA2 Pre-Shared Key –
cursinternetintranet/OK (fig. 8.22b).
2. Pentru a urmări introducerea corectă a cheii, se poate debifa, temporar,
parametrul Hide Password din bara cu instrumente a WinBox (vezi fig. 4.6,
8.22a).
3. Se setează profilul profsec1 pentru interfața wlan1 și se dezactivează
parametrul Default Authenticate: /Wireless/Wireless Tables/Interfaces,
dublu clic wlan1/Interface <wlan1>/Wireless, Security Profile – profilsec1,
Default Autentificate – debifare/OK.
De menţionat că în cazul configurării unui AP, este necesar de dezactivat
nu doar parametrul Default Authenticate (vezi pasul 3 al exemplului 8.5), dar şi
cel Forward Authenticate.
326
a) b)
Fig. 8.22. Crearea profilului profilsec1.
Sarcină practică 8.4. De creat și aplicat un profil de securitate profilsec1 la
ruterul-staţie client, prin interfaţa wlan1, folosind modurile WPA-PSK, WPA2-
PSK și cheia prepartajată cursinternetintranet conform exemplului 8.5.
8.7. Setări specifice 802.11n

Standardul 802.11n conţine, comparativ cu cele 802.11a/b/g, unele
dezvoltări (vezi s. 8.1.4). RouterOS suportă (ht supported mcs), în funcţie de
banda utilizată, primele 24 (0-23) scheme de modulare şi codificare, din cele
specificate în tabelul 8.2 (vezi tabelul 8.5); de bază (ht basic mcs) implicite sunt
primele opt scheme MCS (0-7). Acestea suportă până la 3 fluxuri spaţiale.
Ratele de date folosite sunt specificate în tabelul 8.4 din s. 8.1.4. În mod
obișnuit, ruterele singure negociază modul de conectare și aleg viteza
oportună de transfer date. Dar în acest scop trebuie efectuate configurările
respective din linia de comandă a Terminal.
Configurările existente ale interfeţei fără fir wlan1 pot fi vizualizate în
fereastra Interface < wlan1>, care se afişează la acţionarea Wireless/Wireless
Tables/Interfaces, dublu clic pe înregistrarea wlan1. Semnificaţiile
parametrilor din fila Wireless au fost descrise în ss. 8.2.3, 8.2.8. În figura 8.23
327
sunt prezentate configurările implicite în fila HT pentru RouterOS v5.26 ce
rulează pe ruterul RB951-2n.
Fig. 8.23. Setări implicite în fila HT.

Parametrul HT Tx Chains permite selectarea (bifarea) antenei de folosit
pentru transmisie, iar cel HT Rx Chains – pentru recepţie. În RouterOS,
dimensiunea maximă, dar şi cea implicită, a unităţilor de date de serviciu MAC
(vezi s. 8.1.4) A-MSDU (HT AMSDU Limit) şi, de asemenea, a unităţilor de date
de protocol MAC (vezi s. 8.1.4) A-MPDU (HT AMPDU Limit) este de 8192
octeţi. Intervalul de protecţie (HT Guard Interval) este durata intervalului între
caracterele ce se transmit (vezi tab. 8.2 din s. 8.1.4).
În fila HT MCS se afişează schemele MCS suportate (HT Supported MCS) şi
schemele MCS de bază (HT Basic MCS) – scheme folosite conform standardului
IEEE 802.11n.
8.8. Setarea protocoalelor fără fir MikroTik

Aspectele de selectare a protocoalelor de acces la mediu, folosind
RouterOS, sunt descrise în s. 8.2.10, iar configurarea acestora – în această
secţiune.
8.8.1. Configurarea operării semiduplex
Setarea wlan1, pentru folosirea uneia din opţiunile protocoalelor de acces
la mediul fără fir semiduplex, enumerate în tabelul 8.5 din s. 8.2.10, se
efectuează în fila Wireless a ferestrei Interface <wlan1>.
Exemplul 8.6. Fie se cere de setat interfaţa wlan1 a ruterului-staţie client la
opţiunea nv2 nstreme 802.11 a protocolului de acces la mediul fără fir. În acest
scop:
1. Se configurează interfaţa wlan1: /Wireless/Wireless Tables/Interfaces,
dublu clic wlan1/Interface <wlan1>/Wireless, Wireless protocol – nv2
328
nstreme 802.11/OK (fig. 8.18 din s. 8.5.3, dar în care este afişată opţiunea
implicită any).
2. Se verifică configurarea realizată, în fila Status a ferestrei Interfaces:
/Wireless/ Wireless Tables/Interfaces, dublu clic wlan1/ Interface
<wlan1>/Status (fig. 8.24).
Din figura 8.23 se poate observa că protocolul fără fir, folosit de interfaţa
wlan1, este cel 802.11. Astfel, din cele trei
protocoale, în ordinea preferinţei (vezi s.
8.2.10) – nv2, nstreme şi 802.11, ruterul
staţie-client l-a selectat, până la urmă, pe
cel 802.11, care este setat la AP.
În acelaşi mod interfaţa wlan1 poate fi
setată şi pentru a folosi o oarecare altă
opţiune, din cele şapte descrise în tabelul
8.5 din s. 8.2.10, doar că interfeţele de la
ambele capete ale legăturii fără fir trebuie Fig. 8.24. Protocolul fără fir în
fila Status a wlan1.
să opereze folosind acelaşi protocol.
8.8.2. Configurarea operării duplex folosind Nstreme Dual
După cum a fost menţionat în s. 8.2.10, pentru operarea duplex folosind
Nstreme Dual, ruterul trebuie să dispună de două cartele de interfață fără fir,
fiecare din care trebuie să fie setată la modul nstreme dual slave. Ulterior se
configurează o noua interfaţă – interfaţa duplex în fila Nstreme Dual a
ferestrei New Interface (fig. 8.25). În această filă sunt aşa parametri ca:
 Tx radio – numele antenei (interfeţei simplex) de transmisie;
 Rx radio – numele antenei (interfeţei
simplex) de recepţie;
 Remote MAC – adresa MAC a receptorului
distant;
wlan2
 Tx Band – banda de operare a antenei de
transmisie;
 Tx Channel Width – lăţimea de bandă a
canalului de transmisie;
 Tx Frequency – frecvenţa de lucru a
canalului de transmisie;
 Rx Band, Rx Channel Width şi Rx
Frequency – aceiaşi ca şi Rx Band, Rx
Channel Width şi Rx Frequency, dar
pentru antena/canalul de recepţie;
 Disable CSMA – dezactivarea CSMA/CA; Fig. 8.25. Setarea Nstreme
îmbunătăţeşte performanţa, ş.a. Dual.
329
Exemplul 8.6. Fie se cere de creat la ruter o interfaţa fără fir duplex cu
numele wlandual1, folosind pentru transmisie interfaţa wlan1, iar pentru
recepţie interfaţa wlan2. În acest scop:
1. Interfaţa wlan1 se setează la modul de operare nstreme dual slave:
/Wireless/Wireless Tables/Interfaces, dublu clic pe înregistrarea wlan1/
Interface <wlan1>/Wireless, Mode – nstreme dual slave/OK.
2. Interfața wlan2 se setează la modul de operare nstreme dual slave ca şi cea
wlan1 la pasul 1.
3. Se setează numele wlandual1 al interfeţei duplex: /Wireless/Wireless
Tables/Interfaces, clic +/Nstreme dual/New Interface/General, Name –
wlandual1. De menţionat că secvenţa de acţiuni /Wireless/Wireless Tables/
Nstreme dual, +/ va conduce, de asemenea, la afişarea ferestrei New
Interface.
4. Se deschide fila Nstreme Dual, în care se configurează parametrii respectivi
ai interfeţei wlandual1: New Interface/Nstreme Dual, Tx Radio – wlan1, Rx
Radio – wlan2 şi, respectiv, alţi parametri. În fig. 8.24 este prezentat un
exemplu.
330
9. FOLOSIREA PUNŢILOR ÎN REŢELE
9.1. Punţile MAC – privire de ansamblu
Fie avem un ruter, la interfeţele Ethernet ale căruia sunt conectate prin
cablu mai multe calculatoare. Ansamblul de calculatoare, conectate la o
interfaţă aparte a ruterului, formează un fragment de reţea, denumit şi
subreţea Ethernet. O asemenea subreţea poate fi constituită dintr-unul sau
mai multe calculatoare. Dacă un asemenea fragment operează în regim
semiduplex şi nu conţine punţi (comutatoare), atunci el formează un domeniu
de coliziuni; domeniul de coliziuni operează la nivelul Fizic OSI (L1) – reţea
(subreţea) de nivel L1.
Reţele locale IEEE 802 de nivel L1, pot fi interconectate prin punţi MAC.
Puntea cuplează (concatenează) două sau mai multe interfeţe fizice din cadrul
unui dispozitiv într-o singură interfaţă logică şi operează la nivelul Legătură de
date OSI (L2). Asemenea reţele, denumite şi reţele locale puntate (bridged
LAN) sau cu comutare, formează un domeniu de difuzare ce operează la
Nivelul 2 OSI. Ele permit interconectarea staţiilor, ca şi cum acestea ar fi
ataşate unei singure reţele LAN, chiar dacă ele sunt ataşate la reţele L1
diferite, fiecare din care cu serviciul MAC independent propriu.
În cele ce urmează, pentru fragmentele de reţea ce operează la Nivelul 1
OSI, inclusiv fragmentele-domenii de coliziuni, se va folosi, după cum este
specificat mai sus, şi denumirea de reţele de nivel L1 sau, pur-şi-simplu, reţele
L1. În mod similar, pentru fragmentele de reţea ce operează la Nivelul 2 OSI,
fragmente-domenii de difuzare, se va folosi şi denumirea de reţele de nivel L2
sau, pur-şi-simplu, reţele L2. Evident, pot fi puntate şi fragmente de subreţele
L2.
Pentru interconectarea mai multor subreţele L1 şi L2 printr-o punte, la
ruter trebuie să fie creată o interfaţă de punte, iar apoi fiecare interfaţă fizică,
interconectată cu alte interfeţe fizice prin punte, se configurează ca port
aparte al acestei punţi. Mai mult ca atât, tuturor interfeţelor fizice puntate li
se atribuie o singură adresă MAC – implicit aceasta este cea mai mică din
adresele MAC ale interfeţelor fizice puntate; dar poate fi setată, explicit, şi o
altă adresă MAC.
Schimbul de date între calculatoarele, ce aparţin unor subreţele L1 sau/şi
L2 diferite interconectate printr-un ruter, necesită rutarea pachetelor,
implicând nivelul Reţea OSI cu procesările aferente. Aceasta conduce atât la
creşterea folosirii resurselor de procesare ale ruterului, cât şi la creşterea
reţinerii pachetelor. De aceea, în multe cazuri, este oportună interconectarea
subreţelelor L1/L2 printr-o punte, creată în cadrul ruterului respectiv.
331
Punţile pot interconecta nu doar fragmente de reţele cablate (Ethernet
ş.a.), dar şi fragmente de reţele fără fir (802.11 ș.a.). Noţiunile, introduse
pentru fragmente de reţele cablate, rămân în vigoare şi pentru fragmente de
reţele fără fir.
Pentru determinarea căii de transmisie a cadrelor, între staţiile reţelelor de
nivel L1 interconectate, punţile MAC folosesc adresele MAC destinaţie ale
acestora. Punţile MAC, operând la subnivelul MAC, sunt transparente: acestea
nu apar în listele de rutare, iar utilitele nu pot face distincţie între o staţie
dintr-o reţea de nivel L1 şi o staţie din altă reţea de nivel L1, dacă aceste reţele
sunt puntate.
Reţea locală puntată se numeşte orice reţea locală, care concatenează
două sau mai multe fragmente-domenii de coliziuni prin intermediul punţilor
MAC.
Se poate întâmpla ca într-un ansamblu de reţele puntate să fie bucle fizice,
dar logic acestea sunt evitate, deoarece fiecare punte rulează o utilita, care
calculează căile de prevenire a buclelor şi le implementează. Prin schimbul de
informaţii conform protocolului RSTP (Rapid Spanning Tree Protocol), punţile
negociază o topologie logică fără bucle, celelalte legături fiind dezactivate
(standby). Schimbul de informaţie în cauză este periodic, în formă de mesaje
BPDU (Bridge Protocol Data Unit – Unitate de Date a Protocolului de Punte). În
baza mesajelor BPDU, din mulţimea de punţi ale ansamblului de reţele
puntate, RSTP selectează o punte rădăcină (root bridge) responsabilă de
reconfigurarea reţelei – punte cu cel mai mic ID punte. Astfel, că topologia fără
bucle se actualizează dinamic, în funcţie de modificările în ansamblul de reţele
locale puntate.
Protocolul RSTP, introdus în 2001 (IEEE 802-1w) şi, ulterior, dezvoltat în
standardul IEEE 802-1D-2004, a înlocuit standardul iniţial STP (Spanning Tree
Protocol), fiind considerabil mai rapid.
Serviciul MAC, oferit de o reţea locală puntată, este similar celui oferit de o
reţea LAN ordinară.
Puntarea reţelelor locale poate servi pentru:
 interconectarea staţiilor, ataşate unor reţele locale de diferite tipuri MAC
(de exemplu, Ethernet şi Token-Ring sau FDDI);
 extinderea diametrului şi creșterea numărului permis de staţii ataşate;
 creşterea fiabilităţii şi a calităţii serviciilor, datorită partiţionării de trafic
pe segmente;
 partiţionarea fizică a reţelei locale, din motive de administrare sau
mentenanţă;
 validarea accesului la reţea;
 creşterea disponibilităţii Serviciului MAC, în cazuri de reconfigurare sau
de căderi ale unor componente ale reţelei.
332
De asemenea, puntarea unor reţele conectate la un ruter poate conduce la
reducerea reţinerii cadrelor transmise între acestea, din contul eliminării
procesărilor de la subnivelul LLC şi al celor de la nivelul Reţea – cadrele nu se
rutează. Mai mult ca atât, punţile MAC nu detectează erorile în cadrele
transmise.
Totodată, partiţionarea fizică a reţelei locale prin punţi are, uneori, şi
dezavantaje, dintre care:
 o întârziere suplimentară a cadrelor de tranzit, egală cu durata de
recepţie, stocare, prelucrare şi transmitere a lor de către punte;
 asigurarea unui trafic înalt necesită memorie de capacitate relativ mare
pentru buferizarea temporară a cadrelor de tranzit.
Punţile MAC interconectează reţele LAN prin tranziţionarea (Relay) şi
filtrarea cadrelor între diferitele medii MAC ale acestora. Ele operează la
subnivelul MAC, sub hotarul serviciului MAC, şi sunt transparente, funcţional,
pentru protocoalele ce operează mai sus de acest hotar, în cadrul subnivelului
LLC sau cel al nivelului Reţea. Totodată, prezenţa punţilor MAC poate influenţa
calitatea serviciilor oferite.
Locul funcţiilor de puntare (releu), în cadrul subnivelului MAC, este
prezentat în figura 9.1.
Staţie/ Staţie/
ruter ruter Utilizatorul
Utilizatorul
Servicului MAC LLC LLC Servicului MAC
Punte
Releu Furnizorul
Furnizorul MAC MAC
Servicului MAC MAC MAC Servicului MAC
Fizic Fizic Fizic

Mediul
Fig. 9.1. Organizarea internă a subnivelului MAC la punţi.
Capabilităţile punţilor MAC:
 permit implementarea serviciului LLC fără conexiune neconfirmat
(operarea LLC de Tip 1);
 realizează tranziţionarea (relay) şi filtrarea cadrelor;
 implementează protocolul de Acoperire rapidă a arborelui (Rapid
Spanning Tree Protocol);
 codifică PDU punte transmise şi validează PDU punte recepţionate;
 specifică următorii parametri ai implementării:
1) dimensiunea Bazei de date de filtrare, numărul maximal de
înregistrări;
2) dimensiunea Bazei de date permanente, numărul maximal de
înregistrări;
333
 specifică următoarele caracteristici de performanţă ale implementării:
1) rata garantată de filtrare pentru fiecare port;
2) rata garantată de comutare (tranzitare) pentru fiecare punte;
3) intervalele de timp aferente TF şi TR pentru parametrii (1) şi (2);
 opţional, pot suporta:
1) folosirea unui protocol de gestiune la distanţă;
2) mai multe clase de trafic pentru filtrarea şi înaintarea cadrelor ş.a.
În funcţie de necesităţi, punţile MAC pot fi configurate:
 pentru oferirea de căi redundante între staţii, ceea ce permite sporirea
fiabilităţii de funcţionare;
 astfel, încât căile acceptate între staţii să fie previzibile şi configurabile în
baza disponibilităţii componentelor reţelei.
Punţile MAC pot restricţiona furnizarea Serviciului MAC doar dispozitivelor
autentificate şi autorizate. Accesul dispozitivelor neautorizate, la o reţea locală
puntată, poate fi interzis, cu excepţia minimumului necesar procesului de
autentificare.
Serviciul MAC oferit de o reţea locală puntată este similar celui oferit de o
reţea LAN ordinară. De aceea:
 o punte nu este adresată direct de staţiile comunicante, cu excepţia
cazurilor de gestiune necesare;
 cadrele transmise între staţii, conţin adresa MAC a staţiei destinaţie;
 toate adresele MAC în cadrul reţelei trebuie să fie unice;
 adresele MAC ale staţiilor nu depind de topologia şi configurarea reţelei.
Pentru puntarea a două sau mai multe reţele de nivel L1, trebuie, mai întâi,
de creat interfaţa punţii. O punte conţine porturi. Fiecare port este creat odată
cu adăugarea la punte a unei interfeţe fizice de reţea L1 – setarea acesteia ca
port al punţii. Astfel, numărul de porturi ale punţii este egal cu numărul de
reţele de nivel L1 puntate de aceasta.
Tuturor interfeţelor puntate li se atribuie o singură adresă MAC – adresa
interfeţei punţii. Implicit aceasta este cea mai mică adresă MAC, dintre cele
ale interfeţelor fizice în cauză; dar poate fi, explicit, setată şi o altă adresă
MAC.
Din multiplele alternative de folosire a punţilor MAC în RouterOS, în ss.
9.2-9.5 sunt descrise aspectele de bază ce ţin de:
 puntarea de reţele locale de calculatoare cablate, conectate la un ruter –
puntarea interfeţelor Ethernet (s. 9.2);
 puntarea transparentă a unei legături fără fir (s. 9.3);
 configurarea unui sistem de distribuire fără fir (WDS) simplu (s. 9.4);
 puntarea reţelelor la distanţă (s. 9.5).
334
9.2. Puntarea interfeţelor Ethernet
Fie avem un ruter, la interfeţele Ethernet ale căruia sunt conectate prin
cablu mai multe subreţele L1. În scopul reducerii procesărilor cu fluxurile de
date de tranzit şi, de asemenea, a reţinerii datelor în cadrul ruterului, se
consideră oportună interconectarea acestor subreţele într-o reţea L2 printr-o
punte MAC (vezi s. 9.1.1). Pentru interconectarea subreţelelor în cauză printr-
o punte, este necesar:
1) de creat, la ruter, o interfaţă de punte;
2) fiecare interfaţă, de conectare la ruter a subreţelelor de calculatoare, de
setat ca port al punţii create.
De menţionat că, deoarece puntea operează folosind adresele MAC ale
interfeţelor ce se interconectează, la interconectarea prin punte a interfeţelor
aceluiaşi ruter, subreţelele ce ţin de aceste interfeţe pot să aparţină şi unor
reţele diferite, de exemplu 192.168.20.0/24 şi 192.168.21.0/24.
La configurarea interfeţei punte, se folosesc aşa parametri ca (fig. 9.2):
 Name – numele interfeţei punte;
 Admin. MAC Address – adresa MAC statică a punţii. Are efect doar dacă
este dezactivat regimul de detectare automată (auto mac = no) a celei
mai mici adrese MAC;
 Protocol Mode – protocolul folosit pentru configurarea topologiei fără
bucle a reţelei puntate; valoarea implicită este none, dar poate fi setat
protocolul STP (Spanning Tree Protocol) sau cel RSTP (Rapid Spanning
Tree Protocol), ultimul fiind mai rapid la modificarea topologiei reţelei
ş.a.
La setarea unei interfeţe a ruterului ca port al punţii, se folosesc aşa
parametri ca (fig. 9.3):
 Interface – numele interfeţei ruterului ce se setează ca port al punţii;
 Bridge – numele punţii, la care se adaugă ca porţi interfeţele ruterului;
 Priority – prioritatea portului în diapazonul 0..255. Valoarea implicită este
128;
 Path Cost – costul căii către port, folosit de STP/RSTP pentru
determinarea celei mai convenabile căi, în diapazonul 0..65535. Valoarea
implicită este 10;
 Horizon – utilizarea puntării cu divizarea orizontului (split horizon
bridging) în scopul prevenirii buclelor de puntare – traficul, recepţionat
prin puntea cu valoarea x a orizontului, nu va fi înaintat sau difuzat nici
către un port cu aceeaşi valoare x a orizontului;
 Edge – setarea portului ca marginal sau permiterea detectării automate;
 Point To Point – conexiune punct-la-punct. Poate avea una din valorile –
yes, no sau auto; valoarea implicită este auto;
335
 External FDB – setarea folosirii/nefolosirii tabelului de înregistrări fără fir,
pentru sporirea vitezei de identificare a staţiilor de către punte.
Fig. 9.2. Crearea punţii punte23. Fig. 9.3. Adăugarea ether2 la punte.
Exemplul 9.1. Fie se cere ca două calculatoare, conectate prin cablu la

ruter, să fie puntate prin puntea punte23. Unul din calculatoare este conectat
la interfaţa ether2, iar celălalt la interfaţa ether3 a ruterului. Ruterul operează
în modul AP-bridge. Fiecare calculator, împreună cu interfaţa respectivă a
ruterului, formează o subreţea/segment aparte. În acest scop:
1. Se creează puntea punte23: /Bridge/Bridge/Bridge, +/New Interface/
General, Name – punte23/STP, Protocol Mode – rstp/OK.
2. Se adaugă interfaţa locală ether2 la puntea punte23: /Bridge/Bridge/Ports,
+/New Bridge Port/General, Interface – ether2, Bridge – punte23/OK.
3. Se adaugă interfaţa locală ether3 la puntea punte23, la fel ca la pasul 2
pentru ether2.
4. Se verifică conexiunea, de exemplu folosind ping de la un calculator la
celălalt.
9.3. Puntarea transparentă a unei legături fără fir

În cazul puntării interfeţei fără fir a unui ruter-staţie client, prin care acesta
este conectat la un AP, este necesar ca şi interfaţa fără fir respectivă a AP să
fie puntată. În această secţiune este descrisă puntarea transparentă a unei
legături fără fir între un ruter-staţie client şi un AP; calculatoarele sunt
conectate la interfeţele Ethernet ale ruterului-staţie client. Astfel, este necesar
de creat câte o punte (o interfaţă de punte) la ruterul-staţie client şi la AP, iar
apoi de adăugat interfeţele respective la porturile acestor punţi (interfeţele se
adaugă la punte via porturile acesteia).
Adăugarea interfeţelor Ethernet la punte este descrisă în s. 9.2. În cazul
interfeţelor fără fir, din modurile de operare a staţiilor client – station, station-
336
bridge, station-pseudobridge, station-pseudobridge-clone şi station-wds, doar
modul station nu permite puntarea L2. Totodată, fiecare din celelalte moduri
de operare a clienţilor are specificul său (vezi s. 8.2.5).
Când este necesară crearea unei legături puntate reale cu AP, la staţia
client se foloseşte modul station-wds. Modurile station-pseudobridge şi
station-pseudobridge-clone permit puntarea L2, dar una limitată şi non-
conformă 802.11. Modul station-bridge funcționează doar cu AP RouterOS și
se recomandă de folosit pentru puntarea L2 doar atunci, când din anumite
motive nu este oportun de folosit modul station-wds. Astfel, pentru puntare,
la ruterul-staţie client pe interfaţa fără fir de puntat (wlan1) se va folosi modul
de operare station-wds.
În cazul interfeţelor fără fir, din modurile de operare a AP – ap-bridge,
bridge şi wds-slave (cele alignement-only şi nstreme-dual-slave sunt speciale,
vezi s. 8.2.5), modul bridge se foloseşte doar de către AP ce operează în regim
P2P, iar cel wds-slave – doar de către AP speciale. Astfel, pentru puntare, la AP
trebuie de folosit modul ap-bridge.
Totodată, după cum este menţionat în s. 8.1.6.6, pentru puntarea unei
legături fără fir, nu doar AP-AP, dar şi staţie client-AP, este necesar de folosit
WDS. Pentru crearea unei legături puntate reale fără fir cu interfaţa fără fir a
ruterului-staţie client ce operează în modul station-wds, la AP trebuie de creat,
pe interfaţa fizică fără fir (wlan1, Master Interface – wlan1), o interfaţă WDS
(Wireless Distribution System), căreia i se atribuie un nume; implicit RouterOS
atribuie unor asemenea interfeţe, consecutiv, numele wds1, wds2, etc.
Modul WDS de operare a interfeţei fără fir-punte a AP permite adăugarea
la punte, atât a clienţilor fără fir, inclusiv AP-uri, cât şi a clienţilor prin cablu.
Astfel, este posibilă crearea unei legături WDS între interfaţa fără fir (wlan1),
ce operează în modul wds-staion, a ruterului-staţie client şi interfaţa fără fir
(wlan1), ce operează în modul ap-bridge, a AP.
Exemplul 9.2. Fie un ruter local, la interfeţele Ethernet ale căruia sunt
conectate prin cablu mai multe subreţele L1, iar interfaţa wlan1 a lui este
conectată la interfaţa wlan1 a AP. Punctul de acces, la rândul său, este
conectat la DS prin interfaţa ether1. AP are SSID bit1947, foloseşte banda
2GHz-B/G/N şi frecvenţa de 2,437 MHz; pentru ceilalţi parametri se folosesc
valorile implicite. Se cere de creat o legătură puntată între interfeţele Ethernet
şi cea wlan1 ale ruterului local şi interfaţa wlan1 şi cea ether1 ale AP. În acest
scop, trebuie puntate atât interfeţele respective ale ruterului local, cât şi cele
wlan1 şi ether1 ale AP.
Astfel, la AP:
1. Se creează interfaţa de punte, de exemplu, punteAP: /Bridge/Bridge/Bridge,
+/New Interface/General, Name – punteAP/STP, Protocol Mode – rstp/OK.
337
2. Se adaugă interfaţa wlan1 la puntea punteAP, în mod similar cu pasul 2 al
exemplului 9.1 pentru ether2.
3. Se setează modul ap-bridge şi ceilalţi parametri ai interfeței wlan1:
/Wireless/Wireless Tables/Interfaces, dublu clic wlan1/ Wireless, Mode –
ap bridge, Band – 2GHz-B/G/N, Frequency – 2437, SSID – bit1947/.
4. În continuarea pasului 3, în fila WDS se setează modul WDS (dynamic mesh)
de operare al interfeţei wlan1 şi aceasta se ataşează la puntea punteAP:
/WDS, WDS Mode – dynamic mesh, WDS Default Bridge – punteAP/OK.
Astfel, la AP este creată interfaţa WDS (în fig. 9.4, cu numele wds1 atribuit
de RouterOS).
Fig. 9.4. Info privind puntea punteAP şi interfeţele ataşate wlan1 şi ether1.
5. Se adaugă interfaţa ether1 la puntea punteAP, în mod similar cu pasul 2 al
exemplului 9.1 pentru ether2 (vezi fig. 9.5).
Fig. 9.5. Info privind puntea punte2w şi interfeţele ataşate wlan1 şi ether2.
La ruterul staţie client:

6. Se setează modul station-wds şi ceilalţi parametri ai interfeței wlan1:
/Wireless/Wireless Tables/Interfaces, dublu clic wlan1/Wireless, Mode –
station wds, Band – 2GHz-B/G/N, Frequency – 2437, SSID – bit1947/OK.
7. Se creează puntea punte2w: /Bridge/Bridge/Bridge, +/New Interface/
General, Name – punte2w/STP, Protocol Mode – rstp/OK.
8. Se adaugă interfaţa locală ether2 la puntea punte2w, în mod similar cu pasul
2 al exemplului 9.1 din s. 9.2. Dacă este necesar, la puntea punte2w se
adaugă şi alte interfeţe Ethernet.
9. Se adaugă interfaţa locală wlan1 la puntea punte2w, în mod similar cu pasul
2 al exemplului 9.1 pentru ether2. Astfel interfeţele Ethernet respective şi
338
cea wlan1 ale ruterului-staţie client sunt puntate, ruterul înseşi devenind
punte transparentă.
Starea legăturii WDS la ruterul local este prezentată în figura 9.6
(/Wireless/Wireless Tables/Interfaces).
Fig. 9.6. Starea legăturii WDS (interfaţa wds1) la ruterul local.
9.4. Crearea unui sistem WDS

În exemplul 9.2 din s. 9.3 este descrisă crearea unei legături fără fir puntate
staţie client-AP, care implică folosirea WDS. În caz general, WDS permite
interconectarea fără fir a multiple puncte de acces într-o reţea IEEE 802.11.
Configurarea punctelor de acces în acest scop este similară celei descrise în
exemplul 9.2 cu anumite concretizări, în funcţie de situaţie. Particularităţile de
configurare a punctelor de acces ale WDS (staţie de bază principală, una releu
sau una distantă, modul WDS dynamic, dynamic-mesh, static sau static-mesh,
etc. – vezi s. 8.1.6.6) depind de caracteristicile ESS în ansamblu, inclusiv
amplasarea staţiilor, fluxurile de date între acestea, etc.
În reţeaua din fig. 4.11 a s. 4.2.1, la fiecare ruter local este conectat un
singur calculator, oricum formând, împreună cu interfaţa Ethernet a ruterului
respectiv, o subreţea L1 aparte. Asemenea subreţele la fiecare ruter pot fi mai
multe, în funcţie de numărul de interfeţe Ethernet la ruter. Puntarea interfeţei
fără fir şi a celor Ethernet la ruterele locale, dar şi a interfeţei fără fir a
ruterului AP permite crearea, folosind WDS, a unei reţele L2 care cuprinde
toate calculatoarele conectate la ruterele locale.
Sarcina practică 9.1. De configurat reţeaua din figura 4.11, fiecare
utilizator setând o legătură fără fir puntată ruter client-AP, în condiţiile că AP
este deja configurat corespunzător. La puntea de la ruterul local se va adăuga
atât interfaţa fără fir wlan1, cât şi cea ether2 respectivă. Configurările se vor
efectua conform exemplelor 9.1 şi 9.2 din ss. 9,2, 9.3. Ulterior, se va verifica
apariţia înregistrărilor privind porturile punţii create la ruterul local (similar fig.
9.5), starea legăturii fără fir WDS (similar fig. 9.6) şi posibilitatea schimbului de
date cu calculatoarele vecinilor, folosind, de exemplu, ping.
339
9.5. Puntarea reţelelor fără fir la distanţă
După cum a fost deja menţionat (vezi s. 9.1), puntarea permite înaintarea
de pachete prin reţea fără rutare, ceea ce reduce volumul calculelor necesare
la rutere. În termenii modelului OSI, prin puntare reţelele L3 se transformă în
reţele L2.
În ss. 9.2-9.3 sunt descrise şi prezentate exemple de puntare a reţelelor
locale aflate la distanţe specifice reţelelor LAN. Pot fi puntate însă, folosind
tunelarea, şi reţele locale aflate la distanţă. Tehnologiile folosite în acest scop
sunt Ethernet peste IP (Ethernet over IP – EoIP) şi Serviciul de reţele locale
private (Virtual Private LAN Service – VPLS). Aceste tehnologii sunt succint
descrise în ss. 11.1.3, 11.1.14.
340
10. RUTAREA PACHETELOR
10.1. Esenţă şi metode de rutare
După cum este menţionat în s. 1.3.2, rutarea pachetelor de date este una
din funcţiile de bază ale nivelului Reţea OSI. Ea constă în direcţionarea
pachetelor pe anumite rute în reţea. De rutarea eficientă depinde în mod critic
funcţionarea cu succes a reţelei. Funcțiile de rutare revin ruterelor. La
recepţionarea unui pachet de date, ruterul îl înscrie în memorie, examinează
adresa destinaţie, determină canalul de ieşire pentru transmiterea de mai
departe a pachetului, îl înregistrează în firul de aşteptare către acest canal şi,
ulterior, când îi vine rândul, îl transmite mai departe.
Există mai multe metode şi o mulţime de algoritmi de rutare. Unele
metode de rutare folosesc tabele de rutare, altele – nu folosesc. Tabelul de
rutare al unui ruter conţine informaţii referitoare la folosirea canalelor de
ieşire, pentru transmiterea pachetelor, în funcţie de nodul destinaţie al
acestora. Un exemplu de tabel de rutare şi de determinare a canalului de
ieşire este prezentat în tabelul 10.1 şi figura 10.1. Bineînţeles, un tabel de
rutare conţine şi alte informaţii.
Tabelul 10.1 Tabelul de către A

rutare al ruterului R pachet B 2
ruterul
Canalul de
Destinaţia 1 R
ieşire 3
A 2 4
B 3 către C către B şi D
C 4 Fig.
Fig. 10.1. Determinarea
x.1. Determinarea
D 3 canaluluidede
canalului ieşire.
ieşire.
Nu folosesc tabele de rutare metodele de rutare aleatoare şi prin inundare.

Metoda de rutare aleatoare prevede transmisia pachetului de către nod
printr-un canal de ieşire, selectat în mod aleator. Metoda este simplă, necesită
puţine resurse, însă nu garantează livrarea pachetelor în timp util. De aceea ea
are caracter mai mult teoretic, decât practic.
La rutarea prin inundare, câte o copie a pachetului este transmisă pe
fiecare din canalele incidente ale ruterului, cu excepţia canalului de intrare a
pachetului în nod. Totodată, în antetul pachetului există un câmp contor.
Starea iniţială a contorului este setată cu o valoare egală cu numărul de salturi
(rutere) pe calea cea mai scurtă a transmisiei pachetului până la destinatar,
plus, de obicei, unu sau doi pentru fiabilitate. La trecerea unui nod, valoarea
341
contorului se reduce cu o unitate. Când valoarea contorului devine egală cu 0,
pachetul se elimină din reţea. Parametrul în cauză se numeşte, de obicei, timp
de viaţă (Time To Live – TTL).
Metoda garantează ajungerea a cel puţin unui exemplar al pachetului pe
calea cea scurtă. Neajunsul principal al acesteia constă în încărcarea
suplimentară a reţelei cu copii de pachete. Metoda se foloseşte, uneori,
pentru transmisia unor mesaje scurte de înaltă operativitate.
Metodele, ce folosesc tabele de rutare, pot fi cu rutare statică şi cu rutare
dinamică (adaptivă). Rutarea statică prevede folosirea unor tabele de rutare
precalculate, conţinutul cărora nu se modifică perioade mari de timp. Pentru
transmisia pachetelor, în fiecare nod, pentru fiecare destinaţie, se foloseşte
una sau câteva rute constante. Tabele de rutare pot, de exemplu, să specifice
cele mai scurte căi între fiecare pereche de noduri sursă-destinaţie. Asemenea
tehnici de rutare necesită recalcularea tabelelor de rutare după fiecare
modificare a topologiei, performanţelor componentelor sau a traficului de
date în reţea. Se folosesc rar şi doar în reţele mici cu fluxuri de trafic relativ
constant.
Este cazul de menţionat, însă, că fluxurile informaţionale în reţele au, de
obicei, un caracter foarte dinamic. Aceasta impune, în scopul unei operări
eficiente, folosirea unor metode de rutare cu adaptare la condiţiile curente.
Dintre clasele de metode de rutare dinamică, se evidenţiază: rutarea izolată,
rutarea centralizată, rutarea distribuită şi rutarea hibridă.
Rutarea dinamică izolată este cea mai simplă dintre metodele de rutare
dinamică. Ea prevede rutarea pachetelor în baza informaţiilor disponibile local
la fiecare nod aparte. Informaţiile locale necesare pot fi:
 tabelul de rutare prestabilit;
 starea curentă a canalelor de ieşire;
 lungimea firelor de aşteptare pentru fiecare canal de ieşire ş.a.
Rutarea dinamică distribuită se bazează pe informaţiile disponibile local la
fiecare nod, ca la rutarea izolată, şi, suplimentar, pe informaţiile de la nodurile
învecinate. Schimbul de informaţii locale între nodurile învecinate se poate
efectua periodic, peste un interval de timp prestabilit, sau numai în cazurile de
modificări semnificative de stare. În ultimul caz, se reduce traficul de
informaţii de serviciu în reţea şi, de asemenea, volumul calculelor de
actualizare a tabelelor de rutare. Metoda a găsit o răspândire largă în reţele,
începând cu reţeaua ARPA.
Rutarea dinamică izolată şi chiar cea dinamică distribuită se bazează pe
informaţii locale şi de aceea se adaptează încet la evenimente îndepărtate în
reţea (acumulări de trafic, întreruperi de linii, căderi de noduri). Rutarea
dinamică centralizată presupune calcularea centralizată a tabelelor de rutare
de către un nod-centru, în baza informaţiilor din toată reţeaua. Fiecare nod al
342
reţelei generează rapoarte de stare şi le transmite la nodul-centru. Centrul
determină rutele raţionale pentru toate fluxurile de pachete, alcătuieşte
tabelele de rutare pentru toate nodurile şi le transmite nodurilor. Atât
rapoartele de stare, cât şi tabelele actualizate de rutare pot fi periodice
(sincrone), la un anumit interval de timp, sau asincrone – la modificări
semnificative de stare.
Deşi rutarea dinamică centralizată se efectuează în baza informaţiilor din
toată reţeaua, ceea ce permite optimizarea globală a soluţiilor de rutare,
soluţiile obţinute sunt aplicate cu întârzieri considerabile. Din alta parte,
rutarea dinamică atât cea izolată, cât şi cea distribuită reacţionează prompt,
însă numai la modificări de stare locale.
Rutarea dinamică hibridă îmbină rutarea centralizată şi cea distribuită:
partea centrală supraveghează situaţia globală în reţea, acţionând relativ
încet; nodurile reacţionează prompt şi independent la modificările locale. La o
repartizare raţională a funcţiilor între centru şi nodurile locale, rutarea
dinamică hibridă este mai eficientă, în ce priveşte utilizarea capacităţii reţelei
şi timpii de întârziere.
10.2. Conceptul rutării pachetelor în Internet

10.2.1. Protocoale de rutare în Internet
În Internet rutarea pachetelor are loc la nivelul Internet. În acest scop se
pot folosi aşa protocoale ca OSPF, RIP, IS-IS, IGRP, EIGRP şi BGP (vezi s. 10.3).
Protocoalele OSPF, RIP, IS-IS şi IGRP servesc pentru rutarea pachetelor în
cadrul sistemelor autonome ale Internet, iar cele BGP şi EIGRP – pentru
rutarea pachetelor între sistemele autonome ale Internet.
10.2.2. Tabele de rutare
Toate protocoalele de rutare a pachetelor în Internet folosesc tabele de
rutare (vezi s. 10.1). Fiecare înregistrare (linie) într-un tabel de rutare
reprezintă o regulă de rutare, denumită şi rută.
Parametri obligatorii ai unei rute sunt adresa destinaţie (Destination
Address) şi adresa IP a porţii (Gateway) pentru această destinaţie. Adresă
destinaţie este adresa reţelei, de care ţine staţia, căreia îi este adresat
pachetul rutat. Poartă este interfaţa ruterului adiacent, către care trebuie de
transmis pachetul cu adresa destinaţie dată. Astfel, poarta, definită prin
adresa IP a interfeţei respective, şi specifică în tabelul de rutare canalul de
ieşire pentru pachetele cu adresa destinaţie dată.
Astfel, la determinarea canalului de ieşire, pentru transmisia de mai
departe a pachetului dat, ruterul se bazează pe adresa IP a reţelei destinaţie a
pachetului şi adresa IP a porţii pentru destinaţia în cauză.
343
Un exemplu de tabel de rutare este prezentat în figura 10.2.
Fig. 10.2. Un tabel de rutare în WinBox.

În figura 10.2, Dst. Address este adresa destinaţie a pachetului, iar
Gateway (poarta) – adresa interfeţei către care ruterul trebuie să transmită
pachetul cu adresa destinaţie în cauză. Pentru prima înregistrare din tabel,
adresa IP a porţii este 192.168.1.1.
Poarta, conform definiţiei, se specifică prin adresa IP a interfeţei ruterului
adiacent, către care trebuie de transmis pachetul. Cu alte cuvinte, ea se
specifică prin adresa IP a receptorului canalului de transfer date de ieşire. Dar,
în cazul canalelor punct-la-punct, care şi se folosesc, de obicei, pentru
transferul de date între rutere, canalul are şi o singură interfaţă
transmiţătoare. Ţinând cont de acest fapt, începând cu versiunea 3, RouterOS
permite specificarea porţii şi prin interfaţa ruterului sursă a pachetului. Un
asemenea exemplu este prezentat în fig. 10.2 – ultimele trei înregistrări:
interfeţele wlan1 şi ether2.
10.2.3. Ruta cea mai specifică
Se poate întâmpla ca adresei destinaţie date în tabelul de rutare îi
corespund, dacă nu se ia în considerare dimensiunea reţelei, mai multe rute –
rute cu diferite porţi. În asemenea cazuri pachetul se va transmite conform
rutei, adresa reţelei destinaţie a căreia are cel mai mare prefix de reţea. O
asemenea rută se numeşte ruta cea mai specifică.
Exemplul 10.1. Determinarea rutei celei mai specifice. Fie este necesar de
rutat un pachet către o stație cu adresa IP 192.168.20.2, folosind tabelul de
rutare prezentat în tabelul 10.2.
Tabelul 10.2. Tabelul de rutare pentru exemplul 10.1
Nr. Adresa destinaţie Poarta
0 0.0.0.0/0 172.16.1.5
1 192.168.20.0/24 172.16.1.1
2 192.168.20.0/30 172.16.1.2
În exemplul din tabelul 10.2, adresa IP 192.168.20.2 ține atât de rețeaua
192.168.20.0/24, care pentru stații poate folosi 254 de adrese [192.168.20.1;
344
192.168.20.254], cât și de rețeaua 192.168.20.0/30, care pentru stații poate
folosi 2 adrese [192.168.20.1; 192.168.20.2]. Totodată, pentru adresa
destinație 192.168.20.0/24, regula 1 de rutare specifică folosirea porții
172.16.1.1, iar, pentru adresa destinație 192.168.20.0/30, regula 2 de rutare
specifică folosirea porții 172.16.1.2. Într-un asemenea caz, conform regulii
rutei celei mai specifice, din cele două porți se va folosi poarta 172.16.1.2
(ruta 2), deoarece aceasta corespunde adresei destinație cu cel mai mic
diapazon de adrese pentru stații: adresa reţelei destinaţie are prefixul de reţea
/30, pe când ruta 1 are prefixul de reţea /24.
10.2.4. Ruta şi poarta implicite
Prin definiție, fiecare pachet este rutat conform adresei destinație, adică a
adresei IP a rețelei, de care ține stația, căreia îi este destinat pachetul. Dar
asemenea rețele pot fi foarte multe. Specificarea, în tabelul de rutare, a unei
reguli de rutare aparte, pentru fiecare asemenea adresă destinație, este
laborioasă, costisitoare și de durată. Mai mult ca atât, și procesarea unui
asemenea tabel de către ruter va cere multe calcule.
Soluția propusă este simplă. Rutele, descrise în s. 10.2.2, sunt rute
explicite, în sensul că fiecare din ele specifică o adresă destinație concretă.
Pentru a depăși multitudinea de adrese destinație, de rând cu rutele explicite,
oportune din diverse considerente, în tabel se înscrie și o rută implicită. Ruta
implicită este ruta pentru toate pachetele, adresa destinație a cărora nu
corespunde nici uneia din rutele explicite ale tabelului de rutare. Dacă în
tabelul de rutare este o rută implicită, atunci procedura de selectare a rutei în
acest tabel nu va cădea nicicând.
Adresa destinație a rutei implicite este 0.0.0.0/0. Această adresă specifică
toate adresele destinație, ce nu sunt prezente în rutele explicite ale tabelului
de rutare.
Bineînțeles, adresei destinație 0.0.0.0/0 a rutei implicite trebuie să-i
corespundă, în tabelul de rutare, o anumită poartă. O asemenea poartă se
numește poartă implicită. În exemplul din figura 10.2 aceasta este 192.168.1.1,
iar în cel din tabelul 10.2 poarta implicită este 172.16.1.1.
10.2.5. Distanța rutei
Un parametru important, folosit la rutarea pachetelor, este distanța
(Distance) sau costul rutei. În exemplul din figura 10.2, prima rută are distanţa
1, ceea ce semnifică o distanţă de un singur salt până la următorul ruter;
celelalte trei rute au distanţa 0, ceea ce semnifică faptul că este vorba de
interfeţe ale ruterului curent.
Distanţa este o valoare atribuită rutei, în scopul prioritizării diverselor rute
către aceeași destinație. Astfel, dacă pentru o anumită destinație în tabelul de
rutare sunt mai multe rute, ruterul o va selecta pe cea care are distanța cea
345
mai mică. Implicit, ruterul atribuie rutelor distanțe anumite, în funcție de
protocolul folosit, dar, la necesitate, aceste valori pot fi modificate.
Exemplul 10.2. Determinarea rutei după distanță. Fie este necesar de
rutat un pachet către o stație cu adresa IP 192.168.20.2, folosind tabelul de
rutare prezentat în tabelul 10.3.
Tabelul 10.3. Tabelul de rutare pentru exemplul 10.2
Nr. Adresa destinaţie Poarta Distanța
0 0.0.0.0/0 172.16.1.1 30
1 192.168.20.0/24 172.16.2.1 10
2 192.168.20.0/24 172.16.3.1 20
În exemplul din tabelul 10.3, adresa IP 192.168.20.2 ține de rețeaua
192.168.20.0/24, la care se poate ajunge atât prin poarta 172.16.2.1, cât și
prin cea 172.16.3.1. Din aceste două rute (rutele 1 și 2), ruterul o va alege pe
cea 1, deoarece aceasta are o distanță mai mică și anume 10, pe când ruta 2
are distanța 20.
10.2.6. Rute statice şi rute dinamice
Rutele unui tabel de rutare pot fi statice sau dinamice (vezi și s. 10.1).
Rutele statice sunt definite manual de către administratorii de rețea și nu se
modifică, de obicei, perioade mari de timp. Totodată, la modificarea
topologiei, a performanţelor componentelor sau a traficului de date în reţea,
deseori este oportună redefinirea rutelor, ceea ce nu este prea comod. Este
foarte laborioasă rutarea statică în reţele de dimensiuni mari. De aceea
rutarea statică se folosește mai rar şi doar în reţele mici cu fluxuri de trafic
relativ constante. Unele exemple de rute statice sunt prezentate în ss. 10.2.8,
10.5.
Mai comodă în utilizare este, de regulă, rutarea dinamică; aceasta prevede
recalcularea adaptivă a rutelor, odată cu modificarea stării rețelei și în
anumite alte situații. Asemenea rute se numesc dinamice. Unele rute dinamice
sunt definite de către sistemul de operare al ruterului la configurarea
adreselor IP ale interfețelor, iar altele sunt calculate de protocolul de rutare
dinamică folosit. Rutarea dinamică poate folosi mai multe resurse ale ruterelor
comparativ cu cea statică.
La protocoale de rutare dinamică se referă: RIP, OSPF; IS-IS, BGP, IGRP,
EIGRP ş.a. Unele din acestea sunt descrise în s. 10.3.
10.2.7. Rute multicale
În unele cazuri, de exemplu pentru echilibrarea traficului de date în reţea,
poate fi necesară folosirea a mai mult de o cale către o destinaţie dată.
Totodată, într-un tabel de rutare nu poate fi mai mult de o rută activă către o
destinaţie.
346
Rutele multicale de cost egal (Equal cost multipath – ECMP) conţin mai
mult de o poartă. Rutele ECMP pot fi definite de protocolul OSPF sau manual.
10.2.8. Alți parametri ai rutelor
De rând cu parametrii, descrişi în ss. 10.2.2-10.2.5, rutele pot fi conectate
şi, de asemenea, caracterizate, în funcţie de sistemul de operare folosit, şi de
parametri de stare (activă, inactivă, inaccesibilă), de origine (RIP, OSPF, BGP,
etc.) ş.a.
Conectată (Connected) este rută către o subreţea conectată direct la ruter.
Asemenea rute se formează în mod automat la configurarea adreselor IP ale
interfeţelor ruterului.
Fiecare rută poate fi în una din trei stări: activă, inactivă și inaccesibilă.
Activă este ruta care este selectată pentru a fi folosită la transmisia
pachetelor. În exemplul 10.1 din s. 10.2.3 activă este ruta 2, iar în exemplul
10.2 din s. 10.2.4 – ruta 1. Totodată, ruta 2, în exemplul 10.2 din s. 10.2.4, este
inactivă, deoarece cedează rutei 1; dacă însă interfața pentru ruta activă este
dezactivată, atunci și ruta respectivă (ruta 1, în cazul din în exemplul 10.2)
devine inactivă și se activează ruta inactivă respectivă (ruta 2, în cazul din în
exemplul 10.2), care poate fi considerată ca una de rezervă. Inaccesibilă este
ruta care, la moment, nu asigură accesul la destinația specificată.
Alţi parametri ai rutelor, în raport cu sistemul RouterOS, sunt descrişi în s.
10.4.
10.2.9. Un exemplu de definire a rutelor statice
Exemplul 10.3. Fie se cere crearea tabelelor de rutare statică ale ruterelor
R1 şi R2 din figura 10.3, astfel ca să fie posibil schimbul de date între
calculatoarele subreţelelor LAN1 şi LAN2 şi, de asemenea, accesul acestora la
Internet. Calculatoarele subreţelei LAN1, cu adresa de reţea 192.168.1.0/24,
sunt conectate la interfaţa ether2 cu adresa 192.168.1.1 a ruterului R1, iar
interfaţa ether1 cu adresa 192.168.2.1/30 a ruterului R1 este conectată la
interfaţa ether2 cu adresa 192.168.2.2/30 a ruterului R2. La interfaţa ether3 cu
adresa 192.168.3.1 a ruterului R2 sunt conectate calculatoarele subreţelei
LAN2, cu adresa de reţea 192.168.3.0/24, iar interfaţa ether1 cu adresa
172.16.1.2/30 a ruterului R2 este conectată la interfaţa (poarta) cu adresa
172.16.1.1 a ruterului furnizorului de servicii Internet.
În acest exemplu, adresele IP ale interfeţelor implicate ale ruterelor R1 şi R2
sunt deja configurate. După cum a fost menţionat în s. 10.2.7, odată cu
configurarea adreselor IP ale interfeţelor ruterului, se formează, în mod
automat, şi rutele conectate, adică rutele către subreţelele conectate direct la
ruter. În exemplul 10.3, rute conectate sunt:
 pentru ruterul R1:
- adresa destinaţie 192.168.2.0/30, poarta ether1;
347
 pentru ruterul R2:
- adresa destinaţie 192.168.3.0/24, poarta ether3.
Internet
172.16.1.1
LAN1
LAN2
R1 R2
192.168.1.2
172.16.1.2
192.168.1.1 192.168.2.1 192.168.2.2
192.168.3.1 192.168.3.2
Fig. 10.3. Schema reţelei de calculatoare la exemplul 10.3.

Din figura 10.3 se poate observa că poarta, pentru accesul la Internet de la
ruterul R2, are adresa IP 172.16.1.1. Aceasta poate servi ca poartă implicită
pentru toate destinaţiile pachetelor de tranzit prin ruterul R2, cu excepţia celor
către calculatoarele subreţelei LAN1 şi al celor către calculatoarele subreţelei
LAN2. Pentru accesul calculatoarelor subreţelei LAN2 la calculatoarele
subreţelei LAN1, adică către adresa destinaţie 192.168.1.0/24, este necesar de
definit o rută cu poarta 192.168.2.1. Astfel, obţinem tabelul de rutare al
ruterului R2, prezentat în tabelul 10.4.
Tabelul 10.4. Tabelul de rutare al ruterului R2 din exemplul 10.3
0 0.0.0.0/0 172.16.1.1
1 192.168.1.0/24 192.168.2.1
2 172.16.1.0/30 ether1
3 192.168.2.0/30 ether2
4 192.168.3.0/24 ether3
În ce priveşte tabelul de rutare al ruterului R 1, acesta are o singură
conexiune către reţele exterioare – cea către ruterul R2; celelalte conexiuni
sunt locale. Astfel, pentru toate adresele destinaţie către exterior, poarta, care
totodată este şi implicită, are adresa 192.168.2.1. Tabelul de rutare al ruterului
R2 este prezentat în tabelul 10.5.
Tabelul 10.5. Tabelul de rutare al ruterului R1 din exemplul 10.3
0 0.0.0.0/0 172.16.2.1
1 192.168.2.0/30 ether1
2 192.168.1.0/24 ether2
348
10.3. Protocoale de rutare
10.3.1. Protocolul informaţiilor de rutare RIP
Protocolul RIP (Routing Information Protocol – Protocolul informaţiilor de
rutare) este un protocol de rutare vector-distanţă în cadrul sistemelor
autonome ale Internet şi foloseşte, în calitate de metrică a căilor, numărul de
salturi „staţie-staţie”. Pentru calcularea rutelor, RIP foloseşte algoritmul
Bellman-Ford. În mod obişnuit, fiecare ruter transmite informaţii de
actualizare a tabelelor de rutare odată la 30 s.
RIP a cunoscut trei versiuni: RIPv1 aprobat în 1988 (RFC 1058), RIPv2,
propus în 1993 (RFC 1388) şi dezvoltat în 1998 (RFC 2453), şi RIPng, aprobat în
1997 (RFC 2080). Pentru distribuirea informaţiilor de rutare, RIPv1 foloseşte
difuzarea, iar RIPv2 şi cel RIPng – transmisii multiadresat. De asemenea, RIPv1
nu suportă măştile de subreţea, pe când RIPv2 operează cu acestea şi, de
asemenea, foloseşte un mecanism simplu de autentificare.
RIPv2 operează cu IPv4, ţine cont de informaţiile de subreţele suportând
CIDR. De asemenea, RIPv2 transmite tuturor ruterelor adiacente întregul tabel
de rutare la adresa multiadresat 224.0.0.9. Pentru aplicaţii speciale, se pot
folosi chiar adrese monoadresat. În 1997, pentru RIPv2 este implementată
autentificarea MD5 (RFC 1321).
RIP de generaţia următoare (RIP next generation – RIPng) este o extensie a
RIPv2 pentru IPv6. Principalele deosebiri ale RIPng faţă de RIPv2 sunt:
 suportă operarea cu IPv6;
 nu suportă autentificarea prin actualizarea RIPv1 (RIPv2 suportă).
Ruterele IPv6 folosesc pentru autentificare IPsec;
 nu permite atribuirea unor etichete (tags) arbitrare rutelor (RIPv2
permite);
 necesită codificarea specială a următorului salt pentru un set de intrări
ale rutei, pe când IPv2 codifică următorul salt în intrările fiecărei rute;
 RIPng transmite informaţiile de rutare prin portul UDP 521, folosind
grupul multiadresat ff02::9, pe când RIPv2 le transmite prin portul UDP
520.
Avantaje RIP. RIP este bine testat şi simplu de implementat. În reţele de
mici dimensiuni el consumă puţine resurse.
Dezavantaje RIP. Informaţiile RIP se transmit prin UDP, dimensiunea
maximă a segmentelor căruia este de 512 octeţi. Aceasta permite
transmiterea a până la 25 de înregistrări de rute, în caz contrar trebuie de
folosit mai multe segmente UDP. De asemenea, la RIP numărul maximal de
salturi pe o cale de la sursă până la destinaţie nu trebuie să depăşească 15.
Distanţa de 16 salturi este folosită pentru a specifica rutele inaccesibile,
349
inoperabile sau nedorite din anumite considerente. În reţele mari, traficul RIP
poate consuma relativ multe resurse.
Generalizare. RIP este mai simplu, decât alte protocoale pentru sisteme
autonome, dar are anumite neajunsuri şi în prezent se foloseşte mai rar, de
obicei în reţele de dimensiuni relativ mici. Un protocol vector-distanţă similar
celui RIP este Interior Gateway Routing Protocol (IGRP), înlocuit ulterior cu
Enhanced IGRP (EIGRP), ambele elaborate de compania Cisco. Aceste două
protocoale suportă metrici multiple, inclusiv lăţimea de bandă, durata
reţinerii, încărcarea, MTU şi fiabilitatea.
10.3.2. Protocolul OSPF
10.3.2.1. Caracterizare generală a OSPF
Protocolul OSPF (Open Shortest Path First – deschide, mai întâi, calea cea
mai scurtă) este un protocol de rutare în cadrul sistemelor autonome ale
Internet (deci de tip IGP – Interior Gateway Protocol), ce se bazează pe starea
legăturilor (link state). În general, „Open” în denumire specifică faptul că OSPF
este un protocol deschis, public. Prin sistem autonom (Autonomous System –
AS) Internet se are în vedere un fragment de reţea, în care, pentru schimbul
de informaţii de rutare între rutere, se foloseşte acelaşi protocol de rutare.
OSPF estre un protocol dinamic de rutare cu identificarea operativă a
modificărilor topologice în reţea şi recalcularea corespunzătoare a tabelelor de
rutare. În acest scop, OSPF defineşte determinarea şi distribuirea dinamică
între rutere a informaţiilor de rutare a pachetelor. Fiecare ruter al AS
determină starea tuturor conexiunilor (legăturilor) între sine şi vecini-
adiacenţi, pe care o stochează în baza de date de stare a legăturilor (link state
database – LSDB). Totodată, modificările ce au loc în LSDB proprie le comunică
şi celorlalte rutere ale AS, care, la rândul lor, actualizează LSDB proprii. În LSDB
este stocată starea conexiunilor (legăturilor) între toate ruterele adiacente ale
AS. Toate LSDB ale ruterelor AS sunt identice şi conţin informaţia topologică
privind întregul AS. În baza acestor informaţii, fiecare ruter, folosind algoritmul
Dijkstra, determină arborele minim propriu către toate celelalte rutere ale AS,
rădăcină a acestui arbore fiind el însuşi.
Informaţiile de rutare, transmise între rutere, sunt denumite anunţuri de
stare-legături (Link-State Advertisments – LSA). Din aceste anunţuri, fiecare
ruter află ce rutere sunt în reţea, ce interfeţe ele au, legăturile între rutere,
costul fiecărei legături, etc.
Informaţia privind vecinii (conectivitatea locală) şi rutele este transmisă în
reţea, folosind transportul multiadresat. Pachetele OSPF multiadresat sunt
transmise doar ruterelor adiacente. În acest scop OSPF foloseşte (RFC 2328,
RFC 5340) adresele multiadresat IPv4 224.0.0.5 şi IPv6 ff02::5, pentru toate
350
ruterele SPF-stare legătură (AllSPFRouters), şi cele IPv4 224.0.0.6 şi IPv6
ff02::6, pentru toate ruterele desemnate (AllDRouters).
Pentru rutarea de trafic IP multiadresat, OSPF suportă protocolul MOSPF
(Multicast OSPF – OSPF multiadresat), definit în RFC 1584. Mai larg în acest
scop este folosit protocolul PIM (Protocol Independent Multicast – Protocolul
multiadresat independent), definit în RFC 4601, RFC 3569, RFC 3973 şi RFC
5015. PIM se foloseşte împreună cu OSPF sau alte protocoale de rutare (de
exemplu, RIP, BGP), deoarece el nu realizează funcţii de identificare a
topologiei reţelei.
Fiecare stare-legătură se caracterizează prin metrica de „cost”. În baza
informaţiei privind vecinii şi starea legăturilor acestora, OSPF calculează
tabelul de rutare, aplicând algoritmul Dijkstra.
OSPF suportă folosirea CIDR. În cazul unor sisteme autonome de mari
dimensiuni, OSPF împarte AS respectiv, denumit şi domeniu OSPF, în mai
multe zone gestionate aparte. În fiecare asemenea zonă se aplică o copie
aparte a algoritmului de rutare OSPF. Ruterele ce au interfeţe în mai multe
zone, rulează câte o copie a algoritmului de rutare pentru fiecare zonă aparte.
Totodată, OSPF sintetizează informaţiile privind rutele pentru ruterele fiecărei
zone, reducând astfel numărul de rute anunţate şi, respectiv, încărcarea
reţelei. De asemenea, în scopul reducerii cantităţii şi frecvenţei anunţurilor de
stare-legături, OSPF foloseşte rutere desemnate.
În linii mari, pentru ca o reţea OSPF să devină funcţională, sunt necesare
aşa acţiuni ca:
 descoperirea vecinilor;
 actualizarea (sincronizarea) LSDB;
 calcularea rutelor.
Spre deosebire de protocoalele de rutare RIP şi BGP, care folosesc
protocoale de nivel transport (UDP sau TCP), informaţiile OSPF se încapsulează
direct în pachete IP cu numărul de protocol 89 (vezi tabelul A4.1). Funcţiile de
detectare şi corectare a erorilor în cadrul acestor informaţii sunt de asemenea
realizate de OSPF.
OSPF pentru IPv4 este securizat, folosind metode de autentificare care
permit implicarea în rutarea de pachete doar a ruterelor respective. OSPFv3
nu suportă autentificarea internă, securizarea necesară asigurându-se de
IPsec.
De rând cu protocolul IS-IS (Intermediate System to Intermediate System –
Sistem intermediar către Sistem intermediar) propus de corporaţia Digital
Equipment (OSI DP 10589, RFC 1142), dezvoltarea acestuia – IS-IS integrat
(Integrated IS-IS, RFC 1195), şi cel EIGRP (Enhanced Interior Gateway Routing
Protocol), propus de compania Cisco, OSPF este unul din cele mai folosite
protocoale de rutare în cadrul sistemelor autonome.
351
OSPF a cunoscut trei versiuni: OSPFv1 aprobat în 1990 (RFC 1058), OSPFv2
propus în 1998 (RFC 2328) şi OSPFv3 aprobat în 2008 (RFC 5340) şi folosit cu
IPv6.
10.3.2.2. Zone OSPF
În scopul facilitării şi eficientizării administrării, îndeosebi în cazul unor AS
cu multe rutere, un domeniu OSPF poate fi împărţit în două sau mai multe
zone de rutare OSPF, formând o topologie ierarhică cu două nivele: zona
nucleu (backbone) şi celelalte zone – zone ordinare, ataşate la prima. Fiecare
zonă rulează o copie separată a algoritmului de bază OSPF. Zonele reprezintă
grupuri de rutere gestionate aparte şi sunt interconectate prin rutere
marginale ale zonelor (Area Border Router – ABR). Schimbul de informaţii de
rutare între rutere se efectuează local, în cadrul fiecărui grup. Rutarea între
zone se efectuează prin intermediul ABR. Totodată, informaţiile de rutare,
privind zona respectivă pentru mediul exterior, pot fi sintetizate, reducând
astfel volumul lor. Fiecare zonă menţine, în cadrul ABR, o bază de date de
stare a legăturilor şi rutele din zonă.
Sunt definite mai multe tipuri de zone OSPF: nucleu (backbone), ciot (stub)
şi de tranzit.
Zonă nucleu este zona OSPF, la care sunt conectate toate celelalte zone
OSPF. Conectarea zonelor ordinare la zona nucleu poate fi directă sau virtuală
(prin legături virtuale – tunele). Zona nucleu este responsabilă de distribuirea
informaţiilor de rutare între zonele AS.
Zonă de tranzit este zona OSPF cu două sau mai multe rutere marginale
OSPF şi serveşte pentru tranzitarea de trafic de date de la o zonă adiacentă la
alta. O asemenea zonă nu generează asemenea trafic şi nici nu este destinaţie
a acestuia. Tranzitarea de trafic se efectuează prin legături virtuale-tunele
între ruterele marginale ale zonei de tranzit respective. Legăturile virtuale sunt
identificate prin ID-ruter al ruterului marginal de ieşire din zona de tranzit.
Legăturile virtuale sunt parte a Zonei nucleu. Pentru înaintarea pachetelor, o
asemenea legătură foloseşte rutarea intrazonală a zonei sale de tranzit.
Zonă ciot se numeşte zona OSPF, care nu primeşte înştiinţări de rută
externe faţă de AS, iar rutarea din cadrul zonei se bazează integral pe ruta
implicită. Există şi zone nu-complet-ciot (not-so-stubby area – NSSA) – zone
care pot importa anunţuri de rute externe faţă de AS şi să le trimită altor zone,
dar nu pot însă primi, de la alte zone ale AS, rute externe faţă de AS. Această
funcţionalitate permite, deşi într-un mod limitat, injectarea de rute externe
într-o zonă ciot. Un caz particular de zone ciot, sunt zonele complet ciot
(totally stubby area – TSA) – zone, în care rutele interzonale nu sunt
sintetizate. Unica cale de a ruta trafic înafara unei asemenea zone este ruta
implicită. Astfel, zonele TSA pot avea doar un singur ABR.
352
Fiecare zonă OSPF se identifică printr-un număr pe 32 biţi (inclusiv pentru
IPv6), scris, ca şi adresele IPv4, în formă de patru numere zecimale separate
prin punct. Zona nucleu a AS are ID-ul 0.0.0.0, uneori notat şi 0. Pentru fiecare
din celelalte zone, în calitate de ID poate fi folosită adresa IP a unui ruter din
zona respectivă, denumit uneori şi ruter principal al zonei OSPF.
10.3.2.3. Rutere OSPF
Fiecare ruter OSPF are un identificator, denumit ID ruter, care reprezintă o
adresă IP. Acesta se specifică, în cazul IPv4, în format zecimal, de exemplu, ID
ruter 3.2.1.2. ID ruter trebuie să fie stabilit, fie şi manual, în fiecare caz OSPF.
Dacă acesta nu este specificat, atunci în calitate de ID ruter se va folosi (în
ordine de prioritate):
1) cea mai mare adresă IP atribuită unei interfeţe de buclă locală (logică);
2) cea mai mare adresă din cele ale adreselor interfeţelor fizice active ale
ruterului (dacă nu este definită nici o interfaţă de buclă locală).
Din punctul de vedere al rolului în rutarea OSPF, disting patru categorii de
rutere:
1) rutere interne (Internal router – IR);
2) rutere marginale ale zonei (Area border router – ABR);
3) rutere nucleu (Backbone router – BR);
4) rutere marginale ale AS (Autonomous system border router – ASBR).
De menţionat că unul şi acelaşi ruter poate îndeplini funcţiile de una sau
mai multe categorii de rutere. De exemplu, un ruter poate fi atât ABR, cât şi
ASBR. Aceste patru categorii de rutere nu trebuie confundate cu termenii
ruter desemnat (designated router – DR) şi ruter de rezervă (backup
designated router – BDR), care sunt atribute ale interfeţelor de rutere şi nu ale
ruterelor; acestea sunt descrise mai jos în această secţiune.
Ruter intern este fiecare ruter, care ţine de o singură zonă OSPF. Un
asemenea ruter are relaţii de vecin OSPF cu interfeţe doar din aceeaşi zonă.
De categoria ABR este fiecare ruter, care interconectează două sau mai
multe zone OSPF. De obicei ABR conectează una sau mai multe zone ordinare
la zona nucleu. În cazul de legături virtuale, ABR este implicat, de asemenea, în
conectarea zonei, ce foloseşte legătura virtuală, la o altă zonă ordinară. ABR
este componentă a tuturor zonelor, la care este conectat. El păstrează o bază
de date de stare a legăturilor, pentru fiecare zonă la care este ataşat, şi, de
asemenea, rutele pentru toate zonele AS. ABR sintetizează informaţia
topologică a zonelor ataşate pentru distribuire zonei nucleu. Zona nucleu, la
rândul său, distribuie această informaţie altor zone.
Ruter nucleu este fiecare ruter, care are una sau mai multe interfeţe ce ţin
de zona nucleu OSPF. De menţionat că toate ruterele ABR sunt, de asemenea,
şi rutere nucleu, deoarece anume prin intermediul lor zonele ordinare
respective sunt conectate, direct sau virtual, la zona nucleu. Însă pot fi şi
353
rutere nucleu, care nu sunt rutere ABR; la asemenea rutere toate interfeţele
ţin de zona nucleu.
De categoria ASBR este fiecare ruter, care face schimb de informaţii de
rutare şi cu rutere ce ţin de alte sisteme autonome. Un asemenea ruter
rulează două sau mai multe protocoale de rutare, inclusiv un protocol de
rutare exterioară, de exemplu BGP, sau/şi rute statice. ASBR poate fi un ruter
intern sau ABR şi poate fi, dar poate şi să nu fie un ruter nucleu. Calea către
fiecare ASBR este cunoscută de către fiecare ruter al AS. ASBR distribuie, în
cadrul AS propriu, rutele primite de la alte AS şi viceversa. În acest scop, ASBR
creează LSA (Link-State Advertisment) externe pentru adrese externe şi le
trimite, prin intermediul ABR, la toate zonele din AS propriu. Pentru accesarea
adreselor externe, ruterele din alte zone folosesc ABR respective.
Pentru gestiunea anunţurilor de stare-legături, OSPF alege două sau mai
multe rutere, denumite rutere desemnate şi rutere desemnate de rezervă.
Fiecare zonă OSPF trebuie să aibă un ruter desemnat şi un ruter desemnat de
rezervă.
Ruter desemnat (designated router – DR) se numeşte interfaţa ruterului,
selectată, din mulţimea de interfeţe ale ruterelor unui anumit segment de
reţea multiacces, pentru difuzare multiacces către toate celelalte rutere, prin
LSA-reţea, a informaţiilor de rutare în cadrul acestui segment. ID-ul acestui DR
este adresa IP a interfeţei fizice în cauză. Orice segment de reţea multiacces
are un ruter desemnat. Scopul folosirii DR constă în reducerea traficului de
reţea, în baza unei surse unice de actualizare a informaţiilor de rutare
respective în cadrul unui segment de reţea multiacces. DR menţine topologia
completă a reţelei şi trimite, prin multiadresat, actualizările necesare stare-
legături altor rutere.
Toate ruterele unui segment de reţea multiacces sunt în relaţie
supus/stăpân (slave/master) cu DR, formând „adiacenţe” doar cu DR şi BDR.
Astfel, dacă într-un domeniu de difuzare cu n rutere sunt n(n – 1)/2 relaţii de
vecinătate, atunci la folosirea DR şi BDR, numărul de adiacenţe se reduce de la
n(n – 1)/2 la 2n – 1 (fig. 10.4). Când un ruter trimite o actualizare, el o trimite
către DR şi BDR pe adresa multiadresat 224.0.0.6. DR, la rândul său, trimite
această actualizare către toate celelalte rutere din zonă la adresa multiadresat
224.0.0.5 (AllSPFRouters).
Un ruter poate avea unele interfeţe DR, altele BDR şi terţe – nedesemnate.
Dacă într-o subreţea dată nu există nici DR şi nici BDR, atunci se alege mai întâi
BDR, iar apoi şi DR. Conform RFC 2328, selectarea DR se efectuează în baza
următoarelor criterii:
1) dacă configurarea de prioritate a unui ruter OSPF este 0, atunci acesta
nu poate fi ales nici DR şi nici BDR. Aceasta permite eliminarea
354
ruterelor lente din competiţia de a fi alese DR sau BDR – funcţii,
realizarea cărora presupune consumarea suplimentară de resurse;
2) când un DR cade, atunci BDR îi preia funcţiile şi, totodată, se alege un
nou BDR;
3) este ales ruterul, care trimite pachete Hello de cea mai înaltă prioritate
în intervalul [0; 255];
4) dacă două sau mai multe rutere trimit pachete Hello de cea mai înaltă
prioritate, atunci este ales ruterul cu cel mai înalt ID ruter (router ID –
RID). De menţionat că RID este cea mai înaltă adresă IP logică (buclă
locală) configurată pe ruter, iar dacă aceasta nu este configurată, atunci
ruterul foloseşte cea mai înaltă adresă IP configurată pe interfeţele
active ale lui (de exemplu, adresa 192.168.1.1 este mai înaltă decât cea
10.2.1.2);
5) de obicei, ruterul de prioritatea următoare, după cea mai înaltă, devine
BDR;
6) dacă, după alegerea DR şi BDR, un ruter OSPF de prioritate mai înaltă
este activat în reţea, acesta nu va deveni DR şi nici BDR, până ce nu va
cădea DR sau/şi BDR curent.
BDR
DR
R2
R1
Rn
R3
...
R4 R5
Domeniu de difuzare
Fig. 10.4. Adiacenţe DR şi BDR într-un domeniu de difuzare.

Ruter desemnat de rezervă (backup designated router – BDR) se numeşte
ruterul, care devine DR în cazul, când ruterul desemnat curent cade. BDR este
ruterul OSPF cu cea de a doua cea mai înaltă prioritate în timpul ultimei
alegeri.
355
10.3.2.4. Metrica căilor OSPF
În calitate de metrică de bază, OSPF foloseşte „costul căii”, care se
determină de costul legăturilor componente ale căii în cauză. Factorii de cost
al legăturilor pot fi asociaţi cu distanţa, timpul de reţinere, capacitatea de
transmisie, disponibilitatea, fiabilitatea legăturilor, etc. În practică, totuşi,
acesta se determină, de obicei, de viteza de transfer date (lăţimea de bandă) a
interfeţei, care solicită ruta dată. Compania Cisco, de exemplu, foloseşte
metrica 108/lăţimea de bandă (mărimea 108 poate fi modificată). Astfel, o
legătură de 100 Mbps va avea costul 1, cea de 10 Mbps – costul 10, etc.
Totodată, metricile pot fi comparate doar dacă sunt de acelaşi tip. Disting
patru tipuri de metrici, în ordinea descreşterii preferinţei lor:
1) intrazonă;
2) interzone;
3) externă de tip 1, care include costul căii externe de la ASBR până la
destinaţie în aceeaşi metrică ca şi cea folosită în cadrul AS dat;
4) externă de tip 2, care include costul căii externe de la ASBR către
destinaţia externă, dar într-o metrică de semnificaţie de un ordin mai
mare, decât cea folosită în cadrul AS dat. Costul unei căi externe de tip
2, oricare acesta nu ar fi ca valoare, se consideră mai mare, decât orice
cost al unei căi interne a AS.
10.3.2.5. Tipuri de mesaje OSPF
Pentru schimbul de informaţii cu alte rutere, OSPF foloseşte cinci tipuri de
mesaje (pachete):
 Hello – folosit pentru descoperirea vecinilor-adiacenţi, adică pentru
stabilirea şi menţinerea adiacenţelor cu alte rutere OSPF; mesajele Hello
se folosesc, de asemenea, pentru alegerea ruterelor desemnate (DR) şi a
ruterelor desemnate de rezervă (BDR) ale reţelelor multiacces.
 Link-State Update (LSU – Actualizare stare-legătură) – furnizarea către
vecini a stării unor legături. În acest scop se folosesc mai multe tipuri de
anunţuri stare-legături – LSA (vezi mai jos în această secţiune);
 Link-State Acknowledgement (LSack – Confirmare stare-legătură) –
păstrează o colecţie de înregistrări stare-legături special solicitate.
Permite confirmarea actualizării stării legăturilor;
 Database Description (DD – Descriere bază de date) – conţine
actualizările Bazei de date stare-legături (LSDB) a emiţătorului şi se
foloseşte de către ruterele destinatare pentru actualizarea bazelor de
date proprii. Permite verificarea sincronizării Bazei de date între rutere;
 Link-State Request (LSR – Solicitare stare-legătură) – folosit pentru
solicitarea unor informaţii de actualizare de la baza de date a ruterului
vecin. Informaţiile învechite se identifică în baza schimburilor de date DD;
356
10.3.2.6. Descoperirea vecinilor
Pentru descoperirea vecinilor-adiacenţi ruterele transmit mesaje Hello.
Mesajele Hello se mai numesc şi pachete Hello, deoarece un asemenea mesaj
se încadrează într-un singur pachet. Implicit, ruterele transmit mesaje Hello
fiecare 10 s în segmente punct-la-punct şi multiacces cu difuzare (de exemplu,
Ethernet) şi fiecare 30 s – în segmente multiacces fără difuzare (de exemplu,
Frame Relay, X.25 şi ATM). Acest interval poate fi setat şi manual cu o altă
valoare.
Ruterele vecine răspund tot prin mesaje Hello, în baza cărora se identifică
vecinii şi, respectiv, se creează adiacenţele. Transmiterea şi recepţia periodică
de mesaje Hello permite actualizarea informaţiilor privind vecinii, detectând
cazurile de cădere sau includere în reţea a unor noi vecini. Dacă mesajele Hello
de răspuns nu sosesc în decursul unui interval limită, denumit Dead interval,
valoarea implicită a căruia este de 40 s, atunci se consideră că vecinul în cauză
a căzut sau a fost exclus din reţea.
Operarea protocolului Hello diferă, în funcţie de caracterul segmentului de
reţea conectat la interfaţa respectivă a ruterului. Cel mai simplu este cazul de
segmente punct-la-punct, care presupun un singur vecin.
Două rutere nu devin vecine, dacă nu se îndeplinesc următoarele condiţii:
 este posibilă o comunicare bidirecţională între rutere;
 interfeţele ruterelor aparţin aceleiași zone OSPF;
 interfeţele ruterelor aparţin aceleiași subreţele şi au aceeaşi mască de
reţea, cu excepţia cazului de rețea punct-la-punct;
 ruterele au aceleaşi opţiuni de autentificare şi fac schimb de aceeaşi
parolă, dacă aceasta este setată;
 intervalul Hello şi cel Dead interval în pachetele Hello sunt aceleași;
 rutarea externă (External routing) şi fanioanele NSSA în pachetele Hello
sunt aceleași.
Descoperirea vecinilor în subreţele cu difuzare. În general, reţea cu
difuzare se numeşte reţeaua cu mai mult de două noduri ce suportă adresarea
unui singur mesaj fizic tuturor nodurilor reţelei, altfel reţeaua este una non-
difuzare.
Într-o subreţea cu difuzare, cum este Ethernet, fiecare pachet este
recepţionat de toate nodurile ataşate, ceea ce permite realizarea simplă a
transmiterii/recepţiei de pachete multiadresat. Aceste proprietăţi ale
subreţelelor cu difuzare sunt folosite de OSPF pentru regăsirea vecinilor şi
identificarea conectivităţii bidirecţionale între rutere.
În acest scop se creează reţeaua cu difuzare OSPF, fiecare ruter înscriindu-
se în grupul AllSPFRouters cu adresa IP 224.0.0.5. Pentru a trimite un pachet
Hello multiadresat ruterelor grupului AllSPFRouters, acesta se trimite la adresa
IP 224.0.0.5. Astfel, în loc de a trimite câte un exemplar al pachetului fiecărui
357
ruter aparte, un singur pachet Hello se trimite la adresa IP 224.0.0.5 şi acesta
este recepţionat de toate ruterele grupului.
La avantajele acestei modalităţi de trimitere a pachetelor Hello se referă:
 descoperirea vecinilor în mod automat, prin trimiterea de pachete Hello
multiadresat sau cu difuzare;
 reducerea încărcării capacităţii mediului de transmisie cu pachete Hello,
prin trimiterea a n pachete Hello, în loc de n*(n – 1)/2, unde n este
numărul de rutere în subreţeaua de difuzare;
 dacă subreţeaua dispune de capabilitatea multiadresat, atunci OSPF
operează fără a distribui pachete Hello nodurilor non-OSPF. În caz
contrar, toate ruterele subreţelei vor primi pachete Hello prin difuzare,
inclusiv cele non-OSPF.
Descoperirea vecinilor în subreţele NBMA. Subreţelele multiacces fără
difuzare (nonbbroadcast multiaccess – NBMA), ca şi cele cu difuzare, suportă
mai mult de două rutere, deosebirea fiind în aceea că NBMA nu suportă
capabilitatea de difuzare la nivel Legătură de date. Din cauza aceste limitări,
vecinii OSPF trebuie să fie, iniţial, descoperiţi prin configurarea sistemului de
operare. În scopul reducerii traficului de pachete Hello, majorităţii ruterelor
subreţelei NBMA trebuie să li se atribuie prioritatea 0, pe când ruterele
eligibile ca desemnate (DR) trebuie să li se atribuie o prioritate diferită de 0.
Aceasta asigură trimiterea de pachete Hello, la alegerea DR şi BDR, doar
ruterelor eligibile.
Descoperirea vecinilor în subreţele P2MP. În subreţele punct-la-
multipunct (point-to-multipoint – P2MP) pachete Hello se trimit tuturor
ruterelor subreţelei. În asemenea subreţele nu se aleg rutere DR şi BDR.
10.3.2.7. Anunţuri stare-legături
Pentru a descrie starea legăturilor proprii, ruterele folosesc anunţuri stare-
legături (Link-State Advertisment – LSA). Anunţurile LSA sunt stocate de către
fiecare ruter în propria Bază de date stare-legături (Link-State Data Base –
LSDB). Un ruter are câte o LSDB pentru fiecare zonă, la care aparţine. Toate
ruterele unei zone au LSDB identice. LSDB zonală este compusă din LSA-rutere
(Tip 1), LSA-reţele (Tip 2) şi LSA-sumare (Tip 3). Suplimentar, LSA-externe se
conţin în toate LSDB ale zonelor non-ciot (vezi mai jos în această secţiune).
Când OSPF este lansat pe un ruter, el creează o LSDB, care conţine o singură
intrare – „LSA-ruter” al acestui ruter.
LSDB descrie un graf orientat, vârfurile căruia sunt rutere şi reţele. Fiecare
arc al grafului uneşte două rutere şi reprezintă reţeaua punct-la-punct, la care
sunt ataşate aceste rutere. Un arc, care uneşte un ruter la o reţea, arată că
ruterul are o interfaţă în această reţea.
Reţelele pot fi de tranzit şi ciot (similar frunzei într-un graf). Reţelele de
tranzit pot transmite şi trafic de tranzit – trafic de origine externă faţă de reţea
358
şi adresat către o destinaţie tot din afara acesteia. O asemenea reţea se
reprezintă în graf printr-un vârf, la care sunt ataşate arce atât de intrare, cât şi
de ieşire. Un vârf, ce reprezintă o reţea ciot, are ataşate doar arce de intrare.
Vecinătatea fiecărui nod de reţea în graf depinde de tipul reţelei şi numărul
ruterelor ce au o interfaţă în această reţea. Tipul reţelei poate fi: punct-la-
punct, cu difuzare, multiacces non-difuzare (non-broadcast multiaccess –
NBMA) sau punct-la-multipunct (fig. 10.5).
În figura 10.5a sunt reprezentate, în partea stângă, două rutere
interconectate printr-un canal (link – legătură) punct-la-punct, iar în partea
dreaptă graful LSDB al reţelei punct-la-punct în cauză. De menţionat că graful
prezintă aparte informaţii pentru fiecare din cele două direcţii de transfer date
între cele două rutere. Fiecărei interfeţe de ruter al unei reţele punct-la-punct,
Ia şi Ib în acest caz, trebuie să-i fie atribuită o adresă IP. Respectiv, fiecare din
ele este modelată ca o legătură ciot, pe care ruterul respectiv o anunţă ca o
conexiune ciot către o altă interfaţă ruter. Opţional, o reţea punct-la-punct
poate fi reprezentată printr-o subreţea IP. În asemenea caz, ambele rutere, în
loc să anunţe adresele IP ale interfeţelor, anunţă o legătură ciot către
subreţeaua IP.
În mod similar poate fi interpretată esenţa LSDB şi a tipurilor de reţea,
prezentate în figurile 10.5b şi 10.5c. Reţelele cu difuzare şi cele NBMA se
reprezintă în acelaşi mod. De tip NBMA sunt reţelele în care toate ruterele pot
comunica direct (multiacces). De menţionat că fiecare staţie, conectată direct
la un ruter, se reprezintă în graful LSDB ca o reţea ciot.
Fiecare reţea în graful LSDB are o adresă IP şi, la IPv4, o mască de reţea.
În reţelele non-difuzare, OSPF poate opera în două moduri: NBMA şi punct-
la-multipunct (P2MP). În modul NBMA, OSPF emulează operarea într-o reţea
cu difuzare: se alege un ruter desemnat (DR), care generează LSA pentru
reţea. Grafurile de reprezentare a reţelelor cu difuzare şi ale celor NBMA sunt
identice (fig. 10.5b). Modul NBMA este cel mai eficient pentru operarea OSPF
în reţele non-difuzare. Însă acesta poate fi folosit doar în cazurile, când toate
ruterele reţelei pot comunica direct. Dacă această condiţie nu se îndeplineşte,
atunci sau reţeaua se împarte în subreţele, în care toate ruterele pot comunica
direct, sau se aplică modul punct-la-multipunct.
În cazul de reţele punct-la-multipunct non-difuzare, OSPF tratează toate
conexiunile ruter-ruter ca şi cum acestea ar fi legături punct-la-punct. Pentru
reţea nu se alege nici un ruter desemnat. Un exemplu de reţea punct-la-
multipunct este prezentat în figura 10.6.
359
Schema retelei Graful LSDB al retelei
R1 R2 De Către
Ia Ib la R1 R2 Ia Ib
R1 + +
R2 + +
a) Retea fizica punct-la-punct
R7 De Către
N3 la R7 N3
R7 +
N3
b) Retea ciot (stub)
R3 R4
De Către
la R3 R4 R5 R6 N2
R3 +
N2 R4 +
R5 +
R6 +
N2 + + + +
R5 R6
c) Retea cu difuzare sau NBMA
Fig. 10.5. Patru tipuri de retele (R – ruter, N – retea,

I – interfata ruter, + – interconexiune) [RFC 2328].
În reţeaua din fig. 10.6, se presupune că toate ruterele pot comunica

direct, cu excepţia celor R4 şi R5, iar I3-I6 sunt adresele IP ale interfeţelor
ruterelor respective. În LSDB, ruterele, care pot comunica direct, sunt
interconectate prin arce bidirecţionale şi, de asemenea, fiecare din ele are o
conexiune ciot către adresa IP a interfeţei proprii, spre deosebire de
reprezentarea unei legături punct-la-punct reale în fig. 10.5a.
OSPFv2 şi OSPFv3 folosesc 11 tipuri de LSA (RFC 2328, RFC 5340):
360
 Tip 1 – „LSA-ruter”, prin care ruterul descrie starea şi costul legăturilor
sale către alte rutere sau reţele învecinate ale aceleiaşi zone şi, de
asemenea, dacă el este ABR, ASBR sau punct terminal (endpoint) al uneia
sau al mai multor legături virtuale. LSA tip 1 se generează de fiecare ruter
şi se transmit, prin inundare, doar ruterelor aceleiaşi zone cu ruterul
sursă. ID stare-legătură al LSA tip 1 este ID-ruter al sursei;
R3 R4
I3 I4 De Către
la R3 R4 R5 R6 I3 I4 I5 I6
N2 R3 + + + +
R4 + + +
I5 I6 R5 + + +
R6 + + + +
R5 R6
Fig. 10.6. Schema si LSDB ale unei retele punct-la-multipunct [RFC 2328].
 Tip 2 – „LSA-reţea”, prin care DR al unui segment multiacces (de

exemplu, Ethernet) descrie toate ruterele acestui segment. LSA-reţea se
generează pentru fiecare reţea de tranzit cu difuzare sau NBMA şi se
transmit, prin inundare, doar ruterelor aceleiaşi zone cu DR. Distanţa de
la reţea către fiecare din ruterele ataşate este 0. ID stare-legătură al LSA
tip 2 este adresa IP a interfeţei ruterului DR;
 Tip 3 – „LSA-sumar”, prin care ABR comunică informaţia de rutare
sumară (sintetizată) privind o zonă, către o altă zonă a AS. Pentru fiecare
destinaţie, se specifică costul căii în cadrul zonei (costul sumar al tuturor
legăturilor respective). ID stare-legătură al LSA tip 3 este ID-ul reţelei
destinaţie;
 Tip 4 – „LSA ASBR-sumar”, prin care ASBR comunică informaţia de rutare
sumară privind un AS către un alt AS. Pentru fiecare destinaţie, se
specifică costul căii în cadrul AS (costul sumar al tuturor legăturilor
respective). ID stare-legătură al LSA Tip 4 este ID-ul ASBR;
 Tip 5 – „LSA-extern”, prin care ASBR comunică zonelor din AS, la care
aparţine, cu excepţia celor ciot, informaţia de rutare importată din alte
AS. ID stare-legătură al LSA tip 5 este ID-ul reţelei externe respective;
 Tip 6 – „LSA de grup” (nu toate ruterele îl susţin) este definit pentru OSPF
multiadresat (MOSPF) şi în prezent nu se foloseşte;
361
 Tip 7 – „LSA NSSA extern”, prin care ASBR comunică ABR-urilor zonelor
NSSA informaţia de rutare importată din alte AS. Fiecare asemenea ABR
trimite această informaţie ruterelor din zona sa;
 Tip 8 – „LSA legătură-locală” a OSPFv3 este folosit pentru informarea
privind adresele legături-locale. Deşi au fost definite anumite funcţii şi
pentru OSPFv2, acestea nu au fost susţinute în implementări;
 Tip 9 – „LSA „opacă” legătură-locală” în OSPFv2 (RFC 2370) şi LSA prefix-
intrazonă în OSPFv3;
 Tip 10 – „LSA „opacă” zonă-locală” în OSPFv2 (RFC 2370) conţine
informaţii, care trebuie să fie trimise de alte rutere, chiar dacă acestea nu
le înţeleg;
 Tip 11 – „LSA „opacă” AS” (RFC 5250) conţine informaţii, care trebuie să
fie trimise peste tot, cu excepţia zonelor ciot.
LSA de tip 9-11 sunt destinate pentru extensii ulterioare ale OSPF. Din cele
11 tipuri de anunţuri LSA, enumerate mai sus, se folosesc, preponderent,
primele cinci. Toate tipurile de LSA au un antet LSA de 20 octeţi pentru 8
câmpuri, inclusiv: vârsta LSA, opţiunile suportate, tipul LSA, ID stare-legătură,
ruterul sursă al LSA, numărul de secvenţă al LSA, suma de control şi lungimea
LSA.
10.3.2.8. Sincronizarea LSDB
Există două proceduri de sincronizare (actualizare) a LSDB:
 actualizarea iniţială;
 inundarea de încredere (reliable flooding).
La stablirea pentru prima dată a unei legături între două rutere vecine,
are loc actualizarea iniţială a LSDB. Procedura se numeşte Schimbul bazei
de date (Database exchange). În loc să trimită întreaga bază de date,
ruterul OSPF trimite doar antetele LSA într-o secvenţă de pachete OSPF de
Descriere a bazei de date (Database Description – DD). Ruterul va trimite
următorul pachet DD doar după ce recepţia pachetului precedent este
confirmată. După recepţia întregii secvenţe de pachete DD, ruterul
identifică actualizările necesare: LSA ce lipsesc şi cele ce sunt mai recente.
Apoi el trimite pachete LSR (Link-Stater Request), solicitând LSA respective,
la care vecinii răspund, prin inundare, cu pachete LSU (Link-Stater Update)
– pachete ce conţin LSA solicitate.
Procedura de actualizare a LSDB prin inundarea de încredere se aplică
atunci, când adiacenţele sunt deja stabilite şi ruterul OSPF doreşte să
informeze celelalte rutere despre modificările LSA. Când un ruter primeşte un
asemenea LSU, el instalează în LSDB noile LSA, trimite un pachet de
confirmare către emiţător, încapsulează LSA într-un nou LSU, pe care apoi îl
trimite prin toate interfeţele cu excepţia celei prin care a primit noile LSA. LSA
sunt actualizate fiecare 30 min, dar fără actualizare LSA rămân în LSDB doar
362
pentru cel mult 60 min. De menţionat că nu între toate ruterele vecine se
actualizează LSDB. OSPF decide dacă LSDB trebuie actualizate în baza fiecărui
segment concret de reţea. De exemplu, în ce privește legăturile P2P, LSDB
întotdeauna se sincronizează, dar, în ce priveşte reţelele Ethernet, LSDB se
sincronizează doar între anumite perechi de rutere vecine.
Sincronizarea LSDB în subreţelele cu difuzare se efectuează cu folosirea DR
şi BDR (vezi s. 10.3.2.3).
În subreţelele NBMA, sincronizarea este similară celei în subreţele cu
difuzare, folosind DR şi BDR: se selectează BR şi BDR; iniţial schimbul LSDB are
loc doar cu DR şi BDR, iar actualizarea prin inundare întotdeauna are loc prin
DR. Deosebirea constă în aceea că LSU trebuie să fie replicate şi trimise
fiecărui ruter adiacent în mod separat.
În subreţelele P2MP, fiecare ruter OSPF devine adiacent tuturor ruterelor
cu care acesta comunică direct.
10.3.2.9. Exemplu de configurare a zonelor AS
Un exemplu de sistem autonom Internet, cu conexiuni externe către
reţelele N12-N15, este dat în figura 10.7 (RFC 2328, p. 30). Acest AS este
împărţit în 4 zone OSPF: zona 0 (zona nucleu) şi zonele ordinare (non nucleu)
1, 2 şi 3.
Zona 0 include şase rutere R3-R7, R10 şi R11, din care cele R5 şi R6 sunt
interne. Zona 1 include reţelele N1-N4 şi ruterele R1-R4, din care cele R1 şi R2
sunt interne, iar cele R3 şi R4 sunt marginale (ABR). Zona 2 include reţelele N 6-
N8 şi ruterele R7, R8, R10 şi R11, din care cel R8 este intern, iar cele R7, R10 şi R11
sunt marginale. De menţionat, totodată, că ABR R11 serveşte pentru
conectarea, prin legătură virtuală, a Zonei 3 la cea nucleu, Zona 2 servind, în
acest caz, ca zonă de tranzit între Zona 3 şi cea nucleu – Zona 0. Zona 3 include
reţelele N9-N11, staţia S1 şi ruterele R9, R11 şi R12, din care cele R9 şi R12 sunt
interne, iar cel R11 este marginal. În această zonă, staţia S1 este direct
conectată la ruterul R12, astfel că R12 anunţă ruta pentru această staţie. De
menţionat că Zona 3 a fost astfel configurată ca staţia S 1 şi reţelele N9- N11 să
fie grupate într-o singură rută. În sfârşit, ruterele R 5 şi R7 sunt ASBR, conectate
la unele din reţelele externe N12- N15 fiecare.
Liniile între rutere specifică reţele punct-la-punct fizice. Unica reţea punct-
la-punct, căreia i-au fost atribuite adrese de interfaţă ruter, este cea care
uneşte ruterele R6 şi R10. Ruterele R5 şi R7 au conexiuni către alte AS. Interfeţei
de ieşire a fiecărui ruter îi este atribuit un cost. Cu cât este mai mic costul, cu
atât mai preferată este interfaţa pentru înaintarea de trafic de date. Arcele,
pentru care nu este specificat costul, au costul 0. De menţionat că arcele de la
reţele către rutere au întotdeauna costul 0, deşi acesta este semnificativ.
363
N12 N13 N14
N1 3
1
R1 8
8 8
1 8 8 6
Zona 1 N3 R4 R5
7
3 1
N2 6
R2 1
2 8 6
N4 R3 R6
Ia 7
N12
Ib 5 6
3 Zona 0 2
N11
R9 R10 R7 9
1 3 1 1
1 2 N15
N9 R11 N8 N6
Zona 3 1 Zona 2 1
N10 2 10
S1 4
R12 N7
R8
Fig. 10.7. Un sistem autonom, împărţit în zonele 0-3 [RFC 2328].
Exemple de LSA-ruter şi LSA-reţea, determinate pentru AS din figura 10.7,

sunt prezentate în tabelele 10.6 şi 10.7.
Tabelul 10.6. LSA-ruter al ruterului R12 din figura 10.7 (RFC 2328)
De la
R12 R9 R10 S1
R12
Către
N9 1
N10 2
S1 10
364
Tabelul 10.7. LSA-reţea al reţelei N9 din figura 10.4 (RFC 2328)
De la
R9 R11 R12 N9
R9 0
Către
R11 0
R12 0
N9
Pentru calcularea costului căilor de la un ruter către diversele destinaţii
posibile, OSPF determină, folosind algoritmul Dijkstra, arborele celor mai
scurte căi (SPF) către aceste destinaţii. În acest scop se folosesc informaţiile,
colectate prin anunţuri LSA-ruter şi LSA-reţea. Un exemplu de arbore SPF cu
vârful rădăcină R6, construit pentru AS din figura 10.7, dar fără împărţirea AS în
zone, este dat în figura 10.8.
Arborele din figura 10.8 arată cea mai scurtă cale de la ruterul R6 către
orice reţea sau staţie destinaţie a AS. În baza acestuia, poate fi calculat costul
căilor respective, care constituie unele din înregistrările LSDB, iar ulterior şi
tabelul de rutare. Un exemplu trunchiat de tabel de rutare pentru ruterul R6 în
cadrul AS din figura 10.7 (nedivizat în zone), calculat în baza arborelui SPF din
figura 10.8 (RFC 2328, p. 22), este prezentat în tabelul 10.8.
N4 R3 R6 (originea) R10 Ia
2 6 7 5
1 7 6 3 1
R4 N6 R7
N3 R5 N8
Ib
8 8 8 2 9
R2 R1 R11 R8
N12 N13 N14 N12 N15
3 3 1 4
N11 R9 N9
N7
N2 N1 3
2 10
N10 R12 S1
Fig. 10.8. Arborele SPF pentru ruterul R6 al AS din figura 10.7, nedivizat în zone. Arcele,
pentru care nu este specificat costul, au costul 0 (RFC 2328).
De menţionat că în cazul unor costuri egale a două sau mai multe căi către
o destinaţie, toate aceste căi pot fi folosite, distribuind în mod egal, de
exemplu, traficul de date între ele.
365
Tabelul 10.8. O parte a tabelului de rutare a ruterului R6 pentru destinaţiile
interne ale AS din fig. 10.7 (nedivizat în zone) (RFC 2328, p.23)
Destinaţia Saltul următor Costul
N1 R3 10
N2 R3 10
N3 R3 7
N4 R3 8
Ia * 7
Ib R10 12
N6 R10 8
N7 R10 12
N8 R10 10
N9 R10 11
N10 R10 13
N11 R10 14
S1 R10 21
R5 R5 6
R7 R10 8
Informaţiile bazei de date stare-legături (LSDB) pentru Zona 1 a AS din
figura 10.7 sunt prezentate în tabelul 10.9 (RFC 2328, p. 32).
Tabelul 10.9. Înregistrările bazei de date stare-legături pentru Zona 1
De la
R1 R2 R3 R4 R5 R7 N3
R1 0
R2 0
R3 0
R4 0
R5 14 8
R7 20 14
N1 3
N2 3
N3 1 1 1 1
Către
N4 2
I a, I b 20 27
N6 16 15
N7 20 19
N8 18 25
S1, N9- N11 29 36
N12 8 2
N13 8
N14 8
N15 9
366
Pentru ruterele interne R1 şi R2, LSDB include costurile căilor intrazonă şi,
de asemenea, cele externe către Internet. Costul căilor către toate destinaţiile
externe faţă de Zona 1 se anunţă de către ABR R3 şi R4. Tot aceste ABR anunţă
în Zona 1 şi localizarea ASBR R5 şi R7. De asemenea, LSA externe faţă de AS de
la ASBR R5 şi R7 sunt transmise prin inundare în întregul AS, inclusiv în Zona 1,
şi sunt reprezentate în tabelul 10.9 prin rutele către reţelele N12-N15.
Fiecare înregistrare în LSDB specifică costul căii (distanţa) între sursa şi
destinaţia respectivă. De exemplu, costul celei mai scurte căi de la reţeaua N 3
către fiecare din ruterele R1-R4 ale acesteia este 0, iar în direcţie inversă este 1.
De asemenea, distanţa de la ruterul R3 către cel R5 este 14.
ABR R3 şi R4 sintetizează topologia Zonei 1 pentru distribuire către Zona
nucleu. Informaţiile respective sunt prezentate în tabelul 10.10. În tabel,
pentru fiecare din reţelele Zonei 1, este specificată distanţa până la ele de la
ABR R3 şi, aparte, de la R4.
Tabelul 10.10. Anunţurile ABR R3 şi R4 către Zona 0 (RFC 2328, p. 31)
Reţeaua Anunţul R3 Anunţul R4
N1 4 4
N2 4 4
N3 1 1
N4 2 3
Informaţiile bazei de date stare-legături (LSDB) pentru Zona 0 sunt
prezentate în tabelul 10.11 (RFC 2328, p. 33). Ruterul R11 este unul ABR, deci
este ataşat şi la Zona 0. Pentru ca Zona 0 să nu fie fragmentată, între ruterul
R10 şi cel R11 este configurată o legătură virtuală.
ABR R3, R4, R7, R10 şi R11 sintetizează informaţia de rutare a zonelor lor non-
nucleu pentru distribuire prin Zona 0. În tabel este prezentată şi informaţia de
rutare externă faţă de AS, comunicată de ASBR R 5 şi R7.
Zona 0 permite schimbul de informaţii sintetizate între ABR privind zonele
lor. Fiecare ABR devine, astfel, cunoscut cu informaţiile sintetizate despre
toate celelalte zone. În baza acestor informaţii, fiecare ABR poate să calculeze,
pentru fiecare ruter al zonei sale, distanţa către reţelele celorlalte zone. De
exemplu, ABR R3 calculează mai întâi arborele celor mai scurte căi (SPF) pentru
Zona 0. Acesta permite calcularea distanţei de la R3 până la toate celelalte ABR
şi, de asemenea, până la reţelele Ia şi Ib şi ASBR R5 şi R7, care ţin de Zona 0.
Rezultatele calculelor, pentru ABR R3 şi R4, sunt prezentate în tabelul 10.12.
367
Tabelul 10.11. Înregistrările bazei de date stare-legături pentru Zona 0
De la
R3 R4 R5 R6 R7 R10 R11
R3 6
R4 8
R5 8 6 6
R6 8 7 5
R7 6
R10 7 2
R11 3
N1 4 4
N2 4 4
N3 1 1
Către
N4 2 3
Ia 5
Ib 7
N6 1 1 3
N7 5 5 7
N8 4 3 2
S1, N9- 11
N11
N12 8 2
N13 8
N14 8
N15 9
Tabelul 10.12. Distanţele Zonei 0, calculate de ABR R3 şi R4 (RFC 2328, p. 34)
De la
R3 R4
R3 0 21
R4 22 0
R7 20 14
R10 15 22
Către
R11 18 25
Ia 15 22
Ib 20 27
R5 14 8
R7 20 14
368
Folosind datele tabelului 10.12, fiecare din ABR R3 şi R4 poate determina
distanţa către toate reţelele AS, care nu ţin de zona sa. Aceste distanţe sunt
ulterior anunţate de către ABR R3 şi R4 zonelor lor (tabelul 10.13).
Tabelul 10.13. Destinaţiile anunţate de ABR R3 şi R4 în Zona 1 (RFC 2328, p.35)
De la
R3 R4
Ia , Ib 20 27
N6 16 15
N7 20 19
Către N8 18 25
S1, N9- 29 36
N11
R5 14 8
R7 20 14
De menţionat că în tabelului 10.13 accesul reţelelor Ia şi Ib este grupat într-
un singur LSA. Informaţia tabelului 10.9 permite ruterelor interne ale Zonei 1
să aleagă argumentat între cele două ABR R3 şi R4, în funcţie de destinaţie. De
exemplu, ruterul R1 va selecta ABR R4, pentru traficul către Reţeaua N6, şi cel
R3, pentru traficul către Reţeaua N8. În ce priveşte accesul în afara AS, ruterul
R1 în acelaşi mod va selecta între ASBR R5 şi cel R7.
10.3.2.10. Tabelele de rutare şi structura lor
Tabelul de rutare conţine toată informaţia necesară pentru înaintarea de
către ruter a fiecărui pachet de date IP către orice destinaţie din Internet.
Tabelul de rutare se calculează în baza informaţiilor LSDB. Fiecare intrare a
unui asemenea tabel descrie colecţia celor mai bune căi către o anumită
destinaţie. Pentru înaintarea unui pachet IP concret, se determină intrarea
tabelului de rutare, care asigură cea mai bună cale către destinaţia acestui
pachet. Procedura respectivă este descrisă mai jos în această secţiune.
Fiecare ruter are un singur tabel de rutare, care conţine următoarele
câmpuri:
1) tipul destinaţiei;
2) ID destinaţie;
3) mască adresă;
4) capabilităţi opţionale;
5) zona;
6) tipul căii;
7) costul stare-legătură;
8) costul stare-legătură de tip 2;
9) originea stării-legătură;
369
10) saltul următor;
11) ruterul de anunţuri.
Tipul destinaţiei poate fi „reţea” sau „ruter”. Pentru înaintarea pachetelor
IP se folosesc doar intrările de tip reţea. Intrările de tip „ruter” se folosesc
doar ca etape intermediare în procesul de constituire a tabelului de rutare. De
menţionat că prin adrese IP de tip reţea se au în vedere adresele IP de reţea
(de exemplu, de clasele A, B sau C), de subreţea, superreţea sau staţii IP şi, de
asemenea, ruta implicită. Intrările pentru rutere ABR, sunt menţinute pentru
rutere ABR şi ASBR şi se folosesc pentru calcularea rutelor intrazonă şi,
totodată, pentru menţinerea legăturilor virtuale configurate. Intrările pentru
ruterele ASBR se folosesc la calcularea rutelor externe faţă de AS.
ID destinaţie este numele sau identificatorul destinaţiei, în funcţie de tipul
destinaţiei. Pentru reţele acesta este adresa IP a reţelei, iar pentru rutere –
OSPF ID-ruter.
Mască adresă – se defineşte doar pentru reţele.
Capabilităţi opţionale – în cazul că destinaţia este un ruter, arată
capabilităţile OSPF opţionale suportate de ruterul destinaţie. Una din acestea
este abilitatea de a procesa LSA-externe-AS.
Zona – specifică zona, a cărei informaţie stare-legături a condus la colecţia
de căi a intrării tabelului de rutare. Pentru căile AS externe, acest câmp nu
este definit.
Tip cale – există patru tipuri de căi, folosite pentru rutarea traficului de
date către destinaţie, în ordinea descreşterii preferinţei: intrazonă, interzone,
externă tip 1 şi externă tip 2. Căile intrazonă indică destinaţiile, care aparţin
uneia din zonele ce ţin de ruterul dat. Interzone sunt căile către destinaţii ce
ţin de alte zone OSPF. Căi AS externe sunt căile către destinaţii în afara AS dat
(vezi şi descrierea câmpurilor „Costul” şi „Costul tip 2”).
Costul – costul căii până la destinaţie. Pentru toate căile, cu excepţia celor
externe tip 2, este vorba de costul întregii căi. Pentru căile externe tip 2,
câmpul indică costul porţiunii căii interne în cadrul AS.
Costul tip 2 – este valabil doar pentru căile externe tip 2 şi constituie costul
căii de la ASBR până la destinaţia externă.
Originea stării legătură – este valabil doar pentru căile interzone şi indică
LSA (LSA-ruter sau LSA-reţea) cu referinţă directă la destinaţie. De exemplu,
dacă destinaţia este o reţea de tranzit, acesta este LSA-reţea de tranzit. Dacă
destinaţia este o reţea ciot, acesta este LSA-reţea pentru ruterul ataşat. LSA
este determinat în procesul calculării arborelui celor mai scurte căi (SPF).
Indicele este folosit de extensia MOSPF.
Saltul următor – interfaţa de ieşire a ruterului pentru înaintarea traficului
de date către destinaţie. În reţelele cu difuzare, punct-la-multipunct şi NBMA,
370
următorul salt include, de asemenea, adresa IP a următorului ruter (dacă
există unul) pe calea către destinaţie.
Ruterul de anunţare – este valabil doar pentru căile interzone şi cele
externe faţă de AS şi indică ID-ruter al ruterului de anunţare a LSA-sumare sau
LSA-externe-AS care conduc la această cale.
10.3.2.11. Calcularea tabelelor de rutare ale ruterelor AS monozonă
Fiecare ruter îşi calculează tabelul de rutare propriu, implicând în acest
proces şi celelalte rutere ale AS. Procedura de determinare a tabelului de
rutare, pentru cazul unui sistem autonom nedivizat în zone, include patru
etape:
1) identificarea şi reprezentarea adiacenţelor (stării legăturilor) –
topologiei AS;
2) crearea arborelui SPF pentru ruter;
3) determinarea costului sumar al fiecărei căi prin arbore de la ruter către
posibilele destinaţii în cadrul AS;
4) definitivarea tabelului de rutare.
Identificarea şi reprezentarea adiacenţelor. În scopul schimbului de
informaţii de rutare, OSPF creează adiacenţe între ruterele învecinate. Orice
ruter într-o reţea are o adiacenţă. Dacă un ruter ţine de mai multe reţele,
atunci el poate avea mai multe adiacenţe. Adiacente devin doar acele rutere
învecinate, între care este rezonabil de efectuat schimbul de informaţii de
rutare. Astfel, numărul de rutere adiacente este, de obicei, mai mic decât
numărul ruterelor învecinate, simplificând procesele de determinare şi
distribuire a informaţiilor de rutare.
Determinarea adiacenţelor se realizează în rezultatul transmiterii/recepţiei
de pachete „Hello” vecinilor. Asemenea pachete se transmit periodic de către
toate interfeţele fiecărui ruter. În cazul că un ruter se regăseşte într-un pachet
Hello, acesta trebuie să răspundă respectiv.
După identificarea unui vecin, este asigurată comunicarea bidirecţională cu
acesta. Ulterior, se selectează (într-o reţea cu difuzare sau NBMA) ruterul
desemnat, iar apoi se decide dacă de format (este rezonabil) sau nu (nu este
rezonabil) o adiacenţă cu acest vecin. Adiacenţa se formează doar în cazurile,
când conectarea cu vecinul este una punct-la-punct, punct-la-multipunct sau
prin legături virtuale sau când înseşi ruterul sau vecinul este ruter desemnat
sau ruter desemnat de rezervă. Astfel, ruterele, conectate între ele punct-la-
punct, punct-la-multipunct sau prin legături virtuale, totdeauna devin
adiacente. Pe când, în reţelele cu difuzare şi cele NBMA, doar ruterul
desemnat şi cel desemnat de rezervă devin adiacente tuturor celorlalte rutere.
Dacă se formează o asemenea adiacenţă, atunci se sincronizează bazele de
date stare-legături (LSDB) ale ruterelor AS.
371
În scopul unei asemenea sincronizări, fiecare ruter descrie LSDB proprie,
trimiţând ruterului adiacent un mesaj OSPF „Descriere bază de date” (o
secvenţă de pachete). Ulterior, fiecare ruter solicită selectiv de la ruterul
adiacent, prin mesaje OSPF „Cerere stare-legături”, setul de LSA mai recente,
decât cele din LSDB proprie, realizând actualizările necesare ale LSDB. După
actualizarea LSDB, adiacenţa în cauză este complet funcţională şi se anunţă în
reţea prin LSA-ruter ale celor două rutere; ruterele DR anunţă, de asemenea,
LSA-reţea.
Când se modifică starea unei legături, nodul, care a detectat această
modificare, creează un anunţ LSA referitor la această legătură, pe care îl
transmite către ruterele adiacente, folosind o adresă specială multiadresat.
Fiecare ruter, care a recepţionat acest LSA, actualizează baza de date stare-
legături proprie, iar o copie a LSA o înaintează către toate ruterele adiacente.
Informaţia, referitoare la starea legăturilor, este folosită de către fiecare ruter
pentru reconstituirea LSDB a AS (zonelor sale).
În baza adiacenţelor ruterelor, poate fi construit graful neorientat al
adiacenţelor: vârfurile grafului reprezintă ruterele, iar arcele – adiacenţele
acestora. Graful adiacenţelor descrie căile posibile ale fluxurilor de pachete
(vezi fig. 10.9 – RFC 2328, p. 57).
R1 R2
a)
R1 N1 R2
R7
R7 R3 R4
b) R5 R6 R4
R5 R6
R3
Fig. 10.9. Exemple de reţele şi grafuri de adiacenţă (RFC 2328).
În reţeaua (b) din figura 10.9, ruterul RT7 este DR, iar cel RT3 este BDR.
Crearea arborelui SPF pentru fiecare ruter. În baza informaţiilor privind
starea legăturilor, obţinute prin LSA-rutere şi LSA-reţele, fiecare ruter poate
reconstitui, folosind algoritmul Dijkstra, arborele celor mai scurte căi de la sine
către fiecare din posibilele destinaţii.
Determinarea costului sumar al căilor. În baza informaţiilor privind arborii
SPF, fiecare ruter calculează costul sumar al fiecărei căi de la sine către
372
posibilele destinaţii în cadrul AS, informaţiile respective înscriindu-le în LSDB şi
tabelul de rutare. Ruterele ASBR, prin LSA ASBR-sumar (Tip 4) comunică altor
AS informaţia de rutare sumară privind sistemul autonom în cauză, iar prin LSA
ASBR-extern (Tip 5) comunică ruterelor AS informaţia de rutare către destinaţii
externe, importată din alte AS.
Definitivarea tabelului de rutare. În baza costului căilor interne în cadrul
AS şi al celui al căilor externe, obţinute prin LSA ASBR-extern (Tip 5), fiecare
ruter determină costul sumar al căilor şi rutele către destinaţiile externe,
rezultatele înscriindu-le în LSDB şi tabelul de rutare proprii.
Un exemplu de tabel de rutare pentru ruterul R 6 în cadrul AS din figura
10.4 (nedivizat în zone), calculat în baza arborelui SPF din figura 10.9, este
prezentat în tabelul 10.14.
Tabelul 10.14. Tabelul de rutare al ruterului R6 construit în baza arborelui SPF
din fig. 10.9 (RFC 2328, p. 113)
Următorul Ruterul de
Tipul Destinaţia Zona Tipul căii Costul
salt anunţare
N N1 0 interzone 10 R3 *
N Ia 0 interzone 7 * *
N Ib 0 interzone 12 R10 *
N S1 0 interzone 21 R10 *
R R5 0 interzone 6 R5 *
R R7 0 interzone 8 R10 *
externă
N N12 * tip 1 10 R10 R7
externă
N N13 * tip 1 14 R5 R5
externă
N N14 * tip 1 14 R5 R5
externă
N N15 * tip 1 17 R10 R7
În tabelul 10.14, caracterul N specifică tipul „reţea”, iar cel R – tipul „ruter”
al destinaţiei. În acest exemplu nu există cazuri de mai multe căi, către aceeaşi
destinaţie, cu acelaşi cost. De menţionat că în cazul unor costuri egale a două
373
sau mai mult căi către o destinaţie, toate aceste căi pot fi folosite, distribuind
în mod egal, de exemplu, traficul de date între ele.
De asemenea, deoarece nu există zone, lipsesc şi căile interzone. Ţinând
cont că ruterele R5 şi R7 sunt ASBR, rutele intrazonă au fost calculate către
ruterele R5 şi R7. Aceasta permite calcularea rutelor externe către destinaţiile
anunţate de R5 şi R7 – reţelele N12-N15. Este considerat că toate LSA-externe-
AS, generate de ASBR R5 şi R7, anunţă metrica externă de Tip 1, ceea ce a
condus la calcularea costurilor căilor externe de Tip 1 către destinaţiile N12-N15.
10.3.2.12. Calcularea tabelelor de rutare ale ruterelor AS multizonă
Fie că sunt cunoscute bazele de date stare-legătură ale zonelor ataşate
ruterului, pentru care trebuie de calculat tabelul de rutare (vezi s. 10.3.2.9).
Procedura de determinare a tabelului de rutare include patru etape:
1) calcularea rutelor intrazonă pentru fiecare zonă a AS;
2) calcularea rutelor interzone a AS;
3) îmbunătăţirea rutelor, în baza LSA-sumare a zonelor de tranzit;
4) calcularea rutelor către destinaţii externe.
Calcularea rutelor intrazonă. Rutele intrazonă se determină în baza
arborilor SPF intrazonă, calculaţi pentru fiecare ruter aparte. Arborele SPF
intrazonă al unui ruter are ca vârf rădăcină ruterul în cauză înseşi. Un
asemenea arbore poate fi reconstituit, în baza LSA-rutere şi LSA-reţele
respective, în doi paşi. La primul pas, conform algoritmului Dijkstra, se
formează un subarbore SPF intrazonă, luând în consideraţie doar legăturile
între rutere şi reţelele de tranzit. La cel de al doilea pas, subarborele format se
extinde cu arce şi vârfuri-frunze, care reprezintă legăturile către reţelele ciot şi
aceste reţele înseşi.
În procesul calculelor, fiecare ruter se identifică prin ID-ruter OSPF, iar
fiecare reţea – prin ID-ruter OSPF al ruterului desemnat (DR) pentru această
reţea. Totodată, legăturile între rutere şi reţele se caracterizează de LSA-ruter
şi LSA-reţea respective. Fiecare salt următor de la un vârf al arborelui specifică
interfaţa ruterului, pentru a fi folosită la înaintarea traficului de date către
destinaţie, iar în cazul de reţele cu difuzare, punct-la-multipunct sau NBMA
acesta specifică şi adresa IP a următorului ruter (dacă exista vreunul) pe calea
către destinaţie.
Distanţa (costul) pe o cale de la ruterul-rădăcină a arborelui şi până la un
vârf al arborelui se determină ca şi costul sumar al legăturilor constituente. O
cale se considera mai „scurtă” decât alta, dacă aceasta are un cost sumar mai
mic. Arborele SPF intrazonă pentru ruterul-rădăcină dat se constituie din cele
mai scurte căi de la acest ruter până la fiecare din vârfurile intermediare sau
frunză. În baza arborilor SPF intrazonă, se calculează şi înregistrează în LSDB
costul sumar al fiecărei căi în cadrul zonei, iar ulterior se determină şi rutele
374
către destinaţiile intrazonă. Rutele intrazonă obţinute se înscriu în tabelul de
rutare.
Calcularea rutelor interzone. Rutele interzone se calculează în baza LSA-
sumare. Destinaţia descrisă de un LSA-sumar este sau o reţea (LSA-sumar tip
3) sau un ASBR (LSA-sumar tip 4). Pentru ruterele ASBR, se folosesc doar LSA-
sumare privind zona nucleu, iar pentru ruterele interne (ataşate la o singură
zonă) se folosesc LSA-sumare ale zonei respective. La calcularea rutelor
interzone, din posibilele căi către o destinaţie, se selectează calea cea mai
scurtă (cu cel mai mic cost). Rutele interzone determinate se înscriu în tabelul
de rutare.
Îmbunătăţirea rutelor, în baza LSA-sumare ale zonelor de tranzit. În
cadrul ruterelor marginale de zonă (ABR), conectate la una sau mai multe zone
de tranzit, se examinează LSA-sumare a zonelor de tranzit, pentru a
determina, dacă există sau nu căi mai bune prin zonele de tranzit, decât cele
determinate la etapele 1 şi 2. Orice căi prin zonele de tranzit mai bune sau
egale cu căile determinate la etapele 1 şi 2 sunt înregistrate în tabelul de
rutare.
Calcularea rutelor către destinaţii externe se efectuează în baza
examinării LSA-externe-SA în cadrul ASBR. Asemenea LSA descriu rute către
destinaţii IP specifice sau, una din ele, ruta implicită a AS. În cadrul ruterelor
marginale de zonă (ABR), conectate la una sau mai multe zone de tranzit, se
examinează LSA-sumare a zonelor de tranzit, pentru a determina, dacă există
sau nu căi mai bune prin zonele de tranzit, decât cele determinate la etapele 1
şi 2. Orice căi prin zonele de tranzit mai bune sau egale cu căile determinate la
etapele 1 şi 2 sunt înregistrate în tabelul de rutare. La selectarea celor mai
scurte căi, este necesar de respectat şi următoarele reguli:
a) căile intrazonă şi cele interzone sunt preferabile faţă de cele AS
externe;
b) căile externe Tip 1 sunt preferabile faţă de cele externe Tip 2;
c) căile intrazonă non-nucleu sunt cele mai preferabile;
d) căile intrazonă nucleu şi cele interzone sunt de aceeaşi preferinţă.
Căi multiple de acelaşi cost. OSPF permite folosirea de căi multiple de
acelaşi cost către toate destinaţiile. Fiecare din asemenea rute multiple
trebuie să fie de acelaşi tip (intrazonă, interzone, externă Tip 1 sau externă
Tip2), cost şi să ţină de aceeaşi zonă. Totodată, fiecare rută poate să specifice
un alt salt următor şi ruter de anunţare.
De menţionat că nu se cere ca un ruter OSPF să gestioneze toate rutele
posibile de acelaşi cost către o destinaţie. Numărul acestora se poate limita de
sus.
375
10.3.2.13. Formatul pachetelor OSPF
OSPF foloseşte cinci tipuri de pachete (vezi s. 10.3.2.5). Toate aceste cinci
tipuri de pachete, încep cu un antet comun de 24 octeţi, care conţine 8
câmpuri (fig. 10.10):
 Versiune – numărul versiunii OSPF;
 Tip – tipul pachetului OSPF;
 Lungimea pachetului – lungimea pachetului OSPF în octeţi;
 ID-ruter;
 ID-zonă;
 Suma de control – suma de control IP standard;
 TipAu – identifică procedura de autentificare a pachetului;
 Autentificare – un câmp pe 64 biţi pentru schema de autentificare.
Octet 0 1 2 3
Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Versiune Tip Lungime pachet
32 ID-ruter
64 ID-zonă
96 Suma de control TipAu
128 Autentificare
148 Autentificare
Fig. 10.10. Formatul antetului comun al pachetelor OSPF.
Fiecare din cele cinci tipuri de pachete OSPF, enumerate mai sus în această
secţiune, completează antetul comun pe 24 octeţi din figura 10.10 cu câmpuri
specifice tipului.
10.3.2.14. Extensii OSPF
Cu timpul OSPF este completat cu noi funcţionalităţi, unele din care sunt
evidenţiate în extensii aparte ca: MOSPF, OSPF-TE şi extensii „optice” OSPF.
Extensia MOSPF – OSPF multiadresat (Multicast OSPF, RFC 1584). Este o
extensie a OSPF pentru rutarea multiadresat, permiţând ruterelor partajarea
de informaţii despre adeziunea la grupuri. Rulează peste OSPFv2, folosind
funcţionalităţile acestuia. Pentru distribuirea de informaţii de rutare, MOSPF
foloseşte LSA tip 6, care descrie localizarea destinaţiilor multiadresat. În baza
informaţiilor obţinute prin LSA de tip 6, se determină căile pentru pachete
multiadresat. Asemenea căi se determină doar la cerere, iar rezultatele
obţinute se stochează pentru folosirea de către secvenţele respective de
pachete.
Extensia OSPF-TE (RFC 3630). Este o extensie a OSPF pentru folosire în
reţele non-IP, inclusiv în reţele GMPLS (Generalized Multiprotocol Label
Switching). În reţele GMPLS, extensia OSPF-TE este folosită pentru
376
identificarea şi descrierea topologiei acestora, înregistrată bazele de date
stare-legături (LSDB). În baza LSDB, GMPLS înseşi determină căile de înaintare
a pachetelor prin reţea.
Extensii „optice” OSPF – ca şi concept sunt descrise în RFC 3717 (2004). Ele
trebuie să asigure suportul necesar pentru rutarea pachetelor IP prin reţele
optice. În acest scop, extensiile în cauză trebuie să capteze parametrii
legăturilor prin fibră optică, precum şi constrângerile respective ale reţelelor
optice. În baza acestor informaţii se determină adiacenţele şi informaţiile de
stare a legăturilor (LSDB), care se folosesc de fiecare router pentru a calcula o
cale ruter-ruter (end-to-end) prin reţeaua optică către un alt router.
10.3.2.15. Avantaje şi dezavantaje OSPF faţă de RIP
La avantajele protocoalelor de tehnologie stare-legături, ca OSPF, faţă de
cele vector distanţă, ca RIP, se referă:
 lipsa limitărilor privind numărul de salturi, ceea ce permite folosirea lui şi
în reţele de mari dimensiuni;
 folosirea adresării multiadresat pentru actualizarea informaţiilor de
rutare, reducând traficul informaţiilor de serviciu în reţea;
 actualizările sunt trimise doar la modificarea topologiei reţelei, reducând
traficul informaţiilor de serviciu în reţea;
 definirea logică a rețelelor, în care ruterele sunt grupate în zone
ierarhice, ceea ce permite controlul rapid al modificărilor topologice şi
recalcularea respectivă a rutelor ş.a.
Totodată, OSPF are şi unele dezavantaje faţă de RIP, inclusiv:
 OSPF este mai complex în implementare;
 OSPF necesită mai multe procesări şi memorie, inclusiv din cauza
păstrării a mai multor copii a informaţiilor de rutare.
10.3.3. Protocolul IS-IS
Protocolul IS-IS (Intermediate System to Intermediate System – Sistem
intermediar către Sistem intermediar) este un protocol de rutare, propus de
compania Digital Equipment în 1987, a fost standardizat de ISO în 1992 (DP
10589) și IETF în 1990 (RFC 1142), iar ulterior, tot în 1990, dezvoltat în IS-IS
integrat (Integrated IS-IS, RFC 1195). Scopul inițial al elaborării IS-IS consta în
rutarea datagramelor în cadrul protocolului CLNP (Connectionless-mode
Network Protocol – Protocol de rețea mod fără conexiune) al suitei de
protocoale OSI ISO. CLNP, fiind un protocol de nivel 3 OSI, se folosește larg în
rețelele de telecomunicații de tehnologie SDH (Sinchronous Digital Hierarchy –
Ierarhia Numerică Sincronă).
IS-IS este un protocol de porţi interioare bazat pe starea legăturilor,
considerat un standard de facto pentru rețelele magistrale ale furnizorilor de
377
servicii de rețea. Fiecare ruter IS-IS menține o bază de date privind topologia
rețelei.
Ca și OSPF, protocolul IS-IS reconstituie topologia rețelei și folosește
algoritmul Dijkstra pentru determinarea celor mai bune căi de înaintare a
pachetelor (datagramelor), suportă CIDR, poate aplica transportul
multiadresat pentru descoperirea ruterelor învecinate folosind pachete Hello
și poate folosi autentificarea actualizărilor informațiilor de rutare.
Totodată, spre deosebire de OSPF, IS-IS nu folosește IP pentru transferul
informațiilor de rutare. El este neutru față de tipul de adrese de rețea folosite,
fiind astfel ușor de folosit cu IPv6.
Deși IS-IS tot folosește divizarea AS în zone, modalitatea divizării diferă.
Ruterele IS-IS pot fi de nivel 1 (intrazonă), de nivel 2 (interzone) sau de nivel 1-
2 (atât intrazonă, cât şi interzone). Ruterele de un singur nivel (1 sau 2) pot
schimba informaţii doar cu rutere de acelaşi nivel. Pentru schimbul de
informaţii între ruterele de nivel 1 şi cele de nivel 2, se folosesc rutere de nivel
1-2. Mai mult ca atât, dacă un ABR OSPF ţine de cel puţin două zone (graniţa
între zone trece prin cadrul ABR, pentru diferite zone folosind diferite
interfeţe), atunci fiecare ruter IS-IS ţine de o singură zonă (graniţa între zone
trece în afara ruterelor de nivel 2 sau 1-2). De asemenea, IS-IS nu foloseşte
vreo zonă nucleu. Topologia IS-IS include o topologie magistrală, formată din
rutere de nivel 2, cu ramuri de nivel 1-2 şi zone individuale, formate din rutere
de nivel 1.
La aceleaşi resurse, IS-IS poate suporta un număr mai mare de rutere într-o
zonă, decât OSPF.
10.3.4. Protocoalele IGRP şi EIGRP
Protocolul de rutare pentru porţi interioare (Interior Gateway Routing
Protocol – IGRP) este un protocol vector-distanţă, propus de compania Cisco
pentru depăşirea limitărilor protocolului RIP privind o singură metrică de
rutare şi numărul maxim de salturi într-un AS (≤ 15). IGRP suportă mai multe
metrici de rutare, inclusiv: lăţimea de bandă, întârzierea, încărcarea, lungimea
maximă a unităţii de date de transmis (Maximum Transmission Unit – MTU) şi
fiabilitatea. Aceste metrici pot fi îmbinate într-o singură metrică, folosind o
anumită formulă. Numărul maxim de salturi într-un AS poate fi 255, la
valoarea implicită de 100 salturi.
Însă IGRP nu suportă CIDR, ceea ce limitează considerabil folosirea
eficientă a spaţiului de adrese IPv4. De aceea IGRP a fost ulterior înlocuit cu
protocolul EIGRP.
Protocolul îmbunătăţit de rutare pentru porţi interioare (Enhanced
Interior Gateway Routing Protocol – EIGRP) este un protocol vector-distanţă
avansat, propus de compania Cisco ca o dezvoltare esenţială a celui IGRP.
378
EIGRP suportă CIDR şi este compatibil cu IGRP, convertind în mod automat
metrica EIGRP pe 32 biţi în cea IGRP pe 24 biţi. Majoritatea optimizărilor de
rutare se bazează pe Algoritmul de actualizare prin difuziune (Diffusing Update
Algorithm – DUAL), care garantează operarea fără bucle şi oferă un mecanism
de convergenţă rapidă. Însă EIGRP nu poate fi folosit în cazurile, când ruterele
trebuie să cunoască topologia exactă a reţelei, ca, de exemplu, în reţelele
MPLS.
Din avantajele EIGRP pot fi menţionate [17]:
 încărcarea joasă a resurselor de reţea: în regim stabil de operare, se
transmit doar pachete Hello;
 la apariţia unei modificări în topologia reţelei, se transmit doar
modificările respective în tabelul de rutare;
 convergenţă rapidă la modificări în topologia reţelei.
Informaţiile EIGRP se păstrează în trei tabele: 1) Tabelul de vecinătate; 2)
Tabelul de topologie; 3) Tabelul de rutare. În Tabelul de vecinătate se înscriu
informaţiile privind ruterele învecinate – rutere ale căror interfeţe sunt
interconectate direct prin mediul de transmisie (canal de transfer date).
Pentru a identifica ruterele învecinate, EIGRP transmite pachete Hello, ca şi
OSPF.
Tabelul de topologie nu conţine descrierea topologiei complete a reţelei, ci
doar lista reţelelor destinaţie şi metrica lor. Fiecare destinaţie poate fi marcată
ca „Pasivă” sau „Activă”. Destinaţia este Pasivă, dacă ruta către aceasta este
determinată, şi – Activă, dacă topologia s-a modificat şi ruterul este în
procesul de actualizare a rutelor către această destinaţie.
Tabelul de rutare descrie rutele către toate destinaţiile, inclusiv un succesor
şi, opţional, un succesor posibil pentru fiecare destinaţie. Succesorul serveşte
ca ruter pentru saltul următor. Un ruter este specificat succesor, dacă: a)
acesta asigură cea mai scurtă cale către destinaţia în cauză; b) se garantează
lipsa formării unei bucle de rutare. Succesorul posibil este un succesor de
rezervă şi se foloseşte ca o cale de rezervă, în cazul încărcării înalte a căii prin
ruterul succesor, etc. Un ruter este specificat succesor posibil, dacă acesta
garantează lipsa formării unei bucle de rutare. Evident, un ruter poate avea
mai mulţi succesori posibili. Totodată, numărul total de succesori şi succesori
posibili pentru o destinaţie în tabelul de rutare este limitat, implicit, la patru.
Această limită poate fi modificată de către administrator în intervalul [1; 6],
iar, începând cu sistemul de operare Cisco IOS v. 12.4, – în intervalul [1; 16].
De menţionat că, pentru fiecare succesor posibil, în tabelul de rutare este
specificată metrica. Astfel, dacă, pentru transferul de pachete, este necesar de
folosit un succesor posibil, atunci din multiplii succesori se selectează cel cu
metrica mai mică. De asemenea, schimbul de informații de rutare are loc doar
379
la stabilirea unor noi adiacenţe ale ruterelor învecinate, în procesul căreia se
transmit doar modificările respective.
Cu fiecare rută, EIGRP asociază şase metrici vectoriale diferite, dar, la
calcularea metricii sintetizate, foloseşte doar patru din ele. Cele şase metrici
sunt: 1) lăţimea de bandă; 2) reţinerea; 3) fiabilitatea; 4) încărcarea; 5) MTU;
6) numărul salturilor.
„Lăţimea de bandă” (C) este lăţimea de bandă (viteza de transfer date)
minimă pe calea de la ruter şi până la reţeaua destinaţie în Kbps. „Încărcarea”
(L) se caracterizează printr-un număr din intervalul [1; 255], valoarea 255
corespunzând stării de saturaţie a mediului de transmisie. „Reţinerea” (T) este
reţinerea totală a unui pachet în cadrul căii de la ruter şi până la reţeaua
destinaţie în zeci de microsecunde. „Fiabilitatea” (R) se caracterizează printr-
un număr din intervalul [1; 255], valoarea 255 corespunzând stării de
fiabilitate maximă. „MTU” (V) este cea mai mică valoare, în cadrul căii, a
Unităţii de transmisie maxime (Maximum Transmission Unit – MTU). „Numărul
salturilor” (H) este numărul de rutere prin care a trecut pachetul pe calea
înaintării către destinaţie. Acesta serveşte pentru limitarea dimensiunii AS,
valoarea limită implicită fiind 100, dar poate fi stabilită în intervalul [1; 255].
Dacă numărul salturilor depăşeşte valoarea limită stabilită, atunci destinaţia
respectivă este anunţată ca inaccesibilă.
Pentru calcularea metricii sintetizate (M), se foloseşte expresia
 K 2C K5 (10.1)
256 ( K1C  256  L  K 3T ) R  K , dacă K 5  0
M  4
 256 ( K C  K 2 C
 K 3T ), dacă K 5  0
 1
256  L
unde K1-K5 sunt constante, valoarea cărora poate fi setată de administrator.
Implicit se folosesc valorile K1 = K3 = 1 şi K2 = K4 = K5 = 0, formula (10.1)
reducându-se la cea
M  256 (C  T ). (10.2)
Formula (10.2) foloseşte doar două metrici: lăţimea de bandă C şi reţinerea

T. EIGRP scalează configurarea lăţimii de bandă pentru interfeţe în modul
următor:
C = 107/lăţimea de bandă a interfeţei. (10.3)
De exemplu, dacă lăţimea de bandă a interfeţei este de 105 Kbps, adică 100
Mbps, atunci C = 107/105 = 100.
Pentru evitarea riscului de formare a unor bucle în rutarea pachetelor, se
recomandă folosirea, într-un AS EIGRP, a aceloraşi valori pentru mărimile K1-K5.
De menţionat că, pentru calcularea metricii sintetizate, IGRP foloseşte tot
formula (10.1), cu deosebirea că rezultatul, pentru expresiile din paranteze
380
pătrate, nu se înmulţeşte la 256. Faptul este cauzat de necesitatea convertirii,
pentru compatibilitate, a metricii IGRP pe 24 biţi în cea EIGRP pe 32 biţi: 24 +
log2256 = 32.
EIGRP este compatibil cu IGRP, convertind în mod automat metrica EIGRP
pe 32 biţi în cea IGRP pe 24 biţi.
Deosebirile de bază ale metodelor de rutare vector-distanţă ca IGRP şi
EIGRP de cele ale metodelor stare-legături ca IS-IS şi OSPF. Metodele de
rutare vector-distanţă calculează cele mai scurte căi în baza algoritmului
Bellman-Ford sau similare. Ele folosesc schimbul de informaţii privind vectorul
distanţelor de la fiecare nod până toate destinaţiile cunoscute. Ulterior nu se
mai efectuează schimbul de informaţii topologice, acestea considerându-se
constante.
Metodele de rutare stare-legături calculează cele mai scurte căi în baza
algoritmului Dijkstra sau similare. La calcularea celor mai scurte căi, se folosesc
informaţii actualizate privind starea-legăturilor, acestea considerându-se
dinamice. Fiecare ruter comunică celorlalte rutere modificările privind starea
legăturilor acestuia cu ruterele adiacente. Dacă au loc careva modificări în
starea-legăturilor, informaţiile respective sunt actualizate în timp real.
Astfel, deosebirile majore dinte aceste două categorii de metode de rutare
constau în următoarele:
 metodele vector-distanţă folosesc informaţii de rutare statice, pe când
cele stare-legături folosesc informaţii de rutare dinamice;
 informaţiile de rutare comunicate de fiecare ruter celorlalte rutere
conţin, la metodele vector-distanţă – vectorul distanţelor de la ruter
până toate destinaţiile posibile, iar la metodele stare-legături –
modificările privind starea legăturilor acestuia cu ruterele adiacente.
Deci, la metodele stare-legături traficul de date ce revine unei actualizări
este mai mic.
10.3.5. Protocolul BGP
Protocolul BGP (Border Gateway Protocol – Protocolul porţilor de
margine), descris în RFC 1105 (v.1, a. 1989), RFC 1163 (v.2), RFC 1267 (v.3),
RFC 1771 (v.4) şi RFC 4271, este un protocol pentru porţi exterioare vector-
distanţă sau, mai concret, protocol vector-cale (path vector). Este o dezvoltare
a Protocolului pentru porţi exterioare (Exterior Gateway Protocol – EGP),
aprobat în 1982 (RFC 827), care era limitat la topologii arbore. În contrast cu
EGP, BGPv4 permite rutarea complet descentralizată a pachetelor, suportă
CIDR şi agregarea rutelor pentru reducerea dimensiunii tabelelor de rutare.
Pentru schimbul de informaţii cu alte noduri, BGP foloseşte TCP prin portul
179. Ruterele vecine BGP, denumite şi perechi, se configurează manual pentru
381
crearea unei sesiuni TCP. Periodic, fiecare 30 s, BGP trimite mesaje de 19
octeţi pentru menţinerea conexiunii.
BGP poate fi folosit pentru rutarea pachetelor atât între sisteme
autonome, atunci acesta se numeşte BGP extern (External BGP – EBGP), cât şi
în cadrul AS, atunci acesta se numeşte BGP intern (Internal BGP – IBGP). IBGP
se foloseşte îndeosebi în reţele private de dimensiuni foarte mari. Ruterele de
margine ale unui AS, care realizează schimbul de informaţii cu alte AS, se
numesc rutere marginale (border router sau edge router).
10.3.6. Protocolul MME
Protocolul MME (Mesh Made Easy) este un protocol MikroTik de Nivel
Internet pentru reţele fără fir plasă (mesh). Are la bază ideile protocolului de
rutare B.A.T.M.A.N. (Better Approach To Mobile Ad-hoc Networking).
MME mai mult convine pentru reţele fără fir plasă cu o singură interfaţă
logică. Folosirea lui în reţele tradiţionale necesită un antet de pachet mai mare
chiar decât cel al pachetelor RIP şi nu se recomandă.
MME funcționează prin difuzarea periodică a aşa numitelor mesaje
iniţiatoare. Informaţiile de rutare ale unui asemenea mesaj constau din adresa
IP a iniţiatorului şi o listă opţională de prefixe IP – anunţuri de reţea. Dacă un
nod primeşte un mesaj iniţiator nemaiîntâlnit, atunci el îl redifuzează. Există şi
alte cazuri de redifuzare a mesajelor iniţiatoare (vezi mai jos).
Spre deosebire de alte protocoale de rutare, MME nu menţine informaţii
despre topologia reţelei. Respectiv, MME nu poate calcula tabelul de rutare,
dar nici nu are nevoie de acesta. În schimb, el urmăreşte pachetele primite,
inclusiv numerele lor de secvenţă, pentru a identifica cât de multe pachete s-
au pierdut. Cunoscând statisticile pierderii de mesaje, pentru toate
combinațiile de inițiatori și vecinii lor (la distanţa de un salt), MME poate găsi
cea mai bună poartă către o anumită destinație.
MME este specific reţelelor mobile plasă, pentru care:
 este, de obicei, imposibil de a cunoaşte topologia exactă, deoarece
aceasta se poate modifica rapid;
 modificările de topologie declanșează recalcularea tabelelor de rutare
pentru toate nodurile din rețea; pentru sistemele încorporate, aceasta
poate provoca încărcarea semnificativă a procesorului cu recalcularea
tabelului de rutare.
Pentru depăşirea acestor probleme, nodul MME:
 are grijă doar de vecinul către care este cel mai convenabil salt pentru o
anumită destinaţie;
 evită calcularea tabelului de rutare.
La funcţii secundare ale protocolului MME, îndeplinite de componenta
„protocolul de poartă” a acestuia, se referă: transportarea de informații
despre porţi către Internet și configurarea dinamică a rutelor implicite.
382
Pentru traficul de mesaje iniţiatoare, MME foloseşte portul 1966 al UDP,
iar protocolul de poartă al MME foloseşte portul 1968 al TCP.
Funcţiile de bază ale MME sunt:
 descoperirea automată a ruterului MME vecin (aşa numitul iniţiator –
originator);
 iniţierea mesajului iniţiator şi transmiterea periodică prin inundare a
acestuia prin fiecare interfaţă;
 redifuzarea mesajului iniţiator în baza unor reguli simple;
 selectarea celei mai convenabile porţi pentru fiecare ruter iniţiator şi a
rutelor anunţate de acesta.
Redifuzarea mesajului iniţiator conform regulilor:
 de nu redifuzat mesajele iniţiatoare proprii;
 de redifuzat mesajele cu fanionul unidirecțional setat dacă şi doar dacă:
- relaţia cu vecinul nu este bidirecţională;
- sau vecinul nu este cea mai convenabilă poartă către sine însuşi (adică
există o cale multisalt via acest nod);
 de redifuzat mesajele de la vecini (cu distanţa de un salt);
 de redifuzat mesajele ce nu sunt duplicate. Un mesaj se considera
duplicat, dacă un mesaj cu un asemenea număr de secvenţă a fost
recepţionat mai înainte;
 de redifuzat mesajele duplicate dacă şi doar dacă:
- ele au sosit de la un vecin care este poartă pentru ruterul iniţiator;
- parametrul TTL în pachet este egal cu ultimul TTL pentru această
combinare a vecinului şi iniţiatorului;
- relaţia cu vecinul nu este bidirecţională.
10.4. Rutarea pachetelor în RouterOS

10.4.1. Baza informaţiilor de rutare – RIB
RouterOS păstrează informaţiile de rutare în câteva spaţii distincte ale
Bazei informaţiilor de rutare (Routing Information Base – RIB):
 tabelele de rutare interne proprii ale protocoalelor de rutare, cu excepţia
celui BGP;
 tabele de rutare, grupate în baza valorilor parametrului routing-mark;
 tabelul de rutare principal (main);
 Baza informaţilor de înaintare (Forwarding Information Base – FIB).
Fiecare protocol de rutare, cu excepţia celui BGP, are tabele de rutare
interne proprii. Acestea servesc pentru selectarea celei mai bune, în sensul
protocolului dat, rute. BGP nu deţine tabele interne de rutare, ci stochează şi
foloseşte informaţiile de rutare de la toate perechile din RIB.
383
RIB conţine rute grupate, în baza valorilor parametrului routing-mark, în
tabele de rutare separate. Toate rutele, fără valoarea parametrului routing-
mark specificată, sunt păstrate în tabelul de rutare principal (main). Aceste
tabele sunt folosite pentru selectarea celei mai bune rute.
FIB conţine o copie a informaţiilor de rutare necesare pentru înaintarea
pachetelor: toate rutele active şi toate regulile politicii de rutare. Implicit, dacă
nu se foloseşte marcarea rutelor (routing-mark), atunci toate rutele active
sunt în tabelul de rutare principal, care şi se foloseşte pentru selectarea
rutelor pentru toate destinaţiile.
Schema organizării RIB este prezentată în figura 10.11 [1]. RIB conţine
informaţiile de rutare complete, inclusiv rutele statice, regulile politicii de
rutare configurate de utilizator, informaţiile de rutare parvenite de la
protocoalele de rutare, informaţiile despre reţelele conectate. RIB este folosită
pentru filtrarea informaţiilor de rutare, calcularea celei mai bune rute pentru
fiecare prefix destinaţie, construirea şi actualizarea FIB şi distribuirea rutelor
între diferite protocoale de rutare.
Fig. 10.11. Formarea şi folosirea RIB [1].

Implicit, decizia de înaintare se bazează doar pe valoarea adresei
destinaţie. Fiecare rută conţine parametrul dst-address, care cuprinde toate
adresele destinaţie pentru care poate fi folosită această rută. Dacă există
câteva rute, ce corespund unei adrese IP concrete, atunci se foloseşte ruta cea
mai specifică (vezi s. 10.2.3). Dacă tabelul de rutare conţine câteva rute cu
aceiaşi valoare a dst-address, doar una din ele poate fi folosită pentru
înaintarea pachetelor; această rută se înscrie în FIB şi se marchează ca activă
(Active).
Dacă la luarea deciziei de înaintare a pachetelor se folosesc informaţii
suplimentare de genul adresei sursă a pachetului, atunci este vorba de
„rutarea politică” (policy routing). Rutarea politică se implementează ca o listă
384
de reguli de rutare politică, care selectează tabele de rutare diferite, în funcţie
de adresa destinaţie, adresa sursă, interfaţa sursă şi marcajul rutei (routing mark).
Implicit toate rutele sunt păstrate în tabelul de rutare principal (main).
Rutele pot fi atribuite unui tabel de rutare specific prin setarea, ca valoare a
parametrului routing-mark, a numelui unui alt tabel de rutare. Tabele de
rutare sunt adresate după numele lor şi sunt create în mod automat când sunt
referenţiate în configurare.
Fiecare tabel de rutare poate avea doar o rută activă pentru fiecare valoare
a prefixului IP a dst-address.
10.4.2. Tipurile, originea și starea rutelor
Diferenţierea diferitelor rute după tip, origine şi stare este dată, în linii
mari, în ss. 10.2.3-10.2.7. Pentru specificarea categoriilor în cauză, în RouterOS
se folosesc anumite caractere, denumite fanioane (flags) şi anume:
X – rută dezactivată (Disabled), inactivă. Nu are efect asupra altor rute şi
nu se foloseşte pentru înaintarea pachetelor;
A – rută activă (Active), în uz. Ruta se foloseşte pentru înaintarea
pachetelor;
D – rută dinamică (Dynamic), definită de un protocol de rutare dinamică sau
de sistemul de operare. Ruta nu poate fi exportată sau modificată direct;
C – rută conectată (Connected), rută către o reţea conectată direct la
interfaţa respectivă a ruterului;
S – rută statică (Static), definită manual;
r – rută RIP, definită de protocolul RIP;
b – rută BGP, definită de protocolul BGP;
o – rută OSPF, definită de protocolul OSPF;
MME – rută MME, definită de protocolul MME (vezi s. 10.3.6);
B – rută “gaură neagră” (Blackhole), descarcă pachetele fără informare;
U – rută inaccesibilă (Unreachable), descarcă pachetele și transmite mesaje
ICMP că ruta nu asigură accesul la destinația specificată;
P – rută de interzicere (Prohibit), descarcă pachetele și transmite mesaje
ICMP că ruta interzice înaintarea pachetelor către destinaţie.
Unele exemple de specificare a tipului, originii și stării rutelor pot fi
regăsite în figurile 10.14, 10.15 din s.10.5.
10.4.3. Rute conectate
Conectate sunt rutele către reţelele conectate direct la interfeţele
ruterului. Ele se formează în mod automat la configurarea adreselor IP ale
interfeţelor respective ale ruterului. RIB nu modifică aceste rute.
Pentru fiecare rută conectată, există o adresă IP destinaţie şi:
385
 partea de adresă a dst-address (Destination, în exemplul din fig. 10.12) a
rutei conectate este egală cu adresa de reţea a adresei IP destinaţie
(Network, în exemplul din fig. 10.12);
 partea măştii de reţea a dst-address a rutei conectate (în exemplul din
fig. 10.8 – /24 la Destination: 192.168.100) este egală cu partea măştii de
reţea a adresei IP (în exemplul din fig. 10.12 – Address: 192.168.100);
 parametrul pref-src (în exemplul din fig. 10.12 – Pref. Source:
192.168.100.1) al rutei conectate este egal cu partea de adresă a adresei
IP (în exemplul din fig. 10.12 – Address: 192.168.100.1);
 parametrul interface (Interface, în exemplul din fig. 10.12) al rutei
conectate este egal cu parametrul active-interface al adresei IP.
Corespondenţa descrisă între parametri, pentru ruterele conectate, este
prezentată în exemplul din figura 10.12.
Fig. 10.12. Corespondenţa între parametri, pentru ruterele conectate [1].

10.4.4. Rute cu porţi interfaţă
În RouterOS valoarea porţii (gateway) poate fi specificată prin numele
interfeţei ruterului curent, în loc de adresa IP pentru saltul următor al
pachetului. Asemenea rute se numesc rute cu poartă interfaţă şi au
următoarele proprietăţi specifice:
 spre deosebire de rutele conectate, rutele cu poartă interfaţă nu se
folosesc pentru căutarea următorului salt (nexthop lookup);
 este posibil de atribuit câteva interfeţe ca valoare a porţii şi astfel de
creat rute ECMP. Nu este posibil de a avea rute conectate cu mai mult de
o valoare a porţii.
386
10.4.5. Selectarea rutelor
Fiecare tabel de rutare trebuie să conţină o rută activă pentru fiecare
prefix destinaţie. O asemenea rută este instalată în FIB. Ruta activă este
selectată din toate rutele candidate cu aceleaşi valori ale parametrilor dst-
address şi routing-mark – valori ce corespund criteriilor de a deveni rută
activă. Pot fi mai multe asemenea rute de la diferite protocoale de rutare şi
configurări statice. Ruta candidată, cu cea mai mică distanţă, devine rută
activă. Dacă sunt mai multe rute cu aceeaşi distanţă, ruta activă se selectează
în mod arbitrar, cu excepţia rutelor BGP.
Procesul de selectare a rutelor BGP este cel mai complex. Tabelele de
rutare BGP pot conţine sute de mii de rute. Pentru selectare, se foloseşte
Algoritmul de selectare a celei mai bune rute BGP (BGP Best Path Selection
Algorithm) – ABGP. Acesta compară rutele primite de la o singură instanţă
BGP. Rutele, instalate de diferite instanţe BGP, sunt comparate între ele
conform algoritmului general, selectând ruta cu cea mai mică distanţă.
Algoritmul ABGP constă în următoarele:
1. Ruterul ignoră ruta primită, dacă aceasta nu este validă. O rută este validă, dacă:
 următorul salt (NEXT_HOP) al rutei este valid şi accesibil;
 calea sistemului autonom (AS_PATH), primită de la perechile externe, nu
conţine sistemul autonom local;
 ruta nu este respinsă de filtrele de rutare.
2. Prima cale primită este în mod automat considerată „cea mai bună cale”.
Orice cale primită ulterior este comparată cu prima, pentru a determina
dacă noua cale este mai bună.
3. Se preferă calea cu cea mai mare pondere (WEIGHT). Parametrul WEIGHT
este unul local pentru ruterul pe care acesta este configurat. Ruta, căreia
nu-i este atribuită o valoare parametrului WEIGHT, foloseşte valoarea
implicită 0.
4. Se preferă calea cu cel mai înalt prefix LOCAL_PREF. Este folosit doar în
cadrul unui sistem autonom. Calea, căreia nu-i este atribuită o valoare
parametrului LOCAL_PREF, foloseşte valoarea implicită 100.
5. Se preferă calea cu cea mai mică valoare AS_PATH.
6. Se preferă calea de origine locală printr-o reţea agregată (cu un prefix mare
în loc de multe mici) sau una BGP (o listă de prefixe IP de a fi anunţate).
7. Se preferă calea cu cel mai mic tip ORIGIN. Protocolul IGP este mai mic
decât cel EGP, care, la rândul său, este mai mic decât cel INCOMPLETE.
Astfel,
IGP < EGP < INCOMPLETE. (10.3)
8. Se preferă calea cu cel mai mic parametru multi-exit discriminator (MED).
Ruterul compară atributele MED doar a căilor cu acelaşi sistem autonom
387
învecinat. Căile, fără o valoare MED explicită, sunt tratate ca şi căi cu
valoarea MED egală cu 0.
9. Se preferă căile eBGP faţă de cele iBGP.
10. Se preferă rutele primite de la ruterul BGP cu cel mai mic identificator
router ID.
11. Se preferă ruta cu cea mai scurtă listă route reflection cluster list. Rutele
fără o asemenea listă se consideră având o listă de lungime 0.
12. Se preferă calea ce provine de la vecinul cu cea mai mică adresă.
De menţionat că selectarea dependentă de protocol se efectuează doar
după ce rutele BGP au fost instalate în tabelul de rutare principal; adică poate
fi o rută candidată de la fiecare pereche BGP. De asemenea, rutele BGP, de la
diferite instanţe BGP, sunt comparate la fel ca şi alte rute.
Pentru a participa la procesul de selectare a celei mai bune rute, ruta
trebuie să corespundă următoarelor criterii:
 rută nu trebuie să fie dezactivată;
 distanţa (distance) rutei trebuie să fie mai mică de 255. Distanţa 255 o au
rutele respinse de filtrul de rutare;
 parametrul pref-src nu este setat sau este o adresă locală validă a
ruterului;
 parametrul routing-mark nu este setat sau este referit de regulile de i-
barieră sau cele ale politicii de rutare;
 dacă tipul rutei este unul monoadresat (unicast) şi aceasta nu este o rută
conectată, ea trebuie să aibă cel puţin un salt următor (nexthop)
accesibil.
La pasul următor de selectare a rutei, se caută saltul următor (nexthop
lookup). Rutele, instalate în FIB, trebuie să includă câte o interfaţă asociată cu
fiecare adresă de poartă (următorul salt). Adresa porţii trebuie să fie accesibilă
direct prin această interfaţă. Interfaţa, care trebuie să fie folosită pentru
trimiterea de pachete către fiece adresă de poartă, este determinată prin
căutarea saltului următor (nexthop lookup).
Unele rute, de exemplu cele iBGP, pot avea adrese de poartă la o distanţă
de câteva salturi de la ruter. Pentru instalarea unor asemenea rute în FIB, este
necesar de găsit adresa porţii accesibile direct (un salt imediat următor), care
şi ar trebui să fie folosită pentru a ajunge la adresa porții acestei rute. Adresele
saltului imediat următor sunt de asemenea găsite prin căutarea saltului
următor.
Căutarea saltului următor se efectuează doar în tabelul de rutare principal,
chiar şi pentru rutele cu valori diferite ale marcajului routing-mark. Este
necesar de a limita setul de rute, ce pot fi folosite pentru căutarea salturilor
imediat următoare. Valorile saltului următor pentru rutele RIP şi OSPF, de
exemplu, ar trebui să fie direct accesibile și ar trebui să fie căutate doar
388
folosind rute conectate. Acest lucru este realizat, folosind domeniul de
aplicare (scope) și proprietățile domeniului de aplicare-țintă (target-scope). În
acest context, de menţionat că:
 rutele cu poartă nume interfaţă nu se folosesc pentru căutarea saltului
următor. Dacă ruta are ca salturi următoare atât nume de interfeţe, cât şi
adrese IP active, atunci salturile următoare prin nume de interfeţe se
ignoră;
 rutele cu parametrul scope mai mare decât valoarea acceptată maximă
nu se folosesc pentru căutarea saltului următor. Fiecare rută specifică
valoarea acceptată maximă a parametrului scope, pentru valorile
salturilor următoare, în cadrul proprietăţii target-scope. Valoarea
implicită a acestei proprietăți permite căutarea saltului următor doar
printre rutele conectate, cu excepţia rutelor iBGP care au o valoare
implicită mai mare şi pot căuta saltul următor de asemenea printre rutele
IGP şi cele statice.
Interfaţa şi saltul imediat următor sunt selectate în baza rezultatelor
căutării saltului următor:
 dacă ruta activă cea mai specifică, determinată la căutarea saltului
următor, este una conectată, atunci interfaţa acestei rute este folosită ca
interfaţă a saltului următor, iar această poartă este marcată ca accesibilă
(reachable). Deoarece poarta este direct accesibilă prin această interfaţă
(conform definiţiei rutelor conectate), adresa acestei porţi este folosită
ca adresă a saltului imediat următor;
următor, are saltul următor deja decis, adresa şi interfaţa saltului imediat
următor sunt copiate de la acest salt următor şi această poartă este
marcată ca recursivă (recursive). Căutarea recursivă a saltului următor
este descrisă în exemplul 10.4;
următor, este una ECMP, atunci se foloseşte prima poartă, ce nu este
inaccesibilă, a acestei rute;
 dacă la căutarea saltului următor nu este găsită nici o rută, atunci poartă
în cauză este marcată ca inaccesibilă (unreachable).
Exemplul 10.4. Căutarea recursivă a saltului următor [1]. Fie cazul din
figura 10.13. În acest exemplu, saltul următor 10.2.0.1 din RIB este decis prin
ruta conectată, al cărei statut este reachable (accesibilă). În ce priveşte saltul
următor 10.3.0.1 din RIB, acesta este decis recursiv prin ruta 10.3.0.0/16, al
cărei statut este recursive (recursivă) şi care foloseşte ca salt imediat următor
valoarea 10.2.0.1; această valoare şi este instalată în FIB.
389
Fig. 10.13. Căutarea recursivă a saltului următor [1].
10.4.6. Baza informaţiilor de înaintare – FIB

După cum a fost menţionat în s. 10.4.1, FIB conţine o copie a informaţiilor
de rutare necesare pentru înaintarea pachetelor: toate rutele active şi toate
regulile politicii de rutare. Implicit, dacă nu se foloseşte marcarea rutelor
(routing-mark), atunci toate rutele active sunt în tabelul de rutare principal
(main), care şi se foloseşte pentru selectarea rutelor pentru toate destinaţiile.
Pentru a determina destinaţia unui pachet, FIB foloseşte următoarele
informaţii: adresa sursă; adresa destinaţie; interfaţa sursă; marcajul rutei
(routing-mark); ToS (nu se foloseşte de RouterOS în regulile politicii de rutare,
dar este parte a cheii de căutare a informaţiilor cache de rutare).
Decizia de rutare poate fi:
 de recepţionat local pachetul;
 de aruncat pachetul (fără informare sau cu trimiterea unui mesaj ICMP la
emiţătorul pachetului);
 de trimis pachetul la o adresă IP anume a unei interfeţe anume.
Rezultatele deciziei de rutare sunt memorate în memoria cache de rutare,
pentru îmbunătăţirea performanţelor de înaintare a pachetelor. La rutarea
unui alt pachet, cu aceleaşi valori ale parametrilor enumeraţi mai sus, se
folosesc informaţiile din memoria cache de rutare. Aceasta permite, de
asemenea, implementarea echilibrării per-conexiune a traficului folosind rute
ECMP, deoarece valorile, utilizate la căutarea înregistrărilor în memoria cache
de rutare, sunt aceleaşi pentru toate pachetele ce ţin de aceeaşi conexiune şi
se transmit în aceeaşi direcţie.
Dacă, pentru pachetul dat, în memoria cache de rutare nu există nici o
înregistrare, atunci una este creată prin lansarea următoarei decizii de rutare:
 se verifică dacă pachetul trebuie să fie livrat local (adresa destinaţie este
una a ruterului);
 se procesează regulile implicite ale politicii de rutare;
 se procesează regulile politicii de rutare adăugate de utilizator;
390
 se procesează regulile implicite de căutare a destinaţiei în tabelul de
rutare principal;
 se returnează rezultatul „reţea inaccesibilă”.
Regulile, ce nu se potrivesc pachetului dat, se ignoră. Dacă regulă conţine
acţiunea drop (aruncare) sau unreachable (inaccesibilă), atunci aceasta se
returnează ca rezultat al procesului de luare a deciziei de rutare. Dacă
acţiunea este lookup (căutare), atunci adresa destinaţie a pachetului este
căutată în tabelul de rutare specificat în regulă. Dacă căutarea cade, adică nu
există nici o rută care s-ar potrivi adresei destinaţie a pachetului, atunci FIB
trece la următoarea regulă. Altfel:
 dacă tipul rutei este blackhole, prohibit sau unreachable, atunci, ca
rezultat al deciziei de rutare, se returnează această acţiune;
 dacă aceasta este o rută conectată sau o rută cu poartă nume de
interfaţă, atunci, ca rezultat al deciziei de rutare, se returnează această
interfaţă şi adresa destinaţie a pachetului;
 dacă această rută are o adresă IP ca valoare a porţii, atunci, ca rezultat al
deciziei de rutare, se returnează această adresă şi interfaţa asociată;
 dacă această rută are valori multiple de salt, atunci se alege una din ele
prin rotaţie.
Rezultatul acestei decizii de rutare se stochează într-o nouă înregistrare a
memoriei cache de rutare.
10.4.7. Parametrii rutelor
În funcţie de sistemul de operare folosit, rutele pot fi caracterizate de
diverşi parametri; o parte din aceştia au fost descrişi în ss. 10.2.2-10.2.7,
10.4.1-10.4.6. În RouterOS, conform notării folosite în WinBox, rutele se
caracterizează de aşa parametri ca:
 Check Gateway – fiecare 10 s poarta se verifică, prin trimiterea unei
cereri ecou ICMP (ping) sau a unei cereri ARP (arp). Dacă timp de 10 s de
la poartă nu urmează nici un răspuns, se solicită o pauză (time out). După
două solicitări de pauză, poarta se consideră inaccesibilă. După recepţia
răspunsului de la poartă, aceasta se consideră accesibilă şi contorul de
pauze este resetat;
 Distance – distanţa (vezi s. 10.2.4). Se preferă rutele cu valoarea mai mică
a distanţei. Dacă valoarea distanţei nu este setată, atunci valoarea
implicită a acesteia depinde de protocolul de rutare:
- rutele conectate: 0;
- rutele statice: 1;
- eBGP: 20;
- OSPF: 110;
- RIP: 120;
- MME: 130;
391
- iBGP: 200;
 Dst. Address – prefixul IP al rutei, reprezintă adresa destinaţie (vezi s.
10.2.2) pentru care poate fi folosită ruta în cauză. Valoarea implicită este
0.0.0.0/0. Dacă există mai multe rute, ce se potrivesc adresei destinaţie a
pachetului, atunci se foloseşte ruta cea mai specifică (vezi s. 10.2.3);
 Gateway – poarta (vezi s. 10.2.2), reprezentată printr-un şir de adrese IP
sau nume de interfeţe. Specifică interfaţa către care trebuie să fie
transmise pachetele. Rutele conectate şi, de asemenea, cele de tip
blackhole, unreachable sau prohibit nu au un asemenea parametru.
Valoarea acestui parametru este, de obicei, o singură adresă IP a porţii, la
care se poate ajunge direct prin una din interfeţele ruterului. Rutele
ECMP au mai mult de o valoare a porţii. Valoarea poate fi repetată de
câteva ori;
 Pref. Source – adresa IP locală de folosit pentru transmisia pachetelor de
origine locală. Nu are efect pentru pachetele de tranzit. Dacă valoarea
acestui parametru este setată la o adresă IP, care nu este adresă locală a
acestui ruter, atunci ruta va fi inactivă. Dacă valoarea acestui parametru
nu este setată, atunci, pentru pachetele de origine locală, care se
transmit via această rută, ruterul va alege una din adresele locale ataşate
la interfaţa de ieşire ce se potriveşte prefixului destinaţie a rutei;
 Routing Mark – numele tabelului de rutare ce conţine ruta. Valoarea
implicită – nu este setată, ceea ce semnifică tabelul de rutare principal
(main). La un ruter pot fi folosite până la 250 de marcaje de nume de
tabele de rutare;
 Scope – domeniu de aplicare. Se foloseşte ca rezoluţie pentru saltul
următor. Ruterul poate determina saltul următor doar din rutele cu
valoarea scope mai mică sau egală cu valoarea parametrului target-scope
a rutei în cauză. Valoarea implicită depinde de protocolul de rutare:
- rute conectate: 10 (dacă interfaţa rulează – running);
- rute OSPF, RIP, MME: 20;
- rute statice: 30;
- rute BGP: 40;
- rute conectate: 200 (dacă interfaţa nu rulează).
 Target Scope – domeniul ţintă de aplicare. Se foloseşte ca rezoluţie
pentru saltul următor. Este valoarea maximă a scope pentru o rută, prin
care poate fi decis un salt următor. Valoarea implicită este 10, cu
excepţia iBGP, pentru care aceasta este 30;
 Type – tipul rutei. Poate avea valoarea unicast, blackhole (B), prohibit (P)
sau unreachable (U). Valoarea implicită este unicast. Rutele de tipurile B,
P şi U nu specifică saltul următor pentru pachete, ci definesc execuţia
anumitor acţiuni asupra acestora (vezi s. 10.4.2);
392
 Gateway Status – statutul porţii. Poate avea una din valorile
unreachable, reachable sau recursive (vezi s. 10.4.5).
 OSPF Metric – metrica OSPF de folosit (vezi s. 10.3.2.4) ş.a.
De asemenea, rutele se caracterizează prin origine şi stare (vezi s. 10.4.2).
10.5. Implementarea rutării statice în reţele simple

Rutele tabelului de rutare în WinBox pot fi vizualizate, acţionând
/IP/Routes/Route List/Routes. Un exemplu este prezentat în figura 10.14. Din
tabel devine clar, către care subreţele prin ce poartă este prevăzută
transmiterea pachetelor de date.
Pentru a defini o rută, în fila Routes, se acţionează +/New Route/General
şi, în câmpul Dst. Address, se specifică adresa subreţelei destinaţie, iar în
câmpul Gateway – adresa porţii (fig. 10.14).
Fig. 10.14. Definirea unei rute statice.

După cum se vede din figura 10.14, în fila General pot fi specificate valorile
şi pentru alţi parametri, inclusiv: Type, Distance, Scope, Target Scope, Routing
Mark, Pref. Source, semnificaţia cărora este descrisă în s. 10.4.6. Încă
parametri, preponderent cei ce ţin de protocolul BGP, pot fi setaţi în fila
Attributes.
Dacă se doreşte vizualizarea şi/sau a parametrilor unei rute anume, atunci
prin dublu clic pe înregistrarea acesteia în fila Routes a ferestrei Route List, se
va afişa fereastra Route <adresă_destinaţie_rută> similară celei New Route, cu
393
aceleaşi două file – General şi Attributes, din figura 10.14. Deosebirea constă
doar în titlul ferestrei.
Din cele trei rute, ce se întrevăd în fila Routes a ferestrei Route List, doar
prima rută este statică, în prima coloană a înregistrării respective fiind
prezente caracterele A (rută activă) şi S (rută statică). Celelalte două rute sunt
dinamice (D) active (A) conectate (C). Rutele DAC se adaugă, în tabelul de
rutare, în mod automat, la atribuirea adreselor IP interfeţelor ruterului.
Pentru ca o reţea să fie accesibilă, trebuie definite adresele interfeţelor
ruterului în Lista de adrese (Address List) şi rutele în Lista de rutare (Route
List), figura 10.15.
Fig. 10.15. Tabelul de adrese şi tabelul de rutare.

Exemplul 10.5. Setarea rutei implicite. Fie reţeaua din figura 4.8 a s. 4.2.1.
Se cere definirea la ruterul utilizatorului a rutei implicite, la următoarele date
iniţiale: DHCP Client pe interfaţa wlan1 – activat; adresa IP a wlan1 –
192.168.1.100/24, adresa IP a porţii implicite – 192.168.1.1.
La moment, poarta implicită este configurată de DHCP Client. Pentru a o
defini manual, trebuie, mai întâi, de dezactivat DHCP Client. De asemenea,
trebuie de setat adresa IP a interfeţei wlan1. Astfel:
1. Se dezactivează DHCP Client: /IP/DHCP Client/DHCP Client, clic dreapta pe
înregistrarea wlan1/Disable/OK.
2. Se atribuie adresa IP interfeţei wlan1: /IP/Addresses/Address List, +/New
Address, Addresses – 192.168.1.100/24, Interface – wlan1/OK.
3. Se defineşte ruta implicită: /IP/Routes/Route List/Routes, +/New Route/
General, Dst. Address – 0.0.0.0/0, Gateway – 192.168.1.1/OK.
4. Se verifică, prin ping, posibilitatea accesării porţii 192.168.1.1.
394
Sarcina practică 10.1. Setarea rutei implicite. Fie reţeaua din figura 4.8 a s.
4.2.1. Este necesar de definit ruta implicită pentru ruterul utilizatorului, la
datele iniţiale specificate de profesor.
Exemplul 10.6. Setarea de rute statice. Fie reţeaua din figura 4.8 a s. 4.2.1.
Se cere definirea de rute statice la ruterul utilizatorului, astfel ca să fie posibil
accesul calculatoarelor vecinilor, la datele iniţiale obţinute după finalizarea
exemplului 10.5, adică: DHCP Client pe interfaţa wlan1 – dezactivat; adresa IP
a wlan1 – 192.168.1.100/24; adresa IP a porţii implicite – 192.168.1.1 (AP).
Suplimentar, sunt cunoscute datele iniţiale privind subreţeaua vecinului şi
ruterul lui: adresa IP a interfeţei fără fir a ruterului vecinului – 192.168.1.2/24;
adresa IP a calculatorului vecinului – 192.168.2.1/24, conectat la interfața
ruterului vecinului cu adresa 192.168.2.254/24.
Deoarece sunt definite adresele IP ale ruterelor reţelei, rutele conectate
sunt de asemenea cunoscute. Astfel ruterul-AP cunoaşte toate ruterele
utilizatorilor conectate la el. Însă, implicit, AP nu deţine informaţii despre
subreţelele conectate la ruterele-clienţi ale utilizatorilor. Pentru ca să fie
posibil schimbul de date între calculatoarele utilizatorilor, este necesară
definirea de rute statice respective. În acest scop:
1. Se defineşte ruta statică către ruterul vecinului: /IP/Routes/Route List/
Routes, +/New Route/General, Dst. Address – 192.168.2.0/24, Gateway –
192.168.1.2/OK.
2. Se verifică posibilitatea accesării calculatorului vecinului, prin ping la adresa
192.168.2.1/24.
Sarcina practică 10.2. Setarea de rute statice. Fie reţeaua din figura 4.8 a
s. 4.2.1. Este necesar de definit rute statice la ruterul utilizatorului, astfel ca să
fie posibil accesul calculatorului unui vecin, la datele iniţiale obţinute după
finalizarea sarcinii practice 10.1 şi consultând setările subreţelei vecinului,
conform exemplului 10.6.
10.6. Implementarea OSPF pe un singur domeniu

După cum a fost menţionat în ss. 10.3.2.2, 10.3.2.11, 10.3.2.12, OSPF poate
fi configurat pentru un AS monodomeniu (single domain), denumit şi
monozonă (single-area), sau pentru unul multizonă (multiple-area). Divizarea
în mai multe zone OSPF este recomandată în cazurile unor AS de mari
dimensiuni. Pentru AS de dimensiuni mici, este oportună folosirea unui singur
domeniu OSPF.
Exemplul 10.7. Setarea OSPF pe un singur domeniu. Fie reţeaua din figura
4.8 a s. 4.2.1, considerată ca un AS. Ruterele AS ţin de reţeaua 192.168.1.0/24.
Se cere de implementat, în acest AS, rutarea dinamică, folosind OSPF.
Deoarece reţeaua este relativ mică, AS nu se va diviza în zone.
395
În acest scop:
1. Se startează, în reţea, OSPF:
/Routing/OSPF/OSPF/Networks, +/
New OSPF Network – 192.168.1.0/24
/OK. Pentru parametrul Area se
Fig. 10.16. Startarea OSPF.
păstrează opţiunea implicită –
backbone (fig. 10.16).
2. Pentru ca în tabelul de rutare (Route List – /IP/Routes) să fie rute către
vecini, ei tot trebuie să starteze OSPF.
3. Se verifică prezenţa rutelor către vecini, în tabelul de rutare Route List:
/IP/Routes/Route List.
4. Se verifică, prin ping, posibilitatea schimbului de date cu calculatoarele
vecinilor.
Sarcina practică 10.3. Setarea OSPF pe un singur domeniu. Fie reţeaua din
figura 4.8 a s. 4.2.1, considerată ca un AS. Ruterele AS ţin de reţeaua
192.168.100.0/24. Se cere de implementat, la fiecare din ruterele acestui AS,
rutarea dinamică, folosind OSPF pe un singur domeniu conform exemplului
10.7.
396
11. FOLOSIREA TUNELELOR ÎN REŢELE
11.1. Caracteristica generală a tunelării în reţele
11.1.1. Aspecte de bază
11.1.1.1. Esenţa tunelării
Pentru crearea de legături directe între noduri adiacente, în Internet se
foloseşte protocolul PPP (Point-to-Point Protocol) de Nivel 2 OSI (L2). În cadrul
legăturii se poate folosi autentificarea, transmiterea cifrată a datelor şi
compresia de date. Spre deosebire de legătura directă între noduri adiacente,
tunelul de transfer date poate fi stabilit şi între noduri neadiacente ale uneia şi
aceleiași reţele sau chiar ale unor reţele diferite.
În rețelele de calculatoare tunelare se numeşte încapsularea specială, de
către un protocol de reţea (protocol de livrare), a datelor de transmis între
două noduri ale unui alt protocol de reţea. Aceasta permite transportul de
date via una sau mai multe rețele ce nu corespund anumitor cerinţe de livrare,
inclusiv tunelul poate să ofere o cale sigură de transfer date printr-o rețea
nesigură. Protocolul de tunelare poate folosi, la necesitate, cifrarea datelor.
De obicei, protocolul de tunelare operează la acelaşi nivel de reţea sau
unul superior celui, la care operează protocolul datele căruia se încapsulează.
Tunelele pot fi de Nivel 2 sau de Nivel 3 OSI. Tunelarea de Nivel 3 presupune
existenţa unei conectivităţi IP înainte de iniţierea tunelului, pe când cea de
Nivel 2 prevede, mai întâi, crearea tunelului la Nivelul 2 şi doar apoi stabilirea
conexiunii de Nivel 3.
11.1.1.2. PPP ca protocol L2 între nodurile terminale ale tunelelor
Tunelele pot fi formate atât între noduri terminale ale unei reţele locale,
cât şi între noduri ale unei reţele WAN. Pentru tunelarea datelor peste reţele
IP, pot fi folosite diverse protocoale. Unele din aceste protocoale, de exemplu
cele SSL/TLS, SSH sau L2TP, creează, la fiecare din cele două noduri terminale
ale tunelului, câte o interfaţă de reţea virtuală. Legătura între aceste două
interfeţe virtuale formează impresia unei conexiuni fizice directe între nodurile
terminale ale tunelului.
Deoarece tunelul conţine doar două noduri terminale, el poate fi
reprezentat ca o conexiune punct-la-punct, iar PPP poate fi folosit ca protocol
de Nivel 2 între cele două interfeţe virtuale. Astfel, PPP poate atribui adrese IP
acestor interfețe virtuale – adrese, ce pot fi folosite, de exemplu, pentru
rutarea pachetelor pe traseul între cele două noduri terminale.
397
Poate contribui la înţelegerea tunelării, stiva TCP/IP de protocoale pentru
tunelul SSH+PPP din tabelul 11.1.
Tabelul 11.1. Stiva TCP/IP pentru tunelul SSH+PPP
Nivelul TCP/IP Protocoale, tehnologii de reţea
Aplicaţie Telnet, FTP, SMTP, HTTP, DNS, …
Transport TCP, UDP
Internet IP
Legătură de date PPP
Aplicaţie SSH
Transport TCP
Internet IP
Legătură Ethernet, ATM
Există şi protocoale de tunelare ce nu creează interfeţe virtuale la cele
două noduri terminale ale tunelului, de exemplu, cel IPsec. Asemenea tunele
sunt gestionate direct de stiva TCP/IP.
O altă cale de gestionare a unor aşa tunele ar fi îmbinarea folosirii unui
asemenea protocol de tunelare cu un alt protocol, care ar crea interfeţele
virtuale în cauză. Ca exemplu de asemenea îmbinare poate servi cea
L2TP/IPsec. Protocolul L2TP creează interfeţele virtuale la cele două capete ale
tunelului IPsec. În asemenea cazuri, PPP este de asemenea folosit pentru
atribuirea de adrese IP celor două interfeţe virtuale.
11.1.2. Tipuri de tunele
În reţele se folosesc aşa tipuri de tunele ca:
 EoIP (Ethernet over IP – Ethernet peste IP);
 GRE (Generic Routing Encapsulation – Încapsularea de rutare generică);
 IPIP (IP inside IP – IP în cadrul IP);
 PPTP (Point to Point Tunneling Protocol – Protocol de tunelare punct la
punct);
 L2TP (Layer 2 Tunneling Protocol – Protocol de tunelare de Nivel 2);
 PPPoE (Point to Point over Ethernet – Protocol punct la punct peste
Ethernet);
 MLPPPoE (Multilink PPPoE – PPPoE multilegătură);
 IPsec (Internet Protocol Security – Securitatea protocolului Internet);
 SSTP (Secure Socket Tunneling Protocol – Protocol de tunelare prin soclu
securizat);
 OpenVPN, notat şi OVPN (Open Virtual Private Network – Reţea privată
virtuală sursă deschisă);
 VPLS (Virtual Private Service – Serviciu privat virtual).
398
Descrierea succintă a tunelelor enumerate este dată în ss. 11.1.3-11.1.13,
iar o caracteristică comparativă a unora din ele – în s. 1.1.14.
11.1.3. Tunele EoIP
Tunelarea EoIP (Ethernet over IP) de Nivel 2 este propusă de MikroTik. EoIP
permite crearea de tunele Ethernet între două rutere deasupra unei conexiuni
IP via Internet (fig. 11.1). Deși EoIP nu cifrează datele transmise, el poate rula
peste alte tunele, inclusiv cele IPIP și PPTP. Dacă funcţionalitatea de puntare a
ruterului este activată, atunci traficul Ethernet între cele două rutere din
Internet va fi puntat ca și cum acestea ar fi interconectate printr-un cablu.
Fig. 11.1. Tunelarea EoIP [1].

Protocolul EoIP încapsulează cadrele Ethernet în pachete GRE (Protocolul
Internet 47), la fel ca și PPTP, pe care le trimite către nodul distant al tunelului.
Tunelul EoIP adaugă la antet 42 de octeți (8 octeți GRE, 14 octeți Ethernet și
20 octeți IP). Este important ca, la puntarea tunelelor EoIP, de setat adrese
MAC unice, folosind pentru interfețele EoIP adrese din diapazonul special
00:00:5E:80:00:00 - 00:00:5E:FF:FF:FF, rezervat în asemenea scopuri de IANA.
11.1.4. Tunele GRE
Tunelarea GRE (Generic Routing Encapsulation), descrisă în RFC 1701 și
RFC 1702 (1994) și dezvoltată în RFC 2637 (1999), RFC 2784 şi RFC 2890
(2000), este propusă de compania Cisco, pentru încapsularea unei varietăți
largi de protocoale de Nivel 3 în cadrul unor legături virtuale punct-la-punct
peste IP. Tunelul GRE poate înainta doar pachete IP. Tunelarea GRE este în
mare parte la fel ca și cele IPIP și EoIP.
Protocolul GRE poate fi folosit împreună cu IP, PPTP, IPsec, protocoale de
mobilitate (Mobility) ș.a. Pachetele GRE, încapsulate în cadrul IP, folosesc
protocolul Internet 47.
399
11.1.5. Tunele IPIP
Tunelarea IPIP, denumită şi IP-in-IP şi descrisă în RFC 2003 (1996) şi
dezvoltată în RFC 3168 şi RFC 6864, este una ce încapsulează pachete IP în alte
pachete IP, permițând crearea unui tunel între două rutere IP. O asemenea
încapsulare permite anihilarea rutării IP obişnuite a pachetelor IP respective,
prin livrarea acestora către o destinaţie intermediară. Ea poate fi folosită în
diverse scopuri, inclusiv pentru: livrarea pachetelor către un nod mobil,
folosind Mobile IP; tunelarea de rețele intranet via Internet; folosirea în locul
rutării statice ș.a.
Încapsularea IPIP, prevede adăugarea, la pachetul IP iniţial, a încă unui
antet cu câmpurile Source IP Address (adresa IP Sursă) – punctul de intrare al
tunelului (encapsulator – încapsulatorul), şi Destination IP Address (adresa IP
Destinaţie) – punctul de ieşire al tunelului (decapsulator – decapsulatorul).
Antetul exterior conţine şi multe alte câmpuri, inclusiv: Version, Header
Length, Type of Service, Total Length, Identification, TTL, Protocol, Header
Checksum ş.a.
Pachetul interior nu se modifică, cu excepţia câmpului TTL, care este
decrementat. Câmpurile Don’t Fragment şi Type of Service se copie în antetul
exterior. Dacă dimensiunea noului pachet este mai mare decât Path MTU,
atunci pachetul este, în mod obişnuit, fragmentat, la punctul de intrare al
tunelului, şi defragmentat, la punctul de ieşire al tunelului.
În cazul general, IPIP se foloseşte conform schemei din figura 11.2,
nodurile sursă, încapsulator, decapsulator şi destinaţie fiind diferite; în cazuri
particulare, pot coincide nodurile sursă şi încapsulator şi/sau cele decapsulator
şi destinaţie. Nodul de încapsulare se consideră punct de intrare al tunelului,
iar nodul de decapsulare – punct de ieşire al tunelului. De asemenea, acelaşi
tunel poate fi folosit pentru mai multe noduri sursă şi noduri destinaţie.
Sursa Încapsulator Decapsulator Destinaţia
Fig. 11.2. Schema generală a folosirii tunelelor IPIP.
11.1.6. Tunele PPTP

Protocolul PPTP (Point-to-Point-Tunelling Protocol), publicat în 1999 (RFC
2637), este o extensie a celui PPP pentru tunelarea PPP prin reţele IP la
accesarea Internet prin canale comutate ale reţelelor PSTN (Public Switch
Telephone Network – Reţele telefonice publice cu comutare de canale) sau
ISDN. PPTP nu defineşte careva modificări pentru PPP, ci doar specifică o nouă
modalitate de transport pentru trafic PPP.
PPTP este un protocol de control şi gestiune a apelurilor, care permite
serverului să controleze accesul apelurilor prin canale comutate ale reţelelor
PSTN sau ISDN. Tunelele PPTP servesc pentru apelarea (accesul) la distanţă,
400
inclusiv la domiciliu, a unei reţele pe care este configurat un server PPTP.
Clientul PPTP, necesar în acest scop la staţia client, poate fi creat în Windows,
Mac OSX, RouterOS sau un alt sistem de operare. Odată instalate, serverul şi
clientul PPTP, de la client se poate iniţia formarea conexiunii în cauză, iar după
stabilirea conexiunii, staţia client va avea acces la resursele reţelei distante.
Bineînţeles, în loc de staţia client poate fi şi un ruter.
Protocolul PPTP are o arhitectură client-server. Serverul de reţea PPTP
(PPTP Network Server – PNS) este conceput să ruleze pe sisteme de operare
ordinare, pe când clientul PPTP, denumit şi Concentrator de acces PPTP (PPTP
Access Concentrator – PAC), – să opereze pe o platformă de acces prin apel
(dial access platform).
PAC este responsabil de aşa funcţii ca:
 asigurarea interfeţei fizice către PSTN şi ISDN şi gestiunea modemelor
externe sau a adaptoarelor, inclusiv: adaptarea vitezei de lucru,
convertirea analogo-numerică, convertirea transmisiei sincrone în cea
asincronă ş.a.;
 desfiinţarea logică a unei sesiuni LCP PPP;
 posibil, participarea în protocoalele de autentificare PPP.
La rândul său, PNS este responsabil de aşa funcţii ca:
 posibil, participarea în protocoalele de autentificare PPP;
 agregarea canalelor şi gestiunea trunchiurilor pentru protocolul MLPPP;
 încheierea logică a diverselor protocoale NCP PPP;
 rutarea şi traversarea multiprotocol între interfeţele serverelor de acces
la reţea.
PPTP are grijă de transferul unităţilor de date ale protocolului PPP între
PAC şi PNS şi, de asemenea, controlul şi gestiunea apelurilor. Astfel, PPTP
constă din PAC şi PNS, între care este posibil schimbul de informaţii necesar.
Tunelul PPTP transportă datagrame PPP între PAC şi PNS. În cadrul unui tunel,
definit de o pereche PNS-PAC, pot fi multiplexate mai multe sesiuni. O
conexiune de control, ce operează deasupra TCP prin portul 1723, controlează
stabilirea, lansarea şi menţinerea sesiunilor şi a tunelului PPTP înseşi.
Pentru acces la un tunel PPTP printr-o reţea cu apeluri (PSTN, ISDN, etc.),
trebuie ca aceasta să fie conectată la un PAC, iar produsele program client PPP
standard trebuie să ruleze pe legăturile PPP tunelate.
PPTP poate, de asemenea, să fie folosit pentru tunelarea unei sesiuni PPP
printr-o reţea IP. Într-un asemenea caz, tunelul PPTP şi sesiunea PPP rulează
între aceleaşi două noduri, apelantul acţionând ca un PNS. În asemenea cazuri,
PPTP este un tunel securizat pentru transportul de trafic IP folosind PPP. PPTP
încapsulează PPP în linii virtuale ce rulează peste IP. Pentru a crea legături
cifrate, PPTP încorporează PPP şi MPPE (Microsoft Point to Point Encryption).
401
Pentru a realiza transmiterea de pachete de 1500 octeţi şi mai mari
(Multilink Maximum Received Reconstructed Unit – MRRU) şi, de asemenea,
pentru puntarea peste legături PPP (folosind protocolul BCP – Bridge Control
Protocol, care permite transmiterea de cadre Ethernet primare peste legături
PPP), PPTP suportă MLPPP (Multilink PPP). Aceasta permite puntarea fără
EoIP. În acest scop, deoarece legăturile PPP nu folosesc adrese MAC, puntea
va avea setată o adresă MAC sau va fi pe o interfaţă Ethernet.
Se preconizează că între PAC-uri şi PNS-uri vor exista relaţii mulţi-la-mulţi.
Un PAC poate oferi servicii mai multor PNS-uri. De exemplu, un furnizor de
servicii Internet poate folosi PPTP pentru crearea de VPN-uri mai multor
clienţi. Fiecare reţea privată poate rula unul sau mai multe PNS-uri. Un singur
PNS poate fi asociat cu mai multe PAC-uri, în scopul concentrării traficului de
date de la un număr mare de situri, amplasate în diverse locuri.
PPTP foloseşte o versiune extinsă a GRE (Generic Routing Encapsulation),
pentru a transporta pachete de date PPP. Aceste îmbunătăţiri permit controlul
fluxului şi al congestiei de nivel inferior în cadrul tunelelor, folosite pentru
transportul de date între PAC şi PNS. Ele asigură o folosire eficientă a lăţimii de
bandă disponibile tunelelor şi evitarea retransmisiilor inutile şi a depăşirilor de
memorie tampon necesară. PPTP nu impune careva algoritmi speciali pentru
acest control de nivel inferior, dar defineşte parametrii, care trebuie să fie
comunicaţi, ca aceşti algoritmi să poată lucra eficient.
Pachetele PPP GRE includ un câmp suplimentar de confirmare, în locul
câmpului de rutare al antetului GRE. Asemenea pachete sunt încapsulate în
pachete IP cu numărul de protocol 47. Tunelul GRE este folosit pentru
transferul pachetelor PPP încapsulate, permiţând tunelarea oricăror
protocoale, suportate de PPP, inclusiv a celor IP, IPX şi NetBEUI.
Funcţionarea PPTP are la bază două componente paralele:
1) o conexiune de control între PAC şi PNS, ce operează în pereche
deasupra TCP;
2) un tunel IP între aceleaşi PAC şi PNS, folosit să transporte pachete PPP
încapsulate GRE pentru sesiuni utilizator între PAC şi PNS în cauză.
În scopul tunelării PPP între PAC şi PNS, este necesar de stabilit, mai întâi, o
conexiune de control între aceştia. Conexiunea de control reprezintă o sesiune
TCP standard, prin care este transmisă informația de control și gestiune a
apelului respectiv. Sesiunea de control este logic asociată cu, dar separată de
la, sesiunile tunelate prin tunelul PPTP.
Pentru fiecare pereche PAC-PNS există atât un tunel, cât și o conexiune de
control. Conexiunea de control este responsabilă de stabilirea, lansarea,
gestiunea și desființarea sesiunilor realizate prin tunel. Aceasta este mijlocul,
prin care PNS este informat despre primirea unui apel de la PAC asociat, și, de
asemenea, mijlocul, prin care PAC primește instrucțiuni privind plasarea unui
402
apel de ieșire. Conexiunea de control poate fi stabilită de PAC sau de PNS, în
modul tradițional de stabilire a conexiunilor TCP, folosind mesajele: „Start-
Control-Connection-Request” și „Reply”.
După stabilirea conexiunii de control, PAC și PNS pot iniția sesiuni prin
solicitarea de apeluri de ieșire sau prin răspunderea la cereri de intrare.
Conexiunea de control înseși se menține prin mesaje ecou respective. Aceasta
asigură faptul, ca o cădere a conectivității între PNS și PAC va fi detectată în
timp util.
Pentru fiecare pereche de comunicare PNS-PAC, PPTP prevede stabilirea
unui tunel aparte. Tunelul este folosit pentru transportul pachetelor de date
PPP ale tuturor sesiunilor, ce implică perechea PNS-PAC dată. Căreia din
aceste sesiuni aparține un pachet concret, indică un câmp (cheie) din antetul
GRE al acestuia. Antetul GRE conține, de asemenea, informații necesare
pentru controlul congestiei tunelului și detectarea erorilor în date.
11.1.7. Tunele L2TP
Protocolul L2TPv2 (Layer 2 Tunneling Protocol, RFC 2661), propus în 1999 şi
dezvoltat în 2005 (L2TPv3, RFC 3931), oferă un mecanism dinamic de tunelare
a legăturilor de Nivel 2 OSI, în cadrul reţelelor de transfer date cu comutare de
pachete. Iniţial, L2TP realiza tunelarea sesiunilor PPP (Point-to-Point Protocol),
dar dezvoltările ulterioare ale lui permit tunelarea şi pentru alte protocoale de
Nivel 2.
L2TP este un protocol de tunelare pentru transportul de trafic IP folosind
PPP. El încapsulează PPP în linii virtuale peste IP, Frame Relay şi alte
protocoale/tehnologii. Totodată, L2TP poate incorpora PPP şi MPPE (Microsoft
Point to Point Encryption), pentru cifrarea legăturilor între nodurile terminale
ale tunelului via reţele de comutare pachete. Utilizatorul are o conexiune de
Nivel 2 la un concentrator de acces – LAC (de exemplu, multimodem, DSLAM
ADSL), care tunelează cadrele PPP către NAS (Network Access Server – Serverul
de acces la reţea). Aceasta permite separarea procesării pachetelor PPP de
terminaţiunea circuitului de Nivel 2 (L2). Din punctul de vedere al
utilizatorului, nu există nici o deosebire funcţională între terminarea circuitului
L2 direct în NAS sau folosind L2TP.
Ca şi PPTP, L2TP suportă MLPPP (Multilink PPP), pentru a realiza
transmiterea de pachete de 1500 octeţi şi mai mari (MRRU) şi, de asemenea,
pentru puntarea peste legături PPP (folosind protocolul BCP – Bridge Control
Protocol, care permite transmiterea de cadre Ethernet primare peste legături
PPP). Aceasta permite puntarea fără EoIP. În acest scop, deoarece legăturile
PPP nu folosesc adrese MAC, puntea va avea setată o adresă MAC sau va fi pe
o interfaţă Ethernet.
L2TP include autentificarea PPP şi evidenţa folosirii resurselor, pentru
fiecare conexiune L2TP, local sau printr-un client RADIUS.
403
Traficul L2TP foloseşte protocolul UDP, atât pentru pachete de date, cât şi
pentru pachete de control. L2TP foloseşte portul 1701 UDP doar pentru
stabilirea legăturii, traficul ulterior folosind orice port UDP disponibil, care
poate fi, dar poate şi să nu fie cel 1701. Astfel, L2TP poate fi folosit cu
majoritatea i-barierelor şi ruterelor, inclusiv cele cu NAT, permiţând rutarea
respectivă a traficului UDP.
Protocolul L2TP se foloseşte pentru crearea de reţele private virtuale
(Virtual Private Network – VPN) sau livrarea de servicii de către furnizorii de
servicii Internet.
L2TPv2 este dezvoltat în baza protocolului L2F (Layer 2 Forwarding
Protocol) al companiei Cisco, aprobat şi ca L2TPv1 (RFC 2341), şi a protocolului
PPTP (Point-to-Point Tunelling Protocol) al companiei USRobotics. L2TP constă
din protocolul de gestiune, pentru crearea, menţinerea şi desfiinţarea
sesiunilor L2TP, şi componenta de încapsulare a datelor L2TP pentru
multiplexarea/demultiplexarea fluxurilor de date între două noduri L2TP ale
unei reţele IP. Pentru fiecare din protocoalele (tehnologiile) de Nivel 2,
sesiunile cărora se tunelează folosind L2TP (de exemplu, PPP, Ethernet, Frame
Relay, etc.), sunt prevăzute module aparte de emulare respectivă. În
continuare se vor descrie, dacă nu este menţionat aparte, doar opţiunile ce ţin
de folosirea în acest scop a protocolului PPP.
Pentru transferul datelor, pachetele L2TP se încapsulează în datagrame
UDP, cu aplicarea, în cadrul tunelului L2TP, de sesiuni PPP. În scopul
securizării, L2TP foloseşte, de obicei, protocolul IPsec, îmbinarea în cauză a
două protocoale fiind cunoscută ca L2TP/IPsec.
Cele două capete (L2TP Control Connection Endpoints – LCCE) ale unui
tunel L2TP se numesc LAC (L2TP Access Concentrator) – iniţiatorul tunelului, şi
LNS (L2TP Network Server) – serverul de tunele L2TP. După formarea tunelului,
între cele două puncte terminale se asigură transferuri de date în ambele
direcţii, cu rularea în cadrul tunelului şi a protocoalelor de nivel superior. În
acest scop, pentru fiecare protocol de nivel superior, cum ar fi PPP, în cadrul
tunelului se formează o sesiune L2TP. Pentru fiecare sesiune L2TP, traficul de
date este izolat, astfel că în cadrul unui tunel pot fi formate mai multe reţele
virtuale. La formarea unui tunel L2TP, se ia în considerare şi valoarea MTU
aplicabilă.
Fiecare nod LCCE poate opera ca unul LAC sau ca unul LNS Mai mult ca
atât, unul şi acelaşi nod poate opera în regim LAC sau în regim LNS, în funcţie
de sesiune. Astfel, disting trei modele de tunelare de bază L2TP: LAC-LNS (sau
viceversa), LAC-LAC şi LNS-LNS (figura 11.3).
În modelul LAC-LNS (fig. 11.3a), sistemul distant iniţiază o conexiune PPP
cu un LAC printr-un circuit L2, de exemplu, PPP. La rândul său, LAC tunelează,
traversând Internetul (sau o reţea Frame Relay, ATM, etc.), conexiunea PPP
404
către LNS. De cealaltă parte, LNS încheie logic circuitul L2 şi înaintează traficul
de date respectiv către reţeaua A. Acţiunea de stabilire a conexiunii este
gestionată de LAC (ca un apel de intrare) sau de LNS (ca un apel de ieşire). De
menţionat că o staţie conectată la Internet şi care rulează L2TP (un client LAC)
poate de asemenea participa, fără folosirea vreunui LAC separat, la tunelarea
către o altă staţie.
Sistemul L2 IP Reţeaua
distant LAC LNS locală
Serviciul emulat
a)
Serviciul L2
Sistemul L2 IP L2 Sistemul
distant LAC LAC distant
Serviciul emulat
b)
Serviciul L2
Reţeaua IP Reţeaua
locală LNS LNS locală
Serviciul emulat
c)
Serviciul L2
Fig. 11.3. Schema modelelor de tunelare: a) LAC-LAC; B) LAC-LNS; c) LNS-LNS.

Conform modelului LAC-LAC (fig. 11.3b), fiecare nod LAC înaintează traficul
de date prin circuitul de la sistemul distant către nodul LAC pereche, folosind
L2TP, şi invers. Modelul este simetric: fiecare LAC poate iniţia o sesiune în
orice moment de timp.
În modelul LNS-LNS (fig. 11.3c), un eveniment de nivel utilizator, generat
de trafic sau semnalizat, gestionează, de obicei, stabilirea conexiunii din una
din cele două părţi ale tunelului. De exemplu, un tunel, generat de la un PC de
către utilizator sau automat de echipamentul clientului.
Un tunel L2TP poate fi realizat în cadrul unei întregi sesiuni PPP sau doar în
cadrul unui segment al unei sesiuni cu două segmente. O conexiune multe-salt
(multi-hop) L2TP este [18] un mod de redirecţionare a traficului L2TP din
partea LAC şi a clientului LNS. O conexiune multe-salt se formează, folosind o
poartă multe-salt L2TP ca şi nod intermediar. În acest scop, poarta multe-salt
L2TP se comportă atât ca un LNS pentru un set de LAC, cât şi ca un LAC pentru
un anumit LNS. Un tunel se stabileşte de la un LAC client la o poartă multi-hop
L2TP, iar apoi se stabileşte un alt tunel între poarta multi-hop L2TP şi un LNS
405
destinaţie. Traficul L2TP de la LAC client va fi apoi redirecţionat de poarta
multi-hop L2TP către LNS destinaţie, iar traficul de la LNS destinaţie va fi
redirecţionat către LAC client.
Printr-un tunel L2TP pot fi transmise atât mesaje de date, uneori denumite
şi pachete de date, cât şi mesaje de gestiune, uneori denumite şi pachete de
gestiune. Mesajele de gestiune servesc pentru stabilirea, menţinerea şi
desfiinţarea conexiunilor şi a sesiunilor. Pentru asemenea mesaje, în cadrul
L2TP se foloseşte un canal de gestiune fiabil.
Mesajele de date L2TP servesc pentru încapsularea traficului de date de
Nivel 2 realizat deasupra L2TP. Pentru asemenea mesaje, L2TP nu asigură
fiabilitatea necesară (mesajele pierdute nu se retransmit), funcţiile în cauză
revenind protocoalelor ce operează deasupra L2TP.
Relaţiile dintre mesajele de gestiune şi cele de date peste, respectiv,
gestiunea L2TP şi canalele de date sunt prezentate în figura 11.4.
Cadrul tunelat (Mesajul de date) Mesajul de gestiune L2TP

Antetul pentru date L2TP Antetul de gestiune L2TP
Canalul de date L2TP (nefiabil) Canalul de gestiune L2TP (fiabil)
Reţea cu comutare de pachete (IP, Frame Relay, MPLS, etc.)
Fig. 11.4. Structura L2TPv3 (RFC 3931).

Conform figurii 11.4, mesajele de date, încapsulate de un antet L2TP, sunt
transmise printr-un canal de date L2TP nefiabil, care traversează o reţea cu
comutare de pachete (în exemplu: IP, Frame Relay, MPLS, etc.). Mesajele de
gestiune sunt transmise printr-un canal de gestiune L2TP fiabil, care
traversează aceiaşi reţea cu comutare de pachete.
Tunelarea unei sesiuni L2TP constă din două etape:
1) stabilirea conexiunii de gestiune;
2) stabilirea unei sesiuni ca rezultat al unui apel de intrare sau al unuia de
ieşire.
O sesiune L2TP trebuie stabilită înainte ca L2TP să înceapă să înainteze
cadrele sesiunii. În cadrul unei conexiuni de gestiune pot fi stabilite mai multe
sesiuni, iar între două LCCE pot fi mai multe conexiuni de gestiune.
11.1.8. Tunele PPPoE
11.1.8.1. Esenţa PPPoE
Tunelul PPPoE (Point-to-Point Protocol over Ethernet), descris în RFC 2516
(1999), încapsulează cadre PPP în cadre Ethernet. Iniţial a fost elaborat pentru
controlul conexiunii la Internet a unor reţele locale mici de tip Ethernet.
406
Protocolul PPPoE este o extensie a celui PPP (vezi s. 1.4.5.2), utilizând
Ethernet în loc de o conexiune serială prin modeme. El este folosit pentru a
atribui adrese IP clienților, bazate pe autentificare prin nume de utilizator (şi,
dacă este necesar, prin staţie) spre deosebire de autentificarea doar prin
staţie, folosind doar adrese IP statice sau DHCP. Din considerente de
securitate, nu se recomandă de folosit adrese IP statice sau DHCP pe aceeaşi
interfaţă cu PPPoE.
Locul PPPoE în stiva de protocoale TCP/IP este prezentat în tabelul 11.2.
Tabelul 11.2. PPPoE în stiva de protocoale TCP/IP
Nivelul TCP/IP Protocoale, tehnologii
Aplicaţie Telnet, FTP, SMTP, HTTP, DNS, …
Transport TCP, UDP
Internet IP
PPP
Legătură PPPoE
Ethernet, ATM
PPPoE este un protocol client-server. Clientul şi serverul PPPoE operează
peste orice interfaţă de Nivel 2, inclusiv: fără fir 802.11, Ethernet, RadioLan, EoIP.
PPPoE se foloseşte îndeosebi de către furnizorii de servicii Internet (ISP)
pentru controlul conexiunilor (prin DSL, modeme pentru cabluri şi reţele
Ethernet) dispozitivelor terminale ale utilizatorilor la ruterele ISP şi colectarea
datelor statistice respective. Poate fi folosit şi în reţele locale Ethernet. PPPoE
oferă mijloace de autentificare a utilizatorilor şi de cifrare și compresie a
datelor.
Protocolul PPPoE este unul de Nivel 2 OSI, iar unii autori îl consideră de
Nivel 2,5 OSI, similar cu protocolul MPLS. El poate fi implementat în cadrul
unui ruter sau calculator aparte al utilizatorului, fiind suportat de majoritatea
sistemelor de operare, inclusiv Windows XP şi superioare, Linux, Mac OS X ş.a.
Funcţionarea PPPoE include două etape:
1) descoperirea PPPoE (PPPoE Discovery);
2) sesiunea PPPoE (PPPoE Session).
Conexiunile tradiționale ale PPP sunt stabilite între două puncte terminale
pe o legătură serială sau pe un circuit virtual ATM. PPPoE folosește, de
asemenea, doar conexiuni punct-la-punct.
Rețelele Ethernet însă sunt multiacces, în care fiecare nod poate accesa
orice alt nod al rețelei. Pentru a ajunge la o destinație anume, cadrul Ethernet
conține adresa MAC a acesteia. De aceea, mai întâi, la etapa de descoperire
PPPoE, între cele două noduri sursă și destinație se face schimb de pachete,
pentru ca ambele noduri comunicante să cunoască adresa MAC a celuilalt nod.
Ulterior, aceste adrese MAC sunt specificate în pachetele de control PPP,
407
transmise între cele două noduri pentru a stabili conexiunea PPP prin
Ethernet. De asemenea, la etapa PPPoE Discovery se stabilește sesiunea ID (ID
Session), în decursul căreia se poate efectua un nou schimb de pachete.
Etapa PPPoE Session servește pentru schimbul protejat de pachete între
cele două noduri ale tunelului PPPoE.
PPPoE se foloseşte larg de către furnizorii de servicii Internet din așa
considerente ca [4]:
 oferirea unei modalități scalabile de control a accesului la rețea. Deși este
un protocol de Nivel 2 OSI, el folosește adrese IP și rute implicite într-un
mod similar celui DHCP, ceea ce securizează, într-o oarecare măsură,
rețeaua;
 interacționează eficient cu serverul RADIUS (vezi s. 8.1.7.2);
 permite returnarea, de către serverul RADIUS, de multiple atribute,
inclusiv rata cozilor și atribuirea de adrese IP;
 gestiunea facilă, prin serverul RADIUS, a accesului utilizatorilor la rețea;
 conservarea spațiului IP, prin folosirea adresării punct-la-punct ș.a.
11.1.8.2. Adresarea punct-la-punct PPPoE
PPPoE foloseşte, în mod exclusiv, adresarea punct-la-punct. La folosirea
măştii de subreţea /31, pentru legături punct-la-punct, conform RFC 3061
ambele adrese disponibile se interpretează ca adrese de interfeţe (vezi s.
1.5.1.6). Totuşi, adresarea punct-la-punct folosită de PPPoE este una specifică,
Ethernet fiind o tehnologie multiacces.
Ideea adresării punct-la-punct la PPPoE se bazează pe folosirea
subreţelelor /32 (host routing – rutarea staţiei). Fiece subreţea /32 conţine o
singură adresă de interfaţă, deci fără alternative în transferul de date.
Exemplul 11.1. Adresarea punct-la-punct PPPoE. Fie este necesară
configurarea unei legături punct-la-punct între nodurile A şi B, folosind
subreţele /32.
Soluţia 1. În acest scop, nodului A i se atribuie, de exemplu, adresa IP
192.168.0.1/32 şi adresa de subreţea 192.168.0.2. Atunci, deoarece este vorba
despre o subreţea /32 (cu o singură adresă), nodului A îi este clar că nodul de
la celălalt capăt al legăturii punct-la-punct are adresa 192.168.0.2. Astfel,
nodul B are adresa IP 192.168.0.2/32, iar adresa de subreţea a lui trebuie să
fie 192.168.0.1.
Soluţia 2. În acest scop, nodului A i se atribuie, de exemplu, adresa IP
192.168.0.1/32 şi adresa de subreţea 195.12.3.2. Atunci nodului A îi este clar
că nodul de la celălalt capăt al legăturii punct-la-punct are adresa 195.12.3.2.
Astfel, nodul B are adresa IP 195.12.3.2/32, iar adresa de subreţea a lui trebuie
să fie 192.168.0.1.
408
Protocolul PPPoE este unul de tip client-server. De fiecare dată, când în
reţea apare un nou client PPPoE, serverul PPPoE creează o nouă interfaţă
dinamică, atribuindu-i clientului o nouă adresă IP de subreţea /32. Clientului
PPPoE i se poate atribui o adresă IP publică sau una privată, dar pentru toţi
clienţii se foloseşte aceeaşi poartă – adresa IP a serverului PPPoE într-o
subreţea /32. Pentru atribuirea de adrese IP clienţilor PPPoE, serverul PPPoE
foloseşte fonduri de adrese IP (IP Pools) – vezi s. 7.2.2.1.
Exemplul 11.2. Adresarea punct-la-punct server PPPoE – clienţi PPPoE. Fie
este necesară configurarea unei legături punct-la-punct între serverul PPPoE A
şi clienţii PPPoE B, C şi D, folosind subreţele /32.
Serverul A trebuie să aibă câte o legătură punct-la-punct cu fiecare din
clienţii PPPoE B, C şi D. Totodată, într-o reţea Ethernet, la nodul A, pentru
interconectarea lui cu celelalte trei noduri B, C şi D, este suficientă o singură
interfaţă. Astfel, în baza exemplului 11.1, adresa IP a serverului PPPoE trebuie
să fie combinată, pentru legătura cu fiecare din clienţii PPPoE B, C şi D, cu o
adresă de subrețea /32 aparte – în total trei, după numărul de clienţi.
Soluţia 1. Cele trei legături se configurează conform tabelului 11.3.
Tabelul 11.3. Soluţia 1 a configurării legăturilor la exemplul 11.2
Legătura Serverul PPPoE A Clientul PPPoE
P2P Adresa nod Adresa subreţea Adresa nod Adresa subreţea
A – B 192.168.0.1/32 192.168.0.2 192.168.0.2/32 192.168.0.1
A – C 192.168.0.1/32 192.168.0.3 192.168.0.3/32 192.168.0.1
A – D 192.168.0.1/32 192.168.0.4 192.168.0.4/32 192.168.0.1
Soluţia 2. Cele trei legături se configurează conform tabelului 11.4.
Tabelul 11.4. Soluţia 2 a configurării legăturilor la exemplul 11.2
Legătura Serverul PPPoE A Clientul PPPoE
P2P Adresa nod Adresa subreţea Adresa nod Adresa subreţea
A – B 192.168.0.1/32 172.16.51.4 172.16.51.4/32 192.168.0.1
A – C 192.168.0.1/32 192.168.0.5 192.168.0.5/32 192.168.0.1
A – D 192.168.0.1/32 172.16.1.14 172.16.1.14/32 192.168.0.1
Modalitatea descrisă de adresare punct-la-punct PPPoE permite reducerea
numărului de adrese IP necesare, comparativ cu folosirea subreţelelor /30.
11.1.9. Serviciul MLPPPoE
Serviciul MLPPPoE (Multilink PPPoE), disponibil în RouterOS, permite
agregarea mai multor clienţi PPPoE într-un singur trunchi. Pentru aceasta
trebuie ca atât ruterul PPPoE client, cât şi cel PPPoE server să suporte
funcţionalitatea MLPPP (vezi s 1.4.5.3). Aceasta permite creşterea vitezei de
transfer date. Astfel, dacă sunt disponibile 2 x 2 Mbps/6 Mbps conexiuni
409
Internet, atunci se va obţine o singură conexiune TCP de cca. 4 Mbps/12
Mbps.
11.1.10. Tunele şi reţele private virtuale IPsec
IPsec (Internet Protocol Security) este un set de protocoale de nivel
Internet, elaborat în 1994 şi ulterior dezvoltat (RFC 1825 (a. 1995), RFC 1829,
RFC 2401, RFC 2406, RFC 2412, RFC 4301, RFC 4303, RFC 4309), care serveşte
pentru securizarea comunicărilor IP. În acest scop, IPsec foloseşte
autentificarea şi cifrarea fiecărui pachet de date. El permite autentificarea
reciprocă a respondenţilor la începutul sesiunii de lucru şi, de asemenea,
negocierea cheilor criptografice de folosit în cadrul acesteia. Pentru a folosi
IPsec, nu se cer careva modificări speciale în cadrul aplicaţiei respective. IPsec
asigură protecţia traficului de date într-o reţea IP pentru orice aplicaţie.
IPsec este elaborat pentru IPv6 şi, opţional, pentru IPv4. Totuşi, din cauza
implementării reduse a IPv6, chiar şi în 2014 IPsec este mai mult folosit pentru
securizarea traficului IPv4.
Serviciile IPsec necesare sunt oferite prin selectarea adecvată a
protocoalelor de securitate, a algoritmilor criptografici şi a cheilor
criptografice. IPsec este de tip terminal-terminal, operează pe staţii şi poate fi
folosit pentru protecţia unuia sau a mai multor fluxuri de date între:
a) o pereche de staţii;
b) o pereche de porţi de securitate;
c) o poartă de securitate şi o staţie.
Poartă de securitate se numeşte un sistem intermediar care are
implementat IPsec, de exemplu o i-barieră (firewall) sau un ruter IPsec activat.
Pentru asigurarea serviciilor de securitate a traficului de date, IPsec
foloseşte două protocoale: Antetul de autentificare (Authentication Header –
AH) şi Încapsularea securizată a sarcinii utile (Encapsulating Security Payload –
ESP). Implementările IPsec trebuie să suporte ESP şi pot să suporte AH. Există
foarte puţine cazuri, când ESP nu poate, iar AH poate îndeplini funcţionalităţile
necesare de securitate. Atât AH, cât şi ESP oferă controlul accesului, fortificat
prin distribuirea cheilor criptografice şi gestiunea fluxurilor de trafic.
Ambele protocoale, AH şi ESP, pot fi folosite aparte sau împreună. Fiecare
din ele poate opera atât în modul Transport, cât şi în cel Tunel. În modul
Transport, AH şi ESP oferă protecţia în primul rând pentru protocoalele de
nivel superior, pe când în modul Tunel – pentru pachetele IP tunelate.
În modul Transport, doar sarcina utilă a pachetelor IP este, de obicei,
securizată. Nivelele Transport şi Aplicaţie întotdeauna sunt securizate prin
haşare, de aceea acestea nu pot fi nicicum modificate. Operaţiile ce ţin de
rutare rămân intacte, deoarece acestea necesită modificări în antetul IP. În
IPv4, antetul protocolului de securitate în modul Transport se regăseşte
410
imediat după antetul IP şi opţiuni, dar înainte de protocoalele de nivel superior
(TCP, UDP, etc.).
În modul Tunel, este securizat întregul pachet IP, acesta fiind încapsulat
într-un nou pachet IP, inclusiv un nou antet IP.
Pentru funcţionare, atât AH, cât şi ESP folosesc Asociaţii de securitate
(Security Associations – SA), descrise mai jos în această secţiune.
Antetul de autentificare (AH) asigură integritatea, autentificarea originii şi,
opţional, protecţia contra atacurilor de replicare a pachetelor IP. Integritatea
este proprietatea de a asigura transferul datelor de la sursă către destinaţie
fără alteraţii neobservate, iar atacurile de replicare se manifestă prin
repetarea sau întârzierea, cu rea intenție, a transmisiei de date valabile.
AH operează deasupra IP, folosind protocolul 51 (RFC 5237). El protejează
toate câmpurile pachetelor IPv4, cu excepţia câmpurilor antetului ce se
modifică pe parcursul transmisiei (DSCP/TOS, ECN, Flags - Fanioane, Fragment
Offset – Distanţă fragment, TTL şi Header Checksum – Suma de control a
antetului). În IPv6, AH nu protejează doar câmpurile antetului ce se modifică
pe parcursul transmisiei (DSCP, ECN, Flow Label – Etichetă flux şi Hop Limit –
Limită salturi).
Încapsularea securizată a sarcinii utile (ESP) Încapsularea sarcinii utile
asigură protecţia autenticităţii originii, integrităţii, confidenţialităţii şi,
opţional, protecţia contra atacurilor de replicare a pachetelor IP. Astfel, ESP,
pe lângă funcţionalităţile AH, asigură, suplimentar, şi confidenţialitatea. Prin
asigurarea confidenţialităţii se subînţelege că doar adresatul, nu şi o terţă
parte, poate să identifice conţinutul pachetului. ESP poate suporta, la
necesitate, doar funcţiile de cifrare sau doar de autentificare, deşi folosirea
cifrării fără autentificare nu este sigură.
ESP operează deasupra IP, folosind numărul de protocol 50. Spre deosebire
de AH, ESP în modul Transport nu asigură integritatea și autentificarea pentru
întregul pachet IP. Însă, în modul Tunel, în care întregul pachet IP iniţial este
încapsulat într-un pachet ESP, acesta asigură protecţia întregului pachet IP
intern, dar nu asigură o asemenea protecţie pentru antetul extern al
pachetului (opţiunile externe ale IPv4 sau antetele de extensie IPv6).
Asociaţia de securitate (SA) este o „conexiune” unidirecţională, care oferă
servicii de securitate pentru traficul respectiv de date. Ea este reprezentată de
un set de algoritmi și parametri, de exemplu chei, care se folosesc pentru
cifrarea şi autentificarea unui flux unidirecţional de date. În cazul de fluxuri
bidirecţionale, securizarea în cauză se efectuează de către o pereche de SA.
Serviciile de securitate sunt oferite unei SA prin folosirea AH sau ESP, dar nu a
ambelor protocoale împreună. Dacă pentru un flux de date se aplică ambele
protocoale AN şi ESP, atunci este necesară crearea a două SA.
411
Pentru IPsec, asociaţiile de securitate sunt stabilite prin folosirea
Protocolului Asociaţiilor de securitate şi gestiune a cheilor (Internet Security
Association and Key Management Protocol – ISAKMP). ISAKMP prevede
configurarea manuală de parametri de securitate pre-partajaţi, Schimbul
cheilor Internet (Internet Key Exchange – IKE), Negocierea cheilor prin Internet
Kerberizată (Kerberized Internet Negotiation of Keys – KINK, RFC 3129) şi
folosirea înregistrărilor DNS IPSECKEY sau folosirea unui protocol IKE extins
pentru un mod IPsec neautorizat, denumit Securitate mai bună decât nimic
(Better-Then-Nothing Securuty – BTNS, descris în RFC 5386).
IPsec foloseşte, în funcţie de implementare, aşa standarde, algoritmi şi
modele de securitate ca: Algoritmul DES, Algoritmul DES triplu, Modelul Diffie-
Hellman, Message Digest 5 (MD5), Algoritmul de haşare securizată (SHA-1),
Semnătura RSA (Rivest, Shamir şi Adleman), Internet Key Exchange (IKE),
Autorităţi de certificare ş.a. Implicit, pentru cifrare/descifrare, IPsec foloseşte
algoritmul DES cu chei de 56 biţi.
Diversele modalităţi de securizare, ce pot fi folosite cu IPsec, sunt
înregistrate în Baza de date a asociaţiei de securitate (Security Association
Database – SADB). Fiecare asemenea modalitate poate fi accesată şi aplicată
în baza „Indexului parametrilor de securitate” (SPI) respectiv, specificat în
antetul pachetului respectiv.
Pentru transferuri de date multiadresat, asociaţia de securitate este
definită pentru grupul respectiv de destinaţii. Totodată, pentru un grup pot fi
mai multe asociaţii de securitate cu diferite SPI, ceea ce permite aplicarea
diferenţiată a diverselor modalităţi de securitate diferitor membri ai grupului.
Modul Tunel de funcţionare a IPsec este modul implicit de folosire a IPsec.
În acest mod, întregul pachet original IP este protejat de IPsec. În acest scop,
IPsec împachetează pachetul original IP, îl cifrează, adaugă la acesta un nou
antet IP şi apoi îl transmite către celălalt capăt al tunelului IPsec. Pentru
securizare în modul Tunel, IPsec poate folosi ESP – IPsec(ESP), AH – IPsec(AH)
sau ambele facilităţi împreună. Totuşi, mai frecvent în acest scop se foloseşte
ESP.
Schema modului Tunel de funcţionare a protocolului ESP al IPsec este dată
în figura 11.5, iar cea a protocolului AH al IPsec – în figura 11.6.
În cadrul noului antet IP din figura 11.5, ESP este identificat cu numărul de
protocol Internet 50.
AH protejează întregul pachet original, dar nu şi toate câmpurile noului
antet IP, deoarece conţinutul unora din acestea se modifică la tranzitarea
nodurilor de reţea. AH protejează toate acele câmpuri ale noului antet IP, care
nu se modifică la tranzitarea nodurilor de reţea. În cadrul noului antet IP din
figura 11.6, AH este identificat cu numărul de protocol Internet 51.
412
Pachetul IP original
Antet Rulotă
Antet ESP Antet IP TCP/UDP Date Rulotă ESP
nou IP Autent ESP
Cifrat cu Antet ESP
Semnat de Rulotă Autent ESP

Fig. 11.5. Schema modului Tunel IPsec(ESP).
Modul Tunel al IPsec este folosit, de obicei, pentru securizarea
transferurilor de date între o pereche de porţi de reţea sau de la o staţie către
o poartă, în ultimul caz poarta operând ca un proxy pentru staţiile din aria lui.
Antet Antet
Antet IP TCP/UDP Date
nou IP Autentific
Semnat de Antet Autentific (AH)

Fig. 11.6. Schema modului Tunel IPsec(AH).
Modul Transport de funcţionare a IPsec serveşte pentru comunicări punct
terminal-punct terminal, protejând întregul pachet original IP. În acest scop,
IPsec împachetează pachetul original IP, îl cifrează, adaugă la acesta antetul
original IP şi apoi îl transmite către celălalt capăt al tunelului IPsec. Pentru
securizare în modul Transport, IPsec poate folosi ESP – IPsec(ESP), AH –
IPsec(AH) sau ambele facilităţi împreună. Totuşi, mai frecvent în acest scop se
foloseşte ESP.
Schema modului Transport de funcţionare a protocolului ESP al IPsec este
dată în figura 11.7, iar cea a protocolului AH al IPsec – în figura 11.8.
Antet Rulotă
Antet ESP Antet IP TCP/UDP Date Rulotă ESP
nou IP Autent ESP
Cifrat cu Antet ESP
Semnat de Rulotă Autent ESP

Fig. 11.7. Schema modului transport IPsec (ESP).
413
Spre deosebire de modul tunel, în modul transport în calitate de antet IP
nou se foloseşte o copie a celui IP original cu modificări minore, inclusiv
identificarea ESP în cadrul acestuia cu numărul de protocol Internet 50. Astfel,
noul antet IP nu este protejat.
Antet Antet
Antet IP TCP/UDP Date
nou IP Autentific
Semnat de Antet Autentific (AH)

Fig. 11.8. Schema modului transport IPsec (ESP).
Ca şi în cazul modului transport ESP, în modul transport AH în calitate de

antet IP nou se foloseşte o copie a celui IP original cu modificări minore,
inclusiv identificarea AH în cadrul acestuia cu numărul de protocol Internet 51.
Astfel, noul antet IP nu este protejat.
Modul Transport al IPsec este folosit, de obicei, pentru securizarea
transferurilor de date între două staţii, din care una este client, iar cealaltă
este server, sau între o stație şi o poartă, ultima fiind tratată ca o staţie-gazdă.
Ca exemplu ap putea servi o sesiune Telnet de la o staţie către un server.
11.1.11. Tunele SSTP
Protocolul SSTP (Secure Socket Tunneling Protocol – Protocolul de tunelare
a soclului securizat) este elaborat de compania Microsoft pentru transportul
cadrelor protocolului PPP pe o conexiune HTTPS (HTTP peste SSL) [20]. El
permite utilizatorilor accesarea unei reţele private folosind HTTPS. Folosirea
SSL peste portul TCP 443 dă posibilitatea SSTP să tranziteze i-barierele şi
serverele proxy.
Diverse servicii VPN oferă posibilitatea utilizatorilor mobili şi de la domiciliu
să acceseze la distanţă reţelele corporative folosind PPTP şi L2TP/IPsec. Însă
odată cu implementarea i-barierelor şi serverelor proxy, mulţi furnizori de
servicii Internet, de exemplu în hoteluri, nu permit traficul PPTP şi L2TP/IPsec.
De exemplu, la folosirea PPTP, o problemă majoră constă în blocarea, de către
ISP, a portului GRE.
SSTP oferă un tunel cifrat prin mijloacele protocolului SSL/TLS. Când un
client iniţiază stabilirea unei conexiuni VPN în baza SSTP, mai întâi se stabileşte
conexiunea TCP către serverul SSTP prin portul TCP 443 şi doar apoi cea a
tunelului SSTP. Mai detaliat, acţiunile în cauză se desfăşoară în ordinea:
 se stabileşte conexiunea către serverul SSTP via portul TCP 443;
 se efectuează validarea certificatului SSL/TLS;
414
 se încheie schimbul de mesaje cerere-răspuns HTTPS;
 încep negocierile SSTP;
 sunt iniţiate negocierile PPP şi se încheie sau se respinge autentificarea
PPP;
 se încheie negocierile SSTP;
 se încheie negocierile PPP;
 conexiunea este gata pentru transportarea de trafic de date, de exemplu
de pachete IP.
La client, încapsularea datelor are loc în ordinea:
 datele de nivel aplicaţie se încapsulează, folosind orice protocol de
transport, de exemplu TCP sau UDP;
 segmentele de nivel transport se încapsulează, folosind un protocol de
nivel reţea, de exemplu IP;
 pachetele de nivel reţea se încapsulează, folosind protocolul PPP;
 cadrele PPP se încapsulează folosind SSTP;
 pachetele SSTP se încapsulează folosind SSL/TLS;
 înregistrările SSL/TLS se încapsulează folosind TCP;
 segmentele TCP se încapsulează folosind IP;
 pachetele IP se transmit via orice protocol de Nivel 2, de exemplu
Ethernet sau PPP.
La server, decapsularea datelor are loc în ordinea inversă încapsulării lor.
Stiva de protocoale SSTP este prezentată în figura 11.9.
SSTP poate opera în două moduri de bază: PPP
1) serverul SSTP acceptă direct conexiunea HTTPS, fiind SSTP
similar unui server VPN marginal (edge). Certificatul
SSL/TLS este implementat pe serverul SSTP; HTTPS
2) serverul SSTP este poziționat în spatele unui balansor de TCP
sarcină SSL/TLS, care încheie conexiunile SSL/TLS (pe care,
Fig. 11.9.
respectiv, este instalat certificatul SSL/TLS) şi care Stiva SSTP.
înaintează traficul HTTP descifrat către serverul SSTP.
Trebuie să existe o relaţie implicită de încredere între balansorul de
sarcină SSL/TLS şi serverul SSTP (sau persoana intermediară).
SSTP se recomandă de folosit pentru conexiuni VPN via reţele publice de
transfer date. Clienţi SSTP există în aşa sisteme de operare ca Linux, Windows
Vista/7/8, RouterOS ş.a.
În RouterOS, conexiunea SSTP se stabileşte în ordinea:
 se stabileşte conexiunea de la clientul la serverul SSTP via portul TCP 443;
 SSL validează certificatul serverului. Dacă certificatul este valid, atunci se
stabileşte conexiunea; în caz contrar se respinge stabilirea conexiunii;
 clientul trimite pachete SSTP de control în cadrul unei sesiuni HTTPS, care
stabileşte maşina de stare STTP pe ambele noduri;
415
 au loc negocierile PPP via SSTP;
 tunelul SSTP este stabilit şi încapsularea de pachete poate începe.
Pentru instalarea unui tunel SSTP securizat, sunt necesare certificatele
respective. La server autentificarea se efectuează doar în baza numelui de
utilizator şi parolei, dar la client – serverul se autentifică folosind un certificat.
Acest certificat este folosit de client pentru interconectarea criptografică a
autentificării SSL şi PPP: clientul trimite o valoare specială către server via
conexiunea SSTP, valoare derivată din certificatul serverului şi datele cheii
generate pe parcursul autentificării PPP; aceasta permite verificarea de către
server dacă ambele canale sunt sigure.
Este posibil, de asemenea, de creat un tunel SSTP securizat prin adăugarea
unei autorizări suplimentare folosind un certificat al clientului.
Între două rutere RouterOS este posibil de configurat un tunel nesecurizat,
fără folosirea certificatelor.
11.1.12. Tunele OpenVPN
OpenVPN (Open Virtual Private Network – Reţea privată virtuală sursă
deschisă) este o aplicaţie cu sursă deschisă, care permite crearea de tunele
punct-la-punct sau punct-la-multiclient cu cifrarea puternică a datelor.
Tunelele pot traversa translatoarele NAT şi i-barierele. Aplicaţia este publicată
sub Licenţă generală publică GNU (GNU General Public License).
Open VPN permite perechilor de noduri să se autentifice reciproc, folosind
o cheie secretă prepartajată, bazată pe certificatul respectiv, sau numele de
utilizator şi parola. Mai facilă şi mai robustă este folosirea cheii secrete
prepartajate. În configurarea multiclient-server, aplicaţia permite generarea
unui certificat de autentificare pentru fiecare client, folosind semnătura şi
Autoritatea de certificare. Foloseşte biblioteca de cifrare OpenSSL şi protocolul
SSLv3/TLSv1 pentru schimbul de chei.
Pentru cifrarea datelor, OpenVPN foloseşte biblioteca OpenSSL. În scopul
creşterii performanţelor de cifrare, OpenVPN poate folosi accelerarea tehnică.
Începând cu versiunea 2.3, OpenVPN suportă PolarSSL.
OpenVPN poate rula peste UDP sau TCP, multiplexând tunelele SSL create
într-un singur port TCP/UDP cu numărul implicit 1194, oferit de IANA. Poate
opera via majoritatea serverelor proxy, inclusiv cel HTTP, via NAT şi i-bariere.
Poate crea atât tunele IP de Nivel 3 (TUN), cât şi tunele TAP Ethernet de Nivel
2, care pot transporta trafic Ethernet. OpenVPN poate folosi librăria LZO de
compresie a datelor.
Utilizarea protocoalelor TCP și UDP face din OpenVPN o alternativă de
dorit pentru IPsec, în situațiile în care un ISP ar putea bloca protocoale VPN
specifice, în scopul forțării utilizatorilor să se aboneze la servicii de preț mai
mare.
416
OpenVPN este suportat de multe sisteme de operare, inclusiv Linux, Mac
OS X şi Windows 2000/XP/Vista/7, Windows Mobile 6.5 şi superioare, iOS
3GS+, Android 4.0+ ş.a. Este suportat şi de RouterOS.
11.1.13. Reţele locale virtuale – VLAN
Reţea locală virtuală (Virtual local area network – VLAN) se numeşte o
subreţea a unei reţele locale, izolată logic de celelalte staţii ale LAN, formând
un domeniu de difuzare aparte (domeniu L2). În cadrul unei reţele locale
(reţea L2) pot fi formate două sau mai multe VLAN-uri, fiecare cu ID-ul propriu.
O staţie a unei VLAN anume nu poate comunica cu o staţie ce ţine de un alt
VLAN, chiar dacă aceste două staţii sunt conectate la acelaşi comutator.
Schimbul de date între staţiile unor VLAN diferite poate fi efectuat doar via
unul sau mai multe rutere.
Partiţionarea unei LAN în două sau mai multe VLAN-uri se efectuează în
cadrul unor comutatoare (switches) sau rutere. Echipamentele mai simple
suportă partiţionarea (dacă o suportă în general) doar la nivel de port, care
necesită folosirea de cabluri aparte pentru fiecare VLAN. Echipamentele mai
complexe suportă partiţionarea la nivel de interfaţă de reţea, care presupune
marcarea pachetelor astfel că o singură interconectare (trunchi – trunk) poate
fi folosită pentru transferul datelor mai multor VLAN-uri.
Dacă o VLAN se extinde peste mai mult de un comutator, legătura între
comutatoare devine „trunchi”, în cadrul căruia se transmit pachete marcate
(tagged), fiecare asemenea marcaj specificând VLAN-ul, de care acesta ţine.
Un trunchi transmite traficul mai multor VLAN-uri.
Gruparea staţiilor în VLAN-uri, în funcţie de destinaţia şi cerinţele de
funcţionare a acestora, facilitează considerabil crearea unor LAN-uri eficiente.
O reţea VLAN are aceleaşi atribute ca şi o reţea LAN, dar permite gruparea mai
facilă a staţiilor respective, chiar dacă acestea ţin de comutatoare diferite.
VLAN se configurează în cadrul i-programelor de reţea, fără a fi necesară
folosirea unor echipamente sau canale aparte.
VLAN-urile se folosesc pentru segmentarea serviciilor (producţie, VoIP,
reţele de stocare date – SAN, gestiune reţea ş.a.) în cadrul reţelelor locale,
acestea fiind realizate, în mod tradiţional, de către rutere. Crearea VLAN-urilor
poate fi impusă de cerinţe de securitate, scalabilitate şi gestiune a serviciilor
de reţea. Ruterele pot realiza, pentru VLAN-uri, filtrarea traficului de difuzare,
securizarea, agregarea de adrese şi gestiunea fluxurilor de date.
VLAN-urile pot fi, de asemenea, folosite pentru crearea de reţele L3
multiple pe unul şi acelaşi comutator L2. De exemplu, dacă un server DHCP
este conectat la un comutator, atunci el poate atribui adrese IP oricărei staţii
conectate la acest comutator. Folosind VLAN-urile, reţeaua poate fi divizată în
VLAN-uri astfel că unele staţii nu vor folosi serverul DHCP în cauză, ci vor
obţine adrese legături-locale sau vor obţine adrese IP de la un alt server DHCP.
417
Astfel, folosind VLAN-urile, pot fi construite atât subreţele una-la-una
VLAN – IP (o subreţea L2 – o subreţea L3), cât şi reţele una-la-multe VLAN – IP
(o subreţea L2 – multe subreţele L3).
În procesarea nor (cloud computing), VLAN-urile, adresele IP şi adresele
MAC reprezintă resurse ce pot fi gestionate de către utilizatorii finali. Din
motive de securitate, poate fi preferabilă plasarea maşinilor virtuale ale
norului în cadrul unor VLAN-uri, faţă de plasarea acestora direct în Internet.
Suportă implementarea VLAN-urilor aşa tehnologii de reţea ca: ATM
(Asynchronous Transfer Mode), FDDI (Fiber Distributed Data Interface),
Ethernet, Infiniband ş.a.
Principalul protocol, folosit la configurarea VLAN-urilor, este IEEE 802.1Q.
Numărul maxim de VLAN-uri într-o reţea Ethernet este 4094, iar cel de
subreţele IP nu este practic limitat. Se extinde această limită până la 16 mln, la
folosirea Puntării celei mai scurte căi (Shortest Path Bridging).
Protocolul IEEE 802.1Q defineşte cum de inserat identificatorul VLAN de
patru octeţi în antetul cadrului Ethernet (fig. 11.10).
Adresa MAC Adresa MAC
Preambula Tipul Date utile CRC/FCS
destinaţie sursă
Adresa MAC Adresa MAC Antetul 802.1Q CRC/FCS

Preambula sursă
Tipul Date utile
destinaţie (ID VLAN) recalculat
Fig. 11.10. Inserarea identificatorului VLAN (802.1Q) în cadrul Ethernet-II.
De menţionat că protocolul 802.1Q permite folosirea doar a unui singur
antet VLAN, pe când cel Q-in-Q – două sau mai multe antete VLAN. În
RouterOS, Q-in-Q poate fi configurat prin adăugarea unei interfeţe VLAN peste
o altă asemenea interfaţă.
11.1.14. Reţele locale virtuale private – VPLS
Serviciul de reţele locale virtuale private (Virtual Private Lan Service –
VPLS) este o tehnologie VPN, descrisă în RFC 4761 şi RFC 4762, şi destinată
creării de comunicări multipunct-la-multipunct pe baza Ethernet peste reţele
IP şi MPLS. VPLS permite unor staţii/LAN dispersate geografic să partajeze un
domeniu de difuzare Ethernet, interconectând staţiile prin pseudofire
(pseudo-wires – PW). Tehnologiile folosite pentru crearea pseudofirelor pot fi
Ethernet peste MPLS, L2TPv3 sau GRE. Totodată, spre deosebire de L2TPv3,
care permite crearea de tunele L2 punct-la-punct, VPLS permite conectivitatea
oricine-la-oricine (any-to-any) – multipunct-la-multipunct.
Într-o VPLS, fiecare reţea locală componentă este extinsă până la marginea
reţelei ISP, ultima emulând o punte VPLS şi interconectând toate reţelele LAN
ale clienţilor respectivi într-o singură reţea LAN puntată.
418
Deoarece VPLS emulează o reţea locală Ethernet, este necesară
posibilitatea interconectării, într-o topologie fiecare-cu-fiecare, a tuturor
reţelelor LAN componente. În acest scop poate fi folosit protocolul BGP sau cel
LDP (Label Distribution Protocol – Protocolul de distribuire a etichetelor).
Pentru auto-descoperire și semnalizare, ruterele marginale ale ISP (provider
edge – PE) comunică între ele via un "plan de gestiune" (control plane). Auto-
descoperirea serveşte pentru regăsirea tuturor PE ce ţin de aceeaşi VPLS, iar
semnalizarea – pentru stabilirea PW-urilor. Mulţimea de PW-uri constituie
„planul de date” (data plane) al VPLS.
La folosirea BGP, autodescoperirea şi semnalizarea se realizează în mod
ordinar. Fiecare ruter PE trebuie să fie configurat pentru a participa în reţeaua
VPLS dată. Ulterior, aceste rutere, folosind BGP, simultan descoperă toate
celelalte PE-uri ale VPLS şi stabilesc PW-urile între ele.
La folosirea LDP, fiecare ruter PE este configurat pentru a participa în
reţeaua VPLS dată şi, suplimentar, i se comunică adresele celorlalte PE-uri ale
VPLS. Apoi se stabilesc sesiunile LDP între toate PE-urile şi, în sfârşit, folosind
LDP ce creează PW-urile în PE-uri.
Un avantaj al folosirii PW-urilor constă în aceea că, în cazul de căderi,
traficul va fi în mod automat rutat pe căi de rezervă disponibile. Aceasta va fi
mult mai rapid, decât la folosirea Protocolului de acoperire a arborelui
(Spanning Tree Protocol – STP). De aceea VPLS este o soluţie mai fiabilă de
interconectare la distanţă a reţelelor Ethernet, comparativ cu conectarea
acestora la comutatoare de margine ale reţelei WAN a ISP.
Pachetele VPLS în baza MPLS folosesc două etichete. Cea externă este
folosită pentru înaintarea MPLS ordinară a pachetelor prin reţeaua ISP.
Eticheta internă, în cazul folosirii BGP, este alocată de către PE ca parte a
etichetei totale. În cazul folosirii LDP, eticheta internă este ID-ul circuitului
virtual, atribuit de către LDP la stabilirea topologiei fiecare-cu-fiecare între PE-
urile participante.
Pentru a reduce numărul de adrese MAC de gestionat între PE-uri, se poate
folosi adresa MAC a ruterului de margine pentru toate adresele MAC ale
subreţelei Ethernet respective, în mod similar cu folosirea NAT;
funcţionalitatea respectivă se numeşte MAT (MAC Address Translation).
VPLS are avantaje semnificative, atât pentru utilizatori, cât şi pentru ISP.
Ultimii pot beneficia de la oferirea unui nou serviciu Ethernet şi, de asemenea,
de la reducerea costurilor cu serviciile de transfer date. Utilizatorii pot
beneficia de posibilitatea interconectării, inclusiv la distanţă, a tuturor staţiilor
într-o reţea VPN Ethernet – reţea sigură, omogenă şi de viteză înaltă.
VPLS reprezintă o nouă treaptă în evoluţia Ethernet de la o tehnologie
pentru reţele locale de 10 Mbps la un serviciu global multi-Gbps. Se foloseşte,
419
de obicei, pentru interconectarea la distanţă a mai multor staţii şi reţele
locale.
11.1.15. Alegerea tipului de tunel
Tipul de tunel oportun de folosit depinde de fiecare caz concret în parte şi
selectarea lui poate să nu fie trivială. Dacă mijloacele de reţea sunt deja
instalate, atunci mai întâi se selectează submulţimea de tipuri de tunele
suportate de aceste mijloace. Ulterior, ţinând cont de cerinţele către tunelare
şi consultând proprietăţile diverselor tipuri de tunele, în baza analizei
comparative a acestora, se selectează tipul de tunel necesar.
La selectarea tipului de tunel, pot fi utile unele proprietăţi ale tunelelor,
prezentate în tabelul 11.1.
Tabelul 11.1. Unele proprietăţi ale tunelelor
Nume Protocol Nivelul Setarea Date Cifrarea Tip
Punte
tunel folosit OSI complexă? private? maximă comunicare
EoIP 2 Nu Nu - P2P MikroTi
47
k
GRE 47 3 Nu Nu - P2P -
IPIP 47 3 Nu Nu - P2P -
PPTP TCP 2/3 Nu Nu MPPE 128 P2P BCP
L2TP UDP 2/3 Nu Nu MPPE 128 P2P BCP
PPPoE 2 Nu Nu MPPE 128 P2P +
MLPPPoE 2 Nu Nu MPPE 128 P2P +
IPsec UDP 3 Da Da DES-AES256 P2P -
SSTP TCP 3 Nu Da AES CBC P2P -
VLAN 2 Nu Nu - PMP -
OpenVPN TCP, UDP 2/3 Da Da DES-AES256 PMP +
VPLS 2 Nu - - MPMP +
În tabelul 11.1, P2P semnifică comunicarea între două noduri – punct-la-
punct, P2MP – comunicarea punct-la-multipunct (multiclient), MP2MP –
comunicarea multipunct-la-multipunct (oricine-la-oricine).
La selectarea tipului de tunel, trebuie de ţinut cont că unele tunele pot
cifra traficul de date, ceea ce permite schimbul de date private. Pentru
reţelele de la domiciliu este suficientă, de obicei, cifrarea MPPE 128 [3]. Mai
sigură este cifrarea AES 256. În caz de necesitate, poate fi folosită încapsularea
traficului unui tunel sigur, de exemplu IPsec, în cadrul altuia mai puţin sigur, de
exemplu L2TP, oferind, în final, un transfer de date suficient de securizat.
Contează, de asemenea, şi protocolul folosit. De exemplu, protocolul TCP
este mai fiabil decât cel UDP, însă ultimul este mai rapid.
420
Unele tunele pot tranzita i-barierele şi serverele proxy (de exemplu, L2TP,
SSTP, Open VPN), iar altele nu.
Este important şi faptul că tunelele de Nivel 2 pot fi puntate, iar cele de
Nivel 3 – nu.
Pentru crearea de tunele staţie-ruter, deosebit de importantă este
suportarea, de către sistemul de operare folosit la staţie, a clientului-tunel. De
exemplu, sistemele de operare larg folosite Windows şi Linux suportă clienţi-
tunele PPPoE, PPTP, SSTP, OpenVPN ş.a.
11.2. Configurarea tunelelor în RouterOS

În RouterOS tunelele poate fi create în submeniul Interface al oricăruia din
meniurile /Interfaces şi /PPP. Totodată, pentru vizualizarea configurărilor
existente şi redefinirea unor tunele serveşte fereastra Interface List, iar pentru
altele – cea PPP. Astfel, în fereastra Interface List se pot vizualiza configurările
existente şi redefini tunelele: EoIP (fila EoIP Tunnel), IPIP (fila IP Tunnel), GRE
(fila GRE Tunnel), VLAN (fila VLAN) (fig. 11.11), iar în cea PPP – tunelele: PPPoE
(fila PPPoE Servers), PPTP (butonul PPTP Server), SSTP (butonul SSTP Server),
L2TP butonul L2TP Server) şi OpenVPN (butonul OVPN Server) (fig. 11.12).
Fig. 11.11. Fereastra Interface List de acces şi configuare a tunelelor.
Deoarece, la configurarea unor tunele, ca protocol de Nivel 2 între nodurile

terminale ale acestora se foloseşte cel PPP, mai întâi sunt descrie unele
configurări PPP în RouterOS (sistemul PPP (s. 11.3.1), crearea şi gestionarea
fondurilor de adrese IP (s. 11.3.2), configurarea profilurilor utilizatorilor – PPP
Profiles (s. 11.3.3), setarea conturilor partajate ale utilizatorilor – PPP Secrets
(s. 11.3.4) şi unele aspecte de configurare a conexiunilor PPP – PPP Server (s.
11.3.5) şi PPP Client (s. 11.3.6)), iar apoi şi configurarea de tunele în RouterOS
(ss. 11.4, 11.5).
Fig. 11.12. Fereastra PPP de acces şi configuare a tunelelor.
421
11.3. Configurări PPP în RouterOS
11.3.1. Sistemul PPP
RouterOS oferă un sistem amplu PPP Client/Server, care, de rând cu
funcţionalităţile de bază ale protocolului PPP (vezi s. 1.4.5.2), realizate de
Serverul PPP şi Clientul PPP, include şi funcţionalităţile unor aşa protocoale ca
PPPoE, PPTP, SSTP, L2TP şi OpenVPN (fig. 11.12). La configurarea
funcţionalităţilor tuturor acestor protocoale, se folosesc setările privind
conturile (PPP Secrets) şi profilurile (PPP Profiles) partajate ale utilizatorilor
sistemului PPP. Pot fi folosite, de asemenea, setările ce ţin de fondul comun
de adrese IP (IP Pools).
Conturile partajate ale utilizatorilor sistemului PPP se configurează în
cadrul casetei de dialog New PPP Secret al filei Secrets (/PPP/PPP/Secrets, +) –
vezi s. 11.3.4, profilurile utilizatorilor – în cadrul ferestrei New PPP Profile al
filei Profiles (/PPP/PPP/Profiles, +) – vezi s. 11.3.3, iar fondul de adrese IP – în
cadrul casetei de dialog New IP Pool (/IP/Pool/IP Pool/Pools, +/New IP Pool) –
vezi s. 11.3.3.
Fila Active Connections a ferestrei PPP (fig. 11.12) afişează starea
conexiunilor active pe întreg sistemul PPP.
Pentru autentificare, sistemul PPP foloseşte, în funcţie de protocol şi
serviciu, patru algoritmi:
 PAP – Password Authentication Protocol (Protocol de autentificare prin
parolă). Transmite parolele ASCII necifrate şi de aceea se consideră
nesigur;
 CHAP – Challenge-Handshake Authentication Protocol (Protocol
interactiv de autentificare, descris în RFC 1994). Autentificarea se
efectuează în trei paşi, prin schimbul de informaţii anume între cele două
părţi – client şi server, inclusiv cu cifrare, şi cunoaşterea de către client şi
server a unui text secret comun. Este mai sigur decât cel PAP şi cele
MSCHAP1 şi MSCHAP2;
 MS-CHAPv1 – Microsoft CHAPv1, descris în RFC 2433, este o versiune
Microsoft a protocolului CHAP. Începând cu Windows Vista, MS-CHAPv1
nu mai este suportat;
 MS-CHAPv2 – versiunea a 2-a a MS-CHAP, descrisă în RFC 2759.
Atât MS-CHAPv1, cât şi MS-CHAPv2 sunt mai simple – nu necesită
cunoaşterea de către client şi server a unui text secret comun, dar sunt mai
puţin sigure decât CHAP.
11.3.2. Configurarea fondului de adrese IP – IP Pool
Fondul comun de adrese IP (IP pool) este o mulţime de adrese IP, ce pot fi
alocate în mod automat clienţilor de către serverele DHCP şi PPP. Acesta este
422
unicul fond pentru toate funcţionalităţile RouterOS ce ţin de atribuirea de
adrese IP clienţilor DHCP, PPP şi HotSpot. Când este posibil, aceeaşi adresă IP
se atribuie mai multor clienţi.
Fondul comun de adrese IP disponibile la ruter poate fi vizualizat acţionând
/IP/Pool/IP Pool/Pools. În fila Pools, acesta este reprezentat de înregistrări.
Fiecare asemenea înregistrare reprezintă un fond IP (IP Pool) aparte şi conţine
numele (Name) fondului, unul sau mai multe diapazoane neîntrerupte de
adrese IP (Addresses), separate prin virgulă, şi numele fondului următor (Next
Pool). Un diapazon de adrese se specifică prin prima adresă IP, urmată de
defis, şi ultima adresă a diapazonului. Fond următor este fondul comun de
adrese IP, din cadrul căruia se atribuie adrese IP clienţilor, în cazurile că în
fondul curent adrese neatribuite deja nu mai există.
Exemplul 11.3. Configurarea unui fond de adrese IP. Fie se cere de definit
fondul poolPPP ce ar conţine diapazoanele de adrese IP: 192.168.22.3-
192.168.22.10, 192.168.22.20-192.168.22.24 şi fondul următor default-dhcp.
În acest scop se acţionează: /IP/Pool/IP
Pool/Pools, +/New IP Pool, Name – poolPPP,
Addresses – 192.168.22.3-192.168.22.10, ,
192.168.22.20-192.168.22.24, Next Pool –
default-dhcp/OK (fig. 11.13).
Caracteristicile fondului de adrese IP creat
Fig. 11.13. Setarea IP Pool.
apar în înregistrarea respectivă din fila Pools.
Orice fond de adrese IP din fila Pools poate fi, la necesitate, modificat. Pentru
aceasta, se execută dublu clic pe înregistrarea ce reprezintă fondul respectiv
şi, în caseta de dialog IP Pool <nume_fond> ce se va afişa (similară celei din fig.
11.13, deosebirea fiind doar în titlu), se vor efectua modificările necesare.
Adresele în folosinţă (deja alocate) ale fondului de adrese IP pot fi
vizualizate în fila Used Addresses (/IP/Pool/Used Addresses).
Sarcină practică 11.1. Configurarea de fonduri de adrese IP. De
experimentat crearea de fonduri comune de adrese IP conform exemplului
11.3. De verificat apariţia caracteristicilor fondurilor de adrese IP create ca
înregistrări în fila Pools.
11.3.3. Configurarea PPP Profiles
Modulul PPP Profiles serveşte pentru definirea configurărilor de acces la
sistemul PPP, inclusiv PPPoE, PPTP şi L2TP. Este o modalitate de a atribui
aceleaşi configurări mai multor clienţi. Implicit, RouterOS oferă două profiluri:
default – fără cifrare şi default-encryption – cu cifrare; aceste profiluri nu pot fi
eliminate. Utilizatorul poate doar adăuga noi profiluri PPP.
De menţionat, totuşi, că setările definite în PPP User Database (/PPP/
PPP/Secrets) au prioritate, substituindu-le pe cele similare din PPP Profiles
423
(/PPP/PPP/Profiles); excepţie este prioritatea adreselor IP unice faţă de
fondurile comune de adrese IP.
PPP Profile include aşa parametri ca (vezi fig. 11.14):
 Name – numele profilului;
 Local Address – adresa IP a interfeţei
locale a tunelului sau numele fondului de
adrese IP, din care se atribuie adresă IP
interfeţei PPP locale (serverului PPP);
 Remote Address – adresa IP a interfeţei
distante a tunelului sau numele fondului
de adrese IP, din care se atribuie adresă IP
interfeţei PPP distante (clientului PPP);
 Bridge – numele interfeţei punţii, la care
se va ataşa interfaţa PPP ca port slave;
 Incoming Filter – numele lanţului i-
barierei, pentru pachetele de intrare PPP,
gestionate conform regulilor respective;
 Outgoing Filter – numele lanţului i-
barierei, pentru pachetele de ieşire PPP,
gestionate conform regulilor respective;
 Address List – numele Listei de adrese, în
care se vor înregistra adresele IP atribuite
Fig. 11.14. Setarea PPP Profile.
de PPP;
 DNS Server – adresa IP a serverului DNS pentru clienţii PPP;
 WINS Server – adresa IP a serverului WINS de furnizat clienţilor Windows;
 Change TCP MSS – modificarea setărilor MSS (Maximum Segment Size –
Dimensiunea maximă a segmentului): yes – de ajustat valoarea
conexiunii MSS; no – de nu ajustat valoarea conexiunii MSS; default – de
preluat valoarea conexiunii MSS de la profilul implicit al interfeţei, dacă
ultimul nu este setat special, atunci corespunde celui no.
Exemplul 11.4. Configurarea PPP Profile. Fie se cere de configurat PPP
Profile între două rutere la următoarele date iniţiale: numele profilului –
profilPPP1; adresa nodului terminal local al serverului PPP (tunelului) –
10.0.0.5; pentru clienţii PPP adrese IP se vor aloca din fondul de adrese
poolPPP creat în exemplul 11.3; de ajustat valoarea conexiunii MSS; ceilalţi
parametri – valorile implicite ale RouterOS.
În acest scop se acţionează: /PPP/PPP/Profiles, +/New PPP Profile/
General, Name – profilPPP1, Local Address – 10.0.0.5; Remote Address –
poolPPP, Change TCP MSS – bifare yes/OK (fig. 11.14).
Înregistrarea privind profilul profilPPP1 creat va apare în fila Profiles.
424
Sarcină practică 11.2. Configurarea PPP Profile. Se cere de configurat PPP
Profile la ruter, ţinând cont de următoarele date iniţiale: numele profilului –
profilPPP1; adresa nodului terminal local al serverului PPP (tunelului) –
192.168.1.x; pentru clienţii PPP adrese IP se vor aloca din fondul de adrese
poolPPP creat conform sarcinii practice 11.1 din s. 11.3.2; de ajustat valoarea
conexiunii MSS; ceilalţi parametri – valorile implicite ale RouterOS.
De verificat apariţia înregistrării privind profilul profilPPP1 creat în fila
Profiles.
11.3.4. Configurarea PPP Secrets
Modulul PPP Secrets (Secrete PPP) serveşte pentru configurarea conturilor
partajate ale utilizatorilor sistemului PPP. Aceste conturi au destinaţie locală –
sistemul PPP, şi includ aşa parametri ca: numele contului, parola, profilul,
serviciul de utilizat, adresa IP de la care poate fi accesat ş.a. Unii parametri de
configurare se preiau din profilul (Profile) de utilizator.
Autentificarea locală se efectuează folosind Baza de date a utilizatorilor
(User Database) şi Baza de date a profilurilor (Profile Database). Înregistrările
din User Database au prioritate faţă de cele din Profile Database, excepţie
fiind prioritatea adreselor IP unice faţă de fondurile comune de adrese IP.
PPP Secret include aşa parametri ca (fig. 11.15):
 Name – numele contului pentru
autentificare;
 Password – parola pentru
autentificare;
 Service – serviciul permis utilizatorului
pentru folosire;
 Caller ID – pentru PPTP şi L2TP este
adresa IP, de la care trebuie să se
conecteze clientul. Pentru PPoE este
adresa MAC, de la care trebuie să se
conecteze clientul. Pentru ISDN este
numărul apelantului, de la care trebuie
să se adreseze clientul; Fig. 11.15. Setarea PPP Secret.
 Profile – numele profilului de utilizator de folosit;
 Local Address – adresa IP ce se va atribui interfeţei PPP locale (serverului
PPP);
 Remote Address – adresa IP ce se va atribui interfeţei PPP distante
(clientului PPP);
 Routes – rutele ce apar pe server când clientul este conectat. Parametrul
este ignorat de OpenVPN;
 Limit Bytes In – numărul maxim de octeţi ce pot fi transmişi de client
într-o sesiune;
425
 Limit Bytes Out – numărul maxim de octeţi ce pot fi descărcaţi de client
într-o sesiune.
Exemplul 11.5. Configurarea PPP Secret. Fie se cere de configurat PPP
Secret, la următoarele date iniţiale: numele contului – accesPPPoE; parola –
testIntranet; serviciul – PPPoE; profilul – default-encryption. În acest scop se
acţionează: /PPP/PPP/Secrets, +/New PPP Secret, Name – accesPPPoE,
Password – testIntranet; Service – pppoe; Profile – default-encryption/OK
(fig. 11.15).
11.3.5. Configurarea serverului PPP
Pentru crearea de conexiuni PPP, servesc Serverul PPP (PPP Server) şi
Clientul PPP (PPP Client). Aceştia se folosesc, de obicei, pentru stabilirea unei
conexiuni PPP prin modeme.
Pentru crearea unui server PPP pe un
ruter ce are un singur port serial sau USB
– serial0, trebuie, mai întâi, de identificat
folosirea implicită a acestuia; de obicei
acesta se foloseşte pentru consolă. În
acest scop se acţionează Fig. 11.16. Folosirea portului serial0.
Sniffer.
/System/Ports/Port List/Ports (fig. 11.16).
În cazul din fig. 11.16, portul serial0 este folosit de consolă (Serial Console,
în coloana Used By). Pentru a dezactiva folosirea portului serial0 de către
consolă, se acţionează:
/System/Console/Console, clic pe înregistrarea
serial0, clic x. Va rezulta dispariţia notării Serial
Console în coloana Used By, ceea ce înseamnă
că portul serial0 este liber şi poate fi folosit
pentru o conexiune PPP.
Acum se poate crea, pe portul serial0, un
server PPP. În acest scop se acţionează:
/Interfaces/ Interface List/Interface, +/PPP
Server/New Interface/General, Port – serial0,
Modem Init – ATZ/OK (fig. 11.17). Pentru
parametrul Modem Init (secvenţa de iniţializare
a modemului), se poate întâmpla să fie nevoie
nu de valoarea ATZ, ci de cea ATA0 – trebuie de
consultat documentaţia modemului respectiv. Fig.11.17. Setarea PPP Server.
11.3.6. Configurarea clientului PPP

După cum a fost menţionat în s. 11.3.5, Clientul PPP şi Serverul PPP se
folosesc, de obicei, pentru stabilirea unei conexiuni PPP prin modeme. Clientul
426
PPP se foloseşte pentru apelarea de conexiuni prin portul serial sau USB al
dispozitivului client.
Clientul PPP foloseşte aşa parametri ca:
 Name – numele interfeţei;
 Type – tipul nodului terminal al conexiunii PPP (PPP Client sau PPP
Server);
 Port – portul serial sau USB, la care este conectat modemul;
 APN – numele punctului de acces (AP) al furnizorului de servicii (SP);
 PIN – codul PIN al cartelei SIM;
 User, Password – numele utilizatorului şi parola, folosite pentru autentificare;
 Remote Address – adresa IP a punctului de acces (AP) al furnizorului de
servicii ş.a.
Pentru a seta clientul PPP, la fel ca şi în cazul configurării serverului PPP
(vezi s. 11.3.5), trebuie, mai întâi, de eliberat portul serial respectiv. Ulterior,
se acţionează: /Interfaces/Interface List/Interface, +/PPP Client/New Interface.
Apoi, în filele General şi Port, se specifică valorile necesare ale parametrilor
descrişi mai sus în această secţiune.
11.3.7. Starea conexiunilor PPP
Starea conexiunilor PPP active, inclusiv a celor prin tunele (PPPoE, PPTP,
L2TP, SSTP şi OpenVPN), pot fi vizualizate, acţionând: /PPP/PPP/Active
Connections (fig. 11.18).
Fig. 11.18. Conexiunile PPP active.

Conform figurii 11.18, la ruter este o singură conexiune PPP activă şi
anume una PPPoE.
11.4. Tunelarea în reţele locale şi de acces la ISP

Pentru crearea de tunele în reţele Ethernet şi, de asemenea, cele de acces
la furnizori de servicii Internet, RouterOS realizează protocoalele PPPoE şi
MLPPPoE. În secţiune sunt descrise unele funcţionalităţi şi aspecte de
configurare a PPPoE.
11.4.1. Funcţionalităţi PPPoE RouterOS
În RouterOS, PPPoE operează conform RFC 2516 şi dispune de aşa
funcţionalităţi ca:
427
 suportul serverului şi a clientului PPPoE;
 suportul PPP multilegătură (MLPPP);
 suportul MLPP pe o singură legătură;
 suportul protocolului BCP (Bridge Control Protocol), care permite
transmiterea de cadre Ethernet pe legături PPP;
 cifrarea MPPE de 40 biţi şi cea MPPE de 128 biţi;
 autentificarea pap, chap, mschap1 şi mschap2;
 suportul de servere RADIUS pentru autentificare şi evidenţa folosirii
serviciilor de către clienţi.
Pentru crearea de tunele PPPoE, RouterOS foloseşte clienţi PPPoE şi
servere PPPoE. PPoE RouterOS suportă următoarele tipuri de conexiuni:
 clientul PPoE RouterOS către orice server PPPoE (concentrator de acces);
 serverul PPoE RouterOS (concentratorul de acces) către mai mulţi clienţi
PPPoE – până la 65535 de conexiuni.
11.4.2. Configurarea PPPoE Client
Pentru configurare, PPPoE Client foloseşte aşa parametri ca:
 Name – numele descriptiv al interfeţei PPPoE. Dacă nu este specificată,
se generează de RouterOS. În figura 11.19, acesta este pppoe-out1;
 Max MTU – lungimea maximă a unităţii de date de transmis, octeţi;
 Max MRU – lungimea maximă a unităţii de date de recepţionat, octeţi;
 MRRU – dimensiunea maximă a unui pachet ce poate fi recepţionat pe
legătură. Dacă aceasta depăşeşte valoarea Max MTU/Max MRU, atunci
pachetul este divizat în mai multe unităţi de date;
 Interfaces – interfeţele pe care va rula PPPoE Client;
 Service – numele serviciului stabilit de concentratorul de acces. Câmpul
respectiv poate fi păstrat vid, atunci clientul se va conecta la orice
concentrator de acces al domeniului de difuzare;
 AC Name – numele concentratorului de acces. Câmpul respectiv poate fi
păstrat vid, atunci clientul se va conecta la orice concentrator de acces al
domeniului de difuzare;
 User, Password – numele de utilizator şi parola folosite pentru autentificare;
 Profile – profilul implicit al conexiunii, definit în PPP Profiles;
 Dial On Demand – de conectat la serverul tunelului doar la generarea de
trafic de ieşire;
 Add Default Route – de adăugat adresa IP a celuilalt nod al tunelului ca
rută implicită;
 Use Peer DNS – de obţinut setările DNS de la serverul tunelului;
 Allow – metodele de autentificare permise;
 Local Address – adresa IP alocată clientului;
 Remote Address – adresa IP alocată serverului (de exemplu, adresa IP a
porţii) ş.a.
428
Fig. 11.19. Configurarea PPPoE Client.
Pentru configurarea PPPoE Client, se acţionează: /Interfaces/Interface
List/Interface, /PPPoE Client/New Interface/General, Interfaces - interfaţa
pe care va rula PPPoE Client (de exemplu, wlan1)/Dial Out, User –
nume_utilizator (de exemplu class1), Password – parola/OK. La necesitate,
pot fi specificaţi şi alţi parametri (fig. 11.19).
Sarcină practică 11.3. Configurarea PPPoE Client. De configurat PPPoE
Client, considerând că deja este configurat PPPoE Server pe un ruter în
domeniul de difuzare al ruterului utilizatorului, la următoarele date iniţiale:
Interfaces wlan1, User – class, Password – class.
În acest scop:
1. De restabilit configurarea lucrătoare respectivă a RouterOS: /Files/File List,
clic nume_fişier, clic butonul Restore.
2. De dezactivat clientul DHCP pe interfaţa wlan1: /IP/DHCP Client/DHCP
Client, clic înregistrarea wlan1, x.
3. De configurat PPPoE Client: /PPP/PPP/Interface, /PPPoE Client/New
Interface/General, Interfaces – wlan1)/Dial Out, User – class, Password –
class/OK.
4. De verificat conexiunea PPPoE, folosind ping.
5. De dezactivat clientul PPPoE: /PPP/PPP/Interface, clic pe înregistrarea
pppoe-out1, x.
6. De activat clientul DHCP pe interfaţa wlan1: /IP/DHCP Client/DHCP Client,
clic pe înregistrarea wlan1, √.
11.4.3. Configurarea PPoE Server
Pe fiecare interfaţă, PPPoE Server (Access Concentrator) suportă mai multe
servere, fiecare din care cu numele de serviciu PPPoE propriu. În calitate de
429
nume de concentrator de acces, PPPoE Server foloseşte identitatea ruterului.
În scopuri de securitate, nu se recomandă de atribuit o adresă IP interfeţei pe
care rulează PPPoE Server.
Pentru configurare, PPPoE Server foloseşte aşa parametri ca:
 Service Name – numele serviciului PPPoE. Serverul va accepta doar
clienţii cu acest nume de serviciu şi cei care nu au setat numele de
serviciu;
 Interface – interfaţa la care sunt conectaţi clienţii;
 Max MTU, Max MRU, MRRU – ca şi la PPPoE Client;
 Default Profile – ca şi Profile la PPPoE Client;
 Keepalive Timeout – defineşte perioada fără trafic din partea clientului,
după expirarea căreia ruterul începe transmiterea periodică de pachete
speciale (keepalive). Dacă o următoare (a doua) perioadă de durată
Keepalive Timeout este fără trafic şi fără răspuns, din partea clientului, la
pachetele keepalive, atunci ruterul
deconectează clientul. Valoarea
implicită a parametrului este 10 s;
dacă valoarea acestuia este 0 s, atunci
clientul nu va fi deconectat după acest
parametru;
 One Session Per Host – permite doar o
singură sesiune per staţie (identificată
după adresa MAC);
 Max Sessions – numărul maxim de
clienţi, pe care îi poate servi
concentratorul de acces. Dacă
valoarea parametrului este 0, atunci
acest număr nu este limitat ş.a.
Pentru configurarea PPPoE Server, se Fig. 11.20. Setarea PPPoE Server.
acţionează: /PPP/PPP/PPPoE Servers, +/
New PPPoE Service, Service Name – nume_serviciu (în fig. 11.20 – service1),
Interface – nume_interfaţă pe care va rula PPPoE Client (în fig. 11.20 –
wlan1)/OK. La necesitate, pot fi specificaţi şi alţi parametri.
Sarcină practică 11.4. Configurarea PPPoE Server. De configurat PPPoE
Server, la următoarele date iniţiale: Service Name – service1, Interface –
wlan1, One Session Per Host – bifat.
430
11.5. Comunicarea securizată între reţele la
distanţă
Pentru comunicarea securizată în reţele WAN, se pot folosi diverse
mijloace, o parte din care sunt nominalizate în s. 11.1. În această secţiune sunt
descrise unele funcţionalităţi şi aspecte de configurare a tunelelor PPTP şi
L2TP între reţele ce comunică la distanţă via Internet.
11.5.1. Configurarea tunelelor PPTP
11.5.1.1. Funcţionalităţi PPTP RouterOS
În RouterOS, PPTP dispune de aşa funcţionalităţi ca:
 suportul serverului şi a clientului PPTP;
 suportul PPP multilegătură (MLPPP);
 suportul protocolului BCP (Bridge Control Protocol), care permite
transmiterea de cadre Ethernet pe legături PPP;
 cifrarea RC4 MPPE de 40 biţi şi cea RC4 MPPE de 128 biţi;
 autentificarea pap, chap, mschap1 şi mschap2;
 suportul de servere RADIUS pentru autentificare şi evidenţa folosirii
serviciilor de către clienţi.
Pentru crearea de tunele PPTP, RouterOS foloseşte clienţi PPTP şi servere
PPTP. PPTP RouterOS suportă următoarele tipuri de conexiuni:
 clientul PPTP RouterOS către orice server PPTP (concentrator de acces);
 serverul PPTP RouterOS (concentratorul de acces) către mai mulţi clienţi
PPTP.
El poate fi implementat în cadrul unui ruter sau calculator aparte al
utilizatorului, fiind suportat de majoritatea sistemelor de operare, inclusiv
Windows XP şi superioare, Linux, Mac OS X ş.a.
De rând cu folosirea pentru comunicarea între reţele la distanţă via
Internet, PPTP poate fi folosit şi pentru accesul clienților mobili sau îndepărtați
la resursele rețelelor locale.
Un exemplu de tunel PPTP este prezentat în figura 11.21.
11.5.1.2. Configurarea PPTP Client
Pentru configurare, PPTP Client foloseşte aşa parametri ca:
 Name – numele descriptiv al interfeţei PPTP. Dacă nu este specificat, se
generează de RouterOS. În figura 11.22, acesta este pptp-out1;
431
Tunel securizat
Fig. 11.21. Schema unui tunel PPTP.

 Max MTU, Max MRU, MRRU, User, Password, Profile, Dial on Demand,
Add Default Route, Allow Local Address şi Remote Address – ca şi la
PPPoE Client (vezi s. 11.4.2).
Exemplul 11.6. Configurarea PPTP Client este similară celei PPPoE Client.
În acest scop, se acţionează: /Interfaces/Interface List/Interface, /PPTP
Client/New Interface/Dial Out, Connect To –
adresa_IP_PPTP_Server (în fig. 11.22 –
192.44.17.1), User – nume_utilizator,
Password – parola, Add Default Route –
bifare/OK. La necesitate, pot fi specificaţi şi
alţi parametri (fig. 11.22). De menţionat că
afişarea ferestrei New Interface de configurare
a PPTP Client poate fi efectuată şi acţionând
/PPP/PPP/ Interface, /PPTP Client/New
Interface.
Bifarea parametrului Add Default Route va
direcţiona, prin tunelul creat, tot traficul, ce Fig. 11.22. Setarea PPTP Client.
nu are specificată explicit o altă rută.
Dacă este necesar de transmis trafic specific prin acest tunel PPTP, atunci
pentru asemenea trafic se vor crea rute statice (vezi s. 10.5). În acest scop, se
acţionează: /IP/Routes/Routes, +/New Route, Type – tipul_de_trafic/OK.
Sarcină practică 11.5. Configurarea PPTP Client. De configurat PPTP Client
pe ruterul utilizatorului, considerând că PPTP Server este deja configurat, la
următoarele date iniţiale: Connect To – adresa_IP_PPTP_Server (se va
comunica suplimentar); User – class; Password – class; Add Default Route –
bifare.
În acest scop:
432
1. De configurat PPTP Client conform exemplului 11.6, dar la datele iniţiale ale
sarcinii practice.
2. De verificat conexiunea prin tunel, folosind ping.
3. De creat o rută statică, pentru transmiterea de trafic specific prin tunelul
PPTP.
11.5.1.3. Configurarea şi lansarea PPTP Server
Pentru fiecare tunel către un server PPTP, pe server este creată o interfaţă
aparte. Există două tipuri de interfeţe de servere PPTP:
 interfeţe statice – interfeţe ce se adaugă în mod administrativ, dacă este
nevoie de referit un nume de interfaţă anume (de exemplu, în reguli de i-
bariere) creată pentru un anumit utilizator;
 interfeţe dinamice – interfeţe ce se adaugă în mod automat, de fiecare
dată când se conectează un utilizator, numele căruia lipseşte în lista de
intrări statice existente sau o asemenea intrare este deja activă. O
asemenea interfaţă este eliminată imediat după ce utilizatorul se
deconectează.
Astfel, dacă în configurarea ruterului este nevoie de referit un tunel PPTP
anume, atunci este necesar de folosit pentru acesta o interfață statică.
Pentru configurare, PPTP Client foloseşte aşa parametri ca (fig. 11.23):
 Enabled – activarea/dezactivarea PPTP Server;
 Max MTU, Max MRU, MRRU, Keepalive Timeout, Default Profile şi
Autentication – ca şi la PPPoE Server
(vezi s. 11.4.3).
Pentru configurarea PPTP Server, se
acţionează: /PPP/PPP/Interface, PPTP
Server/PPTP Server, Enabled – bifare, Default
Profile – profilul_implicit_necesar/OK. La
necesitate, pot fi specificaţi şi alţi parametri
(vezi fig. 11.23).
Serverul PPTP creat va accepta conexiuni
de intrare şi va atribui clienţilor PPTP adrese
Fig. 11.23. Activarea PPTP Server.
IP conform profilului specificat.
11.5.1.4. Definirea de rute pentru tunele PPTP
Dacă tunelul PPTP este creat între două subreţele diferite, este necesar de
specificat, la fiecare din cele două rutere, şi rutele între cele două subreţele.
Astfel, pentru un client PPTP, reţea destinaţie va fi subreţeaua de la capătul-
server PPTP al tunelului, iar poartă va fi adresa IP a serverului PPTP. Pentru un
server PPTP, reţea destinaţie va fi subreţeaua de la capătul-client PPTP al
tunelului, iar poartă va fi adresa IP a clientului PPTP.
433
11.5.2. Configurarea tunelelor L2TP
Configurarea tunelelor L2TP este similară celei a tunelelor PPTP. Toate
informaţiile din s. 11.5.1 se referă în aceeaşi măsură la L2TP ca şi la PPTP.
Astfel, dacă este necesară informaţia respectivă despre L2TP, atunci aceasta se
obţine prin simpla înlocuire a notării PPTP cu cea L2TP. Deosebirile între
aceste două protocoale pot fi consultate, comparând informaţiile din s. 11.1.6
(PPTP) şi s. 11.1.7 (L2TP).
434
Bibliografie
1. MikroTik RouterOS Manual. MikroTik (wiki.mikrotik.com/wiki/Manual,
accesat 20.04.2014).
2. MikroTik RouterBOARD product catalog Q2 2014 (download2.mikrotik.com/
2014-Q2.pdf, accesat 20.04.2014).
3. Burgess D.M. Learn RouterOS. Sec.Ed. House Springs, 2011. – 448 p.
4. Discher St.R.W. RouterOS by Exemple. College Station, 2011. – 322 p.
5. Tomai N., Silaghi Gh.C. şi col. Tehnologii şi aplicaţii mobile. – Cluj Napoca:
Risoprint, 2012. – 506 p.
6. Bolun I. Iniţiere în reţele. Internet. – Chişinău: Editura ASEM, 1997. – 391 p.
7. Bolun I., Amarfii I. Reţele informatice: practicum de laborator. – Chişinău:
Editura ASEM, 2007. – 190 p.
8. Bolun I. Programa cursului „Formare practică MikroTik Academy”. –
Chişinău: ASEM, 2012.
9. Key ICT indicators for developed and developing countries and the world
(totals and penetration rates). ITU, 2014 (www.itu.int/en/ITU-D/
Statistics/Pages/stat/default.aspx, accesat 20.04.2014).
10. A Brief History of the Internet Advisory/Activities/Architecture Board
(www.iab.org/about/history/, accesat 20.04.2014).
11. Number of Hosts advertised in the DNS. Internet System Consortium,
January, 2014 (ftp.isc.org/www/survey/reports/20140, accesat
20.04.2014).
12. "IPv6". Google Statistics (www.google.com/intl/en/ipv6/statistics.html,
accesat 20.04.2014).
13. Lashford S. World's First Public G.hn Interop Demonstration at CES by
HomeGrid Forum Members, Jan. 10, 2012 (www.homegridforum.org/
content/pages.php?pg=news_press_releases_item&r, accesat
20.04.2014).
14. Robert V. How Broadband Over Powerlines Works. În: How Stuff Works
(computer.howstuffworks.com/bpl.htm, accesat 17.06.2013).
15. IEEE 802.11-2012 – IEEE Standard for Information technology--
Telecommunications and information exchange between systems Local
and metropolitan area networks--Specific requirements Part 11: Wireless
435
LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
IEEE, 29.03.2012.
16. Ahamed S.S. Riaz. Review and Analysis of Local Multipoint Distribution
System (LMDS) to Deliver Voice, Data, Internet, and Video Services. In:
International Journal of Engineering Science and Technology, Vol. 1(1),
October 2009, pp. 1-7.
17. Enhanced Interior Gateway Routing Protocol, Cisco document ID 16406.
(www.cisco.com/en/US/tech/tk365/technologies_white_paper0918
6a0080094cb7.shtml, accesat 17.06.2013).
18. Conexiune multi-hop L2TP. Centrul de informare iSeries
(publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rza
iy/rzaiymultihop.htm, accesat 20.04.2014).
19. Assigned Internet Protocol Numbers. IANA (http://www.iana.org/
assignments/protocol-numbers/protocol-numbers.xhtml, accesat
20.04.2014)).
20. [MS-SSTP]: Secure Socket Tunneling Protocol (SSTP) (msdn.microsoft.com/
en-us/library/cc247338.aspx, accesat 20.04.2014).
21. Ellis J.H. The Possibility of Secure Non-Secret Digital Encryption. CESG
Report, January 1970.
436
Anexa 1. Unele echipamente de reţea MikroTik (în baza [2])
Configurare
Denumire produs RAM,M Nr. porturi (Ethernet ş.a.),
Procesor Wireless Viteză
o Mbps
Soluţii integrate
Groove 52HPn AR9342* 600MHz 64 1x10/100 5GHz, 2GHz IEEE 125Mbps
802.11a/b/g/n
Groove A-52HPn AR9342 600MHz 128 1x10/100 5GHz, 2GHz IEEE 125Mbps
802.11a/b/g/n
CCR1016-12G Tile-Gx16 (16 nuclee 1,2GHz) 2x1024 12x10/100/1000, 1 serial, USB 12Gbps
CCR1036-12G-4S Tile-Gx36 (36 nuclee 1.2GHz) 2x2048 12x10/100/1000, 4xSFP, 1 16Gbps
serial, USB
CCR1036-12G- Tile-Gx36 (36 nuclee 1.2GHz) 16 Go 12x10/100/1000, 4xSFP, 1 16Gbps
4S-EM serial, USB
Metal 5Hn AR7241 400MHz 64 1x10/100 5GHz IEEE 802.11a/n
Metal 2Hn AR7241 400MHz 64 1x10/100 2GHz IEEE 802.11b/g/n
OmniTIK AR7241, 400MHz 32 5x10/100 5GHz IEEE 802.11a/n
RB260GS TF470 96 5x10/100/1000
RB750 AR7241 400MHz 32 5x10/100
RB750GL AR7241 400MHz 64 5x10/100, 1x1000
RB750UP AR7241 400MHz 32 5x10/100, USB
RB/751U-2HnDP AR7241 400MHz 32 5x10/100, USB 2GHz IEEE 802.11b/g/n
437
RB951-2n AR9331 300MHz 32 5x10/100 2GHz IEEE 802.11b/g/n
RB1100Hx2 P2020 (2nuclee 1066MHz) 1024 13x10/100/1000, 1serial
RB1100AHx2 P2020 (2nuclee 1066MHz) 2048 13x10/100/1000, 1serial
RB1200 PPC460GT 1000MHz 512 10x10/100/1000, 1serial
RB2011L AR9344 600MHz 64 5x10/100; 5x10/100/1000 2.4GHz 802.11b/g/n
RB2011L-IN AR9344 600MHz 64 5x10/100; 5x10/100/1000 2.4GHz 802.11b/g/n
RB2011L-RM AR9344 600MHz 64 5x10/100; 5x10/100/1000 2.4GHz 802.11b/g/n
RB2011LS AR9344 600MHz 64 5x10/100; 5x10/100/1000, 2.4GHz 802.11b/g/n
1SFP
RB2011LS-IN AR9344 600MHz 64 5x10/100; 5x10/100/1000 2.4GHz 802.11b/g/n
RB2011UAS- AR9344 600MHz 128 5x10/100; 5x10/100/1000, 2.4GHz 802.11b/g/n
2HnD -IN 1SFP,USB
RB/2011UAS-IN AR9344 600MHz 128 5x10/100; 5x10/100/1000,
1SFP, USB, 1serial
RB/2011UAS-RM AR9344 600MHz 128 5x10/100; 5x10/100/1000,
1SFP, USB, 1serial
SEXTANT G AR9342 600MHz 32 1x10/100/1000, USB 5GHz 802.11a/n
SXT 5HPnD AR7241 400MHz 32 1x10/100, USB 5GHz AR9280 802.11a/n
SXT Lite5 AR9344 600MHz 64 1x10/100, USB 5GHz AR9280 802.11a/n
SXT G-2HnD AR7242 400MHz 32 1x10/100/1000, USB 2GHz 802.11b/g/n
SXT Lite2 AR9344 600MHz 64 1x10/100, USB 2GHz 802.11b/g/n
Plăci de bază
RB411L AR7130 300MHz 32 1x10/100
RB411 AR7130 300MHz 32 1x10/100, 1 serial
438
RB411U AR7130 300MHz 64 1x100, 1miniPCI, 1serial, USB
RB411AR AR7130 300MHz 32 1x10/100, 1 serial
RB411AH AR7130 680MHz 64 1x10/100, 1 serial
RB411UAHL AR7130 680MHz 64 1x10/100, USB
RB411GL AR7130 680MHz 64 1x10/100, 1x1000, USB
RB411UAHR AR7130 680MHz 64 1x10/100, 1 PCIe, USB 2GHz 802.11b/g/n
RB433L AR7130 300MHz 64 3x10/100, 3miniPCI da
RB433 AR7130 300MHz 64 3x10/100, 3miniPCI, 1 serial da
RB433AH AR7161 680MHz 128 3x10/100, 3miniPCI, 1 serial da
RB433UAHL AR7161 680MHz 128 3x10/100, 3miniPCI, USB da
RB433UAH AR7161 680MHz 128 3x10/100,3miniPCI,1serial,2USB da
RB433GL AR7161 680MHz 128 3x10/100, 1x1000, 3miniPCI, USB da
RB435G AR7161 680MHz 256 3x10/100x1000, 5miniPCI, da
2USB, 1serial
RB450 AR7130 300MHz 32 5x10/100, 1 serial
RB450G AR7161 680MHz 256 5x10/100x1000, 1 serial
RB493 AR7130 300MHz 64 9x10/100, 3miniPCI, 1ser.
RB493AH AR7161 680MHz 128 9x10/100, 3miniPCI, 1serial
RB493G AR7161 680MHz 128 9x10/100x1000,3miniPCI, USB
RB711-2Hn AR7241 400 MHz 32 1x10/100 2GHz AR9283 802.11b/g/n
RB711-2Hn AR7241 400 MHz 32 1x10/100 2GHz AR9283 802.11b/g/n
RB711-2Hn AR7241 400 MHz 64 1x10/100, USB 2GHz AR9283 802.11b/g/n
RB711-5Hn AR7241 400 MHz 32 1x10/100, 5GHz AR9283 802.11a/n
RB800 MPC8544 800MHz 256 3x10/100x1000, 1PCI, 2GHz sau 5GHz, în funcție
439
4miniPCI, 1miniPCIe, 1 ser. de cartela folosită
RB911G-5HPnD AR9342 600MHz 32 1x1000 5GHz AR9283 802.11a/n
RB911G-2HPnD AR9342 600MHz 32 1x1000 2GHz AR9283 802.11b/g/n
RB912UAG-5HPnD AR9342 600MHz 64 1x1000,1 mini PCIe,USB 5GHz AR9283 802.11a/n
RB912UAG-2HPnD AR9342 600MHz 64 1x1000,1 mini PCIe, USB 2GHz AR9283 802.11b/g/n
RB951G-2HnD AR9344 600MHz 128 5x10/100/1000 2GHz 802.11b/g/n
RB2011UAS-2HnD AR9344 600MHz 128 5x10/100; 5x10/100/1000, 2.4GHz 802.11b/g/n
1SFP, USB
Cartele
R5SHPn AR9220 miniPCI 5GHz IEEE 802.11a/n 125Mbps
R2SHPn AR9220 miniPCI 2.4GHz 802.11b/g/n 125Mbps
R52 AR5414 802.11a/b/g
R52H AR5414 802.11a/b/g
R52Hn AR9220 miniPCI 802.11a/b/g/n 300Mbps
R52N-m AR9220 miniPCI 802.11a/b/g/n 300Mbps
RB44Ge AR8131M 4x10/100/1000, 4PCIe 300Mbps
*AR – procesor Atheros; PPC, P – procesor Power PC; Tile – procesor Tilera; TF – procesor Taifatech.
440
Anexa 2. Funcționalități ale unor echipamente de reţea Mikrotik
711G-5HnD/SEXTANT G-5HnD
SXT G-2HnD/SXT G-5HnD
SXT Lite 2(Lite 5)/SEXTANT 5HnD

751G-2HnD/951G-2HnD
411AR/951-2n/Groove A2Hn-32
711UA-2HnD/711UA-5HnD
711-2HnD(5HnD)/SXT 5HPnD/
( A5Hn)/Metal 2SHPn(5SHPn)
411/411L/711-2Hn/711-5Hn
411UAHR/411UAHL
OmniTIK UPA-5HnD
2011LS/2011LS -IN
Groove 2Hn/Groove 5Hn

433UAH/433UAHL
2011UAS-2HnD-IN
CCR1016-12G-BU
CCR1036-12G-4S
2011L/2011L -IN
OmniTIK U-HnD
2011UAS-2HnD
CCR1036-12GS
1200/1100Hx2
2011UAS-RM
711GA-5HnD
450G/750GL
2011UAS-IN
751U-2HnD
2011L-RM
433/433L
450/750
493AH
433AH
411AH
750UP
433GL
411GL
411U
493G
435G
800
493
Șasiu ˅ ˅ ˅ ˅ ˅
LCD ˅ ˅ ˅ ˅ ˅ ˅
Port SFP ˅ ˅ ˅ ˅ ˅ ˅ ˅
Ruter magistral ˅ ˅ ˅ ˅ ˅
Două circuite fără fir ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
Magistrală fără fir ˅ ˅ ˅
Ieșire PoE ˅ ˅
Unitate 3G ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
Gigabit Ethernet ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
MultiAP sarcină înaltă ˅ ˅ ˅ ˅ ˅
˅ ˅
AP sarcină înaltă ˅ ˅ ˅ ˅ ˅ ˅
˅ ˅ ˅ ˅ ˅
AP sarcină medie ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
AP sarcină mică ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
Ruter Eth. sarcină înaltă ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
Ruter Eth. sarcină medie ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅ ˅
Ruter Eth. sarcină mică ˅ ˅ ˅ ˅ ˅ ˅
CPE cost mic, punct-la-punct ˅ ˅ ˅
441
Anexa 3. Numere de porturi ale soclurilor Internet
Protocolul ce
Port Descriere
îl foloseşte
7 TCP UDP Echo (Echo Protocol)
11 TCP UDP USERS – utilizatori activi
20 TCP FTP (File Transfer Protocol) – transfer de date
21 TCP FTP (File Transfer Protocol) – control (comenzi)
SSH (Secure SHELL) – logare şi transfer de fişiere (scp, sftp)
22 TCP
securizate
23 TCP TELNET (Network Terminal Protocol)
25 TCP SMTP (Simple Mail Transfer Protocol)
37 TCP UDP TIME (TIME Protocol)
43 TCP WHOIS (WHOIS Protocol)
53 TCP UDP DNS (Domain Name System)
57 TCP Mail Transfer Protocol (RFC 780)
BOOTP (Bootstrap Protocol) Server; DHCP (Dynamic Host
67 UDP
Configuration Protocol )
BOOTP (Bootstrap Protocol) Client; DHCP (Dynamic Host
68 UDP
Configuration Protocol )
69 UDP TFTP (Trivial FTP)
80 TCP HTTP (Hipertext Transfer Protocol)
109 TCP POP2 (Post Office Protocol v2)
110 TCP POP3 (Post Office Protocol v3)
115 TCP SFTP (Simple File Transfer Protocol)
118 TCP UDP SQL (Structured Query Language) – servicii SQL
119 TCP NNTP (Network News Transfer Protocol)
123 UDP NTP (Network Time Protocol)
143 TCP IMAP (Internet Massage Access Protocol)
161 UDP SNMP (Simple Network Management Protocol)
179 TCP BGP (Border Gateway Protocol)
194 TCP UDP IRC (Internet Relay Chat)
220 TCP UDP IMAP v3 (Internet Message Access Protocol)
264 TCP UDP BGMP (Border Gateway Multicast Protocol)
443 TCP HTTPS (Hypertext Transfer Protocol prin SSL/TLS)
512 UDP rexec (Remote Process Execution)
500 UDP Internet Key Exchange (IKE) protocol
520 UDP RIP (Routing Information Protocol)
442
521 UDP RIPng (Routing Information Protocol next generation)
546 TCP DHCPv6 (Dynamic Host Configuration Protocol) client
547 TCP DHCPv6 (Dynamic Host Configuration Protocol) server
554 TCP RTSP (Real Time Streaming Protocol)
563 TCP UDP NNTPS (Network News Transfer Protocol prin SSL/TLS)
646 TCP UDP LDP (Label Distribution Protocol)
989 TCP UDP FTPS (date) (FTP prin TLS/SSL)
990 TCP UDP FTPS (comenzi) (FTP prin TLS/SSL)
992 TCP UDP TELNET prin TLS/SSL
993 TCP IMAPS (Internet Massage Access Protocol prin TLS/SSL)
995 TCP POP3S (Post Office Protocol 3 prin TLS/SSL)
1080 TCP SOCKS proxy
1194 TCP UDP OpenVPN
1293 TCP UDP IPsec (Internet Protocol Security)
1512 TCP UDP WINS (Microsoft Windows Internet Name Service)
L2F (Layer 2 Forwarding Protocol) şi L2TP (Layer 2
1701 UDP
Tunneling Protocol)
1718 UDP H.323 (Gatekeeper Discovery)
1719 TCP H.323 Gatekeeper RAS
1720 TCP H.323 Call Setup
1723 TCP PPTP (Point-to-Point Tuneling Protocol)
1731 TCP H.323 Audio Call Control
1900 UDP nPnP (Universal Plug and Play)
2000 TCP Serverul de testare a lăţimii de bandă
2427 UDP MGCP (Media Gateway Control Protocol)
2828 TCP nPnP (Universal Plug and Play)
3306 TCP UDP Sistemul de gestiune a bazelor de date MySQL
3455 TCP UDP RSVP (Resource Reservation Protocol)
3986 TCP Proxy for WinBox
3987 TCP SSL proxy for secure WinBox
5000+ UDP H.323 RTP Audio Streem
5004 TCP UDP RTP (Real-time Transport Protocol) – date media
5005 TCP UDP RTP (Real-time Transport Protocol) – control
5060 TCP UDP SIP (Session Initiation Protocol)
5061 TCP UDP SIPS (Session Initiation Protocol prin TLS/SSL)
5222 TCP XMPP (Extensible Messaging and Presence Protocol)
XMPPS (Extensible Messaging and Presence Protocol
5223 TCP
prin TLS/SSL)
5353 UDP mDNS (Multicast DNS)
443
5678 UDP MikroTik Neighbor Discovery Protocol
6665-
TCP IRC (Internet Relay Chat)
6669
6687 TCP IRC SSL (Secure Internet Relay Chat)
8080 TCP HTTP Web Proxy
8291 TCP WinBox
8728 TCP API
20561 UDP MAC WinBox
/1 ICMP
/4 Încapsularea IP-IP în IP
/41 Încapsularea IPv6
GRE (General Routing Encapsulation) pentru tunele PPTP
/47
şi EoIP
/50 ESP (Encapsulating Security Payload for IPv4)
/51 AH (Authentication Header for IPv4)
/89 OSPF (Open Shortest Path First)
444
Anexa 4. Lista exemplelor
Pa-
Exemplul
gina
1.1 Folosirea câmpului TTL al antetului unui pachet IPv4 35
1.2 Adresă de clasa C 46
1.3 Folosirea schemei de adrese cu subreţele 47
1.4 Folosirea schemei CIDR 47
1.5 Adresă MAC locală a entitităţilor de reţea 65
3.1 Notarea de echipamente RouterBoard 118
4.1 Notarea activării consecutive pentru executarea unor funcţii 140
4.2 Comanda de afişare a rutelor tabelului de rutare 142
4.3 Comanda de revenire, de la starea curentă, în meniul rădăcină al 142
arborelui de comenzi
4.4 Comanda de deplasare în arbore cu un nivel mai sus, spre meniul 142
rădăcină
4.5 Configurarea legăturii calculator-ruter utilizator 148
4.6 Restabilirea unei copii de rezervă binare 169
4.7 Salvarea în formă binară şi ulterioara restabilire a configurării ruterului 169
din linia de comandă
4.8 Crearea şi folosirea copiilor de rezervă textuale ale configurării curente 171
a RouterOS
4.9 Resetarea configurării ruterului din linia de comandă Terminal a 173
WinBox
5.1 Adăugarea unei reguli log ce ar fixa aplicarea comenzilor ping din 186
partea stațiilor către ruter
5.2 Definirea unei reguli dst-nat 196
5.3 Definirea unei reguli redirect 197
6.1 Distribuire lăţme de bandă conform limit-at 207
6.2 Distribuire lăţme de bandă cu implicarea max-limit 208
6.3 Distribuire lăţme de bandă cu implicarea limit-at a cozilor interne 208
6.4 Distribuire lăţme de bandă conform limit-at trunchiat 209
6.5 Definirea de reguli de marcare Mangle 211
6.6 Limitarea torentelor 218
6.7 Configurarea cozilor simple din linia de comandă 219
6.8 Folosirea transferurilor în rafale 220
6.9 Atribuirea de priorităţi 221
445
6.10 Configurarea cozilor arbore PC1 şi server 222
6.11 Alocarea de rate egale anumite staţiilor unei subreţele 226
6.12 Alocarea de rate egale anumite staţiilor unei subreţele folosind cozile 228
simple
6.13 Distribuirea egală a unei rate anumite între staţiile unei subreţele 228
6.14 Distribuirea egală a unei rate necunoscute între staţiile unei 230
subreţele
6.15 Determinarea sursei traficului de date folosind Torch 234
6.16 Monitorizarea traficului cozilor simple folosind Graphing 236
6.17 Monitorizarea traficului prin interfeţele ruterului folosind Graphing 237
7.1 Configurarea statică a unei noi înregistrări ARP 243
7.2 Configurarea perimetrelor de acces Hotspot 259
7.3 Accesul Hotspot fără autentificare – IP binding 259
7.4 Restricţionarea accesului la serverul proxy folosind i-bariera 263
7.5 Restricţionarea accesului la serverul proxy de la anumite staţii 264
7.6 Blocarea accesului la anumite situri Web 264
7.7 Blocarea accesului de la anumite staţii la un sit Web dat 264
7.8 Blocarea accesului de la anumite staţii la situri Web ce conţin un subşir 264
dat de caractere în URL
7.9 Blocarea descărcării, pentru anumite staţii, a fişierelor cu o anumită 265
extensie
7.10 Redirecţionarea accesului de la un sit Web la altul 265
7.11 Setarea evidenţei paginilor Web în memoria RAM 266
7.12 Setarea evidenţei paginilor Web pe un calculator 266
7.13 Configurarea funcţiei Email 269
7.14 Restartarea ruterului la căderea accesului la Internet, folosind 273
Netwatch
8.1 Configurarea minimă a ruterului-staţie client 313
8.2 Configurarea minimă a ruterului- punct de acces 316
8.3 Crearea regulilor de asociere la AP prin interfaţa wlan1 320
8.4 Crearea de reguli de conectare a staţiei la AP, prin interfaţa wlan1 323
8.5 Crearea și aplicarea profilului de securitate profilsec1 la ruterul-staţie 326
client
8.6 Setarea interfeţei wlan1 a ruterului-staţie client la opţiunea nv2 328
nstreme 802.11 a protocolului de acces la mediul fără fir
8.7 Crearea la ruter o interfeţei fără fir duplex cu numele wlandual 330
9.1 Puntarea interfeţelor Ethernet 336
9.2 Puntarea transparentă a unei legături fără fir 337
10.1 Determinarea rutei celei mai specifice 344
446
10.2 Determinarea rutei după distanță 346
10.3 Definirea rutelor statice 347
10.4 Căutarea recursivă a saltului următor 389
10.5 Setarea rutei implicite 394
10.6 Setarea de rute statice 395
10.7 Setarea OSPF pe un singur domeniu 395
11.1 Adresarea punct-la-punct PPPoE 408
11.2 Adresarea punct-la-punct server PPPoE – clienţi PPPoE 409
11.3 Configurarea unui fond de adrese IP 423
11.4 Configurarea PPP Profile 424
11.5 Configurarea PPP Secret 426
11.6 Configurarea PPTP Client 432
447
Anexa 5. Lista sarcinilor practice
Pa-
Sarcină practică
gina
4.1 Configurarea cartelei de reţea a calculatorului utilizatorului 148
4.2 Configurarea legăturii calculator-ruter utilizator 150
4.3 Configurarea interfeţei wlan1 a ruterului utilizatorului 153
4.4 Configurarea legăturii PC-Internet prin AP 154
4.5 Specificarea identităţii ruterului utilizatorului 156
4.6 Adăugarea unui utilizator nou cu drepturi de administrator 157
4.7 Actualizarea RouterOS 165
4.8 Dezactivarea şi reactivarea modulul wireless 168
4.9 Crearea, modificarea și reinstalarea unei copii de rezervă binară a 170
configurărilor curente ale RouterOS
5.1 Definirea de reguli input 184
5.2 Definirea de reguli forward 185
5.3 Definirea de reguli log 187
5.4. Definirea de reguli folosind starea conexiunilor 189
5.5 Crearea de liste de adrese şi reguli cu folosirea lor 191
5.6 Definirea regulii masquerade pentru un port anume 194
6.1 Limitarea ratei de acces la Internet pentru calculator 215
6.2 Limitarea ratei de acces de la calculator la o adresă dată din Internet 217
6.3 Aplicarea disciplinei PCQ folosind cozi simple 230
6.4 Testarea capacităţii de transfer date către o interfaţă a ruterului 232
utilizatorului
6.5 Monitorizarea traficului printr-o o interfaţă a ruterului utilizatorului 233
8.1 Configurarea ruterului utilizatorului ca staţie client 315
8.2 Configurarea ruterului utilizatorului ca punct de acces 317
8.3 Crearea a trei reguli de acces la AP prin interfaţa wlan1 321
9.1 Crearea unui sistem WDS 339
10.1 Setarea rutei implicite 395
10.2 Setarea de rute statice 395
10.3 Setarea OSPF pe un singur domeniu 396
11.1 Configurarea de fonduri de adrese IP 423
11.2 Configurarea PPP Profile 425
11.3 Configurarea PPPoE Client 429
11.4 Configurarea PPPoE Server 430
11.5 Configurarea PPTP Client 432
448
Anexa 6. Abrevieri
ABR – Area Border Router (Ruter marginal al zonei)
ACFC – Address and Control Field Compression (Compresia câmpurilor Adresa
şi Control)
ADSL – Asymetric DSL (DSL asimetrică)
AES – Advanced Encryption Standard (Standard de cifrare avansată)
AH – Authentication Header (Antet de autentificare)
A-MPDU – MPDU agregation (Agregare MPDU)
A-MSDU – MSDU agregation (Agregare MSDU)
AP – Access point (Punct de acces)
ARP – Address Resolution Protocol (Protocolul de rezoluţie a adresei)
AS – Autonomous System (Sistem autonom)
ASBR – Autonomous System Border Router (Ruter marginal al AS)
BCP – Bridge Control Protocol (Protocol de control al punţii)
BDR – Backup Designated Router (Ruter desemnat de rezervă)
BFIFO – Bytes First-In First-Out (Octeții: primii sosiți – primii deserviți)
BGP – Border Gateway Protocol (Protocolul de poartă marginală)
BR – Backbone Router (Ruter nucleu)
BRI – Basic Rate Interface (Interfaţă rată de bază, Acces de bază)
BSA – Basic Service Area (Aria serviciilor de bază)
BSS – Basic Service Set (Set de servicii de bază)
BSSID – BSS ID
BTNS – Better Then Nothing Securuty (Securitate mai bună decât nimic)
CBR – Contention Based Protocol (Protocol bazat pe conţinut)
CCITT – Comittée Consultative Internationale de Telefonie et Telegrafie
CCMP – Counter Mode Cipher Block Chaining Message Authentication Code
Protocol
CD – Compact Disc
CDP – Cisco Discovery Protocol (Protocol de descoperire Cisco)
CF – Compact Flash (Cartelă de memorie CF)
CHAP – Challenge Handchake Authentification Protocol
CIDR – Classless Inter-Domain Routing (Rutarea inter-domeniu fără clase)
CIR – Committed Information Rate (Rata asigurată de informații)
CLNP – Connectionless-mode Network Protocol (Protocol de rețea mod fără
conexiune)
CR – Contention Ratio (Raportul de dispută)
CRC – Cyclic Redundaancy Check (Verificarea redundanţei ciclice)
449
CSLIP – Compressed Serial Line Internet Protocol (Protocolul Internet pentru
linii seriale cu compresie)
CSMA/CD – Carrier Sense Multiple Access with Colision Detection (Acces
multiplu cu controlul purtătoarei şi detecţia coliziunilor)
DES – Data Encryption Standard (Standard de cifrare a datelor)
DFS – Dynamic Frequency Selection (Selectarea dinamică a frecvenţei)
DHCP – Dynamic Host Configuration Protocol (Protocol de configurare
dinamică a staţiilor)
DNS – Domain Name System (Sistemul numelor de domenii)
DR – Designated Router (Ruter desemnat)
DS – Distribution System (Sistem de distribuire)
DSL – Digital Subscriber Line (Linie de abonat numerică)
DSA – Digital Signature Algorithm (Algoritm de semnătură numerică)
DSE – Dynamic Station Enablement (Activarea dinamică a staţiei)
DSM – DS Medium (Mediul DS)
DSSS – Direct-Sequence Spread Spectrum
EAP – Extensible Authentification Protocol (Protocol de autentificare
extensibilă)
eBGP (EBGP) – Exterior BGP (BGP exterior)
ECMP – Equal Cost Multipath (Multicale de cost egal)
ECN – Explicit Congestion Notification (Notificarea explicită a congestiei)
EGP – Exterior Gateway Protocol (Protocol pentru porţi exterioare)
EIGRP – Enhanced Interior Gateway Routing Protocol (Protocol de rutare
pentru porţi interioare îmbunătăţit)
EoIP – Ethernet over IP (Ethernet peste IP)
ESP – Encapsulating Security Payload (Încapsularea securizată a sarcinii utile)
ESS – Extended Service Set (Set de servicii extins)
EUI – Extended Unique Identifier (Identificator unic extins)
FHSS – Frequency-Hopping Spread Spectrum
FIB – Forwarding Information Base (Baza informaţiilor de înaintare)
FIFO – First Input - First Output (Primul sosit – primul serveit)
FTP – File Transfer Protocol (Protocolul transferului de fişiere)
FTTB – Fiber-To-The-Building (Fibră-până-la-clădire)
FTTC – Fiber-To-The-Curb (Fibră-până-la-margine)
FTTD – Fiber-To-The-Desk (Fibră-până-la-birou)
FTTH – (Fiber-To-The-Home (Fibră-până-la-locuinţă)
FTTN – Fiber-To-The-Node (Fibră-până-la-nod)
FTTP – Fiber-To-The-Premises (Fibră-până-la-sediu)
FSC – Frame Check Sequence (Secvenţa de verificare a cadrului)
GRE – Generic Routing Encapsulation (Încapsularea de rutare generică)
450
GTK – Group Transient Key (Cheie de grup tranzitorie)
HDD – Hard Disk Drive (Unitate de disc fix)
HDLC – High-Level Data Link Control (Control de nivel înalt al legăturii de date)
HDSL – High DSL
HTB – Hierarchical Token Bucket (Cupă ierarhică cu jeton)
HTTP – Hipertext Transfer Protocol (Protocolul transferului de hipertexte)
HTTPS – HTTP Secured (HTTP securizat)
IAB – Internet Advisory Board, Internet Arhitecture Board
IANA – Internet Assigned Numbers Authority
iBGP – Interior BGP (BGP interior)
iBSS – Infrastructure BSS (BSS infrastructură)
IBSS – Independent BSS (BSS independent)
ICMP – Internet Control Mesage Protocol (Protocolul mesajelor de control
Internet)
ICANN – Internet Corporation for Assigned Names and Numbers
ICCB – Internet Configuration Control Board
ICMP – Internet Control Message Protocol (Protocolul de control al mesajelor
Internet)
ID – Identificator
IEEE – Institute of Electrical and Electronics Engineers
IETF – Internet Engineering Task Force
IGMP – Internet Group Management Protocol (Protocolul de gestiune a
grupurilor Internet)
IGP – Interior Gateway Protocol (Protocol pentru porţi interioare)
IGRP – Interior Gateway Routing Protocol (Protocol de rutare pentru porţi
interioare)
IKE – Internet Key Exchange (Schimbul de chei Internet)
IMAP – Internet Message Access Protocol (Protocolul de acces al mesajelor
Internet)
IMAPS – IMAP Secured (IMAP securizat)
InARP – Inverse Address Resolution Protocol (Protocolul de rezoluţie inversă a
adresei)
IP – Internet Protocol (Protocolul Internet)
IPCP – IP Control Protocol (Protocolul de control IP)
IPIP – IP inside IP (IP în cadrul IP)
IPsec – Internet Protocol Security (Securitatea protocolului Internet)
IPX – Internetwork Packet Exchange
IPXCP – IPX Control Protocol (Protocolul de control IPX)
IR – Internal Router (Ruter intern)
IRC – Internet Relay Chat (Conversaţii prin Internet)
451
IRTF – Internet Research Task Force
ISAKMP – Internet Security Association and Key Management Protocol
ISDN – Integrated Services Digital Network (Reţea numerică cu servicii
integrate)
IS-IS – Intermediate System to Intermediate System (Sistem intermediar către
sistem intermediar)
ISO – International Standard Organization (Oraganizaţia Internaţională de
Standardizare)
ISOC – Internet SOCiety (Societatea Internet)
ISP – Internet Service Provider (Furnizor de servicii Internet)
ITU-T – International Telecommunication Union – Telecommunication
(Uniunea Internaţională de Telecomunicaţii - Telecomunicaţii)
KINK – Kerberized Internet Negotiation of Keys (Negocierea cheilor prin
Internet Kerberizată)
L1 – Level 1 (Nivel 1)
L2F – Layer 2 Forwarding Protocol (Protocol de înaintare de Nivel 2)
L2TP – Layer 2 Tunneling Protocol (Protocol de tunelare de Nivel 2)
LAC – L2TP Access Concentrator (Concentrator de acces L2TP)
LAN – Local Area Network (Reţea locală de calculatoare)
LAPB – Link Access Procedure, Balanced (Protocolul de acces balansat al
legăturii)
LCCE – L2TP Control Connection Endpoints (Capetele de control al conexiunii
L2TP)
LCP – Link Control Protocol (Protocolul de gestiune a legăturii)
LLC – Logical Link Control (Controlul legăturii logice)
LMDS – Local Multipoint Distribution Service (Serviciu local distribuit
multipunct)
LSA – Link-State Advertisments (Anunţ stare-legături)
LSDB – link state database (Bază de date stare-legături)
LSU – Link-State Update (Actualizare stare-legătură)
MAC – Medium Access Control (Controlul accesului la mediu)
MAN – Metropolitan Area Network (Reţea metropolitană de calculatoare)
MBSS – Mesh BSS (BSS plasă)
MCPPP – Multiclass PPP (PPP clase multiple)
MD5 – Message Digest 5
MGCP – Media Gateway Control Protocol (Protocolul de control al porţilor de
media)
MIB – Management Information Base (Baza informaţiilor de gestiune)
452
MIMO – Multiple-input and Multiple-output (Multiple intrări şi multiple ieşiri)
MIR – Maximal Information Rate (Rata maximă de informații)
MLPPp – Multilink PPP (Protocolul PPP legături multiple)
MLPPPoE – Multilink PPPoE (PPPoE multilegătură)
MNDP – Mikrotik Neighbor Discovery Protocol (Protocolul Mikrotik de
descoperire a vecinilor)
MME – Mesh Made Easy (Creare uşoară plasă)
MP2MP – Multipoint-to-Multipoint (Multipunct-la-multipunct)
MPDU – MAC protocol data unit (Unitate de date de protocol MAC)
MPLS – Multiprotocol Label Switching (Multiprotocol cu comutare prin
etichete)
MPPE – Microsoft Point to Point Encryption (Cifrare punct-la-punct Miscrosoft)
MRRU – Multilink Maximum Received Reconstructed Unit (Unitatea maximă de
recepţie refăcută multilegătură)
MRU – Maximum Receive Unit (Unitatea maximă de recepţie)
MSDU – MAC service data unit (Unitate de date de deservire MAC)
MTU – Maximum Transmission Unit (Unitate maximă de transmisie)
NAS – Network Access Server (Serverul de acces la reţea)
NAT – Network Address Translation (Translatare de adrese de reţea)
NBMA – Nonbbroadcast Multiaccess (Multiacces non-difuzare)
NCP – Network Control Protocol (Protocolul de gestiune a reţelei)
NDP – Neighbor Discovery Protocol (Protocolul de descoperire a vecinilor)
NFS – Network File System (Sistemul de fişiere de reţea)
NIC – Network Interface Controller sau Network Interface Card (Cartelă de
interfaţă de reţea, Cartelă de reţea)
NMS – Network Management System (Sistem de gestiune a reţelei)
NNTP – Network News Transfer Protocol (Protocolul transferului ştirilor în
reţea)
NSSA – Not-So-Stubby Area (Zonă nu complet ciot)
NTP – Network Time Protocol (Protocolul timpului în reţea)
OFDM – Orthogonal Frequency-Division Multiplexing
OID – Object Identifier (Identificatorul obiectului)
OSI – Open System Interconnection (Interconectarea sistemelor deschise)
OSPF – Open Shortest Path First (Deschide mai întâi calea cea mai scurtă)
OUI – Organizationally Unique Identifier (Identificatoul unic al organizației)
P2P – Peer-to-Peer (Punct-la-punct)
P2MP – Point-to-Multipoint (Punct-la-multipunct)
PAN – Perosnal Area Network (Reţea personală de calculatoare)
PAP – Password Authentification Protocol (Protocol de autentificare prin
parolă)
453
PAC – PPTP Access Concentrator (Concentrator de acces PPTP)
PCQ – Per Connection Queue (Coadă per conexiune)
PDU – Processing Data Unit (Unitate de date pentru procesare)
PFIFO – Packets First-In First-Out (Pachetele: primele sosite – primele
deservite)
PIM – Protocol Independent Multicast (Multiadresat independent de
protocol)
PKI – Public Key Infrastructure (Infrastructură de chei publice)
PMK – Pariwise Master Key (Cheie pereche master)
PNS – PPTP Network Server (Server de reţea PPTP)
POP – Post Office Protocol (Protocolul oficiului de poştă)
POS – Packet over SONET/SDH (Pachete peste SONET/SDH)
PPP – Point-to-Point Protocol (Protocol punct-la-punct)
PPPoA – PPP over ATM (PPP peste ATM)
PPPoE – PPP over Ethernet (PPP peste Ethernet)
PPTP – Point to Point Tunneling Protocol (Protocol de tunelare punct-la-punct)
PRI – Primary Rate Interface (Interfaţă rată primară, Acces primar)
PSK – Pre-Shared Key (Cheie pre-partajată)
PTK – Pairwise Transient Key (Cheie pereche tranzitorie)
QoS – Quality of Services (Calitatea serviciilor)
RARP – Reverse Address Resolution Protocol (Protocolul de rezoluţie reversă a
adresei)
RED – Random Early Drop (Aruncarea aleatoare timpurie)
RFC – Request for Comments (Cerere pentru comentarii)
RIB – Routing Information Base (Baza informaţiilor de rutare)
RIP – Routing Information Protocol (Protocolul informaţiilor de rutare)
RIR – Regional Internet Registers (Registre Internet regionale)
RouterOS – sistem de operare de reţea pentru rutere Mikrotik
RPC – Remote Procedure Call (Chemarea procedurilor la distanţă)
RSN – Robust security network (Reţea puternic securizată)
RSNA – Robust security network association (Asociaţie de reţea puternic
securizată)
RSTP – Rapid Spanning Tree Protocol (Protocol de acoperire rapidă a
arborelui)
RTCP – RTP Control Protocol (Protocolul de control al RTP)
RTMP – Real-Time Messaging Protocol (Protocolul de mesajerie în timp real)
RTP – Real-time Transport Protocol (Protocolul de transport în timp real)
RTSP – Real Time Streaming Protocol (Protocolul de flux în timp real)
SCTP – Stream Control Transmission Protocol (Protocol de control al
transmisiei fluxului)
454
SD – Secure Digital (Cartelă de memorie SD)
SDD – Solid State Disk (Discuri de memorie SSD)
SDH – Sinchronous Digital Hierachy (Ierarhia Numerică Sincronă)
SDLC – Synchronous Data Link Control (Controlul legăturii de date sincrone)
SDM – Spatial Division Multiplexing (Multiplexarea cu divizare spaţială)
SDSL – Single DSL
SFQ – Stochastic Fairness Queuing (Deservirea stocastică echilibrată);
SGCP – Simple Gateway Control Protocol (Protocol simplu de gestiune a
porţilor)
SHA – Source Hardware Address (Adresa echipamentului emiţătorului)
SIP – Session Initiation Protocol (Protocolul de iniţiere a sesiunii)
SIPS – SIP Secured (SIP securizat)
SLIP – Serial Line Internet Protocol (Protocolul Internet pentru linii seriale)
SMTP – Simple Mail Transfer Protocol (Protocol de transfer poştă ordinară)
SNMP – Simple Network Management Protocol (Protocolul simplu de gestiune
a reţelei)
SNTP – Simple NTP (NTP simplu)
SHELL – Remote Shell Protocol (Protocolul de interfaţă utilizator la distanţă)
SLAAC – Stateless address autoconfiguration – Autoconfigurare adresă fără
stare
SOCKS – SOCKet Secure (Soclu securizat)
SONET – Synchronous Optical Network (Reţea optică sincronă)
SPA – Sender Protocol Address (Adresa de protocol a emiţătorului)
SPI – Security Parameter Index (Indexului parametrilor de securitate)
SSID – Service Set Identifier (Identificatorul setului de servicii)
SSL – Secure Sockets Layer (Nivelul de socluri securizate)
SSH – Secure Shell (Interfaţă securizată)
SSTP – Secure Socket Tunneling Protocol (Protocol de tunelare prin soclu
securizat)
STD – Standard
STP – Spanning Tree Protocol (protocol de acoperire a arborelui)
SwOS – sistem de operare de reţea pentru comutatoare Mikrotik
TCP – Transmission Control Protocol (Protocol de control al transmisiei)
TLS – Transport Layer Security (Securitatea nivelului Transport)
TFTP – Trivial FTP (Protocolul trivial de transfer de fişiere)
THA – Target Hardware Address (Adresa echipamentului destinaţiei)
TPA – Target Protocol Address (Adresa de protocol a destinaţiei)
TSA – Totally Stubby Area (Zonă complet ciot)
TTL – Time To Live (Timp de viaţă)
UDP – User Datagram Protocol (Protocol datagrame utilizator)
455
UPnP AV – Universal Plug and Play Audio and Video (Audio şi video plug and
play universal)
URL – Uniform Resource Location (Localizarea uniformă a resurselor)
UTP – Unshielded Twisted Pairs (Perechi răsucite neecranate)
VDSL – Very High DSL (DSL de viteză foarte înaltă)
VLAN – Virtual LAN (Reţea locală virtuală)
VoD – Video-on-Demand (Video la cerere)
VoIP – Voice over IP (Voce peste IP)
VPLS – Virtual Private Service (Serviciu privat virtual)
VPN – Virtual Private Network (Reţea privată virtuală)
VRF – Virtual Routing and Forwarding (Rutarea şi înaintarea virtuală)
VRRP –Virtual Router Redundancy Protocol (Protocolul de redundanţă a
ruterelor virtuale)
WAN – Wide Area Network (Reţea de calculatoare de arie largă)
WDS – Wireless Distribution System (Sistem de distribuire fără fir)
WEP – Wired Equivalent Privacy (Confidenţialitate echivalentă celei cu
cabluri)
WLAN – Wireless LAN (Reţea locală fără fir)
WM – Wireless Medium (Mediu fără fir)
WMAN – Wireless MAN (MAN fără fir)
WMM – Wireless Multimedia (Multimedia fără fir)
WNIC – Wireless Network Interface Controller (Interfaţă de reţea fără fir)
WPA – Wi-Fi Protected Access (Acces Wi-Fi protejat)
WPA2 – Wi-Fi Protected Access 2 (Acces Wi-Fi protejat 2)
WPAN – Wireless PAN (PAN fără fir)
WWAN – Wireless WAN (WAN fără fir)
WWW – World Wide Web
XML – Extensible Markup Language (Limbaj de marcare extensibil)
XMPP – Extensible Messaging and Presence Protocol (Protocol extensibil de
mesajerie şi prezenţă)
456
Sub redacţia autorilor
Bun de tipar 27.06.2014

Format 60x84 1/16. Coli de tipar 28,56
Coli de autor 33,79. Tirajul 50 ex.
Tipografia Departamentului Editorial-Poligrafic

al Academiei de Studii Economice din Moldova
Chişinău MD-2005, Mitropolit Gavriil Bănulescu-Bodoni 59
Tel. 40-29-36
457

InterIntranet2014 Manual Bolun

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

InterIntranet2014 Manual Bolun

Încărcat de

Drepturi de autor:

Formate disponibile

Ion Bolun, Victor Andronatiev

Punct de acces Internet

Mijloace utilizator 1 Mijloace utilizator n

Cablu UTP ∙∙∙∙∙∙∙∙ Cablu UTP

Fig. 4.11. Schema reţelei de calculatoare de creat.

Ion Bolun, Victor Andronatiev

Toate drepturile rezervate autorilor:

1.2. Structura Internet

Fig. 1.1. Interconectarea reţelelor în Internet.

1.3. Modelul de referinţă OSI ISO

Nivele inferioare Nivele superioare

Fig. 1.2 Schema modelului de referinţă OSI ISO.

1.4. Modelul arhitectural şi protocoale TCP/IP

Transport TCP, UDP, DCCP, SCTP, RSVP

*Îndeplinesc funcţii ce ţin atât de nivelul Internet, cât şi de cel Aplicaţie.

1.4.4. Protocoale de nivel Internet

Conexiunea Desfiinţarea Faza protocolului Da Autentificare

Stabilirea Conexiunea a Da Este necesară Da Autentificarea

Fig. 1.6. Schema stabilirii şi desfiinţării unei conexiuni PPP.

1.5. Adresarea în Internet

ID reţea ID subreţea ID staţie

Fig. 1.8 Crearea unei subreţele prin fragmentarea ID staţie.

Pentru separarea prefixului de subreţea de „ID staţie”, serveşte masca

De menţionat că adresa IPv4 0.0.0.0 este folosită de staţii atunci când

Câmp Prefixul Zerouri ID interfaţă

Câmp Prefixul Fanion Sc ID group

Octeţi mai semnificativi

b) Identificatorul unic al organizaţiei Extensia identificatorului

Biţi mai semnificativi 0 – unic global (U)

Fig. 1.11. Formatul unei adrese MAC-48: a) general; b) cu detalierea octetului 1.

Conform standardului IEEE 802, pentru perceperea umană mai uşoară,

1.6. Conectarea la Internet

1.7.1. Accesul şi execuţia de sarcini la distanţă

Ruter Internet Ruter

1 – scenariul „SVoIP  SVoIP”; 4 – scenariul „T  SVoIP”;

Fig. 1.12. Alternative de realizare a telefoniei IP.

Pentru convorbiri prin Internet, utilizatorul poate folosi: a) un aparat

Cheia de cifrare e Cheia de descifrare d

Text clar Text clar

Fig. 1.13. Modelul de bază al folosirii cifrurilor.

Fig. 1.14. Modelul sistemului criptografic cu chei publice.

2.2. Avantaje intranet

2.3. Caracteristici importante ale intranet

2.4. Funcţionalităţi de bază ale intranet

2.5. Aspecte de creare şi dezvoltare a intranet

3.2. Echipamente de reţea MikroTik

Fig. 3.2. Ruterele: a) RB2011L şi b) RB411UAHR.

Fig. 3.3. Carcasele CA 493 (a) şi CAOTS (b).

Fig. 3.4. Interfeţele S-31DLC20D (a), S-3553LC20D (b) şi R52n-M.

3.3. Sistemul de operare MikroTik RouterOS

3.4. Licențe RouterOS

3.5. Sistemul de operare MikroTik SwOS

3.6. Monitorul de rețea Dude

4.1.3. Descărcarea iprogramelor Mikrotik

Fig. 4.3. Descărcarea produselor program ale Mikrotik.

Fig. 4.5. Fereastra WinBox de acces a RouterOS.

Fig. 4.6. Acţiunile de accesare MAC a ruterului folosind WinBox.

Adresă Clic dreapta

Fig. 4.7. Interfaţa de lucru a WinBox.

Fig. 4.8. Activarea/dezactivarea Safe Mode din linia de comandă.

Sistemul de comenzi şi aplicarea lor sunt succint caracterizate în s. 4.1.6.4.

Fig. 4.9. Interfaţa utilitei WebFig.

Comparând fig. 4.9 şi 4.7, se poate observa că barele meniurilor principale