[Company Logo Image]  

[ Home ] [ Up ] [ News ] [ Szukaj ] [ Index ] [ NetMapa ] [ Ankieta ] [ Sprawy GroszNetu ] [ Forum ] [ FAQ ] [ Download ]

Ruting IP w Linuxie

 

 

Home
Up

Email

Ruting IP w Linuxie 2.2

Pawe│ Krawczyk
<kravietz@ceti.pl>


1   WstΩp

1.1   O czym jest ten artyku│?

Tekst ten omawia wiΩkszo£µ nowo£ci dotycz╣cych obs│ugi sieci IP, kt≤re pojawi│y siΩ w j╣drze Linuxa 2.2. Nie jest to vademecum dla os≤b pocz╣tkuj╣cych ani HOWTO. Jego zadaniem jest zapoznanie z u┐ytecznymi funkcjami os≤b zajmuj╣cych siΩ ruterami dzia│aj╣cymi na Linuxie i posiadaj╣cych podstawowe pojΩcie o dzia│aniu protoko│u IP.

1.2   Nowo£ci w j╣drze

Pocz╣tki wielkich zmian w Linuxie, dotycz╣cych protoko│u IP, to koniec 1996 roku, kiedy pojawi│a siΩ wersja 2.1.17. Zawiera│a ona pierwsz╣ wersjΩ przepisanego praktycznie od nowa kodu obs│uguj╣cego IP. Nowo£ci╣ by│a zgodno£µ z RFC 1812 [12] i ruting rozszerzony (policy routing). Do konfiguracji nowych funkcji s│u┐y│ program iproute, potem pojawi│ siΩ pakiet iproute2, zawieraj╣cy program ip. Kolejne wersje j╣dra wprowadzi│y tak┐e mechanizmy sterowania przep│ywem danych (traffic control), obs│ugiwane za pomoc╣ oddzielnego programu tc i opisane w osobnym artykule 1. Rozwijanie tej czΩ£ci j╣dra Linuxa oraz pakietu iproute2 to przede wszystkim zas│uga Aleksieja N. Kuƒniecowa <kuznet@ms2.inr.ac.ru> z moskiewskiego Instytutu Fizyki J╣drowej.

1.3   Nowo£ci w iproute2

Obs│uga iproute2 r≤┐ni siΩ zasadniczo od dotychczas stosowanych narzΩdzi -- ifconfig i route. W programach tych adres IP oraz maska podsieci by│y podawane oddzielnie, przy czym ta ostania by│a tradycyjnie zapisywana w postaci aaa.bbb.ccc.ddd. Program ip przyjmuje natomiast maskΩ podsieci w formacie skr≤conym aaa.bbb.ccc.ddd/nn, gdzie nn jest kt≤r╣ okre£la siΩ jako liczbΩ bit≤w jedynkowych w masce. Przyk│adowo, maska sieci C zapisywana tradycyjnie jako 255.255.255.0 ma 24 bity jedynkowe, podsieci 255.255.255.240 -- 28 itp.

Wi╣┐e siΩ z tym tak┐e mo┐liwo£µ u┐ywania skr≤conych postaci adres≤w IP, gdzie brakujace bajty s╣ zastΩpowane zerami. Przyk│adowo:

Notacja skr≤cona Notacja pe│na
127/8 127.0.0.0/8
192.168/16 192.168.0.0/16
0/0 0.0.0.0/0

Nale┐y podkre£liµ, ┐e jest to notacja zgodna z filozofi╣ CIDR ([2], [3]) oraz IPv6 i zalecana przez RFC 1812 ([12]), gdzie tradycyjn╣ konstrukcjΩ adresu IP (adres sieci, adres podsieci, adres hosta) zastΩpuje siΩ przez adres prefiksu i adres hosta. W konsekwencji wy┐ej opisana notacja maski podsieci odpowiada po prostu d│ugo£ci prefiksu w bitach.

1.4   Konfiguracja adres≤w interfejs≤w

Ka┐dy interfejs mo┐e posiadaµ wiΩcej ni┐ jeden adres IP. Dodatkowe adresy s╣ po prostu adresami, r≤┐ni╣cymi siΩ od podstawowego adresu tylko flag╣ secondary, a nie samodzielnymi pseudointefejsami, jak to by│o w j╣drach 2.0 i wcze£niejszych.

Do ustawiania adresu intefejsu s│u┐y polecenie ip addr:

   ip addr add ADRES dev INTERFEJS
   [ ( peer | remote ) P-T-P ]
   [ ( broadcast | brd ) BROADCAST ]
   [ anycast ANYCAST ] [ label NAZWA ]
   [ scope ZASI╩G ]
Parametr ADRES jest adresem dodawanym do interfejsu. Nale┐y zaznaczyµ, ┐e w odr≤┐nieniu od programu ifconfig adresy IPv4 podaje siΩ razem z mask╣ podsieci jako aaa.bbb.ccc.ddd/nn.

Adresy IPv6 podaje siΩ standardowo jako aa:bb:...:zz/nnn, gdzie /nnn to d│ugo£µ prefiksu (maski podsieci).

W przypadku intefejs≤w point-to-point (na przyk│ad PPP) parametr ADRES okre£la adres lokalny intefejsu, natomiast adres drugiego ko±ca nale┐y podaµ po parametrze peer (akceptowane jest r≤wnie┐ s│owo remote).

