Tyblog

» Construyendo mi router ideal por 50 dólares »

Después de que mi Asus N66U estirara la pata, consideré algunas opciones: otro router «todo en uno», actualizar a algo como un EdgeRouter, o fabricar algo personalizado.Cuando leí el artículo de Ars Technica en el que se ensalzaban las virtudes de construir tu propio router, lo tuve claro: DIY it is.

Tengo un poco de complejo psicológico cuando se trata de rodar mis propias soluciones sobre-ingeniería, pero me puse algunos objetivos generales: el resultado final debe ser barato, de bajo consumo, bien soportado por Linux, y extensible.Por cierto, las placas ARM encajan muchos de estos requisitos, y algunos como el Raspberry Pi han despertado tanta actividad de la comunidad que hay un gran apoyo para la plataforma ARM, a pesar de que puede sentirse extraño de x86.

Me las he arreglado para improvisar un dispositivo que no sólo es muy barato para lo que hace, pero es muy capaz en su propio derecho.Si usted tiene algún interés en la construcción de su propio router casero, voy a demostrar aquí que hacerlo no sólo es factible, pero relativamente fácil de hacer y ofrece una gran cantidad de utilidad – de la conformación del tráfico, a la supervisión de flujo de red, a DNS dinámico.

Lo construí usando el espressobin, Arch Linux Arm, y Shorewall.

Esa foto muestra la placa encerrada en una carcasa impresa en 3d.Desafortunadamente, el espressobin no es lo suficientemente popular como para presumir de una amplia variedad de carcasas adquiribles como tiene la Raspberry Pi, pero hay algunos buenos modelos por ahí para imprimir en 3d.

Como nota al margen, la siguiente documentación no pretende ser una guía completa paso a paso para hacer lo mismo por ti mismo.Aunque quiero cubrir muchas de las opciones que entraron en la construcción, la configuración de algo tan importante como un router / firewall realmente no debe ser un trabajo de copiar / pegar y sería mejor ser guiado libremente por los pasos aquí con una comprensión completa de cómo y por qué.

• El por qué
• Primera parte: Hardware
  • ¿Qué pasa con el WiFi?
• Segunda parte: Software
  • Sistema operativo
  • Firewall
• Tercera parte: La construcción básica
  • Instalación del SO
  • Configuración del SO
  • Firewall
  • DHCP
• Cuarta parte: Interludio
• Parte cinco: Actualizaciones
  • Monitoreo de flujo de red
  • Formación del tráfico
• Conclusión

El por qué

Hay un montón de routers sólidos por ahí que usted puede comprar que no son incendios de neumáticos de stock ISP y probablemente sería más que adecuado (te estoy mirando con amor, EdgeRouter Lite).Entonces, ¿por qué molestarse con todo esto? Hay algunos beneficios legítimos aquí:

• Es realmente muy asequible. Mi router ha pasado mis puntos de referencia con colores de vuelo, y tiene todas las características que podría tirar de Linux (que es una gran lista).
• Es seguro. Me parece que cada mes se anuncia una nueva vulnerabilidad para algún dispositivo de borde de red de consumo. Compara eso con un firewall autogestionado, y sé exactamente qué servicios están expuestos (y si iptables se rompe, el mundo tiene problemas mayores). Para cualquier detractor, por cierto, el único puerto que escucha en mi cortafuegos es un puerto aleatorio de alta numeración para la autenticación ssh sólo de clave pública. Así que sí, creo que es más seguro que algún router de consumo de Huawei.
• Tiene grandes características. Claro, mi espressobin puede enrutar y servir como un firewall, pero he caído en algunas otras capacidades útiles también.
• Es performante. En los puntos de referencia menores que realicé, el espressobin puede realmente empujar el tráfico sin romper a sudar.
• Fue muy divertido de construir. Si usted a) necesita un nuevo router o b) quiere cortar sus dientes en un proyecto de una sola placa ARM, esto podría ser un buen ajuste.

Parte Uno: Hardware

Técnicamente usted podría armar un router usando cualquier computadora con dos NICs, pero podemos hacerlo igualmente bien con menos energía, un factor de forma más pequeño, y más asequible.Las placas ARM dan en el clavo: son súper baratas, más potentes de lo que se piensa, y están bien soportadas con tantas variantes en el mercado.

