Linux Advanced Routing & Traffic Control HOWTO
Шрифт:
Рассмотрим простой пример. Предположим, что имеется сеть из нескольких компьютеров. В ней находятся компьютеры 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-кэша можно просмотреть так:
Как видите, мой компьютер espa041 (9.3.76.41) "знает", как найти компьютер espagate (9.3.76.1). А теперь добавим еще один адрес в наш кэш:
В результате попытки взаимодействия компьютера espa041 с espa043, ethernet-адрес последнего был добавлен в кэш. По истечении некоторого тайм аута (если между этими двумя компьютерами больше не было передано ни одного пакета), espa041 "забудет" адрес компьютера espa043 и для того чтобы что-то сообщить ему, опять потребуется послать ARP-запрос.
Удалим адрес компьютера espa043 из кэша:
Теперь espa041 "забыл" адрес компьютера espa043. Если espa041 опять "захочет" что-то сообщить espa043, он будет вынужден вновь послать ARP-запрос. В этом листинге также видно, что в записи для espagate (9.3.76.1), состояние reachable (доступно) изменилось на stale (устарело). Это означает, что ethernet-адрес все еще является допустимым, но он должен быть подтвержден при первой же попытке обмена.
Глава 4. Правила — база политик маршрутизации
Если ваш маршрутизатор обслуживает сложную сеть, то нужно удовлетворять нужды разных людей, обслуживание которых, вероятно, должно отличаться. База политик маршрутизации позволяет реализовать это с помощью набора таблиц маршрутизации.
Если вы хотите использовать эту возможность, убедитесь что ядро собрано с поддержкой "IP: advanced router" и "IP: policy routing".
Когда ядру необходимо выбрать маршрут, оно определяет в соответствии с какой таблицей это нужно делать. По-умолчанию, определены три таблицы. Старая утилита route изменяет таблицы main и local, как и утилита ip (по-умолчанию).
Правила по-умолчанию:
В этом листинге приведены приоритеты всех правил. Мы видим, что правила применяются ко всем пакетам (from all). Мы уже видели таблицу 'main', она выводится командой ip route ls , но таблицы 'local' и 'default' для нас новые.
Если мы хотим сделать что-то интересное, то нужно задать правила, использующие разные таблицы маршрутизации. Это позволит нам переопределить общесистемную таблицу маршрутизации.
За точной семантикой происходящего в ядре, когда есть несколько подходящих правил, обратитесь к документации ip-cref Алексея Кузнецова.
4.1. Простая маршрутизация по источнику.
Давайте опять рассмотрим реальный пример. У меня есть 2 (вообще-то 3, пора бы вернуть их) кабельных модема, подключенных к маршрутизатору Linux с NAT ('masquerading'). Люди с которыми я живу в одном доме, платят мне за использование Internet. Допустим одни из моих соседей ходит только на hotmail и хочет платить меньше. Мне это подходит, но при этом будет использоваться медленный канал.
Быстрое соединение имеет с моей стороны адрес 212.64.94.251, а с другой — 212.64.94.1. Медленное соединение получает динамический адрес, в данном примере это 212.64.78.148, адрес провайдера — 195.96.98.253.
Таблица local: