Alguém mais está usando o OpenBSD como roteador na empresa? Em que hardware você está executando? [fechadas]


26

Temos um roteador OpenBSD em cada um dos nossos locais, atualmente em execução no hardware genérico do PC "homebrew" em um gabinete de servidor 4U. Devido a questões de confiabilidade e considerações de espaço, estamos olhando para atualizá-las para algum hardware adequado para servidor com suporte, etc.

Essas caixas servem como roteadores, gateways e firewalls em cada site. Neste ponto, estamos bastante familiarizados com o OpenBSD e o Pf, tão hesitantes em nos afastar do sistema para algo mais, como o hardware dedicado da Cisco.

Atualmente, estou pensando em mudar os sistemas para algumas máquinas HP DL-series 1U (modelo ainda a ser determinado). Estou curioso para saber se outras pessoas usam uma configuração como essa em seus negócios ou se migraram para ou se afastaram de uma.


1
Descobri que as respostas nos ajudaram, pois estamos executando o bsd aberto há 9 anos e começamos a pensar em mudar para o jos por causa de problemas de energia no data center. Agora vou pensar novamente, pois acho que subestimamos os benefícios de rodar em uma plataforma aberta.

Respostas:


43

Executamos exclusivamente roteadores / firewalls do OpenBSD para atender ao FogBugz On Demand. A menos que você esteja operando em uma função de trânsito e precise da taxa de transferência extremamente alta que o hardware e o software integrado podem oferecer, o OpenBSD em hardware sólido será uma solução mais gerenciável, escalável e econômica.

Comparando o OpenBSD ao IOS ou JUNOS (na minha experiência):

Vantagens

  • O firewall pf é incomparável em termos de flexibilidade, configuração gerenciável e integração com outros serviços (funciona perfeitamente com spamd, ftp-proxy, etc.). Os exemplos de configuração não fazem justiça.
  • Você obtém todas as ferramentas de um * nix no seu gateway: syslog, grep, netcat, tcpdump, systat, top, cron, etc.
  • Você pode adicionar ferramentas conforme necessário: iperf e iftop que achei muito úteis
  • tcpdump. Disse o suficiente.
  • Configuração intuitiva para veteranos do Unix
  • Integração perfeita com o gerenciamento de configuração existente (cfengine, fantoche, scripts, o que for).
  • Os recursos da próxima geração são gratuitos e não requerem módulos complementares.
  • Adicionar desempenho é barato
  • Sem contratos de suporte

Desvantagens

  • O IOS / JUNOS simplifica o descarregamento / carregamento de uma configuração inteira. Na ausência de quaisquer ferramentas de gerenciamento de configuração, elas serão mais fáceis de implantar após a gravação da sua configuração.
  • Algumas interfaces simplesmente não estão disponíveis ou são estáveis ​​no OpenBSD (por exemplo, eu não conheço nenhuma placa ATM DS3 bem suportada).
  • Os dispositivos high-end dedicados do tipo Cisco / Juniper lidam com pps mais altos que o hardware do servidor
  • Sem contratos de suporte

Desde que você não esteja falando de roteadores de backbone em um ambiente semelhante ao ISP ou de roteadores de borda que fazem interface com conexões de rede especializadas, o OpenBSD deve ficar bem.

Hardware

O mais importante para o desempenho do seu roteador são as suas NICs. Uma CPU rápida ficará sobrecarregada sob carga moderada se você tiver NICs de merda que interrompam para cada pacote que recebem. Procure placas de rede de gigabit que suportem pelo menos atenuação / coalescência de interrupções. Eu tive boa sorte com os drivers Broadcom (bge, bnx) e Intel (em).

A velocidade da CPU é mais importante do que em hardware dedicado, mas não é algo para se preocupar. Qualquer CPU moderna de classe de servidor lida com uma tonelada de tráfego antes de mostrar qualquer tensão.

Garanta uma CPU decente (vários núcleos ainda não ajudam muito, então veja GHz bruto), boa ECC RAM, um disco rígido confiável e um chassi sólido. Em seguida, dobre tudo e execute dois nós como um cluster CARP ativo / passivo. Desde a atualização do pfsync do 4.5, você pode executar ativo / ativo, mas eu não testei isso.