El contendiente más conocido es la Raspberry Pi, pero sin dos NICs o red gigabit, no es una buena opción.Además, estás pagando por cosas como una GPU que no son necesarias en un dispositivo de red sin cabeza.

La buena noticia es que el año pasado, el espressobin fue lanzado, y es súper capaz.Se siente construido a propósito para este tipo de cosas: red gigabit, un interruptor incorporado, y sin adornos que de otro modo se necesitaría para algo más de propósito general (ni siquiera hay una pantalla de salida, sólo una consola de serie).

Aunque la placa es bastante joven, tanto Armbian como Arch Linux Arm soportan el hardware, y ambos proyectos hacen un gran trabajo con él.Si usted no ha explorado el mundo de Linux en ARM, no hay mucho que temer aquí.Armbian y Arch Linux Arm proporcionan todo lo que necesita para aarch64 de forma nativa en los repos de la distribución, por lo que hay poco que se encontrará que se siente extraño en un chip ARM de 64 bits, y ciertamente se siente que vale la pena cuando se tiene en cuenta la asequibilidad del hardware y la huella de baja potencia.

Aquí están algunos de los aspectos más destacados para mí:

• La placa incluye un conmutador de red Topaz incorporado. En mis pruebas de red, el tráfico que sólo cruza las interfaces LAN es indistinguible de la velocidad del tráfico que pasa a través de un interruptor de vainilla. Si usted transmite desde un NAS o tiene otros requisitos altos para la comunicación entre dispositivos que cruzan el router, esto puede hacer una gran diferencia.
• La consola de serie es un ciudadano de primera clase. En mi Raspberry Pis, a veces me frustró tener que llegar a mi pantalla HDMI cuando la depuración de los problemas, pero el espressobin tiene un puerto serie micro USB para facilitar el acceso a la consola.
• El chip aarch64 ha sido grande. No sólo ha manejado todo lo que he lanzado en él, pero ¿sabía usted que no es afectado por meltdown? Los chips Cortex-A53 no se ven afectados por el error de ejecución especulativa, por lo que es una ventaja añadida.

¿Qué pasa con el WiFi?

Haré una pequeña nota aquí que intenté usar el espressobin como un punto de acceso inalámbrico también.La placa tiene una ranura mini PCIe muy adecuada para una tarjeta inalámbrica, y aunque debería haber funcionado, puedo informar definitivamente que no es una buena idea.

Sin entrar en detalles dolorosos, hay una serie de problemas que no hacen que valga la pena el esfuerzo.No pude conseguir bandas de 5Ghz de trabajo en cualquier escenario, mi servicio hostapd 2.4Ghz se convirtió en no responde cada doce horas más o menos, y las velocidades eran escandalosamente malo.

En general, creo que esto es un fallo del hardware de espressobin.Tarjetas que deberían ser bien soportadas en Linux (algunas de las tarjetas que probé estaban basadas en ath9k o ath10k) simplemente no funcionan con la interfaz mPCIe de la placa.Incluso las tarjetas recomendadas oficialmente tenían problemas – la RTL8191SE funcionaba intermitentemente, e incluso la tarjeta producida por Globalscale no funciona como se anuncia.Por cierto, si encuentras una tarjeta bien soportada en la espressobin, por favor, deja una respuesta en el hilo del foro relacionado que empecé a discutir este tema.

Con todo lo dicho, mi intención en este inicio de este proyecto era separar mi AP de mi router, si terminaba usando una espressobin o no.Mantener las tareas de firewalling / enrutamiento aparte de la tecnología inalámbrica es una buena separación de las preocupaciones, y usted puede conseguir muy buenos dispositivos dedicados AP sin ninguna función fuera de la difusión de una señal para mantenerlo simple y potente.

Por lo que vale, terminé comprando un dispositivo Ubiquity UniFi y he sido totalmente feliz con él.

Parte dos: Software

Hay dos grandes opciones aquí: Sistema operativo y software de cortafuegos.

Sistema operativo

