🥇Router Banana Pi R64 - Debian, Wireguard, RKN

O Banana Pi 64 é un ordenador de placa única semellante ao Raspberry Pi, pero con varios portos Ethernet, o que permite convertelo nun enrutador baseado nunha distribución Linux de propósito xeral.

Si, xa existe Openwrt, pero ten os seus propios problemas, a súa GUI e a súa CLI; Hai Mikrotik, pero de novo ten a súa propia GUI/CLI, e Wireguard non funciona fóra da caixa... En xeral, quero un enrutador con configuracións flexibles, mantendo no marco do Linux estándar, que traballas. con cada día.

No artigo baixo os nomes BPI, R64, placa única, vou dicir o mesmo: a placa única Banana Pi R64.

Elixir unha imaxe. Descarga a través de eMMC

A primeira habilidade que debes adquirir cando traballas SBC en xeral, e co R64 en particular, isto supón aprender a cargar un sistema operativo nel e poder interactuar con el, porque o R64 non ten porto para monitor (HDMI, por exemplo). Cando todo caeu - deixaron de funcionar Wifi, Ethernet, Bluetooth, USB, etc.. Hai un UART, a través da cal sempre podes ver o que pasou mal, e tamén executar un par de comandos desde a consola, se é necesario.

Algoritmo para conectarse a R64 mediante USB-UART:

corremos á tenda de pezas de radio para buscar un cable USB-UART (PL2303, de serie a USB)
conecte un extremo USB ao ordenador e o outro, UART, ao R64, con tres cables de cada catro, como na imaxe de abaixo
executar na consola do ordenador sudo minicom

Despois disto, na maioría dos casos aparecerá a consola de placa única = éxito.
Podes ver máis detalles aquí.

A continuación, o xeito máis sinxelo é cargar o sistema operativo desde unha tarxeta SD: descargar por Ligazón imaxe e enchea:

unzip -p 2019-08-23-ubuntu-16.04-lite-preview-bpi-r64-sd-emmc.img.zip | pv | sudo dd of=/dev/mmcblk0 bs=10M status=noxfer

Introducimos a tarxeta na ranura SD R64, acendémola e observamos a consola conectada cargando primeiro uboot, despois cargando Linux estándar.

Unha opción de inicio alternativa é usar unha tarxeta de 64 Gb xa integrada no R8, chamada eMMC. Segundo as instrucións da wiki, copiamos a imaxe no dispositivo
/dev/mmcblk0 a BPI, reinicia, elimina a tarxeta SD, volve activar BPI... e non funciona. Como ir e vir Boot select non te molestes.

O feito é que polo menos para BPI necesitas establecer unha bandeira especial para poder iniciar desde unha unidade flash interna:

root@bpi-r64:~# ./mmc extcsd read /dev/mmcblk1 | grep 'PARTITION_CONFIG'
Boot configuration bytes [PARTITION_CONFIG: 0x00]
root@bpi-r64:~# ./mmc bootpart enable 1 1 /dev/mmcblk1
root@bpi-r64:~# ./mmc extcsd read /dev/mmcblk1 | grep 'PARTITION_CONFIG'
Boot configuration bytes [PARTITION_CONFIG: 0x48]

A continuación, cómpre escribir o precargador nunha partición de arranque especial

root@bpi-r64:~# echo 0 > /sys/block/mmcblk0boot0/force_ro 
root@bpi-r64:~# dd if=preloader_evb7622_64_foremmc.bin of=/dev/mmcblk0boot0

O fabricante R64 (China) publicou este binario aquí. O que fai é descoñecido (non hai códigos fonte), pero tampouco funcionará sen el.

En xeral, despois disto, as imaxes comezan a cargarse desde eMMC. Se queres descubrilo e crear imaxes desde cero, en ambos casos (SD/eMMC) tes que escribir varios ficheiros máis (precargador para tarxetas SD, ATF, u-boot) só para comezar a cargar o núcleo. Este tema aínda está desenvólvese, pero para nós o principal é que funcione e ben.

Agora descargo a través de eMMC, para ser sincero, non o uso, unha tarxeta SD é suficiente, pero pasei bastante tempo para que funcione, así que déixao estar no artigo.

Selección dun sistema operativo. Armbiano

A primeira tarefa da aplicación é lanzar unha VPN, naturalmente Wireguard. Inmediatamente descubriuse que no lado do núcleo non estaba montado e non había cabeceiras. Reconstruín o núcleo e, como é o meu costume con x86, montei o módulo do núcleo usando DKMS. Non obstante, a velocidade de construír incluso pequenas utilidades en arm64 sorprendeume desagradablemente. E entón foi necesario outro módulo do núcleo, etc. En xeral, resulta que todo o relacionado co núcleo ensambla mellor nun portátil x86 cálido, despois transfírese ao R64 mediante unha simple copia, reinicia e proba.

Outra cousa é a parte do espazo de usuario. No meu caso de escoller Debian, todo para a arquitectura arm64 xa está en packages.debian.org e non hai necesidade de reconstruír nada.

Para non producir outra bicicleta, eu portado Armbiano en BPI R64.
Ou mellor dito, isto: a parte do espazo de usuario é Armbian, e o núcleo tómase do repositorio Franco-A. Pódese descargar a última imaxe aquí.

Toda a actividade sobre o desenvolvemento da parte de software de R64 realízase en o foro. En xeral, o propio fabricante esfórzase en popularizar o enrutador para Openwrt, pero grazas á actividade do desenvolvedor Frank de Alemaña, todas as funcións acaban rapidamente no núcleo de Debian. Sorprendentemente, Frank está activo en todos os fíos do foro.

Organización do espazo de traballo: fíos

Por separado, gustaríame dicirche como, durante o desenvolvemento/proba, colocar un SBC (non só un BPI) nunha mesa para non executar un cable Ethernet desde unha fonte de Internet en toda a sala/oficina. O caso é que, por unha banda, cómpre proporcionar Internet a unha peza de hardware, pero, por outra banda, todo o que hai nesa peza de hardware pode avariar e, en primeiro lugar, a wifi.

En primeiro lugar, decidín mercar un "asubío" USB-Wifi barato, conécteo ao único porto do BPI e esquéceme dos cables. Para iso, comprei un TP-LINK TL-WN725N USB 2.0 barato, pero moi pronto quedou claro que non despegaría: para que o asubío funcione, necesitas un controlador do núcleo, que, por suposto, non estaba alí. (máis tarde montei o controlador RTL8XXXU necesario, pero aínda non é práctico). E o cable Ethernet estragou o aspecto da sala durante un tempo.

Como resultado, conseguín desfacerme do cable coa axuda de Tenda MW3 (sistema de malla wifi): simplemente coloquei un cubo debaixo da mesa e conectei o BPI ao porto LAN deste último cun cable Ethernet dun metro de lonxitude. Éxito.

Wireguard, RKN, Bird

Unha das cousas polas que quero usar Banana PI é ter acceso gratuíto aos sitios bloqueados por RKN, en particular, para que as chamadas de Telegram e Slack poidan funcionar. Xa se propuxeron artigos sobre Habré sobre este tema: tempo, два, tres.

Despleguei exactamente esta solución usando Ansible: Ligazón.

Suponse que o VPS está executando Ubuntu 18.04. Comprobei a funcionalidade en dous hospedadores en Europa: Amazon e Digital Ocean.

Entón, instalamos o Armbian anterior en R64, accesible a través de ssh baixo o nome hm-bananapi-1 e ten acceso a internet. Implementamos constantemente Ansible, scripts de automatización e lanzamos a propia instalación en R64:

# зависимости для Debian-based дистрибутивов
$ sudo apt install --no-install-recommends python3-pip python3-setuptools python3-wheel git
$ which pip3
/usr/bin/pip3

# ansible с pybook, скриптование на Python
$ pip3 install https://github.com/muravjov/ansible/archive/ansible-2.10.0.dev0-pybook2019.tar.gz

$ export PATH=~/.local/bin:$PATH
$ which ansible-playbook
/home/sa/.local/bin/ansible-playbook

$ git clone https://github.com/muravjov/ansible-bpi-r64.git
$ cd ansible-bpi-r64

$ git submodule update --init

# убеждаемся в доступности hm-bananapi-1
$ ssh hm-bananapi-1 which python3
/usr/bin/python3

# собственно установка
$ ansible-playbook ./router.py -l hm-bananapi-1

