Борьба с Proxy ARP на Token-Ring'е

Задача

Жила-поживала наша интернетная сеточка с DNS/WEB/MAIL серверами и Firewall'ом. И все они вместе с маршрутизатором провайдера находились в одном сегменте, да не в простом, а в Token-Ring'овском. И всё это продолжалось до тех пор, пока не понадобилось спрятать DNS/WEB/MAIL за Firewall (CheckPoint Firewall-1). Вот тут и началась эта почти детективная история.

По правилам хорошего тона Internet-сервера не принято ставить в Intranet-сеть, ибо если всё-таки произойдёт взлом, например, WEB-сервера, то ничто уже не спасёт внутреннюю сеть от злобных хакеров. С другой стороны, выставлять ресурсы в Internet, не обеспечив им защиту, также недопустимо для приличной организации. Поэтому создают так называемую демилитаризованную зону (DMZ), и в ней размещают DNS/WEB/MAIL/etc. Так поступили и мы.

На рисунке изображена функциональная схема сети, а пунктиром отмечены соединения, возникшие после перемещения Internet-серверов в DMZ. Естественно, при любой модернизации сети не должен меняться IP-адрес DNS-сервера, а лучше, чтобы и адреса других Internet-серверов оставались неизменны. Не буду описывать, как можно было бы решить поставленную задачу, если бы была возможность изменить конфигурацию маршрутизатора провайдера, через который мы ходим в Internet. Такой возможности не было, поэтому мы решили воспользоваться Proxy ARP.

Теория

Чтобы понять, что такое Proxy ARP и как он работает, рассмотрим события, происходящие при получении маршрутизатором провайдера c адресом 10.1.1.1 IP-пакета, предназначенного, например, для DNS-сервера, имеющего IP-адрес 10.1.1.25. Маршрутизатор анализирует адрес назначения и, выяснив, что он находится в одной подсети с token-ring интерфейсом, посылает в сегмент широковещательный ARP-запрос: "Всем-всем! Какой MAC-адрес у IP адреса 10.1.1.25?". Получив такой запрос, DNS-сервер формирует ARP-ответ, адресованный непосредственно маршрутизатору: "У IP-адреса 10.1.1.25 такой-то MAC-адрес". Маршрутизатор заносит эту информацию в собственную ARP-таблицу, хранящую записи соответствий IP-адресов и MAC-адресов, и отправляет IP-пакет адресату, т.е. DNS-серверу. Таким образом, переместив DNS-сервер в DMZ, мы лишили маршрутизатор возможности дождаться ответа на ARP-запрос, поскольку ARP-пакеты существуют только в пределах одного сегмента. Решить эту проблему можно, настроив какой либо из хостов, находящихся в одном сегменте с маршрутизатором, отвечать на ARP-запросы и подставлять в качестве MAC-адреса, соответствующего IP-адресу 10.1.1.25, MAC-адрес Firewall'а. В этом случае маршрутизатор будет посылать на Firewall все IP-пакеты, предназначенные DNS-серверу. Этот механизм и называется Proxy ARP. После того, как Firewall получил IP-пакет, в котором в качестве адреса назначения указан адрес 10.1.1.25, приходит в действие механизм статической трансляции адресов (static NAT), пакет соответствующим образом преобразуется и отправляется в сегмент DMZ, где наконец и находит получателя -- DNS-сервер. Впрочем, описание подробностей процесса трансляции адресов выходит за рамки этой статьи.

Проблемы

