ProHoster > Blog > administration > Banana Pi R64-router – Debian, Wireguard, RKN

Banana Pi R64-router – Debian, Wireguard, RKN

Banana Pi 64 er en singleboard-computer, der ligner Raspberry Pi, men med flere Ethernet-porte, som gør det muligt at lave den om til en router baseret på en generel Linux-distribution.

Banana Pi R64-router – Debian, Wireguard, RKN

Ja, der er allerede Openwrt, men det har sine egne problemer, dets GUI og CLI; Der er Mikrotik, men igen har den sin egen GUI/CLI, og Wireguard fungerer ikke ud af boksen... Generelt vil jeg gerne have en router med fleksible indstillinger, samtidig med at den forbliver inden for rammerne af standard Linux, som du arbejder med med hver dag.

I artiklen under navnene BPI, R64, single-board vil jeg mene det samme – selve Banana Pi R64 single-boardet.

Valg af billede. Download via eMMC

Den allerførste færdighed, du skal tilegne dig, når du arbejder med SBC generelt, og med R64 i særdeleshed, betyder det, at man lærer, hvordan man indlæser et styresystem i det og kan interagere med det, fordi R64 ikke har en port til en skærm (HDMI, for eksempel). Da alt faldt af - stoppede Wifi, Ethernet, Bluetooth, USB osv. med at virke. Der er en UART, gennem hvis grænseflade du altid kan se, hvad der gik galt, og også køre et par kommandoer fra konsollen, hvis det er nødvendigt.

Algoritme for tilslutning til R64 via USB-UART:

  • vi løber til butikken for radiodele efter et USB-UART-kabel (PL2303, seriel-til-USB)
  • tilslut den ene USB-ende til computeren, og den anden, UART, til R64, med tre ledninger ud af fire, som på billedet nedenfor
  • køre i computerkonsollen sudo minicom

Herefter vil singleboard-konsollen i de fleste tilfælde vises = succes.
Du kan se flere detaljer her.

Banana Pi R64-router – Debian, Wireguard, RKN

Dernæst er den nemmeste måde at indlæse operativsystemet fra et SD-kort: download af link billede og udfyld det:

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

Vi indsætter kortet i R64 SD-slottet, tænder det og observerer, at den tilsluttede konsol indlæses først ved uboot og derefter standard Linux-indlæsning.

En alternativ opstartsmulighed er at bruge et 64Gb-kort, der allerede er indbygget i R8, kaldet eMMC. I henhold til instruktionerne i wikien kopierer vi billedet til enheden
/dev/mmcblk0 til BPI, genstart, fjern SD-kortet, tænd BPI igen... og det virker ikke. Hvordan man går frem og tilbage Boot select gider ikke.

Faktum er, at i det mindste for BPI skal du indstille et specielt flag for at kunne starte fra et internt flashdrev:

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]

Dernæst skal du skrive preloader ind i en speciel boot-partition

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

Producenten R64 (Kina) postede denne binære her. Hvad det gør er ukendt (der er ingen kildekoder), men det vil heller ikke fungere uden det.

Generelt efter dette begynder billederne at indlæse fra eMMC. Hvis du vil finde ud af det og lave billeder fra bunden, så skal du i begge tilfælde (SD/eMMC) skrive flere filer (preloader til SD-kort, ATF, u-boot) bare for at komme til at indlæse kernen. Dette emne er stadig udvikler sig, men for os er det vigtigste, at det virker og okay.

Nu downloader jeg via eMMC, for at være ærlig, jeg bruger det ikke, et SD-kort er nok, men jeg brugte ret meget tid på at få det til at virke, så lad det være i artiklen.

Valg af operativsystem. Armbian

Den første applikationsopgave er at lancere en VPN, naturligvis Wireguard. Det blev straks opdaget, at på kernesiden var det ikke samlet, og der var ingen headere. Jeg genopbyggede kernen og, som det er min vane med x86, samlede jeg kernemodulet ved hjælp af DKMS. Men hastigheden på at bygge selv små hjælpeprogrammer på arm64 overraskede mig ubehageligt. Og så skulle der et andet kernemodul til osv. Generelt viser det sig, at alt relateret til kernen bedst samles på en varm x86 bærbar, derefter overføres til R64 ved simpel kopiering, genstart og testet.

En anden ting er brugerpladsdelen. I mit tilfælde med at vælge Debian, er alt til arm64-arkitekturen allerede på packages.debian.org, og der er ingen grund til at genopbygge noget.

For ikke at producere endnu en cykel, har jeg porteret armbian på BPI R64.
Eller rettere sagt dette: brugerrumsdelen er Armbian, og kernen er taget fra lageret Åben-EN. Det seneste billede kan downloades her.

Al aktivitet omkring udvikling af softwaredelen af ​​R64 udføres på forum. Generelt stræber producenten selv efter at popularisere routeren til Openwrt, men takket være aktiviteten fra udvikleren Frank fra Tyskland ender alle funktionerne hurtigt i kernen til Debian. Overraskende nok er Frank aktiv i alle forumtråde.

Arbejdspladsorganisation: ledninger

Separat vil jeg gerne fortælle dig, hvordan du under udvikling/testning placerer en SBC (ikke kun en BPI) på et bord for ikke at køre et Ethernet-kabel til den fra en internetkilde på tværs af hele lokalet/kontoret. Faktum er, at du på den ene side skal forsyne et stykke hardware med internet, men på den anden side kan alt i det stykke hardware gå i stykker, og først og fremmest Wifi.

Først besluttede jeg at købe en billig USB-Wifi "fløjte", tilslutte den til den eneste port på BPI'en og glemme alt om ledningerne. For at gøre dette købte jeg en billig TP-LINK TL-WN725N USB 2.0, men meget hurtigt blev det klart, at det ikke ville tage fart: for at fløjten skal virke, har du brug for en kernedriver, som selvfølgelig ikke var der (senere samlede jeg den nødvendige RTL8XXXU-driver, men den er stadig upraktisk). Og Ethernet-kablet spolerede rummets udseende i et stykke tid.

Som følge heraf lykkedes det mig at komme af med kablet ved hjælp af Tenda MW3 (Wifi mesh-system): Jeg placerede simpelthen en terning under bordet og tilsluttede BPI'en til sidstnævntes LAN-port med et meterlangt Ethernet-kabel. Succes.

Wireguard, RKN, Bird

En af de ting, jeg vil bruge Banana PI til, er at have fri adgang til især sider, der er blokeret af RKN, så Telegram og Slack-opkald kan fungere. Artikler om Habré er allerede blevet foreslået om dette emne: tid, два, tre.

Jeg implementerede præcis denne løsning ved hjælp af Ansible: link.

VPS'en antages at køre Ubuntu 18.04. Jeg tjekkede funktionaliteten på to hostere i Europa: Amazon og Digital Ocean.

Så vi installerede ovenstående Armbian på R64, den er tilgængelig via ssh under navnet hm-bananapi-1 og har internetadgang. Vi implementerer konsekvent Ansible, automatiseringsscripts og starter selve installationen på 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

Dernæst skal du implementere vores VPN til VPS'en på samme måde:

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

