Рис. 6.27. Перенаправление маршрутов
Данная возможность может использоваться для упрощения процедуры формирования таблицы маршрутизации. Например, рабочие станции могут хранить только маршрут по умолчанию (в сеть 0), адресующий соседний шлюз. При передаче данных хостам той же сети, что и источник, шлюз будет информировать последний о перенаправлении маршрутов, позволяя тем самым заполнить элементы маршрутизационной таблицы.
Функция
rtredirect()
вызывается с параметрами, указывающими на адрес получателя, новый адрес шлюза, который необходимо миновать для достижения адресата, а также источник перенаправления маршрута. Заметим, что сообщения о перенаправлении маршрута принимаются только от текущего шлюза для данного получателя. Если существует маршрут, отличный от маршрута по умолчанию, то для него изменяется поле
rt_gateway
согласно указанному в сообщении новому адресу шлюза. В противном случае создается новая запись таблицы маршрутизации.
Вопросы определения маршрутов в UNIX являются прерогативой специальных прикладных процессов, а не ядра операционной системы. Ядро размещает и хранит необходимую маршрутизационную информацию, а также обеспечивает интерфейс доступа к этой информации. Процесс имеет возможность добавить или удалить маршрут с помощью системного вызова ioctl(2). Для добавления маршрута используется команда
SIOCADDRT
, а для удаления —
SIOCDELRT
.
В качестве процессов, отвечающих за заполнение таблиц маршрутизации и ее динамическое обновление, можно назвать стандартный демон routed(1M), использующий протокол RIP (Routing Information Protocol) для динамического определения и обновления маршрутов, а также демон gated(1M), поддерживающий работу нескольких протоколов обмена маршрутизационной информацией (RIP, OSPF, BGP).
Текущую таблицу маршрутизации можно увидеть, воспользовавшись командой netstat(1M):
$ netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
------------ ------------- ----- --- ----- ---------
127.0.0.1 127.0.0.1 UH 0 5054 lo0
194.85.160.0 194.85.160.50 U 3 30926 le0
default 194.85.160.1 UG 0 47150 le0
Первая запись таблицы показывает маршрут для псевдохоста (localhost) логической сети операционной системы. Следующий маршрут адресует непосредственно подключенную к интерфейсу (его адрес 194.85.160.50) сеть (194.85.160.0). Наконец, последняя запись определяет маршрут по умолчанию, направляя все пакеты, адресованные получателям "внешнего мира", для которых наш хост не знает конкретных маршрутов, на шлюз с адресом 194.85.160.1, который обладает большей информацией о возможных маршрутах.
Реализация TCP/IP
Прежде чем перейти к описанию функционирования модулей протоколов TCP/IP, рассмотрим еще одну структуру данных, называемую управляющим блоком протокола (Protocol Control Block, PCB), который в случае TCP/IP называется Internet PCB, и представлен структурой
inpcb
, определенной в файле
<netinet/in_pcb.h>. Вид структуры
inpcb
показан на рис. 6.28.
Рис. 6.28. Структуры данных протоколов TCP/IP
Эта структура создается для каждого активного сокета TCP или UDP и содержит информацию, необходимую для текущих транзакций протокола, такую как IP-адреса источника и получателя (
inp_laddr
и
inp_faddr
), номера портов (
inp_lport
и
inp_fport
), маршрутизационной информации (
inp_route
). TCP создает дополнительный управляющий блок, где хранятся данные, необходимые для работы этого протокола (такие как порядковые номера, номера подтверждений и т.д.)
Управляющие блоки размещаются в виде связанного списка, отдельного для TCP и UDP. Модули протокола имеют в своем распоряжении набор функций для создания, поиска и удаления управляющего блока. Модуль IP демультиплексирует сообщения на основании номера протокола, указанного в заголовке датаграммы, а протокол транспортного уровня, в свою очередь, производит поиск требуемого управляющего блока для доставки данных протоколам более высокого уровня (приложений).
Перейдем теперь к описанию взаимодействия рассмотренных модулей в сетевой подсистеме BSD UNIX (рис. 6.29).
Рис. 6.29. Сетевая подсистема BSD UNIX
Модуль IP
Сетевой интерфейс получает пакеты данных из сети и передает их соответствующему модулю сетевого уровня на основании информации, содержащейся в заголовке кадра уровня канала. В данном разделе мы не будем рассматривать поддержку различных сетевых протоколов, а остановимся только на взаимодействии с протоколом IP. В этом случае полученные пакеты помещаются в очередь приема модуля IP. После этого с помощью программного прерывания вызывается процедура
ip_input()
, которая поочередно извлекает пакеты из очереди и обрабатывает их. После обработки на основании информации заголовка IP-датаграммы данные либо передаются протоколу транспортного уровня, либо уничтожаются, если в данных обнаружена ошибка, либо передаются другому интерфейсу для последующей отправки фактическому адресату. В последнем случае система выполняет роль шлюза.
Датаграмма считается адресованной данному хосту, если адрес получателя совпадает с одним из адресов интерфейса данного хоста, или адрес получателя является широковещательным (или групповым) адресом данной сети. В случае получения фрагментированной датаграммы модуль производит ее реассемблирование. Для этого отдельные фрагменты собираются в специально организованной очереди, пока не будет сформирована исходная датаграмма. После этого данные передаются транспортному протоколу. Для демультиплексирования модуль IP использует поле
Protocol
заголовка, которое по существу является индексом таблицы, каждый элемент которой представлен коммутатором протокола, рассмотренного ранее в этой главе. Соответственно модуль IP имеет возможность непосредственно вызвать функцию
pr_input()
требуемого протокола следующего уровня.
В случае, когда полученная датаграмма не содержит ошибок, но не адресована данному хосту, она, возможно, должна быть передана на другой сетевой интерфейс для последующей передачи фактическому адресату. Эта процедура носит название шлюзования (forwarding) и включает выполнение следующих шагов:
□ Производится проверка разрешения шлюзования. [87] В случае отрицательного результата хост не может выполнять функции шлюза и данные уничтожаются.
□ Производится проверка адреса получателя. Если адрес датаграммы не принадлежит адресному пространству сетей класса А, В или С, такие данные не могут быть переданы. [88]
□ Определяется дальнейший маршрут передачи датаграммы.
□ Если дальнейший путь датаграммы проходит через тот же интерфейс, с которого она была получена, и хост-отправитель расположен в той же сети, ему отправляется сообщение ICMP REDIRECT.
