Tyblog

” Construindo meu roteador ideal por $50 ”

Depois que meu Asus N66U chutou o balde, eu considerei algumas opções: outro router tudo-em-um, actualizar para algo como um EdgeRouter, ou fazer algo personalizado.Quando li o artigo da Ars Technica, que espelhava as virtudes de construir seu próprio roteador, isso praticamente o resolveu: Faça-você-mesmo é.

Eu tenho um pouco de complexo psicológico quando se trata de rolar minhas próprias soluções super-projetadas, mas eu defini alguns objetivos gerais: o resultado final deve ser barato, de baixa potência, bem suportado pelo Linux, e extensível.

Eu consegui juntar um dispositivo que não só é barato pelo que faz, mas é extremamente capaz por direito próprio.

Eu construí-o usando o espressobin, Arch Linux Arm, e Shorewall.

Aquele quadro mostra o quadro fechado em uma caixa impressa em 3d. Infelizmente, o expressobin não é popular o suficiente para ostentar uma grande variedade de caixas compráveis como o Raspberry Pi tem, mas existem alguns bons modelos para impressão em 3d.

Como nota lateral, a seguinte documentação não pretende ser um guia passo-a-passo completo para fazer o mesmo.Embora eu queira cobrir muitas das escolhas que entraram na construção, configurar algo tão importante como um roteador/firewall realmente não deveria ser um trabalho de copiar/colar e seria melhor ser livremente guiado pelos passos aqui com uma compreensão completa de como e porquê.

• O Porquê
• Parte Um: Hardware
  • E sobre WiFi?
• Parte Dois: Software
  • Operating System
  • Firewall
• Parte Três: A Construção Básica
  >
  • Instalação de SO

  >

  • Configuração de SO

  >

  • Firewall
  • DHCP

  >

>

• Parte Quatro: Interlúdio

>

• Parte Cinco: Atualizações
  >
  • Monitoramento de fluxo de rede

  >

  • Formação de tráfego

  >

• Conclusão

>

O Porquê

>

Existem muitos roteadores sólidos lá fora que você pode comprar que não são estoque ISP incêndios de pneus e provavelmente seria mais do que adequado (Estou olhando para você amorosamente, EdgeRouter Lite).Então por que se preocupar com tudo isso? Há alguns benefícios legítimos aqui:

• É na verdade muito acessível. O meu router passou os meus benchmarks com distinção, e tem todas as funcionalidades que eu poderia retirar do Linux (que é uma grande lista).
• É seguro. Eu sinto que uma nova vulnerabilidade é anunciada todos os meses para algum dispositivo de ponta da rede de consumo. Compare isso com um firewall auto gerenciado, e eu sei exatamente quais serviços estão expostos (e se o iptables estiver quebrado, o mundo tem problemas maiores). Para qualquer opositor, por sinal, a única porta que escuta no meu firewall é uma porta aleatória de número alto para autenticação ssh apenas com chave pública. Então sim, eu acho que é mais seguro do que algum roteador Huawei de consumo.
• Tem ótimos recursos. Claro, meu espressobin pode rotear e servir como firewall, mas eu também deixei cair alguns outros recursos úteis.
• É performante. Nas pequenas referências que fiz, o espressobin pode realmente empurrar o tráfego sem quebrar um suor.
• Foi muito divertido de construir. Se você a) precisa de um novo roteador ou b) quer cortar seus dentes em um projeto ARM de placa única, este pode ser um bom ajuste.

Parte Um: Hardware

Tecnicamente você poderia montar um roteador usando qualquer computador com dois NICs, mas nós podemos fazer igualmente bem com menos energia, um fator de forma menor, e mais acessível.As placas ARM chegam ao ponto ideal: elas são super baratas, mais poderosas do que você imagina, e bem suportadas com tantas variantes no mercado.

O concorrente mais conhecido é o Raspberry Pi, mas sem dois NICs ou rede gigabit, não é uma boa opção.Além disso, você está pagando por coisas como uma GPU que não são necessárias em um dispositivo de rede sem cabeça.

A boa notícia é que no ano passado, o espressobin foi lançado, e é super capaz.Ele parece ter sido construído para esse tipo de coisa: rede gigabit, um switch embutido, e sem folhos que você precisaria para algo mais geral (não há nem um display, apenas um console serial).

Embora a placa seja bastante jovem, tanto o Armbian quanto o Arch Linux Arm suportam o hardware, e ambos os projetos fazem um ótimo trabalho com ele.Se você não explorou o mundo do Linux no ARM, não há muito a temer aqui.Armbian e Arch Linux Arm fornecem tudo o que você precisa para aarch64 nativamente no repositório de distribuição, então há pouco que você vai encontrar que parece estranho em um chip ARM de 64 bits, e com certeza vale a pena quando você fatoriza na acessibilidade do hardware e no baixo consumo de energia.

Aqui estão alguns dos destaques para mim:

• A placa inclui um switch de rede Topaz embutido. No meu teste de rede, o tráfego que só atravessa as interfaces LAN é indistinguível – em termos de velocidade – do tráfego que passa por um switch vanilla. Se você transmite a partir de um NAS ou tem requisitos elevados para comunicação entre dispositivos que cruzam o roteador, isso pode fazer uma grande diferença.
• O console serial é um cidadão de primeira classe. No meu Raspberry Pis, por vezes fiquei frustrado por ter de alcançar o meu ecrã HDMI quando depurava problemas, mas o expressobin tem uma porta série micro USB para fácil acesso ao console.
• O chip aarch64 tem sido ótimo. Não só tratou de tudo o que eu lhe atirei, como sabia que não é afectado pelo derretimento? Os chips Cortex-A53 não são afetados pelo bug de execução especulativa, então isso é um bônus adicional.

E sobre WiFi?

Eu vou fazer uma pequena nota aqui que eu tentei usar o espressobin como um ponto de acesso sem fio também.A placa tem um slot mini PCIe bem adequado para uma placa sem fio, e embora devesse ter funcionado, eu posso relatar definitivamente que não é uma boa idéia.

Sem entrar em detalhes dolorosos, há uma série de problemas que não fazem valer a pena o esforço.Eu não consegui colocar bandas de 5Ghz funcionando sob qualquer cenário, meu serviço de 2.4Ghz hostapd ficou sem resposta a cada doze horas ou mais, e as velocidades eram chocantemente ruins.

Em geral, eu acho que isto é uma falha do hardware espressobin.Cards que deveria ser bem suportado no Linux (algumas das placas que eu testei eram ath9k ou ath10k) simplesmente não funcionam com a interface mPCIe da placa.Mesmo os cartões oficialmente recomendados tinham problemas – o RTL8191SE funcionaria intermitentemente, e mesmo o cartão produzido pela Globalscale não funciona como anunciado. A propósito, se você encontrar um cartão bem suportado no espressobin, por favor, deixe uma resposta no tópico do fórum relacionado que comecei a discutir este assunto.

Com tudo isso dito, minha intenção neste início deste projeto era separar meu AP do meu roteador, quer eu acabasse usando um espressobin ou não.Manter as tarefas de firewalling/routing separadas do wireless é uma boa separação de preocupações, e você pode obter muito bons dispositivos AP dedicados sem qualquer função fora da transmissão de um sinal para mantê-lo simples e poderoso.

Para que conste, acabei comprando um dispositivo Ubiquity UniFi e fiquei totalmente satisfeito com ele.

Parte Dois: Software

Existem duas grandes escolhas aqui: OS e firewalling software.

Operating System

A primeira escolha a fazer é se você quer enrolar isto manualmente a partir de uma distribuição que suporta aarch64 ou usar uma solução tipo firmware-pré-construída como o OpenWRT.Pessoalmente, eu descobri que sempre que eu uso uma solução encolhida como Tomato/OpenWrt ou FreeNAS para uma compilação, eu normalmente fico frustrado sem poder realmente entrar lá e ajustar as coisas, então eu estarei usando uma distribuição Linux de propósito geral para o sistema operacional.

Como mencionei anteriormente, Armbian e Arch Linux ARM suportam a placa, e espressobin tem documentação oficial para o Ubuntu (assim como Yocto, com o qual eu não estava familiarizado até agora).Embora eu não lhe diga qual é o melhor para o seu caso de uso, aqui está porque eu preferi Arch Linux Arm:

• I’m totally sold on rolling release distributions.
• I’m also sold on running atop bleeding cuttingting-edge distros. No caso de um roteador, é bom estar perto do upstream quando atualizações potencialmente relacionadas à segurança são lançadas.
• Arch nos fornecerá uma tábua limpa para construir um topo sem nenhum serviço estranho. Isto significa que, com uma base mínima, podemos saber exatamente o que teremos instalado, exposto e rodando depois de juntar as peças.
• Eu conheço e gosto do pessoal do Arch Linux ARM. Olá WarheadsSE!

Firewall

Salguns nomes como PFSense vêm-me imediatamente à cabeça, mas eu gostaria muito de correr algo em Linux uma vez que o conheço muito melhor do que um BSD (mais, as melhores opções de SO para a espressobin são baseadas em Linux).

A paisagem de firewall do Linux é bastante ampla. Embora nós quase certamente usaremos algo baseado em iptables, há muitos serviços de nível superior que se situam no topo de iptables (ufw, firewalld, etc.).)Enquanto você poderia escrever seu próprio conjunto de regras simples e ir com ele, eu optei por usar um serviço de firewall já que isso nos compra um bom conhecimento tribal que a comunidade Linux tem fomentado ao longo dos muitos anos que eles têm gerenciado firewalls iptables.

Em geral, um bom daemon firewalling deve:

• Ajustar-se ao perfil do “projeto OSS saudável”. Isto significa que ele deve ser mantido ativamente, estar por perto por algum tempo e ter adoção decente.
• Evite a complexidade. Desenhos simples são mais fáceis de depurar, estender e operar.
• Apoiar algumas características agradáveis, tais como suporte para modelagem de tráfego e fácil configuração de encaminhamento de portas.

Após um pouco de poking, eu me instalei no Shorewall.Aqui estão algumas das razões mais notáveis que eu escolhi:

• O fluxo de configuração é compilar-e-aplicar. Isso garante que nosso conjunto de regras seja são antes de aplicá-lo, o que também significa que não há nenhum daemon residente consumindo os recursos do dispositivo, o que é relevante em um pequeno computador de placa única.
• Vem com muito conhecimento histórico incorporado, então as regras do iptables que são cuspidas lidam com muitas caixas de borda que você normalmente não pensaria.
• Cobrirei mais disso depois, mas a marcação de pacotes e o suporte nativo para moldagem de tráfego tornam os qdiscs de classe fácil.

Parte Três: The Basic Build

Este post não pretende ser um guia completo, mas eu queria incluir os pontos amplos para que fique aparente o quão fácil isto é montar.

OS Install

Este é fácil – basta seguir a página do Arch Linux Arm espressobin.É particularmente importante notar as bandeiras adicionadas no comando mkfs.ext4 e a configuração adicional do U-Boot.

OS Config

Geralmente, as instalações do Arch Linux Arm são muito bem definidas desde o get-go. É claro, você vai querer configurar um usuário não-root para administrar com essa não é a conta padrão, então lembre-se de desativar o usuário alarm, alterar todas as senhas e atualizar o sistema.

Como uma nota lateral, eu recomendo altamente instalar o pacote pacmatic e usá-lo no lugar do normal pacman.Ele detectará automaticamente as atualizações dos arquivos de configuração e ajudará a fundi-los, bem como notícias importantes em linha para quebrar alterações de pacotes.

Além disso, eu sugeriria configurar o etckeeper para rastrear sua configuração de firewall (o wiki Arch tem uma boa introdução).Eu configurei o meu para automaticamente empurrar para um repo gitolite hospedado privadamente.Para ser completamente honesto, eu não gosto de toda solução de gerenciamento de configuração por aí, e quase todas as nossas alterações estão limitadas a /etc, então esta é uma boa solução de backup para mim pelo menos.

Note que a configuração de rede padrão para o espressobin funciona bem para o caso de uso do roteador:

• As interfaces lan, lan0 e lan1, estão em ponte para a interface br0. Isto nos permite centralizar coisas de rede privada como o dnsmasq em uma única interface virtual.
• A interface de face pública é wan. Ela vai buscar seu endereço do provedor upstream via DHCP.

As únicas alterações necessárias para obter br0 e wan configuração para o nosso router são duas adições: primeiro, atribuir à interface LAN um IP estático uma vez que será o router, e permitir o reencaminhamento de IP e mascaramento de IP em /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

E confirme que a interface com interface WAN solicitará um endereço ao ISP em /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Eu configurei UseDNS=no aqui já que prefiro usar os servidores OpenNIC ao invés dos meus ISP’s upstream – Mencionarei onde configurá-los mais tarde.

Firewall

Os repositórios Arch Linux ARM aarch64 têm a última versão do Shorewall, que é o que eu usei. Minhas configurações não são tão extravagantes, e se você está seriamente considerando implantar o Shorewall com uma conexão com a internet selvagem, eu recomendo altamente a leitura de toda a introdução do Shorewall a um firewall de duas interfaces.Ele cobre o básico de como você deve configurar as coisas com um bom resumo de roteamento e firewall em geral.

Basicamente, você irá colocar a interface br0 e wan nas zonas certas e definir quaisquer regras necessárias em /etc/shorewall/rules.Lembre-se de deixar os hosts em sua LAN usar seu servidor DNS:

DNS(ACCEPT) loc $FW

Você confirmará que o DHCP é permitido na interface LAN no arquivo interfaces.