Her er argumentet altid current-vpn, og det faktiske VPS-navn er konfigureret i en variabel (i dette tilfælde er det 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

Åh ja, før alle disse operationer skal du generere hemmeligheder (især Wireguard-nøgler) i mappen ./secrets, skal mappen se ud så.

Ansible Automation i Python

Du bemærker måske, at i stedet for at være i YAML-format, er Ansible-kommandoerne kodet i Python-scripts. Til sammenligning, hvordan du aktiverer fugledæmonen på den sædvanlige måde:

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

og hvordan man gør det samme via Python:

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

At skrive Ansible-kommandoer i Python giver dig mulighed for at genbruge koden, og det åbner generelt op for alle mulighederne for det generelle sprog. For eksempel installation af bird på R64 og VPS:

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

se funktionskoden install_bird().

Denne funktion kaldes pybook implementeret her. Der er endnu ingen dokumentation om pybook, men jeg løser dette problem senere.

Hvad tænker han opstrøms i denne anledning.

Overvågning. Prometheus

I alt: telegram virker, linkedin og pornhub også, generelt er brugeroplevelsen ok. Men alt kan gå i stykker, inklusive kinesisk hardware.

Kernelopdateringer kan også være interessante: for eksempel, jeg ønskede at opdatere kerne 5.4 => 5.6, ja, Wireguard er der ude af boksen, ingen grund til at patche... Ikke før sagt end gjort: Jeg overførte møjsommeligt patcherne fra 5.4 til 5.6, kernen startede, tunnelen til VPS'en pingede, men fuglen kan ikke forbinde med fejlen "BGP Error" ... "Jeg rullede tilbage i rædsel" (c) til 5.4; Flytningen til 5.6 blev udskudt i TODO.

Derfor tilføjede jeg, udover at installere routeren og VPS, overvågning (på x86 Ubuntu 18.04), som er installeret på en separat vært med følgende komponenter:

  • prometheus, alertmanager, blackbox_exporter - alt i docker
  • Advarsler sendes til telegramkanalen ved hjælp af metalmatze/alertmanager-bot bot - også i Docker
  • tor for botten, så botten kan advare situationer, når der er internet, men Telegram virker stadig ikke, og botten kan ikke selv oprette forbindelse
  • anvendt alarmer: NodeVPNTroubles (ingen ping til VPS), BirdVPNTroubles (ingen Bird-session), AntifilterDownloadTroubles (fejl ved indlæsning af blokerede IP-adresser), SiteTroubles (ulykkeligt telegram er ikke tilgængeligt)
  • systemadvarsler, for eksempel HostGrowingDiskReadLatency (billigt SD-kort bliver ulæseligt)

Eksempel på overvågningsinstallation:

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

Auto Discovery for Prometheus er konfigureret i mappen /etc/prometheus/auto_http, et eksempel på tilføjelse af en vært til overvågning (værter overvåges ikke som standard):

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

Ud over det hele planlagde jeg at oprette forbindelse til to udbydere, så internettet ville fortsætte med at fungere, selvom den ene udbyder havde problemer med netværket, eller de glemte at betale for internettet osv. og andre menneskelige faktorer.

Den mest avancerede brugeroplevelse om emnet multi-wan er beskrevet her til Mwan3-systemet under Openwrt. Denne løsning har rig funktionalitet, men opsætning og drift af den generelt til multi-wan er ret besværligt. Bare et eksempel: Hvis du kommer til nogle websteder fra to IP-adresser på én gang, kan de måske ikke lide det, de holder op med at fungere => "Internettet fungerer ikke."

Under hensyntagen til denne erfaring besluttede jeg, at multihoming ikke er en prioritet endnu, kun failover. Selvom det ser ud til, at i de nyeste versioner af Linux skal alt fungere med en kommando som:

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

Så for at undgå et enkelt fejlpunkt tager vi 2 BPI'er, forbinder hver til én udbyder, forbinder dem med hinanden og laver forbindelsen med hinanden til dynamisk routing via bird/OSPF.

Dernæst annoncerer vi den samme IP-adresse på hver enkelt, hvis tjenesten er tilgængelig (internet, DNS). Det vil sige, at vi ikke selv vil sætte standardruten, men gennem fugl. Jeg spionerede på løsningen her .

Denne funktionalitet er endnu ikke implementeret, den snigende coronavirus spillede et puds her (ikke alt kom fra Aliexpress; en anden onlinebutik, Layta, lovede at levere om en uge, men der er gået mere end en måned; den anden udbyder havde ikke tid at forlænge kablet inden karantæne, lykkedes det kun at få et hul i boret ind i væggen til kablet).

Sådan bestiller du R64

Selve tavlen er i den officielle butik SinoVoip.
Det er også bedre at bestille med det samme:

  • ernæring + informer EU eller US stikstandard
  • køleplade: radiatorer/ventilatorer; fordi både CPU'en og switch-chippen varmer op
  • wifi antenne, for eksempel

Der er en nuance - leveringsprisen er blevet utilstrækkeligt høj i den officielle butik i nogen tid. Manager Judy Huang overbeviste mig om, at der ikke var nogen fejl, og du kunne vælge ePacket for $5, men jeg så, at for Rusland er der kun EMS for >$33. Ubehageligt, men ikke kritisk. Desuden, hvis du vælger et andet land til levering (jeg gik gennem alle kontinenterne), vil leveringen koste ~$5. Russofober?.. Men så fandt jeg ud af, at for Frankrig er leveringsprisen også ~30$, og jeg faldt til ro.

Som et resultat tilbød Judy at afgive en ordre, men ikke betale (vink: læg mindre på kortet, så den automatiske betaling ikke går igennem); skriv til hende og hun vil sætte leveringsprisen ned til normalen. Succes.

Issues

Ikke alt fungerer perfekt endnu.

Ydelse

Ansible=Python-kommandoer udføres langsomt, selv inaktive, i 20-30 sekunder; en størrelsesorden længere end på en x86 bærbar. Desuden udføres de først ret hurtigt, ~3 sekunder, derefter bremses de kraftigt. Dette kan skyldes, at CPU'en opvarmes (drossel). Go-koden tager også lang tid at virke:

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

Wifi virker, men på Armbian stopper det efter cirka en dag, skriver:

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

Kun en genstart hjælper. Vi skal videre Find ud af det.

Ethernet

Ethernet virker, men efter ~64 timer stopper pakker (DHCP) fra RXNUMX med at ankomme.
Genstart af grænsefladen hjælper:

ifdown br0; sleep 30; ifup br0

Driveren er ny, den er ikke blevet accepteret i kernen endnu, jeg håber det er kinesiske Landen Chao afslutter det.

Kilde: www.habr.com

Tilføj en kommentar