Meus roteadores estão funcionando lado a lado com nossos balanceadores de carga em configurações de nó duplo de 1U. Cada nó possui:

  • Chassi Supermicro SYS-1025TC-TB (NICs Intel Gigabit integradas)
  • CPU Xeon Harpertown Quad Core de 2 GHz (meus balanceadores de carga usam vários núcleos)
  • RAM registrada ECC de 4GB da Kingston
  • NIC de suplemento Intel Gigabit de porta dupla

Eles são sólidos desde a implantação. Tudo isso é um exagero para a nossa carga de tráfego, mas eu testei a taxa de transferência acima de 800 Mbps (limitada pela NIC, a CPU estava praticamente inativa). Como fazemos uso intenso de VLANs, esses roteadores também precisam lidar com muito tráfego interno.

A eficiência de energia é fantástica, pois cada chassi de 1U possui uma única fonte de alimentação de 700 W, alimentando dois nós. Distribuímos os roteadores e balanceadores através de vários chassis, para que possamos perder um chassi inteiro e ter um failover praticamente uniforme (obrigado pfsync e CARP).

Sistemas operacionais

Alguns outros mencionaram o uso do Linux ou FreeBSD em vez do OpenBSD. A maioria dos meus servidores é FreeBSD, mas prefiro roteadores OpenBSD por alguns motivos:

  • Um foco mais apertado em segurança e estabilidade do que Linux e FreeBSD
  • A melhor documentação de qualquer sistema operacional de código aberto
  • Sua inovação está centrada nesse tipo de implementação (consulte pfsync, ftp-proxy, carp, gerenciamento de vlan, ipsec, sasync, ifstated, pflogd, etc. - todos incluídos na base)
  • O FreeBSD está com vários lançamentos atrasados ​​no porto de pf
  • pf é mais elegante e gerenciável que iptables, ipchains, ipfw ou ipf
  • Processo de configuração / instalação mais enxuto

Dito isto, se você está intimamente familiarizado com o Linux ou o FreeBSD e não tem tempo para investir, provavelmente é uma idéia melhor acompanhar um deles.


Obrigado pela resposta extremamente detalhada. O que você descreve é ​​praticamente exatamente o tipo de sistema que estamos construindo, um par de servidores com GigE duplo integrado e uma NIC de suplemento GigE dupla em uma configuração de failover CARP. É muito reconfortante ver que alguém está executando essa configuração em um grande sistema de produção.
27411 Kamil Kisiel

1
Pessoalmente, prefiro o iptables, acho que o pf é muito restrito. Minha experiência com o CARP no OpenBSD é ótima quando você deseja realizar trabalhos planejados (failover planejado), mas o failover geralmente não funciona quando há uma falha real. Eu tive exatamente um failover de pf bem-sucedido, e isso foi com o OpenBSD 4.5. Além disso, a situação de suporte para o OpenBSD é sombria. Se você não tem o conhecimento interno ou paga a alguém, a resposta para todas as perguntas ou suporte quando ele falha é: "sua mãe é gorda".
Thomas

1
Eu executo pf / pfsync / CARP dois firewalls em uma configuração de failover. Eu experimentei duas situações de failover e, em ambos os casos, só soube disso no meu sistema de monitoramento, dizendo que um dos firewalls estava inoperante. Os serviços do cluster continuaram sem interrupção perceptível.
Insyte 12/08/09

8

pfsense É um ótimo firewall baseado no FreeBSD, rico em recursos, fácil de configurar e com uma comunidade ativa e opções de suporte. Existem várias pessoas que o usam em situações comerciais / de produção que estão ativas no fórum. Eu uso em casa e estou empurrando no trabalho, é uma alternativa muito bem montada. Eles ainda têm uma imagem de VM para download para testá-la!


Eu olhei para esse link. essa variante do MonoWall parece ótima. :-)
djangofan 12/08/09

Eu acredito que o mono se concentra no hardware incorporado, enquanto o pfsense se concentra nos sistemas baseados em PC. Acredito que ele pretendia oferecer recursos mais avançados / de classe empresarial do que aqueles encontrados no m0n0wall ou em outras distribuições básicas de firewall.
Chance

2

Onde trabalho, usamos o RHEL5 + quagga e zebra em mais de 4 caixas para rodar o trânsito a 450mbps. Então, sim, você pode fazer isso na empresa e economizar muito dinheiro.

Classificamos a limitação usando o TC e usamos as regras iptables e notrack.


2

Eu usei o OpenBSD 3.9 como um firewall e mudei para um Juniper SSG5.

