O gateway é removido da resposta DHCP através do túnel OpenVPN

Question

Eu tenho uma configuração OpenVPN em ponte. Esta é a configuração do meu servidor:

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

O servidor está rodando em uma máquina Debian rodando na rede A, o cliente está rodando em um roteador OpenWRT na rede B. Na rede A, a interface tap0 é conectada com a rede local, contendo um servidor DHCP e um gateway para a Internet. Na rede B, a interface tap0 é conectada com uma rede separada, sem acesso ao servidor DHCP ou à Internet. A ideia é que o túnel OpenVPN forneça acesso à Internet para a rede B.

Nesta configuração, o servidor OpenVPN não aloca endereços IP para uso pelos clientes. Em vez disso, apenas permite que o servidor DHCP na rede local lide com isso. Isso funciona porque esta é uma configuração em ponte (TAP), não roteada (TUN).

Portanto, o DHCP funciona no túnel. Os clientes do lado da rede B obtêm seus endereços IP diretamente do servidor DHCP no lado da rede A. O problema é que parece que o gateway padrão é retirado da resposta do DHCP, porque está vazio nas máquinas da rede B.

Por exemplo, é isso que recebo em um cliente Windows conectado à rede 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

Eu encontrei isto: link

Isso sugere que isso é um comportamento documentado, mas não sei como desabilitar isso. Eu tentei usar a diretiva route-nopull no lado do cliente, mas não parece ter nenhum efeito.

Além disso, não posso usar as diretivas redirect-gateway , pois preciso colocar o gateway diretamente nas máquinas conectadas com o adaptador tap0 do cliente OpenVPN, e não no próprio cliente OpenVPN.

Minha configuração do lado do cliente da seguinte forma:

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

Tenha em mente que está no formato UCI do OpenWRT.

EDITAR:

Apenas encontrei isso nos registros:

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

Este é exatamente o comportamento que eu quero desativar.

Também encontrei isto:

If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode. The optional nogw flag (advanced) indicates that gateway information should not be pushed to the client.

Interessante. Eu fiz não definir nogw . Poderia ser isso é implicitamente definido ou algo assim? Posso 'cancelar' explicitamente?

EDIT: Encontrei isto: link
Alguém com o mesmo problema, discussão de um ano atrás. Não há respostas.

    

Answer 1

De acordo com a documentação do OpenVPN, server-bridge é uma expressão de atalho para

mode server
tls-server
push "route-gateway dhcp"

e

server-bridge nogw é uma expressão de atalho para

mode server
tls-server

Curiosamente, push "route-gateway dhcp" ativa um proxy DHCP que distribui a opção de gateway padrão na resposta do DHCP do servidor DHCP original. Isso pode ser visto no log do OpenVPN em daemon.notice openvpn[4879]: Extracted DHCP router address: a.b.c.d

Sua solução seria usar server-bridge nogw e a resposta DHCP contém a opção de rota padrão novamente.

    

Answer 2

as opções de bridge do servidor openvpn são usadas para o modo bridge, você tem duas opções  use um servidor dhcp separado ou a opção server-bride

  https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Se eu tiver um servidor openvpn na minha sub-rede 192.168.122.0/24, posso usar a ponte do servidor dessa maneira

  #ip of my vpn server 192.168.122.9
  #vpn client ip pool
  server-bridge 192.168.122.9 255.255.255.0 192.168.122.20 192.168.122.40

Desta forma, meu cliente vpn obtém o endereço IP na sub-rede remota sem usar o servidor dhcp remoto

    

Answer 3

Use isto para o DHCP sobre o OpenVPN (no server.conf):

server-bridge 172.18.100.100 255.255.0.0 172.18.100.105 172.18.100.250

Onde:

• 172.18.100.100 é o IP do servidor OpenVPN
• 172.18.100.105-172.18.100.250 é o intervalo de IPs do cliente

E você também precisará disso no OpenVPN (server.conf):

push "route 172.18.0.0 255.255.0.0"

É sobre isso. Depois, você só precisa encaminhar todo o tráfego através de um gateway (IP do servidor) se quiser sair da rede privada (no cliente).

    

Answer 4

Só tive esse problema e descobri isso, sem uma solução útil. Depois de algumas horas eu descobri!

Use isso:

mode server

tls-server

e remova:

server-bridge

E o DHCP passará diretamente para o cliente!