🥇Router Banana Pi R64 — Debian, Wireguard, Roskomnadzor

Banana Pi 64 è un computer a scheda unica simile al Raspberry Pi, ma con diverse porte Ethernet, il che consente di trasformarlo in un router basato su una distribuzione Linux di uso generale.

Sì, esiste già OpenWrt, ma ha le sue complicazioni con il proprio GUI e CLI; c'è Mikrotik, ma anche quello ha il suo GUI/CLI e WireGuard non funziona di default... In generale, si desidera un router con impostazioni flessibili, rimanendo nell'ambito di un Linux standard, con cui si lavora ogni giorno.

Nell'articolo, con i termini BPI, R64, e scheda unica intenderò sempre lo stesso — il computer a scheda unica Banana Pi R64.

Scelta dell'immagine. Avvio da eMMC

La prima abilità che bisogna acquisire lavorando con SBC generalmente, e con R64 in particolare, è imparare a caricare un sistema operativo e avere la possibilità di interagire con esso, poiché l'R64 non ha una porta per il monitor (come HDMI, ad esempio). Quando tutto va male — smette di funzionare WiFi, Ethernet, Bluetooth, USB e altro, è disponibile UART, attraverso il quale è sempre possibile controllare cosa non va e, se necessario, eseguire alcuni comandi dalla console.

Algoritmo per connettersi a R64 tramite USB-UART:

corriamo al negozio di componenti elettronici per un cavo USB-UART (PL2303, Serial-to-USB)
colleghiamo una estremità USB al computer e l'altra, UART, al R64, con tre fili su quattro, come nell'immagine sottostante
nella console del computer avviamo sudo minicom

Dopo questo, nella maggior parte dei casi apparirà la console della scheda madre = successo.
Puoi guardare di più qui.

Successivamente, il modo più semplice è caricare il sistema operativo dalla scheda SD: scarichiamo il link file immagine e lo carichiamo:

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

inseriamo la scheda nello slot SD del R64, accendiamo, osserviamo attraverso la console collegata il caricamento prima di uboot, poi il caricamento standard di Linux.

Un'opzione alternativa di avvio è attraverso la scheda eMMC da 8Gb già installata nel R64. Seguendo le istruzioni nel wiki, scriviamo l'immagine sul dispositivo
/dev/mmcblk0 в BPI, перегружаемся, вытаскиваем SD-карту, включаем BPI снова… и не работает. Как туда-сюда Boot select Non tirare.

Il fatto è che, almeno per BPI, è necessario impostare un flag speciale per poter avviarsi dalla 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]

Successivamente, nel bootloader speciale bisogna registrare il preloader

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

Il produttore R64 (Cina) ha rilasciato questo binario qui. Non si sa cosa faccia (non ci sono sorgenti), ma senza di esso non funzionerà.

In effetti, dopo questo, le immagini iniziano a caricarsi anche da eMMC. Se si desidera approfondire e creare immagini da zero, per entrambi i casi (SD/eMMC) è necessario scrivere ulteriori file (preloader per schede SD, ATF, u-boot), solo per arrivare al caricamento del kernel. Questo tema è ancora si sviluppa, ma per noi è importante che funzioni, ed è sufficiente.

Attualmente non utilizzo il caricamento tramite eMMC, a dire il vero, le schede SD sono più che sufficienti, ma ho speso abbastanza tempo per farlo funzionare, quindi lo includerò nell'articolo.

Scelta del sistema operativo. Armbian

Il primo compito pratico è stato avviare un VPN, naturalmente Wireguard. È subito emerso che dal lato del kernel non era compilato e mancavano gli header. Ho ricompilato il kernel e, abituato all'x86, ho creato il modulo del kernel utilizzando DKMS. Tuttavia, la velocità di compilazione su arm64, anche per piccole utilità, mi ha sconcertato. E poi è stato necessario un altro modulo del kernel, e così via. Insomma, sembra che tutto ciò che riguarda il kernel sia meglio compilarlo su un caldo e accogliente laptop x86, poi trasferirlo semplicemente su R64, riavviarlo e testarlo.

Un altro discorso è la parte userspace. Nel mio caso, scegliendo Debian, tutto per l'architettura arm64 è già disponibile su packages.debian.org e non c'è bisogno di ricompilare nulla.

Per non generare un'altra bicicletta, io portato Armbian su BPI R64.
In altre parole: la parte userspace è Armbian, mentre il kernel viene preso dal repository di Frank-a. L'immagine più recente può essere scaricata qui.

