Qualcun altro sta usando OpenBSD come router nell'azienda? Su quale hardware lo stai eseguendo? [chiuso]


26

Abbiamo un router OpenBSD in ciascuna delle nostre sedi, attualmente in esecuzione su hardware PC "homebrew" generico in un case server 4U. A causa di problemi di affidabilità e considerazioni di spazio, stiamo cercando di aggiornarli ad un hardware adeguato di livello server con supporto ecc.

Queste scatole fungono da router, gateway e firewall in ogni sito. A questo punto abbiamo abbastanza familiarità con OpenBSD e Pf, così titubanti nel passare dal sistema a qualcos'altro come l'hardware Cisco dedicato.

Attualmente sto pensando di spostare i sistemi su alcune macchine HP serie 1U HP (modello ancora da determinare). Sono curioso di sapere se altre persone usano una configurazione come questa nelle loro attività o se sono migrate da o verso una di esse.


1
Ho trovato le risposte che ci hanno aiutato dato che abbiamo iniziato a bsd aperto per 9 anni e ho iniziato a pensare di passare ai jos a causa di problemi di alimentazione nel data center. Ora ci ripenserò perché penso che abbiamo sottovalutato i vantaggi di correre su una piattaforma aperta.

Risposte:


43

Eseguiamo esclusivamente router / firewall OpenBSD per servire FogBugz On Demand. A meno che tu non stia operando in un ruolo di transito e non abbia bisogno di un throughput pps estremamente elevato che l'hardware appositamente costruito e il software integrato possono fornire, OpenBSD su hardware solido sarà una soluzione più gestibile, scalabile ed economica.

Confronto di OpenBSD con IOS o JUNOS (nella mia esperienza):

vantaggi

  • Il firewall pf non ha eguali in termini di flessibilità, configurazione gestibile e integrazione in altri servizi (funziona perfettamente con spamd, ftp-proxy, ecc.). Gli esempi di configurazione non rendono giustizia.
  • Ottieni tutti gli strumenti di un * nix sul tuo gateway: syslog, grep, netcat, tcpdump, systat, top, cron, ecc.
  • Puoi aggiungere strumenti se necessario: iperf e iftop l'ho trovato molto utile
  • tcpdump. È stato detto abbastanza.
  • Configurazione intuitiva per i veterani di Unix
  • Perfetta integrazione con la gestione della configurazione esistente (cfengine, puppet, script, qualunque cosa).
  • Le funzionalità di prossima generazione sono gratuite e non richiedono moduli aggiuntivi.
  • L'aggiunta di prestazioni è economica
  • Nessun contratto di supporto

svantaggi

  • IOS / JUNOS semplifica il dump / caricamento di un'intera configurazione. In assenza di strumenti di gestione della configurazione, saranno più facili da implementare una volta scritta la configurazione.
  • Alcune interfacce semplicemente non sono disponibili o stabili su OpenBSD (ad esempio, non conosco schede ATM DS3 ben supportate).
  • I dispositivi Cisco / Juniper dedicati di fascia alta gestiranno pps più elevati dell'hardware del server
  • Nessun contratto di supporto

Finché non stai parlando di router backbone in un ambiente simile a un ISP o di router edge che si interfacciano con connessioni di rete specializzate, OpenBSD dovrebbe andare bene.

Hardware

La cosa più importante per le prestazioni del router sono le schede di rete. Una CPU veloce verrà rapidamente sopraffatta da un carico moderato se si hanno schede di rete di merda che si interrompono per ogni singolo pacchetto che ricevono. Cerca almeno schede NIC gigabit che supportano la mitigazione / coalescenza degli interrupt. Ho avuto fortuna con i driver Broadcom (bge, bnx) e Intel (em).

La velocità della CPU è più importante che nell'hardware dedicato, ma non è qualcosa di cui preoccuparsi. Qualsiasi moderna CPU di classe server gestirà una tonnellata di traffico prima di mostrare qualsiasi sforzo.

Prendi una CPU decente (più core non aiutano ancora molto, quindi guarda GHz crudo) buona RAM ECC, un disco rigido affidabile e uno chassis solido. Quindi raddoppiare tutto ed eseguire due nodi come cluster CARP attivo / passivo. Dall'aggiornamento 4.5 di pfsync puoi eseguire active / active, ma non l'ho provato.

