Tyblog

 » Construire mon routeur idéal pour 50 $  »

Après que mon Asus N66U ait donné un coup de pied au seau, j’ai envisagé quelques options : un autre routeur tout-en-un, mettre à niveau vers quelque chose comme un EdgeRouter, ou brasser quelque chose de personnalisé.Lorsque j’ai lu l’article d’Ars Technica épousant les vertus de la construction de votre propre routeur, cela a à peu près tout réglé : DIY c’est.

J’ai un peu un complexe psychologique quand il s’agit de rouler mes propres solutions sur-ingénierie, mais j’ai fixé quelques objectifs généraux : le résultat final devrait être bon marché, de faible puissance, bien pris en charge par Linux, et extensible.Incidemment, les cartes ARM répondent à beaucoup de ces exigences, et certains comme le Raspberry Pi ont remué tellement d’activité communautaire qu’il y a un grand soutien pour la plate-forme ARM, même si elle peut se sentir étranger à x86.

J’ai réussi à bricoler un dispositif qui n’est pas seulement dirt cheap pour ce qu’il fait, mais qui est extrêmement capable en soi.Si vous avez un quelconque intérêt à construire votre propre routeur domestique, je vais démontrer ici que le faire est non seulement faisable, mais relativement facile à faire et offre une énorme quantité d’utilité – de la mise en forme du trafic, à la surveillance du netflow, au DNS dynamique.

Je l’ai construit en utilisant l’espressobin, Arch Linux Arm, et Shorewall.

Cette photo montre la carte enfermée dans un boîtier imprimé en 3d.Malheureusement, l’espressobin n’est pas assez populaire pour se vanter d’une grande variété de boîtiers achetables comme le Raspberry Pi, mais il existe de bons modèles pour l’impression 3d.

En guise de remarque, la documentation suivante n’est pas destinée à être un guide complet étape par étape pour faire la même chose vous-même.Bien que je veuille couvrir un grand nombre des choix qui sont entrés dans la construction, la configuration de quelque chose d’aussi important qu’un routeur/pare-feu ne devrait vraiment pas être un travail de copier/coller et serait mieux d’être vaguement guidé par les étapes ici avec une compréhension approfondie du comment et du pourquoi.

• Le pourquoi
• Première partie : Matériel
  • Qu’en est-il du WiFi ?
• Deuxième partie : Logiciel
  • Système d’exploitation
  • Pare-feu
• Troisième partie : La construction de base
  • Installation du système d’exploitation
  • Configuration du système d’exploitation
  • Pare-feu
  • DHCP
• Quatrième partie : Interlude
• Cinquième partie : Mises à niveau
  • Surveillance du flux de réseau
  • Mise en forme du trafic
• Conclusion

Le pourquoi

Il y a beaucoup de routeurs solides que vous pouvez acheter qui ne sont pas des feux de pneus de fournisseur d’accès stock et qui seraient probablement plus que convenables (je vous regarde affectueusement, EdgeRouter Lite).Alors pourquoi s’embêter avec tout cela ? Il y a quelques avantages légitimes ici :

• C’est en fait très abordable. Mon routeur a passé mes benchmarks avec brio, et a toutes les fonctionnalités que je pourrais éventuellement tirer de Linux (qui est une grande liste).
• Il est sécurisé. J’ai l’impression qu’une nouvelle vulnérabilité est annoncée pour un périphérique de réseau grand public chaque mois. Comparez cela à un pare-feu autogéré, et je sais exactement quels services sont exposés (et si iptables est cassé, le monde a de plus gros problèmes). D’ailleurs, pour tous les opposants, le seul port qui écoute sur mon pare-feu est un port aléatoire à numéro élevé pour l’authentification ssh à clé publique uniquement. Donc oui, je pense qu’il est plus sûr que certains routeurs Huawei grand public.
• Il a de grandes fonctionnalités. Bien sûr, mon espressobin peut router et servir de pare-feu, mais j’ai laissé tomber dans d’autres capacités utiles aussi.
• Il est performant. Dans les benchmarks mineurs que j’ai effectués, l’espressobin peut vraiment pousser le trafic sans transpirer.
• C’était vraiment amusant à construire. Si vous a) avez besoin d’un nouveau routeur ou b) voulez vous faire les dents sur un projet ARM monocarte, cela pourrait être un bon ajustement.

Partie un : Matériel

Techniquement, vous pourriez mettre en place un routeur en utilisant n’importe quel ordinateur avec deux NIC, mais nous pouvons faire aussi bien avec moins de puissance, un facteur de forme plus petit, et plus abordable.Les cartes ARM sont le sweet spot : elles sont super bon marché, plus puissantes que vous ne le pensez, et bien supportées avec tant de variantes sur le marché.

Le concurrent le plus connu est le Raspberry Pi, mais sans deux NIC ou un réseau gigabit, ce n’est pas une bonne option.De plus, vous payez pour des choses comme un GPU qui ne sont pas nécessaires dans un périphérique réseau sans tête.

La bonne nouvelle est que l’année dernière, l’espressobin a été publié, et il est super capable.Il semble construit spécialement pour ce type de chose : un réseau gigabit, un commutateur intégré et aucune fioriture dont vous auriez autrement besoin pour quelque chose de plus général (il n’y a même pas de sortie d’affichage, juste une console série).

Bien que la carte soit assez jeune, Armbian et Arch Linux Arm supportent tous deux le matériel, et les deux projets font un excellent travail.Si vous n’avez pas exploré le monde de Linux sur ARM, il n’y a pas grand-chose à craindre ici.Armbian et Arch Linux Arm fournissent tout ce dont vous avez besoin pour aarch64 nativement dans les dépôts de la distribution, donc il y a peu de choses que vous rencontrerez qui vous semblent étrangères sur une puce ARM 64 bits, et cela en vaut certainement la peine lorsque vous tenez compte du caractère abordable du matériel et de la faible empreinte énergétique.

Voici quelques-uns des points saillants pour moi :

• La carte comprend un commutateur réseau Topaz intégré. Dans mes tests réseau, le trafic qui traverse seulement les interfaces LAN est indiscernable en termes de vitesse du trafic passant par un commutateur vanille. Si vous faites du streaming à partir d’un NAS ou si vous avez d’autres exigences élevées pour la communication inter-appareils qui traverse le routeur, cela peut faire une grande différence.
• La console série est un citoyen de première classe. Sur mes Raspberry Pis, j’étais parfois frustré de devoir atteindre mon écran HDMI lors du débogage des problèmes, mais l’espressobin a un port série micro USB pour un accès facile à la console.
• La puce aarch64 a été formidable. Non seulement elle a géré tout ce que j’ai jeté sur elle, mais saviez-vous qu’elle n’est pas affectée par meltdown ? Les puces Cortex-A53 ne sont pas impactées par le bug d’exécution spéculative, donc c’est un bonus supplémentaire.

Qu’en est-il du WiFi ?

Je ferai une petite note ici que j’ai tenté d’utiliser l’espressobin comme un point d’accès sans fil aussi.La carte a un slot mini PCIe bien adapté pour une carte sans fil, et bien que cela aurait dû fonctionner, je peux définitivement rapporter que ce n’est pas une bonne idée.

Sans entrer dans des détails douloureux, il y a une flopée de problèmes qui ne valent pas la peine.Je n’ai pas pu faire fonctionner les bandes 5Ghz dans n’importe quel scénario, mon service hostapd 2,4Ghz est devenu sans réponse toutes les douze heures environ, et les vitesses étaient choquantes.

En général, je pense que c’est un échec du matériel espressobin.Les cartes qui devraient autrement être bien supportées sous Linux (certaines des cartes que j’ai testées étaient basées sur ath9k ou ath10k) ne fonctionnent tout simplement pas avec l’interface mPCIe de la carte.Même les cartes officiellement recommandées ont eu des problèmes – le RTL8191SE fonctionnerait par intermittence, et même la carte produite par Globalscale ne fonctionne pas comme annoncé.Incidemment, si vous trouvez une carte bien supportée sur l’espressobin, veuillez déposer une réponse sur le fil de forum connexe que j’ai commencé à discuter de ce problème.

Avec tout cela étant dit, mon intention au début de ce projet était de séparer mon AP de mon routeur, que je finisse par utiliser un espressobin ou non.Garder les tâches de pare-feu / routage à part du sans fil est une belle séparation des préoccupations, et vous pouvez obtenir de très bons dispositifs AP dédiés sans aucune fonction en dehors de la diffusion d’un signal pour le garder simple et puissant.

Pour ce que ça vaut, j’ai fini par acheter un dispositif Ubiquity UniFi et j’ai été totalement heureux avec lui.

Partie deux : logiciel

Il y a deux grands choix ici : Le système d’exploitation et le logiciel de pare-feu.

Système d’exploitation

Le premier choix à faire est de savoir si vous voulez rouler à la main ceci à partir d’une distribution qui supporte aarch64 ou utiliser une solution pré-construite de type firmware comme OpenWRT.Personnellement, j’ai constaté que chaque fois que j’utilise une solution rétrécie comme Tomato/OpenWrt ou FreeNAS pour une construction, je suis généralement frustré sans pouvoir vraiment entrer là-dedans et tweak les choses, donc je vais utiliser une distribution Linux polyvalente pour le système d’exploitation.

Comme je l’ai mentionné précédemment, Armbian et Arch Linux ARM supportent la carte, et espressobin a une documentation officielle pour Ubuntu (ainsi que Yocto, que je ne connaissais pas jusqu’à présent).Bien que je ne vous dirai pas ce qui est le mieux pour votre cas d’utilisation, voici pourquoi j’ai préféré Arch Linux Arm:

• Je suis totalement vendu sur les distributions de libération de roulement.
• Je suis également vendu sur l’exécution de distros de pointe saignantes. Dans le cas d’un routeur, il est agréable d’être proche de l’amont lorsque des mises à jour potentiellement liées à la sécurité sont publiées.
• Arch nous fournira une ardoise propre pour construire au sommet sans aucun service étranger. Cela signifie que, avec une base minimale, nous pouvons savoir exactement ce que nous aurons installé, exposé et en cours d’exécution après avoir assemblé les pièces.
• Je connais et j’aime les gens d’Arch Linux ARM. Salut WarheadsSE!

Firewall

Certains noms comme PFSense me viennent immédiatement à l’esprit, mais j’aimerais vraiment exécuter quelque chose sur Linux puisque je le connais beaucoup mieux qu’un BSD (de plus, les meilleures options d’OS pour l’espressobin sont basées sur Linux).

Le paysage des pare-feu Linux est assez large.Bien que nous utiliserons presque certainement quelque chose basé sur iptables, il y a beaucoup de services de plus haut niveau qui s’assoient au-dessus d’iptables (ufw, firewalld, etc.)Alors que vous pourriez écrire votre propre jeu de règles iptables simple et aller avec, j’ai opté pour l’utilisation d’un service de pare-feu puisque le faire nous achète une belle connaissance tribale que la communauté Linux a favorisé au cours des nombreuses années où ils ont géré des pare-feu iptables.

En général, un bon démon de pare-feu devrait:

• Fit dans le profil « projet OSS sain ». Cela signifie qu’il devrait être activement maintenu, exister depuis un certain temps, et avoir une adoption décente.
• Éviter la complexité. Les conceptions simples sont plus faciles à déboguer, à étendre et à exploiter.
• Porter quelques fonctionnalités agréables à avoir, telles que le support de la mise en forme du trafic et la configuration facile de la redirection de port.

Après avoir farfouillé pendant un certain temps, j’ai opté pour Shorewall.

• Le flux de configuration est compilé puis appliqué. Cela garantit que notre jeu de règles est sain avant de l’appliquer, ce qui signifie également qu’il n’y a pas de démon résident consommant les ressources du périphérique, ce qui est pertinent sur un petit ordinateur monocarte.
• Il est livré avec beaucoup de connaissances historiques agréables intégrées, de sorte que les règles iptables qui sont crachées gèrent beaucoup de cas limites auxquels vous ne penseriez pas normalement.
• Je couvrirai plus de cela plus tard, mais le marquage des paquets et le support natif de la mise en forme du trafic rendent les qdiscs de classe faciles.

Partie trois : La construction de base

Ce post n’a pas pour but d’être un guide complet, mais je voulais inclure les grands points à puce afin qu’il soit évident à quel point cela est facile à mettre en place.

OS Install

Ceci est facile – il suffit de suivre la page espressobin d’Arch Linux Arm.Il est particulièrement important de noter les drapeaux ajoutés sur la commande mkfs.ext4 et la configuration U-Boot supplémentaire.

OS Config

Généralement, les installations d’Arch Linux Arm sont assez bien paramétrées dès le départ.Bien sûr, vous voudrez configurer un utilisateur non root pour administrer avec qui n’est pas le compte par défaut, alors n’oubliez pas de désactiver l’utilisateur alarm, de changer tous les mots de passe et de mettre à jour le système.

En guise de remarque, je recommande fortement d’installer le paquet pacmatic et de l’utiliser à la place du pacman ordinaire.Il détectera automatiquement les mises à jour des fichiers de configuration et aidera à les fusionner, ainsi qu’à mettre en ligne les nouvelles importantes pour les changements de paquets de rupture.

En outre, je suggérerais de configurer etckeeper pour suivre votre configuration de pare-feu (le wiki Arch a une bonne introduction).Je configure le mien pour pousser automatiquement vers un repo gitolite hébergé en privé.Pour être tout à fait honnête, je n’aime pas toutes les solutions de gestion de la configuration qui existent, et presque tous nos changements sont limités à /etc, donc c’est une solution de secours assez bonne pour moi au moins.

Notez que la configuration réseau par défaut pour l’espressobin fonctionne bien pour le cas d’utilisation du routeur :

• Les deux interfaces lan, lan0 et lan1, sont pontées vers l’interface br0. Cela nous permet de centraliser les choses orientées vers le réseau privé comme dnsmasq sur une seule interface virtuelle.
• L’interface orientée vers le public est wan. Elle récupérera son adresse du FAI en amont via DHCP.

Les seuls changements nécessaires pour obtenir br0 et wan configurés pour notre routeur sont deux ajouts : d’abord, l’attribution à l’interface LAN d’une IP statique puisqu’elle sera le routeur, et l’activation de la redirection d’IP et du masquage d’IP dans /etc/systemd/network/br0.network :

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Et confirmer que l’interface faisant face au WAN demandera une adresse au FAI dans /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

J’ai défini UseDNS=no ici car je préfère utiliser les serveurs OpenNIC au lieu de ceux de mon FAI en amont – je mentionnerai où les définir plus tard.

Firewall

Les dépôts Arch Linux ARM aarch64 ont obtenu la dernière version de Shorewall, qui est ce que j’ai utilisé.Mes configurations ne sont pas si fantaisistes, et si vous envisagez sérieusement de déployer Shorewall avec une connexion à l’internet sauvage, je recommande vivement de lire l’intégralité de l’introduction de Shorewall à un pare-feu à deux interfaces.Il couvre les bases de la façon dont vous devriez configurer les choses avec un bon résumé du routage et du pare-feu en général.

Basiquement, vous allez mettre l’interface br0 et wan dans les bonnes zones et définir toutes les règles nécessaires dans /etc/shorewall/rules.N’oubliez pas de laisser les hôtes de votre réseau local utiliser votre serveur DNS :

DNS(ACCEPT) loc $FW

Vous confirmerez que DHCP est autorisé sur l’interface du réseau local dans le fichier interfaces.

Je noterais ici que j’ai frappé un bogue avec Shorewall pendant ma configuration de pare-feu que j’ai trouvé pour être patché littéralement la veille – et Arch Linux ARM avait le paquet mis à jour dans les dépôts en amont déjà.Score un point pour l’utilisation de distros à jour.

DHCP

dnsmasq est l’ajustement parfait pour un routeur domestique.Il regroupe un serveur DNS et DHCP dans un démon léger qui gère tout ce dont vous auriez besoin d’un petit réseau, et il est assez mature pour qu’il y ait beaucoup de documentation l’utilisant pour ce cas d’utilisation exact.

Note : J’ai tenté d’utiliser le serveur DHCP intégré de systemd que vous pouvez définir avec DHCPServer= dans les fichiers .network, car cela semblait être un moyen léger d’exécuter un serveur DHCP sans logiciel supplémentaire.Sans être trop verbeux, cela ne vaut pas la peine, une raison significative étant qu’il n’y a aucun moyen de trouver les baux d’adresses actuels.

Il y a beaucoup d’options qui devraient être définies ici, mais les plus importantes sont:

# Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

Si vous avez besoin d’affectations statiques ou d’alias, ceux-ci sont faciles à ajouter également.

Partie Quatre : Interlude

Avec l’espressobin servant les requêtes DHCP et DNS sur br0, le pare-feu via Shorewall, et le routage des paquets entre le LAN et le WAN, c’est un routeur fonctionnel.A ce stade, il suffit de connecter le port WAN au FAI en amont et les deux ports lan0/lan1 à des périphériques ou un autre commutateur.

Cependant, ce n’est qu’un début.Si nous voulons vraiment considérer cela comme un remplacement de routeur, il y a des choses vraiment cool que nous pouvons faire pour renforcer davantage ses capacités afin qu’il ne se sente pas comme un déclassement de quelque chose comme mon vieil Asus N66U.

Partie cinq : Mises à niveau

J’ai boulonné les fonctionnalités suivantes à mon routeur espressobin vanille, que je couvrirai chacune à son tour :

• Surveillance du flux net
• Mise en forme du trafic

Surveillance du flux net