A continuación, debes implementar a nosa VPN no VPS do mesmo xeito:

ansible-playbook ./router.py -l current-vpn

Aquí o argumento é sempre actual-vpn e o nome real do VPS está configurado nunha variable (neste caso é paris-vpn-aws-t2-micro-1):

$ grep current_vpn group_vars/all 
current_vpn: paris-vpn-aws-t2-micro-1
#current_vpn: frankfurt-vpn-d0-starter-1

Ah, si, antes de todas estas operacións cómpre xerar segredos (en particular claves Wireguard) no cartafol ./secrets, o directorio debería parecer así.

Ansible Automation en Python

Podes notar que, en lugar de estar en formato YAML, os comandos de Ansible están codificados en scripts de Python. A modo de comparación, como activar o daemon paxaro do xeito habitual:

- name: start bird
  systemd:
    name: bird
    state: started
    enabled: yes

e como facer o mesmo a través de Python:

with mapping:
    append("name", "start bird")
    with mapping("systemd"):
        append("name",  "bird")
        append("state", "started")
        append("enabled", "yes")

Escribir comandos de Ansible en Python permíteche reutilizar o código e, en xeral, abre todas as posibilidades da linguaxe de propósito xeral. Por exemplo, instalando Bird en R64 e VPS:

install_bird("router/bird.conf.j2")
install_bird("vpn/bird.conf.j2")

ver o código da función install_bird().

Esta función chamada pybook implementado aquí. Aínda non hai documentación sobre pybook, pero solucionarei este problema máis tarde.

Que pensa augas arriba nesta ocasión.

Seguimento. Prometeo

Total: telegram funciona, linkedin e pornhub tamén, en xeral a experiencia do usuario está ben. Pero todo pode romper, incluído o hardware chinés.

As actualizacións do kernel tamén poden ser interesantes: por exemplo, quería actualizar o kernel 5.4 => 5.6, ben, Wireguard está aí fóra da caixa, non hai necesidade de parchear... Nada máis dicir que feito: transferín coidadosamente os parches da 5.4 a 5.6, o núcleo iniciouse, o túnel para o VPS fixo ping, pero Bird non pode conectarse co erro "Erro BGP" ... "Retrocei con horror" (c) a 5.4; O paso a 5.6 aprazouse en TODO.

Polo tanto, ademais de instalar o enrutador e o VPS, engadín a supervisión (en Ubuntu x86 18.04), que está instalado nun host separado cos seguintes compoñentes:

prometheus, alertmanager, blackbox_exporter - todo en docker
As alertas envíanse á canle de telegram usando o bot metalmatze/alertmanager-bot, tamén en Docker
tor para o bot, para que o bot poida alertar de situacións cando hai Internet, pero Telegram aínda non funciona e o propio bot non pode conectarse
aplicado alertas: NodeVPNTroubles (sen ping a VPS), BirdVPNTroubles (sen sesión Bird), AntifilterDownloadTroubles (erro ao cargar os enderezos IP bloqueados), SiteTroubles (un telegrama desafortunado non está dispoñible)
alertas do sistema, por exemplo, HostGrowingDiskReadLatency (a tarxeta SD barata faise ilegible)

Exemplo de instalación de monitorización:

ansible-playbook ./monitoring.py -l monitoring-preprod

Auto Discovery for Prometheus está configurado no cartafol /etc/prometheus/auto_http, un exemplo de engadir un host á supervisión (os hosts non se supervisan por defecto):

bash << 'EOF'
HOSTNAME=hm-bananapi-1
IP_ADDRESS=`ssh -G $HOSTNAME | awk '/^hostname / { print $2 }'`

ssh monitoring-preprod sudo sponge /etc/prometheus/auto_http/$HOSTNAME.json << EOF2
[
  {
    "targets": ["$IP_ADDRESS:9100"],
    "labels": {
      "env": "prod",
      "hostname": "$HOSTNAME"
    }
  }
]
EOF2
EOF

TODO: 2 provedores, 2 BPI, conmutación por error anycast

Ademais de todo, planeaba conectarme a dous provedores para que Internet seguise funcionando, aínda que un provedor tivese problemas coa rede, ou se esquecera de pagar a Internet, etc., e outros factores humanos.