Do ustawiania adresu rozg│oszeniowego (broadcast) s│u┐y parametr broadcast (lub kr≤cej brd). W nowych wersjach iproute parametr + spowoduje adresu obliczonego automatycznie na podstawie d│ugo£ci prefiksu.

Adres anycast stosowany w IPv6 ustawia sie parametrem anycast. 2

ZasiΩg adresu (scope) okre£la siΩ parametrem scope, kt≤ry mo┐e byµ jednym ze standardowych zasiΩg≤w, albo nazw╣ (lub numerem) zasiΩgu zdefiniowanego przez u┐ytkownika. 3

Interfejsowi mo┐na nadawaµ nazwy za pomoc╣ parametru label, co jest przydatne w przypadku dodawania kolejnych adres≤w do interfejsu (eth0:1, eth0:2,...). W ten spos≤b do dodatkowych adres≤w mo┐na siΩ tak┐e odwo│ywaµ za pomoc╣ starszych wersji polecenia ifconfig.

2   Konfiguracja parametr≤w interfejsu

Dodanie adresu do interfejsu nie powoduje jego automatycznej aktywacji (flaga UP) Jest to zachowanie odmienne od znanego z j╣der 2.0 Do konfigurowania tego -- i innych -- parametr≤w intefejsu s│u┐y polecenie ip link:

   ip link set INTERFEJS [ ( up | down ) ]
   [ arp ( on | off ) ]
   [ multicast ( on | off ) ]
   [ ( txqueuelen | txqlen ) PKT ]
   [ name NAZWA ]
  • Flagi up i down powoduj╣ odpowiednio aktywacjΩ lub deaktywacjΩ interfejsu. W momencie aktywacji interfejsu kernel dodaje do tablicy rutingu trasy kieruj╣ce na ten interfejs pakiety do sieci do niego przy│╣czonej. Jest ona umieszczana w specjalnej tablicy local. Warto zauwa┐yµ, ┐e w j╣drach 2.0 i wcze£niejszych tak╣ trasΩ trzeba by│o dodaµ explicite za pomoc╣ polecenie route, obecnie nie jest to ju┐ konieczne.

  • Opcja arp w│╣cza lub wy│╣cza protok≤│ ARP dla danego interfejsu. Oznacza to, ┐e interfejs nie bΩdzie odpowiada│ na pytania ARP, nawet je£li pytanie dotyczy jego adresu IP. 4

  • Opcja multicast w│╣cza lub wy│╣cza obs│ugΩ pakiet≤w multicast na danym interfejsie.

  • Parametr txqueulen (akceptowany jest skr≤t txqlen) okre£la wielko£µ kolejki wyj£ciowej danego interfejsu w pakietach. Wielko£µ ta jest ustawiana przez system automatycznie na podstawie domy£lnej warto£ci -- innej dla ka┐dego rodzaju interfejsu -- a zale┐nej od jego przepustowo£ci. Z regu│y ustawienie domy£lne jest wystarczaj╣ce, jego zmiana mo┐e byµ czasem korzystna na przyk│ad do poprawienia wsp≤│dzielenia wolnego │╣cza PPP. 5

3   Komunikacja host≤w w obrΩbie sieci lokalnej

3.1   Wprowadzenie

W IPv4 informacja o adresie w warstwie │╣cza (link layer address) interfejsu posiadaj╣cego dany adres IP jest uzyskiwana za pomoc╣ protoko│u ARP (Address Resolution Protocol, RFC 826 [1]), korzystaj╣cego z rozg│aszania w warstwie │╣cza i r≤┐ni╣cego siΩ implementacj╣ dla ka┐dego rodzaju sieci fizycznej (ARP dla Ethernetu r≤┐ni siΩ od ARP dla ATM). W IPv6 s│u┐y do tego protok≤│ wyszukiwania host≤w s╣siaduj╣cych (Neighbor Discovery), oparty o pakiety multicast i dzia│aj╣cy nad warstw╣ IP. Dok│adny jego opis -- oraz terminologiΩ -- mo┐na znaleƒµ w RFC 2461 [6].

W zwi╣zku z tym, kernel tablica s╣siednich host≤w, przechowywana przez kernel, jest niezale┐na od protoko│u i zawiera informacje uzyskane albo za pomoc╣ ARP albo za pomoc╣ ND. S│u┐y ona tak┐e jako baza danych do wprowadzonego jako standard przez IPv6, ale dzia│aj╣cego tak┐e dla IPv4, mechanizmu weryfikacji osi╣galno£ci hosta (Neighbor Unreachability Discovery).

Tablica s╣siednich host≤w zawiera nastΩpuj╣ce informacje: adres IP hosta, adres hosta w warstwie │╣cza (link layer address) oraz aktualny stan rekordu. Dodatkowo s╣ w niej przechowywane takie informacje jak ilo£µ odwo│a± do danego rekordu oraz czas ostatniego odwo│ania. G│≤wne stany rekord≤w to: incomplete (┐aden host nie odpowiedzia│ na pytanie o dany adres), reachable (host jest osi╣galny) oraz stale (host by│ osi╣galny, lecz rekord jest przeterminowany). Ponadto istniej╣ dwa stany specjalne: noarp (rekord nie jest uaktualniany przez ARP ani ND) oraz permanent (rekord dodany rΩcznie przez administatora). Oba nie s╣ nigdy zmieniane przez kernel, nie jest w stosunku do nich u┐ywany ARP, ND ani NUD, a rekordy w stanie permanent nie s╣ usuwane podczas okresowego czyszczenia tablicy (garbage collecting).

