Rutare Avansata in Linux Si Controlul Traficului

Rutare avansata in Linux si controlul
traficului
Autori:
Bert Hubert
Netherlabs BV
bert.hubert@netherlabs.nl
Gregory Maxwell (Section Author)
remco%virtu.nl
Remco van Mook (Section Author)
remco@virtu.nl
Martijn van Oosterhout (Section Author)
kleptog@cupid.suninternet.com
Paul B Schroeder (Section Author)
paulsch@us.ibm.com
Jasper Spaans (Section Author)
jasper@spaans.ds9a.nl
Pedro Larroy (Section Author)
piotr%omega.resa.ed
Traducere && adaptare: sasinu.
Data nasterii(lartc): 2002/12/14 22:52:31
Index
1. Dedicatie
2. Introducere
2.1. Licenta && Disclaimer
2.2. Cunostiinte necesare
2.3. Ce poate face Linux
2.4. Note de intretinere
2.5. Acces, CVS si subscrierea actualizarilor
2.6. Lista de mail
2.7. Formatul acestui document
3. Introducere - iproute2
3.1. De ce iproute2 ?
3.2. Tur iproute2
3.3. Chestii necesare
3.4. Explorarea configuratiei curente
3.4.1. Cum vedem link-urile
3.4.2. Cum vedem adresele ip
3.4.3. Cum vedem rutele
3.5. ARP
4. Reguli - baza de date cu politicile de rutare

4.1. Rutare simple source
4.2. Rutare pentru mai multi provideri
4.2.1. Split access (acces impartit)
4.2.2. Load balancing (Balansarea conexiunii)
5. GRE si tunele
5.1. Cateva notiuni despre tunele
5.2. Tunele IP-IP
5.3. Tunele GRE
5.3.1. Tunel IPv4
5.3.2. Tunel IPv6
5.4. Tunele userland
6. Tunele IPv6 cu Cisco si/sau 6bone
6.1. Tunele IPv6
7. IPSEC: IP sigur in Internet
7.1. Introducere in Manual Keying (semnare automata)
7.2. Automatic Keying (Semnare automata)
7.2.1. Teorie
7.2.2. Exemplu
7.2.3. Automatic Keying cu certificate x.509
7.3. Tunele IPSEC
7.4. Interoperarea IPSEC cu alte sisteme
7.4.1. Windows
8.
Rutare multicast (difuzare pe grupuri)
9. Queueing Disciplines (reguli de asteptare) pentru

administrarea latimii de banda
9.1. Explicarea queue-rilor (cozilor) si queueing
disciplines (reguli de asteptare)
9.2. Queueing Ddisciplines simple, fara clase
9.2.1. pfifo_fast
9.2.2. Token Bucket Filter (Filtru cu jetoane)
9.2.3. Stochastic Fairness Queueing (Cozi de
asteptare echilibrate probabilistice)
9.3.Cand si cum este folosit un anumit queue
9.4. Terminologie
9.5. Queueing Discipline cu clase (reguli de asteptare cu
clase)
9.5.1. Fluxul in qdisc-uri cu si fara clase
9.5.2. Familia qdisc: radacini, handle-re, parinti
si copii
9.5.3. qdisc PRIO
9.5.4. Renumitul qdisc CBQ
9.5.5. Hierarchical Token Bucket (Jetoane

ierarhice)
9.6. Clasificarea pachetelor cu filtre
9.6. Exemple de filtre simple
9.7. Toate comenzile de filtrare de care veti avea
nevoie in mod normal
9.7. Intermediate queueing device - IMQ (dispozitivul de
asteptare intermediar)
9.7.1. Exemple de configurare
10. Load sharing over multiple interfaces (distribuirea
conexiunii pe mai multe interfete )
10.1. Slabiciuni
10.2. Alte posibilitati
11. Netfilter si iproute - marcarea pachetelor
12. Filtre avansate pentru (re)clasificarea pachetelor
12.1 Clasificarea u32
12.1.1. Selectorul u32
12.1.2. Selectori generali
12.1.3. Selectori specifici
12.2. Clasificatorul 'route'
12.3. Policing Filters (filtre de limitare)
12.3.1. Metode de aplicare a filtrelor
12.3.2. Supralimitarea actiunilor
12.3.3. Exemple
12.4. Filtre hash pentru filtrarea rapida masiva
13. Parametrii kernel-ului pentru retea
13.1. Reverse Path Filtering (filtrare dupa calea inversa)
13.2. Setari obscure
13.2.1. Generalitati IPv4
13.2.2. Setari pe device
13.2.3. Politica vecinilor
13.2.4. Setari de rutare
14. qdisc-uri avansate si mai putin utilizate
14.1. bfifo/pfifo
14.1.1. Parametri si folosire
14.2. Algoritmul Clark-Shenker-Zhang (CSZ)
14.3. DSMARK
14.3.1. Introducere
14.3.2. La ce se refera Dsmark ?
14.3.3. Introducere in differentiated services
(servicii diferentiate)
14.3.4. Lucrul cu Dsmark
14.3.5. Cum functioneaza SCH_DSMARK

14.3.6. Filtrul TC_INDEX
14.4. qdisc-ul Ingress
14.5. Random Early Detection - RED (detectare rapida
aleatoare)
14.6. Generic Random Early Detection (detectarea generica
rapida aleatoare)
14.7. Emulare VC/ATM
14.8. Weighted Round Robin (WRR)
15. Carte de bucate
15.1. Rularea mai multor site-uri cu SLA-uri diferite
15.2. Protejarea sistemului de atacuri SYN
15.3. Limitare ratei ICMP pentru prevenire dDoS
15.4. Prioritizarea traficului interactiv
15.5. Web-caching transparent cu netfilter, iproute2,
ipchains si squid
15.5.1. Diagrama fluxului de trafic dupa
implementare
15.6. Prevenire problemelor Path MTU Discovery cu setari
MTU pentru fiecare ruta
15.6.1. Solutie
15.7. Prevenirea problemelor Path MTU Discovery cu MSS
Clamping (pentru utilizatorii ADSL, cablu, PPPoE si
PPtP)
15.8. Cel mai tare Traffic Conditioner (coordonator de
trafic): Intarziere mica, down/upload-uri rapide
15.8.1. De ce nu functioneaza bine in modul
prestabilit
15.8.2. Scriptul real (CBQ)
15.8.3. Scriptul real (HTB)
15.9. Limitarea ratei pentru un singur host sau o masca de
reatea
15.10. Exemplu de configurare NAT cu Qos
15.10.1. Optimizare latimii de banda
15.10.2. Clasificarea pachetelor
15.10.3. Imbunatatirea configuratiei
15.10.4. Activarea configuratiei la pornire
16. Construirea bridge-urilor, si pseudo-bridge-urilor cu Proxy
ARP
16.1. Stadiul de dezvoltare - bridging si iptables
16.2. Bridging si shaping
16.3. Pseudo-bridge-uri cu Proxy ARP
16.3.1. ARP si Proxy ARP
16.3.2. Implementare
17. Rutare dinamica - OSPF si BGP

17.1. Setare OSPF cu Zebra
17.1.1. Chestii necesare
17.1.2. Configurare Zebra
17.1.3. Rulare Zebra
18. Alte posibilitati
19. Bibliografie
20. Multumiri.
1. DEDICATIE
Lu' tipu'.
2. INTRODUCERE
Acest document incearca sa aduca putina lumina in metodele
de rutare Linux 2.2/2.4. Desi poate nu stiti, deja folositi niste
instrumente care va permit realizarea unor lucruri spectaculoase.
Comenzi ca route sau ifconfig sunt de fapt niste interfete la
puternica infrastructura iproute2.
2.1. Licenta si disclaimer

Ba! Daca stricati ceva eu nu sunt de vina caci eu sunt pur
si cast si nevinovat. Atentie ! Daca nu stricati nimic nu o sa
invatati niciodata depanarea configurarilor si, in general,
nimic...
Document GPL.
2.2. Cunostiinte necesare

- networking-concepts-HOWTO de Rusty Russell
http://netfilter.samba.org/unreliable-guides/networking-conceptsHOWTO/index.html
- Linux Networking-HOWTO (Inainte era NET-3 HOWTO) http://www.linuxports.com/howto/networking
2.3. Ce poate face Linux

O lista mica cu posibilitatile care le ofera Linux:
- Accelerarea conexiunii pentru anumite host-uri
- Accelerarea conexiunii _spre_ anumite host-uri
- Impartirea latimii de banda in mod convenabil
- Protejarea retelei de atacuri DoS
- Protejeaza Internet-ul de clienti
- Multiplexarea mai multor servere pentru balansarea
conexiunii si diponibilitate ridicata
- Restrictionarea accesului la host-uri
- Limitarea accesului utilizatorilor catre alte host-uri
- Rutarea in functie de id-ul utilizatorului, adresa MAC,
adresa IP sursa, port, tipul serviciului, perioada zilei sau
continut
In acest moment, putini folosesc aceste caracteristici din
cateva motive. Cu toate ca documentatia oferita este stufoasa nu
prea este orientata pe practica. Controlul traficului aproape ca
nu este documentat.
2.4. Note de intretinere

Do re Mi
2.5. Acces, CVS si subscrierea actualizarilor

www.ds9a.nl/lartc
2.6. Lista de mail

http://mailman.ds9a.nl/mailman/listinfo/lartc
2.7. Formatul acestui document

Rutarea si filtrarea sunt doua lucruri distincte.
Filtrarea este documentata in HOWTO-ul lui Rusty disponibil la
adresa urmatoare:
Rusty's Remarkably Unreliable Guides:
http://netfilter.samba.org/unreliable-guides/
Ne vom concentra asupra posibilitatilor oferite de
combinarea instrumentelor netfilter si iproute2.
3. INTRODUCERE - IPROUTE2
3.1. De ce iproute2 ?
In acest moment majoritatea distributiilor Linux si
majoritate Unix-urilor folosesc venerabilele comenzi arp,
ifconfig si route. Desi aceste instrumente sunt viabile, in
versiunile Linux 2.2 si mai avansate, functioneaza intr-un mod
neasteptat. De exemplu, tunelele GRE fac parte din procesul de
rutare dar necesita instrumente diferite.
Cu iproute2, tunelele sunt integrate in setul de
instrumente.
Kernel-urile 2.2 si mai avansate includ un subsistem de
retea complet refacut. Codul nou de retea aduce o performanta si
functionalitate Linuxului putin comparabila cu alte produse. De
fapt, noul cod pentru rutare, filtrare si clasificare este mult
mai complex decat cel oferit de rutere dedicate, firewall-uri si
produse pentre modelare a traficului.
Odata cu aparitia unor noi concepte de retea, au aparut si
metode de aplicare a acestora pe infrastructura existenta in
sistemele de operare. Aceasta stratificare constanta a dus la
aparitia codurilor de retea cu comportare ciudata, fenomen
intalnit si in limbile vorbite. In trecut, Linux simula, aproape
in intregime, subsistemul de retea SunOS, care nu era ideal.
Aceasta infrastructura noua ofera posibilitati care nu
existau in versiunile anterioare.
3.2. Tur iproute2

Linux are un sistem sofisticat pentru administrarea
latimii de banda numit Traffic Control. Acest sistem suporta
diverse metode pentru clasificare, prioritizare, impartire si

limitare a traficului de intrare/iesire.
Prima si prima data vom explora posibilitatile iproute2.
3.3. Chestii necesare

Pachetul iproute2 poate fi gasit la adresa:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz
Unele functii din iproute2 au nevoie de activarea anumitor
parametri din kernel. Toate optiunile pentru controlul traficului
in seria de kernel-uri pana la 6.2. inclusiv, nu sunt activate in
mod prestabilit.
Este necesara activarea suportului pentru netlink in cazul
recompilarii kernel-ului.
3.4. Explorarea configuratiei curente

Poate va fi o surpriza, dar iproute2 este deja configurat.
Comenzile curente ifconfig si route folosesc deja cererile de
sistem (syscalls) avansate, dar in mare parte cu setarile (foarte
plictisitoare) prestabilite.
Instrumentul central este ip. In cele ce urmeaza vom afisa
lista interfetelor:
3.4.1. Cum vedem link-urile

