Dois servidores DHCP, bloqueiam clientes para um deles?

Question

Estou construindo uma rede de kickstart que reside em uma VLAN diferente usando seu próprio servidor DHCP. Por alguma razão, meus clientes do kickstart continuaram a receber IPs do meu servidor DHCP primário.

A maneira que eu configuro é que eu tenho um servidor DHCP primário neste roteador aqui:

192.168.15.1

Conectado a esse servidor DHCP é um switch com o IP de 192.168.15.2. Meu servidor kickstart (Scientific Linux) está conectado a esse switch em duas portas:

Porta 2 - onde o servidor kickstart se comunica com o resto da rede de produção via eth0. O IP atribuído ao servidor nessa interface é 192.168.15.100 (na eth0). Os detalhes são:

Interface: eth0
IP: 192.168.15.100
Netmask: 255.255.255.0
Gateway: 192.168.15.1

Porta 7 - tem seu próprio ID de VLAN (junto com a porta 8). O servidor kickstart está conectado a essa porta com o IP de 172.16.15.100 (na eth1). Mais uma vez, os detalhes são:

Interface: eth1
IP: 172.16.15.100
Netmask: 255.255.255.0
Gateway: none

O servidor kickstart executa seu próprio servidor DHCP e os atribui pela eth1. A maior parte do kickstart é construída sobre a VLAN kickstart através da porta 8. Para evitar que o servidor kickstart DHCP atribua endereços através da rede de produção, eu tenho a configuração da rota assim:

route add -host 255.255.255.255 dev eth1

Neste ponto, os clientes continuavam recebendo IPs do servidor DHCP 192.168.15.1. Preciso descobrir uma maneira de impedir que solicitações do cliente atinjam esse DHCP. Deve-se notar isso, mas eu também construo hosts KVM no servidor kickstart também, então eu preciso que esses KVMs tenham a capacidade de obter solicitações DHCP do servidor DHCP 192.168.15.1 através da rede de bridge assim que eu terminar de resolver este problema em particular. (Atualmente, eles se comunicam via NAT).

Então, o que seria feito para resolver isso? Através do iptables ou algum tipo de roteamento eu preciso colocar?

Eu tentei limitar-me a solicitações via IPtables nessa interface, permitindo solicitações DHCP para a rede 172.16.15.x:

-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 67 -j ACCEPT

E rejeita atribuições no eth1 da rede 192.168.15.x:

-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 67 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 67 -j REJECT

Não. : (

    

Answer 1

Ok, eu percebi isso - eu não desmarquei a vlan padrão, o que está causando o tráfego da vlan padrão para a minha vlan de kickstart.

Isso foi corrigido. Atribuições DHCP não funcionam mais nessas portas, mas pelo menos agora eu sei o problema. :)

    

Answer 2

Fico feliz por você ter resolvido seu problema de VLAN, mas talvez esteja interessado em saber que pode usar ebtables para filtrar o tráfego DHCP.

Por exemplo, se você tiver dois servidores DHCP em duas LANs diferentes conectadas pelo dispositivo tap0 em um servidor Linux, você poderá isolá-los e ainda manter o fluxo de tráfego TCP / IP e ARP executando:

modprobe ebtables && modprobe ebtable_filter && modprobe ebt_ip
ebtables -A INPUT --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
   -j DROP
ebtables -A FORWARD --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
   -j DROP
ebtables -A FORWARD --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Neste exemplo, você deve executar ebtables nas duas extremidades para não desperdiçar largura de banda, mas apenas uma resolveria o problema de DHCP.