Banana Pi R64 Router - Debian, Wireguard, RKN

Banana Pi 64 är en enkelkortsdator som liknar Raspberry Pi, men med flera Ethernet-portar, vilket gör det möjligt att förvandla den till en router baserad på en allmän Linux-distribution.

Banana Pi R64 Router - Debian, Wireguard, RKN

Ja, det finns redan Openwrt, men det har sina egna problem, dess GUI och CLI; Det finns Mikrotik, men återigen har den ett eget GUI/CLI, och Wireguard fungerar inte direkt... Generellt sett vill jag ha en router med flexibla inställningar, samtidigt som den håller sig inom ramen för standard Linux, som du arbetar med med varje dag.

I artikeln under namnen BPI, R64, enkelkort kommer jag att mena samma sak - själva Banana Pi R64 enkelkort.

Att välja en bild. Ladda ner via eMMC

Den allra första färdigheten du behöver skaffa dig när du arbetar med SBC i allmänhet, och med R64 i synnerhet, innebär detta att lära sig hur man laddar in ett operativsystem i det och att kunna interagera med det, eftersom R64 inte har en port för en bildskärm (HDMI, till exempel). När allt föll av - slutade Wifi, Ethernet, Bluetooth, USB, etc. att fungera. Det finns en UART, genom vars gränssnitt du alltid kan se vad som gick fel, och även köra ett par kommandon från konsolen, om det behövs.

Algoritm för att ansluta till R64 via USB-UART:

  • vi springer till affären för radiodelar efter en USB-UART-kabel (PL2303, seriell-till-USB)
  • Anslut ena USB-änden till datorn och den andra, UART, till R64, med tre av fyra kablar, som på bilden nedan
  • kör i datorkonsolen sudo minicom

Efter detta kommer i de flesta fall enkortskonsolen att visas = framgång.
Du kan se fler detaljer här.

Banana Pi R64 Router - Debian, Wireguard, RKN

Därefter är det enklaste sättet att ladda operativsystemet från ett SD-kort: ladda ner genom länk bild och fyll den:

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 sätter in kortet i R64 SD-kortplatsen, slår på det och observerar att den anslutna konsolen laddar först uboot, sedan standard Linux-laddning.

Ett alternativt startalternativ är att använda ett 64Gb-kort som redan är inbyggt i R8, kallat eMMC. Enligt instruktionerna i wikin kopierar vi bilden till enheten
/dev/mmcblk0 till BPI, starta om, ta bort SD-kortet, slå på BPI igen... och det fungerar inte. Hur man går fram och tillbaka Boot select bry dig inte.

Faktum är att åtminstone för BPI måste du ställa in en speciell flagga för att kunna starta från en intern flashenhet:

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]

Därefter måste du skriva preloader till en speciell startpartition

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

Tillverkare R64 (Kina) publicerade denna binära fil här. Vad det gör är okänt (det finns inga källkoder), men det fungerar inte utan det heller.

I allmänhet börjar bilderna efter detta att laddas från eMMC. Om du vill ta reda på det och skapa bilder från grunden, måste du för båda fallen (SD/eMMC) skriva flera filer till (preloader för SD-kort, ATF, u-boot) bara för att komma till att ladda kärnan. Detta ämne är fortfarande kvar utvecklas, men för oss är huvudsaken att det fungerar och okej.

Nu laddar jag ner via eMMC, för att vara ärlig, jag använder det inte, det räcker med ett SD-kort, men jag spenderade ganska mycket tid på att få det att fungera, så låt det stå i artikeln.

Välja ett operativsystem. Armbian

Den första applikationsuppgiften är att starta ett VPN, naturligtvis Wireguard. Det upptäcktes omedelbart att den inte var sammansatt på kärnan och att det inte fanns några rubriker. Jag byggde om kärnan och, som min vana är med x86, satte jag ihop kärnmodulen med DKMS. Men hastigheten att bygga även små verktyg på arm64 överraskade mig obehagligt. Och sedan krävdes ytterligare en kärnmodul osv. I allmänhet visar det sig att allt som har med kärnan att göra är bäst att montera på en varm x86-bärbar dator, sedan överföras till R64 genom enkel kopiering, startas om och testas.

En annan sak är användarutrymmesdelen. I mitt fall av att välja Debian finns allt för arm64-arkitekturen redan på packages.debian.org och det finns inget behov av att bygga om någonting.

För att inte producera en cykel till har jag portad armbian på BPI R64.
Eller snarare, detta: användarutrymmesdelen är Armbian, och kärnan är hämtad från förvaret Frank-A. Den senaste bilden kan laddas ner här.

