🥇Banana Pi R64 router - Debian, Wireguard, RKN

A Banana Pi 64 egy a Raspberry Pi-hez hasonló egylapos számítógép, de több Ethernet porttal rendelkezik, ami lehetővé teszi, hogy egy általános célú Linux disztribúción alapuló routerré alakítsák.

Igen, van már Openwrt, de megvannak a maga problémái, a GUI és a CLI; Van Mikrotik, de annak megint van saját GUI/CLI, és a Wireguard nem megy ki a dobozból... Általánosságban elmondható, hogy rugalmas beállításokkal rendelkező routert szeretnék, miközben a normál Linux keretein belül marad, amivel te dolgozol. minden nappal.

A cikkben a BPI, R64, single-board név alatt ugyanazt fogom érteni - magát a Banana Pi R64 egykártyát.

Kép kiválasztása. Letöltés eMMC-n keresztül

A legelső készség, amelyet el kell sajátítania, amikor dolgozik SBC általánosságban, és az R64 esetében ez azt jelenti, hogy megtanuljuk, hogyan töltsünk be operációs rendszert, és tudjunk vele kommunikálni, mert az R64-ben nincs monitor portja (pl. HDMI). Amikor minden leesett - leállt a Wifi, Ethernet, Bluetooth, USB, stb.. Van egy UART, aminek a felületén keresztül mindig láthatod, hogy mi rontott el, és a konzolról is futtathatsz pár parancsot, ha kell.

Algoritmus az R64-hez USB-UART-on keresztül történő csatlakozáshoz:

futunk a rádióalkatrész boltba egy USB-UART kábelért (PL2303, soros-USB)
csatlakoztassa az egyik USB végét a számítógéphez, a másik UART végét pedig az R64-hez, négyből három vezetékkel, az alábbi képen látható módon
fut a számítógép konzoljában sudo minicom

Ezek után a legtöbb esetben megjelenik az egylapos konzol = siker.
További részleteket láthat itt.

Ezután a legegyszerűbb módja az operációs rendszer betöltése SD-kártyáról: letöltés: link kép és töltse ki:

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

Behelyezzük a kártyát az R64 SD foglalatba, bekapcsoljuk, és megfigyeljük, hogy a csatlakoztatott konzol először uboot, majd normál Linux betöltődik.

Alternatív rendszerindítási lehetőség az R64-be már beépített 8 GB-os kártya, az eMMC használata. A wiki utasításai szerint a képet másoljuk a készülékre
/dev/mmcblk0 a BPI-hez, indítsa újra, vegye ki az SD-kártyát, kapcsolja be újra a BPI-t... és nem működik. Hogyan lehet oda-vissza menni Boot select ne zavarjon.

A helyzet az, hogy legalább a BPI-hez be kell állítania egy speciális jelzőt, hogy a belső flash meghajtóról indíthasson:

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]

Ezután az előtöltőt egy speciális rendszerindító partícióra kell írnia

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

Az R64 gyártó (Kína) közzétette ezt a bináris fájlt itt. Hogy mit csinál, az ismeretlen (nincs forráskód), de enélkül sem fog működni.

Általában ezt követően elkezdődik a képek betöltése az eMMC-ről. Ha ki akarod találni és a semmiből szeretnél képeket készíteni, akkor mindkét esetben (SD/eMMC) még több fájlt kell írnod (SD kártya előbetöltő, ATF, u-boot) csak a kernel betöltéséhez. Ez a téma még mindig fejlődik, de nekünk az a fő, hogy működjön és rendben.

Most eMMC-n keresztül töltöm le, őszintén szólva nem használom, elég egy SD kártya, de elég sok időt töltöttem azzal, hogy működjön, szóval legyen benne a cikkben.

Operációs rendszer kiválasztása. Armbian

Az első alkalmazási feladat egy VPN, természetesen a Wireguard elindítása. Azonnal kiderült, hogy a kernel oldalán nincs összerakva, és nincsenek fejlécek. Újraépítettem a kernelt, és az x86-nál szokásom szerint összeállítottam a kernelmodult DKMS segítségével. Az arm64-en még kis közművek kiépítésének sebessége azonban kellemetlenül meglepett. És akkor kellett még egy kernel modul stb. Általánosságban elmondható, hogy a kernellel kapcsolatos mindent a legjobb egy meleg x86-os laptopon összeszerelni, majd egyszerű másolással átvinni az R64-re, újraindítani és tesztelni.

Egy másik dolog a userspace rész. Az én esetemben, amikor a Debian-t választom, az arm64 architektúrához már minden megtalálható a packages.debian.org-on, és nincs szükség újjáépítésre.

Annak érdekében, hogy ne gyártsanak még egy kerékpárt, I portolt armbiai a BPI R64-en.
Illetve ez: a userspace rész Armbian, a kernel pedig a repository-ból származik Őszinte-A. A legújabb kép letölthető itt.

