Жила-поживала наша интернетная сеточка с 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-таблицу:
За доскональное воспроизведение таблицы не ручаюсь (неоткуда снять - 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 не просто
предпочтительное, а единственно возможное решение. Если у вас были такие
случаи - пишите!