Como dito pelo sh-beta OpenBSD como MUITAS boas características: pf é incrível, tcpdump, muitas boas ferramentas ...

Eu tive alguns motivos para mudar para o Juniper. Em particular, a configuração é rápida e fácil. No OpenBSD, tudo é "um pouco complicado".

por exemplo: o gerenciamento de banda é, na minha opinião, muito mais fácil de configurar no SSG.

A versão do OpenBSD que usei era bastante antiga; Talvez a versão mais recente seja melhor nesse ponto.


No lado do hardware, minha caixa do OpenBSD era um antigo Dell GX280.
21430 Matthieu

1

Para as pequenas empresas de meu pai com uma filial, eu uso o OpenBSD como roteador / gateway / firewall para a filial principal e a filial. Isso nunca nos decepcionou. Usamos um servidor Dell Tower em cada local. Cada servidor está equipado com um cartão Dual GiGE, 8 GB de RAM (pequenos excessos, eu sei) e funciona bem. A filial está configurada para conectar-se à principal através do IPSEC e a implementação do IPSEC do OpenBSD é deliciosamente fácil de usar.


1

Os gateways do OpenBSD são usados ​​em muitas configurações empresariais. Temos dois gateways OpenBSD em nossas redes.

Ainda me lembro de um episódio engraçado com o OpenBSD: o disco rígido morreu, mas o gateway continuava roteando o tráfego, como se nada tivesse acontecido, servindo apenas da memória. Deu-me algum tempo para configurar outra instância.

Com requisitos de hardware muito baixos, o Dual Opteron 248's é ótimo. Eu raramente vejo a CPU ultrapassar 5%. Eles são muito estáveis. Estou usando há pouco mais de 7 anos sem problemas.


1

Estou executando o OpenBSD (4.9) em produção em nosso firewall principal há algum tempo. É um ASUS MB bastante antigo, com 2 GB DDR (1) de RAM e um Athlon de núcleo duplo (2 GHz). Comprei uma placa Intel de quatro portas (PCI Express) e usei na porta gráfica x16. NÃO jogue fora suas placas de vídeo PCI, se houver alguma. Você precisará dela como placa gráfica se planeja usar a porta PCI-Express 16x para a NIC (o gfx onboard não funcionou no meu caso).

Eu sei que não é um hardware de "classe corporativa". mas estes são os benefícios claros dessa configuração:

  • Eu tenho muitos MB por aí e, portanto, nunca ficarão sem peças de reposição (se preparando para o CARP também).

  • Os cabos AMD mais baratos suportam ECC RAM !.

  • Todo o hardware / peças de reposição são baratos e estáveis

  • O desempenho nessas plataformas é excelente (4x Gbps), mesmo para nossa configuração de hospedagem bastante pesada!


0

Eu tenho no passado. Instalei-o originalmente em alguns PCs com "caixa branca" e atualizei-o para um Dell Power Edge 2950. Fontes de alimentação redundantes, discos rígidos - grande melhoria do ponto de vista da confiabilidade. Não é uma melhoria observada, é claro, tivemos sorte e a caixa branca nunca travou, mas teoricamente estávamos em melhor forma com mais redundância.

Estávamos apenas usando-o para filtrar pacotes de um T1, portanto, não é uma melhoria notável no desempenho.


0

Você pensou em mudar para o FreeBSD? O OpenBSD não pode utilizar totalmente os sistemas SMP modernos (ou seja, Core2Quad). O FreeBSD possui pf e ipfw que você pode usar simultaneamente e também possui uma camada de rede não-GIANT.

Nós temos rodado roteadores de software FreeBSD como gateways ISP há anos, isso nos salvou muitos


0

Eu não posso falar por * BSD (ainda ... me dê tempo ...), mas estamos rodando roteadores Linux há mais de 10 anos e os amamos. Mais barato, sem aborrecimentos de licença e, se você olhar os documentos, encontrará a maioria das ferramentas necessárias para realizar as tarefas. Eu suspeitaria que o BSD esteja muito no mesmo barco.

Estamos executando um DL365 G1 com um soquete de processador único e 6 GB, embora a RAM seja principalmente para atender caixas de correio ...


0

Use NICs de servidor Intel (em) Gigabit.

Um cartão que funciona bem é o HP NC360T. É porta dupla e PCI Express.

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.