La primera elección que hay que hacer es si se quiere rodar a mano esto desde una distribución que soporte aarch64 o utilizar una solución preconstruida tipo firmware como OpenWRT.Personalmente, he encontrado que cada vez que utilizo una solución de contracción como Tomato/OpenWrt o FreeNAS para una construcción, por lo general me frustra sin ser capaz de realmente entrar allí y ajustar las cosas, por lo que voy a utilizar una distribución de Linux de propósito general para el sistema operativo.

Como mencioné anteriormente, Armbian y Arch Linux ARM soportan la placa, y espressobin tiene documentación oficial para Ubuntu (así como Yocto, que desconocía hasta ahora).Aunque no te voy a decir cuál es el mejor para tu caso de uso, he aquí por qué he preferido Arch Linux Arm:

• Estoy totalmente vendido a las distribuciones rolling release.
• También estoy vendido a correr encima de distros de vanguardia. En el caso de un router, es bueno estar cerca de las actualizaciones relacionadas con la seguridad.
• Arch nos proporcionará una pizarra limpia para construir sobre ella sin ningún servicio extraño. Esto significa que, con una base mínima, podemos saber exactamente lo que tendremos instalado, expuesto y funcionando después de juntar las piezas.
• Conozco y me gusta la gente de Arch Linux ARM. Hola WarheadsSE!

Firewall

Inmediatamente me vienen a la mente algunos nombres como PFSense, pero realmente me gustaría ejecutar algo en Linux ya que lo conozco mucho mejor que un BSD (además, las mejores opciones de SO para el espressobin están basadas en Linux).

El panorama de los cortafuegos de Linux es bastante amplio, aunque seguramente utilizaremos algo basado en iptables, hay un montón de servicios de nivel superior que se asientan sobre iptables (ufw, firewalld, etc.).) Mientras que usted podría escribir su propio conjunto de reglas iptables y seguir con él, he optado por utilizar un servicio de cortafuegos, ya que al hacerlo nos compra un buen conocimiento tribal que la comunidad de Linux ha fomentado a lo largo de los muchos años que han gestionado los cortafuegos iptables.

En general, un buen demonio de cortafuegos debe:

• Encajar en el perfil de «proyecto OSS saludable». Esto significa que debería ser mantenido activamente, haber existido durante un tiempo, y tener una adopción decente.
• Evitar la complejidad. Los diseños simples son más fáciles de depurar, extender y operar.
• Apoyar algunas características agradables de tener, como el apoyo a la conformación del tráfico y la configuración fácil de reenvío de puertos.

Después de husmear por un tiempo, me decidí por Shorewall.Aquí están algunas de las razones más notables que fui con él:

• El flujo de configuración es compilar-entonces-aplicar. Esto asegura que nuestro conjunto de reglas es sano antes de aplicarlo, lo que también significa que no hay demonio residente consumiendo los recursos del dispositivo, lo que es relevante en un pequeño ordenador de placa única.
• Viene con un montón de buen conocimiento histórico incorporado, por lo que las reglas de iptables que se escupen manejan un montón de casos de borde en los que normalmente no pensarías.
• Cubriré más de esto más tarde, pero el marcado de paquetes y el soporte nativo para la conformación de tráfico hacen que los qdiscs de clase sean fáciles.

Tercera Parte: La construcción básica

Este post no pretende ser una guía completa, pero quería incluir los puntos generales para que sea evidente lo fácil que es armar esto.

Instalación del SO

Este es fácil – sólo tienes que seguir la página de Arch Linux Arm espressobin.Es particularmente importante tener en cuenta las banderas añadidas en el comando mkfs.ext4 y la configuración adicional de U-Boot.

Configuración del SO

Generalmente, las instalaciones de Arch Linux Arm están bastante bien configuradas desde el principio.Por supuesto, querrás configurar un usuario no root para administrar con él que no sea la cuenta por defecto, así que recuerda desactivar el usuario alarm, cambiar todas las contraseñas y actualizar el sistema.

Como nota al margen, recomiendo encarecidamente instalar el paquete pacmatic y usarlo en lugar del habitual pacman.Detectará automáticamente las actualizaciones de los archivos de configuración y ayudará a fusionarlos, así como a alinear las noticias importantes para los cambios de paquetes de ruptura.

