Servidor DHCP concede concessões para clientes da interface WAN


0

Boa tarde a todos:

Aqui está a configuração de infraestrutura relevante que estou usando:

Modem ---> Roteador -> Roteador (192.168.1.1) -> ponte sem fio (ddwrt; estático 192.168.1.254) -> Proxmox Server (estático 192.168.1.101)

Nesse servidor, existem duas pontes virtuais - vmbr0 que é conectada a eth0 (a porta usada para conectar o servidor à ponte sem fio) e vmbr1 - que está configurado como em branco.

Neste servidor proxmox, atualmente tenho três VMs - Centos7, caixa estável do debian e uma instalação do pfsense-2.4.x. A caixa pfsense está configurada da seguinte maneira:

vtnet0 = nic virtual conectado ao vmbr0 (ponte para eth0 que é o uplink para todo o servidor) vtnet1 = nic virtual conectado ao vmbr1 (nenhuma configuração para esse vswitch vmbr1)

WAN = vtnet0 (nic virtual conectado à conexão em ponte com eth0 que se conecta a montante) WAN: IPv4 / DHCP: (endereço 192.168.1. * Do DHCP do roteador a montante)

LAN = vtnet1 (nic virtual conectado ao switch virtual sem configuração no host proxmox); LAN = IPv4 STATIC 172.16.0.1/12


Problemas

1)

Eu preparei tudo, e as caixas CentOS e Debian estão recebendo os endereços DHCP da rede 172.16.0.0/12 muito bem ... No entanto, quando eu olho para as concessões do DHCP, percebo que alguns dos meus colegas de quarto têm realmente puxou seu DHCP da caixa pfsense. Como estou vendo "$ (RoomMates) Iphone" aparecendo com uma concessão de DHCP na rede 172.16.0.0/12 ...

O iphone deles está se conectando ao roteador principal AP, que deve atribuir a esses clientes um IP 192.168.1.x. Em vez disso, o iphone (assim como outros clientes, como os desktops) está obtendo um IP da 172.16.0.1 e se conectando a partir dela. O engraçado é que alguns clientes obtêm o DHCP do roteador 192.168.1.1 - por exemplo, existem clientes nos dois servidores DHCP e estou tentando descobrir como manter todos os clientes fora das VMs para obter sua concessão de DHCP a partir de 192.168. Rede 1.0.

2)

Quando desabilito a caixa pfsense, acontece o seguinte: As caixas CentOS e debian (que têm suas vnics anexadas à vmbr1 - a vswitch não configurada), extraem um IP de 192.168.1.1 ... Como estão na vmbr1, elas não devem ser capaz de acessar essa rede, pois ela não é conectada a eth0 (ou qualquer NIC real, nesse caso).

Eu tentei as seguintes configurações, sem sucesso: -bloqueie todo o tráfego RFC1918 na interface WAN -como como acima, mas para a interface LAN -jogue com configurações de firewall por horas -Wireshark usado no desktop conectado à rede 192.16.1.0 para analisar dhcp, ip .addr == $ (172.16./12 IP do pfsense) e, geralmente, analisando o que vejo. Nada.

Não é possível bloquear todo o tráfego da WAN na interface da LAN, pois preciso que as VMs na rede da interface da LAN acessem 192.16. rede e internet além do demarc.

Estático 172.16. o endereçamento para o vms funciona, mas eu gostaria de ter o dhcp ativado, pois é divertido brincar e bastante conveniente para um ambiente que muda frequentemente.

TL; DR: - Tentando criar uma rede 172.16.0.0/12 no Proxmox. Tentando separá-los para que, se a caixa pfsense cair, não ocorra tráfego entre vmbr0 e vmbr1. Também tentando garantir que os clientes do upstream (qualquer coisa que não seja VMs do servidor proxmox) não usem o pfsense box como servidor DHCP (o que não deveria estar acontecendo, porque novamente o tráfego está vindo pela interface WAN na instalação do pfsense .. .)

Por favor, ajude, todas as dicas são úteis. Mais do que feliz em fornecer logs, saída, o que for necessário. Estive puxando meu cabelo durante todo o fim de semana e é frustrante, pois eu fiz essa configuração funcionar antes no Homelab.


você mencionou algumas vezes uma rede 192.16.0.0 / 24. se isso não é um erro de digitação, é um espaço de endereço incorreto. pt.wikipedia.org/wiki/…
Tim_Stewart 21/02

É um erro de digitação, obrigado por apontar. Estava muito cansada e quando eu escrevi isso - muito obrigado!
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.