Route flags ugh что значит

Маршрутизация Openvpn.

Всем привет! Возникла странная, на первый взгляд, задача. Объясню суть. Имеется Openvpn сервер, имеется Openvpn-клиент. И тот и другой на Debian 8. Подсеть vpn — 10.18.0.0. На клиент пробрасывается подсеть сервера, допустим 192.168.1.0. Таблица маршрутизации на клиенте:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 внешний_ip 0.0.0.0 UG 0 0 0 eth0

10.18.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0

внешний_ip 0.0.0.0 255.255.255.248 U 0 0 0 eth0

192.16.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2

192.168.1.0 10.18.0.1 255.255.255.0 UG 0 0 0 tap0

В кое-каких целях, необходимо, чтобы последняя строка, где флаг UG, была с флагом U. Если поменять последний маршрут командой

route add -net 192.168.1.0 netmask 255.255.255.0 dev tap0

то получается, но пингов до компьютеров в сети 192.168.1.0 нет, за исключением самого сервера 192.168.1.1, где стоит openvpn-server. Вопрос: каким образом добиться одного флага U, и при этом пинговать всю подсеть 1.0, предоставляемую openvpn-сервером? Спасибо

Вот этой командой:

да, согласен, но. Вот кусочек таблицы с сервера, который работает в данный момент: 192.168.1.0 * 255.255.255.0 U 0 0 0 tap0

Просто, суть в том, что необходимо заменить старый пк (клиент) на новый, сохранив работоспособность, и на текущем клиенте все работает, и маршрут, который относится к openvpn, именно такой. Я сам не пойму, как оно работает, но если там будет флаг G, то будут проблемы с кое-каким ПО.

Нарисуй текущую схему сетей, со шлюзами, с учётом VPN сети.

гм. про утиль «route» нужно забыть. Мы не в 90-х годах. iproute2 наше все.

То, что ты хочешь «route add -net 192.168.1.0 netmask 255.255.255.0 dev tap0» была с флагом U без G — очень странно. Маршрут без G — это прямой маршрут, т.е. сеть непосредственно подключенная к этому роутеру, а это не так.

tap обычно используется с «topology subnet» т.е. это локальная сеть, а не p2p, следовательно для подключения сети клиента нужно знать его IP т.е. gateway и этим обычно рулят с сервера в его конфиге через «route 192.168.1.0 255.255.255.0 xxx.xxx.xxx.xxx» + ccd «iroute 192.168.1.0 255.255.255.0»

В кое-каких целях, необходимо, чтобы последняя строка, где флаг UG, была с флагом U.

В каких же это, интересно? G говорит о том, что данная подсеть не локальная, доступ в неё через шлюз (Gateway).

гм. про утиль «route» нужно забыть. Мы не в 90-х годах. iproute2 наше все.

И что же такое страшное произойдёт, если пользоваться route и ifconfig вместо ip?

Вообще если ты хочешь, чтобы эта сеть у тебя была локальная, то тебе нужен бриджинг с ней, то есть OpenVPN-сервер должен подключать клиентов сразу к 192.168.1.0/24, а не к 10.18.0.0/24.

Но схему сети привести, как уже предложили, не помешает, да.

Если трафик роутится, то зачем tap?

Страшного не произойдет.Про ifconfig я ничего не говорил.

route не знает про такие параметры маршрута как: scope, tos, src, table и протокол через который был установлен маршрут. если используется policy-routing, то без table & src жить невозможно. Наличие контейнеров так же заставляет использовать «ip ro»

В отличии от ifconfig, который научили использовать /masklen в адресе, route до сих пор нужно указывать -net в случае добавления сети (а это наиболее распространенное действие) и лишнее слово netmask перед маской в старинной нотации. Для сети маска присутствует обязательно аж с 94 года!

и лишнее слово netmask перед маской в старинной нотации.

Можно в сокращённом виде писать, зачем старинную нотацию использовать? Вот так работает:

route не нужно использовать, а следует ip route. Во многих дистрибутивах его уже давно нет, как и остальных программ из net-tools, вроде ifconfig.

Мыло-мочало, начинай сначала. Тыц.

Except for the patch mass that Debian accumulated, the net-tools package has not seen any upstream development after version 1.60, released sometime about April 15 2001.

Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes. Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly. Ifconfig is obsolete! For replacement check ip.

ifconfig makes secondary addresses look like separate interfaces

People often get the impression that labeled secondary addresses are a separate interface (thanks to the dumb output of ifconfig, as a result of ioctl limitations), which in fact is not the case. You cannot use eth0:1 in iptables nor iproute2, so do not even think of eth0:1 being an interface on its own.

Similarly, you cannot set flags on these “interfaces”.

Сосёт — это несомненно. Ты мне расскажи лучше, чем мешает его использование, если работает нормально.

Источник

Route flags ugh что значит

Глава 9 IP маршрутизация

Маршрутизация — это одна из наиболее важных функций IP. На рисунке 9.1 показана упрощенная модель того, что реализуется на IP уровене. Датаграммы, которые должны быть смаршрутизированы, могут генерироваться как локальным хостом, так и каким-либо удаленным хостом. В последнем случае наш хост должен быть сконфигурирован как маршрутизатор, иначе датаграммы, получаемые через сетевые интерфейсы и не предназначенные нашему хосту, будут молча удалены.

