Encaminador Banana Pi R64: Debian, Wireguard, RKN

El Banana Pi 64 és un ordinador d'una sola placa similar al Raspberry Pi, però amb diversos ports Ethernet, cosa que permet convertir-lo en un encaminador basat en una distribució de Linux de propòsit general.

Sí, ja hi ha Openwrt, però té els seus propis problemes, la seva GUI i la seva CLI; Hi ha Mikrotik, però de nou té la seva pròpia GUI/CLI, i Wireguard no funciona fora de la caixa... En general, vull un encaminador amb configuracions flexibles, tot romanent dins del marc del Linux estàndard, que vostè treballa. amb cada dia.

A l'article sota els noms BPI, R64, placa única, vull dir el mateix: la mateixa placa Banana Pi R64.

Selecció d'una imatge. Descarregar mitjançant eMMC

La primera habilitat que cal adquirir quan es treballa SBC en general, i amb l'R64 en particular, això vol dir aprendre a carregar-hi un sistema operatiu i poder-hi interactuar, perquè l'R64 no disposa de port per a monitor (HDMI, per exemple). Quan tot va caure: Wifi, Ethernet, Bluetooth, USB, etc. van deixar de funcionar. Hi ha un UART, a través de la interfície del qual sempre podeu veure què va fallar, i també executar un parell d'ordres des de la consola, si cal.

Algoritme per connectar-se a R64 mitjançant USB-UART:

• anem a la botiga de peces de ràdio per obtenir un cable USB-UART (PL2303, sèrie a USB)
• connecteu un extrem USB a l'ordinador i l'altre, UART, a l'R64, amb tres cables de quatre, com a la imatge següent
• executar a la consola de l'ordinador sudo minicom

Després d'això, en la majoria dels casos apareixerà la consola d'una sola placa = èxit.
Podeu veure més detalls aquí.

A continuació, la manera més senzilla és carregar el sistema operatiu des d'una targeta SD: descarregar per enllaç imatge i omple-la:

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

Introduïm la targeta a la ranura SD R64, l'encenem i observem la càrrega de la consola connectada primer uboot, després la càrrega estàndard de Linux.

Una opció d'arrencada alternativa és utilitzar una targeta de 64 Gb ja integrada a l'R8, anomenada eMMC. Segons les instruccions del wiki, copiem la imatge al dispositiu
/dev/mmcblk0 a BPI, reinicieu, traieu la targeta SD, torneu a activar BPI... i no funciona. Com anar i tornar Boot select no et molestis.

El fet és que almenys per a BPI cal establir una marca especial per poder arrencar des d'una unitat 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ó, heu d'escriure el precarregador en una partició d'arrencada especial

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

El fabricant R64 (Xina) ha publicat aquest binari aquí. El que fa és desconegut (no hi ha codis font), però tampoc funcionarà sense ell.

En general, després d'això, les imatges comencen a carregar-se des de l'eMMC. Si voleu esbrinar-ho i crear imatges des de zero, en ambdós casos (SD/eMMC) heu d'escriure diversos fitxers més (precarregador per a targeta SD, ATF, u-boot) només per carregar el nucli. Aquest tema encara està s'està desenvolupant, però per a nosaltres el més important és que funcioni i estigui bé.

Ara em descarrego mitjançant eMMC, per ser sincer, no la faig servir, amb una targeta SD n'hi ha prou, però he passat força temps fent-la funcionar, així que deixeu-ho a l'article.

Selecció d'un sistema operatiu. Armià

La primera tasca de l'aplicació és llançar una VPN, naturalment Wireguard. Immediatament es va descobrir que al costat del nucli no estava muntat i no hi havia capçaleres. Vaig reconstruir el nucli i, com és el meu costum amb x86, vaig muntar el mòdul del nucli mitjançant DKMS. No obstant això, la velocitat de construir fins i tot petites utilitats a arm64 em va sorprendre desagradablement. I llavors es necessitava un altre mòdul del nucli, etc. En general, resulta que tot allò relacionat amb el nucli es munta millor en un ordinador portàtil x86 càlid, després es transfereix a l'R64 mitjançant una còpia senzilla, es reinicia i es prova.

Una altra cosa és la part de l'espai d'usuari. En el meu cas d'escollir Debian, tot per a l'arquitectura arm64 ja està a packages.debian.org i no cal reconstruir res.

Per no produir una altra bicicleta, jo portat Armià a BPI R64.
O millor dit, això: la part de l'espai d'usuari és Armbian i el nucli s'ha pres del repositori Franco-A. La darrera imatge es pot descarregar aquí.