[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc
pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc
pfifo_fast qlen 10
link/ppp
Informatiile afisate sunt diferite la voi, dar asta apare

pe ruterul meu NAT de acasa. Voi explica numai o parte din
rezultate deoarece nu totul este relevant in acest moment.
Prima data vedem interfata loopback. Desi calculatorul dv.
poate functiona si fara ea, va sfatuiesc sa o lasati activata.
Dimensiunea MTU (Maximum Transfer Unit) este de 3924 octeti si nu
trebuie sa stea intr-un queue (coada de asteptare). Chestie
logica, de altfel, interfata loopback exista doar in "imaginatia"
kernel-ului.
Nu vom discuta despre interfata dummy, care poate lipsi
fara nici o problema. Mai sunt doua interfete fizice, una la care
se conecteaza modemul meu prin cablu si cealalta care serveste
segmentul meu ethernet de acasa. De asemeni mai apare si
interfata ppp0.
Remarcati absenta adreselor IP - iproute a evoluat de la
idea de link si adresa IP. Cu IP aliasing, conceptul de adresa IP
a devenit, cumva, irelevant.
Totusi este afisata adresa MAC, identificatorul fizic
interfetelor ethernet.
3.4.2. Cum vedem adresele ip

[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc
pfifo_fast qlen 10
link/ppp
inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0
In acest caz este afisata mai mult informatie. Putem vedea
adresele si caror interfete sunt asociate. 'inet' inseamna
Internet (IPv4). Sunt si alte familii de adrese, dar momentan nu
ne intereseaza.
Sa examinam interfata eth0 mai in detaliu. Este asociata

cu adresa inet 10.0.0.1/8. Ce inseamna asta? /8 reprezinta
numarul de biti pe care este adresa de retea. In total sunt 32
biti, deci raman 24 biti pentru host-urile din retea. Primii 8
biti corespund la 10.0.0.0, adresa de retea si masca de retea
este 255.0.0.0.
Ceilalti biti sunt conectati la interfata, deci adresa
10.259.3.13 este disponibila direct pe interfata eth0 ca si
10.0.0.1.
Cu ppp0, se aplica acelasi lucru, desi numerele sunt
diferite. Adresa interfetei este 212.64.94.251 fara o masca de
retea. Asta inseamna ca avem o conexiune punct-la-punct si
fiecare adresa, cu exceptia 212.64.94.251, este remote (la
distanta). Mai aflam ca la capatul celalalt al liniei se mai afla
tot o adresa IP 212.64.94.1 /32 specifica ca nu exista biti de
retea.
Observati si 'qdisc', care inseamna Queueing Discipline
(regula de asteptare). Va fi foarte important mai tarziu.
Este foarte important sa intelegeti lucrurile explicate
aici. Pentru mai multe detalii studiati documentatia de la
inceputul acestui HOWTO.
3.4.3. Cum vedem rutele

Pana acum stim sa gasim adresele 10.x.y.z si avem
conexiune cu 212.64.94.1. Totusi nu este destul. Avem nevoie sa
ajungem in Internet. Internet-ul este disponibil prin conexiunea
ppp si se pare ca 212.64.94.1 poate ruta pachetele noastre si
trimite rezultatele inapoi.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Rezultatul afisat este destul de evident. Primele patru
linii afiseaza informatii cunoscute de ip address show, iar
ultima linie ne spune ca Internet-ul este disponibil via
212.64.94.1, gateway-ul prestabilit. Ne dam seama ca este un
gateway datorita cuvantului 'via', care spune ca pachetele
trebuie trimise la 212.64.94.1 ca sa fie rutate spre Internet.
Pentru referinta, putem vizualiza tabela de rutare
folosind utilitarul route:
[ahu@home ahu]$ route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
212.64.94.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.64.94.1 0.0.0.0 UG 0 0 0 ppp0
3.5. ARP
ARP inseamna Address Resolution Protocol descris in RFC
826 (http://www.faqs.org/rfcs/rfc826.html). ARP este utilizat de
o masina conectata la retea pentru rezolvarea adresei/locatiei
hardware a unei alte masini in aceeasi retea locala. Aceasta este
metoda prin care o masina din reteaua foo.com poate comunica cu o
alta masina care este in reteaua bar.net. Totusi, o adresa ip nu
poate identifica si locatia unui masini. De acest lucru se ocupa
ARP.
Sa luam un exemplu simplu. Presupun ca am o retea formata
din cateva calculatoare. Doua din ele, in reteaua mea, sunt foo
cu adresa 10.0.0.1 si bar cu adresa 10.0.0.2. Foo da ping pe bar
sa verifice daca este pornit, dar foo nu are nici cea mai mica
idee unde este bar. Cand foo incearca sa dea ping pe bar va
trimite un ARP request (cerere ARP). Aceasta ARP request este
similar unui strigat al lui foo pe retea: "Bar(10.0.0.2), ceara
ma-ti! Unde esti?" Fiecare masina de pe retea va auzi request-ul
ARP. Doar bar (10.0.0.2) va raspunde. Bar va trimie un ARP reply
(raspuns ARP) inapoi la foo care contine adresa
ceruta:"Foo(10.0.0.1.)...Puiule...Sunt la 00:60:94:e9:12". Dupa
aceasta tranzactie simpla care a permis localizarea prietenului
sau in retea, foo poate comunica cu bar pana cand va uita (cand
intrarea asociata cu bar va fi stearsa din cache-ul arp) unde
este bar (de obicei 15 minute in Unix).
Pentru a vedea tabela arp a vecinilor:
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Dupa cum vedeti statia mea espa041 (9.3.76.41) stie cum sa
gaseasca espa042 (9.3.76.42) si espagate (9.3.76.1). Sa mai
adaugam o masina in cache-ul arp.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84)

bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms
--- espa043.austin.ibm.com ping statistics --1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
In urma incercarii de conectare espa-41 la espa043,
adresa/locatia hardware espa043 a fost adaugata la tabelul arp.
Pana cand intrarea pentru espa043 expira (daca cele doua masini
nu comunica) espa041 stie unde poate gasi espa043 si nu trebuie
sa mai trimita request-uri ARP.
Acum vom sterge espa043 din cache-ul arp:
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev
eth0
9.3.76.43 dev eth0 nud failed
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale
Acum espa041 a uitat din nou unde se afla espa043 si va
trebui sa trimita un nou request ARP data viitoare cand trebuie
sa comunice cu espa043. De asemeni, puteti vedea ca espagate
(9.3.76.1) si-a schimbat starea la 'stale'. Asta inseamna ca
locatia afisata este inca valida dar va trebui confirmata la
prima tranzactie catre acea masina.
4. REGULI - BAZA DE DATE CU POLITICILE DE RUTARE

Daca aveti un ruter mai complex, puteti satisface cerinte
pentru clienti diferiti, ce trebuie serviti diferit. Baza de date
cu politicile de rutare permite acest lucru prin folosirea mai
multor tabele de rutare.
Pentru a putea folosi aceasta functie, in kernel trebuie
activate la compilare optiunile "IP: advanced router" si "IP:
policy features".
Cand kernel-ul trebuie sa ia o decizie de rutare afla
conform carui tabel va face acest lucru. Prestabilit sunt trei
tabele. Utilitarul mai vechi, route, modifica tabelele main si

local exact ca si ip (prestabilit).
Regulile prestabilite:
[ahu@home ahu]$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Aceasta comanda afiseaza prioritatea tuturor regulilor.
Observam ca toate regulile se aplica la toate pachetele ('from
all'). Tabela main am mai vazut-o cu ip route ls, dar 'local' si
'default' sunt noi.
Pentru a genera configuratii usor de administrat se
folosesc reguli care indica mai multe tabele permitand incalcarea
regulilor de rutare existente.
Pentru semantica exacta privind comportarea kernel-ului
cand mai multe reguli se potrivesc, detalii in documentatia ipcref a lu' Alexey.
4.1. Politica de rutare simple source (sursa simpla)

Sa mai luam un exemplu simplu. Am doua modemuri pe cablu
conectate la un ruter Linux NAT. Clientii ma platesc ca sa poata
folosi Internet-ul. Sa presupunem ca unul din ei intra numai pe
hotmail si vrea sa plateasca mai putin. Pe mine nu ma deranjeaza
dar el va folosi modemul low-end.
Modemul rapid are adresa IP 212.64.94.251 cu o legatura
punct-la-punct cu 212.64.94.1. Modemul mai lent are mai multe
adrese IP, in acest caz 212.64.78.148 si este conectat cu
195.96.98.253.
Tabela locala:
[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo proto kernel scope link src
127.0.0.1
local 10.0.0.1 dev eth0 proto kernel scope host src 10.0.0.1
broadcast 10.0.0.0 dev eth0 proto kernel scope link src 10.0.0.1
local 212.64.94.251 dev ppp0 proto kernel scope host src
212.64.94.251
broadcast 10.255.255.255 dev eth0 proto kernel scope link src
10.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 212.64.78.148 dev ppp2 proto kernel scope host src
212.64.78.148
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1

local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Mai multe lucruri evidente, lucruri care trebuie sa apara
undeva. Uite ca apar aici. Tabela default este goala.
Tabela main:
[ahu@home ahu]$ ip route list table main
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Vom crea acum o regula noua pe care o vom numi 'Ion',
clientul care intra pe hotmail. Desi se poate lucra cu numere
este mult mai usor daca adaugam tabelele proprii in
/etc/iproute2/rt_tables.
# echo 200 Ion >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table Ion
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup Ion
32766: from all lookup main
32767: from all lookup default
Ce mai ramane de facut? Trebuie generata tabela lui Ion si
sters cache-ul cu rute:
# ip route add default via 195.96.98.253 dev ppp2 table Ion
# ip route flush cache
Am terminat. Implementarea in ip-up ramane ca exercitiu
pentru cititor.
4.2. Rutare pentru mai multi provideri

O configuratie des intalnita este aceea cand reteaua
locala (sau o singura masina) se conecteaza la Internet prin doi
provideri.
____
+------------+
|
|
/
/
+---------------+ Provider 1
|
|
|
+------+------+
+------------+
|
if1
|
/
\
|
|
| Retea locala -----+ Ruter Linux |
Internet
\_
__/
|
|
\__
__/
|
if2
|
\__/
+------+------+
+------------+
|
|
|
+---------------+ Provider 2
|
|
+------------+
__
__/ \__
_/
\__
+---------|
|
|
|
|
|
|
|
|
|
+---------|
\
\_____
De obicei sunt doua intrebari in ce priveste aceast tip de

configuratie.
4.2.1. Split Access (acces impartit)

Prima tine de modul in care sunt rutate raspunsurile la
pachetele care vin de la un provider, de exemplu Provider 1,
inapoi la acelasi provider.
Sa folosim niste nume simbolice. $IF1 va fi prima
interfata (if1 in opera de arta de mai sus) si $IF2 a doua
interfata. $IP1 va fi adresa IP asociata interfetei $IF1 si $IP2
celei de a doua. In continuare, $P1 va fi adresa de gateway
pentru Provider 1 si $P2 adresa Provider 2. In sfarsit, $P1_NET
va fi adresa retelei in care este $P1 si $P2_NET adresa retelei
in care este $P2.
Vom crea doua tabele de rutare aditionale, de exemplu T1
si T2 care vor fi adaugate in /etc/iproute2/rt_tables dupa care
va fi setata rutarea in aceste tabele astfel:
ip
ip
ip
ip
route
route
route
route
add
add
add
add
$P1_NET
default
$P2_NET
default
dev
via
dev
via
$IF1 src $IP1 table T1

$P1 table T1
$IF2 src $IP2 table T2
$P2 table T2
Nimic spectaculos, doar constructia unei rute spre gateway

si a unei rute prestabilite (default) via gateway-ul respectiv
similar cazului in care accesul s-ar face printr-un singur
provider, doar ca rutele se pun in tabele separate. Remarcati ca
ruta spre retea e de ajuns, permitand gasirea oricarui host din

acea retea, inclusiv gateway-ul dupa cum este specificat mai sus.
In continuare trebuie configurata tabela main (principala)
de rutare. Ca idee e bine sa se faca rutarea catre un vecin
conectat direct. Remarcati argumentele 'src', care asigura ca
adresa IP de iesire este corect aleasa.
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
Ruta prestabilita:
ip route add default via $P1
In continuare sunt configurate regulile care aleg tabela
de rutare potrivita. Vrem sa fim siguri ca rutarea se face pe o
_anumita_ interfata pentru adresa IP corespunzatoare.
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
Acest set de comenzi configureaza procesul de rutare
astfel incat raspunsurile la traficul de intrare pe o anumita
interfata se vor face tot pe aceeasi interfata.
Aceasta configuratie este de baza - va functiona pentru
toate procesele care ruleaza pe ruter si pe reteaua locala daca
se foloseste masquerade (mascaradare). Daca nu, atunci inseamna
ca avem adrese IP reale de la ambii provideri sau mascquerade-ul
se face catre unul din cei doi provideri. In ambele cazuri s-ar
putea adauga reguli care sa specifice ce/cum/cat sa se ruteze in
functie de adresa IP a unei statii din reteaua locala.
4.2.2. Load balancing (balansarea conexiunii)

A doua intrebare se refera la load balancing-ul
(balansarea traficului) intre cei doi provideri. Nu e chiar asa
de greu daca am configurat split access (acces impartit) ca in
subcapitolul anterioar.
In loc de configurarea rutei prestabilite pentru un anumit
provider, o vom seta ca ruta multipath (multicale). In kernel-ul
nerecompilat rutele vor fi balansate intre cei doi provideri. Se
face cam ashea (pe baza schemei din sectiunea precedenta):
#ip route add default scope global nexthop via $P1 dev $IF1
weight 1 nexthop via $P2 dev $IF2 weight 1
Parametrii 'weight' specifica daca conexiunea prin unul

dintre provideri este preferata celuilalt provider.
De remarcat ca balansarea nu va fi perfecta, fiind bazata
pe rute, si rutele sunt pastrate in cache. Acest lucru inseamna
ca rutele folosite mai des vor fi intotdeauna catre providerul
preferat.
Mai mult, daca chiar vreti sa incercati acest lucru, va
recomand patch-urile lui Julian Anastasov la adresa:
http://www.linuxvirtualserver.org/~julian/#routes
(http://www.linuxvirtualserver.org/~julian/#routes). Va fi mai
eficient suportata acest tip de configuratie.
5. GRE SI TUNELE
Exista trei tipuri de tunele in Linux. Tunele IP in IP,
tunele GRE si tunele care nu sunt incluse in kernel (de exemplu
PPTP).
5.1. Cateva notiuni despre tunele

Tunelele pot fi folosite pentru realizarea unor chestii
neobisnuite si foarte misto. De asemeni pot face aceste chestii
sa se comporte foarte nasol daca nu sunt configurate cum trebuie.
Nu configurati ruta prestabilita spre un tunel decat daca stiti
_exact_ ce faceti. Mai mult, tunelurile creaza trafic excesiv
deoarece mai au nevoie de un set de antete IP. In mod normal asta
inseamna 20 octeti per pachet, deci daca dimensiunea maxima a
unui pachet (MTU - Maximum Trasfer Unit) intr-o retea este de
1500 octeti, un pachet printr-un tunel poate avea maximum 1480
octeti. De obicei acest lucru nu este o problema, dar aveti grija
sa cititi despre fragmentarea/reansamblarea pachetelor daca veti
conecta retele mari cu tunele. Si, bineinteles, metoda cea mai
rapida este sa sapi la ambele capete ale tunelului.
5.2. Tunele IP-IP

Acest tip de tunele este de mult timp disponibil in Linux.
Avem nevoie de doua module pentru kernel ipip.o si new_tunnel.o.
Sa spunem ca avem trei retele: retelele interne A si B si

reteau intermediara C (sau Internet).
Reteaua A:
adresa de retea 10.0.1.0
netmask 255.255.255.0
ruter 10.0.1.1.
Ruterul are adresa 172.16.17.18 in reteaua C.
Reteaua B:
netmask 255.255.255.0
ruter 10.0.2.1
Ruterul are adresa 172.19.20.21 in reteaua C.
In ce priveste reteaua C presupunem ca va transporta orice
pachet de la A catre B si invers. Reteau C poate fi si Internetul.
Cum facem acest lucru?
Prima data trebuie sa avem modulele necesare in kernel:
#insmod ipip.o
#insmod new_tunnel.o
Apoi, pe ruterul din reteaua A:
#ifconfig tunl0 10.0.1.1. pointopoint 172.19.20.21
#route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
Si pe ruterul din reteaua B:
#ifconfig tunl0 10.0.2.1. pointopoint 172.16.17.18
#route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0
Pentru dezactivarea tunelului:
#ifconfig tunl0 down
No iaca e gata. Totusi printr-un tunel nu poate fi
transportat trafic broadcast (difuzare) sau trafic IPv6. Pot fi
conectate doua retele IPv4 care, in mod normal, nu ar putea fi
conectate - mai mult nu. In ce priveste compatibilitatea, codul
pentru incapsulare IP in IP exista de mult timp fiind compatibil
pana la seria de kernel-uri 1.3. Tunelurile IP-in-IP Linux nu

functioneaza cu alte sisteme de operare sau rutere dedicate, din
cate stiu io. E simplu si functioneaza. Folositi acest tip de
tunel daca aveti nevoie, daca nu alegeti GRE.
5.3. Tunele GRE

GRE este un protocol de tunneling (tunelare) dezvoltat la
origini de Cisco si poate face cateva chestii in plus fata de IPin-IP. De exemplu poate transporta trafic multicast (difuzare pe
grupuri) si IPv6.
In linux este necesar modulul ip_gre.o.
5.3.1. Tunel IPv4

Sa realizam un tunel IPv4. Avem trei retele: retelele
interne A,B si reteaua intermediara C (poate fi Internet).
Reteaua A:
netmask 255.255.255.0
ruter 10.0.1.1.
Ruterul are adresa 172.16.17.18 in reteaua C. Sa numim
aceasta retea neta (cata originalitate).
Reteaua B:
netmask 255.255.255.0
ruter 10.0.2.1
Ruterul are adresa 172.19.20.21 in reteaua C. Aceasta
retea o vom numi netb (mdea...).
In ce priveste reteaua C presupunem ca va transporta orice
pachet de la A la B si invers. Cum si de ce, nu ne intereseaza.
Pe ruterul din reteaua A:
#ip tunnel add netb mode gre remote 172.19.20.21 local
172.16.17.18 ttl 255
#ip link set netb up
#ip addr add 10.0.1.1 dev netb
#ip route add 10.0.2.0/24 dev netb
Sa discutam un pic despre ce apare aici. In linia 1 am

adaugat un tunnel device (dispozitiv tunel) si l-am numit netb
(evident). In continuare am specificat ca protocolul utilizat va
fi GRE ('mode gre'), adresa de la celalalt capat al tunelului va
fi 172.19.20.21 (interfata de pe ruter). Pachetele care intra in
tunel origineaza in 172.16.17.18 (lucru care permite mai multe
adrese IP in reteaua C utilizarea uneia dintre ele pentru tunel
ramanand la latitudinea noastra). Campul TTL este configurat la
255 (ttl 255).
A doua linie activeaza tunelul.
A treia linie asociaza dispozitivului tunel netb adresa
10.0.1.1 Pentru retele mici nu ar trebui sa fie o problema dar
daca intentionati sa realizati o exploatare miniera (multe
tunele) luati in calcul folosirea unui spatiu de adrese IP mai
mare (in acest exemplu am putea folosi 10.0.3.0).
A patra linie ruteaza pachetele pentru reteaua B prin
dispozitivul netb proaspat configurat. Remarcati notarea diferita
a netmask-ului. Daca nu va este familiara aceasta notatie, aveti
aici cateva explicatii: scrieti netmask-ul in format binar si
numarati cifrele 1. Daca nu stiti sa faceti acest lucru tineti
minte ca 255.0.0.0 este /8, 255.255.0.0 este /16 si 255.255.255.0
este /24. A, 255.255.254.0 este /23 pentru curiosi.
Pentru ruterul B:
#ip tunnel add neta mode gre remote 172.16.17.18 local
172.19.20.21 ttl 255
#ip link set neta up
#ip addr add 10.0.2.1 dev neta
#ip route add 10.0.1.0/24 dev neta
Pentru dezactivarea tunelului pentru ruterul A:
#ip link set netb down
#ip tunnel del netb
Analogie pentru ruterul B.
5.3.2. Tunel IPv6

Pentru referinta in sectiunea 6 sunt descrise adresele
IPv6.
Sa presupunem ca aveti urmatoare retea IPv6 si vreti sa o
conectati la 6bone sau la un prieten.
retea 3ffe:406:5:1:5:a:2:1/96
Adresa noastra IPv4 este 172.16.17.18 si ruterul 6bone are
adresa IPv4 172.22.23.24.
#ip tunnel add sixbone mode sit remote 172.22.23.24 local
172.16.7.18 ttl 255
#ip link set sixbone up
#ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
#ip route add 3ffe::/15 dev sixbone
Sa discutam aceasta configuratie (gyeah!). In prima linie
am creat un tunnel device (dispozitiv tunel) pe care l-am numit
sixbone. L-am pus in modul 'sit' (asta inseamna incapsulare IPv6
in IPv4) si i-am specificat adresa locala (local) si adresa de la
celalalt capat (remote). TTL este setat la maximum - 255. In
continuare am activat device-ul. Apoi am adaugat adresa IPv6 a
retelei noastre si am pus ruta pentru 3ffe::/15 (singura retea in
6bone)prin tunel.
In acest moment tunelele GRE sunt un standard acceptat si
in afara comunitatii Linux asa ca este metoda preferata si
recomandata de tunelare.
5.4. Tunele din Tara lui Papura Voda (userland)

Daca stau sa ma gandesc sunt o gasca de implementari
pentru tunele, neincluse in kernel. Cele mai cunoscute sunt,
bineinteles, PPP si PPTP dar sunt multe altele (unele
proprietare, unele sigure, unele care nici macar nu folosesc IP)
si acest lucru depaseste cu mult scopul acestui HOWTO.
6. TUNELE IPv6 CU CISCO SI/SAU 6BONE

Nota:
Tunneling-ul (tunelarea) IPv6-in-IPv4 nu este prin
definitie GRE. Pot fi create tunele IPv6-in-IPv4 prin tunneling
device-urile GRE (GRE baga _orice_ prin IPv4), dar device-ul
utilizat aici ('sit') incapsuleaza doar IPv6 in IPv4 - un caz
particular.
6.1. Tunele IPv6

Mai exista si o alta aplicatie a capabilitatilor de
tunneling pe care le ofera Linux. Este foarte populara printre
utilizatorii IPv6 de la inceput sau pionerii. Exemplul practic de
mai jos nu este singura metoda de folosire a tunelurilor IPv6.
Totusi, este o metoda des intalnita pentru realizarea de tuneluri
intre Linux si un ruter Cisco care suporta IPv6. Din experienta
este unul dintre cele mai intalnite utilizari. Pariez pe basca
mea ca acest lucru se aplica si tie ;-)
Cateva chestiuni legate de adresele IPv6. Adresele IPv6,
comparate cu IPv4, sunt foarte mari: 128 biti vs 32 biti. Acest
lucru ne ofera lucrul de care avem nevoie: multe adrese IP mandre
si cornute. Mai exact
340.282.266.920.938.463.463.374.607.431.768.211.465. In afara de
asta, IPv6 (sau IPng - IP Next Generation) presupune reducerea
tabelelor de rutare pe ruterele din backbone-ul Internet-ului,
configurari mai simple a echipamentelor, securitate mai buna la
nivelul IP si suport mai bun pentru QoS (Quality of Service Calitatea Serviciului).
Exemplu: 2002:836b:9820:0000:0000:0000:836b:9886
Scrierea adreselor IPv6 este nasoala rau. Ca sa usuram
acest lucru s-au stabilit cateva reguli:
- nu utilizam zerourile din fata (exact ca in IPv4)
- se folosesc ':' pentru separarea campurilor de 16 biti
sau doi octeti
- daca exista mai multe zerouri consecutive se poate scrie
'::'. Acest lucru poate fi folosit o singura data
intr-o
adresa si doar pentru dimensiuni de 16 biti.
Adresa 2002:836b:9820:0000:0000:0000:836b:9886 poate fi
scrisa ca
2002:836b:9820::836b:9886, un format ceva mai aerisit.
Adresa 3ffe:0000:0000:0000:0000:0020:34A1:F32C poate fi
scrisa ca
3ffe::20:34A1:F32C mult mai scurt decat originalul.
IPv6 a fost gandit ca succesor al lui IPv4. Datorita
faptului ca este o tehnologie relativ recenta nu exista inca o
retea globala nativa IPv6. Pentru a realiza aceasta trecere mai
usor a fost introdus 6bone.
Retelele native IPv6 sunt conectate prin incapsularea
protocolului IPv6 in pachete IPv4 si transportarea lor prin
infrastructura Ipv4 existenta de la o locatie IPv6 la alta.
In acest moment intervin tunelurile.

Pentru a putea folosi IPv6, trebuie sa avem un kernel care
il suporta. Sunt o multime de documentatii klumea despre cum
poate fi facut acest lucru. Practic, totul se reduce la cateva
chestii de baza:
- faceti rost de o distributie recenta Linux cu glibc
- reactualizati sursele kernel-ului
Dupa asta recompilati kernel-ul cu suport IPv6:
- cd /usr/src/linux
- make menuconfig
- alegeti "Networking Options"
- alegeti "The IPv6 protocol","IPv6: enable EUI-64 token
format", "IPv6: disable provider based addresses"
Nu-l compilati ca modul ca de obicei nu prea merge bine.
Cu alte cuvinte compilati IPv6 in kernel (built-in)
salvati fisierul de configurare si compilati kernel-ul.
Inainte de asta editati fisierul Makefile: EXTRAVERSION=-x
in EXTRAVERSION=-x-IPv6.
Exista multa documentatie valabila despre compilarea si
instalarea kernel-ului, totusi acest document este despre cu
totul altceva. Daca aveti probleme in acest moment, cautati
documentatie despre compilarea kernel-ului in functie de
specificatiile personale.
Fisierul /usr/src/linux/README ar fi un bun inceput. Dupa
asta reporniti sistemul cu noul kernel. Incercati '/sbin/ifconfig
-a' si observati dispozitivul nou 'sit0-device'. SIT inseamna
Simple Internet Transition. Puteti sa va faceti un compliment;
sunteti cu un pas mai aproape de IP Next Generation.
Sa trecem la pasul urmator. Vreti sa va conectati statia
proprie sau chiar reteaua locala la alta retea IPv6. Aceasta ar
putea fi 6bone configurata special pentru asa ceva.
Sa presupunem ca aveti urmatoarea retea IPv6:
3ffe:604:6:8::/64 si vreti sa o conectati la 6bone sau la un
prieten. Remarcati ca notarea /64 pentru subretele functioneaza
exact ca in cadrul adreselor IPv4 obisnuite.
Adresa noastra IPv4 este 145.100.24.181 si ruterul 6bone
are adresa 145.100.1.5:
# ip tunnel add sixbone mode sit remote 145.100.1.5 [local
145.100.24.181 ttl 255]
# ip link set sixbone up
# ip addr add 3FFE:604:6:7::2/126 dev sixbone
# ip route add 3ffe::0/16 dev sixbone
Sa discutam aceasta configuratie. In prima linie am creat
un tunnel device care se cheama sixbone. L-am pus in modul 'sit'
(incapsulare IPv6-in-IPv4) si am specificat destinatia remote
(celalalt capat) si adresa locala (local). TTL este setat la

maximum, 255.
In continuare am activat tunelul ('up'). Apoi am adaugat
adresa de retea proprie si am adaugat o ruta pentru 3ffe::/15
(tot 6bone in acest moment) prin tunel. Daca masina pe care ati
configurat acest lucru este si gateway-ul IPv6 atunci:
#echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
#/usr/local/sbin/radvd
In ultima linie, radvd este - ca si zebra - un demon de
advertisement (anuntare), pentru suportul capabilitatilor de
autoconfigurare IPv6. Puteti sa gasiti mai multe informatii cu un
motor de cautare. Puteti verifica configuratia astfel:
#/sbin/ip -f inet6 addr
Daca rulati radvd pe gateway-ul vostru IPv6 si folositi un
kernel cu suport IPv6 pe o masina din reteaua locala va puteti
bucura de functiile de autoconfigurare din IPv6:
$/sbin/ip -f inet6 addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue inet6 ::1/128 scope
host
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen
100
inet6 3ffe:604:6:8:5054:4cff:fe01:e3d6/64 scope global dynamic
valid_lft forever preferred_lft 604646sec inet6
fe80::5054:4cff:fe01:e3d6/10 scope link
Puteti sa configurati si un server de nume pentru adrese
IPv6. Tipul de inregistrare A are un echivalent pentru IPv6:
AAAA. In loc de in-addr.arpa folositi ip6.int. Sunt o multime de
informatii despre acest subiect.
Exista un numar din ce in ce mai mare de aplicatiii ce
suporta IPv6, inclusiv ssh, telnet, inetd, Mozilla, server-ul web
Apache si multe altele. Toate acestea nu fac parte din acest
document despre rutare;-)
Pe un ruter Cisco configuratia arata in modul urmator:
!
interface Tunnel1
description IPv6 tunnel
no ip address
no ip directed-broadcast
ipv6 address 3FFE:604:6:7::1/126
tunnel source Serial0

tunnel destination 145.100.24.181
tunnel mode ipv6ip
!
ipv6 route 3FFE:604:6:8::/64 Tunnel1
Daca nu aveti un ruter Cisco puteti incerca unul agentii
IPv6 disponibili pe Internet. Pot sa-si configureze ruterul lor
Cisco cu un tunel pentru voi. De obicei prin intermediul unei
interfete web prietenoase. Folositi un motor de cautare - "ipv6
tunnel broker".
7. IPSEC: IP SIGUR IN INTERNET

In acest moment exista doua tipuri de IPSEC disponibile in
Linux. Pentru 2.2 si 2.4 este FreeS/WAN care a fost prima
implementare majora. Site-ul lor oficial este
http://www.freeswan.org si cel neoficial si neintretinut
http://www.freeswan.ca. FreeS/WAN nu a fost inclus in kernel din
cateva motive. Cele mai des mentionate sunt cele 'politice'
privind americanii care lucreaza la crypto si patandu-i
(tainting) exportabilitatea. De altfel, nu se integreaza bine in
kernel ceea ce il face un candidat slab.
In plus multi
(http://www.edlug.ed.ac.uk/archive/Sep2002/msg00244.html) au
avertizat
(http://lists.freeswan.org/pipermail/design/2002November/003901.html) in legatura cu calitatea codului. Pentru
configurarea FreeS/WAN gasiti documentatie la:
http://www.freeswan.ca/code/old/freeswan-Snapshot/doc/index.html.
Odata cu Linux 2.5.47 exista o implementare nativa IPSEC
in kernel. A fost scrisa de Alexey Kuznetsov si Dave Miller,
inspirata din activitatea grupului IPv6 USAGI. Odata cu aceasta
implementare, CryptoAPI (James Morris) a fost inclus in kernel pachet care realizeaza criptarea propriu-zisa.
Acest HOWTO va prezenta doar versiunea 2.5+ IPSEC.
FreeS/WAN este recomandata utilizatorilor Linux 2.4, dar trebuie
stiut faptul ca difera de configuratia din IPSEC nativ.
In ce priveste 2.5.49, IPSEC functioneaza fara patch-uri.
Nota: Am adunat patch-uri pentru 2.5.48 realizate de
Alexey sau Dave Miller - http://ds9a.nl/ipsec. Va rog sa le
aplicati pe toate inainte de a carai si a raporta probleme
(deocamdata nu exista pentru 2.5.49). Utilitare puteti gasi

acilea:
ftp://ftp.inr.ac.ru/ip-routing/iputils-ss021109-try.tar.bz2;
binare precompilate & pagini
man:http://ds9a.nl/ipsec/setkey.tar.gz. Compilarea acestor
utilitare necesita editarea fisierelor Makefile pentru
specificarea kernel-ului 2.5.x. Aceasta situatie va fi remediata
in cel mai scurt timp. Cand compilati kernel-ul activati
"PF_KEY", "AH","ESP" si tot ce este in CryptoAPI! In acest moment
TCP_MSS nu merge si trebuie dezactivat.
Atentie! Autorul acestui capitol este un ignorant in ce
priveste IPSEC! Raportati greselile lui Bert Hubert la adresa
ahu@ds9a.nl.
In primul rand vom configura o conexiune sigura intre doua
host-uri. O mare parte din acesta operatie poate fi automatizata,
dar vom face totul "de mana" ca sa intelegem ce se petrece sub
capota.
Puteti sa sariti peste urmatoarea sectiune daca ce va
intereseaza este automatic keying (semnare automata) dar
intelegerea manual keying (semnare manuala) poate fi utila.
7.1. Introducere in Manual Keying (semnare automata)

IPSEC este un subiect complicat. Multa informatie este
disponibila online, acest HOWTO va face o introducere si va
explica conceptele de baza.
Nota: Multe configuratii iptables elimina pachetele IPSEC!
Pentru a permite trecerea acestora folositi: #iptables -A xxx -p
50 -j ACCEPT si #iptables -A xxx -p 51 ACCEPT.
IPSEC ofera o versiune securizata a IP. Securitatea in
acest context inseamna doua lucruri diferite: criptare
si autentificare. O viziune naiva a securitatii ar putea fi doar
criptarea dar poate fi usor demonstrat ca nu este suficient comunicarea poate fi criptata dar nu exista nici o garantie ca la
celalalt capat este cine ar trebuie sa fie.
IPSEC suporta Encapsulated Security Payload (ESP) pentru
criptare si Authentication Header (AH) pentru autentificarea
partenerului de comunicatie. Pot fi configurate amandoua sau
numai una.
ESP ca si AH se bazeaza pe security association (asociatie
de securitate). O astfel de asociatie (SA) inseamna o sursa, o
destinatie si o instructiune. Un exemplu de autentificare SA

poate arata asa:
#add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5
"1234567890123456";
Ceea ce inseamna 'traficul de la 10.0.0.11 la 10.0.0.16
care are nevoie de AH poate fi semnat folosind HMAC-MD5 cu
secretul 1234567890123456'. Aceasta instructiune este etichetata
cu identificatorul SPI (Security Parameter Index) '15700', mai
multe mai tarziu. Chestia interesanta in ce privesta SA este
simetria. Ambele parti ale unei conexiuni folosesc acelasi SA, nu
este inversat la celalalt capat. Remarcati ca nu exista o regula
de autoinversare - acest SA descrie o posibila autentificare de
la 10.0.0.11 la 10.0.0.216. Pentru traficul in ambele sensuri
sunt necesare 2 SA.
Un exemplu de ESP SA:
#add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc
"12345678901234566789012";
Ceea ce inseamna: "traficul de 10.0.0.11 la 10.0.0.216
care trebuie criptat foloseste 3des-cbc cu cheia
1234567890123456789012". Id-ul SPI este 15701.
Pana acum am observat ca un SA descrie instructiuni
posibile, dar nu si o politica privind cum/cand vor fi folosite
aceste instructiuni. Ca fapt divers pot exista mai multe SA
aproape identice avand doar id-ul SPI diferit. Pentru criptarea
propriu-zisa trebuie sa stabilm o politica. Aceasta politica
include lucruri de genul "foloseste ipsec daca este disponibil"
sau "ignora traficul fara ipsec".
Un exemplu tipic de SP (Security Policy) arata cam asa:
#spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
esp/transport//require
ah/transport//require;
Daca aceasta configuratie a fost introdusa pe host-ul
10.0.0.216, inseamna ca tot traficul spre 10.0.0.11 trebuie
criptat si incapsulat intr-un antent de autentificare AH.
Remarcati ca nu este specificat ce SA este folosit, decizia fiind
luata de kernel.
Cu alte cuvinte, un SP inseamna _ce_ vrem; un SA inseamna
_cum_ se face.
Pachetele de iesire sun etichetate (labelled) cu un SA SPI
(cum) care este folosit de kernel pentru criptare si
autentificare astfel incat nodul de la distanta (remote) poate

gasi instructiunea de verificare si decriptare corespunzatoare.
Urmeaza o configuratie foarte simpla pentru comunicare
dintre host-ul 10.0.0.216 cu 10.0.0.11 folosind criptare si
autentificare.
Nota: Reverse Path (calea inversa) este in mod text in
aceasta versiune initiala si aceasta configuratie nu ar trebui
aplicata.
Pe host-ul 10.0.0.216:
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc
"123456789012123456789012";
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
Pe host-ul 10.0.0.11, acelasi SA, fara SP:
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc
"123456789012123456789012";
Cu aceasta configuratie (aceste fisiere pot fi executate
daca 'setkey' este instalat in /sbin), ping-ul catred 10.0.0.11
de la 10.0.0.216 arata cam asa in tcpdump:
22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa):
ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply
De remarcat ca ping-ul de 10.0.0.11 este vizibil. Ping-ul
initial nu poate fi citit de tcpdump, dar arata totusi SPI-ul AH
si ESP care spune host-ului 10.0.0.11 cum sa verifice
autenticitatea pachetelor si cum sa le decripteze.
Mai trebuie mentionate cateva lucruri. Configuratia de mai
sus este prezentata in multe exemple IPSEC si este foarte
periculoasa. Problema este ca aceasta politica se ocupa numai de
pachetele trimise de 10.0.0.216 catre 10.0.0.11 si specifica
modul in care aceste pachete sunt tratate de 10.0.0.11 dar
_accepta_ si traficulneautentificat si necriptat pe 10.0.0.11.
Oricine poate trimite pachete falsificate (spoofed) si
date necriptate iar 10.0.0.11 le va accepta. Pentru a remedia
acest lucru, trebuie sa folosim un SP de intrare pe 10.0.0.11 ca

in cele ce urmeaza:
#!/sbin/setkey -f
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
Acum traficul care vine de la 10.0.0.216 la 10.0.0.11
trebuie sa aiba ESP si AH valide.
Pentru a finaliza aceasta configuratie, vom realiza
autentificarea si criptarea si in celalalt sens. Configuratia
completa pe 10.0.0.216 este:
#!/sbin/setkey -f
flush;
spdflush;
#AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
#ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc
"123456789012123456789012";
add 10.0.0.216 10.0.0.216 esp 245001 -E 3des-cbc
"123456789012123456789012";
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
Pe 10.0.0.11:
#!/sbin/setkey -f
flush;
spdflush;
#AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
#ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc

"123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc
"123456789012123456789012";
ah/transport//require
esp/transport//require;
ah/transport//require
In acest exemplu am folosit chei identice pentru ambele
directii ale traficului. Nu e un lucru necesar...
Pentru a verifica configuratia folositi comanda 'setkey
-D', care afiseaza SA sau 'setkey -DP' care afiseaza politicile
active.
7.2. Automatic Keying (Semnare automata)

In sectiunea anterioara, criptarea a fost configurata
folosind secrete (parole) simple partajate (shared). Cu alte
cuvinte, pentru a pastra securitatea, trebuie sa ne transferam
configuratia criptata pe un canal sigur. Daca am configura un
host la distanta prin telnet, orice tert ar putea afla secretul
impartit si configuratia nu ar mai avea nici un rost.
Mai mult, secretul fiind partajat nu mai este un secret.
Host-ul de la distanta nu poate face mare lucru cu secretul
nostru, dar trebuie sa ne asiguram ca folosim un secret diferit
pentru fiecare dintre parteneri. Asta inseamna un numar mare de
chei, daca sunt 10 parteneri trebuie folosite minimum 50 de
secrete diferite.
In afara de problema cheilor simetrice, mai este necesara
inca o cheie pentru rollover (ciclare). Daca un tert reuseste sa
capteze trafic destul, ar putea afla cheia prin inginerie
inversa. Acest lucru poate fi prevenit daca se schimba cheia
periodic, proces care trebuie automatizat.
Alta problema cu semnarea manuala este ca definim un
anumit algoritm si o anumita lungime a cheilor ceea ce implica
multa coordonarea cu host-ul de la distanta. Este de dorit
utilizarea unei politici de chei mai larga cum ar fi "putem
folosi 3DES si Blowfish cu urmatoarea dimensiune minima a
cheilor".
Pentru a elimina aceste carente, IPSEC ofera Internet Key

Exchange pentru schimbarea automata a cheilor generate aleator
care sunt transmise folosind tehnologie de criptare asimetrica,
conform cu detalile algoritmului negociat.
Implementarea IPSEC in Linux 2.5 functioneaza cu demonul
Kame 'racoon' IKE. Din 9 noiembrie, versiunea racoon in
distributia iptools a lu' Alexey poate fi compilata, desi s-ar
putea sa fie nevoie ca linia '#include <net/route.h>' sa fie
eliminata in doua fisiere. O versiune precompilata gasiti la
urmatoarea adresa:
http://ds9a.nl/ipsec/racoon.bz2.
Nota: IKE foloseste portul 500 cu UDP. Vedeti sa nu-l
blocati cu iptables.
7.2.1. Teorie
Dupa cum am explicat mai sus, semnarea automata elimina
partea mai plictisitoare a configurarilor (care ar trebuie sa o
facem noi). Mai exact, creeaza SA din mers. Totusi nu stabiliste
politicile, care raman la latitudinea noastra (normal).
Deci, pentru a utiliza IKE, stabiliti o politica, dar nu
configurati nici un SA. Daca kernel-ul gaseste o politica IPSEC,
dar nu si un SA, va anunta demonul IKE, care va incerca sa
negocieze propriile SA.
Daca nu va mai aduceti aminte, un SP inseamna _ce_ dorim
iar un SA _cum_ dorim sa facem o chestie. Folosirea automatic
keying (semnare automata) ne face scapati de la configurarea a
ceea _ce_ vrem.
7.2.2. Exemplu
Kame racoon vine cu o haita mare de optiuni, majoritatea
au niste valori predefinite misto, deci nu trebuie sale mai
setam. Dupa cum am povestit mai sus, operatorul trebuie sa
defineasca un SP, dar nu si un SA.
In acest exemplu, 10.0.0.11 si 10.0.0.216 vor fi conectate
cu o legatura securizata, de aceasta data cu putin ajutor de la
racoon. Pentru simplitatea configuratiei vom folosi chei prepartajate, infioratoareale 'secrete partajate'. Certificatele
X.509 sunt discutate intr-o sectiune separata (7.2.3).
Vom incerca sa pastram cat mai mult din configuratia
prestabilita pe ambele host-uri:
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
my_identifier address;
lifetime time 2 min;
#sec, min, ora
initial_contact on;
proposal_check obey; #obey, strict sau claim
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous
{
pfs_group 1;
lifetime time 2 min;
authentication_algorithm hmac_sha1;
compression_alorithm deflate;
}
Multe setari - cred ca mai pot fi scoase cateva ca sa ne
apropiem de configuratia prestabilita. Cateva chestii care nu
prea merita atentie. Am configurat doua setari anonime pentru
toate host-urile de la distanta - configuratia in continuare
fiind aerisita. Nu e necesar sa folosim sectiuni pentru fiecare
host, decat daca sunt absolut necesare.
Mai mult, am realizat configuratia astfel incat ne vom
identifica dupa adresa noastra IP ('mu_identifier address') si am
declarat ca putem folosi algoritmii de criptare 3des, sha1. Cheia
pre-partajata va fi localizata in psk.txt.
In psk.txt, vom scrie doua lucruri, care difera pe ambele
host-uri.
Pe 10.0.0.11:
10.0.0.216 password2
Pe 10.0.0.216
10.0.0.11 password2
Aveti grija ca aceste fisiere sa fie detinute de root si
proprietatile sa fie setate la 0600 altfel racoon nu va avea
"incredere" in continutul lor. Daca nu ati observat cele doua
fisiere sunt in oglinda.
In continuare vom seta politica dorita. Simplu.
Pe 10.0.0.216:
#!/sbin/setkey -f
flush;
spdflush;
Pe 10.0.0.11:
#!/sbin/setkey -f
flush;
spdflush;
Remarcati ca politicile sunt in oglinda din nou.
Acum tot ce mai ramane de facut e sa lansam racoon. Odata
lansat, in momentul in care incercam sa ne conectam prin telnet
de la 10.0.0.11 la 10.0.0.216, sau invers, racoon va incepe
negocierea:
12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
request for 10.0.0.11 queued due to no phase1 found.
12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin
Aggressive mode.
12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor

ID: KAME/racoon
12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldnt find
the proper pskey, try to get one by the peers address.
12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
established 10.0.0.216[500]-10.0.0.11[500]
spi:044d25dede78a4d1:ff01e5b4804f0680
12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new
phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA
established: ESP/Transport 10.0.0.11->10.0.0.216
spi=44556347(0x2a7e03b)
12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)
Pentru a vedea SA folosim 'setkey -D' si voila: sunt
acolo:
10.0.0.216 10.0.0.11
esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)
E: 3des-cbc 5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
A: hmac-sha1 c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002
diff: 31(s) hard: 600(s) soft: 480(s)
last: Nov 11 12:29:12 2002 hard: 0(s) soft: 0(s)
current: 304(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 3 hard: 0 soft: 0
sadb_seq=1 pid=17112 refcnt=0
10.0.0.11 10.0.0.216
esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)
E: 3des-cbc d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
A: hmac-sha1 41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002
diff: 31(s) hard: 600(s) soft: 480(s)
last: hard: 0(s) soft: 0(s)
current: 231(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 2 hard: 0 soft: 0
sadb_seq=0 pid=17112 refcnt=0
La fel si SP-urile configurate:
10.0.0.11[any] 10.0.0.216[any] tcp
in ipsec
created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
lifetime:0(s) validtime:0(s)
spid=3616 seq=5 pid=17134
refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
out ipsec
created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
lifetime:0(s) validtime:0(s)
spid=3609 seq=4 pid=17134
refcnt=3
7.2.2.1. Probleme si defecte cunoscute

Daca nu functioneaza, verificati ca toate fisierele de
configurare sa fie detinute de root si sa poata fi citite numai
de root. Pentru a porni racoon interactiv folositi parametrul 'F'. Pentru specificarea unui anumit fisier de configurare, in loc
de locatia unde a fost compilat, folositi '-f'. Pentru cantitati
mari de detalii, daugati 'log debug' in racoon.conf.
7.2.3. Semnare automata cu certificate x.509

Dupa cum am mai mentionat, folosirea secretelor partajate
este dificila deoarece nu sunt usor de partajat si odata realizat
acest lucru nu mai sunt secrete. Din fericire, exista tehnologia
de criptare asimetrica care rezolva aceasta problema.
Daca fiecare participant IPSEC creeaza o cheie publica si
una privata, comunicatia poate fi setata prin distribuirea
cheilor publice si configurarea politicii.
Crearea unei chei este relativ usoara, desi trebuie oleac'
de munca. Ceea ce urmeaza se bazeaza pe intrumentul 'openssl'.
7.2.3.1. Crearea unui certificat X.509 pentru host-ul propriu

OpenSSL are o infrastructura mare pentru chei care pot sau
nu pot fi semnate de autoritatile de certificare. In acest
moment, nu trebuie sa tinem toata aceastra infrastructura si
folosim securitate veche si buna, ca la mama acasa, fara o
autoritate de certificare.
Prima data facem o cerere pentru certificat pentru host-ul
nostru, 'laptop':
#openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM

-keyout laptop.private -outform PEM -out reques.pem
In continuare vom completa un formular:
Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:Delft
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux
Advanced
Routing & Traffic Control
Organizational Unit Name (eg, section) []:laptop
Common Name (eg, YOUR name) []:bert hubert
Email Address []:ahu@ds9a.nl
Please enter the following extra attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Ramene la latitudinea voastra completarea acestor campuri.
Puteti sau nu sa scrieti nume host-ului, in functie de
necesitatile de securitate. In acest exemplu avem nevoie.
Acum vom aplica semnatura proprie pe aceasta cerere:
#openssl x509 -req -in reques.pem -signkey laptop.private -out
laptop.public
Signature ok
subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic
Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl
Getting Private key
Fisierul request.pem nu mai este necesar.
Repetati aceasta procedura pentru toate host-urile care au
nevoie de o cheie. Puteti distribui fisierul '.public' fara nici
o jena dar fisierul '.private' sa fie cum se si numeste!
7.2.3.2. Setare si lansare

Odata create cheile private si publice pentru host-urile
nostre racoon le poate folosi.
Revenim la configuratia precedenta si cele doua host-uri,
10.0.0.11 ('upstairs') si 10.0.0.216 ('laptop').
In fisierul racoon.conf pe 10.0.0.11 adaugam:
path certificate "/usr/local/etc/racoon/cers";

remote 10.0.0.216
{
exchange_mode aggressive,main;
my_identifier asn1dn;
peers_identifier asn11dn;
certificate_type x509 "upstairs.public" "upstairs.private";
peers_certificate "laptop.public";
proposal {
authentication_method rsasig;
dh_group 2;
}
}
Aceasta configuratia localizeaza certificatele in
/usr/local/etc/racoon/certs. Mai mult contine elemente specifice
pentru 10.0.0.216.
Liniile cu 'asn1dn' indica lu' racoon ca identificatorul
host-ului local cat si a celui de la distanta va fi extras din
cheile publice. Acesta este 'subject=/C=NL/L=Dlelft/O=Linux
Advanced Routing & Traffic Control/OU=laptop/CN=bert
hubert/Email=ahu@ds9a.nl' de mai sus.
Linia cu 'certificate_type' configureaza cheia publica
locala si cheia privata locala. 'peers_certfile' determina
racoon-ul sa citeasca cheia publica de la peer din fisierul
laptop.public.
'proposal' ramane la fel cu exceptia
'authentication_method' care este acum 'rsasig', indicand ca se
folosesc chei RSA pentru autentificare.
Configuratia pentru 10.0.0.216 este aproape identica, cu
oglindirea obisnuita:
path certificate "/usr/local/etc/racoon/certs";
remote 10.0.0.11
{
exchange_mode aggressive, main;
my_identifier asn
my_identifier asn1dn;
peers_identifier asn1dn;
certificate_type x509 "laptop.public" "laptop.private";
peers_certfile "upstairs.public";
proposal {
authentication_method rsasig;
dh_group 2 ;
}
}
racoon.conf fiind setat pe ambele host-uri, mai ramane
mutarea fisierelor cheie in locul lor. Masina 'upstairs' are
nevoie de upstairs.private, upstairs.public si laptop.public
in /usr/local/etc/racoon/certs iar 'laptop' are nevoie de
laptop.private, laptop.public si upstairs.public tot in
/usr/local/etc/racoon/certs. Aveti grija ca acest director sa fie
detinut de root si aiba drepturi 0600 altfel racoon nu le va
citi. Cu alte cuvinte fiecare host are nevoie de propria cheie
publica si privata si cheia publica a host-ul de la distanta.
Verificati daca SP este setat (liniile spdadd in sectiunea 7.2.2.
Lansati racoon si totul ar trebuie sa mearga.
7.2.2.3. Configurarea tunelurilor sigure

Pentru securizarea comunicatiei cu un host la distanta
trebuie schimbate cheile publice. Desi cheie publica nu trebuie
sa fie secreta este foarte important sa nu fie alterata. Altfel
spus trebuie sa fim siguri ca nu exista o entitate intermediara.
Pentru a usura acest lucru, OpenSSL ofera comanda
'digest':
#openssl dgst upstairs.public
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1
Tot ce mai ramane de facut este sa verificam ca host-ul de
la distanta are acelasi rezultat in urma acestei comenzi. Acest
lucru poate fi facut la telefon sau fata in fata cu operatorul
host-ului pentru asigurarea ca numarul nu a fost trimis prin
acelasi e-mail care continea cheia.
Alta metoda ar fi folosirea unui tert de incredere care
ruleaza o autoritate de certificare (Certificate Authority).
Acest CA va semna cheia voastra, ceea ce am facut si noi mai sus.
7.3. Tunele IPSEC

Pana acum am vazut IPSEC in asa-zisul mod 'transport' cand
ambele noduri inteleg IPSEC direct. Cum deseori acest lucru nu se
intampla, s-ar putea ca intelegerea IPSEC sa fie necesara doar

pentru rutere care sa faca treaba si pentru host-urile din
spatele lor. Acest mod se cheama 'tunnel mode'.
Configurarea este gigea. Pentru tunelarea traficului spre
130.161.0.0/16 de la 10.0.0.216 via 10.0.0.11 punem urmatoare
chestie pe 10.0.0.216:
#!/sbin/setkey -f
flush;
spdflush;
add 10.0.0.216 10.0.0.11 esp 34501
-m tunnel
-E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.0/24 130.161.0.0/16 any -P out ipsec
esp/tunnel/10.0.0.216-10.0.0.11/require;
Nota: '-m tunnel' este foarte important! Este configurata
un SA cu criptare (ESP) intre cele doua capete ale tunelului
10.0.0.216 si 10.0.0.11.
In continuare este configurat tunelul propriu-zis. Kernelul trebuie sa cripteze tot traficul rutat de la 10.0.0.0/24 la
130.161.0.0/16. Mai mult, acest trafic trebuie transportat la
10.0.0.11
#!/sbin/setkey -f
flush;
spdflush;
add 10.0.0.216 10.0.0.11 esp 34501
-m tunnel
-E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.0/24 130.161.0.0/16 any -P in ipsec
esp/tunnel/10.0.0.216-10.0.0.11/require;
Remarcati configuratiile aproape identice, exceptand
partea cu '-P out' care devine '-P in'. Ca si in exemplele de
pana acum, am configurat traficul intr-un singur sens. Realizarea
configuratiei pentru celalalt capat al tunelului ramane ca un
exercitiu pentru cititor.
O alta denumire pentru aceasta configuratie este 'proxy
ESP', care parca suna mai clar.
Nota: Functionarea tunelulelor IPSEC au nevoie de
activarea forward-arii in kernel.
7.4. Interoperarea IPSEC cu alte sisteme

De completat in versiunile urmatoare.
7.4.1. Windows
Idem 7.4
8. RUTARE MULTICAST
(difuzare pe grupuri)
Multicast-HOWTO este realizat pe vremea bunicii (relativ)

si nu poate fi complet sau in pas cu tehnologia.
Inainte de a realiza rutarea multicast (difuzare pe
grupuri), trebuie sa configurati kernel-ul cu tipul de multicast
care il veti utiliza. Exista patru tipuri mai des intalnite:
- DVMRP (versiunea de multicast a protocolului RIP de
unicast (difuzare normala))
- MOSPF (acelasi lucru doar ca se bazeaza pe OSPF)
- PIM-SM ("Protocol Independent Multicasting - Sparse
Mode", care presupune ca utilizatorii dintr-un grup de multicast
sunt imprastiati)
- PIM-DM ("Protocol Independent Multicasting - Dense
Mode", care presupune ca utilizatorii sunt apropiati)
In kernel-ul Linux veti remarca lipsa acestor optiuni.
Asta deoarece protocolul este utilizat de o aplicatie de rutare,
cum ar fi Zebra, mrouted sau pimd. Cu toate acestea trebuie sa
stiti care protocol veti folosi pentru a selecta optiunile
corecte in kernel.
Pentru toate tipurile de rutare multicast, trebuie sa
selectati "multicast" si "multicast routing". Pentru DVMRP si
MOSPF acestea sunt suficiente. Pentru PIM trebuie sa activati si
PIMv1 sau PIMv2 in functie de versiunea de protocol (1 sau 2)
care o foloseste reteaua voastra.
Dupa recompilarea kernel-ului veti vedea ca la boot-are
lista de protocoale IP include si IGMP. Acesta este un protocol
pentru administrarea grupurilor multicast. In momentul in care
acest document a fost scris Linux suporta versiunile IGMP 1 si 2
desi exista versiunea 3 care este documentata. Acest lucru nu ne
afecteaza asa de mult deoarece IGMPv3 este destul de nou si
functiile pe care le aduce nu sunt asa de folosite. Deoarece IGMP

trateaza grupuri, doar capabilitatile din versiunea cea mai
simpla IGMP peste intregul grup vor fi folosite. Pe parcurs vom
folosi in special IGMPv2, desi mai apare din cand in cand si
IGMPv1.
Pana aici totul e bine. Am activat multicast-ingul. Acum
trebuie sa spunem kernel-ului Linux ce poate face cu el asa ca
vom activa rutarea. Adaugam o retea virtuala multicast in tabela
de rutare:
#ip route add 224.0.0.0/4 dev eth0
(Presupunand, bineinteles, ca folositi eth0 pentru
multicast! Puteti inlocui cu un dispozitiv la alegere.)
Acum activam forward-area de pachete:
#echo 1 > /proc/sys/net/ipv4/ip_forward
In acest moment va intrebati daca va functiona. Pentru a
testa conexiunea dam un ping pe grupul prestabilit 224.0.0.1.
Toate masinile din LAN cu multicast-ul activat vor raspunde.
Observati ca toate masinile care raspund nu au o adresa IP
224.0.0.1. Surprize surprize (cu intonatie va rog)! Aceasta este
o adresa de grup si toti membrii grupului vor raspunde cu adresa
proprie, nu cu a grupului.
#ping -c 224.0.0.1
(Urmeaza o continuare)
9. QUEUEING DISCIPLINES (reguli de asteptare) PENTRU

ADMINISTRAREA LATIMII DE BANDA
Cand am descoperit chestia asta linguricea mi-a fost
sensibilizata. Linux 2.2/2.4 vine cu niste capabilitati de
managementul traficului comparabile cu al sistemelor high-end.
Linux intrece cu mult oferta Frame Relay si ATM.
Pentru a preveni confuziile, tc utilizeaza urmatoarele
reguli pentru latimea de banda:
mbps=1024 kbps=1024 * 1024 bps => byte/s
mbit=1024 kbit => kilo bit/s
mb=1024 kb=1024 * 1024 b => byte

mbit= 1024 kbit => kilo bit
Numerele sunt stocate intern in bps si b.
Cand tc afiseaza rata de transfer, foloseste urmatoarele:
1Mbit=1024 Kbit= 1024 * 1024 bps => byte/s
9.1. Explicarea queue-rilor (cozilor) si queueing disciplines

(reguli de asteptare)
Folosind queue-rile putem determina modul in care sunt
_trimise_ datele. Este foarte important sa intelegem ca putem
modela (shape) doar datele care le transmitem.
Tinand cont de modul de functionare al Internet-ului, nu
avem control direct asupra datelor care ne sunt trimise. Este
similar casutei postale de acasa. Nu putem influenta in nici un
fel cantitatea de scrisori care o primim, in afara de contactarea
personala.
Cu toate acestea Internet-ul este bazat in mare parte pe
TCP/IP care are cateva caracteristici care ne pot ajuta. TCP/IP
nu poate determina capacitatea unei retele dintre doua host-uri
asa ca incepe sa trimita date din ce in ce mai rapid ('slow
start'). Cand pachetele incep sa se piarda, deoarece s-a depasit
rata maxima de transfer (hard sau soft), va incetini pana la o
valoare optima. In realitate protocolul este ceva mai destept dar
vom discuta mai tarziu despre asta.
Acest lucru este echivalent cu ignorarea corespondentei in
speranta ca oamenii nu va vor mai trimite scrisori si biletele de
dragoste (care tulbura visele la la la). Singura diferenta e ca
in Internet chestia asta functioneaza :).
Daca aveti un ruter si vreti ca anumit host-uri din
reteaua voastra sa nu faca download la o viteza prea mare trebuie
sa modelati traficul pe interfata interna (conectata la reteaua
locala) prin care sunt trimise date catre propriile statii.
De asemenea trebuie sa va asigurati ca conexiunea nu va fi
"gatuita". Daca aveti un NIC 100Mbit si un ruter cu o conexiune
256kbit, trebuie sa va asigurati ca nu trimiteti mai multe date
decat poate suporta ruterul. Altfel, ruterul va controla
coexiunea si modelarea latimii de banda disponibile. Avem nevoie
sa "stapanim" propria coada de asteptare, daca se poate spune
asa, si link-ul cel mai lent. Din fericire acest lucru este
destul de facil.
9.2. Queueing Ddisciplines simple, fara clase

Dupa cum am spus, cu queueing disciplines, putem modifica
modul in care sunt trimise datele. Regulile de asteptare fara
clase accepta informatia care trebuie transmisa si o
reprogrameaza (reschedule), o intarzie (delay) sau nu o
proceseaza (drop).
Aceste metode pot fi folosite pentru modelarea traficului
pentru o interfata, fara subdiviziuni. Este foarte important sa
intelegeti aceasta parte a regulilor de asteptare inainte sa
ajungem la "reguli de asteptare in reguli de asteptare cu clase"
(classful qdisc-containing-qdisc).
De departe cea mai folosita regula este pfifo_fast qdisc este si cea prestabilita. Acest lucru explica si robustetea
acestor caracterisitici avansate. Nu sunt nimic mai mult decat un
alt queue.
Fiecare din aceste queue-uri are avantaje si dezavantaje
specifice. Nu toate sunt testate cum trebuie.
9.2.1. pfifo_fast
Aceasta este, cum spune si numele, First In First Out
(primul intrat primul iesit), ceea ce inseamna ca toate pachetele
sunt tratate la fel. Aproximativ. Queue-ul pfifo_fast are 3 asazise benzi (bands). In fiecare banda, se aplica regulile FIFO. Cu
toate astea, cat timp sunt pachete in banda 0, banda 1 nu va fi
procesata. La fel pentru 1 si 2.
Kernel-ul tine cont de flag-ul Type of Service (TOS tipul serviciului) al pachetelor si are grija sa insereze pachete
cu intarziere minima (minimum delay) in banda 0.
Sa nu confundati acest qdisc simplu fara clase (classless
simple qdisc) cu cel PRIO cu clase! Desi se comporta similar
pfifo_fast nu suporta clase si nu pot fi adaugate alte qdisc-uri
cu ajutorul comenzii tc.
9.2.2.1 Parametri si folosire

Fiind prestabilit, qdisc-ul pfifo_fast nu poate fi
reconfigurat si arata cam asa:
priomap - determina cum prioritatile pentru pachete, in functie

de asocierile kernel-ului, sunt mapate la benzi. Maparea se face
in functie de octetul TOS din pachet:
0
1
2
3
4
5
6
7
+-------+-------+-------+-------+-------+-------+------+-------+
|Precedenta (Precedence)|
TOS
|
MBZ |
+-------+-------+-------+-------+-------+-------+------+-------+
Cei patru biti TOS (campul TOS - TOS field) sunt definiti
astfel:
Binar Zecimal
Semnificatie
-------------------------------1000
8
Intarziere minima (Minimize delay - md)
0100
4
Rata de transfer maxima (Maximize
throughput - mt)
0010
2
Siguranta maxima (Maximize reliability mr)
0001
1
Cost minim (Minimize monetary cost - mmc)
0000
0
Serviciu normal (Normal Service)
Cum la dreapta acestor patru biti este un bit 1, valoarea
reala a campului TOS este dubla valorii bitilor TOS. Tcdump -v
afiseaza valoarea reala a campului TOS, nu doar cei 4 biti.
TOS
Biti
Semnificatie
Prioritate
Banda
----------------------------------------------------------------------------------0x0
0
Normal Service
0
Best Effort
1
0x2
1
Minimize Monetary Cost
1
Filler
2
0x4
2
Maximize Reliability
0
Best Effort
1
0x6
3
mmc+mr
0
Best Effort
1
0x8
4
Maximize Throughput
2
Bulk
2
0xa
5
mmc+mt
2
Bulk
2
0xc
6
mr+mt
2 Bulk
2
0xe
0x10
Interactive
0x12
Interactive
0x14
Interactive
0x16
Interactive
0x18
7
2
8
0
9
0
10
0
11
0
12
mmc+mr+mt
2 Bulk
Minimize Delay
mmc+md
mr+md
mmc+mr+md
mt+md
4 Int. Bulk
13
mmc+mt+md
4 Int. Bulk
14
mr+mt+md
4 Int. Bulk
15
mmc+mr+mt+md
4 Int. Bulk
1
0x1a
1
0x1c
1
0x1e
1
O gasca de numere. A doua coloana are valorile bitilor TOS
relevanti, iar pe a treia semnificatia acestora. De exemplu 15
inseamna un pachet care "cere" cost minim, siguranta maxima, rata
de transfer maxima si intarziere minima. Eu il numesc pachet
"olandez". A patra coloana arata modul in care kernel-ul Linux
interpreteaza bitii TOS - prioritatea la care sunt mapati.
Ultima coloana arata rezultatul prestabilit priomap. In
linie de comanda priomap arata cam asa:
1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1
Asta inseamna ca prioritatea 4, de exemplu, este mapata la
banda 1. Priomap permite folosirea unor prioritati mai mari (>7)
care nu corespund maparilor TOS, dar care sunt setate prin alte
mijloace.
Acest tabel din RFC 1349 (sa-l cititi pentru mai multe
detalii) prezinta modul in care aplicatiile pot sa-si seteze
bitii TOS:
TELNET
FTP
1000
Control
(intarziere minima)
1000
(intarziere
0100
(rata de transfer maxima)

(intarziere minima)
minima)
TFTP
SMTP
Date
1000
Faza de comanda 1000
(intarziere
minima)
Faza de date 0100
(rata de transfer maxima)
DNS (serviciul pentru numele de domenii)

Interogare UDP (UDP Query) 1000
(intarziere minima)
Interogare TCP (TCP Query) 0000
Transfer de zona(Zone Transfer) 0100
(rata de transfer
maxima)
NNTP
ICMP
0010
Erori
Cereri(Requests)
(cost minim)
0000
0000
(de cele mai multe
Raspunsuri (Answers) 0000
(de cele mai multe
ori)
ori)
txqueuelen - Lungimea acestei cozi este obtinuta din configurarea
interfetei, care poate fi afisata si setata cu ajutorul ifconfig
si ip. Pentru a seta lungimea cozii la 10, scrieti in linia de
comanda:
#ifconfig eth0 txqueuelen 10
Acest parametru nu poate fi setat cu tc!
9.2.2. Token Bucket Filter - TBF (Filtru cu jetoane)

TBF este un qdisc simplu care lasa sa treaca doar
pachetele care nu depasesc o rata de transmitere stabilita
administrativ, dar cu posibilitatea unor burst-uri (rafale)
scurte mai mari ca aceasta rata.
TBF este foarte precis, menajand reteaua si procesorul.
Este alegerea preferata pentru incetinirea traficului pe o
interfata.
Implementarea TBF este, mai exact, un buffer (bucket),
umplut constant cu bucati de informatie numite token-uri (jeton)
la o rata specifica (token rate). Cel mai important parametru al
bucket-ului este dimensiunea - numarul de token-uri cu care poate
fi incarcat. Fiecare token "prinde" un pachet din queue-ul de
date si este sters din token bucket. Daca se asociaza acest
algoritm cu doua fluxuri - token si date, apar trei posibilitati:
- Datele vin in TBF la o rata egala cu cea a token-urilor.

In acest caz pachetul este preluat de un token si trece de queue
fara intarziere.
- Datele vin in TBF la o rata mai mica decat cea a tokenurilor. Doar o parte din token-uri sunt sterse la iesirea unui
pachet iesit din queue, asa ca token-urile se vor acumula, pana
cand bucket-ul se umple. Token-urile excesive pot fi folosite la
trimiterea datelor la o viteza mai mare decat cea stabilita,
avand loc unul sau mai multe burst-uri scurte.
- Datele vin in TBF la o rata mai mare decat cea a tokenurilor. Asta inseamna ca bucket-ul va epuiza toate token-urile,
ceea ce va determina ca TBF sa accelereze rata token-urilor un
timp. Aceasta situatie se numeste 'overlimit situation'. Daca
pachetele vin in continuare la o rata neschimbata nu vor mai fi
procesate (drop).
Ultima varianta este foarte importanta deoarece permite
modelarea latimii de banda disponibila datelor care trec prin
filtru.
Acumularea de token-uri permite un burst scurt pentru ca
pachetele excesive sa treaca fara pierderi, dar orice
supraincarcare cu durata mai mare va determina intarziere
pachetelor si, eventual, neprocesarea lor.
Nota: in implementarea actuala token-urile corespund
octetilor nu pachetelor.
9.2.2.1. Parametri si folosire

Desi s-ar putea sa nu fie nevoie, TBF are cateva chestii
interesante care pot fi modificate. Sa vedem mai intai parametrii
care sunt intotdeauna disponibili:
limit sau latency - 'Limit' este numarul de octeti care pot fi
incarcati in queue pana la un token liber. Puteti
specifica acest lucru si altfel, folosind parametrul 'latency',
care seteaza timpul maxim de asteptare a unui pachet in TBF.
Ultimul calcul se face in functie de dimensiunea bucket-ului,
rata si rata de varf (peakrate) daca este activat.
burst/buffer/maxburst - Dimensiunea pachetului in octeti. Este
cantitatea maxima de octeti pentru care pot exista
token-uri
disponibile instantaneu. In general, modelarea unor rate mari de
transfer necesita un bucket mare. Pentru 10mbit/s pe Intel, aveti
nevoie de un bucket cu minim 10KB daca vreti sa poata fi atinsa
rata configurata. Daca buffer-ul este prea mic, pachetele nu vor
fi procesate deoarece numarul de token-uri pe un tick de ceas

depaseste dimensiunea bucket-ului.
mpu - Un pachet de dimensiune 0 foloseste o parte din latimea de
banda. Pentru ethernet, nici un pachet nu poate fi
mai mic de
64 octeti. MPU (Minimum Packet Unit) determina folosirea minima a
unui token pentru un pachet.
rate - Factorul de viteza. Am povestit mai sus despre limite.
Daca bucket-ul este incarcat cu token-uri si este permisa
golirea sa, o face, prestabilit, la o viteza infinita. Daca vreti
sa modificati acest lucru folositi urmatorii parametri:
peakrate - Daca mai exista token-uri disponibile, pachetele care
sosesc sunt trimise cu viteza luminii, daca se poate spune asa.
Acest lucru s-ar putea sa nu va convina, in special daca aveti un
bucket mare. Peakrate-ul poate fi folosit pentru a specifica cat
de repede va fi golit bucket-ul. Daca faceti totul ca la carte,
dupa trecerea unui pachet va urma o pauza apoi va trece si
urmatorul pachet. Am calculat timpii de asteptare ca sa putem
trimite doar la peakrate (rata de varf). Cu toate acestea,
datorita rezolutiei temporale de 10ms in Unix, cu pachete medii
10.000 biti, suntem limitati la un peakrate de 1mbit/s!
mtu/minburst - Peakrate-ul (rata maxima de transfer) nu este
foarte folositor daca rata medie este mai mare. Un
peakrate
ridicat este posibil daca sunt trimise mai multe pachete pe un
tick de ceas, ceea ce inseamna ca am
creat un nou bucket!
Pentru a calcula peakrate-ul maxim posibil, se inmulteste
mtu configurat cu 100 (sau,mai exact, HZ, 100 pe Intel si 1024 pe
Alpha).
9.2.2.2. Configuratie demonstrativa

O configuratie simpla dar _foarte_ folositoare:
#tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst
1540
De ce este asa de meserie chestia asta? Daca aveti un
device de retea cu un queue mare, cum ar fi un modem cablu sau
DSL si comunicarea cu acesta se face printr-un device rapid, de
exemplu o interfata ethernet, veti observa ca upload-ul aproape

ca anuleaza interactivitatea.
Acest lucru se intampla datorita supraincarcarii queueului din modem, care probabil este _imens_, lucru normal de
altfel deoarece permite o rata de transfer ridicata pentru
upload. Cum nu dorim sa se intample acest lucru si queue-ul sa
ramana in limite rezonabile pentru a se pastra un echilibru intre
upload si download folosim configuratia de mai sus. Ce se
intampla de fapt? Este incetinita rata de transfer pentru upload
ceea ce reduce queue-ul din modem, practic queue-ul ramane in
Linux, unde poate f controlata.
Modificati 220kbit conform conexiunii provider-ului
vostru, minus cateva procente. Daca aveti un modem foarte rapid
mai cresteti un pic burst-ul.
9.2.3. Stochastic Fairness Queueing (cozi de asteptare

echilibrate probabilistice)
SFQ este o implementare simpla a familiei de algoritmi
pentru queue-uri de asteptare egale. Este mai putin precis decat
celelalte, dar are nevoie si de mai putine resurse (putere de
calcul) ramanand aproape perfect echilibrat.
Cuvantul cheie in SFQ este conversatia (sau fluxul), care
corespunde de obicei unei sesiuni TCP sau unui stream (flux) UDP.
Traficul este impartit intr-un numar destul de mare de queue-uri
FIFO, cate unul pentru fiecare conversatie apoi este trimis,dupa
un model round robin (ciclare), catre un numar limitat de queueuri folosind un algoritm hash.
Datorita hash-ului, sesiuni multiple pot ajunge in acelasi
bucket, ceea ce ar injumatati sansa fiecarei sesiuni de a trimite
un pachet, viteza efectiva scazand la jumatate. Pentru a preveni
aceasta situatie, SFQ isi schimba algoritmul hash destul de des
astfel incat oricare doua sesiuni vor fi concurente la un moment
dat nu mai mult de cateva secunde.
Este important de remarcat ca SFQ este folositor doar in
cazul in care interfata de iesire este incarcata! Daca nu atunci
nu va exista nici o coada de asteptare si, evident, nu va avea
nici un efect. Voi explica mai tarziu modul de combinare SFQ cu
alte qdisc-uri pentru a lua ce e mai bun din fiecare.
Configurarea SFQ pe interfata ethernet conectata la
modemul cablu sau la ruterul DSL nu are nici un sens fara o
modelare ulterioara a traficului!
9.2.3.1. Parametri si folosire

SFQ se autoconfigureaza destul de bine:
perturb - Reconfigureaza hash-ul o data la n secunde. Daca nu
este setat nu va fi niciodata reconfigurat.Nerecomandat. 10
(secunde) e o valoare destul de buna.
quantum - Cantitatea de octeti care poate fi descarcata dintr-un
queue de catre un stream cand ii vine
randul. Prestabilit la 1
maximum sized pachet (MTU-sized). Nu configurati mai mic ca MTU!
9.2.3.2. Configuratie demonstrativa

Daca aveti un device cu o viteza a conexiunii si rata de
transfer identica, cum ar fi un modem normal, aceasta
configuratie va permite sa stabiliti egalitatea intre procesele
care folosesc conexiunea:
#tc qdisc add dev ppp0 root sfq perturb 10
#tc -s -d qdisc ls
qdisc sfq 800c:dev ppp0 quantum 1514b limit 128p flows 128/1024
perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)
Numarul 800c: este asociat automat ca identificator de
manipulare (handle number). 'Limit' inseamna ca 128 de pachete
pot astepta in aceast queue. Sunt 1024 de bucket-uri hash
disponibile, din care 128 pot fi active la un moment dat (nu mai
incap pachete in aceasta queue). Odata la 10 secunde hash-urile
sunt reconfigurate.
9.3. Cand si cum este folosit un anumit queue

Pe scurt, acestea sunt niste queue-uri simple care
administreaza traficul prin reordonarea, incetinirea si refuzarea
pachetelor (drop).
Cateva sfaturi privind folosirea queue-rilor (unele qdiscuri care apar aici sunt descrise in capitolul 14):
- Pentru a incetini traficul de iesire folositi TBF. Functioneaza
pentru latimi de banda mari daca scalati bucket-ul.
- Daca aveti o conexiune incarcata si vreti sa fiti sigur ca o

sesiune nu o utilizeaza in defavoarea celorlalte folosit SFQ.
- Daca aveti un backbone mare (si stiti cam despre ce este
vorba), incercati Random Early Drop.
- Pentru modelarea traficului de intrare, care nu este forwardat, folositi Ingress Policer. ca veni vorba, administrarea
traficului de intrare se numeste policing nu shaping (modelare).
- Daca forward-ati acest trafic, folositi TBF pe interfata
destinatie. In cazul in care vreti sa forward-ati pe mai multe
interfete folositi Ingress Policer.
- Daca nu vreti sa modelati traficul pe o interfata, dar vreti sa
aflati cat de incarcata este si daca exista un queue folositi
pfifo queue (diferit de pfifo_fast). Nu are benzi interne dar are
contoare.
- In sfarsit puteti face modelare "sociala". S-ar putea sa nu
puteti folosi tehnologia pentru a obtine ceea ce vreti.
Utilizatorii considera limitarile tehnice un afront. O vorba buna
v-ar putea sa impartiti latimea de banda cum trebuie.
9.4. Terminologie
Pentru a intelege configuratii mai importante trebuie
clarificate cateva concepte. Datorita complexitatii si
"prospetimii" tematicii abordate, sunt folositi diferiti termeni
care, de fapt, inseamna acelasi lucru.
Am folosit ca referinta draft-ietf-diffserv-model-06.txt,
An Informal Management
Model for Diffserv Routers. Il puteti gasi la
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model06.txt
Cititi-l pentru a vedea definitile oficiale.
Queueing Discipline (regula de asteptare) - Un algoritm care
administreaza queue-ul unui device, pentru intrare (ingress) sau
iesire (egress)
Classless qdisc (regula de asteptare fara clase) - un qdisc fara
subdiviziuni interne configurabile
Classful qdisc (regula de asteptare cu clase) - Un classful qdisc
contine mai multe clase. Fiecare dintre aceste clase contine un
alt qdisc, care poate fi la randul cu sau fara clase. Conform
definitiei stricte, pfifo_fast este cu clase, deoarece are trei
benzi care sunt,de fapt, clase. Cu toate acestea din perspectiva
operatorului care realizeaza configurarea, pfifo_fast nu are

clase deoarece nu poate fi modificat cu tc.
Classes (clase) - Un classful qdisc poate avea mai multe clase
interne. Fiecare dintre aceste clase poate contine un qdisc real.
Classifier (clasificator) - Fiecare qdisc cu clase foloseste un
classifier pentru a determina carei clase ii este trimis un
anumit pachet.
Filter - Clasificarea este facut cu ajutorul filtrelor. Un filtru
are un numar de conditii; in cazul unei potriviri este executata
actiunea asociata.
Scheduling (programare) - Un qdisc poate decide, cu ajutorul unui
classifier, daca anumite pachete au prioritate. Acest proces se
numeste scheduling sau reordering.
Shaping (modelare) - Procesul de intarziere a pachetelor inainte
de a iesi pe o anumita interfata conform unei rate maxime de
transfer stabilite. Shaping-ul este realizat cu egress. De
asemeni in procesul de shaping unele pachete pot fi pierdute din
diverse motive.
Policing - intarzierea sau neprocesarea pachetelor pentru a
mentine traficul sub o anumita limita. In Linux, polcing-ul nu
poate intarzia un pachet - nu exista un queue ingress...
Work-Conserving (conservarea muncii) - Un qdisc work-conserving
va procesa doar un pachet existent. Cu alte cuvinte, nu va
intarzia un pachet daca NIC-ul poate trimite unul (in cazul unui
qdisc egress).
non-Work-Conserving - unele queue-uri, de exemplu TBF, poate
pastra un pachet pe o anumita perioada de timp pentru a limita
latimea de banda. Asta inseamna ca uneori refuza sa trimita un
pachet chiar daca acesta este disponibil.
Acum ca ne-am lamurit cu terminologia, sa vedem pe unde
stau termenii:
Program userspace
^
|
+------------------------------+------------------------------------+
|
|
+------------> Stiva IP
/ ---------> Forward --->
|
|
|
|
|
|
|
|
/
|
/
|
/
/-qdisc1-\
|
/
Egress
/--qdisc2--\
|
|
| /
------>a
|
|/
|
|
^
|
--->------------->Ingress
|
|
Qdisc
|
Classifier---qdisc3--\--qdisc4--/
\-qdiscn-/
+-------------------------------------------------------------------+
Schema realizata de Jamal Hadi Salim.
Cam asa arata kernel-ul. Sageata din stanga jos reprezinta
traficul de intrare care se duce in qdisc-ul Ingress unde sunt
aplicate (daca exista) filtre. Aceasta operatie se numeste
policing - pachetele care intra pot fi procesate devreme, din
moment ce n-au parcus un anumit traseu in kernel. Daca vreti sa
le opriti (drop) aici este cel mai bun loc pentru a evita
folosirea puterii de calcul.
Daca pachetul merge mai departe, poate fi adresat unei

aplicatii locale, caz in care intra stiva IP pentru a fi procesat
si trimis unei aplicatii. Mai poate fi forward-at catre egress.
Programele utilizator pot sa transmita, la randul lor, date care
vor fi examinate si trimise la Egress Classifier. Dupa ce a fost
filtrat ajunge sa stea intr-un queue. In cazul in care nu a fost
realizata o configuratie exista un singur qdisc instalat,
pfifo_fast, care primeste intotdeauna un pachet. Acest proces se
numeste enqueueing.
Pachetul sta in qdisc, asteptand kernel-ul sa-l trimita pe
interfata de retea - dequeueing.
Aceasta schema este valabila sin in cazul in care exista
un singur adaptor de retea - sagetile care intra sau ies din
kernel nu trebuie luate ad literam. Fiecare adaptor de retea are
ingress/egress.
9.5. Reguli de asteptare fara clase

9.5.1. Fluxul in qdisc-uri fara clase si clase *
9.5.2. Familia qdisc: radacini, descriptoare,
parinti si copii
9.5.3. qdisc PRIO
9.5.4. Renumitul qdisc CBQ
9.5.5. Jeton ierarhic (Hierarchical Token Bucket) *
9.6. Clasificarea pachetelor cu filtre
9.6. Exemple de filtre simple
9.7. Toate comenzile de filtrarea de care veti avea
nevoie in mod normal
9.7. Dispozitivul de asteptare intermediar (Intermediate
queueing device - IMQ)
9.7.1. Exemple de configurare
10. Distribuirea conexiunii pe mai multe interfete (load sharing)
10.1. Caveats *
10.2. Alte posibilitati
11. Netfilter si iproute - marcarea pachetelor
12. Filtre avansate pentru (re)clasificarea pachetelor
12.1 Clasificarea u32
12.1.1. Selectorul u32
12.1.2. Selectori generali
12.1.3. Selectori specifici
12.2. Clasificatorul route
12.3. Filtre politiste :P (policing filters)
12.3.1. Metode de polici *
12.3.2. Supralimitarea actiunilor

12.3.3. Exemple
12.4. Filtre hash pentru filtrarea rapida masiva *
13. Parametrii kernel-ului pentru retea
13.1. Filtrare dupa calea inversa (Reverse Path Filtering)
*
13.2. Setari obscure
13.2.1. Generalitati IPv4
13.2.2. Setari pe dispozitiv
13.2.3. Politica vecinilor *
13.2.4. Setari de rutare
14. Reguli de asteptare avansate si mai putin utilizate
14.1. bfifo/pfifo
14.2. Algoritmul Clark-Shenker-Zhang (CSZ)
14.3. DSMARK
14.3.1. Introducere
14.3.2. La ce se refera Dsmark ?
14.3.3. Introducere in servicii diferentiate
14.3.4. Lucrul in Dsmark
14.3.5. Cum functioneaza SCH_DSMARK
14.3.6. Filtrul TC_INDEX
14.4. qdisc Intress
14.5. Detectare rapida aleatoare (Random Early Detection RED)
14.6. Detectarea generica rapida aleatoare
14.7. Emulare VC/ATM
14.8. Weighted Round Robin (WRR) *
15. Carte de bucate
15.1. Rularea mai multor site-uri cu SLA-uri diferite
15.2. Protejarea sistemului de atacuri SYN
15.3. Limitare ratei ICMP pentru prevenire dDoS *
15.4. Prioritizarea traficului interactiv
15.5. Web-caching transparent cu netfilter, iproute2,
ipchains si squid
15.5.1. Diagrama fluxului de trafic dupa
implementare
15.6. circumventing Path MTU Discovery issues with per
route MTU settings*
15.6.1. Solutie
15.7. Circumventing Path MTU Discovery issues with MSS
Clamping (pentru utilizatorii ADSL, cablu, PPPoE si
PPtP)
15.8. Ultimul coordonator de trafic: Intarziere mica,

down/upload-uri rapide
15.8.1. De ce nu functioneaza bine in modul
prestabilit
15.8.2. Scriptul real (CBQ)
15.8.3. Scriptul real (HTB)
15.9. Limitarea ratei pentru un singur host sau o masca de
reatea
15.10. Exemplu de configurare NAT cu Qos
15.10.1. Optimizare latimii de banda
15.10.2. Clasificarea pachetelor
15.10.3. Imbunatatirea configuratiei
15.10.4. Activarea configuratiei la pornire
16. Construirea bridge-urilor, si pseudo-bridge-urilor cu Proxy
ARP
16.1. Stadiul de dezvoltare a bridging si iptables *
16.2. Bridging si shaping *
16.3. Pseudo-bridge-uri c Proxy ARP
16.3.1. ARP si Proxy ARP
16.3.2. Implementare
17. Rutare dinamica - OSPF si BGP
17.1. Setare OSPF cu Zebra
17.1.1. Cunostiinte necesare
17.1.2. Configurare Zebra
17.1.3. Rulare Zebra
18. Alte posibilitati
19. Bibliografie
20. Multumiri.

Rutare Avansata in Linux Si Controlul Traficului

Încărcat de

Informații document

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

Rutare Avansata in Linux Si Controlul Traficului

Încărcat de

Drepturi de autor:

Formate disponibile

Rutare avansata in Linux si controlul

4. Reguli - baza de date cu politicile de rutare

Rutare multicast (difuzare pe grupuri)

9. Queueing Disciplines (reguli de asteptare) pentru

9.5.5. Hierarchical Token Bucket (Jetoane

14.3.5. Cum functioneaza SCH_DSMARK

17. Rutare dinamica - OSPF si BGP

2.1. Licenta si disclaimer

2.2. Cunostiinte necesare

- Linux Networking-HOWTO (Inainte era NET-3 HOWTO) http://www.linuxports.com/howto/networking

2.3. Ce poate face Linux

2.4. Note de intretinere

2.5. Acces, CVS si subscrierea actualizarilor

2.6. Lista de mail

2.7. Formatul acestui document

3.2. Tur iproute2

diverse metode pentru clasificare, prioritizare, impartire si

3.3. Chestii necesare

3.4. Explorarea configuratiei curente

3.4.1. Cum vedem link-urile

Informatiile afisate sunt diferite la voi, dar asta apare

3.4.2. Cum vedem adresele ip

Sa examinam interfata eth0 mai in detaliu. Este asociata

3.4.3. Cum vedem rutele

[ahu@home ahu]$ route -n

PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84)

4. REGULI - BAZA DE DATE CU POLITICILE DE RUTARE

tabele. Utilitarul mai vechi, route, modifica tabelele main si

4.1. Politica de rutare simple source (sursa simpla)

local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1

4.2. Rutare pentru mai multi provideri

De obicei sunt doua intrebari in ce priveste aceast tip de

4.2.1. Split Access (acces impartit)

$IF1 src $IP1 table T1

Nimic spectaculos, doar constructia unei rute spre gateway

ruta spre retea e de ajuns, permitand gasirea oricarui host din

4.2.2. Load balancing (balansarea conexiunii)

Parametrii 'weight' specifica daca conexiunea prin unul

5.1. Cateva notiuni despre tunele

5.2. Tunele IP-IP

Sa spunem ca avem trei retele: retelele interne A si B si

pana la seria de kernel-uri 1.3. Tunelurile IP-in-IP Linux nu

5.3. Tunele GRE

5.3.1. Tunel IPv4

Sa discutam un pic despre ce apare aici. In linia 1 am

5.3.2. Tunel IPv6

5.4. Tunele din Tara lui Papura Voda (userland)

6. TUNELE IPv6 CU CISCO SI/SAU 6BONE

6.1. Tunele IPv6

In acest moment intervin tunelurile.

(celalalt capat) si adresa locala (local). TTL este setat la

tunnel source Serial0

7. IPSEC: IP SIGUR IN INTERNET

(deocamdata nu exista pentru 2.5.49). Utilitare puteti gasi

7.1. Introducere in Manual Keying (semnare automata)

destinatie si o instructiune. Un exemplu de autentificare SA

autentificare astfel incat nodul de la distanta (remote) poate

acest lucru, trebuie sa folosim un SP de intrare pe 10.0.0.11 ca

add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc

7.2. Automatic Keying (Semnare automata)

Pentru a elimina aceste carente, IPSEC ofera Internet Key

path pre_shared_key "/usr/local/etc/racoon/psk.txt";

12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor

7.2.2.1. Probleme si defecte cunoscute