Banana Pi R64-ruter - Debian, Wireguard, RKN

Banana Pi 64 er en enkeltbords datamaskin som ligner på Raspberry Pi, men med flere Ethernet-porter, som gjør det mulig å gjøre den om til en ruter basert på en generell Linux-distribusjon.

Banana Pi R64-ruter - Debian, Wireguard, RKN

Ja, det finnes allerede Openwrt, men det har sine egne problemer, GUI og CLI; Det er Mikrotik, men igjen har den sin egen GUI/CLI, og Wireguard fungerer ikke ut av esken... Generelt sett vil jeg ha en ruter med fleksible innstillinger, samtidig som jeg holder meg innenfor rammen av standard Linux, som du jobber med med hver dag.

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

Velge et bilde. Last ned via eMMC

Den aller første ferdigheten du må tilegne deg når du jobber med SBC generelt, og med R64 spesielt, betyr dette å lære hvordan du laster et operativsystem inn i det og kunne samhandle med det, fordi R64 ikke har en port for en skjerm (HDMI, for eksempel). Når alt falt av - sluttet Wifi, Ethernet, Bluetooth, USB, etc. å fungere. Det er en UART, gjennom grensesnittet som du alltid kan se hva som gikk galt, og også kjøre et par kommandoer fra konsollen, om nødvendig.

Algoritme for tilkobling til R64 via USB-UART:

  • vi løper til radiodelsbutikken for en USB-UART-kabel (PL2303, seriell-til-USB)
  • koble den ene USB-enden til datamaskinen, og den andre, UART, til R64, med tre av fire ledninger, som på bildet nedenfor
  • kjøre i datamaskinkonsollen sudo minicom

Etter dette vil i de fleste tilfeller enkeltbordskonsollen vises = suksess.
Du kan se flere detaljer her.

Banana Pi R64-ruter - Debian, Wireguard, RKN

Deretter er den enkleste måten å laste ned operativsystemet fra et SD-kort: last ned av link bilde og fyll 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 setter inn kortet i R64 SD-sporet, slår det på, og observerer at den tilkoblede konsollen lastes først ved uboot, deretter standard Linux-lasting.

Et alternativt oppstartsalternativ er å bruke et 64Gb-kort som allerede er innebygd i R8, kalt eMMC. I henhold til instruksjonene i wikien kopierer vi bildet til enheten
/dev/mmcblk0 til BPI, start på nytt, fjern SD-kortet, slå på BPI igjen... og det fungerer ikke. Hvordan gå frem og tilbake Boot select ikke bry deg.

Faktum er at i det minste for BPI må du sette et spesielt flagg for å kunne starte opp fra en intern flash-stasjon:

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]

Deretter må du skrive forhåndslaster inn i en spesiell oppstartspartisjon

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

Produsent R64 (Kina) la ut denne binærfilen her. Hva det gjør er ukjent (det er ingen kildekoder), men det vil ikke fungere uten det heller.

Generelt, etter dette begynner bildene å lastes fra eMMC. Hvis du vil finne ut av det og lage bilder fra bunnen av, så må du for begge tilfeller (SD/eMMC) skrive flere filer (preloader for SD-kort, ATF, u-boot) bare for å komme til å laste inn kjernen. Dette emnet er fortsatt utvikler seg, men for oss er hovedsaken at det fungerer og greit.

Nå laster jeg ned via eMMC, for å være ærlig, jeg bruker det ikke, et SD-kort er nok, men jeg brukte ganske mye tid på å få det til å fungere, så la det være i artikkelen.

Velge et operativsystem. Armbian

Den første applikasjonsoppgaven er å lansere en VPN, naturligvis Wireguard. Det ble umiddelbart oppdaget at på kjernesiden var den ikke satt sammen og det var ingen overskrifter. Jeg bygde om kjernen og, som min vane med x86, satt sammen kjernemodulen ved hjelp av DKMS. Men hastigheten på å bygge selv små verktøy på arm64 overrasket meg ubehagelig. Og så var det nødvendig med en kjernemodul til osv. Generelt viser det seg at alt relatert til kjernen best settes sammen på en varm x86 bærbar PC, og deretter overføres til R64 ved enkel kopiering, omstart og testing.

En annen ting er brukerromsdelen. I mitt tilfelle med å velge Debian, er alt for arm64-arkitekturen allerede på packages.debian.org, og det er ikke nødvendig å gjenoppbygge noe.

For ikke å produsere en annen sykkel, har jeg portert armbian på BPI R64.
Eller rettere sagt, dette: brukerromsdelen er Armbian, og kjernen er hentet fra depotet Frank-EN. Det siste bildet kan lastes ned her.