3.2   Obs│uga tablicy s╣siad≤w

Do manipulacji tablic╣ zawieraj╣c╣ informacje o adresach fizycznych host≤w i odpowiadaj╣cych im adresach IP s│u┐y polecenie ip neigh:

       ip neigh ( add | del )
       (ADRES [ lladdr LLADDR ] | proxy PROXY )
       [ nud ( permanent | noarp | stale | reachable ) ]
       dev INTERFEJS
Polecenie ip neigh mo┐e dodawaµ dwa typy rekord≤w do tablicy:

  • Adres rzeczywisty Parametr ADRES jest wtedy adresem IPv4 lub IPv6, kt≤rego rekord chcemy dodaµ lub usun╣µ z tablicy host≤w s╣siaduj╣cych. Adres warstwy │╣cza zwi╣zany z dodawanym adresem IP podajemy natomiast w parametrze lladdr.

  • Adres Proxy ARP Parametr PROXY okre£la adres IP hosta, dla kt≤rego dany interfejs ma po£redniczyµ w protokole ARP. WiΩcej informacji o technice ,,Proxy ARP'', kt≤rej nie bΩdziemy tutaj opisywaµ, mo┐na znaleƒµ na przyk│ad w ,,Network Administrator's Guide'' [10] w rozdziale Configuring TCP/IP Networking, sekcja Checking the ARP Tables.

4   Ruting

4.1   WstΩp.

W kernelach 2.0 by│a tylko jedna podstawowa tablica rutingu. W kernelach 2.2 tablic tych mo┐e byµ do 250 zdefiniowanych tablic, z czego domy£lnie aktywne s╣ trzy:

  • local (255)
  • main (254)
  • default (253)
Tablica local zawiera trasy dodawane automatycznie przez kernel, takie jak trasy do lokalnych interfejs≤w oraz trasy broadcastowe. Trasy w tej tablicy maj╣ z regu│y zasiΩg host lub link.

Tablica main odpowiada starej tablicy rutingu w kernelach 2.0 i do niej trafiaj╣ trasy dodawane przez u┐ytkownika, je£li nie poda on innej tablicy. Do niej dodawane s╣ r≤wnie┐ trasy tworzone automatycznie przez kernel w momencie aktywacji interfejsu.

Tablica default jest domy£lnie pusta.

Ponadto istnieje tak┐e tablica cache, kt≤ra jest tworzona automatycznie i traktowana w odmienny spos≤b ni┐ wy┐ej wymienione tablice. W szczeg≤lno£ci, jej zawarto£µ jest uzupe│niana automatycznie przez kernel i nie jest ona dostΩpna do zapisu przez u┐ytkownika. Jej zawarto£µ mo┐na natomiast przegl╣daµ, co jest opisane poni┐ej.

Tablice s╣ przegl╣dane w kolejno£ci: local, main, default. Pozosta│e tablice nie s╣ przeszukiwane automatycznie, znajduj╣ natomiast zastosowanie w rutingu rozszerzonym (policy routing).

Zasady nazewnictwa poszczeg≤lnych tablic nieco siΩ zmieni│y w kolejnych wersjach iproute2. W chwili obecnej odwzorowanie nazw na numery tablic jest definiowane w pliku /etc/iproute2/rt_tables. Domy£lnie znajduj╣ siΩ tam w│asnie take nazwy jak powy┐ej, nic nie stoi jednak na przeszkodzie, by definiowaµ i dodawaµ w│asne.

4.2   Obs│uga tablic rutingu.

Do operacji na tablicach tras s│u┐y polecenie ip route. Jego sk│adnia jest bardzo rozbudowana, wiΩc w tej sekcji ograniczymy siΩ tylko do om≤wienia g│≤wych funkcji polecenia ip route. Szczeg≤│owe om≤wienie parametr≤w znajduje siΩ w dodatku C.

Dodawanie oraz usuwanie tras z tablicy odbywa siΩ za pomoc╣ polecenia ip route add (lub del), kt≤rego argumentem jest specyfikacja trasy. W najprostszym przypadku sk│ada siΩ ona z adresu sieci docelowego oraz adresu rutera do tej sieci prowadz╣cego (next hop). Poni┐ej ograniczymy siΩ do om≤wienia mniej lub bardziej typowych przypadk≤w.

       ip route add 192.168.2.0/24 via 192.168.1.1
    Powy┐sze polecenie dodaje do g│≤wnej tablicy rutingu trasΩ prowadz╣c╣ do sieci 192.168.2.0/24 przez ruter o adresie 192.168.1.1.

       ip route add 192.168.2.0/24
         via 192.168.1.1 table default
    Dodaje tak╣ sam╣ trasΩ, ale do tablicy default.

      ip route add 0/0 via 192.168.0.1
    Dodaje trasΩ domy£ln╣ (default) przez ruter 192.168.0.1. Warto zwr≤ciµ uwagΩ na skr≤tow╣ formΩ zapisu sieci przeznaczenia 0.0.0.0/0, oznaczaj╣cej trasΩ domy£ln╣ i zapisanej skr≤towo jako 0/0.

      ip route add 10.1/16 via 192.168.1.1
        src 10.2.2.1
    Trasa, kt≤r╣ to polecenie dodaje nie jest tak interesuj╣ca jak wystΩpuj╣cy w nim parametr src. Powoduje on, ┐e pakiety wychodz╣ce z hosta t╣ tras╣, bΩd╣ mia│y adres ƒr≤d│owy ustawiony jako 10.2.2.1. Dotyczy to tylko pakiet≤w inicjowanych przez host lokalny (tj. przy po│╣czeniach wychodz╣cych).