Tutta l'attività relativa allo sviluppo della parte software di R64 è condotta su forum. In generale, il produttore stesso cerca di popolarizzare il router per OpenWrt, ma grazie all'impegno dello sviluppatore Frank dalla Germania, tutte le funzionalità vengono rapidamente integrate nel kernel per Debian. È sorprendente, ma Frank è attivo in ogni thread del forum.

Organizzazione dello spazio di lavoro: cavi

Voglio parlare di come posizionare un SBC (non solo BPI) sulla scrivania durante lo sviluppo/testing, in modo da non dover portare il cavo Ethernet da una fonte Internet attraverso tutta la stanza/ufficio. Infatti, da un lato bisogna garantire che il dispositivo abbia accesso a Internet, ma dall'altro lato questo stesso dispositivo potrebbe avere problemi, in particolare con il Wifi.

All'inizio ho deciso di acquistare un economico dongle USB Wifi, collegarlo all'unico porto disponibile sul BPI e dimenticare i fili. Per questo ho comprato il TP-LINK TL-WN725N USB 2.0 a basso costo, ma ben presto è diventato chiaro che non funzionava: il dongle necessitava di un driver del kernel, che naturalmente non era presente (in seguito ho ricompilato il driver necessario RTL8XXXU, ma rimaneva comunque poco pratico). Inoltre, il cavo Ethernet rovinava l'aspetto della stanza per un certo tempo.

Alla fine sono riuscito a liberarmi del cavo grazie al Tenda MW3 (sistema Wifi mesh): ho posizionato un cubo sotto il tavolo e ho collegato il BPI alla porta LAN dell'ultimo utilizzando un cavo Ethernet di un metro. Successo.

Wireguard, RKN, Bird

Uno dei motivi per cui utilizzo Banana PI è per avere accesso libero a siti bloccati dal governo russo, in particolare per utilizzare Telegram e fare chiamate su Slack. A questo proposito, sono già stati pubblicati articoli su Habr: una volta, due volte, tre volte.

Ho implementato esattamente questa soluzione utilizzando Ansible: link.

Si presume che VPS stia funzionando su Ubuntu 18.04. Ho verificato il funzionamento su due provider in Europa: Amazon e Digital Ocean.

Quindi, abbiamo installato l'Armbian sopra menzionato su R64, che è accessibile via ssh con il nome hm-bananapi-1 ed è connesso a Internet. Procediamo a distribuire sequenzialmente ansible, gli script di automazione e avviamo l'installazione proprio su 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

Dopodiché, è necessario distribuire in modo simile il nostro VPN su VPS:

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

Qui l'argomento è sempre current-vpn, mentre il nome del VPS è configurato nella variabile (in questo 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, prima di tutte queste operazioni è necessario generare i segreti (in particolare le chiavi Wireguard) nella cartella ./secrets, la directory dovrebbe apparire così.

Automazione Ansible su Python

Si può notare che invece del formato YAML, i comandi Ansible sono codificati in script Python. Per confronto, ecco come avviare il demone bird in modo tradizionale:

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

e come fare la stessa cosa attraverso Python:

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

Scrivere comandi Ansible in codice Python consente il riutilizzo del codice e apre tutte le possibilità di un linguaggio di programmazione generale. Ad esempio, l'installazione di bird su R64 e VPS:

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

vedere il codice della funzione install_bird().

Questa funzionalità chiamata pybook è stata realizzata qui. Al momento non c'è documentazione su pybook, provvederò a correggere questa mancanza.

Cosa ne pensa upstream a proposito.

Monitoraggio. Prometheus

In sintesi: telegram funziona, linkedin e pornhub anche, in generale l'esperienza dell'utente è buona. Ma tutto potrebbe rompersi, e anche l'hardware cinese.

Gli aggiornamenti del kernel possono essere interessanti: ad esempio, volevo aggiornare il kernel da 5.4 a 5.6, e lì c'è Wireguard preinstallato, non serve patchare… Detto fatto: ho faticosamente trasferito le patch da 5.4 a 5.6, il kernel si è avviato, il tunnel verso il VPS risponde al ping, ma bird non riesce a connettersi con l'errore "BGP Error"… "Inorridito, sono tornato indietro" (c) a 5.4; ho rimandato il passaggio a 5.6 nel TODO.

Perciò, oltre all'installazione del router e del VPS, ho aggiunto il monitoraggio (su x86 Ubuntu 18.04), che viene installato su un host separato con i seguenti componenti:

prometheus, alertmanager, blackbox_exporter — tutto in Docker
Gli avvisi vengono inviati a un canale Telegram tramite il bot metalmatze/alertmanager-bot — anch'esso in Docker
tor per il bot, affinché il bot possa segnalare situazioni in cui c'è internet, ma Telegram non funziona e il bot stesso non riesce a connettersi
avvisi applicativi avvisi: NodeVPNTroubles (nessun ping verso il VPS), BirdVPNTroubles (nessuna sessione Bird), AntifilterDownloadTroubles (errore nel download di indirizzi IP bloccati), SiteTroubles (Telegram maledetto non disponibile)
avvisi di sistema, ad esempio, HostGrowingDiskReadLatency (la scheda SD economica smette di funzionare)

Esempio di installazione del monitoraggio:

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

La funzione di Auto Discovery per Prometeus è configurata per la cartella /etc/prometheus/auto_http. Ecco un esempio di aggiunta di un host al monitoraggio (per impostazione predefinita, gli host non sono monitorati):

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 provider, 2 BPI, failover anycast

In aggiunta a tutto ciò, ho programmato di collegarmi a due provider per garantire la continuità di internet, anche in caso di problemi di rete con uno dei provider o se dimenticano di pagare per il servizio, ecc., e per altri fattori umani.

L'esperienza utente più avanzata in merito al multi-wan è descritta qui per il sistema Mwan3 su OpenWRT. Questa soluzione offre funzionalità ricche, ma la configurazione e l'operatività per il multi-wan possono risultare piuttosto complesse. Un esempio: se ci si collega a determinati siti da due indirizzi IP contemporaneamente, essi potrebbero non gradirlo e smettere di funzionare => "internet non funziona".

Considerando questa esperienza, ho deciso che il multihoming non è ancora una priorità, solo il failover. Anche se, sembra che nelle ultime versioni di Linux tutto dovrebbe funzionare con un solo comando del tipo:

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

Per evitare un singolo punto di fallimento, utilizziamo 2 BPI, collegandoli a diversi provider, e creando una connessione tra di loro mediante il routing dinamico attraverso bird/OSPF.

Successivamente, annunciamo lo stesso indirizzo IP su ciascuno di essi quando il servizio è disponibile (internet, DNS). Quindi non impostiamo il percorso predefinito manualmente, ma tramite bird. Ho visto questa soluzione. qui .

Questa funzionalità non è ancora stata implementata, il subdolo coronavirus ha complicato le cose (non tutto è arrivato da AliExpress; un altro negozio online, Layta, aveva promesso la consegna in una settimana, ma sono già passati più di un mese; il secondo provider non è riuscito a stendere il cavo prima della quarantena, ha solo forato un buco nel muro per il cavo).

Come ordinare R64

La scheda nel negozio ufficiale SinoVoip.
È meglio ordinare anche:

alimentazione + comunicare lo standard della spina EU o USA
dissipazione del calore: radiatori/ventole; perché sia la CPU che il chip dello switch si scaldano
un'antenna per il wifi, ad esempio

C'è un problema: il costo della spedizione è diventato inadeguatamente alto nel negozio ufficiale. La responsabile Judy Huang mi ha assicurato che non ci sono errori e che posso scegliere ePacket per 5$, ma ho visto che per la Russia c'è solo EMS a più di 33$. È sgradevole, ma non critico. Inoltre, se scelgo qualsiasi altro paese per la spedizione (ho provato tutti i continenti), il costo è di circa 5$. Russofobi?.. Ma poi ho scoperto che anche per la Francia il costo della spedizione è di circa 30$, e mi sono tranquillizzato.

Alla fine Judy ha proposto di effettuare l'ordine, ma di non pagare (hint: caricare meno sulla carta in modo che il pagamento non venga elaborato automaticamente); scrivermi e ridurrà il costo della spedizione a un valore normale. Successo.

Problemi

Non tutto funziona ancora perfettamente.

Prestazioni

I comandi Ansible=Python vengono eseguiti lentamente, anche quelli vuoti, impiegando 20-30 secondi; molto più a lungo rispetto al laptop x86. Inizialmente, vengono eseguiti abbastanza rapidamente, circa 3 secondi, poi rallentano drasticamente. Potrebbe essere a causa del surriscaldamento della CPU (throttling). Il codice Go funziona anche lentamente:

# запрос метрик для прометея из 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

Il Wifi funziona, ma su Armbian smette di funzionare dopo circa un giorno, scrivendo:

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

Solo un riavvio aiuta. Dobbiamo continuare a indagare.