Собрал домашний сервер, на Centos.
Все задачи, маршрутизацию на 2 локальные сетки, на пиринговые ресурсы внешние сделал.
IPTV через igmpproxy прикрутил. Интернет раздается провайдером по VPN (l2tp), использовал xl2tpd.

Но вот потребовалось подключаться к VPN-серверу на площадке (mpd5). Как не бился с форвардингом - не работало.

Картина такая - на интерфейсе домашнего сервера , который смотрит во внутреннюю локалку - пакеты GRE уходят, но ответов не приходит.

На интерфейсе сервера на площадке - обратная картина - GRE посылается на домашний сервер, но нет ответа.

На ppp0 - тоже видно что пакеты приходят с площадки, но из локалки ничего нет.

Решение задачи простое - загрузить модуль ядра :

serv# modprobe ip_nat_pptp

и все взлетело

Ну и чтобы загружалось всегда - прописываем модуль здесь - /etc/sysconfig/iptables-config, строка - IPTABLES_MODULES=”ip_conntrack_netbios_ns ip_nat_pptp”

З.ы. VPN соединение создавалось не на домашнем сервере, а на компьютере в домашней локальной сети.

Если вдруг сломалась очередь qmail-a, есть полезная утилита для ее восстановления.
Называется queue-fix, ставится из портов:

serv# cd /usr/ports/mail/queue-fix
serv# make config
serv# make install

После установки переименовываем старую очередь (расположение по дефолту):

serv# mv /var/qmail/queue /var/qmail/queue.old

Останавливаем qmail полностью, чтобы никаких его процессов не висело в памяти

например так:

serv# /usr/local/etc/rc.d/qmail.sh stop

и фиксим очередь :

serv# /var/qmail/bin/queue-fix -i /var/qmail/queue

Запускаем qmail

serv# /usr/local/etc/rc.d/qmail.sh start

должно заработать.

Если не заработало - надо проверять.

У меня например, на qmail был наложен патч BIG TODO.
Поэтому при установке queue-fix этот патч также надо использовать (make config).

Посмотреть с какими патчами был собран qmail (если он собирался из портов конечно) можно, например, так:

serv# cat /var/db/ports/qmail/options

Как-то так..

Собственно все просто.
Для поддержки режима bridge пересобираем ядро с поддержкой девайса:

device if_bridge

и опциями для фильтрации трафика (на базе ipfw):

options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT

В файл /etc/sysctl.conf добавляем строки

net.link.bridge.ipfw=1
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=1
net.link.ether.ipfw=1
net.inet.ip.fw.enable=1


В файле /etc/rc.conf поднимаем сам мост (на двух физических интерфейсах fxp0 и em0):

cloned_interfaces="bridge0"
ifconfig_bridge0="addm fxp0 addm em0 up"
ifconfig_fxp0="inet 192.168.1.2 netmask 255.255.255.0 up"
ifconfig_em0="up"


Для доступа по сети на интерфейс fxp0 назначен IP.
В принципе, для этого хорошо было бы использовать отдельный интерфейс, но его нет, так что используем один из имеющихся.

reboot