Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
- Название:Linux Advanced Routing & Traffic Control HOWTO
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO краткое содержание
Оригинальную версию документа вы найдете по адресу http://lartc.org/.
Практическое руководство по применению iproute2 (и в меньшей степени netfilter) для управления трафиком.
Linux Advanced Routing & Traffic Control HOWTO - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Взглянем поближе на интерфейс eth0 . Из листинга видно, что ему назначен адрес "inet" — 10.0.0.1/8, где "/8" определяет число бит, соответствующих адресу сети. Таким образом, для адресации хостов в сети у нас остается 32 – 8 = 24 бита, что соответствует адресу сети – 10.0.0.0 и маске сети – 255.0.0.0.
Это говорит о том, что любой хост в этой сети, например 10.250.3.13, будет непосредственно доступен через наш интерфейс с IP-адресом 10.0.0.1.
Для ppp0 применима та же концепция, хотя числа в IP-адресе отличаются. Ему присвоен адрес — 212.64.94.251, без маски сети. Это означает, что он обслуживает соединение типа "точка-точка" (point-to-point), и что каждый адрес, за исключением 212.64.94.251, является удаленным. Но и это еще не все. Для этого интерфейса указывается адрес другого конца соединения — 212.64.94.1. Здесь число "/32" говорит о том, что это конкретный IP-адрес и он не содержит адреса сети.
Очень важно, чтобы вы поняли суть этой концепции. Если у вас возникают какие либо затруднения, обращайтесь к документации, упомянутой в начале этого HOWTO Linux Advanced Routing & Traffic Control HOWTO Bert Hubert, Thomas Graf, Gregory Maxwell, Remco van Mook, Martijn van Oosterhout, Paul B Schroeder, Jasper Spaans, Pedro Larroy Глава 1. Посвящение. Посвящается большому количеству людей. Перечислим лишь некоторых из них: • Rusty Rassel • Алексею Н. Кузнецову • Отличным ребятам из Google • Сотрудникам из Casema Internet.
.
Вы наверняка обратили внимание на слово "qdisc". Оно обозначает дисциплину обработки очереди (Queueing Discipline). Позднее мы коснемся этой темы подробнее.
3.4.3. Просмотр списка маршрутов с помощью утилиты ip
Итак, мы теперь знаем, как можно отыскать адреса 10.x.y.z, и как обратиться к адресу 212.64.94.1. Однако этого недостаточно, поскольку нам необходимо иметь возможность общения с внешним миром. Интернет доступен нам через ppp-соединение, которое объявляет, что хост с адресом 212.64.94.1, готов передать наши пакеты во внешний мир и вернуть результаты обратно.
[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
Этот листинг достаточно "прозрачен". Первые 3 строки сообщают сведения, которые нами уже обсуждались выше. Последняя строка говорит о том, что внешний мир доступен через 212.64.94.1 — шлюз, заданный по-умолчанию. То что это шлюз, видно благодаря наличию слова "via" (в переводе с англ. — "через"). Этот шлюз (с адресом 212.64.94.1) готов перенаправлять наши пакеты в Интернет и возвращать обратно результаты наших запросов.
Для примера, более "старая" утилита 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 — Address Resolution Protocol (Протокол Определения Адреса) описан в
RFC 826. Он используется для определения ethernet-адреса по IP-адресу. Машины в Интернет более известны под именами, которые преобразуются в IP-адреса, благодаря чему узел сети, скажем с именем foo.com, имеет возможность связаться с другой машиной, например с именем bar.net. Но в ethernet-сетях для адресации используется не IP-адрес, а ethernet-адрес и здесь на сцену выходит протокол ARP.Рассмотрим простой пример. Предположим, что имеется сеть из нескольких компьютеров. В ней находятся компьютеры foo , с адресом 10.0.0.1 и bar , с адресом 10.0.0.2. Пусть foo хочет послать пакет ICMP Echo Request ( ping) компьютеру bar , чтобы проверить — работает ли он, но увы, foo не знает ethernet-адрес компьютера bar . Таким образом, прежде чем ping-ануть bar , foo должен отослать ARP-запрос. Этот запрос очень похож на то, что обычно кричит человек, пытаясь отыскать в толпе своего товарища: "Bar (10.0.0.2)! Ты где?". В результате все машины в сети услышат "крик" foo , но только bar (10.0.0.2) откликнется на него, послав обратно ARP-ответ, который можно трактовать как: "Foo (10.0.0.1)! Я — здесь! Мой адрес 00:60:94:E9:08:12.". После этой "переклички" foo будет знать ethernet-адрес компьютера bar и сможет связаться с ним, пока опять не "забудет" (в кэше ARP) адрес компьютера bar (обычно записи в ARP-кэше удаляются через 15 минут).
Содержимое ARP-кэша можно просмотреть так:
[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
Как видите, мой компьютер espa041 (9.3.76.41) "знает", как найти компьютер espagate (9.3.76.1). А теперь добавим еще один адрес в наш кэш:
[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
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
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
В результате попытки взаимодействия компьютера espa041 с espa043 , ethernet-адрес последнего был добавлен в кэш. По истечении некоторого тайм аута (если между этими двумя компьютерами больше не было передано ни одного пакета), espa041 "забудет" адрес компьютера espa043 и для того чтобы что-то сообщить ему, опять потребуется послать ARP-запрос.
Удалим адрес компьютера espa043 из кэша:
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 nud failed
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 stale
Теперь espa041 "забыл" адрес компьютера espa043 . Если espa041 опять "захочет" что-то сообщить espa043 , он будет вынужден вновь послать ARP-запрос. В этом листинге также видно, что в записи для espagate (9.3.76.1), состояние reachable (доступно) изменилось на stale (устарело). Это означает, что ethernet-адрес все еще является допустимым, но он должен быть подтвержден при первой же попытке обмена.
Глава 4. Правила — база политик маршрутизации
Если ваш маршрутизатор обслуживает сложную сеть, то нужно удовлетворять нужды разных людей, обслуживание которых, вероятно, должно отличаться. База политик маршрутизации позволяет реализовать это с помощью набора таблиц маршрутизации.
Если вы хотите использовать эту возможность, убедитесь что ядро собрано с поддержкой "IP: advanced router" и "IP: policy routing".
Когда ядру необходимо выбрать маршрут, оно определяет в соответствии с какой таблицей это нужно делать. По-умолчанию, определены три таблицы. Старая утилита routeизменяет таблицы main и local, как и утилита ip(по-умолчанию).
Правила по-умолчанию:
[ahu@home ahu]$ ip rule list
0: from all lookup local
32766: from all lookup main
Интервал:
Закладка: