iptables - forward для двух интерфейсов

навскидку

LO_IFACE="lo"

$IPT -A FORWARD -i $LAN_IFACE -o $VPN_IFACE-j ACCEPT

$IPT -A FORWARD -i $LAN_IFACE -o $LO_IFACE-j ACCEPT

если не в этом дело, надо будет кружечку чая и подумать...

Не, не помогло..

А как у вас дела с DNS у клиентов?

так, попробую заново написать конфиг, примерно так

iptables -F
LAN_IFACE="eth0"
INET_IFACE="eth1"
VPN_IFACE="tap0"
VPN_IP="<IP VPN>"
LAN_IP="<LAN IP>"

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


# [это не самое главное]
iptables -N bad_tcp_packets
iptables -N allowed
iptables -N tcp_packets
iptables -N udp_packets
iptables -N icmp_packets

iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

iptables -A allowed -p TCP --syn -j ACCEPT
iptables -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A allowed -p TCP -j DROP

iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

iptables -A INPUT -p tcp -j bad_tcp_packets

iptables -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

iptables -A FORWARD -p tcp -j bad_tcp_packets
# [/это не самое главное]

#также надо разрулить, каким образом для пользователей реализован сервис DNS, если надо. Возможно дать им доступ в инет только к днс серверу
#iptables -A FORWARD -p ALL -i $LAN_IFACE -o $INET_IFACE -d <IP сервера DNS> -j ACCEPT

iptables -A FORWARD -i $LAN_IFACE -o $VPN_IFACE -j ACCEPT # - разрешит доступ из локалки в впн

# [не уверен, что надо, но попробуйте оставить]
iptables -A OUTPUT -p tcp -j bad_tcp_packets
iptables -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
# [/не уверен, что надо, но попробуйте оставить]
iptables -t nat -A POSTROUTING -o $VPN_IFACE -j SNAT --to-source $VPN_IP

опять же навскидку, пробовал бы так.

относительно

# [не уверен, что надо, но попробуйте оставить] 
iptables -A OUTPUT -p tcp -j bad_tcp_packets 
iptables -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT 
# [/не уверен, что надо, но попробуйте оставить] 

можно просто в дефолтной политике выставить output accept. ИМХО такой конфиг должен заработать, как уже сказал, про dns не забудьте.

Фильтрация на output штука достаточно бессмысленная.

согласен, просто так правильнее, что ли. Сначала всё запретить, потом разрешить что нужно.

Не совсем чтобы и бессмысленная.. Например актуально для перекрытия возможных каналов утечки данных из корп. сети, от вирусов там всяких.. короче смысл есть..

Попробовал этот конфиг, ситуация немного изменилась - теперь на клиенте при пинге клиента из удаленной сети вместо таймаута пишет «Заданный узел недоступен» с ответом от ip vpn'a.

Если честно, я не совсем понял, зачем в конфиге последнее правило (с натом)? Я конечно в iptables новичок (как и в линуксе), наверное чего-то не учел, но мне кажется, что адреса в VPN сети не должны натиться... Или я не прав?

По поводу ДНСов - сейчас все настроено в виртуальной тестовой сети, там днса вообще нет, поэтому естественно на клиентах они тоже не указаны. Я все операции делаю только по ip. В боевой сети будет стоять ДНС внутри локальной сети, который будет редиректить запросы в инет при необходимости, поэтому доступ к внешнему днсу нужен будет только одной машине.

P.s.: спасибо за такой пример конфига, я почерпнул из него несколько полезных вещей :)

«Заданный узел недоступен» с ответом от ip vpn'a.

а если пинговать с самой машины, то ответ приходит ? подозреваю, что либо пингуемые узлы вообще не доступны, либо что-то с маршрутами.

Если честно, я не совсем понял, зачем в конфиге последнее правило (с натом)?

А без этого правила работает ?!

Вообще, смысл в том, чтобы правильно настроить цепочку преобразований пакетов и выстроить, так сказать, туннель. SNAT позволяет подменить адрес источника исходящих пакетов на Ваш внешний адрес, таким образом, ответный пакет придёт на корректный внешний адрес а не будет ломиться на не существующие во внешней сети локальные адреса.

адреса в VPN сети не должны натиться... Или я не прав?

они не должны натиться, если ваши локальные машины являются клиентами впн, а так как они находятся за роутером, то про впн они ничего не подозревают и tap0 вообще рассматривается как устройство (всё-равно, если бы у Вас было 3 сетевушки на роутере и 2 из них во внешнюю сторону, надо было бы разруливать обе)

P.s.: спасибо за такой пример конфига, я почерпнул из него несколько полезных вещей :)

Админ админу друг, товарищ и man :)

Однако же проблема не решена, где-то накосячил, убедитесь что недоступные ресурсы из локалки доступны непосредственно с роутера.

PS Извиняюсь за сумбур, так и не получилось выспаться.

попробуйте команду traceroute, чтоб увидеть, после какого узла, пингуемый узел недоступен

http://ru.wikipedia.org/wiki/Iptables - man iptraf на русском.

Для дебага, для начала сделайте дефолтные правила ACCEPT iptables -P OUTPUT ACCEPT в частности.

>они не должны натиться, если ваши локальные машины являются клиентами впн, а так как они находятся за роутером, то про впн они ничего не подозревают и tap0 вообще рассматривается как устройство (всё-равно, если бы у Вас было 3 сетевушки на роутере и 2 из них во внешнюю сторону, надо было бы разруливать обе)

