Ruting IP w Linuxie 2.2
PaweŞ Krawczyk
<kravietz@ceti.pl>
30 maja 2000
Spis tre±ci
1 Wst¦p 2
1.1 O czym jest ten artykuŞ? . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Nowo±ci w jˇdrze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Nowo±ci w iproute2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Kon_guracja adresów interfejsów . . . . . . . . . . . . . . . . . . . . 3
2 Kon_guracja parametrów interfejsu 4
3 Komunikacja hostów w obr¦bie sieci lokalnej 5
3.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 ObsŞuga tablicy sˇsiadów . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Ruting 6
4.1 Wst¦p. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Obsªuga tablic rutingu. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Ruting rozszerzony 8
5.1 Wst¦p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Ruting rozszerzony . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Translacja adresów . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Optymalizacja 10
6.1 Filtrowanie za pomocˇ tablicy rutingu . . . . . . . . . . . . . . . . . 10
6.2 Optymalizacja _ltra pakietów . . . . . . . . . . . . . . . . . . . . . . 11
6.3 Optymalizacja tablicy rutingu . . . . . . . . . . . . . . . . . . . . . . 11
1
7 Dodatki 11
7.1 Zasi¦gi adresów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 Wykorzystanie tras unreachable . . . . . . . . . . . . . . . . . . . . 12
7.3 Znakowanie pakietów . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4 Wery_kacja adresów . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.5 Ograniczenia pr¦dko±ci odpowiedzi ICMP . . . . . . . . . . . . . . . . 14
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 kon_guracji 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 (tra_c 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.
1PaweŞ Krawczyk, ˙Sterowanie przepŞywem danych w Linuxie 2.2"
2
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 _lozo_ˇ 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 pre_ksu i adres hosta. W konsekwencji
wy»ej opisana notacja maski podsieci odpowiada po prostu dŞugo±ci pre_ksu
w bitach.
1.4 Kon_guracja 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 agˇ secondary, a
nie samodzielnymi pseudo_intefejsami, 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±˘
pre_ksu (maski podsieci).
Wprzypadku 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 pre_ksu.
Adres anycast stosowany w IPv6 ustawia sie parametrem anycast. 2
2Patrz http://www.whatis.com/anycast.htm
3
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 zde_niowanego 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 ifcon_g.
2 Kon_guracja parametrów interfejsu
Dodanie adresu do interfejsu nie powoduje jego automatycznej aktywacji (aga UP)
Jest to zachowanie odmienne od znanego z jˇder 2.0 Do kon_gurowania 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
3Wi¦cej na temat zasi¦gów mo»na przeczyta˘ w Dodatku B.
4Flag¦ NOARP majˇ ustawionˇ automatycznie na przykŞad intefejsy typu point-to-point (PPP,
SLIP), interfejs dummy itp.
4
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 _zycznej (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 wery_kacji 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 _zycznych 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
5Dla intefejsów PP wielko±ciˇ domy±lnˇ jest 10 pakietów. Alan Cox zaleca w takim wypadku
zmniejszenie tej warto±ci do 3.
5
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 Con_guring 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 zde_niowanych 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 tra_ajˇ
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.Wszczegó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 de_niowane
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 de_niowa˘ i dodawa˘ wŞasne.
6
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 specy_kacja 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 kon_guracja 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 _ltrujˇcych _rewall, co jest dokŞadniej opisane w
rozdziale 6 (str. 10).
7
_ Do translacji adresów (Network Address Translation) przez tras¦ nat. Patrz rozdziaŞ 5.3
(str. 9).
_ 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. 12).
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 zde_niowane 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 _rewall 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 identy_katorem TABLICA.
8
_ 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. 9).
_ unreachable, prohibit, reject Odrzucajˇ pakiety na ró»ne sposoby, analogicznie
jak trasy specjalne opisane w sekcji 4.2 (str. 7).
_ 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 (IP
masquerading). Jest to zaawansowana funkcja, pozwalajˇca na schowanie nawet bardzo
du»ej sieci komputerów posiadajˇcych adresy prywatne (zde_niowane w RFC
1918 [4]) za ruterem maskujˇcym. Istnieje wiele opisów dziaŞania i kon_guracji 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 kon_guruje si¦ oddzielnie.
TŞumaczenie adresów docelowych kon_guruje si¦ za pomocˇ polecenia ip route i
polega ono na stworzeniu specjalnej trasy nat. Sie˘ docelowa okre±la zakres adresów,
7Na przykŞad ˙IP Masquerade mini HOWTO", http://www.jtz.org.pl/Html/mini/IPMasquerade.
pl.html
9
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
Trzeba pami¦ta˘, »e translacja adresów skon_gurowana w ten sposób dziaŞa wy-
Şacznie dla pakietów rutowanych przez dany system, czyli wchodzˇcych jednym interfejsem
i wychodzˇcych innym. W szczególno±ci nie obejmuje ona pakietów generowanych
przez sam ruter, czyli na przykŞad poŞˇcze« wychodzˇcych z tego rutera. Adres
ąródŞowy takich poŞˇcze« mo»na zde_niowa˘ natomiast przy pomocy parametru src
polecenia ip route, który jest opisany w rozdziale 4.2 na stronie 7.
6 Optymalizacja
Podczas projektowania oraz kon_guracji 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 _ltra pakietów. Generalnie, przeszukiwanie
tablic rutingu jest znacznie szybsze ni» przeszukiwanie reguŞek _ltra. 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 _ltrowania 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. 7). 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.
8Interesujˇce opracowanie na ten temat mo»na znaleą˘ w pracy [13]
10
6.2 Optymalizacja _ltra pakietów
Czas przeszukiwania listy reguŞek _ltra 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 tra_e« 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 agˇ SYN). Mo»na
to zrealizowa˘ dodajˇc na poczˇtku listy reguŞk¦ przepuszczajˇcˇ wszystkie pakiety
dla protokoŞu TCP i nie opatrzone agˇ 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 kon_guracji 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 zde_niowany 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, kon_gurowany 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
kon_guracji adresów.Woparciu 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
11
(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ˇ kon_gurowanie automatycznie i musz
ˇ by˘ zde_niowane 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 de_niowanie 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
12
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 _ltra 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. 8).
_ W kontroli przepŞywu danych, do przydziaŞu pasma oraz priorytetów w zale»no-
±ci od protokoŞu. SŞu»y do tego _ltr fw oraz odpowiednio zde_niowane oznaczenia
pakietów: identy_katorowi przepŞywu 1:1 odpowiada oznaczenie 0x10001,
2:3 { 0x20003 itd.
7.4 Wery_kacja adresów
Sekcja RFC 1812 [12] sugeruje, by rutery posiadaŞy mo»liwo±˘ wery_kacji, czy pakiet
przychodzˇcy danym interfejsem posiada adres ąródŞowy z sieci, która jest przez ten
interfejs rutowana.
13
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 _ltr zgodny z RFC 1812 powinien takie pakiety przechwytywa˘
i kasowa˘. Z reguŞy sˇ one efektem bަdnej kon_guracji gdzie± w odlegŞych zakˇtkach
sieci lub { co gorsza { próby przeprowadzenia ataku przez sfaŞszowanie adresów IP
(address spoo_ng).
W Linuxie wery_kacj¦ 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 wery_kacji { 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˘ wery_kacj¦ adresów nale»y zapisa˘ warto±˘ 0, tak
jak w poni»szym przykŞadzie:
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
Wery_kacji 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 o_ary potokiem odpowiedzi na faŞszywy pakiet
ICMP. Jest to funkcja zalecana przez RFC 1812 [12] 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 ji_es, 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
14
_ 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
15
Bibliogra_a
[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 Autocon_guration", 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 _rewalls", June 1999,
http://dawn.elte.hu/ endre/meres/index-en.rxml
16
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.
17