Taka konfiguracja mo┐e byµ przydatna na przyk│ad je£li nasza sieµ jest pod│╣czona do kilku provider≤w (multi-homed) bez rutingu dynamicznego i chcemy by pakiety wysy│ane do jednego z nich wraca│y t╣ sam╣ tras╣. W przeciwnym razie wraca│yby one tras╣ podyktowan╣ przez adres ƒr≤d│owy wynikaj╣cy z adresu naszego g│≤wnego interfejsu.

       ip route add unreachable 10.1.2/24
    Specjalny rodzaj trasy. Pakiety kierowane do sieci docelowej 10.1.2.0/24 zostan╣ odrzucone, a w odpowiedzi zostanie odes│any komunikat ICMP ,,Host unreachable''. DostΩpne s╣ tak┐e inne tego rodzaju trasy: prohibit i blackhole. Pierwsza z nich zwraca pakiet ,,Packet administratively prohibited'', a druga usuwa pakiet bez zwracania ┐adnej informacji.

Trasy te mo┐na efektywnie wykorzystaµ przynajmniej na trzy sposoby:
  • Jako znacznie szybsze wersje czΩ£ci regu│ek filtruj╣cych firewall, co jest dok│adniej opisane w rozdziale 6 (str. X).
  • Do translacji adres≤w (Network Address Translation) przez trasΩ nat. Patrz rozdzia│ 5.3 (str. X).
  • Wykorzystanie trasy unreachable dla unikniΩcia pΩtli rutingu powstaj╣cych przy dynamicznie tworzonych interfejsach typu PPP. Przypadek ten jest dok│adniej opisany w dodatku 7.2 (str. X).

5   Ruting rozszerzony

5.1   WstΩp

W tradycyjnym modelu ruter dokonuje wyboru trasy tylko na podstawie adresu przeznaczenia pakietu. Kryteria wyboru trasy dla konkretnego pakietu, z kilku o r≤┐nym zasiΩgu, okre£la RFC 1812 [12]. Na przyk│ad, je£li w tablicy rutingu znajduj╣ siΩ dwie trasy -- jedna na podsieµ i druga na hosta w tej podsieci -- to pierwsze±stwo bΩdzie mia│a trasa bardziej szczeg≤│owa, na hosta. Jest to tzw. regu│a ,,najd│u┐szego dopasowania'' trasy (longest match). Pozosta│e regu│y wyboru tras przez ruter mo┐na znaleƒµ w sekcji 5.2.4.3 RFC 1812 [12].

Linux 2.2 spe│nia wszystkie zdefiniowane przez ten dokument wymagania wobec ruter≤w internetowych. Poza podstawowymi funkcjami posiada on potΩ┐ny mechanizm w postaci rutingu rozszerzoneg (policy routing).

5.2   Ruting rozszerzony

Routing rozszerzony pozwala na wybranie trasy wed│ug wymienionych poni┐ej selektor≤w, kt≤re mog╣ byµ │╣czone w dowolnych kombinacjach. Selektory te, jak widaµ, odpowiadaj╣ poszczeg≤lnym polom pakietu IP:

Parametr Selektor
Adres ƒr≤d│owy from
Adres docelowy to
Typ us│ugi (Type of Service) tos
Interfejs z kt≤rego przychodzi pakiet iif
Oznakowanie nadane przez firewall fwmark 6

Do ka┐dej regu│ki, bΩd╣cej grup╣ selektor≤w , przypisany jes priorytet (pref) oraz akcja. Priorytet okre£la kolejno£µ sprawdzania regu│ek -- regu│ki o ni┐szym priorytecie s╣ sprawdzane wcze£niej. Akcja jest to spos≤b w jaki zostanie potraktowany pakiet pasuj╣cy do danej regu│ki. DostΩpne s╣ nastΩpuj╣ce podstawowe akcje:

  • table TABLICA Pakiet jest kierowany wed│ug tradycyjnego algorytmu wyboru trasy, na podstawie tablicy rutingu okre£lanej identyfikatorem TABLICA.

  • nat SIEC/MM Adres ƒr≤d│owy pakietu jest t│umaczony na adres z sieci podanej w parametrze SIEC. Poniewa┐ t│umaczenie jest w stosunku 1:1, wiΩc rozmiar nowej sieci okre£lany mask╣ MM musi byµ taki sam jak rozmiar sieci t│umaczonej. Nale┐y podkre£liµ, ┐e za pomoc╣ rutingu rozszerzonego t│umaczy siΩ jedynie adresy ƒr≤d│owe pakiet≤w. Translacji w drug╣ stronΩ dokonuje siΩ za pomoc╣ odpowiedniego wpisu w tablicy rutingu, co jest opisane w sekcji 5.3 (str. X).

  • unreachable, prohibit, reject Odrzucaj╣ pakiety na r≤┐ne sposoby, analogicznie jak trasy specjalne opisane w sekcji 4.2 (str. X).

  • realms
Nale┐y pamiΩtaµ o dw≤ch rzeczach. Po pierwsze, regu│ka nakazuj╣ca przeszukiwanie tablicy local ma zawsze pierwsze±stwo i nie jest mo┐liwe zmiana jej priorytetu. Z tego powodu nie bΩd╣ dzia│aµ regu│ki w kt≤rych selektorem jest adres docelowy jednego z interfejs≤w danego hosta. Takie przypadki mo┐na jednak rozwi╣zaµ dodaj╣c stosown╣ trasΩ do tablicy local.