All verksamhet kring utveckling av mjukvarudelen av R64 bedrivs på Forum. Generellt sett strävar tillverkaren själv efter att popularisera routern för Openwrt, men tack vare aktiviteten hos utvecklaren Frank från Tyskland hamnar alla funktioner snabbt i kärnan för Debian. Överraskande nog är Frank aktiv i varje forumtråd.

Arbetsplatsorganisation: ledningar

Separat skulle jag vilja berätta hur man under utveckling/testning placerar en SBC (inte bara en BPI) på ett bord för att inte dra en Ethernet-kabel till den från en internetkälla över hela rummet/kontoret. Faktum är att du å ena sidan måste förse hårdvaran med Internet, men å andra sidan kan allt i den hårdvaran gå sönder, och först och främst Wifi.

Först bestämde jag mig för att köpa en billig USB-Wifi "vissla", koppla in den i den enda porten på BPI och glömma ledningarna. För att göra detta köpte jag en billig TP-LINK TL-WN725N USB 2.0, men mycket snart stod det klart att det inte skulle ta fart: för att visselpipan ska fungera behöver du en kärndrivrutin, som naturligtvis inte fanns där (senare monterade jag ihop den nödvändiga RTL8XXXU-drivrutinen, men den är fortfarande opraktisk). Och Ethernet-kabeln förstörde utseendet på rummet ett tag.

Som ett resultat lyckades jag bli av med kabeln med hjälp av Tenda MW3 (Wifi mesh-system): Jag placerade helt enkelt en kub under bordet och kopplade BPI:n till den senares LAN-port med en meterlång Ethernet-kabel. Framgång.

Wireguard, RKN, Bird

En av sakerna jag vill använda Banana PI till är att ha fri tillgång till sajter blockerade av RKN, i synnerhet, så att Telegram och Slack-samtal kan fungera. Artiklar om Habré har redan föreslagits om detta ämne: tid, два, tre.

Jag distribuerade exakt den här lösningen med Ansible: länk.

VPS antas köra Ubuntu 18.04. Jag kollade funktionaliteten på två värdar i Europa: Amazon och Digital Ocean.

Så vi installerade ovanstående Armbian på R64, den är tillgänglig via ssh under namnet hm-bananapi-1 och har tillgång till internet. Vi distribuerar konsekvent Ansible, automatiseringsskript och startar själva 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

Därefter måste du distribuera vår VPN till VPS på samma sätt:

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

