ГУРУ Linux'a

iptables -A PREROUTING -s IP_ADDRESS -m mac --mac-source MAC_ADDRESS -j ACCEPT
а еще лучшеавторизацию ввести - ВПН там либо еще че нибудь. гарантий больше, тк мак легко вычислить и поменять. вот тут уже будет сложней бороться

забыл добавить - остальные пакеты в DROP...короче на citforum недавно очень толковая дока по iptables появилась. иди читай

> iptables -A PREROUTING -s IP_ADDRESS -m mac --mac-source MAC_ADDRESS -j ACCEPT

Совершенно верно, только -A FORWARD, а не -A PREROUTING, это же filter, а не mangle/nat

Я только предложу чуть более подробно один из вариантов решения Вашей проблемы:

Создаем новую цепочку check-mac. Это не обязательно, но всегда лучше когда набор правил хорошо структурирован:

iptables -N check-mac

устанавливаем политику по умолчанию:

iptables -P check-mac RETURN

то есть, пропускать все пакеты в вызвашую цепочку

Вставляем вызов этой цепочки в самом начале FORWARD:

iptables -I FORWARD 1 -j check-nat

Проверяем пакеты проходящие по этой цепочке и фиксируем все с подмененными ip для последующего разбора полетов:

iptables -A check-nat -s $IP -m mac --mac-source ! xx:xx:xx:xx:xx:xx -j LOG

и отвергаем их к такой-то матери:

iptables -A check-nat -s $IP -m mac --mac-source ! xx:xx:xx:xx:xx:xx -j REJECT

.....
(Повторяем эту операцию для всех необходимых ip)

Cтавь VPN, а то синхронная смена mac и ip не спасет тебя от воровства траффика. Узнать чужой мак не проблема, достаточно один раз пингануть соседа и набрать arp -a. К VPN прикрути 128 mppe для надежности

На самом деле шифрование vpn-трафика вопрос довольно спорный ИМХО...
Вот шифрование ПАРОЛЯ - безусловно да, а шифрование всего трафика ЗАЧАСТУЮ совершенно ненужно, но при этом это лишняя нагрузка на сервер...

ИМХО :)

Нагрузка на самом деле небольшая, используется ведь понтовое криптование с использованием алгоритма rc4. У меня на Athlon 750 при среднем количестве юзеров в онлайне 40 человек, где на каждого по 10кб/c траффика загрузка проца 0.1%