Az R64 szoftverrészének fejlesztésével kapcsolatos minden tevékenység a következő napon történik fórum. Általánosságban elmondható, hogy a gyártó maga igyekszik népszerűsíteni az Openwrt útválasztóját, de a német Frank fejlesztő tevékenységének köszönhetően minden funkció gyorsan a Debian rendszermagjába kerül. Meglepő módon Frank minden fórumszálban aktív.

Munkaterület szervezése: vezetékek

Külön szeretném elmondani, hogy a fejlesztés/tesztelés során hogyan helyezzünk el egy SBC-t (nem csak egy BPI-t) az asztalra, hogy ne fusson rá Ethernet-kábel egy Internet forrásból az egész helyiségben/irodában. A helyzet az, hogy egyrészt egy hardvert internettel kell ellátni, másrészt az adott hardverben minden elromolhat, és mindenekelőtt a Wifi.

Először úgy döntöttem, veszek egy olcsó USB-Wifi „sípot”, bedugom a BPI egyetlen portjába, és elfelejtem a vezetékeket. Ehhez vásároltam egy olcsó TP-LINK TL-WN725N USB 2.0-t, de nagyon hamar kiderült, hogy nem indul el: a síp működéséhez kernel-illesztőprogramra van szükség, ami természetesen nem volt ott. (később összeraktam a szükséges RTL8XXXU drivert, de még mindig nem praktikus ). Az Ethernet-kábel pedig egy időre elrontotta a szoba megjelenését.

Ennek eredményeként a Tenda MW3 (Wifi mesh system) segítségével sikerült megszabadulnom a kábeltől: egyszerűen az asztal alá tettem egy kockát, és egy méteres Ethernet kábellel csatlakoztattam a BPI-t az utóbbi LAN portjához. Siker.

Drótvédő, RKN, madár

Az egyik dolog, amire a Banana PI-t használni szeretném, az az, hogy ingyenes hozzáféréssel rendelkezzenek az RKN által blokkolt oldalakhoz, különösen, hogy működhessenek a Telegram és a Slack hívások. Habréról már cikkeket javasoltak ebben a témában: idő, два, három.

Pontosan ezt a megoldást telepítettem az Ansible segítségével: link.

A VPS feltételezhetően Ubuntu 18.04-et futtat. Két európai tárhelyen ellenőriztem a funkcionalitást: az Amazon és a Digital Ocean.

Tehát a fenti Armbiant R64-re telepítettük, ssh-n keresztül érhető el a név alatt hm-bananapi-1 és internet hozzáféréssel rendelkezik. Következetesen telepítjük az Ansible automatizálási szkripteket, és magát a telepítést elindítjuk az R64-en:

# зависимости для 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

Ezután a VPN-t ugyanúgy kell telepítenie a VPS-re:

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