На рисунке 9.1 также показан демон маршрутизации, который обычно является пользовательским процессом. Наиболее часто в Unix системах используются демоны routed и gated. Термин демон (daemon) означает, что процесс работает «в фоновом режиме» и его функционирование не оказывает влияние на систему в целом. Демоны обычно стартуют, когда система загружается, и живут все время, пока система работает. Протоколы маршрутизации, используемые на конкретном хосте, определяют, как будет происходить обмен информацией о маршрутах с удаленными маршрутизаторами. (Заинтересованные читатели могут обратиться к [ Perlman 1992] для получения более подробной информации.) Мы вкратце рассмотрим динамическую маршрутизацию и протокол обмена информацией о маршрутизации (RIP — Routing Information Protocol) в главе 10. В этой главе мы рассмотрим, как IP уровень принимает решения о маршрутизации.

IP уровень обращается к таблице маршрутизации, которая показана на рисунке 9.1 (на загруженных хостах подобное обращение может происходить несколько сот раз в секунду), однако демон маршрутизации обновляет таблицу значительно реже (примерно один раз каждые 30 секунд). Таблица маршрутизации также может быть обновлена, когда принимается ICMP сообщение о перенаправлении (ICMP redirect), мы увидим это в разделе «ICMP ошибки перенаправления», когда будем рассматривать команду route. Эта команда обычно исполняется при загрузке системы и устанавливает некоторые исходные маршруты. Также в этой главе мы будем использовать команду netstat, для просмотра таблиц маршрутизации.

Рисунок 9.1 Действия, выполняемые IP уровнем.

Прежде чем начать обсуждение IP маршрутизации, необходимо понять, что именно ядро обновляет в таблице маршрутизации. Информация, содержащаяся в таблице маршрутизации, необходима IP уровню для принятия решения о маршрутизации. В разделе «IP маршрутизация» главы 3 мы показали, каким образом IP просматривает свою таблицу маршрутизации.

Поиск совпадающего адреса хоста.
Поиск совпадающего адреса сети.
Поиск пункта по умолчанию. (Пункт по умолчанию обычно указывается в таблице маршрутизации как сеть с идентификатором сети равным нулю.)

Совпавший адрес хоста используется всегда перед совпавшим адресом сети.

Маршрутизация, осуществляемая IP — процесс поиска в таблице маршрутизации, определение интерфейса, куда будет послан пакет, называется механизмом маршрутизации. С другой стороны, политика маршрутизации устанавливает правила, по которым решается, какой маршрут будет внесен в таблицу маршрутизации. IP осуществляет механизм маршрутизации, тогда как маршрутизирующий демон обычно определяет политику маршрутизации.

Простая таблица маршрутизации

Давайте рассмотрим типичные таблицы маршрутизации. На хосте svr4 мы запустили команду netstat с опцией -r, чтобы просмотреть таблицу маршрутизации, и с опцией -n, которая печатает IP адреса в цифровом формате, а не в виде имен. (Мы сделали это, потому что некоторые пункты таблицы маршрутизации это сети, а не хосты. Без опции -n команда netstat просматривает файл /etc/networks, и берет оттуда имена сетей. При этом может получиться некоторая путаница, потому что в выводе команды помимо имен хостов появятся имена сетей.)

svr4 % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 0 emd0
127.0.0.1 127.0.0.1 UH 1 0 lo0
default 140.252.13.33 UG 0 0 emd0
140.252.13.32 140.252.13.34 U 4 25043 emd0

В первой строке говорится, что для пункта назначения 140.252.13.65 (хост slip) шлюз (маршрутизатор), на который будут посылаться пакеты, это 140.252.13.35 (bsdi). Хост slip подсоединен к bsdi через SLIP канал, а bsdi находится в той же сети Ethernet, что и данный хост.

Для конкретного маршрута может быть показано 5 различных флагов.

Маршрут подключен к шлюзу (маршрутизатору). Если этот флаг не установлен, считается, что пункт назначения подключен непосредственно.

Маршрут ведет к хосту, что означает, что в качестве пункта назначения используется полный адрес хоста. Если этот флаг не установлен, то маршрут указывает на сеть, что в свою очередь означает, что пунктом назначения является адрес сети: идентификатор сети или комбинация идентификатора сети и идентификатора подсети.

Маршрут был модифицирован посредством перенаправления («ICMP ошибки перенаправления»).

Флаг G очень важен, потому что именно этот флаг определяет различие между непрямым маршрутом (indirect route) и прямым маршрутом (direct route). (Флаг G не устанавливается для прямого маршрута.) Отличие заключается в том, что у пакета, направляющегося по прямому маршруту, IP адрес и адрес канального уровня указывают на конечный пункт назначения (рисунок 3.3). Когда пакет отправляется по непрямому маршруту, IP адрес указывает на конечный пункт назначения, а адрес канального уровня указывает на маршрутизатор следующей пересылки. Мы видели подобный пример этого на рисунке 3.4. В этой таблице маршрутизации мы видим непрямой маршрут (флаг G установлен), при этом IP адрес пакета, который будет передаваться по этому маршруту, будет совпадать с IP адресом конечного пункта назначения (140.252.13.65), а адрес канального уровня будет указывать на соответствующий маршрутизатор, IP адрес которого 140.252.13.35.

Очень важно понимать разницу между флагами G и H. Флаг G определяет различие между прямым и непрямым маршрутом, как описано выше. Флаг H указывает на то, что адрес пункта назначения (первая колонка вывода команды netstat) это полный адрес хоста. Отсутствие флага H означает, что адрес назначения это адрес сети (идентификатор хоста должен быть установлен в 0). При просмотре таблицы маршрутизации используются следующие правила: если маршрут указывает на хост он должен полностью совпадать с IP адресом пункта назначения, если маршрут указывает на сеть — сопасть должны идентификаторы сети и любого идентификатора подсети в адресе пункта назначения. Большинство версий команды netstat сначала печатают все пункты, указывающие на хосты, после чего печатаются пункты, указывающие на сети.

