🥇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, létezik az Openwrt, de annak megvannak a saját furcsaságai, saját grafikus felhasználói felülete és parancssori felülete; létezik a Mikrotik, de annak is megvan a saját grafikus felhasználói felülete/parancssori felülete, és... Wireguard Nem működik magától... Alapvetően egy rugalmas beállításokkal rendelkező routert szeretnék, miközben megmaradok a szokásos Linux keretein belül, amivel nap mint nap dolgozom.

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ő gyakorlati feladat természetesen egy VPN elindítása WireguardAzonnal felfedeztem, hogy a kernel nincs megfelelően lefordítva, és nincsenek benne fejlécek. Újraépítettem a kernelt, és ahogy az x86-nál szokásom, DKMS-sel készítettem egy kernel modult. Azonban az ARM64-en mért fordítási sebesség, még kis segédprogramok esetén is, kellemetlenül meglepő volt. Aztán szükség volt egy újabb kernel modulra, és így tovább. Alapvetően kiderült, hogy bármi, ami kernellel kapcsolatos, a legjobb egy vacak x86-os laptopon lefordítani, majd egyszerűen átmásolni az ARM64-re, újraindítani és tesztelni.

A térfelhasználás egy másik kérdés. Az én esetemben a választás Debian, az arm64 architektúrához szükséges összes elem már megtalálható a csomagokban.debian.org, és nincs szükség semmit újrafordításra.

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 maga a gyártó próbálja népszerűsíteni az OpenWrt routert, de a német fejlesztő, Frank tevékenységének köszönhetően az összes funkció gyorsan bekerül a kernelbe. Debian-a. Meglepő módon Frank minden fórumtémájában 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.

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

Feltételezzük, hogy a VPS a következő alatt fut: Ubuntu Április 18.04. Két európai tárhelyszolgáltatónál teszteltem a funkcionalitást: az Amazonon és a Digital Oceanon.

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 kulcsokat) kell generálni Wireguard) a mappába ./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 frissíteni akartam az 5.4 => 5.6 kernelt, nos, ott volt Wireguard Azonnal kész, nincs szükség patch-elésre... Alig mondtam, kész: aprólékosan átraktam a patch-eket az 5.4-ről 5.6-ra, a kernel elindult, a VPS-hez vezető alagút pingelt, de a Bird nem tud csatlakozni a "BGP Error" hibával... "Rettenetesen visszagörgettem" (c) 5.4-re; az 5.6-ra való áttérés bekerült a TODO-ba.

Ezért a router és a VPS telepítése mellett hozzáadtam a monitorozást is (x86-on Ubuntu 18.04), amely egy különálló gépre van telepítve a következő komponensekkel:

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.