I miei router funzionano fianco a fianco con i nostri sistemi di bilanciamento del carico in configurazioni 1U a doppio nodo. Ogni nodo ha:

  • Chassis Supermicro SYS-1025TC-TB (schede di rete Intel Gigabit integrate)
  • CPU Xeon Harpertown Quad Core 2GHz (i miei bilanciatori di carico utilizzano i core multipli)
  • RAM registrata ECC Kingston da 4 GB
  • NIC add-in Intel Gigabit a doppia porta

Sono stati solidi fin dalla distribuzione. Tutto ciò è eccessivo per il nostro carico di traffico, ma ho testato un throughput fino a 800 Mbps (limitato alla NIC, la CPU era per lo più inattiva). Facciamo un forte uso delle VLAN, quindi anche questi router devono gestire molto traffico interno.

L'efficienza energetica è fantastica poiché ogni chassis 1U ha un singolo alimentatore da 700 W che alimenta due nodi. Abbiamo distribuito router e bilanciatori su più chassis in modo da poter perdere un intero chassis e avere un failover praticamente continuo (grazie pfsync e CARP).

Sistemi operativi

Alcuni altri hanno menzionato l'uso di Linux o FreeBSD invece di OpenBSD. La maggior parte dei miei server sono FreeBSD, ma preferisco i router OpenBSD per alcuni motivi:

  • Una maggiore attenzione alla sicurezza e alla stabilità rispetto a Linux e FreeBSD
  • La migliore documentazione di qualsiasi sistema operativo Open Source
  • La loro innovazione è incentrata su questo tipo di implementazione (vedi pfsync, ftp-proxy, carp, vlan management, ipsec, sasync, ifstated, pflogd, ecc., Tutti inclusi nella base)
  • FreeBSD ha più versioni dietro la porta di pf
  • pf è più elegante e gestibile di iptables, ipchains, ipfw o ipf
  • Processo di installazione / installazione più snello

Detto questo, se hai familiarità con Linux o FreeBSD e non hai il tempo di investire, è probabilmente un'idea migliore andare con uno di loro.


Grazie per la risposta estremamente dettagliata. Quello che descrivi è più o meno esattamente il tipo di sistema che stiamo cercando di costruire, una coppia di server con dual GigE integrato e una doppia scheda aggiuntiva GigE aggiuntiva in una configurazione di failover CARP. È molto rassicurante vedere che qualcun altro sta eseguendo una simile configurazione in un grande sistema di produzione.
Kamil Kisiel,

1
Personalmente preferisco iptables, penso che pf sia troppo limitato. La mia esperienza con CARP su OpenBSD è che è eccezionale quando si desidera eseguire lavori pianificati (failover pianificato), ma il failover molto spesso non funziona quando si verifica un errore effettivo. Ho avuto esattamente un failover crash pf di successo, e questo è stato con OpenBSD 4.5. Inoltre, la situazione di supporto per OpenBSD è triste. Se non hai le conoscenze interne o paghi qualcuno, la risposta a tutte le domande o il supporto quando si blocca è: "tua madre è grassa".
Thomas,

1
Eseguo pf / pfsync / CARP due firewall in una configurazione di failover. Ho riscontrato due situazioni di failover e in entrambi i casi l'ho imparato solo dal mio sistema di monitoraggio che mi diceva che uno dei firewall era inattivo. I servizi del cluster sono proseguiti senza interruzioni evidenti.
Insyte,

8

pfsense È un ottimo firewall basato su FreeBSD, è molto ricco di funzionalità, facile da configurare e ha una comunità attiva e opzioni di supporto. Ci sono diverse persone che lo usano in situazioni commerciali / di produzione che sono attive nel forum. Lo uso a casa e lo spingo al lavoro, è un'alternativa davvero ben messa insieme. Hanno anche un'immagine VM da scaricare per provarla!


ho guardato quel link. quella variante di MonoWall è fantastica. :-)
djangofan,

Credo che il mono si concentri sull'hardware incorporato, mentre pfsense si concentra sui sistemi basati su PC. Credo che fosse destinato a offrire funzionalità più avanzate / di classe enterprise rispetto a quelle presenti in m0n0wall o in altre distro firewall di base.
Probabilità,

2

Dove lavoro, stiamo usando RHEL5 + quagga e zebra su 4 scatole per eseguire il transito per 450 Mbps. Quindi sì, puoi farlo in azienda e risparmiare un sacco di soldi.

Limitiamo le tariffe utilizzando TC e utilizziamo iptables e le regole notrack.


2