Po drugie, pierwsze±stwo maj╣ tak┐e trasy znajduj╣ce siΩ w tablicy cache. W zwi╣zku z tym, po dodaniu nowych regu│ek nale┐y tΩ tablice wyczy£ciµ poleceniem ip route flush table cache.

5.3   Translacja adres≤w

Linux umo┐liwia translacjΩ adres≤w IP na dwa sposoby:

  • dynamicznie, w stosunku ,,wiele do 1'',

  • statycznie, w stosunku ,,1 do 1''
Pierwszy algorytm by│ dostΩpny ju┐ w Linuxie 2.0 jako maskowanie adres≤w (masquerading). Jest to zaawansowana funkcja, pozwalaj╣ca na schowanie nawet bardzo du┐ej sieci komputer≤w posiadaj╣cych adresy prywatne (zdefiniowane w RFC 1918 [4]) za ruterem maskuj╣cym. Istnieje wiele opis≤w dzia│ania i konfiguracji maskowania adres≤w IP 7.

Linux 2.2 umo┐liwia tak┐e statyczne t│umaczenie adres≤w w stosunku 1 do 1. Oznacza to, ┐e okre£lonej podsieci adres≤w prywatnych musi byµ przyporz╣dkowana podsieµ adres≤w publicznych o tej samej wielko£ci. NAT jest realizowany na poziomie tablicy rutingu oraz rutingu rozszerzonego. T│umaczenie adres≤w ƒr≤d│owych i docelowych konfiguruje siΩ oddzielnie.

T│umaczenie adres≤w docelowych konfiguruje siΩ za pomoc╣ polecenia ip route i polega ono na stworzeniu specjalnej trasy nat. Sieµ docelowa okre£la zakres adres≤w, kt≤re maj╣ byµ t│umaczone, a adres rutera (via) jest pierwszym adresem z sieci na kt≤r╣ maj╣ byµ t│umaczone adresy docelowe. Trasa ta musi znaleƒµ siΩ w tablicy local:

        ip route add nat 192.168.1.0/24 via 195.116.211.0 table local
T│umaczenie adres≤w ƒr≤d│owych ustawia siΩ za pomoc╣ odpowiedniej regu│ki rutingu rozszerzonego. W tym wypadku selektor from okre£la sieµ, kt≤ra ma byµ t│umaczona, a akcja nat -- adres pierwszego adresu sieci, na kt≤r╣ maj╣ byµ t│umaczone adresy ƒr≤d│owe.

        ip rule add from 195.116.211.0/24 nat 192.168.1.0

6   Optymalizacja

Podczas projektowania oraz konfiguracji ruter≤w, maj╣cych obs│ugiwaµ du┐y ruch nale┐y braµ pod uwagΩ wydajno£µ systemu oraz op≤ƒnienia powstaj╣ce podczas przeszukiwania du┐ych tablic rutingu lub d│ugich list filtra pakiet≤w. Generalnie, przeszukiwanie tablic rutingu jest znacznie szybsze ni┐ przeszukiwanie regu│ek filtra. To pierwsze odbywa siΩ z pomoc╣ funkcji haszuj╣cych, podczas gdy drugie jest zwyk│ym przeszukiwaniem liniowym 8.

6.1   Filtrowanie za pomoc╣ tablicy rutingu

Filtrowanie pakiet≤w przy pomocy ipchains zu┐ywa wiΩcej czasu procesora ni┐ przeszukiwanie tablic rutingu. Je£li jedynymi kryteriami filtrowania s╣ adresy ƒr≤d│owe lub docelowe pakiet≤w IP, to optymalniejsze bΩdzie skorzystanie ze specjalnej trasy prohibit (opisanej w sekcji 4.2, str. X). Na przyk│ad, regu│kΩ ipchains:

    ipchains -A input -d 192.168.0.0/24 -j REJECT

Mo┐na zast╣piµ przez:

    ip route add prohibit 192.168.0.0/24

W przypadku regu│ek odrzucaj╣cych pakiety na podstawie adresu ƒr≤d│owego nale┐y skorzystaµ z rutingu rozszerzonego i polecenia ip rule add from.

6.2   Optymalizacja filtra pakiet≤w

Czas przeszukiwania listy regu│ek filtra pakiet≤w mo┐na zredukowaµ uk│adaj╣c je w odpowiedniej kolejno£ci. Dla ka┐dego sprawdzanego pakietu lista jest przeszukiwana od pocz╣tku a┐ do pierwszej pasuj╣cej do niego regu│ki.

Po pierwsze, przy pomocy zliczania pakiet≤w nale┐y okre£liµ kt≤re regu│ki maj╣ najwiΩcej trafie± i umie£ciµ je na pocz╣tku listy.

Po drugie, w przypadku protoko│u TCP mo┐na zaszczΩdziµ czas przeszukuj╣c tablicΩ tylko dla pakiet≤w rozpoczynaj╣c po│╣czenie (wyr≤┐nionych flag╣ SYN). Mo┐na to zrealizowaµ dodaj╣c na pocz╣tku listy regu│kΩ przepuszczaj╣c╣ wszystkie pakiety dla protoko│u TCP i nie opatrzone flag╣ SYN:

    ipchains -A forward -p tcp ! -y