Itt az argumentum mindig aktuális-vpn, és a tényleges VPS-név egy változóban van konfigurálva (ebben az esetben 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

Ó igen, mindezen műveletek előtt titkokat (különösen Wireguard kulcsokat) kell generálnia a mappában ./secrets, a könyvtárnak így kell kinéznie így.

Lehetséges automatizálás a Pythonban

Észreveheti, hogy a YAML formátum helyett az Ansible parancsok Python-szkriptekben vannak kódolva. Összehasonlításképpen, hogyan lehet engedélyezni a madárdémont a szokásos módon:

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

és hogyan kell ugyanezt megtenni Python segítségével:

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

Az Ansible parancsok Pythonban történő írása lehetővé teszi a kód újrafelhasználását, és általában megnyitja az általános célú nyelv összes lehetőségét. Például a bird telepítése R64-re és VPS-re:

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

lásd a funkció kódját install_bird().

Ez a funkció az ún pybook végrehajtva itt. Még nincs dokumentáció a pybookról, de később kijavítom a problémát.

mit gondol upstream ez alkalommal.

Monitoring. Prométheusz

Összesen: a távirat működik, a linkedin és a pornhub is, általában a felhasználói élmény rendben van. De minden eltörhet, beleértve a kínai hardvert is.

A kernelfrissítések is érdekesek lehetnek: például az 5.4 => 5.6-os kernelt akartam frissíteni, nos, a Wireguard ott van a dobozból, nem kell foltozni... Alig van szó: gondosan átvittem a javításokat az 5.4-ről 5.6-ra, a kernel elindult, az alagút a VPS-hez pingált, de a madár nem tud csatlakozni a "BGP Error" hibával... "Iszonyatosan visszagurultam" (c) 5.4-re; Az 5.6-ra való átállást a TODO-ban elhalasztották.

Ezért az útválasztó és a VPS telepítése mellett hozzáadtam a megfigyelést (x86 Ubuntu 18.04-en), amely egy külön gazdagépre van telepítve a következő összetevőkkel:

prometheus, alertmanager, blackbox_exporter – mindez a dockerben
A riasztásokat a metalmatze/alertmanager-bot bot segítségével küldik a távirati csatornára – szintén a Dockerben
tor a bot számára, hogy a bot riaszthassa az olyan helyzeteket, amikor van internet, de a távirat továbbra sem működik, és maga a bot nem tud csatlakozni
alkalmazott riasztások: NodeVPNTroubles (nincs ping a VPS-hez), BirdVPNTroubles (nincs Bird-munkamenet), AntifilterDownloadTroubles (hiba a blokkolt IP-címek betöltésekor), SiteTroubles (a rossz sorsú távirat nem érhető el)
rendszerriasztások, például HostGrowingDiskReadLatency (az olcsó SD-kártya olvashatatlanná válik)

Példa megfigyelő telepítésre:

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

A Prometheus automatikus felderítése az /etc/prometheus/auto_http mappában van konfigurálva, egy példa egy gazdagép hozzáadására a megfigyeléshez (a gazdagépeket alapértelmezés szerint nem figyeli):

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 szolgáltató, 2 BPI, anycast feladatátvétel

Mindezek mellett két szolgáltatóhoz való csatlakozást terveztem, hogy az internet tovább működjön, még akkor is, ha az egyik szolgáltatónak gondjai vannak a hálózattal, vagy elfelejtett fizetni az internetért stb., meg egyéb emberi tényezők.

Leírják a legfejlettebb felhasználói élményt a multi-wan témakörben itt az Openwrt alatti Mwan3 rendszerhez. Ez a megoldás gazdag funkcionalitással rendelkezik, de általában a multi-wan beállítása és üzemeltetése meglehetősen problémás. Csak egy példa: ha egyszerre két IP-címről érkezik egyes oldalakra, lehet, hogy nem tetszik nekik, leállnak => „nem működik az internet”.

Ezt a tapasztalatot figyelembe véve úgy döntöttem, hogy a multihoming még nem prioritás, csak a feladatátvétel. Bár úgy tűnik, hogy a Linux legújabb verzióiban mindennek egyetlen paranccsal kell működnie, például:

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

Tehát az egyetlen hibapont elkerülése érdekében veszünk 2 BPI-t, mindegyiket egy szolgáltatóhoz csatlakoztatjuk, összekapcsoljuk egymással, és a madár/OSPF-en keresztül dinamikus útválasztást hozunk létre egymással.

Ezután mindegyiken ugyanazt az IP-címet hirdetjük meg, ha elérhető a szolgáltatás (Internet, DNS). Vagyis nem magunk állítjuk be az alapértelmezett útvonalat, hanem a madáron keresztül. Megnéztem a megoldást itt .

Ez a funkció még nem valósult meg, itt az alattomos koronavírus trükközött (nem minden érkezett meg az Aliexpresstől; egy másik webáruház, a Layta ígérte, hogy egy hét múlva szállít, de már több mint egy hónap telt el; a második szolgáltatónak nem volt ideje a kábel meghosszabbítására a karantén előtt, csak sikerült egy lyukat fúrni a falba a kábel számára).

Hogyan rendelhetek R64

Maga a tábla a hivatalos boltban van SinoVoip.
Érdemes azonnal megrendelni:

étel + tájékoztassa az EU vagy az Egyesült Államok csatlakozó szabványát
hűtőborda: radiátorok/ventilátorok; mert a CPU és a kapcsoló chip is felmelegszik
wifi antenna, például

Van egy árnyalat - a szállítási ár egy ideje nem megfelelően magas a hivatalos boltban. Judy Huang menedzser meggyőzött arról, hogy nincs hiba, és választhat az ePacket 5 dollárért, de láttam, hogy Oroszországban csak EMS van 33 dollár felett. Kellemetlen, de nem kritikus. Sőt, ha más országot választasz a szállításhoz (én az összes kontinenst bejártam), a szállítás ~5 dollárba kerül. Russzofóbok?.. De aztán rájöttem, hogy Franciaországnak is ~30$ a szállítási ára, és megnyugodtam.

Ennek eredményeként Judy felajánlotta, hogy megrendel, de nem fizet (célzás: kevesebbet tegyen a kártyára, hogy ne menjen át az automatikus fizetés); írj neki és lecsökkenti a szállítási árat a normálra. Siker.

Problémák

Még nem működik minden tökéletesen.

termelékenység

Ansible=A Python parancsok lassan futnak le, még az üresjáratok is, 20-30 másodpercig; egy nagyságrenddel hosszabb, mint egy x86-os laptopon. Sőt, eleinte elég gyorsan, ~3 másodpercig végrehajtják, aztán erősen lelassulnak. Ennek oka lehet a CPU felmelegedése (fojtás). A Go kód működése is sokáig tart:

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

A Wifi működik, de Armbianon körülbelül egy nap után leáll, írja:

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

Csak az újraindítás segít. Tovább kell lépnünk megold.

Ethernet

Az Ethernet működik, de ~64 óra elteltével az RXNUMX-ről nem érkeznek csomagok (DHCP).
A felület újraindítása segít:

ifdown br0; sleep 30; ifup br0

A driver új, még nem fogadták be a kernelbe, remélem kínai Landen Chao befejezi.

Forrás: will.com

Banana Pi R64 Router - Debian, Wireguard, RKN