Noto aqui que eu acertei um bug com Shorewall durante a configuração do meu firewall que encontrei para ser corrigido literalmente no dia anterior – e o Arch Linux ARM já tinha o pacote atualizado nos repositórios upstream.

DHCP

dnsmasq é o ajuste perfeito para um roteador doméstico. Ele agrupa um servidor DNS e DHCP em um daemon leve que lida com tudo que você precisaria de uma rede pequena, e é maduro o suficiente para que haja muita documentação usando-o para aquele exato caso de uso.

Note: Eu tentei usar o servidor DHCP embutido do systemd que você pode configurar com DHCPServer= em .network arquivos, já que parecia ser uma maneira leve de rodar um servidor DHCP sem software extra. Sem ser muito palavroso, não vale a pena, uma razão significativa sendo que não há como encontrar locações de endereços atuais.

Existem muitas opções que devem ser definidas aqui, mas as mais importantes são:

# 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

Se você precisar de atribuições estáticas ou aliases, essas também são fáceis de adicionar.

Parte Quatro: Interlúdio

Com o expressobin servindo pedidos DHCP e DNS em br0, firewalling via Shorewall, e pacotes de roteamento entre a LAN e a WAN, é um roteador funcional. Neste ponto, conectar a porta WAN ao ISP upstream e as duas portas lan0/lan1 a dispositivos ou outro switch é tudo o que é necessário.

No entanto, isso é apenas um começo. Se realmente quisermos considerar isto como uma substituição de roteador, há algumas coisas genuinamente legais que podemos fazer para aumentar ainda mais as suas capacidades para que não se sinta como um downgrade de algo como o meu antigo Asus N66U.

Part Five: Upgrades

Fui aparafusado nos seguintes recursos ao meu roteador de baunilha espressobin, que cada um cobrirá por sua vez:

• Monitoramento do tráfego
• Formação do tráfego

Monitoramento do tráfego

Visibilidade do tráfego é algo que achei muito valioso com o meu firmware Asus Merlin para rastrear o uso.Netflow é o padrão de fato para este tipo de coisa, e entre todas as opções disponíveis, eu realmente gosto do ipt-netflow porque ele é um módulo de kernel nativo, então há muito pouco overhead e é muito ativamente mantido.

Acontece que eu sou provavelmente a primeira pessoa a usá-lo na arquitetura aarch64, porque eu tive alguma ajuda para obtê-lo suportado no chipset aarch64. O mantenedor do projeto foi (e tem sido) super responsivo a correções de bugs, então eu não tive nenhum problema em garantir que o módulo seja suportado nos últimos kernels que o projeto Arch Linux ARM roda em.

Utilizá-lo é uma questão de instalar o pacote ipt-netflow-dkms-git do AUR.Ele compilará para o seu kernel porque o dkms é incrível, e eu deixei cair o seguinte em /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Isso irá carregá-lo, e você configurá-lo em /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Onde $ip é o seu destino de netflow.Finalmente, o tráfego é capturado fluindo para um alvo iptables especial, o que pode ser feito diretamente do shorewall, convenientemente.Em /etc/shorewall/start:

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

>

Isso direciona todos os pacotes no roteador para primeiro entrar no alvo NETFLOW antes de qualquer outra coisa, que processa os pacotes e os passa de volta para fluir através das regras normais que o Shorewall configura.

Obviamente, ipt-netflow precisa de um lugar para onde enviar os logs de netflow, mas isso está fora do escopo deste post.No meu caso, eu tenho uma instância Logstash rodando na minha rede com o módulo netflow rodando e agregando eventos em um cluster Elasticsearch. Isso me dá alguns painéis convenientes e a capacidade de visualizar uma grande variedade de informações sobre a minha rede.Há alguns dashboards padrão:

Incluindo alguns bem legais, como um dashboard Geo-IP:

>

No entanto, a métrica mais relevante em que estou interessado é o meu uso total de largura de banda porque tenho um ISP antediluviano que se preocupa com os limites de dados.Felizmente isso é fácil com os dados de fluxo de rede que estou coletando: podemos simplesmente pedir ao Elasticsearch para somar alguns campos e obter essas métricas facilmente. O seguinte painel tem duas visualizações:

• O medidor compara a soma durante o período de tempo em questão com o limite que o meu ISP definiu para mim, assim eu posso facilmente ver onde está o meu uso atual contra o limite.
• As séries de tempos plota a largura de banda em bytes ao longo do tempo, a fim de ver quando estou usando essa largura de banda.

