Шлюз разделяется от ответа 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), не направленный (БОЧКА) установка.

Так, 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

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

Также найденный этим:

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

Интересный. Я не установил nogw. Это могло быть, это, неявно установлен или что-то? Я могу 'сбросить' его явно?

Править: Найденный этим: https://forums.openvpn.net/topic13494.html
Кто-то с той же проблемой, распараллельте по сравнению с предыдущим годом. Никакие ответы.