Här är argumentet alltid aktuell-vpn, och det faktiska VPS-namnet är konfigurerat i en variabel (i det här fallet är 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, innan alla dessa operationer måste du generera hemligheter (särskilt Wireguard-nycklar) i mappen ./secrets, ska katalogen se ut .

Ansible Automation i Python

Du kanske märker att istället för att vara i YAML-format, är Ansible-kommandona kodade i Python-skript. Som jämförelse, hur man aktiverar fågeldemonen på vanligt sätt:

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

och hur man gör samma sak via Python:

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

Genom att skriva Ansible-kommandon i Python kan du återanvända koden, och generellt sett öppnas alla möjligheter för det allmänna språket. Till exempel, installera bird på R64 och VPS:

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

se funktionskoden install_bird().

Denna funktion kallas pybook genomförs här. Det finns ingen dokumentation om pybook ännu, men jag ska åtgärda det här problemet senare.

Vad tycker han uppströms om detta.

Övervakning. Prometheus

Totalt: telegram fungerar, linkedin och pornhub också, i allmänhet är användarupplevelsen ok. Men allt kan gå sönder, inklusive kinesisk hårdvara.

Kärnuppdateringar kan också vara intressanta: till exempel, jag ville uppdatera kärnan 5.4 => 5.6, ja, Wireguard finns där ur lådan, inget behov av att patcha... Inte förr sagt än gjort: jag överförde mödosamt patcharna från 5.4 till 5.6, kärnan startade, tunneln till VPS:n plingade, men bird kan inte ansluta till felet "BGP Error" ... "Jag rullade tillbaka i skräck" (c) till 5.4; Flytten till 5.6 sköts upp i TODO.

Därför, förutom att installera routern och VPS, lade jag till övervakning (på x86 Ubuntu 18.04), som är installerad på en separat värd med följande komponenter:

  • prometheus, alertmanager, blackbox_exporter - allt i docker
  • Varningar skickas till telegramkanalen med hjälp av metalmatze/alertmanager-bot boten - även i Docker
  • tor för boten, så att boten kan varna situationer när det finns internet, men telegram fungerar fortfarande inte, och boten själv kan inte ansluta
  • applicerad varningar: NodeVPNTroubles (ingen ping till VPS), BirdVPNTroubles (ingen Bird-session), AntifilterDownloadTroubles (fel vid laddning av blockerade IP-adresser), SiteTroubles (olyckligt telegram är inte tillgängligt)
  • systemvarningar, till exempel HostGrowingDiskReadLatency (billigt SD-kort blir oläsligt)

Exempel på övervakningsinstallation:

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

Auto Discovery för Prometheus konfigureras i mappen /etc/prometheus/auto_http, ett exempel på att lägga till en värd för övervakning (värdar övervakas inte 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 leverantörer, 2 BPI, anycast failover

Utöver allt planerade jag att koppla upp mig till två leverantörer så att internet skulle fortsätta fungera, även om en leverantör hade problem med nätet, eller de glömde att betala för internet etc. och andra mänskliga faktorer.

Den mest avancerade användarupplevelsen på ämnet multi-wan beskrivs här för Mwan3-systemet under Openwrt. Denna lösning har rik funktionalitet, men att installera och använda den i allmänhet för multi-wan är ganska besvärligt. Bara ett exempel: om du kommer till vissa webbplatser från två IP-adresser samtidigt, kanske de inte gillar det, de kommer att sluta fungera => "Internet fungerar inte."

Med hänsyn till denna erfarenhet bestämde jag mig för att multihoming inte är en prioritet ännu, bara failover. Även om det verkar som att i de senaste versionerna av Linux borde allt fungera med ett kommando som:

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

Så, för att undvika en enda punkt av fel, tar vi 2 BPI:er, ansluter var och en till en leverantör, ansluter dem till varandra och gör anslutningen till varandra dynamisk routing via bird/OSPF.

Därefter annonserar vi samma IP-adress på var och en om tjänsten är tillgänglig (Internet, DNS). Det vill säga, vi kommer inte att ställa in standardrutten själva, utan genom fågel. Jag spanade efter lösningen här .

Denna funktion har ännu inte implementerats, det lömska coronaviruset spelade ett spratt här (inte allt kom från Aliexpress; en annan onlinebutik, Layta, lovade att leverera om en vecka, men mer än en månad har gått; den andra leverantören hade inte tid att förlänga kabeln innan karantän, lyckades bara få ett hål i borr i väggen för kabeln).

Hur man beställer R64

Själva tavlan finns i den officiella butiken SinoVoip.
Det är också bättre att beställa omedelbart:

  • mat + informera EU- eller US-kontaktstandard
  • kylfläns: radiatorer/fläktar; eftersom både CPU:n och switchchippet värms upp
  • wifi antenn, exempelvis

Det finns en nyans - leveranspriset har blivit otillräckligt högt i den officiella butiken under en tid. Manager Judy Huang övertygade mig om att det inte var något fel, och du kunde välja ePacket för $5, men jag såg att för Ryssland finns det bara EMS för >$33. Obehagligt, men inte kritiskt. Dessutom, om du väljer något annat land för leverans (jag gick igenom alla kontinenter), kommer leveransen att kosta ~$5. Russofober?.. Men sedan upptäckte jag att för Frankrike är leveranspriset också ~30$, och jag lugnade ner mig.

Som ett resultat erbjöd Judy sig att göra en beställning, men inte betala (antyda: lägg mindre på kortet så att den automatiska betalningen inte går igenom); skriv till henne så sänker hon leveranspriset till normalt. Framgång.

Frågor

Allt fungerar inte perfekt ännu.

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

Ansible=Python-kommandon exekveras långsamt, även inaktiva, i 20-30 sekunder; en storleksordning längre än på en x86 laptop. Dessutom exekveras de till en början ganska snabbt, ~3 sekunder, sedan saktar de ner kraftigt. Detta kan bero på att CPU:n värms upp (strypning). Go-koden tar också lång tid att fungera:

# запрос метрик для прометея из 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 fungerar, men på Armbian slutar det efter ungefär 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
...

Bara en omstart hjälper. Vi måste gå vidare sortera ut.

ethernet

Ethernet fungerar, men efter ~64 timmar slutar paket (DHCP) från RXNUMX att anlända.
Att starta om gränssnittet hjälper:

ifdown br0; sleep 30; ifup br0

Drivrutinen är ny, den har inte accepterats i kärnan än, jag hoppas att det är kinesiska Landen Chao avslutar det.

Källa: will.com

Lägg en kommentar