Pacote DHCP não está cruzando a interface tun0

3

Eu tenho a seguinte configuração em um escritório remoto:

--- vlan interface --- Remote Router --tun0--> Main office Firewall --> Active Directory DHCP

Estou usando dhcp3-relay para encaminhar solicitações DHCP (difusões) para meu servidor principal do AD (unicast). O problema é: a solicitação dhcp chega na interface vlan do Remote Router (transmissão), é encaminhada corretamente através do roteamento para nosso servidor AD, uma resposta é dada, mas ao receber o pacote não é encaminhada internamente de tun0 para vlanXXX interface do Remote Router de onde o pedido originalmente veio. Aqui está a saída tcpdump do Remote Router.

tun0 interface:

tcpdump -i tun0 -nevvv udp port 67 or 68

13:23:45.049995 Out ethertype IPv4 (0x0800), length 592: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576) IP.VPN.REMOTE.OFFICE.67 > IP.OF.AD.SERVER.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, hops 1, xid 0x2c896edc, secs 11527, Flags [none] (0x0000)
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

13:23:45.145014  In ethertype IPv4 (0x0800), length 350: (tos 0x0, ttl 125, id 24829, offset 0, flags [none], proto UDP (17), length 334) IP.OF.AD.SERVER.67 > IP.OF.NET.GATEWAY.67: BOOTP/DHCP, Reply, length 306, xid 0x2c896edc, Flags [none] (0x0000)
          Your-IP NEW.LEASE.FROM.AD
          Server-IP IP.OF.AD.SERVER
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

Aqui você pode ver que o pacote é encaminhado corretamente pelo software dhcrelay para o nosso escritório principal, e o AD concede uma nova concessão ao host. Já temos essa solução trabalhando em outros links que não são baseados em openvpn (mpls) para distribuir IPs para escritórios remotos.

vlanXXX interface:

tcpdump -i vlanXXX -nevvv udp port 67 or 68

13:21:45.022067 MAC:ADDR:OF:THE:REMOTE:CLIENT > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 147, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, xid 0x496364c3, secs 11407, Flags [none] (0x0000)
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

Só podemos ver a solicitação de transmissão proveniente do host, mas não a resposta que chegou em tun0 e deve ser roteada para vlanXXX .

Além disso, o Remote Router é bastante permissivo com este protocolo:

iptables -A INPUT  -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A OUTPUT -p udp --sport 67 --dport 67:68 -j ACCEPT
iptables -A FORWARD -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A FORWARD -p udp --sport 67 --dport 67:68 -j ACCEPT

informações do processo do relé dhcp3:

hafw:~# ps fax | grep dhc
 5714 pts/0    D+     0:00                      \_ grep dhc
 5087 ?        Ss     0:04 /usr/sbin/dhcrelay3 -i vlanxxx IP.OF.AD.SERVER

configuração padrão ( /etc/default/dhcp3-relay ):

# Defaults for dhcp3-relay initscript
# sourced by /etc/init.d/dhcp3-relay
# installed at /etc/default/dhcp3-relay by the maintainer scripts

#
# This is a POSIX shell fragment
#

# What servers should the DHCP relay forward requests to?
SERVERS="IP.OF.AD.SERVER"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="vlanXXX"

# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""

Versão do software:

hafw:~# dpkg -l | grep dhcp3-relay
ii  dhcp3-relay                            3.1.1-6+lenny6           DHCP relay daemon

O que eu já tentei fazer na configuração de retransmissão e não alterei o comportamento:

  • Adicione a opção -a para anexar informações do agente
  • Adicione -c 20 e aumente o número de saltos do padrão (10) para 20. De qualquer forma, há apenas 8 saltos para alcançar o AD.
  • Adicione tun0 e a interface vlan de internet vlanYYY que está enfrentando a internet.
  • Deixe INTERFACES= vazio assim, não haverá uma opção -i .

Estou sentindo falta de algo?

    
por nwildner 11.04.2018 / 18:49

1 resposta

1

Isso parece uma falha de design dentro do próprio utilitário dhcrelay . Ele só pode escutar em interfaces broadcast , e o OpenVPN é uma interface ponto a ponto . O -i flag não irá alterar isso (somente reduzirá o número de interfaces selecionadas do conjunto de interfaces broadcast ).

A solução geral parece ser executar dhcrelay em um dispositivo dentro de sua LAN remota, e não no próprio gateway. O tráfego unicast retransmitido será então passado através do túnel OpenVPN para o servidor DHCP e de volta.

Se você precisar de um servidor pequeno / barato para esse tipo de tarefa, eu posso recomendar o Raspberry Pi executando o Raspbian (Debian disfarçado). Eu corro DNS em um par deles em cada um dos nossos escritórios remotos.

Referências

por 24.04.2018 / 15:10