Es duu a terme tota l'activitat sobre el desenvolupament de la part de programari de R64 fòrum. En termes generals, el propi fabricant s'esforça per popularitzar l'encaminador per a Openwrt, però gràcies a l'activitat del desenvolupador Frank d'Alemanya, totes les funcions acaben ràpidament al nucli de Debian. Sorprenentment, Frank està actiu en tots els fils del fòrum.

Organització de l'espai de treball: cables

Per separat, m'agradaria explicar-vos com, durant el desenvolupament/prova, col·loqueu un SBC (no només un BPI) a una taula per no fer-hi passar un cable Ethernet des d'una font d'Internet a tota la sala/oficina. El fet és que, d'una banda, cal proporcionar Internet a un maquinari, però, de l'altra, tot el que hi ha en aquest maquinari es pot trencar, i primer de tot Wifi.

Primer, vaig decidir comprar un "xiulet" USB-Wifi barat, connectar-lo a l'únic port del BPI i oblidar-me dels cables. Per fer-ho, vaig comprar un TP-LINK TL-WN725N USB 2.0 de baix cost, però aviat va quedar clar que no s'enlairaria: perquè el xiulet funcioni, necessiteu un controlador del nucli, que, per descomptat, no hi havia. (més tard vaig muntar el controlador RTL8XXXU necessari, però encara no és pràctic). I el cable Ethernet va fer malbé l'aspecte de l'habitació durant una estona.

Com a resultat, vaig aconseguir desfer-me del cable amb l'ajuda de Tenda MW3 (sistema de malla Wifi): simplement vaig col·locar un cub sota la taula i vaig connectar el BPI al port LAN d'aquest últim amb un cable Ethernet d'un metre de llarg. Èxit.

Wireguard, RKN, Bird

Una de les coses per les quals vull utilitzar Banana PI és tenir accés gratuït als llocs bloquejats per RKN, en particular, perquè les trucades de Telegram i Slack puguin funcionar. Ja s'han proposat articles sobre Habré sobre aquest tema: temps, два, 03:00.

Vaig implementar exactament aquesta solució mitjançant Ansible: enllaç.

Se suposa que el VPS està executant Ubuntu 18.04. Vaig comprovar la funcionalitat de dos hosts a Europa: Amazon i Digital Ocean.

Per tant, vam instal·lar l'Armbian anterior a R64, s'hi pot accedir mitjançant ssh sota el nom hm-bananapi-1 i té accés a internet. Despleguem constantment Ansible, scripts d'automatització i iniciem la pròpia instal·lació a 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ó, heu de desplegar la nostra VPN al VPS de la mateixa manera:

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

Aquí l'argument sempre és current-vpn, i el nom real del VPS es configura en una variable (en aquest cas és 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, sí, abans de totes aquestes operacions cal generar secrets (en particular claus Wireguard) a la carpeta ./secrets, el directori hauria de semblar tan.

Ansible Automation en Python

És possible que noteu que en lloc d'estar en format YAML, les ordres Ansible estan codificades en scripts de Python. Per comparar, com activar el dimoni dels ocells de la manera habitual:

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

i com fer el mateix mitjançant Python:

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

Escriure ordres Ansible a Python us permet reutilitzar el codi i, en general, obre totes les possibilitats del llenguatge de propòsit general. Per exemple, instal·lant bird a R64 i VPS:

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

veure el codi de la funció install_bird().

Aquesta característica es diu pybook implementat aquí. Encara no hi ha documentació sobre pybook, però solucionaré aquest problema més tard.

Què pensa ell riu amunt en aquesta ocasió.

Seguiment. Prometeu

Total: telegram funciona, linkedin i pornhub també, en general l'experiència de l'usuari està bé. Però tot es pot trencar, inclòs el maquinari xinès.

Les actualitzacions del nucli també poden ser interessants: per exemple, volia actualitzar el nucli 5.4 => 5.6, bé, Wireguard és allà fora de la caixa, no cal aplicar pedaços... Tan aviat com ho he dit i fet: he transferit amb cura els pedaços de la 5.4. a 5.6, el nucli es va iniciar, el túnel al VPS va fer ping, però l'ocell no pot connectar-se amb l'error "Error BGP" ... "Vaig retrocedir amb horror" (c) a 5.4; El pas a 5.6 es va ajornar a TODO.

Per tant, a més d'instal·lar l'encaminador i el VPS, he afegit monitorització (a Ubuntu x86 18.04), que s'instal·la en un host independent amb els components següents:

• prometheus, alertmanager, blackbox_exporter - tot a Docker
• Les alertes s'envien al canal de telegram mitjançant el bot metalmatze/alertmanager-bot, també a Docker
• tor per al bot, de manera que el bot pugui alertar de situacions quan hi ha Internet, però Telegram encara no funciona i el bot en si no es pot connectar
• aplicat alertes: NodeVPNTroubles (sense ping a VPS), BirdVPNTroubles (sense sessió Bird), AntifilterDownloadTroubles (error en carregar adreces IP bloquejades), SiteTroubles (el telegrama desafortunat no està disponible)
• alertes del sistema, per exemple, HostGrowingDiskReadLatency (la targeta SD barata es torna il·legible)

Exemple d'instal·lació de monitoratge:

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

La descoberta automàtica per a Prometheus es configura a la carpeta /etc/prometheus/auto_http, un exemple d'afegir un amfitrió a la supervisió (els amfitrions no es supervisen per defecte):

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 proveïdors, 2 BPI, anycast failover

A més de tot, tenia previst connectar-me a dos proveïdors perquè Internet continués funcionant, encara que un proveïdor tingués problemes amb la xarxa, o s'oblidés de pagar per Internet, etc., i altres factors humans.

Es descriu l'experiència d'usuari més avançada sobre el tema multi-wan aquí per al sistema Mwan3 sota Openwrt. Aquesta solució té una funcionalitat rica, però configurar-la i operar-la en general per a multi-wan és bastant problemàtic. Només un exemple: si entres a alguns llocs des de dues adreces IP alhora, pot ser que no els agradi, deixaran de funcionar => "Internet no funciona".

Tenint en compte aquesta experiència, vaig decidir que el multihoming encara no és una prioritat, només la failover. Tot i que, sembla que a les últimes versions de Linux tot hauria de funcionar amb una ordre com:

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

Per tant, per evitar un únic punt de fallada, prenem 2 BPI, connectem cadascun a un proveïdor, els connectem entre ells i fem la connexió entre ells encaminament dinàmic mitjançant bird/OSPF.

A continuació, anunciem la mateixa adreça IP a cadascun si el servei està disponible (Internet, DNS). És a dir, no establirem la ruta per defecte nosaltres mateixos, sinó a través de l'ocell. Vaig espiar la solució aquí .

Aquesta funcionalitat encara no s'ha implementat, el coronavirus insidios va jugar una mala passada aquí (no tot va arribar d'Aliexpress; una altra botiga en línia, Layta, es va comprometre a lliurar en una setmana, però ha passat més d'un mes; el segon proveïdor no va tenir temps. per estendre el cable abans de la quarantena, només va aconseguir fer un forat a la paret per al cable).

Com demanar R64

El tauler en si es troba a la botiga oficial SinoVoip.
També és millor demanar immediatament:

• menjar + informa l'estàndard d'endoll de la UE o dels EUA
• dissipador de calor: radiadors/ventiladors; perquè tant la CPU com el xip del commutador s'escalfen
• antena wifi, per exemple

Hi ha un matís: el preu de lliurament s'ha tornat insuficientment alt a la botiga oficial durant un temps. La gerent Judy Huang em va convèncer que no hi havia cap error i que podríeu triar ePacket per 5 dòlars, però vaig veure que per a Rússia només hi ha EMS per > 33 dòlars. Desagradable, però no crític. A més, si trieu qualsevol altre país per al lliurament (he passat per tots els continents), el lliurament costarà ~ $5. Russòfobs?.. Però després vaig descobrir que per a França el preu de lliurament també és de ~30$ i em vaig calmar.

Com a resultat, Judy es va oferir a fer una comanda, però no pagar (pista: posar menys a la targeta perquè no passi el pagament automàtic); escriu-li i ella reduirà el preu del lliurament a la normalitat. Èxit.

Qüestions

Encara no tot funciona perfectament.

Productivitat

Ansible=Les ordres de Python s'executen lentament, fins i tot les inactives, durant 20-30 segons; un ordre de magnitud més llarg que en un ordinador portàtil x86. A més, al principi s'executen amb força rapidesa, ~ 3 segons, després s'alenteixen bruscament. Això pot ser degut a l'escalfament de la CPU (acceleració). El codi Go també triga molt a 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

El wifi funciona, però a Armbian s'atura al cap d'aproximadament un dia, escriu:

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
...

Només un reinici ajuda. Hem de seguir endavant resoldre.

Ethernet

Ethernet funciona, però després de ~64 hores els paquets (DHCP) de RXNUMX deixen d'arribar.
Reiniciar la interfície ajuda a:

ifdown br0; sleep 30; ifup br0

El controlador és nou, encara no s'ha acceptat al nucli, espero que sigui el xinès Landen Chao l'acaba.

Font: www.habr.com