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¢,
...
onlyprograms