rutare avansata in linux si controlul traficului

Rutare avansata in Linux si controlul traficului

Autori:

Bert Hubert

Netherlabs BV

[email protected]

Gregory Maxwell (Section Author)

remco%virtu.nl

Remco van Mook (Section Author)

[email protected]

Martijn van Oosterhout (Section Author)

[email protected]

Paul B Schroeder (Section Author)

[email protected]

Jasper Spaans (Section Author)

[email protected]

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.4.1. Parametri si folosire

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-concepts-HOWTO/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: mtu 3924 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: dummy: mtu 1500 qdisc noop

link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

3: eth0: mtu 1400 qdisc pfifo_fast qlen 100

link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff


link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff

3764: ppp0: 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: 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: mtu 1500 qdisc noop

link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff


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


link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff

3764: ppp0: 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 ip-cref 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 route add $P1_NET dev $IF1 src $IP1 table T1

ip route add default via $P1 table T1

ip route add $P2_NET dev $IF2 src $IP2 table T2

ip route add default via $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 Internet-ul.

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 IP-in-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: mtu 3924 qdisc noqueue inet6 ::1/128 scope host


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/2002-November/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 [email protected].

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 descrieinstructiuni 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 ' 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 pre-partajate, 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 []:[email protected]

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 protected]

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 protected]' 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. Kernel-ul 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 asa-zise 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:

01234567

+-------+-------+-------+-------+-------+-------+-------+-------+

|Precedenta (Precedence)|

TOS | MBZ |

+-------+-------+-------+-------+-------+-------+-------+-------+

Cei patru biti TOS (campul TOS - TOS field) sunt definiti astfel:

BinarZecimal Semnificatie

--------------------------------

10008 Intarziere minima (Minimize delay - md)

01004 Rata de transfer maxima (Maximize throughput - mt)

00102 Siguranta maxima (Maximize reliability - mr)

00011 Cost minim (Minimize monetary cost - mmc)

00000 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

7

mmc+mr+mt

2 Bulk

2

0x10

8

Minimize Delay

6 Interactive

0

0x12

9

mmc+md

6 Interactive

0

0x14

10

mr+md

6 Interactive

0

0x16

11

mmc+mr+md

6 Interactive

0

0x18

12

mt+md

4 Int. Bulk

1

0x1a

13

mmc+mt+md

4 Int. Bulk

1

0x1c

14

mr+mt+md

4 Int. Bulk

1

0x1e

15

mmc+mr+mt+md

4 Int. Bulk

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

1000

(intarziere minima)

FTP

Control

1000

(intarziere minima)

Date

0100(rata de transfer maxima)

TFTP

1000

(intarziere minima)

SMTP

Faza de comanda 1000

(intarziere minima)

Faza de date0100(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

0010

(cost minim)

ICMP

Erori

0000

Cereri(Requests) 0000

(de cele mai multe ori)

Raspunsuri (Answers) 0000

(de cele mai multe 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 token-urilor. 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 token-urilor. 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 queue-ului 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 queue-uri 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 qdisc-uri 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 forward-at, 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 impar

rutare avansata in linux si controlul traficului

Documents