Descríbese a experiencia de usuario máis avanzada sobre o tema do multi-wan aquí para o sistema Mwan3 baixo Openwrt. Esta solución ten unha funcionalidade rica, pero configurala e operala en xeral para multi-wan é bastante problemática. Só un exemplo: se chegas a algúns sitios desde dous enderezos IP á vez, quizais non lles guste, deixarán de funcionar => "Internet non funciona".

Tendo en conta esta experiencia, decidín que o multihoming aínda non é unha prioridade, só o failover. Aínda que, parece que nas últimas versións de Linux todo debería funcionar cun comando como:

ip route add default 
    nexthop via 192.168.1.1 weight 10 
    nexthop via 192.168.2.1 weight 5

Entón, para evitar un único punto de falla, tomamos 2 BPI, conectamos cada un a un provedor, conectámolos entre si e realizamos a conexión entre eles enrutamento dinámico a través de bird/OSPF.

A continuación, anunciamos o mesmo enderezo IP en cada un se o servizo está dispoñible (Internet, DNS). É dicir, non estableceremos a ruta predeterminada nós, senón a través do paxaro. espiei a solución aquí .

Esta funcionalidade aínda non foi implementada, o insidioso coronavirus xogou aquí unha mala pasada (non todo chegou de Aliexpress; outra tenda en liña, Layta, prometeu entregar nunha semana, pero pasou máis dun mes; o segundo provedor non tivo tempo). para estender o cable antes da corentena, só conseguiu facer un burato na parede para o cable).

Como pedir R64

O taboleiro en si está na tenda oficial SinoVoip.
Tamén é mellor pedir inmediatamente:

comida + informar sobre o estándar de enchufe da UE ou dos EUA
disipador de calor: radiadores/ventiladores; porque tanto a CPU como o chip do interruptor estanse quentando
antena wifi, por exemplo

Hai un matiz: o prezo de entrega fíxose inadecuadamente alto na tenda oficial durante algún tempo. A xerente Judy Huang convenceume de que non había ningún erro e que podías escoller ePacket por $5, pero vin que para Rusia só hai EMS por > $33. Desagradable, pero non crítico. Ademais, se escolles outro país para a entrega (pasei por todos os continentes), a entrega custará ~$5. ¿Rusófobos?... Pero entón descubrín que para Francia o prezo da entrega tamén é de ~30 $ e calmeime.

Como resultado, Judy ofreceuse a facer un pedido, pero non pagar (suxerir: poñer menos na tarxeta para que non pase o pago automático); escríbelle e ela reducirá o prezo da entrega á normalidade. Éxito.

Cuestións

Aínda non todo funciona perfectamente.

Produtividade

Ansible=Os comandos de Python execútanse lentamente, incluso os inactivos, durante 20-30 segundos; unha orde de magnitude máis longa que nun portátil x86. Ademais, ao principio execútanse con bastante rapidez, ~ 3 segundos, despois diminúen bruscamente. Isto pode deberse ao quecemento da CPU (aceleración). O código Go tamén leva moito tempo en funcionar:

# запрос метрик для прометея из node_exporter на Go
$ time curl -s http://172.30.1.1:9100/metrics > /dev/null

real    0m6,118s
user    0m0,005s
sys     0m0,009s

# однако температура 51 градус, не так и много
sa@bananapir64:~$ cat /sys/devices/virtual/thermal/thermal_zone0/temp
51700

Wifi

A wifi funciona, pero en Armbian detense despois dun día aproximadamente, escribe:

sa@bananapir64:~$ dmesg | grep -E 'mt7622_wmac.*timeout'
[470303.802539] mt7622_wmac 18000000.wmac: Message 38 (seq 3) timeout
[470314.042508] mt7622_wmac 18000000.wmac: Message 50 (seq 4) timeout
...

Só un reinicio axuda. Temos que seguir adiante ordenar.

Ethernet

Ethernet funciona, pero despois de ~64 horas os paquetes (DHCP) de RXNUMX deixan de chegar.
Reiniciar a interface axuda a:

ifdown br0; sleep 30; ifup br0

O controlador é novo, aínda non foi aceptado no núcleo, espero que sexa o chinés Landen Chao remata-lo.

Fonte: www.habr.com

Router Banana Pi R64: Debian, Wireguard, RKN