Колонка счетчика обращений (reference count) сообщает о количестве использований каждого маршрута. Протоколы, ориентированные на соединения, такие как TCP, занимают маршрут все время, пока соединение установлено. Если установить Telnet соединение между хостами svr4 и slip, то счетчик обращений будет установлен в 1. Если установить еще одно Telnet соединение, счетчик будет показывать 2, и так далее.

Следующая колонка (use) показывает количество пакетов, прошедших по этому маршруту. Если запустить программу ping, которая отправит 5 пакетов, счетчик установится в значение 5 (Естественно, при условии, что никто больше не использует этот маршрут). Последняя колонка интерфейс (interface) сообщает нам имя локального интерфейса.

Вторая строка в выводе относится к loopback интерфейсу (глава 2, раздел «Интерфейс Loopback»), который всегда имеет имя lo0. Флаг G не установлен, так как маршрут не ведет к маршрутизатору. Флаг H указывает, что адрес назначения (127.0.0.1) это адрес хоста, а не адрес сети. Когда флаг G не установлен, это указывает на прямой маршрут, в колонке gateway указывается IP адрес исходящего интерфейса.

Третья строка вывода описывает маршрут по умолчанию. Каждый хост должен иметь один или несколько маршрутов по умолчанию. Этот пункт указывает на то, что необходимо посылать пакеты на маршрутизатор 140.252.13.33 (sun), если не был найден конкретный маршрут. Это означает, что хост svr4 может получить доступ к другим системам в Internet через маршрутизатор sun (и его SLIP канал) воспользовавшись этим единственным пунктом таблицы маршрутизации. Возможность установить маршрут по умолчанию это одна из наиболее мощных концепций IP маршрутизации. Флаги для этого маршрута (UG) говорят о том, что маршрут указывает на маршрутизатор.

Здесь мы специально назвали sun маршрутизатором, а не хостом, потому что когда он работает как маршрутизатор по умолчанию, используются его функции IP перенаправления, при этом он не выступает в роли хоста.

Требования к хостам Host Requirements RFC указывает, что IP уровень должен поддерживать несколько маршрутов по умолчанию. Большинство реализаций, однако, этого не позволяют. Когда существует несколько маршрутов по умолчанию, общая техника выбора маршрута заключается в последовательном многократном переборе маршрутов. Именно так поступает, например, Solaris 2.2.

И последняя строка указывает на подключенный Ethernet. Флаг H не установлен, это указывает на то, что адрес назначения (140.252.13.32) это адрес сети, при этом идентификатор хоста установлен в 0. И действительно, 5 младших битов установлены в 0 (рисунок 3.11). Это прямой маршрут (флаг G не установлен), поэтому в колонке gateway указывается IP адрес исходящего интерфейса.

Существует еще один немаловажный аспект, оказывающий влияние на маршрутизацию, однако он не отражен в выводе команды netstat. Это маска подсети, связанная с адресом назначения (140.252.13.32). Когда адрес пункта назначения сравнивается с IP адресом 140.252.13.33, адрес перед сравнением, логически суммируется с маской подсети, связанной с этим адресом назначения (0xffffffe0 из раздела «Пример подсети» главы 3). Так как ядро знает каждый интерфейс, связанный с каждым пунктом таблицы маршрутизации, и так как каждый интерфейс имеет маску подсети, каждый пункт таблицы маршрутизации имеет собственную маску подсети.

Сложность таблицы маршрутизации хоста зависит от топологии сетей, к которым хост имеет доступ.

Самый простой (однако наименее интересный) случай — это когда хост вообще не подключен к сетям. Протоколы TCP/IP могут использоваться на этом хосте, однако только для общения с самим собой! Таблица маршрутизации в данном случае содержит единственный пункт соответствующий loopbackv интерфейсу.
Хост подключен к одной локальной сети и имеет возможность получить доступ к хостам только в этой локальной сети. Таблица маршрутизации имеет 2 пункта: один для loopback интерфейса и один для локальной сети (например, Ethernet).
Возможен вариант, когда другие сети (например, Internet) доступны через один маршрутизатор. В этом случае обычно используется пункт по умолчанию, указывающий на этот маршрутизатор.
И последнее, когда добавляются маршруты к хостам или сетям. Примером этого может служить маршрут к хосту slip через маршрутизатор bsdi.

Давайте проследим за тем, что делает IP когда обращается к таблице маршрутизации, чтобы смаршрутизировать пакеты на хосте svr4.

Предположим, что адрес назначения принадлежит хосту sun, 140.252.13.33. Во-первых, осуществляется поиск совпадающего адреса хоста. Два пункта хостов в таблице (slip и localhost) не совпадают, поэтому поиск в таблице маршрутизации осуществляется снова на предмет совпадающего адреса сети. Совпадение найдено в пункте 140.252.13.32 (идентификатор сети и идентификатор подсети совпали), поэтому используется интерфейс emd0. Это прямой маршрут, поэтому адрес канального уровня будет являться адресом назначения.
Предположим, что адрес назначения это адрес хоста slip, 140.252.13.65. Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается успешно. Это непрямой маршрут, поэтому IP адрес назначения остается 140.252.13.65, а адресом канального уровня будет адрес канального уровня маршрутизатора 140.252.13.35, используется интерфейс emd0.
Теперь мы посылаем датаграмму по Internet на хост aw.com (192.207.117.2). Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается неудачей, поэтому осуществляется поиск на предмет совпадающего адреса сети. Он также завершается неудачно. И последний шаг это поиск пункта по умолчанию, который заканчивается успешно. Маршрут является непрямым через маршрутизатор 140.252.13.33 с использованием интерфейса emd0.
В нашем последнем примере мы послали датаграмму на свой собственный хост. Существует 4 способа сделать это, используя имя хоста, IP адрес хоста, loopback имя или loopback IP адрес:

ftp svr4
ftp 140.252.13.34

ftp localhost
ftp 127.0.0.1

В двух первых случаях второй поиск в таблице маршрутизации приведет к совпадению с сетью 140.252.13.32, и пакет посылается через Ethernet драйвер. Как мы показали на рисунке 2.4, пакет, предназначенный на собственный IP адрес хоста, посылается в loopback драйвер, который ставит пакет во входную очередь IP.

В двух следующих случаях указано имя loopback интерфейса или его IP адрес, поэтому первый поиск в таблице маршрутизации приведет к совпадению адреса хоста, и пакет отсылается в loopback драйвер, который ставит его во входную очередь IP.

Во всех четырех случаях пакет отправляется в loopback драйвер, однако принимаются два разных решения о маршрутизации.

Инициализация таблицы маршрутизации

Мы никогда не упоминали о том, как создаются пункты в таблице маршрутизации. Когда инициализируется интерфейс (обычно, когда адрес интерфейса устанавливается командой ifconfig), автоматически создается прямой маршрут для этого интерфейса. Для каналов точка-точка и loopback интерфейса устанавливается маршрут к хосту (то есть устанавливается флаг H). Для широковещательных интерфейсов, таких как Ethernet, маршрутом является сама эта сеть.

Маршруты к хостам или сетям, которые не подключены непосредственно, должны быть помещены в таблицу маршрутизации каким-либо иным образом. Самый распространенный способ создания маршрутов — с помощью команды route, что обычно делается из загрузочных файлов при старте системы. На хосте svr4 были исполнены следующие команды, которые добавляют пункты, показанные ранее:

route add default sun 1
route add slip bsdi 1

Третий аргумент (default и slip) это пункты назначения, четвертый аргумент это маршрутизатор (gateway) и последний аргумент это показатель маршрутизации. Команда route использует показатель маршрутизации следующим образом: она устанавливает флаг G, если показатель больше чем 0, и не устанавливает флаг G, если показатель равен 0.

К сожалению, совсем немногие системы содержат команды route в своих стартовых файлах. В 4.4BSD и BSD/386 это /etc/netstat, в SVR4 — /etc/inet/rc.inet, в Solaris 2.x — /etc/rc2.d/S69inet, в SunOS 4.1.x — /etc/rc.local и в AIX 3.2.2 — /etc/rc.net.

В некоторых системах маршрутизатор по умолчанию содержится в файле, например, /etc/defaultrouter. Этот пункт по умолчанию добавляется в таблицу маршрутизации при каждой перезагрузке.

Существует еще один способ заполнить таблицу маршрутизации с помощью запуска демона маршрутизации (см. главу 10) или с помощью нового протокола определения маршрутов (раздел «ICMP сообщения поиска маршрутизатора»).

Более сложные таблицы маршрутизации

Хост sun является маршрутизатором по умолчанию для всех хостов в нашей подсети, так как он имеет SLIP канал с дозвоном, который подключен к Internet (см. рисунок на внутренней стороне обложки).

sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 171 le0
127.0.0.1 127.0.0.1 UH 1 766 lo0
140.252.1.183 140.252.1.29 UH 0 0 sl0
default 140.252.1.183 UG 1 2955 sl0
140.252.13.32 140.252.13.33 U 8 99551 le0

Первые два пункта таблицы маршрутизации sun идентичны первым двум пунктам для хоста svr4: маршрут, указывающий на хост slip, через маршрутизатор bsdi и loopback маршрут.

Третья строка отличается. Это прямой маршрут (флаг G не установлен) на хост (флаг H установлен), соответствующий каналу точка-точка, интерфейс SLIP. Если мы посмотрим на вывод команды ifconfig,

sun % ifconfig sl0
sl0: flags=1051
inet 140.252.1.29 —> 140.252.1.183 netmask ffffff00

то увидим, что адрес назначения в таблице маршрутизации на другом конце канала точка-точка (маршрутизатор netb), а адрес маршрутизатора в действительности это локальный IP адрес исходящего интерфейса (140.252.1.29). (Раньше мы говорили, что для прямых маршрутов адрес маршрутизатора печатается командой netstat как локальный IP адрес используемого интерфейса.)

Пункт по умолчанию это непрямой маршрут (флаг G), указывающий на сеть (нет флага H). Адрес маршрутизатора — 140.252.1.183, (адрес на другом конце SLIP канала), а не локальный IP адрес SLIP интерфейса (140.252.1.29) (так как это непрямой маршрут).

Необходимо обратить внимание на то, что третья и четвертая строки в выводе команды netstat (интерфейс sl0) создаются программным обеспечением SLIP при установлении канала SLIP, они удаляются, когда канал SLIP отключается.

Нет маршрута к пункту назначения

Во всех наших примерах сделано предположение, что поиск в таблице маршрутизации заканчивается успешно и будет обнаружено соответствие, хотя бы с маршрутором по умолчанию. Что произойдет, если маршрут по умолчанию отсутствует, и не будет найдено совпадение с указанным пунктом назначения?

Ответ зависит от того, какого рода IP датаграмма обрабатывается, то есть была ли она сгенерирована непосредственно этим хостом или она должна быть перенаправлена (в том случае, если хост выступает в роли маршрутизатора). Если датаграмма была сгенерирована этим хостом, приложению, которое отправило датаграмму, возвращается ошибка «хост недоступен» (host unreachable) или «сеть недоступна» (network unreachable). Если датаграмма должна быть перенаправлена, посылающему хосту возвращается ICMP собщение о недоступности хоста. Мы рассмотрим эту ошибку в следующем разделе.

ICMP ошибки о недоступности хоста и сети