Ho usato OpenBSD 3.9 come firewall e sono passato a Juniper SSG5.

Come detto da sh-beta OpenBSD come MOLTE buone funzionalità: pf è incredibile, tcpdump, molti buoni strumenti ...

Ho avuto alcuni motivi per passare a Juniper. In particolare, la configurazione è semplice e veloce. Su OpenBSD tutto è "un po 'complicato".

per esempio: la gestione della bandwith è, secondo me, molto più facile da configurare sul SSG.

La versione di OpenBSD che ho usato era piuttosto vecchia; Forse la versione più recente è migliore su questo punto.


Sul lato hardware, la mia scatola OpenBSD era un vecchio Dell GX280.
Matthieu,

1

Per la piccola impresa di mio padre con una filiale, utilizzo OpenBSD come router / gateway / firewall sia per la sede principale che per la filiale. Non ci ha mai delusi. Usiamo un Dell Tower Server in ogni posizione. Ogni server è dotato di una doppia scheda GiGE, 8 GB di RAM (lievi sovraccarichi, lo so) e funziona bene. La filiale è configurata per connettersi a quella principale tramite IPSEC e l'implementazione IPSEC di OpenBSD è deliziosamente facile da usare.


1

I gateway OpenBSD sono utilizzati in molte configurazioni aziendali. Abbiamo due gateway OpenBSD sulle nostre reti.

Ricordo ancora un episodio divertente con OpenBSD: l'hard disk è morto, ma il gateway ha continuato a instradare il traffico, come se niente fosse, servendo solo dalla memoria. Mi ha dato del tempo per impostare un'altra istanza.

Requisiti hardware molto bassi, i Dual Opteron 248 sono eccezionali. Raramente vedo che la CPU supera il 5%. Sono molto stabili. Lo sto usando da oltre 7 anni senza problemi.


1

Gestisco OpenBSD (4.9) in produzione sul nostro firewall principale da un po 'di tempo. È un ASUS MB piuttosto vecchio con 2 GB di RAM DDR (1) e un dual core (2 GHz) Athlon. Ho acquistato una scheda Intel quad port (pci-express) e utilizzata nella porta grafica x16. NON gettare le schede grafiche PCI in caso di posa. Ne avrai bisogno come scheda grafica se prevedi di utilizzare la porta 16x PCI-express per la scheda di rete (nel mio caso gfx integrato non ha funzionato).

So che non è un hardware "di classe Enterprise". ma questi sono i chiari vantaggi di questa configurazione:

  • Ho un sacco di questi MB in giro, e quindi non finiranno mai i pezzi di ricambio (preparandomi anche per il CARP).

  • I cavi AMD più economici supportano la RAM ECC !.

  • Tutti i componenti hardware / di ricambio sono economici e stabili

  • Le prestazioni su questi rig sono eccezionali (4x Gbps), anche per la nostra configurazione di hosting piuttosto pesante!


0

Ho in passato. L'ho installato originariamente su alcuni PC "whitebox", quindi aggiornato a un Dell Power Edge 2950. Alimentatori ridondanti, dischi rigidi: un grande miglioramento dal punto di vista dell'affidabilità. Ovviamente non è stato osservato un miglioramento, siamo stati fortunati e il whitebox non si è mai bloccato, ma in teoria eravamo in forma migliore con più ridondanza.

Lo usavamo solo per filtrare i pacchetti di un T1, quindi non un notevole miglioramento delle prestazioni.


0

Hai pensato di passare a FreeBSD? OpenBSD non può utilizzare completamente i moderni sistemi SMP (ad es. Core2Quad). FreeBSD ha pf e ipfw che puoi usare simultaneamente e ha anche un livello di rete non GIANT.

Da anni gestiamo software router FreeBSD come gateway ISP, questo ci ha permesso di risparmiare parecchio


0

Non posso parlare per * BSD (ancora ... dammi tempo ...) ma gestiamo router Linux da oltre 10 anni e li adoro. Più economico, senza problemi di licenza e se dai un'occhiata ai documenti ti accorgerai di avere la maggior parte degli strumenti necessari per fare le cose. Sospetto che BSD sia nella stessa barca.

Stiamo eseguendo un DL365 G1 con un singolo socket riempito e 6Gb, anche se la RAM è principalmente per la manutenzione delle cassette postali ...


0

Utilizzare schede NIC Intel (em) Gigabit Server.

Una scheda che funziona bene è l'HP NC360T. È dual port e pci-express.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.