Списали дорогой маршрутизатор - поставили старый ПК с Linux

Linux 2.4 вышел в январе, и в нём наконец появился нормальный netfilter - замена старому ipchains. Мы давно поглядывали на эту тему: у одного клиента заканчивался контракт на поддержку маршрутизатора Cisco, и продлевать его за те же деньги желания не было. Решили попробовать поднять шлюз на обычном ПК с Linux.

Железо нашли в кладовке - Pentium II, 64 мегабайта памяти, жёсткий диск на четыре гигабайта. Прикупили вторую сетевую карту - PCI, рублей за триста. Итого стоимость шлюза: б/у системник и одна сетевая карта. Разница с маршрутизатором - в несколько раз.

Задача была простой: внутренняя сеть с серыми адресами, один внешний IP от провайдера, все машины в офисе должны выходить в интернет. Классический NAT, ничего экзотического.

Поставили Debian, два сетевых интерфейса: eth0 смотрит в сторону провайдера, eth1 - в локалку. Базовая конфигурация заняла вечер. Вот минимум, который нужен чтобы оно поехало:

# Включить форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Добавить в /etc/sysctl.conf, чтобы не сбрасывалось после перезагрузки
net.ipv4.ip_forward = 1

# Правило NAT - маскарад для всего, что уходит наружу
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Разрешить форвардинг между интерфейсами
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Сохранили правила через iptables-save, добавили восстановление при загрузке. На клиентских машинах прописали шлюз - IP eth1-интерфейса нашего ящика. Проверили: пинги идут, браузеры открываются, почта ходит. Принципиально работает.

Грабли начались на следующий день. Три штуки, разной степени приятности.

Первое - форвардинг не поднялся после перезагрузки, хотя мы прописали sysctl.conf. Оказалось, что скрипт восстановления iptables запускался раньше, чем применялся sysctl. Порядок загрузки сервисов в Debian тогда требовал внимательного отношения к зависимостям - поправили приоритеты в init.d, больше не повторялось.

Второе - FTP в активном режиме перестал работать. Клиенты подключались, авторизовывались, но при попытке листинга директории зависали. Это классика NAT и FTP: в активном режиме сервер сам открывает соединение обратно к клиенту, а NAT этого не понимает без специального хелпера. Починилось загрузкой модуля ip_conntrack_ftp и ip_nat_ftp - после этого FTP заработал как положено. Пассивный режим работал и без них, но не все клиентские программы умели переключаться.

Третье - один из сотрудников пожаловался, что ICQ периодически теряет соединение и переподключается. Поковырялись - проблема в том, что NAT-сессии для UDP имеют таймаут, и если клиент долго молчит (а ICQ в режиме простоя именно так и делает), запись в таблице трансляций устаревает. Соединение рвётся. Для TCP это не так заметно, там keepalive помогает. Для UDP - проблема. Немного подняли таймаут для UDP-сессий в conntrack, стало лучше, но не идеально. ICQ - это ICQ, там своя логика переподключения, в конце концов сошлись на том, что это приемлемо.

Что порадовало - под нагрузкой машина ведёт себя нормально. Двадцать с лишним пользователей, одновременно работают браузеры, почта, FTP-клиенты - никаких тормозов, нагрузка на процессор минимальная. Pentium II с задачей шлюза справляется с большим запасом.

SSH на шлюзе подняли сразу - после прошлой истории со сниффером управлять чем-либо по открытому каналу как-то не тянет. Telnet на шлюз - это вообще не обсуждается.

Интернет-шаринг через NAT - тема, с которой мы уже сталкивались в другом виде. Но там был Windows ICS, который делал всё сам и в чёрный ящик не пускал. Здесь - полный контроль: видно каждое правило, понятно что происходит, можно добавить фильтрацию или логирование в любой момент.

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