Пример

Пример

Мы запускаем программу, требуя от нее установки соглашения о безопасности, касающегося трафика между узлами 127.0.0.1 и 127.0.0.1 (то есть локального трафика):

macosx % add 127.0.0.1 127.0.0.1 HMAC-SHA-1-96 160

 0123456789abcdef0123456789abcdef01234567

Sending add message:

SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

Source address: 127.0.0.1/32

Dest address: 127.0.0.1/32

Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567

Reply returned:

SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

Source address: 127.0.0.1/32

Dest address: 127.0.0.1/32

Обратите внимание, что в ответе системы отсутствует ключ. Дело в том; что ответ направляется на все сокеты PF_KEY, которые, однако, могут принадлежать к разным доменам, а данные о ключах не должны передаваться между доменами. После добавления записи в базу данных мы даем команду ping 127.0.0.1, чтобы проверить, задействуется ли соглашение о безопасности, после чего запрашиваем дамп базы данных и смотрим, что в ней изменилось.

macosx % dump

Sending dump message:

SADB Message Dump, errno 0, satype Unspecified, seq 0, pid 6283

Messages returned:

SADB Message Dump, errno 0, satype IPsec AH, seq 0, pid 6283

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

[unknown extension 19]

Current lifetime:

36 allocations. 0 bytes

added at Thu Jun 5 21:01:31 2003, first used at Thu Jun 5 21:15:07 2003

Source address: 127.0.0.1/128 (IP proto 255)

Dest address: 127.0.0.1/128 (IP proto 255)

Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567

Из этого дампа видно, что ядро изменило значение протокола с 0 на 255. Это артефакт реализации, а не общее свойство сокетов PF_KEY. Кроме того, ядро изменило длину префикса с 32 на 128. Это какая-то проблема, связанная с протоколами IPv4 и IPv6. Ядро возвращает расширение (с номером 19), которое не обрабатывается нашей программой выведения дампа. Неизвестные расширения пропускаются (их длина имеется в соответствующем поле). Наконец, возвращается расширение времени жизни (листинг 19.7), содержащее информацию о текущем времени жизни соглашения о безопасности.

Листинг 19.7. Структура расширения времени жизни

struct sadb_lifetime {

 u_int16_t sadb_lifetime_len;     /* длина расширения / 8 */

 u_int16_t sadb_lifetime_exttype; /* SADB_EXT_LIFETIME_{SOFT,HARD,CURRENT} */

 u_int32_t sadb_lifetime_allocations; /* количество соединений, конечных

                                       точек или потоков */

 u_int64_t sadb_lifetime_bytes;   /* количество байтов */

 u_int64_t sadb_lifetime_addtime; /* время создания либо время от создания

                                     до устаревания */

 u_int64_t sadb_lifetime_usetime; /* время первого использования или время от

                                     первого использования до устаревания */

};

Расширения времени жизни бывают трех типов. Расширения SADB_LIFETIME_SOFT и SADB_LIFETIME_HARD задают гибкое и жесткое ограничения на время жизни соглашения. Сообщение SADB_EXPIRE отправляется ядром в случае превышения гибкого ограничения на время жизни. После достижения жесткого ограничения использование соглашения прекращается. Расширение SADB_LIFETIME_CURRENT возвращается в ответ на SADB_DUMP, SADB_EXPIRE и SADB_GET и описывает соответствующие параметры текущего соглашения.

Данный текст является ознакомительным фрагментом.