6.3   Optymalizacja tablicy rutingu

Je£li tablica rutingu danego rutera posiada lub ma w za│o┐eniu posiadaµ wiΩcej ni┐ 100 pozycji, to podczas konfiguracji kernela nale┐y w│╣czyµ opcjΩ CONFIG_IP_ROUTE_LARGE_TABLES (Networking options, IP: Advanced router, IP: large routing tables). Spowoduje to przebudowanie struktur odpowiedzialnych za szybkie wyszukiwanie pozycji w tablicy podczas ka┐dego dodawania do niej nowych pozycji.

7   Dodatki

7.1   ZasiΩgi adres≤w

ZasiΩg (scope) mo┐na rozpatrywaµ w kontek£cie adres≤w interfejs≤w oraz tras. Jako standardowy element protoko│u IP zasiΩg adresu jest zdefiniowany jednoznacznie w IPv6 w RFC 2373 [8]. W adresie IPv6 zasiΩg determinuj╣ pierwsze 4 bity adresu. I tak, adres IPv6 moƒe posiadaµ nastΩpuj╣cy zasiΩg:

node--local
 
host--local
Adres lokalny oznaczaj╣cy tΩ sam╣ maszynΩ, tak jak adresy z klasy 127/8 w IPv4. Adres ten jest nadawany interfejsowi lokalnemu i nie mo┐e byµ przesy│any przez rutery.

link--local
Adres lokalny, obowi╣zuj╣cy wy│╣cznie w sieci lokalnej, do kt≤rej nale┐y dany host. Ka┐dy host IPv6 musi posiadaµ taki adres, konfigurowany automatycznie przez system w momencie aktywacji interfejsu sieciowego. Istnienie adres≤w typu link-local jest bardzo wygodne, poniewa┐ pozwala na komunikacjΩ miΩdzy hostami le┐╣cymi w jednej sieci lokalnej bez uprzedniego przydzielania i konfiguracji adres≤w. W oparciu o adresy link-local mo┐na tak┐e tworzyµ sieci prywatne, do kt≤rych w IPv4 s│u┐y│y klasy wydzielone z publicznej puli adres≤w (192.168/16 itp.). Pakiety z adresami o tym zasiΩgu nie mog╣ byµ przekazywane przez rutery.

site--local
Adres lokalny, obowi╣zuj╣cy w ramach administratcyjnie okre£lonej sieci prywatnej. Adresy o tym zasiΩgu nie s╣ konfigurowanie automatycznie i musz╣ byµ zdefiniowane przez administratora sieci. Jednak pakiety z adresami site-local mog╣ byµ przekazywane przez rutery, co pozwala na tworzenie sieci prywatnych obejmuj╣cych wiele segment≤w LAN.

global
Adresy publiczne.
W przypadku IPv4 j╣dro Linuxa r≤wnie┐ rozr≤┐nia zasiΩgi adres≤w, nie s╣ one jednak czΩ£ci╣ standardu tylko raczej przeniesieniem wygodnej metody rozr≤┐niania adres≤w z IPv6. Dla IPv4 j╣dro rozr≤┐nia nastΩpuj╣ce zasiΩgi:

host--local
Odpowiednik zasiΩgu host--local w IPv6, zarezerwowany dla adres≤w z klasy 127/8.

link--local
Odpowiednik zasiΩgu link--local w IPv6. W przypadku IPv4 zasiΩg ten jest nadawany adresowi warstwy │╣cza danego interfejsu, czyli np. adresowi MAC karty sieciowej w Ethernecie.

site--local
Odpowiednik zasiΩgu site-local w IPv6. Poniewa┐ jednak rezerwacja okre£lonych klas adres≤w IPv4 dla sieci prywatnych (RFC 1918 [4]) jest tylko umowna, zasiΩg site-local mo┐na nadaµ ka┐demu adresowi, chocia┐ sens ma nadawanie go tylko adresom z klas zarezerwowanych.

universe, global
Adresy publiczne.
Mo┐liwe jest definiowanie w│asnych warto£ci zasiΩg≤w. [11] podaje przyk│ad zasiΩgu dla tras wewn╣trzsieciowych (interior), kt≤rym przypisuje siΩ warto£µ zasiΩgu pomiΩdzy universe i link.

WiΩcej informacji na temat zasiΩg≤w mo┐na znaleƒµ w dokumentach RFC 2373 [8] , RFC 2374 [5] oraz RFC 2462 [7].

7.2   Wykorzystanie tras unreachable

Je£li mamy serwer dostΩpowy z pul╣ modem≤w, na kt≤re po£wiΩcamy Podsieµ okre£lonej wielko£ci, to z regu│y na g│≤wnym ruterze jest ustawiona trasa kieruj╣ca pakiety do tej podsieci na adres serwera dostΩpowego.

Je£li dany modem jest zajΩty to odpowiadaj╣cy mu adres IP posiada trasΩ w tablicy rutingu, kieruj╣c╣ pakiety do niego na przydzielony dynamicznie interfejs. Natomiast w momencie gdy jaki£ adres nie jest przydzielony wdzwaniaj╣cemu siΩ klientowi, pakiet przeznaczony na dany adres IP zostanie skierowany wed│ug trasy domy£lnej i wr≤ci do rutera. Ten z powrotem odbije go na serwer dostΩpowy, i tak a┐ do wyczerpania czasu ┐ycia (TTL) pakietu.