Además, sugeriría configurar etckeeper para rastrear la configuración de su firewall (el wiki de Arch tiene una buena introducción).Yo configuré el mío para empujar automáticamente a un repo privado de gitolite.Para ser completamente honesto, no me gustan todas las soluciones de gestión de la configuración por ahí, y casi todos nuestros cambios se limitan a /etc, por lo que esta es una solución de copia de seguridad lo suficientemente bueno para mí, al menos.

Tenga en cuenta que la configuración de red por defecto para el espressobin funciona bien para el caso de uso del router:

• Ambas interfaces lan, lan0 y lan1, se puentean a la interfaz br0. Esto nos permite centralizar las cosas orientadas a la red privada como dnsmasq en una sola interfaz virtual.
• La interfaz orientada al público es wan. Obtendrá su dirección del ISP de origen a través de DHCP.

Los únicos cambios necesarios para configurar br0 y wan para nuestro router son dos adiciones: primero, asignar a la interfaz LAN una IP estática ya que será el router, y habilitar el reenvío de IP y el enmascaramiento de IP en /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Y confirmar que la interfaz orientada a la WAN solicitará una dirección al ISP en /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Aquí pongo UseDNS=no ya que prefiero usar servidores OpenNIC en lugar de los de mi ISP de origen -más adelante mencionaré dónde ponerlos.

Firewall

Los repositorios de Arch Linux ARM aarch64 tienen la última versión de Shorewall, que es la que utilicé.Mis configuraciones no son tan sofisticadas, y si estás considerando seriamente desplegar Shorewall con una conexión a la Internet salvaje, recomiendo encarecidamente leer toda la introducción de Shorewall a un firewall de dos interfaces.Cubre los fundamentos de cómo debe configurar las cosas con un buen resumen de enrutamiento y firewalling en general.

Básicamente, pondrá la interfaz br0 y wan en las zonas correctas y establecerá cualquier regla necesaria en /etc/shorewall/rules.Recuerde que debe permitir que los hosts de su LAN utilicen su servidor DNS:

DNS(ACCEPT) loc $FW

Confirmará que el DHCP está permitido en la interfaz LAN en el archivo interfaces.

Aquí me gustaría señalar que me encontré con un error con Shorewall durante la configuración de mi cortafuegos que encontré parcheado literalmente el día anterior – y Arch Linux ARM tenía el paquete actualizado en los repositorios upstream ya.Anota un punto por usar distros actualizadas.

DHCP

dnsmasq es la solución perfecta para un router doméstico, ya que reúne un servidor DNS y DHCP en un demonio ligero que maneja todo lo que se necesita en una red pequeña, y es lo suficientemente maduro como para que haya un montón de documentación que lo utiliza para ese caso de uso exacto.

Nota: Intenté usar el servidor DHCP incorporado en systemd que se puede configurar con DHCPServer= en los archivos .network, ya que parecía una manera ligera de ejecutar un servidor DHCP sin software adicional.Sin ser demasiado verboso, no vale la pena, una razón importante es que no hay manera de encontrar los arrendamientos de direcciones actuales.

Hay un montón de opciones que deben establecerse aquí, pero las más importantes son:

# 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 necesita asignaciones estáticas o alias, son fáciles de añadir también.

Cuarta Parte: Interludio

Con el espressobin sirviendo peticiones DHCP y DNS en br0, cortafuegos a través de Shorewall, y el enrutamiento de paquetes entre la LAN y WAN, es un router en funcionamiento.En este punto, la conexión del puerto WAN a la corriente ascendente del ISP y los dos puertos lan0/lan1 a los dispositivos u otro interruptor es todo lo que es necesario.

Sin embargo, eso es sólo un comienzo.Si realmente queremos considerar esto como un reemplazo del router, hay algunas cosas realmente interesantes que podemos hacer para reforzar aún más sus capacidades para que no se sienta como un downgrade de algo como mi viejo Asus N66U.

Parte Cinco: Actualizaciones

Atornillé las siguientes características a mi router vanilla espressobin, que cubriré cada una a su vez:

• Monitoreo de Netflow
• Formación del tráfico

Monitoreo de Netflow

La visibilidad del tráfico es algo que encontré realmente valioso con mi firmware Asus Merlin para rastrear el uso.Netflow es el estándar de facto para este tipo de cosas, y entre todas las opciones disponibles, me gusta mucho ipt-netflow porque es un módulo nativo del kernel por lo que hay muy poca sobrecarga y se mantiene muy activamente.

