Шлюз лишается ответа DHCP через туннель OpenVPN

У меня есть мостовая настройка OpenVPN. Это моя конфигурация сервера:

port 1194
proto udp
dev tap0

ca      /etc/openvpn/easy-rsa/keys/ca.crt
cert    /etc/openvpn/easy-rsa/keys/server.crt
key     /etc/openvpn/easy-rsa/keys/server.key
dh      /etc/openvpn/easy-rsa/keys/dh2048.pem

# brtctl upscript
script-security 2
up /etc/openvpn/up.sh

tls-server
server-bridge

keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Сервер работает на машине Debian, работающей в сети A, клиент работает на маршрутизаторе OpenWRT в сети B. В сети A интерфейс tap0 соединен с локальной сетью, содержащей DHCP-сервер и шлюз в Интернет. В сети B интерфейс tap0 соединен с отдельной сетью без DHCP-сервера или доступа в Интернет. Идея состоит в том, что туннель OpenVPN обеспечивает доступ в Интернет для сети B.

В этой настройке сервер OpenVPN не выделяет IP-адреса для использования клиентами. Вместо этого он просто позволяет DHCP-серверу в локальной сети справляться с этим. Это работает, потому что это мостовая (TAP), а не маршрутизированная (TUN) установка.

Итак, DHCP действительно работает через туннель. Клиенты на стороне сети B получают свои IP-адреса непосредственно от DHCP-сервера на стороне сети A. Проблема в том, что похоже, что шлюз по умолчанию удаляется из ответа DHCP, потому что он пуст на машинах в сети B.

Например, вот что я получаю на клиенте Windows, подключенном к сети B:

Ethernet adapter Ethernet:

   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.2.123(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : vrijdag 25 juli 2014 22:49:38
   Lease Expires . . . . . . . . . . : zaterdag 26 juli 2014 10:49:38
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 192.168.2.1
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

Я нашел это: https://community.openvpn.net/openvpn/ticket/312#comment:3

Это говорит о том, что это задокументированное поведение, но я не знаю, как это отключить. Я пробовал использовать директиву route-nopull на стороне клиента, но, похоже, не имеет никакого эффекта.

Кроме того, я не могу использовать redirect-gateway директивы, поскольку мне нужно получить шлюз прямо на машинах, соединенных мостом с адаптером tap0 клиента OpenVPN, а не на самом клиенте OpenVPN.

Моя клиентская конфигурация выглядит следующим образом:

config openvpn sample_client
    option enabled 1

    option client 1

    option dev tap

    option proto udp

    list remote "server.com 1194"

    option resolv_retry infinite

    option nobind 1

    option persist_key 1
    option persist_tun 1

    option ca /etc/openvpn/ca.crt
    option cert /etc/openvpn/client.crt
    option key /etc/openvpn/client.key

    option ns_cert_type server

    option comp_lzo yes

    option verb 3

    option route-nopull 1

Имейте в виду, что это формат OpenWRT UCI.

РЕДАКТИРОВАТЬ:

Только что нашел это в журналах:

daemon.notice openvpn(sample_client)[5062]: Extracted DHCP router address: 192.168.2.1

Это именно то поведение, которое я хочу отключить.

Также нашел это:

Если --server-bridge используется без каких-либо параметров, он включит режим DHCP-прокси, при котором подключенные клиенты OpenVPN получат IP-адрес для своего адаптера TAP от DHCP-сервера, работающего в локальной сети на стороне сервера OpenVPN. Обратите внимание, что только клиенты, которые поддерживают привязку DHCP-клиента к адаптеру TAP (например, Windows), могут поддерживать этот режим. Необязательный флаг nogw (расширенный) указывает, что информация о шлюзе не должна передаваться клиенту.

Интересный. я сделал не устанавливать nogw. Может быть, это неявно установлено или что-то в этом роде? Могу ли я его явно "отключить"?

РЕДАКТИРОВАТЬ: Нашел это: https://forums.openvpn.net/topic13494.html
Кто-то с той же проблемой, ветка год назад. Нет ответов.