ICMP ошибка о недоступности хоста (host unreachable) отправляется маршрутизатором, когда он получает IP датаграмму, которую невозможно перенаправить. (На рисунке 6.10 мы показали формат ICMP сообщений о недоступности.) Мы сможем пронаблюдать это в нашей сети, если выключим SLIP канал с дозвоном на маршрутизаторе sun и попробуем отправить пакет через SLIP канал с любого другого хоста, указав sun как маршрутизатор по умолчанию.

Ранние реализации TCP/IP в BSD генерировали и ошибки о недоступности хоста, и ошибки о недоступности сети, в зависимости от того, принадлежал ли пункт назначения локальной подсети или нет. 4.4BSD генерирует только ошибку о недоступности хоста.

Обратимся снова к выводу команды netstat запущенной на маршрутизаторе sun, вывод показан в предыдущем разделе. Мы видим, что пункт таблицы маршрутизации, который соответствует SLIP каналу, добавляется, когда SLIP канал включается, и удаляется, когда SLIP канал выключается. Это означает, что когда SLIP канал отключен, маршрута по умолчанию на sun не существует. Однако мы не будем пытаться изменить все таблицы маршрутизации у хостов в нашей маленькой сети, оставив им возможность самим удалить свои маршруты по умолчанию. Вместо этого мы посчитаем ICMP сообщения о недоступности хоста, сгенерированные sun для любых пакетов, которые он не может перенаправить.

Мы можем увидеть это, запустив ping с svr4 на хост, находящийся на другом конце SLIP канала (в настоящее время этот хост выключен):

svr4 % ping gemini
ICMP Host Unreachable from gateway sun (140.252.13.33)
ICMP Host Unreachable from gateway sun (140.252.13.33)
^? символ прерывания

На рисунке 9.2 мы показали вывод команды tcpdump для этого примера. (Команда запущена на хосте bsdi).

1 0.0 svr4 > gemini: icmp: echo request
2 0.00 (0.00) sun > svr4: icmp: host gemini unreachable

3 0.99 (0.99) svr4 > gemini: icmp: echo request
4 0.99 (0.00) sun > svr4: icmp: host gemini unreachable

Рисунок 9.2 Сообщение ICMP о недоступности хоста в ответ на ping.

Когда маршрутизатор sun обнаруживает, что на хост gemini нет маршрута, он отвечает на эхо запрос сообщением о недоступности хоста.

Если мы включим SLIP канал, подключающий нас к Internet, и попробуем послать ping на несуществующий в Internet IP адрес, то рано или поздно получим сообщение об ошибке. Интересно посмотреть, как далеко уйдет пакет по Internet, перед тем как будет получена ошибка:

sun % ping 192.82.148.1 этот IP адрес не подключен к Internet
PING 192.82.148.1: 56 data bytes
ICMP Host Unreachable from gateway enss142.UT.westnet.net (192.31.39.21)
for icmp from sun (140.252.1.29) to 192.82.148.1

Обратившись к рисунку 8.5, мы увидим, что пакет прошел через шесть маршрутизаторов, перед тем как было определено, что IP адрес не существует. Только когда он дошел до пределов NSFNET магистрали, была выявлена ошибка. Это произошло из-за того, что шесть маршрутизаторов, которые перенаправляли пакет, отправляли его на пункт назначения по умолчанию. И только когда пакет достиг NSFNET магистрали, маршрутизатор, имеющий полное представление о каждой сети, подключенной к Internet, смог определить ошибку. Это иллюстрирует тот факт, что большинство маршрутизаторов функционируют, не представляя себе полной топологии сетей.

[Ford, Rekhter, and Braun 1993] определяет домены маршрутизации верхнего уровня (top-level routing domain) как маршрутизаторы, поддерживающие и обрабатывающие информацию о большинстве узлов Internet и не использующие маршрутов по умолчанию. В Internet существует пять доменов маршрутизации верхнего уровня: NFSNET магистраль, Commercial Internet Exchange (CIX), NASA Science Internet (NSI), SprintLink и European IP Backbone (EBONE).

Перенаправлять или не перенаправлять

Мы уже несколько раз упоминали о том, что хост не сможет перенаправить IP датаграммы, если он специально не сконфигурирован, чтобы выступать в роли маршрутизатора. Как осуществляется подобная конфигурация?

Большинство Berkeley реализаций, имеют переменную ядра, названную ipforwarding (или похоже). (См. приложение Е.) Некоторые системы ( BSD/386 и SVR4, например) перенаправляют датаграммы, если эта переменная установлена в ненулевое значение. В SunOS 4.1.x определено три значения для этой переменной: -1 обозначает, что перенаправление никогда не будет осуществляться и что никогда нельзя будет сменить значение этой переменной, 0 обозначает, что перенаправление не осуществляется, однако значение переменной устанавливается в 1, когда два или более интерфейсов активизированы, и 1 обозначает, что перенаправление осуществляется всегда. У Solaris 2.x также существует три значения, а именно 0 (перенаправление не осуществляется), 1 (перенаправление осуществляется всегда) и 2 (перенаправление осуществляется только тогда, когда активизированы два или более интерфейсов).

В более ранних реализациях 4.2BSD датаграммы перенаправляются по умолчанию. При этом, если система сконфигурирована неверно, возникает очень много проблем. Именно поэтому данная опция ядра должна быть всегда по умолчанию установлена в значение «без перенаправления» (never forward), пока системный администратор специально не включит перенаправление.

ICMP ошибки перенаправления