La visibilité du trafic est quelque chose que j’ai trouvé vraiment utile avec mon firmware Asus Merlin pour suivre l’utilisation.Netflow est la norme de facto pour ce genre de choses, et parmi toutes les options disponibles, j’aime vraiment ipt-netflow parce que c’est un module natif du noyau donc il y a très peu de surcharge et il est très activement maintenu.

Il s’avère que je suis probablement la première personne à l’utiliser sur l’architecture aarch64, parce que j’ai reçu de l’aide pour le faire supporter sur le chipset aarch64.Le mainteneur du projet était (et a été) super réactif aux corrections de bogues, donc je n’ai pas eu de problèmes pour assurer que le module est supporté sur les derniers noyaux sur lesquels le projet Arch Linux ARM fonctionne.

L’utiliser est une question d’installation du paquet ipt-netflow-dkms-git à partir de l’AUR.Il sera construit pour votre noyau parce que dkms est génial, et j’ai déposé ce qui suit dans /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Ceci le chargera, et vous le configurerez dans /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Où $ip est votre destination netflow.Enfin, le trafic est capturé en s’écoulant dans une cible iptables spéciale, ce qui peut être fait directement depuis shorewall, de manière pratique.Dans /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

Ceci dirige tous les paquets sur le routeur pour qu’ils entrent d’abord dans la cible NETFLOW avant toute autre chose, qui traite les paquets et les renvoie pour qu’ils circulent à travers les règles normales que Shorewall met en place.

Bien sûr, ipt-netflow a besoin d’un endroit où envoyer les journaux de netflow, mais cela sort du cadre de ce post.Dans mon cas, j’ai une instance Logstash en cours d’exécution sur mon réseau avec le module netflow en cours d’exécution et agrégeant les événements dans un cluster Elasticsearch.Cela me donne quelques tableaux de bord pratiques et la possibilité de visualiser une grande variété d’informations sur mon réseau.Il y a quelques tableaux de bord par défaut :

Y compris certains assez cool, comme un tableau de bord Geo-IP :

Mais la métrique la plus pertinente qui m’intéresse est mon utilisation totale de la bande passante car j’ai un FAI antédiluvien qui se soucie des plafonds de données.Heureusement, c’est facile avec les données netflow que je collecte : nous pouvons simplement demander à Elasticsearch de faire la somme de certains champs et obtenir ces métriques facilement.Le tableau de bord suivant comporte deux visualisations :

• La jauge compare la somme sur la période en question au plafond que mon FAI m’a fixé, de sorte que je peux facilement voir où se situe mon utilisation actuelle par rapport au plafond.
• La série temporelle trace la bande passante en octets dans le temps afin de voir quand j’utilise cette bande passante.

Ce qui est particulièrement cool dans cette configuration, c’est que, parce que nous stockons les mesures de netflow dans Elasticsearch au lieu d’un autre datastore ou d’une base de données de séries temporelles, je peux en fait cibler les requêtes pour ces tableaux de bord afin de faire des choses comme seulement la somme des octets totaux pour certaines plages CIDR parce que le moteur de stockage sous-jacent (Lucene) comprend nativement les adresses IP.Par exemple, la requête suivante dans Kibana:

NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

Filtrera efficacement les gros morceaux potentiels de bande passante qui se produisent entre les hôtes de mon réseau local, comme le streaming entre mon hôte Kodi et ma machine NAS.Cool.

Traffic Shaping

Ceci s’est transformé en une entreprise assez massive qui était un trou de lapin fascinant dans lequel disparaître.Certains firmwares de routeur stock et la plupart des firmwares de routeur personnalisés offrent une certaine forme de QoS ou de mise en forme du trafic, donc j’espérais faire la même chose sur mon routeur personnalisé afin de protéger certains de mes trafics (comme Overwatch) des latences élevées.

Le monde de la technologie QoS est un endroit fascinant.Alors que vous pourriez vous fier à certains schémas simples comme un filtre HTB (hierarchical token bucket), les avancées dans le filtrage des paquets sont étonnamment actives et il existe de nombreuses approches intéressantes.

Ce sur quoi j’ai finalement opté est un filtre HFSC (hierarchical fair-service curve).Je vais être honnête : les mathématiques derrière cela sont tellement hors de ma ligue que j’ai dû lire plusieurs résumés tentant de les décomposer pour les personnes normales, et la meilleure explication qui avait du sens pour moi était un excellent gist sur lequel je suis tombé de l’utilisateur GitHub eqhmcow qui explique les avantages et l’utilisation de HFSC en pratique.

