Ao tentar configurar um roteador do OpenBSD, encontrei um problema de roteamento aparente.
Eu tenho uma máquina de 1U com NICs de 6 gigabits (em0-em5). Meu ISP me forneceu o seguinte:
xx.xx.97.246/28 static WAN IP.
xx.xx.97.241 default gateway address.
xx.xx.98.192/29 static block that is externally routed to via xx.xx.97.246
Esta é minha configuração:
+-------------------+
| em0 +----> ISP's gateway (xx.xx.97.241)
| xx.xx.97.246 |
+-------------------+
| em2 +----> DMZ network (xx.xx.98.194-198)
| xx.xx.98.193/29 |
+-------------------+
| em4 +----> LAN2 (172.16.1.0/24)
| 172.16.1.1 | [NATs to xx.xx.97.246 address]
+-------------------+
| em5 +----> LAN (192.168.1.0/24)
| 192.168.1.1 | [NATs to xx.xx.97.246 address]
+-------------------+
O encaminhamento foi ativado em sysctl.conf .
Com essa configuração e algumas regras básicas de PF, consegui acesso básico à Internet a partir das redes LAN (em4 / 5) e posso acessar servidores de e-mail / DNS na rede DMZ a partir das redes LAN. Até agora tudo bem.
O problema está em acessar a rede DMZ da Internet e qualquer host na rede DMZ acessando a Internet (para realizar pesquisas de upstream no DNS, etc.). Não parece haver conectividade com a Internet em nenhuma direção quando um endereço de rede DMZ é o terminal.
Eu posso fazer ping no endereço xx.xx.97.246 WAN da rede DMZ, mas não consigo fazer ping no endereço do gateway padrão do ISP ( xx.xx.97.241 ).
Eu recebo um rastro estranho ao tentar rastrear a partir da rede DMZ para o IP da WAN - ele pula o salto em2 e só relata o IP da WAN como se fosse o próximo salto. Posso rastrear para em2 e obter seu endereço como o próximo salto se eu especificar o endereço em2 como o endereço de destino. Independentemente disso, não consigo fazer o ping nem rastrear para o endereço do gateway - recebo uma mensagem "host inacessível".
Isso é o que eu tentei até agora:
Adicionar uma rota estática de xx.xx.98.193 ao IP da WAN e obter "rota existe" ok, faz sentido. Desesperado, tentei adicionar uma rota de xx.xx.98.193 ao endereço do gateway e obtive "destino inacessível".
Adicionando xx.xx.98.193 como um alias de IP a em0 e alterando o endereço de em2 para xx.xx.98.194 . Isso não parece ter qualquer efeito em nada além de quebrar todo o roteamento através do gateway.
Desconectado o comutador DMZ de em2 e conectado em um PC configurado para o endereço estático xx.xx.98.194 , em seguida desabilitado pf com pfctl -d que essencialmente passa tudo e tira o pf da imagem. Nenhuma mudança.
Verifique novamente a tabela arp com arp -a e pode ver que em2 (é MAC) está vinculado a xx.xx.98.193 / 29. Também verifiquei a tabela de roteamento com netstat -ranf inet e ela mostra o xx.xx.97.241 gateway como padrão.
Neste ponto, acho que isso é puramente um problema de roteamento, especialmente depois de tomar as etapas 3 & 4. A propósito, os passos 1 e amp; 2 foram revertidos e o sistema foi reinicializado para reverter para a configuração anterior antes de tentar o 3 & 4.
Eu considerei a ponte entre em0 e em2 , mas isso não parece necessário, pois todas as interfaces estão na mesma máquina e uma vez que o pacote de host de em2 chega ao roteador, a tabela de roteamento deve ter o caminho para o gateway padrão.
Eu também notei uma mensagem de arp estranha repetindo em /var/log/messages "tentativa de sobrescrever a entrada permanente xx.xx.98.193 por". O mac via arp era do gateway xx.xx.97.241 do ISP. Não tenho certeza se isso é normal "chatty logging" ou se é um sintoma do meu problema.
Agradecemos antecipadamente pelo seu tempo de leitura e resposta,
Rob
ATUALIZAÇÃO:
Aqui está minha tabela de roteamento:
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default xx.xx.97.241 UGS 4 54 - 8 em0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHl 1 0 32768 1 lo0
172.16.1/24 172.16.1.1 C 0 0 - 8 em4
172.16.1.1 xx:xx:xx:xx:1b:60 HLl 0 0 - 1 lo0
172.16.1.255 172.16.1.1 Hb 0 0 - 1 em4
192.168.1/24 192.168.1.1 C 0 0 - 8 em5
192.168.1.1 xx:xx:xx:xx:1b:61 HLl 0 0 - 1 lo0
192.168.1.255 192.168.1.1 Hb 0 0 - 1 em5
xx.xx.97.240/28 xx.xx.97.246 UC 1 0 - 8 em0
xx.xx.97.241 xx:xx:xx:xx:fc:d4 UHLc 1 4 - 8 em0
xx.xx.97.246 xx:xx:xx:xx:1b:5c HLl 0 0 - 1 lo0
xx.xx.97.255 xx.xx.97.246 UHb 0 0 - 1 em0
xx.xx.98.192/29 xx.xx.98.193 UC 2 0 - 8 em2
xx.xx.98.193 xx:xx:xx:xx:1b:5e HLl 0 0 - 1 lo0
xx.xx.98.195 xx:xx:xx:xx:d8:33 UHLc 0 4 - 8 em2
xx.xx.98.197 link#3 UHLc 0 4 - 8 em2
xx.xx.98.199 xx.xx.98.193 UHb 0 0 - 1 em2
224/4 127.0.0.1 URS 0 0 32768 8 lo0
Eu tentei muitas configurações ontem à noite (principalmente porque estou ficando sem ideias). De acordo com as tentativas anteriores, o PF foi desativado com pfctl -d para removê-lo como uma variável. Provavelmente a tentativa mais sensata de alguma coisa foi esta:
em0 e em2 . em0 configurada com o endereço xx.xx.98.193 e em2 com o endereço xx.xx.98.194 , em seguida, um PC conectado a em2 com xx.xx.98.195 . Com essa configuração do PC, eu poderia fazer o ping até o endereço 194 (em2 IF), mas não o endereço 193 (em0 IF). Do sistema OpenBSD eu pude fazer ping nos endereços 194 e 195.
Parece que, seja qual for o problema, a falha no roteamento ocorre quando em2 tenta alcançar em0 . Também para pelo menos uma tentativa de ping, o PC aumentou para em0 com 50 de perda, mas falhou consistentemente a partir de então.
Deve haver algo bobo que eu esteja sentindo falta aqui. Minha próxima coisa louca para tentar será ativar / adicionar logs de roteamento do kernel e comparar o que é produzido entre roteamento bem-sucedido entre interfaces e entre em0 / 2. Vai ser um curso intensivo na pilha / kernel de rede do OpenBSD para isso. : /
Poste a saída do netstat -ranf inet. O que acontece se você desativar o pf e executar ping em um host na Internet que saiba responder usando ping -I xx.xx.98.193? Eu também acho incompreensível seu ISP fornecer um endereço MAC para xx.xx.98.193. Isso me leva a acreditar que seu problema está no fim de seu ISP.
Tags networking routing openbsd