Nous utilisons exclusivement des routeurs / pare-feu OpenBSD pour servir FogBugz On Demand. Sauf si vous opérez dans un rôle de transit et avez besoin du débit pps extrêmement élevé que le matériel spécialement conçu et les logiciels intégrés peuvent fournir, OpenBSD sur du matériel solide sera une solution plus gérable, évolutive et économique.
Comparer OpenBSD à IOS ou JUNOS (d'après mon expérience):
Les avantages
- Le pare-feu pf est inégalé en termes de flexibilité, de configuration gérable et d'intégration dans d'autres services (fonctionne de manière transparente avec spamd, ftp-proxy, etc.). Les exemples de configuration ne lui rendent pas justice.
- Vous disposez de tous les outils d'un * nix sur votre passerelle: syslog, grep, netcat, tcpdump, systat, top, cron, etc.
- Vous pouvez ajouter des outils si nécessaire: iperf et iftop que j'ai trouvé très utiles
- tcpdump. Assez dit.
- Configuration intuitive pour les vétérans Unix
- Intégration transparente avec la gestion de configuration existante (cfengine, marionnette, scripts, etc.).
- Les fonctionnalités de nouvelle génération sont gratuites et ne nécessitent aucun module complémentaire.
- Ajouter des performances n'est pas cher
- Pas de contrats de support
Désavantages
- IOS / JUNOS simplifient le vidage / chargement d'une configuration entière. En l'absence d'outils de gestion de configuration, ils seront plus faciles à déployer une fois votre configuration écrite.
- Certaines interfaces ne sont tout simplement pas disponibles ou stables sur OpenBSD (par exemple, je ne connais aucune carte ATM DS3 bien prise en charge).
- Les appareils dédiés haut de gamme de type Cisco / Juniper gèrent des pps plus élevés que le matériel serveur
- Pas de contrats de support
Tant que vous ne parlez pas de routeurs de dorsale dans un environnement de type FAI ou de routeurs de périphérie s'interfaçant avec des connexions réseau spécialisées, OpenBSD devrait être parfait.
Matériel
La chose la plus importante pour les performances de votre routeur est votre NIC. Un processeur rapide sera rapidement submergé par une charge modérée si vous avez des cartes réseau merdiques qui s'interrompent pour chaque paquet unique qu'il reçoit. Recherchez les cartes réseau gigabit qui prennent en charge au moins l'atténuation / la fusion des interruptions. J'ai eu de la chance avec les pilotes Broadcom (bge, bnx) et Intel (em).
La vitesse du processeur est plus importante que dans le matériel dédié, mais ce n'est pas quelque chose à craindre. Tout processeur moderne de classe serveur gérera une tonne de trafic avant d'afficher toute contrainte.
Prenez-vous un CPU décent (plusieurs cœurs n'aident pas beaucoup pour l'instant, alors regardez le GHz brut), une bonne RAM ECC, un disque dur fiable et un châssis solide. Ensuite, doublez tout et exécutez deux nœuds en tant que cluster CARP actif / passif. Depuis la mise à niveau de pfsync de 4.5, vous pouvez exécuter active / active, mais je n'ai pas testé cela.
Mes routeurs fonctionnent côte à côte avec nos équilibreurs de charge dans des configurations à deux nœuds 1U. Chaque nœud a:
- Châssis Supermicro SYS-1025TC-TB (cartes réseau Intel Gigabit intégrées)
- Processeur Xeon Harpertown Quad Core 2 GHz (mes équilibreurs de charge utilisent les cœurs multiples)
- 4 Go de mémoire RAM Kingston ECC enregistrée
- Carte réseau complémentaire Intel Gigabit à deux ports
Ils sont solides comme le roc depuis leur déploiement. Tout cela est exagéré pour notre charge de trafic, mais j'ai testé un débit supérieur à 800 Mbps (NIC limité, le processeur était principalement inactif). Nous utilisons beaucoup les VLAN, de sorte que ces routeurs doivent également gérer beaucoup de trafic interne.
L'efficacité énergétique est fantastique car chaque châssis 1U possède un seul bloc d'alimentation de 700 W alimentant deux nœuds. Nous avons réparti les routeurs et les équilibreurs sur plusieurs châssis afin que nous puissions perdre un châssis entier et avoir un basculement à peu près transparent (merci pfsync et CARP).
Systèmes d'exploitation
Certains autres ont mentionné l'utilisation de Linux ou FreeBSD au lieu d'OpenBSD. La plupart de mes serveurs sont FreeBSD, mais je préfère les routeurs OpenBSD pour plusieurs raisons:
- Un accent plus serré sur la sécurité et la stabilité que Linux et FreeBSD
- La meilleure documentation de tout système d'exploitation Open Source
- Leur innovation est centrée sur ce type d'implémentation (voir pfsync, ftp-proxy, carp, vlan management, ipsec, sasync, ifstated, pflogd, etc. - qui sont tous inclus dans la base)
- FreeBSD a plusieurs versions en retard sur son port de pf
- pf est plus élégant et gérable que iptables, ipchains, ipfw ou ipf
- Processus de configuration / d'installation allégé
Cela dit, si vous êtes intimement familier avec Linux ou FreeBSD et que vous n'avez pas le temps d'investir, c'est probablement une meilleure idée d'aller avec l'un d'eux.