Je£li na serwerze dostΩpowym stworzymy trasΩ unreachable dla danej podsieci z -- co istotne -- du┐╣ miar╣ metric, to pakiety kierowane na nieaktywne w danym momencie adresy IP zostan╣ odrzucone z komunikatem ,,Host unreachable'', co bΩdzie zgodne z prawd╣.

7.3   Znakowanie pakiet≤w

Nowy kod filtra pakiet≤w Linuxa posiada przydatn╣ funkcjΩ znakowania pakiet≤w pasuj╣cych do danej regu│ki. Oznakowanie jest liczb╣ 32--bitow╣, kt≤rej warto£µ okre£la parametr -m polecenia ipchains. Najpro£ciej opisaµ to na przyk│adzie. Tworzymy odpowiedni │a±cuch:

# ipchains -A forward -p tcp -d 192.168.1.1/32 25 -j ACCEPT -m 0x1234
# ipchains -vL forward
Chain forward (policy ACCEPT: 315108 packets, 107748450 bytes):
pkts bytes target prot tosa tosx mark source destination ports
0 0 ACCEPT tcp 0xFF 0x00 0x1234 anywhere 192.168.1.1 any -> smtp


Wszystkie pakiety wysy│ane na port 25 hosta 192.168.1.1 zostan╣ przepuszczone (docelowy │a±cuch ACCEPT) oraz opatrzone znakiem 0x1234. Jak mo┐na wykorzystaµ takie oznakowanie? Jest to bardzo u┐yteczny mechanizm, pozwalaj╣cy na zmianΩ zachowania rutera (dzia│aj╣cego w warstwie sieci) wobec pakietu w zale┐no£ci od cech charakterystycznych dla protoko│≤w warstwy transportowej. Czyli przede wszystkim numer≤w port≤w protoko│≤w TCP oraz UDP, jak r≤wnie┐ typ≤w pakiet≤w ICMP. Mo┐na to wykorzystaµ przynajmniej na dwa sposoby:

  • W rutingu rozszerzonym, do kierowania r≤┐nymi trasami pakiet≤w nale┐╣cych do r≤┐nych protoko│≤w, za pomoc╣ parametru fwmark (patrz rozdzia│ 5.2, str. X).

  • W kontroli przep│ywu danych, do przydzia│u pasma oraz priorytet≤w w zale┐no£ci od protoko│u. S│u┐y do tego filtr fw oraz odpowiednio zdefiniowane oznaczenia pakiet≤w: identyfikatorowi przep│ywu 1:1 odpowiada oznaczenie 0x10001, 2:3 -- 0x20003 itd.

7.4   Weryfikacja adres≤w

Sekcja RFC 1812 [12] sugeruje, by rutery posiada│y mo┐liwo£µ weryfikacji, czy pakiet przychodz╣cy danym interfejsem posiada adres ƒr≤d│owy z sieci, kt≤ra jest przez ten interfejs rutowana.

Wyobraƒmy sobie, ┐e dany ruter posiada dwa interfejsy eth0 i eth1. Pierwszy z nich jest wyj£ciem na £wiat i skierowana jest na niego trasa domy£lna. Na drugi interfejs jest ustawiona trasa 195.116.2111.0/24, kieruj╣ca do znajduj╣cej siΩ za tym ruterem sieci LAN. W normalnej sytuacji pakiet z adresem ƒr≤d│owym z sieci 195.116.211.0/24 nie ma prawa pojawiµ siΩ na zewnΩtrznym interfejsie eth0. Pakiety z tej sieci mog╣ bowiem byµ generowane wy│╣cznie w sieci lokalnej, znajduj╣cej siΩ za intefejsem eth1.

Ruter posiadaj╣cy filtr zgodny z RFC 1812 powinien takie pakiety przechwytywaµ i kasowaµ. Z regu│y s╣ one efektem b│Ωdnej konfiguracji gdzie£ w odleg│ych zak╣tkach sieci lub -- co gorsza -- pr≤by przeprowadzenia ataku przez sfa│szowanie adres≤w IP (address spoofing).

W Linuxie weryfikacjΩ adres≤w w│╣cza siΩ za pomoc╣ interfejsu systcl, czyli zapisuj╣c odpowiedni╣ warto£µ w pliku znajduj╣cym siΩ w systemie plik≤w /proc. S╣ dostΩpne dwa poziomy weryfikacji -- silniejsza, w pe│ni zgodna z RFC 1812 (warto£µ 2) i s│absza, dotycz╣ca tylko sieci bezpo£rednio przy│╣czone do danego hosta (warto£µ 1). By zupe│nie wy│╣czyµ weryfikacjΩ adres≤w nale┐y zapisaµ warto£µ 0, tak jak w poni┐szym przyk│adzie:

        echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
Weryfikacji adres≤w nie nale┐y w│╣czaµ w okre£lonych wypadkach, kiedy mog│aby ona w og≤le uniemo┐liwiµ │╣czno£µ. Na przyk│ad, je£li ruting do jakiej£ sieci jest asymetryczny (pakiety wchodz╣ jednym interfejsem, wychodz╣ innym).

7.5   Ograniczenia prΩdko£ci odpowiedzi ICMP

Linux 2.2 posiada mo┐liwo£µ ograniczenia prΩdko£ci wysy│ania na okre£lone pakiety ICMP. Ma to na celu zmiejszenie przeci╣┐enia sieci, zasob≤w rutera oraz ograniczenie atak≤w polegaj╣cych na zalewaniu ofiary potokiem odpowiedzi na fa│szywy pakiet ICMP. Jest to funkcja zalecana przez RFC 1812 w punkcie 4.3.2.8.