Вот тут позволю себе не согласиться. Третья сетевушка смотрит в виртуальную сеть с локальными адресами (192.168..), а значит мои пакеты в ней маршрутизируемы. Для прохождения их через эту сеть достаточно настроить маршруты, что я и сделал. Все будет работать без ната, причем напротив, мне как раз нужно без ната, чтобы я видел исходные адреса клиентов. То, что такая схема работает, доказывает эксперимент - отключаю всек правила iptables, и vpn начинает работать нормально. Пакеты проходит именно через tap0, я это отслеживал через tcpdump.

Получается, что с маршрутами все верно, клиенты доступны, но iptables по какой-то причине блокирует проходящий пакет.

А политику output я итак делаю accept, имхо так удобней. Хотя в общих случаях согласен, что лучше сначала все заблокировать, а потом разрешить то, что нужно.

Сейчас к своим правилам попробовал влоб подставить вот так:

$IPT -A FORWARD -s 192.168.10.2 -d 192.168.11.2 -j ACCEPT

где 192.168.10.2 - адрес клиента локальной сети
192.168.11.2 - адрес клиента удаленной сети

локального клиента ping 192.168.11.2 стал проходить. Станно, почему тогда с интерфейсами не получается???

странно, может действительно впн накладывает свои особенности при разруливании правил. Посмотрите, а вот добавление такого правила не решит проблему:

IPT -A FORWARD -s $LAN_IP -d $VPN_IP -j ACCEPT

Вот так:

$IPT -A FORWARD -o ! $EXT_IFACE -j ACCEPT

тоже работает. Только что-то мне кажется, что это костыль... Как мне потом выборочно давать доступ в инет?

Что-то не понял, я ж вроде посто ранее тоже самое написал? Так работает :) Или под $LAN_IP имеется ввиду вся подсеть? Тогда тоже решит проблему, но вариант не очень хороший, т.к. подсетей будет много, все они должны друг к другу прозрачно ходить. При таком решении в случае добавления новой подсети мне прийдется править конфиг для всех серверов.

относительно

iptables -t nat -A POSTROUTING -o $VPN_IFACE -j SNAT --to-source $VPN_IP

IPT -A FORWARD -s $LAN_IP -d $VPN_IP -j ACCEPT

так работает ?

это команда разрешает форвардить пакеты исходящие от адреса локальной сетевушки и приходящие в интерфейс впн, откуда они уже умчатся в просторы впн :)

>Без него работает только потому, что в впн только одна сеть и за её пределы вам не нужно выходить, к примеру, если бы в ней был удалённый шлюз до другой впн или интернета, то такая строчка была бы необходима ИМХО.

Я использую топологию звезда для соединения всех филлиалов, есть набор физических сетей, которые объединены в одну виртуальную. Поэтому с любой точки в любую все без ната работает. Вот с интернетом согласен, нат понадобился бы, но только отдельным правилом именно для доступа в инет. Благо выход в инет в моем случае можно делать с каждого филлиала :)

>это команда разрешает форвардить пакеты исходящие от адреса локальной сетевушки и приходящие в интерфейс впн, откуда они уже умчатся в просторы впн

Ну это понятно. Просто я ж говорю, что если допустим добавляем новую подсеть (новый филлиал), тогда прийдется на каждом шлюзе каждого филлиала и центра прописывать новую строчку с новым диапазоном адресов, что не удобно. Если отвязаться от адреса, а привязаться к интерфейсу, тогда этой проблемы не будет.

новый филиал и новая подсеть она куда подключена будет? к серверу впн ? Тогда у нового филиала будет свой ИП вида 192.168.11.х и никаких проблем. Перефразирую, если траффик до нового клиента пойдёт через устройство в адресом VPN_IP (тот что сейчас), то проблем не будет. А если при это м в впн появится новая подсеть типа 192.168.12.х и в ней будет шлюз до новой сети, то потребуется SNAT и всё, если я не ошибаюсь и правильно понял возможные изменения в ТЗ.

Сети появляются именно виде 12.x, 13.x, 14.x и т.п. Все они подключаются к центральному серверу. Соответственно пакет с одного филлиала маршрутом бросается в центр, а оттуда опять же маршрутом в другой филлиал.

тогда, по моему скромному разумению, новых правил не надо будет, разве что только SNAT один раз

Если использовать SNAT, тогда не нужно будет. Но как было сказано выше - использовать NAT внтури сети нельзя, хотя бы потому, что есть контроллеры домена, которые должны реплиципроваться между собой. Не думаю, что контроллер корректно обработает запрос на репликацию с неизвестным ему адресом-источником (который поменяется SNATом).

про контроллеров домена ничего не скажу, пробовать надо. Вполне возможно, что с snat'ом нормально работать будет. Как вариант решения проблемы - если есть доступ к впн серверу, сделать клиентами впн вообще всех пользователей (так сделано у меня). Больше мороки с настройкой клиентов и сервера (в таком случае лучше делать туннель (tun) а не устройство впн (tap)), меньше с настройками как в Вашем случае, более функционально (доступ к любому коспьютеру по vnc и прочие сервисы).

>доступ к любому коспьютеру по vnc и прочие сервисы

Так доступ к любому клиенту в любом случае будет. По крайней мере по такой схеме сейчас все работает на ISA серверах, есть возможность попасть на любой клиент (использую DameWare). Просто возникла необходимость избавиться от ISA, потому решаю аналогичную задачу с помощью линукса.

Делать такие настройки на двух сотнях клиентов как-то не хочется. Уж лучше перебить правила на шлюзах :)

Если iptables не позволяет пропустить траффик по двум устройствам, тогда прийдется делать либо по адресам, либо так:

$IPT -A FORWARD -o ! $EXT_IFACE -j ACCEPT

если получится при этом дать доступ в инет некоторым клиентам.

Решил таки проблему!!! :)

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

$IPT -A FORWARD -d 192.168.0.0/16 -j ACCEPT
$IPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

После этого все заработало как часики.

Всем спасибо за помощь!