All aktivitet på utvikling av programvaredelen av R64 utføres på forum. Generelt sett streber produsenten selv etter å popularisere ruteren for Openwrt, men takket være aktiviteten til utvikleren Frank fra Tyskland, havner alle funksjonene raskt i kjernen til Debian. Overraskende nok er Frank aktiv i alle forumtråder.

Organisering av arbeidsområdet: ledninger

Separat vil jeg fortelle deg hvordan du under utvikling/testing plasserer en SBC (ikke bare en BPI) på et bord for ikke å kjøre en Ethernet-kabel til den fra en Internett-kilde over hele rommet/kontoret. Faktum er at du på den ene siden må gi en maskinvare med Internett, men på den annen side kan alt i den maskinvaren brytes ned, og først og fremst Wifi.

Først bestemte jeg meg for å kjøpe en billig USB-Wifi "fløyte", koble den til den eneste porten på BPI og glemme ledningene. For å gjøre dette kjøpte jeg en rimelig TP-LINK TL-WN725N USB 2.0, men veldig snart ble det klart at den ikke ville ta av: for at fløyten skal fungere, trenger du en kjernedriver, som selvfølgelig ikke var der (senere satte jeg sammen den nødvendige RTL8XXXU-driveren, men den er fortsatt upraktisk). Og Ethernet-kabelen ødela utseendet til rommet en stund.

Som et resultat klarte jeg å kvitte meg med kabelen ved hjelp av Tenda MW3 (Wifi mesh-system): Jeg plasserte ganske enkelt én kube under bordet og koblet BPI til sistnevntes LAN-port med en meterlang Ethernet-kabel. Suksess.

Wireguard, RKN, Bird

En av tingene jeg vil bruke Banana PI til er å ha gratis tilgang til nettsteder blokkert av RKN, spesielt, slik at Telegram- og Slack-samtaler kan fungere. Artikler om Habré har allerede blitt foreslått om dette emnet: tid, два, tre.

Jeg implementerte akkurat denne løsningen ved å bruke Ansible: link.

VPS antas å kjøre Ubuntu 18.04. Jeg sjekket funksjonaliteten på to hostere i Europa: Amazon og Digital Ocean.

Så vi installerte Armbian ovenfor på R64, den er tilgjengelig via ssh under navnet hm-bananapi-1 og har internettilgang. Vi distribuerer konsekvent Ansible, automatiseringsskript og starter selve installasjonen 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

Deretter må du distribuere VPN-en vår til VPS-en på samme måte:

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

