Я спрашивал многих людей, как это сделать и мне отвечали по-разному: начиная с советов по настройке масок 255.255.255.255 на интерфейсах МЭ и заканчивая покупкой профессиональных средств, таких как CISCO PIX Firewall и др. При этом необходимость покупки обосновывалась тем, что сделать так, чтобы и слева и справа (на разных сетевых интерфейсах) у компьютера на базе Linux была одна и та же сеть, и пакеты попадали с одного интерфейса на другой – невозможно. Поэтому у меня и родилась идея написать эту статью, дабы поделиться своим опытом.

Пусть карточка на МЭ, смотрящая на интернет-шлюз, будет eth0, а смотрящая в сеть с компьютерами – eth1.

Тогда даже прописанные вручную правила:

# route add -host x.x.x.1 dev eth0

# route add -host x.x.x.2 dev eth0

# route add -host x.x.x.3 dev eth1

# route add -host x.x.x.4 dev eth1

# route add -host x.x.x.5 dev eth1

  ..

# route add -host x.x.x.y dev eth1

# route add default gw x.x.x.1

показывающие, что тот или иной IP-адрес следует искать на том или ином интерфейсе, не помогают[1].

Сам компьютер, на котором стоит МЭ, «видит» все машины после прописывания подобных правил, машины сети и Интернет «видят» Linux. Но машины сети отказываются видеть шлюз, ну а шлюз, в свою очередь, отказывается видеть машины в сети. Указание в настройке машин сети шлюзом адреса x.x.x.3, привязанного к интерфейсу eth1, ни к чему не приводит, и дело кажется тупиковым. Всё это происходит, потому что умный шлюз не знает о том, что надо передавать пакеты для адресов x.x.x.4, x.x.x.5 и др. на адрес x.x.x.2. Если провести эксперимент: при вышеописанной конфигурации назначить на eth0 вместо адреса x.x.x.2 ненадолго адрес x.x.x.4, далее обратиться с него куда-либо в Интернет, чтобы шлюз его «увидел», а затем быстро поменять всё обратно, то некоторое время общение с компьютером x.x.x.4 будет нормальным. Он будет «видеть» шлюз и Интернет. Интернет также будет видеть его. Такая ситуация многих вдохновляет: заработало! Шлюз пингуется, а машины сети видны из Интернета. Но радость быстро проходит, когда происходит обновление arp-таблицы шлюза. Если шлюз ваш, то проблема в принципе решается просто. Необходимо на шлюзе для адресов, находящихся за МЭ, указать адрес x.x.x.2 в качестве gateway, подобно тому как в настройках Linux шлюзом является адрес x.x.x.1. Тогда наш шлюз будет слать пакеты на MAC-адрес eth0 и всё должно работать. Не следует искать проблем в отсутствии 1 в файле /proc/sys/net/ipv4/ip_forward или в отсутствии поддержки ip_forward в ядре, ошибок в настройке iptables (ipchains) или где-то ещё. В нашем случае проблема состоит в том, что мы не можем перенастраивать шлюз.

Существует решение этой проблемы в виде моста (bridge). Логично предположить: а кто мешает Linux брать пакеты с одной карточки из одной физической сети и передавать их в другую физическую сеть, в которую смотрит другая его карточка. Сразу хочу вас обрадовать, что у меня всё это работает (более года) довольно быстро и не требует больших ресурсов. Меня же, до того как я это сделал, многие «теоретики» уверяли, что сделать такое можно, но работать это будет медленно, особенно если я захочу, чтобы вдобавок происходила фильтрация пакетов. «О МЭ и думать забудь, – говорили они, – если у тебя не Dual Xeon». У меня AMD K7 (Duron) великолепно справляется с этой задачей, причём на 100-мегабитной сетке по команде:

# top

загрузка от пересылки и фильтрации не превышает 3-4%. Так что можно смело говорить о том, что при сегодняшних ценах решение получается дешёвое.

Большую часть загрузки процессора забирают на себя другие процессы, как snort и httpd сервера apache, как видно из рисунка. Если же обращения к веб-серверу нечастые, то большую часть загрузки потребляет сама программа top. Данный screenshot был сделан сразу после завершения скачивания 50-мегабайтного файла, который скачивался несколько секунд.