Resulta que probablemente soy la primera persona en usarlo en la arquitectura aarch64, porque obtuve algo de ayuda para que fuera soportado en el chipset aarch64.El mantenedor del proyecto fue (y ha sido) súper receptivo a las correcciones de errores, así que no he tenido ningún problema para asegurar que el módulo sea soportado en los últimos kernels en los que corre el proyecto Arch Linux ARM.

Usarlo es cuestión de instalar el paquete ipt-netflow-dkms-git desde el AUR.Se construirá para tu kernel porque dkms es impresionante, y solté lo siguiente en /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Eso lo cargará, y lo configuras en /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Donde $ip es tu destino de netflow.Por último, el tráfico se captura fluyendo en un objetivo especial de iptables, lo que se puede hacer directamente desde shorewall, convenientemente.En /etc/shorewall/start:

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

Esto dirige todos los paquetes en el router para entrar primero en el objetivo NETFLOW antes de cualquier otra cosa, que procesa los paquetes y los pasa de nuevo a fluir a través de las reglas normales que Shorewall establece.

Por supuesto, ipt-netflow necesita un lugar para enviar los registros de netflow, pero eso está fuera del alcance de este post.En mi caso, tengo una instancia de Logstash que se ejecuta en mi red con el módulo netflow que se ejecuta y agrega eventos en un clúster de Elasticsearch.Esto me da algunos cuadros de mando conveniente y la capacidad de visualizar una amplia variedad de información acerca de mi red.Hay algunos dashboards por defecto:

Incluyendo algunos bastante interesantes, como un dashboard Geo-IP:

Sin embargo, la métrica más relevante que me interesa es mi uso total de ancho de banda porque tengo un ISP antediluviano que se preocupa por los topes de datos.Afortunadamente, eso es fácil con los datos de netflow que estoy recopilando: podemos pedirle a Elasticsearch que sume algunos campos y obtener esas métricas fácilmente.El siguiente panel tiene dos visualizaciones:

• El indicador compara la suma durante el período de tiempo en cuestión con el límite que mi ISP ha establecido para mí, por lo que puedo ver fácilmente dónde se encuentra mi uso actual en comparación con el límite.
• La serie de tiempo traza el ancho de banda en bytes a lo largo del tiempo con el fin de ver cuando estoy usando ese ancho de banda.

Algo especialmente interesante de esta configuración es que, dado que estamos almacenando las métricas de netflow en Elasticsearch en lugar de en algún otro almacén de datos o base de datos de series temporales, puedo centrar las consultas para estos paneles con el fin de hacer cosas como sólo sumar el total de bytes para ciertos rangos CIDR porque el motor de almacenamiento subyacente (Lucene) entiende las direcciones IP de forma nativa.Por ejemplo, la siguiente consulta en Kibana:

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

Filtrará de forma efectiva los grandes trozos de ancho de banda que se produzcan entre los hosts de mi LAN, como el streaming entre mi host Kodi y la máquina NAS.Cool.

Traffic Shaping

Esto se convirtió en una empresa bastante masiva que fue un agujero de conejo fascinante para desaparecer.Algunos firmwares de routers estándar y la mayoría de los personalizados ofrecen alguna forma de QoS o conformación de tráfico, así que esperaba hacer lo mismo en mi router personalizado para proteger parte de mi tráfico (como Overwatch) de las altas latencias.

El mundo de la tecnología QoS es un lugar fascinante.Mientras que podría confiar en algunos esquemas simples como un filtro HTB (hierarchical token bucket), los avances en el filtrado de paquetes son sorprendentemente activos y hay un montón de enfoques interesantes.

Lo que finalmente decidí fue un filtro HFSC (hierarchical fair-service curve).Seré sincero: las matemáticas que hay detrás están tan fuera de mi alcance que tuve que leer varios resúmenes que intentaban desglosarlo para la gente normal, y la mejor explicación que tuvo sentido para mí fue un excelente gist con el que me topé del usuario de GitHub eqhmcow que explica los beneficios y el uso de HFSC en la práctica.

