Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

younghacker: проблему решил. Все оказалось довольно просто, если копнуть поглубже и разобраться в особенностях инициализации сети.
1) Отключаем дебиановскую службу инициализации сети "networking.service":
# systemctl disable networking.service
2) Конфигурируем "systemd-networkd.service". У меня архитектура сети довольно сложная, потому примеры приводить не буду. Но все сводиться к созданию файлов настроек в /etc/systemd/network. man в помощь.
ВНИМАНИЕ!!!
Возможно этот шаг можно пропустить. Я не проверял, но похоже systemd-networkd умеет "цеплять" настройки сети из /etc/network/interfaces
3) Включаем службу "systemd-networkd.service":
# systemctl enable systemd-networkd.service
4) И ребут для чистоты эксперимента...

Все. Теперь зависимости типа "After=network.target" будут корректно отрабатывать.

P.S.
Есть еще один костыльный способ реализации логики network-online на традиционных дебиановских скриптах инициализации. Обсуждается здесь: unix.stackexchange.com/questions/209832/debian-sys...

Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

younghacker: нет. Совсем нет времени на долгие изыскания решения. Аптайм сервера исчисляется месяцами, потому просто дернуть сервис при перезагрузке не составляет труда.
Скрипт обрабатывает именно TAP интерфейс, отсюда и возникшие сложности...

Судя по всему, виновата агрессивная параллелизация загрузки systemd.
Как только будет время, подробно изучу эту проблему и обязательно отпишусь здесь.
Спасибо за помощь! ;)

Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

# systemctl list-unit-files | grep -i vpn
openvpn.service                            enabled 
openvpn@.service                           disabled

Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

В /lib/systemd/system нашлось 2 файла:
1) openvpn.service

# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

2) openvpn@.service

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
PrivateTmp=true
KillMode=mixed
Type=forking
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
PIDFile=/run/openvpn/%i.pid
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn
ProtectSystem=yes
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw

[Install]
WantedBy=multi-user.target

Что бы это могло значить?

Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

Петр Иванов: Да. Ссылки есть. В rc0.d и т.д.

Почему systemd запускает OpenVPN раньше готовности интерфейсов определенных в /etc/network/interfaces?

Для службы openvpn в /etc/init.d/openvpn уже прописана зависимость от сети и даже сетевых ФС.
Я так понимаю, что служба запускается в режиме обратной совместимости. Т.к. юнита для systemd я что то не нашёл.

Port forwarding и два шлюза в одной подсети на одном интерфейсе - куда копать?

Владимир Дубровин: да, похоже это единственное решение. Костыль еще тот, но и задача не лучше :)

Port forwarding и два шлюза в одной подсети на одном интерфейсе - куда копать?

Спасибо!
Пока сделал с разными портами и policy routing:

# ip rule add fwmark 0x1/0x3 lookup 201
# ip rule add fwmark 0x2/0x3 lookup 202

# ip route add default via 192.168.0.1 table 201
# ip route add default via 192.168.0.4 table 202
# ip route add default via 192.168.0.1 metric 1000
# ip route add default via 192.168.0.4 metric 2000

# iptables -t mangle -N out-marking
# iptables -t mangle -A PREROUTING -m connmark ! --mark 0x0/0x3 -j out-marking
# iptables -t mangle -A out-marking -i br0 -j CONNMARK --restore-mark --mask 0x3
# iptables -t mangle -A out-marking -i p9p1 -j CONNMARK --restore-mark --mask 0x3

# iptables -t mangle -N in-marking
# iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -j in-marking
# iptables -t mangle -A in-marking -i p4p1 -p tcp -m tcp --dport 1101 -j CONNMARK --set-xmark 0x1/0x3
# iptables -t mangle -A in-marking -i p4p1 -p tcp -m tcp --dport 1102 -j CONNMARK --set-xmark 0x2/0x3

Однако хотелось бы универсальности. Есть ли способ средствами iptables определить с какого шлюза пришел пакет при новом соединении? Да бы не разбрасывать порты вручную.