Her er argumentet alltid gjeldende-vpn, og det faktiske VPS-navnet er konfigurert i en variabel (i dette tilfellet 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

Å ja, før alle disse operasjonene må du generere hemmeligheter (spesielt Wireguard-nøkler) inn i mappen ./secrets, skal katalogen se ut .

Ansible automatisering i Python

Du vil kanskje legge merke til at i stedet for å være i YAML-format, er Ansible-kommandoene kodet i Python-skript. Til sammenligning, hvordan aktivere fugledemonen på vanlig måte:

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

og hvordan du gjør det samme via Python:

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

Å skrive Ansible-kommandoer i Python lar deg gjenbruke koden, og åpner generelt opp alle mulighetene for det generelle språket. For eksempel installere bird på R64 og VPS:

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

se funksjonskoden install_bird().

Denne funksjonen kalles pybook implementert her. Det er ingen dokumentasjon på pybook ennå, men jeg skal fikse dette problemet senere.

Hva tror han oppstrøms i denne anledning.

Overvåkning. Prometheus

Totalt: telegram fungerer, linkedin og pornhub også, generelt er brukeropplevelsen ok. Men alt kan gå i stykker, inkludert kinesisk maskinvare.

Kjerneoppdateringer kan også være interessante: for eksempel, jeg ønsket å oppdatere kjerne 5.4 => 5.6, vel, Wireguard er der ut av esken, ingen grunn til å lappe... Ikke før sagt enn gjort: Jeg har møysommelig overført oppdateringene fra 5.4 til 5.6, kjernen startet opp, tunnelen til VPS pinget, men bird kan ikke koble seg til feilen "BGP Error" ... "Jeg rullet tilbake i skrekk" (c) til 5.4; Flyttingen til 5.6 ble utsatt i TODO.

Derfor, i tillegg til å installere ruteren og VPS, la jeg til overvåking (på x86 Ubuntu 18.04), som er installert på en separat vert med følgende komponenter:

  • prometheus, alertmanager, blackbox_exporter - alt i docker
  • Varsler sendes til telegramkanalen ved hjelp av metalmatze/alertmanager-bot-boten - også i Docker
  • tor for boten, slik at boten kan varsle situasjoner når det er Internett, men telegram fungerer fortsatt ikke, og selve boten kan ikke koble seg til
  • anvendt varsler: NodeVPNTroubles (ingen ping til VPS), BirdVPNTroubles (ingen Bird-økt), AntifilterDownloadTroubles (feil ved lasting av blokkerte IP-adresser), SiteTroubles (ulykkelig telegram er utilgjengelig)
  • systemvarsler, for eksempel HostGrowingDiskReadLatency (billig SD-kort blir uleselig)

Eksempel på overvåkingsinstallasjon:

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

Auto Discovery for Prometheus er konfigurert i mappen /etc/prometheus/auto_http, et eksempel på å legge til en vert til overvåking (verter overvåkes 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 leverandører, 2 BPI, anycast failover

I tillegg til alt planla jeg å koble meg til to leverandører for at Internett skulle fortsette å fungere, selv om den ene leverandøren hadde problemer med nettverket, eller de glemte å betale for internett osv. og andre menneskelige faktorer.

Den mest avanserte brukeropplevelsen om temaet multi-wan er beskrevet her for Mwan3-systemet under Openwrt. Denne løsningen har rik funksjonalitet, men å sette opp og betjene den generelt for multi-wan er ganske plagsomt. Bare ett eksempel: Hvis du kommer til noen nettsteder fra to IP-adresser samtidig, kan det hende de ikke liker det, de vil slutte å fungere => "Internett fungerer ikke."

Med tanke på denne erfaringen bestemte jeg meg for at multihoming ikke er en prioritet ennå, kun failover. Selv om det ser ut til at i de nyeste versjonene av 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 å unngå et enkelt feilpunkt, tar vi 2 BPIer, kobler hver til én leverandør, kobler dem til hverandre og gjør forbindelsen med hverandre dynamisk ruting via bird/OSPF.

Deretter annonserer vi den samme IP-adressen på hver enkelt hvis tjenesten er tilgjengelig (Internett, DNS). Det vil si at vi ikke vil sette standardruten selv, men gjennom fugl. Jeg spionerte på løsningen her .

Denne funksjonaliteten er ennå ikke implementert, det lumske koronaviruset spilte et puss her (ikke alt kom fra Aliexpress; en annen nettbutikk, Layta, lovet å levere om en uke, men det har gått mer enn en måned; den andre leverandøren hadde ikke tid å forlenge kabelen før karantene, klarte bare å få et hull i boret inn i veggen for kabelen).

Slik bestiller du R64

Selve brettet er i den offisielle butikken SinoVoip.
Det er også bedre å bestille umiddelbart:

  • mat + informer EU eller amerikansk pluggstandard
  • kjøleribbe: radiatorer/vifter; fordi både CPU og bryterbrikke varmes opp
  • wifi antenne, for eksempel

Det er en nyanse - leveringsprisen har blitt utilstrekkelig høy i den offisielle butikken i noen tid. Manager Judy Huang overbeviste meg om at det ikke var noen feil, og du kunne velge ePacket for $5, men jeg så at for Russland er det bare EMS for >$33. Ubehagelig, men ikke kritisk. Dessuten, hvis du velger et annet land for levering (jeg gikk gjennom alle kontinentene), vil leveringen koste ~$5. Russofober?.. Men så fant jeg ut at for Frankrike er leveringsprisen også ~30$, og jeg slo meg til ro.

Som et resultat tilbød Judy å legge inn en bestilling, men ikke betale (ymte: legg mindre på kortet slik at den automatiske betalingen ikke går gjennom); skriv til henne og hun vil redusere leveringsprisen til normalen. Suksess.

Problemer

Ikke alt fungerer perfekt ennå.

Производительность

Ansible=Python-kommandoer utføres sakte, selv inaktive, i 20-30 sekunder; en størrelsesorden lengre enn på en x86 bærbar PC. Dessuten blir de først utført ganske raskt, ~3 sekunder, deretter bremser de kraftig. Dette kan skyldes at CPU-en varmes opp (struping). Go-koden bruker også lang tid på å fungere:

# запрос метрик для прометея из 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 fungerer, men på Armbian stopper det etter omtrent 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
...

Bare en omstart hjelper. Vi må gå videre finne det ut.

Ethernet

Ethernet fungerer, men etter ~64 timer slutter pakker (DHCP) fra RXNUMX å komme.
Å starte grensesnittet på nytt hjelper:

ifdown br0; sleep 30; ifup br0

Driveren er ny, den har ikke blitt akseptert i kjernen ennå, jeg håper det er kinesiske Landen Chao gjør det ferdig.

Kilde: www.habr.com

Legg til en kommentar