Связь rsync со специальными файлами

У меня есть немного более сложная конфигурация, которая также включает NAT и динамическую (внутреннюю) маршрутизацию на машине.

Существует несколько частей к нему. Давайте запустимся с правил:

Maginot:~# ip rule ls
0:      from all lookup local 
1000:   from all lookup main 
1500:   from 173.167.51.136/29 lookup comcast 
1501:   from 76.160.165.106/29 lookup cavtel 
1502:   from 151.200.251.90/31 lookup vzdsl 
1502:   from 151.200.251.92/31 lookup vzdsl 
1502:   from 151.200.251.94 lookup vzdsl 
2000:   from all fwmark 0x1 lookup comcast 
2001:   from all fwmark 0x2 lookup cavtel 
2002:   from all fwmark 0x3 lookup vzdsl 
2500:   from all lookup comcast 
2501:   from all lookup cavtel 
2502:   from all lookup vzdsl 
32767:  from all lookup default 

(Таблицы являются именами в /etc/iproute2/rt_tables)

Как Вы видите, у нас есть три ISPs в данный момент и мы пара статических IP-адресов на каждом. Правила 1500-1502 отправляют трафик от тех исходных IP-адресов соответствующий интерфейс. Правила 2000-2002 отправляют трафик с данной меткой брандмауэра (мы доберемся до того), соответствующий интерфейс. Правила 2500-2502 дают предпочтительное распоряжение нашего ISPs для трафика, который уже не был присвоен ISP. Если Вы идете вниз, Вы удаляете правило для него, и следующий в списке используется.

Каждая таблица маршрутизации довольно тривиальна:

Maginot:~# ip route ls table comcast
default via 173.167.51.142 dev comcast 

(Локальный и основной имеют намного больше материала, но это - непосредственно подключенные и внутренние маршруты, соответственно. Значение по умолчанию таблицы пусто).

Затем, его важное, что, после того как соединение присвоено ISP, это остается там (включая входящие соединения). Попытка переместить его невозможна, так как у нас есть различные IP-адреса в каждом интерфейсе, и наши ISPs на самом деле имеют фильтрацию обратного пути. Мы сохраняем их на том же ISP с правилами брандмауэра.

Помните, что SNAT сделан после маршрутизации, таким образом, ip rule политики не помогут. Необходимо ли использовать что-то еще (возможно, это - проблема?)

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN # if already set, we're done
iptables -t mangle -A PREROUTING -i wan                                       -j MARK --set-mark $MARK_CAVTEL
iptables -t mangle -A PREROUTING -i comcast                                   -j MARK --set-mark $MARK_COMCAST
iptables -t mangle -A PREROUTING -i vz-dsl                                    -j MARK --set-mark $MARK_VZDSL

iptables -t mangle -A POSTROUTING -o wan     -j MARK --set-mark $MARK_CAVTEL
iptables -t mangle -A POSTROUTING -o comcast -j MARK --set-mark $MARK_COMCAST
iptables -t mangle -A POSTROUTING -o vz-dsl  -j MARK --set-mark $MARK_VZDSL
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

Это из сценария оболочки, который настраивает его; $MARK_… переменные соответствуют меткам, которые Вы видите в правилах выше. Довольно простой: восстановите метку соединения (помните, метки на пакет); если существует метка теперь (от метки соединения), мы сделаны. Иначе установите метку на ту на основе включенного интерфейса.

Обратите внимание, что это восстанавливает метку перед маршрутизацией и только сохраняет его впоследствии. И метка установлена на исходящий интерфейс независимо (который является спорным).

Наконец, существуют фактические правила NAT. У нас есть несколько локальные префиксы, этот код выполняется в для цикла с $local набор каждому:

iptables -t nat -A POSTROUTING -s $local -o wan     -j SNAT --to-source 76.160.165.106
iptables -t nat -A POSTROUTING -s $local -o comcast -j SNAT --to-source 173.167.51.137
iptables -t nat -A POSTROUTING -s $local -o vz-dsl  -j SNAT --to-source 151.200.251.90

(Примечание: существует намного больше правил, включая некоторый DNAT для серверов демилитаризованной зоны, и т.д... Я думаю, что скопировал все соответствующие.)