ICMP ошибка перенаправления отправляется маршрутизатором на хост, пославший IP датаграмму, когда датаграмма должна быть послана на другой маршрутизатор. Подобная концепция довольно проста. Мы привели три составные части этой концепции на рисунке 9.3. Увидеть ICMP перенаправление можно только когда хост имеет выбор, на какой маршрутизатор послать пакет. (Обратитесь к примерам, которые мы приводили на рисунке 7.6.)

Предположим, что хост посылает IP датаграмму на R1. Подобное решение принято потому, что R1 — это маршрутизатор по умолчанию для этого хоста.
R1 принимает датаграмму, просматривает свою таблицу маршрутизации, и определяет, что маршрутизатором следующей пересылки является R2, и именно туда необходимо отправить датаграмму. Когда R1 отправляет датаграмму на R2, он определяет, что отправляет ее на тот же самый интерфейс, с которого датаграмма была получена (локальная сеть, к которой подключен хост и два маршрутизатора). В этом случае маршрутизатор отправляет ошибку перенаправления на хост, пославший датаграмму.
R1 посылает ICMP перенаправление на хост, сообщая тем самым, что следующие датаграммы необходимо посылать на R2 вместо R1.

Рисунок 9.3 Пример ICMP перенаправления.

Перенаправления используются для того, чтобы позволить хосту с минимальным знанием о маршрутах поддерживать и обновлять свою таблицу маршрутизации. Как правило, формирование таблицы маршрутизации хоста начинается с создания маршрута по умолчанию (R1 или R2 из нашего примера на рисунке 9.3), при этом с использованием перенаправления хост может обновить свою таблицу маршрутизации. ICMP перенаправление позволяет TCP/IP хостам полностью полагаться на интеллектуальность маршрутизаторов в вопросе выбора маршрутов. Маршрутизаторы R1 и R2 в нашем примере должны точно представлять топологию подключенных сетей, тогда как хосты, подключенные к локальной сети, могут начинать свою маршрутизацию с маршрута по умолчанию, узнавая затем более подробно о новых маршрутах из принятых перенаправлений.

Посмотрим ICMP перенаправления в действии на примере нашей сети (на внутренней стороне обложки). Мы показали всего три хоста (aix, solaris и gemini) и два маршрутизатора (gateway и netb) в верхней части сети, в действительности там более 150 хостов и 10 маршрутизаторов. Большинство хостов считают gateway маршрутизатором по умолчанию, так как он предоставляет доступ к Internet.

Как можно получить доступ из подсети 140.252.1 к нижней подсети (4 нижние хоста на рисунке)? Во-первых, вспомним, что если на конце SLIP канала находится единственный хост, используется уполномоченный агент ARP (глава 4, раздел «Уполномоченный агент ARP»). Это означает, что для хостов в верхней сети 140.252.1 не требуется специальных средств, для того чтобы получить доступ к хосту sun (140.252.1.29). Доступ обеспечит программное обеспечение уполномоченного агента ARP на netb.

Однако, если на удаленном конце SLIP канала присутствует сеть, то необходима маршрутизация. Одно из возможных решений заключается в том, чтобы каждый хост и маршрутизатор знали о том, что маршрутизатор netb является шлюзом в сеть 140.252.13. Этого можно добиться путем внесения статического маршрута в каждую таблицу маршрутизации на каждом хосте или запустив на каждом хосте маршрутизирующий демон. Однако существует более простой способ (метод, который обычно используется) — использовать ICMP перенаправление.

Запустим программу ping с хоста solaris в верхней сети на хост bsdi (140.252.13.35) в нижней сети. Так как идентификаторы подсети различны, уполномоченный агент ARP не может быть использован. Предположим, что статический маршрут не установлен, поэтому при посылке первого пакета будет использован маршрут по умолчанию на маршрутизатор gateway. Ниже мы приводим таблицу маршрутизации, перед тем как запустили ping:

solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
————— ————— ——- — ——- —————
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.1.0 140.252.1.32 U 3 15042 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5747

(Пункт 224.0.0.0 используется для групповой адресации IP. Мы опишем это в главе 12.) Если указать опцию -v в командной строке ping, то будут видны все ICMP сообщения принятые хостом. Нам необходимо указать эту опцию, чтобы увидеть сообщения о перенаправлении, которые будут посланы.

solaris % ping -sv bsdi
PING bsdi: 56 data bytes
ICMP Host redirect from gateway gateway (140.252.1.4)
to netb (140.252.1.183) for bsdi (140.252.13.35)
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=383. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=364. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=2. time=353. ms
^? символ прерывания
—-bsdi PING Statistics—-
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 353/366/383

Перед тем как мы получим первый ответ на ping, хост примет ICMP перенаправление от маршрутизатора по умолчанию gateway. Если мы затем посмотрим таблицу маршрутизации, то увидим, что появился новый маршрут к хосту bsdi. (Этот пункт выделен жирным шрифтом.)

solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
————— ————— ——— — ——- ————-
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.13.35 140.252.1.183 UGHD 0 2
140.252.1.0 140.252.1.32 U 3 15045 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5749

Pltcmm мы впервые видиv флаг D, который означает, что маршрут был установлен с использованием ICMP перенаправления. Флаг G обозначает, что это непрямой маршрут к шлюзу (netb), а флаг H обозначает, что это маршрут к хосту (как мы и ожидали), а не маршрут к сети.

Так как это маршрут к хосту, добавленный путем перенаправления, он обслуживает только хост bsdi. Если затем мы попробуем получить доступ к хосту svr4, будет сгенерировано еще одно перенаправление, и будет создан еще один маршрут к хосту. Точно так же, попытка получить доступ к хосту slip создаст еще один маршрут. Каждое перенаправление на конкретный хост приводит к созданию нового маршрута к хосту. Все три хоста в подсети (bsdi, svr4 и slip) будут обслуживаться одним маршрутом к сети, указывающим на маршрутизатор sun. Однако, ICMP перенаправления создают маршруты к хостам, а не маршруты к сетям, так как маршрутизатор, генерирующий перенаправление в данном примере (gateway), не имеет представления о структуре подсетей в сети 140.252.13.