El resumen es el siguiente: con una clase de control de tráfico HFSC, se puede priorizar el tráfico de forma muy eficaz y lograr un buen equilibrio entre los flujos que requieren un gran ancho de banda y bajas latencias.No es una solución mágica – todavía tendrá que marcar qué tipos de tráfico son sensibles a la latencia – pero ha funcionado bastante bien para mí.Sin las reglas en su lugar, una descarga de Steam o Blizzard Launcher matará los tiempos de ping, mientras que las reglas HFSC activas recortarán con gracia esas porciones pesadas de tráfico para asegurar que los flujos interactivos no se vean afectados.Es realmente grande!

El gist antes mencionado hace un buen trabajo de establecer cómo configurar sus clases tc desde cero.Sin embargo, Shorewall realmente puede manejar el control de tráfico de clase de forma nativa, por lo que podemos configurar poderosas reglas de QoS con bastante facilidad.Los siguientes archivos de configuración se basan en las velocidades de ancho de banda que he medido, que son aproximadamente 230 de bajada y 10 de subida.

El primer paso es establecer las clases tc relevantes para cada dispositivo en el archivo tcdevices:

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

Aquí la interfaz br0 orientada a la LAN obtiene un gigabit completo, pero la interfaz WAN wan obtiene el 97% de su velocidad de bajada y el 90% de mi velocidad de subida disponible.El razonamiento para estos números se explica en el gist – estamos esencialmente recreando este conjunto de reglas en términos de Shorewall.

A continuación, definimos cómo las marcas de paquetes se asignarán a las clases tc en el archivo 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

Esto hará que el tráfico importante/interactivo caiga en las clases que tienen mayor prioridad.Por supuesto, también necesitamos marcar los paquetes que deben obtener esa mayor prioridad, lo que se hace en 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

Esto establece las marcas de alta prioridad (1 y 2) que son manejadas por nuestra clase tc.El ejemplo incluye pings ICMP, ssh, algunos juegos de Blizzard y tráfico local.

La recarga de shorewall debería poner esto en práctica.El resultado final debería permitir el tráfico masivo, como las descargas o los streams, sin afectar negativamente a la latencia del tráfico interactivo, como ssh, los tiempos de ping en el juego, etc. Mis pruebas informales han confirmado esto – tenga en cuenta que si decide verificar esto usted mismo, puede observar picos de latencia inmediatamente después de una ráfaga inicial de tráfico masivo, pero HFSC interviene rápidamente para hacer cumplir los límites para mantener las latencias bajas para el tráfico interactivo.

Tengo un par de conjuntos de puntos de referencia que muestran HFSC en acción, pero aquí hay un pequeño ejemplo: cómo la latencia de ping se ve afectada cuando iperf se ejecuta en el fondo.

Como puedes ver, sin ninguna regla de control de tráfico, las ráfagas de tráfico masivo pueden tener impactos bastante negativos en el tráfico interactivo sensible a las altas latencias.Con HFSC, podemos evitar esos problemas.

Conclusión

He estado usando mi router casero durante varios meses y parece funcionar muy bien.No he experimentado ninguna misteriosa caída de la conexión, problemas de velocidad o problemas de hardware durante todo el período de funcionamiento continuo, por lo que consideraría la construcción un éxito.Las actualizaciones están bien también; después de un normal sudo pacmatic -Syu y reiniciar el sistema vuelve a estar en línea con todas las reglas iptables y otros servicios como se esperaba, por lo que mantenerse al día con los últimos kernels y otros paquetes es sencillo.

Para resumir:

• Para una persona con conocimientos de operaciones o de mente técnica, una construcción de router personalizado es muy factible. Los ordenadores de placa única ARM hacen que sea barato y conveniente empezar.
• Las soluciones de software libre para el cortafuegos, la conformación del tráfico y la supervisión de la red son maduras y fáciles de trabajar. En particular, las soluciones más antiguas como Shorewall y dnsmasq están muy bien documentadas y tienen muchos años de trabajo en su documentación y conjunto de características.
• Mientras que el enrutamiento + DNS + DHCP es un éxito, el WiFi OSS puede ser un éxito o un fracaso. Su kilometraje puede variar, pero mi espressobin simplemente no es un buen punto de acceso.