Первым делом мы озадачились вопросом, как заставить связку WinNT/Firewall-1 отвечать на arp-запросы. Посмотрели на ключи запуска arp.exe (утилиты, предназначенной для манипулирования содержимым arp-таблицы) и обнаружили, что стек Windows гибкостью по-прежнему не страдает и позволяет добавлять только локальные записи в arp-таблицу, т.е. Windows никому не признается в том, что он знает МАС-адрес для 10.1.1.25, поэтому его нельзя использовать в нужном нам качестве. К счастью, поскольку функция всё-таки необходимая, то CheckPoint не оставил на произвол судьбы своих пользователей и предоставил возможность организовать ProxyARP средствами Firewall'а. Радость наша была недолгой -- выяснилось, что существует документированное CheckPoint'ом ограничение и ProxyARP невозможно организовать на Token-ring'овском интерфейсе в силу некоей ужасно специфической архитектуры драйверов сетевых карт в NT. Наш "ответ Чемберлену" оригинальностью не отличался. Мы решили поставить в незащищ`нный сегмент ещё один компьютер и возложить на него обязанность в ответ на arp-запрос маршрутизатора подсовывать MAC-адрес Firewall'a. Очевидно, что этот компьютер не мог быть под Windows. Чтобы избежать очередных упреков в фанатизме, я предложил использовать симпатичную мне FreeBSD. От этой идеи пришлось отказаться буквально через полчаса после начала подготовки к инсталляции -- выяснилось, что под "фрю" Token-ring'овские драйвера отсутствуют как таковые. Зато, хотя и ISA, но есть драйвера под Linux. Заменив PCI на ISA-адаптер, установили RedHat 6.1 и подняли интерфейс tr0, прописав на него адрес 10.1.1.8. Следующим шагом была попытка добавить запись в arp-таблицу: 
  arp -HW tr -i tr0 -s 10.1.1.25 00068989893D pub
где 00068989893D - MAC-адрес firewall'а, а "pub" означает, что эту запись надо "рекламировать", т.е. отвечать на ARP-запросы.

Попытка убедиться в правильности проделанного привела нас в полное изумление, мы получили приблизительно такую arp-таблицу: 

Address    HWtype  HWaddress          Flags Mask  Iface
  10.1.1.8   token   00:06:11:33:89:3A  C     *     tr0
  10.1.1.25  token   *                  CMP   *     tr0
За доскональное воспроизведение таблицы не ручаюсь (неоткуда снять - Linux снесли :)), но совершенно точно, что вместо MAC-адреса были звездочки. Два дня, потраченные на заучиванием man'ов и рысканье в Интернете, не дали никакого результата -- в arp-таблице по-прежнему присутствовали загадочные звёздочки. При этом добавление в таблицу строки без ключа pub проходило без сюрпризов.

Решение

В конце концов настал час OS/2. Бодро удалив разделы Linux, я установил WSeB. Снова добавление записи и проверка: 
  arp -s 10.1.1.25 00068989893D pub
  arp -a
  interface  hardware address   IP address    minutes since
                                              last use
    lan0     0 :06:11:33:89:3A  10.1.1.8            0
    lan0     0 : 0: 0: 0:89:3D  10.1.1.25 (P)  (permanent)
Результат впечатляет. Отчаявшись, мы погрузились в чтение описания Token-ring, предположив, что, возможно, наши проблемы неразрешимы в силу его архитектурных особенностей, и операционные системы невиноваты. Не найдя в описании ничего предосудительного, я, не питая особых надежд, изложил суть проблемы на #os2russian Сергею Евтушенко, на что получил исчерпывающий ответ: arp.exe, входящий в TCP/IP 4.1 и все последующие, неправильно обрабатывает командную строку! Оставалось только сбегать в соседнюю комнату с дискетой и принести "правильный" arp.exe от мерлиновского TCP/IP 4.0. И вот то, чего мы так долго добивались: 
  arp -a
  interface  hardware address   IP address   minutes since
                                               last use
    lan0     0 :06:11:33:89:3A  10.1.1.8            0
    lan0     0 :06:89:89:89:3D  10.1.1.25 (P)  (permanent)
Как это не удивительно, но бывают случаи, когда использование OS/2 не просто предпочтительное, а единственно возможное решение. Если у вас были такие случаи - пишите!
Stepan Trubachev.

Интересные ссылки:
Комментариев к странице: 0 | Добавить комментарий
Домой | Проект ядро Core/2 | Проект OS/4 Download | Новости | Гостевая книга | Подробно обо всем | Нужные программы | Проекты | OS/2 FAQ | Всячина | За и Против | Металлолом | #OS2Russian | RDM/2 | Весёлые картинки | Наша галерея | Доска объявлений | Карта сайта | ПОИСК | ФОРУМ