На рисунке 9.4 показан формат сообщения ICMP о перенаправлении.

Рисунок 9.4 ICMP сообщение о перенаправлении.

Существуют четыре различных типа сообщений о перенаправлении, с различными значениями кода (code), как показано на рисунке 9.5.

Описание

0 перенаправление для сети

1 перенаправление для хоста

2 перенаправление для типа сервиса (TOS) и сети

3 перенаправление для типа сервиса (TOS) и хоста

Рисунок 9.5 Различные значения code для ICMP перенаправления.

Существуют три IP адреса, которые должен знать получатель ICMP перенаправления: (1) IP адрес, который вызвал перенаправление (находится в IP заголовке, возвращенном как данные в ICMP сообщении о перенаправлении), (2) IP адрес маршрутизатора, который послал перенаправление (является IP адресом источника IP датаграммы, содержащей перенаправление) и (3) IP адрес маршрутизатора, который должен быть использован (находится в байтах с 4-го по 7-ой в ICMP сообщении).

Существует несколько правил, посвященных ICMP перенаправлениям. Во-первых, перенаправления генерируются только маршрутизаторами, ни в коем случае не хостами. Однако, перенаправления могут быть использованы только хостами, не маршрутизаторами. Считается, что маршрутизаторы используют протоколы маршрутизации и обмениваются таблицами с другими маршрутизаторами, поэтому они не нуждаются в перенаправлениях. (Это означает, что на рисунке 9.1 таблица маршрутизации должна быть обновлена либо с использованием маршрутизирующего демона, либо с использованием перенаправления, однако не с использованием и того и другого.)

Когда 4.4BSD функционирует как маршрутизатор, осуществляются следующие проверки, причем каждая из них должна быть истиной, для того чтобы было сгенерировано ICMP перенаправление.

Исходящий и входящий интерфейс один и тот же.
Маршрут, который будет использоваться для исходящей датаграммы, не должен быть создан или модифицирован с использованием ICMP перенаправления. Также он не должен быть маршрутом по умолчанию для маршрутизатора.
Датаграмма не должна быть смаршрутизирована от источника.
Ядро должно быть сконфигурировано таким образом, чтобы посылать перенаправления.

Переменная ядра с именем ip_sendredirects (или похожим). (См. приложение Е.) Большинство современных систем (4.4BSD, SunOS 4.1.x, Solaris 2.x и AIX 3.2.2, например) включают эту переменную по умолчанию. Другие системы, например, SVR4, имеют эту переменную по умолчанию выключенной.

В дополнение, хост 4.4BSD, который принимает ICMP перенаправления, осуществляет некоторые проверки перед модификацией своей таблицы маршрутизации. Это предотвращает странное поведение маршрутизатора или хоста, вызванное некорректной модификацией таблицы маршрутизации системы.

Новый маршрутизатор должен быть в непосредственно подключенной сети.
Перенаправление должно быть от текущего маршрутизатора на указанный пункт назначения.
Перенаправление не может заставить хост использовать самого себя в качестве маршрутизатора.
Модифицируемый маршрут должен быть непрямым маршрутом.

И в заключение стоит повториться, что маршрутизаторы должны посылать только перенаправления к хостам (codes 1 или 3 на рисунке 9.5), а не перенаправления к сетям. Из-за разделения на подсети не всегда можно однозначно указать, когда должно быть послано перенаправление к сети вместо перенаправления к хосту. Некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, в том случае если маршрутизатор послал неверный тип (type).

ICMP сообщения поиска маршрутизатора (ICMP Router Discovery Messages)

Ранее в этой главе мы говорили, что одним из способов инициализации таблицы маршрутизации является создание статических маршрутов, которые заносятся в конфигурационные файлы. Подобный метод часто используется для установки маршрута по умолчанию. Существует способ, заключающийся в использовании ICMP объявлений маршрутизаторов.

Основной принцип заключается в том, что после загрузки хост рассылает широковещательные или групповые запросы с требованием сообщить ему о маршрутизаторе. Один или несколько маршрутизаторов отвечают с использованием сообщения об объявлении маршрутизатора. В дополнение, маршрутизаторы периодически рассылают широковещательные или групповые сообщения с объявлением маршрутизатора, позволяя каждому хосту, который примет эти сообщения, обновить свои таблицы маршрутизации.

RFC 1256 [Deering 1991] содержит формат этих ICMP сообщений. На рисунке 9.6 показан формат ICMP сообщения запроса маршрутизатора. На рисунке 9.7 показан формат ICMP сообщения объявления маршрутизатора, которое рассылается маршрутизаторами.

В одном сообщении маршрутизатор может объявить несколько адресов. Поле количества адресов. Размер записи адреса — количество 32-битных слов для каждого адреса маршрутизатора, оно всегда установлено в 2. Время жизни — количество секунд, в течение которого данное объявление адресов считается действительным.

Рисунок 9.6 Формат ICMP сообщения запроса маршрутизатора.

Рисунок 9.7 Формат ICMP сообщения объявления маршрутизатора.

Затем следует одна или несколько пар IP адресов. IP адрес должен быть одним из адресов посылающего маршрутизатора. Уровень предпочтительности — это 32-битное целое число со знаком, указывающее на предпочтительность этого адреса в качестве адреса маршрутизатора по умолчанию, по сравнению с другими адресами маршрутизаторов в той же подсети. Большее значение указывает на большую предпочтительность адреса. Уровень предпочтительности 0x80000000 указывает на то, что соответствующий адрес, несмотря на то что он объявлен, не должен быть использован получателем в качестве адреса маршрутизатора по умолчанию. Обычное значение предпочтительности это 0.