Algo particularmente legal sobre esta configuração é que, porque estamos armazenando as métricas de netflow no Elasticsearch ao invés de alguma outra base de dados de série temporal ou datastore, eu posso na verdade focar as consultas para estes dashboards a fim de fazer coisas como apenas a soma total de bytes para certas faixas CIDR porque o mecanismo de armazenamento subjacente (Lucene) entende os endereços IP nativamente.Por exemplo, a seguinte consulta em Kibana:

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

Filtrará eficazmente grandes quantidades de largura de banda que acontecem entre hosts na minha LAN, como o streaming entre o meu host Kodi e a máquina NAS.Cool.

Traffic Shaping

Isso se transformou em um empreendimento bastante massivo que foi uma fascinante toca de coelho para desaparecer.Alguns roteadores de estoque e a maioria dos roteadores personalizados oferecem alguma forma de QoS ou traffic shaping, então eu esperava fazer o mesmo no meu roteador personalizado para proteger parte do meu tráfego (como Overwatch) de altas latências.

O mundo da tecnologia QoS é um lugar fascinante.Enquanto você poderia confiar em alguns esquemas simples como um filtro HTB (hierarchical token bucket), os avanços na filtragem de pacotes são surpreendentemente ativos e há muitas abordagens interessantes.

O que eu eventualmente estabeleci foi um filtro HFSC (hierarchical fair-service curve).Vou ser honesto: a matemática por trás disso está tão fora do meu alcance que tive que ler vários resumos tentando quebrá-lo para pessoas normais, e a melhor explicação que fez sentido para mim foi um excelente resumo que eu encontrei no eqhmcow do usuário do GitHub que explica os benefícios e uso do HFSC na prática.

O tl;dr é o seguinte: com uma classe de controle de tráfego HFSC, você pode priorizar o tráfego e alcançar um bom equilíbrio entre fluxos que requerem alta largura de banda e baixas latências.Sem as regras em vigor, um download de Steam ou Blizzard Launcher matará os tempos de ping, enquanto as regras HFSC ativas cortarão graciosamente essas partes pesadas do tráfego para garantir que os fluxos interativos não sejam impactados. É realmente ótimo!Os seguintes arquivos de configuração são baseados nas minhas velocidades de banda medidas, que são cerca de 230 down e 10 up.

O primeiro passo é definir as classes relevantes tc para cada dispositivo no arquivo:tcdevices>

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

Aqui a interface LAN-facing br0 recebe gigabit completo, mas a interface WAN wan recebe 97% da sua velocidade down e 90% da minha velocidade up disponível.O raciocínio para estes números está explicado no essencial – estamos essencialmente recriando este conjunto de regras em termos de Shorewall.

Próximo, defina como as marcas de pacotes serão mapeadas para tc classes no arquivo 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

Isso irá deixar o tráfego importante/interativo em classes que recebem maior prioridade.Claro, também precisamos marcar os pacotes que devem ter essa prioridade mais alta, o que é feito em 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

Isso define as marcas de alta prioridade (1 e 2) que são tratadas pela nossa tc class.O exemplo inclui pings ICMP, ssh, alguns jogos da Blizzard e tráfego local.

Eu tenho alguns conjuntos de referências que mostram HFSC em acção, mas aqui está um pequeno exemplo: como as latências ping são afectadas quando o iperf é executado em segundo plano.

Como você pode ver, sem nenhuma regra de controle de tráfego em vigor, explosões de tráfego em massa podem ter impactos bastante negativos no tráfego interativo sensível a latências altas. Com HFSC, podemos evitar esses problemas.

Conclusão

Utilizo meu roteador home-brew há vários meses e parece funcionar muito bem.Eu não tive nenhuma queda de conexão misteriosa, problemas de velocidade ou problemas de hardware durante todo o período de operação contínua, então eu consideraria a construção um sucesso.As atualizações também são boas; depois de um normal sudo pacmatic -Syu e reiniciar o sistema volta online com todas as regras do iptables e outros serviços, como esperado, então manter-se atualizado com os últimos kernels e outros pacotes é simples.

Para resumir:

• Para uma pessoa com conhecimento de operações ou de espírito técnico, a construção de um roteador personalizado é muito fácil. Os computadores de placa única ARM tornam barato e conveniente para começar.
• Soluções ARM para firewalling, traffic shaping, e monitoramento de rede são maduros e fáceis de trabalhar. Em particular, soluções finamente envelhecidas como Shorewall e dnsmasq são muito bem documentadas e têm muitos anos de trabalho colocados em sua documentação e conjunto de recursos.
• Embora o roteamento + DNS + DHCP seja um slam dunk, o OSS WiFi pode ser atingido ou falhado. Sua milhagem pode variar, mas meu espressobin simplesmente não é um bom ponto de acesso.