W przypadku Linuxa limity okre£la siΩ przez podanie minimalnego odstΩpu czasowego pomiΩdzy dwoma odpowiedziami ICMP okre£lonego typu. Czas ten okre£la siΩ w jiffies, czyli podstawowej wewnΩtrznej jednostce czasu j╣dra Linuxa. W systemach opartych o procesory Intela i kompatybilne jest to 1/100 sekundy, a w przypadku procesor≤w Alpha -- 1/1024 sekundy.

Limitowaniu podlegaj╣ nastΩpuj╣ce pakiety ICMP wyliczone poni┐ej wraz z odpowiadaj╣cymi im pozycjami w sysctl:

  • Destination unreachable
    /proc/sys/net/ipv4/icmp_destunreach_rate

  • Parameter problem
    /proc/sys/net/ipv4/icmp_paramprob_rate

  • Time exceeded
    /proc/sys/net/ipv4/icmp_timeexceed_rate

  • Echo reply
    /proc/sys/net/ipv4/icmp_echoreply_rate
Wszystkie wy┐ej wymienione limity s╣ domy£lnie ustawione na 1 sekundΩ, za wyj╣tkiem icmp_echoreply_rate, kt≤re ma warto£µ 0 -- czyli brak limitu.

W praktyce dzia│anie limit≤w objawia siΩ na przyk│ad brakiem odpowiedzi na jedn╣ z pr≤bek polecenia traceroute, jak w poni┐szym przyk│adzie:

$ traceroute tau2
traceroute to tau2.ceti.com.pl (195.116.211.16), 30 hops max, 40 byte packets
 1  tau2 (195.116.211.16)  0.282 ms *  0.256 ms

References

[1]
David C. Plummer, ,,An Ethernet Address Resolution Protocol'', November 1982 (RFC 826)

[2]
Y. Rekhter, T. Li, ,,An Architecture for IP Address Allocation with CIDR'', September 1993 (RFC 1518)

[3]
V. Fuller, T. Li, J. Yu, K. Varadhan, ,,Classless Inter-Domain Routing (CIDR)'', September 1993 (RFC 1519)

[4]
Y. Rekhter et al., ,,Address Allocation for Private Internets'', February 1996 (RFC 1918)

[5]
R. Hinden, M. O'Dell, S. Deering, ,,An IPv6 Aggregatable Global Unicast Address Format'', July 1998 (RFC 2374)

[6]
W. Thomson, E. Nordmark, T. Narten, ,,Neighbor Discovery for IP Version 6 (IPv6)'', December 1998 (RFC 2461)
[7]
W. Thomson, T. Narten, ,,IPv6 Stateless Address Autoconfiguration'', December 1998 (RFC 2462)

[8]
R. Hinden, S. Deering, ,,IP Version 6 Addressing Architecture'', July 1998 (RFC 2373)
[9]
Alexey N. Kuznetsov, ,,IP Command Reference'', April 14, 1999
[10]
Olaf Kirch, ,,The Network Administrators' Guide''
[11]
include/linux/rtnetlink.h
[12]
F. Baker, ,,Requirements for IP Version 4 Routers'', June 1995, (RFC 1812)
[13]
H. Endre, ,,CPU consumption of Linux firewalls'', June 1999, http://dawn.elte.hu/ endre/meres/index-en.rxml
Copyright 1999 by Pawe│ Krawczyk <kravietz@ceti.pl>




Warunki dystrybucji




Kopiowanie w formie elektronicznej dozwolone wy│╣cznie w niezmienionej postaci, z zachowaniem informacji o autorze oraz warunkach dystrybucji i w celach niekomercyjnych. Przedruk oraz sprzeda┐ dozwolone wy│╣cznie za pisemn╣ zgod╣ autora.


UWAGA: obecna wersja ma jeszcze masΩ b│Ωd≤w, niedor≤bek i nie£cis│o£ci, wiΩc proszΩ czytaµ j╣ z krytycznym nastawieniem i nie wierzyµ we wszystko co napisa│em.


Uwagi, poprawki i rozszerzenia mile widziane.

1
Pawe│ Krawczyk, ,,Sterowanie przep│ywem danych w Linuxie 2.2''
2
Patrz http://www.whatis.com/anycast.htm
3
WiΩcej na temat zasiΩg≤w mo┐na przeczytaµ w Dodatku B.
4
FlagΩ NOARP maj╣ ustawion╣ automatycznie na przyk│ad intefejsy typu point-to-point (PPP, SLIP), interfejs dummy itp.
5
Dla intefejs≤w PP wielko£ci╣ domy£ln╣ jest 10 pakiet≤w. Alan Cox zaleca w takim wypadku zmniejszenie tej warto£ci do 3.
6
Patrz dodatek 7.3 (str. X)
7
Na przyk│ad ,,IP Masquerade mini HOWTO'', http://www.jtz.org.pl/Html/mini/IP-Masquerade.pl.html
8
Interesuj╣ce opracowanie na ten temat mo┐na znaleƒµ w pracy [13]
This document was translated from LATEX by HEVEA.


 

 

Wyślij E-mail MMalinow@bigfoot.com z pytaniami lub komentarzem.
Copyright ⌐ 2000 GroszNet Osiedlowa Sieµ Komputerowa
Ostatnia modyfikacja: March 01, 2000