Когда маршрутизатор стартует, он начинает периодически рассылать объявления на все интерфейсы, которые поддерживают групповой и широковещательный тип адресации. В действительности эти объявления не периодические, они рассылаются случайным образом. Это сделано для того, чтобы объявления не перемешивались и не синхронизировались с другими маршрутизаторами в той же подсети. Обычный интервал между объявлениями составляет от 450 до 600 секунд. Время жизни по умолчанию для каждого объявления составляет 30 минут.

Поле времени жизни также используется, когда интерфейс маршрутизатора выключается. В этом случае маршрутизатор может передать последнее объявление с временем жизни, установленным в 0.

Помимо периодических объявлений, маршрутизатор отвечает на запросы от хостов. Он отвечает на запросы объявлением маршрутизатора.

Если в одной подсети существует несколько маршрутизаторов, задача системного администратора сконфигурировать уровень предпочтительности для каждого маршрутизатора. Например, основной маршрутизатор по умолчанию должен иметь более высокий уровень предпочтительности по отношению к запасному маршрутизатору.

При старте хост обычно посылает три запроса о поиске маршрутизатора с интервалом в 3 секунды. После того как принято объявление от маршрутизатора, запросы прекращаются.

Хост также слушает объявления от маршрутизатора. Эти объявления могут привести к смене маршрутизатора по умолчанию для данного хоста. Если объявление не получено для текущего маршрута по умолчанию, он может быть удален по тайм-ауту.

Пока текущий маршрутизатор по умолчанию функционирует, он отправляет объявления каждые 10 минут с временем жизни в 30 минут. Это означает, что маршрут по умолчанию в таблице маршрутизации хоста не будет удален по тайм-ауту, даже если одно или два объявления будут потеряны.

Сообщения о поиске маршрутизатора обычно генерируются и обрабатываются пользовательскими процессами (демонами). Поэтому добавляется еще один программный способ обновления таблицы маршрутизации к тем, что показаны на рисунке 9.1, несмотря на то, что он может добавить или удалить только пункт по умолчанию. Демон должен быть сконфигурирован так, чтобы выступать либо в роли маршрутизатора, либо в роли хоста.

Эти два ICMP сообщения достаточно новы и поддерживаются не всеми системами. В нашей сети их поддерживает только Solaris 2.x (демон in.rdisc). Несмотря на то, что RFC рекомендует использовать групповую адресацию IP, где это возможно, поиск маршрутизаторов может осуществляться с использованием широковещательных сообщений.

IP маршрутизация это краеугольный камень, на котором держится функционирование систем, использующих TCP/IP, будь то хост или маршрутизатор. Записи в таблице маршрутизации довольно просты: до 5 флаговых битов, IP адрес назначения (хост, сеть или по умолчанию), IP адрес маршрутизатора следующей пересылки (для непрямого маршрута) или IP адрес локального интерфейса (для прямого маршрута) и указатель на используемый локальный интерфейс. Записи, соответствующие хостам, имеют более высокий приоритет, чем записи, соответствующие сетям, а оба типа записей имеют более высокий приоритет по сравнению с маршрутом по умолчанию.

Просмотр таблицы маршрутизации осуществляется для каждой IP датаграммы, которую система генерирует или пропускает через себя. Таблица маршрутизации может быть обновлена с помощью демона маршрутизации или ICMP перенаправления. По умолчанию система никогда не пропустит через себя датаграмму, если система не сконфигурирована как маршрутизатор. Статические маршруты могут быть добавлены с помощью команды route, а ICMP сообщения поиска маршрутизатора могут быть использованы для инициализации и динамического обновления маршрутов по умолчанию. Хост может запуститься с очень простой таблицей маршрутизации, которая динамически обновляется с помощью ICMP перенаправлений, приходящих с маршрутизатора по умолчанию.

Эта глава была посвящена тому, как отдельная система использует свою таблицу маршрутизации. В следующей главе мы рассмотрим, как маршрутизаторы обмениваются друг с другом маршрутной информацией.

Упражнения

Как Вы думаете, почему существуют два типа ICMP перенаправлений — на сеть и на хост?
Обратитесь к таблице маршрутизации хоста svr4, показанной в начале раздела «Принципы маршрутизации». Является ли необходимым указание маршрута на хост slip (140.252.13.65)? Что изменится, если этот пункт будет удален из таблицы маршрутизации?
Представьте, что существует кабель между 4.2BSD и 4.3BSD хостами. Также представьте, что идентификатор сети — 140.1. Хост 4.2BSD распознает в качестве широковещательных адресов только адреса с идентификаторами хостов, установленными во все нули (140.1.0.0), тогда как хост 4.3BSD обычно отправляет широковещательные сообщения с идентификаторами хостов, состоящих из всех единичных битов (140.1.255.255). Также, хост 4.2BSD по умолчанию старается перенаправить входящие датаграммы, даже если он имеет только один интерфейс. Опишите, что произойдет, когда хост 4.2BSD получает IP датаграммы с адресом назначения 140.1.255.255.
Продолжим предыдущее упражнение. Представьте себе, что кто-либо исправил эту проблему, добавив запись в ARP кэш на одной из систем в подсети 140.1. (воспользовавшись командой arp), сказав при этом, что IP адрес 140.1.255.255 соответствует Ethernet адресу из всех единичных битов (широковещательный запрос Ethernet). Опишите, что произойдет в этом случае.
Просмотрите таблицу маршрутизации Вашей системы и опишите каждую запись.

Источник