Le tl;dr est le suivant : avec une classe de contrôle du trafic HFSC, vous pouvez très efficacement hiérarchiser le trafic et atteindre un bon équilibre entre les flux qui nécessitent une bande passante élevée et des latences faibles.Ce n’est pas une solution miracle – vous devrez toujours marquer quels types de trafic sont sensibles à la latence – mais cela a fonctionné assez bien pour moi.Sans les règles en place, un téléchargement de Steam ou de Blizzard Launcher tuera les temps de ping, tandis que les règles HFSC actives réduiront gracieusement ces portions lourdes du trafic pour s’assurer que les flux interactifs ne sont pas affectés.C’est vraiment génial!

Le gist susmentionné fait un bon travail en exposant comment configurer vos classes tc à partir de zéro.Cependant, Shorewall peut effectivement gérer le contrôle du trafic par classe de manière native, de sorte que nous pouvons configurer des règles de QoS puissantes assez facilement.Les fichiers de configuration suivants sont basés sur mes vitesses de bande passante mesurées, qui sont d’environ 230 vers le bas et 10 vers le haut.

La première étape consiste à définir les classes tc pertinentes pour chaque périphérique dans le fichier tcdevices:

# cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

Ici, l’interface br0 orientée vers le réseau local obtient un gigabit complet, mais l’interface wan du réseau étendu obtient 97% de sa vitesse vers le bas et 90% de ma vitesse disponible vers le haut.Le raisonnement pour ces chiffres est expliqué dans le gist – nous sommes essentiellement en train de recréer ce jeu de règles en termes de Shorewall.

Puis, définissez comment les marques de paquets vont correspondre aux classes tc dans le fichier tcclasses:

# cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

Cela va faire tomber le trafic important/interactif dans des classes qui obtiennent une priorité plus élevée.Bien sûr, nous devons également marquer les paquets qui devraient obtenir cette plus haute priorité, ce qui est fait dans mangle:

# cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24

Cela définit les marques de haute priorité (1 et 2) qui sont traitées par notre classe tc.L’exemple inclut des pings ICMP, ssh, certains jeux Blizzard, et le trafic local.

Le rechargement de shorewall devrait les mettre en œuvre.Le résultat final devrait permettre le trafic de masse comme les téléchargements ou les flux tout en n’affectant pas négativement la latence du trafic interactif comme ssh, les temps de ping dans les jeux, et ainsi de suite.Mes tests informels ont confirmé cela – notez que si vous décidez de vérifier cela vous-même, vous pouvez observer des pics de latence immédiatement après une rafale initiale de trafic de masse, mais HFSC intervient rapidement pour faire respecter les limites afin de maintenir les latences basses pour le trafic interactif.

J’ai quelques ensembles de benchmarks qui montrent HFSC en action, mais voici un tout petit exemple : comment les latences ping sont impactées lorsque iperf est exécuté en arrière-plan.

Comme vous pouvez le voir, sans aucune règle de contrôle du trafic en place, les rafales de trafic en vrac peuvent avoir des impacts assez négatifs sur le trafic interactif sensible aux latences élevées.Avec HFSC, nous pouvons éviter ces problèmes.

Conclusion

J’utilise mon routeur maison depuis plusieurs mois maintenant et il semble fonctionner parfaitement.Je n’ai pas connu de chutes de connexion mystérieuses, de problèmes de vitesse ou de problèmes matériels pendant toute la période de fonctionnement continu, donc je considérerais la construction comme un succès.Les mises à niveau sont bien aussi ; après un sudo pacmatic -Syu et un redémarrage normaux, le système revient en ligne avec toutes les règles iptables et d’autres services comme prévu, de sorte que le maintien des derniers noyaux et autres paquets est simple.

Pour résumer:

• Pour une personne douée pour les opérations ou ayant un esprit technique, la construction d’un routeur personnalisé est très faisable. Les ordinateurs monocartes ARM rendent le démarrage peu coûteux et pratique.
• Les solutionsOSS pour le pare-feu, la mise en forme du trafic et la surveillance du réseau sont matures et faciles à utiliser. En particulier, des solutions finement vieillies comme Shorewall et dnsmasq sont très bien documentées et ont de nombreuses années de travail mises dans leur documentation et leur ensemble de fonctionnalités.
• Alors que le routage + DNS + DHCP est un slam dunk, le WiFi OSS peut être frappé ou manqué. Votre kilométrage peut varier, mais mon espressobin n’est tout simplement pas un bon point d’accès.