Banana Pi R64 router — Debian, Wireguard, RKN

A Banana Pi 64 egy Raspberry Pi típusú egylapos számítógép, de több Ethernet porttal rendelkezik, lehetővé téve, hogy routerré alakítsuk a Linux általános forgalmú disztribúcióján.

Banana Pi R64 router — Debian, Wireguard, RKN

Igen, már elérhető az Openwrt, de annak megvannak a saját buktatói, saját GUI-jával és CLI-jával; van Mikrotik is, de annak ismét saját GUI/CLI-ja van, és a Wireguard alapértelmezés szerint nem működik… Összességében egy rugalmas beállításokkal rendelkező routerre vágyom, miközben a mindennap használt standard Linux keretein belül maradok.

A cikkben, amely a BPI, R64, egylapos számítógép címek alatt szerepel, ugyanazt a Banana Pi R64 egylapos gépet értem.

Kép kiválasztása. Indítás eMMC-n keresztül.

Az első készség, amelyet el kell sajátítani a SBC általánosságban, és különösen az R64-nél, az az, hogy megtanuljuk, hogyan indítsuk el rajta az operációs rendszert, és lehetőségünk legyen interakcióba lépni vele, mivel az R64-nek nincs portja monitorhoz (például HDMI). Amikor minden leállt — nem működik a Wifi, az Ethernet, a Bluetooth, az USB és a többi, csak UART van, amelyen keresztül mindig megnézhetjük, mi ment rosszul, és szükség esetén néhány parancsot is futtathatunk a konzolon.

USB-UART csatlakoztatási algoritmus az R64-hez:

  • futás a rádiós alkatrészek boltjába egy USB-UART kábellel (PL2303, Serial-to-USB)
  • az egyik USB végét a számítógéphez csatlakoztatjuk, a másikat, UART-ot az R64-hez, három vezetékkel a négyből, ahogy az alábbi képen látható
  • a számítógép konzolján elindítjuk sudo minicom

Ezután a legtöbb esetben megjelenik az egylapos számítógép konzolja = siker.
További részletekért tekintse meg itt.

Banana Pi R64 router — Debian, Wireguard, RKN

A legegyszerűbb az operációs rendszert SD-kártyáról indítani: letöltjük a linkre kattintva képet és feltöltjük:

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

betesszük a kártyát az R64 SD-nyílásába, bekapcsoljuk, és követjük a csatlakoztatott konzolon a betöltést, először az uboot, majd a standard linuxot.

Egy alternatív indítási lehetőség — az R64-ben elhelyezett 8 Gb méretű eMMC kártya segítségével. Az útmutató szerint a képet átmásoljuk az eszközre
/dev/mmcblk0 в BPI, перегружаемся, вытаскиваем SD-карту, включаем BPI снова… и не работает. Как туда-сюда Boot select ne húzd.

Az a helyzet, hogy legalább a BPI számára speciális zászlót kell állítani ahhoz, hogy képes legyünk az belső flash-ről indulni:

root@bpi-r64:~# .\/mmc extcsd read \/dev\/mmcblk1 | grep 'PARTITION_CONFIG'\nBoot configuration bytes [PARTITION_CONFIG: 0x00]\nroot@bpi-r64:~# .\/mmc bootpart enable 1 1 \/dev\/mmcblk1\nroot@bpi-r64:~# .\/mmc extcsd read \/dev\/mmcblk1 | grep 'PARTITION_CONFIG'\nBoot configuration bytes [PARTITION_CONFIG: 0x48]

Ezután a külön boot szakaszba kell rögzíteni a preloader-t

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

A R64 gyártója (Kína) tette közzé ezt a binárist itt. Hogy mit csinál, az nem ismert (nincsenek forráskódok), de nélküle sem működik.

Tulajdonképpen ezután az image-ek elkezdenek indulni az eMMC-ről is. Ha pedig szeretnél mélyebben belemenni és nulláról image-eket készíteni, akkor mindkét esetben (SD/eMMC) még több fájlt (preloader SD-kártyához, ATF, u-boot) kell rögzítened, csak hogy eljuss a kernel betöltéséig. Ez a téma még mindig Go nyelven fejlődik., de számunkra a lényeg, hogy működik, és kész.

Jelenleg az eMMC bootot őszintén nem használom, az SD kártyák elegendőek, de elég sok időt töltöttem annak érdekében, hogy működjön, ezért legyen benne a cikkben.

Operációs rendszer választás. Armbian

Az első alkalmazási feladat — VPN elindítása, természetesen Wireguard. Azonnal kiderült, hogy a kernel oldaláról nincs összerakva, és nincsenek fejlécfájlok. Újra kellett építenem a kernelt, és a megszokás szerint x86-on összeraktam a kernel modult DKMS segítségével. Azonban az arm64-en való építés sebessége még kisebb segédprogramok esetén is kellemetlenül meglepett. Aztán még egy kernel modulra volt szükség, stb. Végül is minden, ami a kernelhez kapcsolódik, jobban jár, ha a meleg, hagyományos x86 laptopon építed, majd egyszerű másolással átköltözteted az R64-re, újraindítod és teszteled.

Más kérdés a userspace rész. Az én esetemben, Debian választásával, minden az arm64 architektúrához már rendelkezésre áll a packages.debian.org-on, és semmit sem kell újraépíteni.

Hogy ne hozzak létre egy újabb biciklit, én portolta Armbian a BPI R64-en.
Pontosabban: a userspace rész — Armbian, míg a kernel egy Frank -ból származik. A legfrissebb image-ot le lehet tölteniAz R64 szoftver részének fejlesztésével kapcsolatos minden aktivitás a itt.

. Tulajdonképpen a gyártó maga is népszerűsíteni szeretné az Openwrt alatti routert, de a német Frank fejlesztő aktivitásának köszönhetően minden funkció gyorsan bekerül a Debian kernelbe. Meglepő, de Frank aktív minden fórumban. a fórumonA munkahelyi környezet megszervezése: vezetékek

Vezetékek

Külön szeretném megemlíteni, hogyan lehet a fejlesztés/tesztelés során az SBC-t (nemcsak a BPI-t) az asztalra helyezni úgy, hogy ne kelljen Ethernet kábelt vezetni az internet forrástól a szoba/iroda másik végébe. Az a helyzet, hogy az egyik oldalon internetet kell biztosítani a készüléknek, a másik oldalon pedig a készülék belső hatékonysága is fontos, és elsősorban a Wifi.

Először úgy döntöttem, hogy beszerzek egy olcsó USB-Wifi "stickert", beledugom a BPI egyetlen portjába, és elfelejtem a vezetékeket. Ehhez beszereztem egy olcsó TP-LINK TL-WN725N USB 2.0-t, de nagyon hamar világossá vált, hogy nem fog működni: a stick működéséhez kernel driverre van szükség, ami természetesen nem volt ott (később összegyűjtöttem a szükséges RTL8XXXU drivert, de ez így is gyakorlatilag használhatatlan). Az Ethernet kábel pedig egy időre rontotta a szoba látványát.

Végül sikerült megszabadulnom a kábeltől a Tenda MW3 (Wifi mesh-rendszer) segítségével: egyszerűen az asztal alatt elhelyeztem egy kockát, és egy méteres Ethernet kábellel csatlakoztattam a BPI-t az utolsó LAN portjához. Sikerült.

Wireguard, RKN, Bird

Az egyik kívánságom, amiért a Banana PI-t használom, hogy szabadon érhessem el az RKN által blokkolt weboldalakat, különösen a Telegram és a Slack hívások működéséhez. Erről már írtak cikkeket a Habr-on: egyszer, kétszer, három.

Egy ilyen megoldás megvalósítását Ansible segítségével hajtottam végre: link.

Feltételezhető, hogy a VPS Ubuntu 18.04-en fut. A működőképességét két európai hoszton ellenőriztem: Amazon és Digital Ocean.

Tehát telepítettük a fenti Armbiant az R64-re, elérhető SSH-n keresztül a néven hm-bananapi-1 és van internet elérhetősége. Soron következő az ansible és az automatizálási szkriptek telepítése és a telepítés elindítása 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 hasonló módon kell telepíteni a VPN-t a VPS-re:

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

Itt az argumentum mindig current-vpn, a VPS neve pedig egy változóban van beállítva (ebben az esetben ez 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, és minden ilyen művelet előtt titkokat (különösen Wireguard kulcsokat) kell generálni a következő mappába ./secrets, a könyvtárnak így kell kinéznie így.

Ansible automatizálás Python segítségével

Megjegyezhető, hogy az Ansible parancsok YAML formátuma helyett Python szkriptekben van kódolva. Hasonlítsuk össze, hogyan lehet hagyományos módon elindítani a bird démonját:

- név: bird indítása
  systemd:
    név: bird
    állapot: elindítva
    engedélyezett: igen

és hogyan ugyanaz Python segítségével:

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

Az Ansible parancsok Python kódba való írása lehetővé teszi a kód újrafelhasználását, és általában véve megnyitja az összes lehetőséget a programozási nyelv számára. 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")

a funkció kódjának megtekintése install_bird().

Ez a funkció, amelynek neve pybook megvalósítva itt. A pybook dokumentációja még nem létezik, majd később kijavítom ezt a hiányosságot.

Mit gondol upstream erről.

Monitorozás. Prometheus

Összefoglalva: a Telegram jól működik, a LinkedIn és a Pornhub is rendben van, tehát a felhasználói élmény — ok. De minden elromolhat, és a kínai hardver is.

A kernel frissítések is érdekesek lehetnek: például, frissíteni akartam a kernelt 5.4-ről 5.6-ra, mert ott a Wireguard alapból benne van, nincs szükség patch-elésre... Megtörténtek a dolgok: gondosan átvittem a patch-eket 5.4-ről 5.6-ra, a kernel felépült, a VPS-ig tartó alagút pingelhető, de a bird nem tudott kapcsolódni "BGP Error" hibával... "Rémülten visszaléptem" (c) 5.4-re; a 5.6-ra való áttételt a TODO-ba tettem.

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

  • prometheus, alertmanager, blackbox_exporter — mind Dockerben
  • az értesítések a Telegram-csatornára jutnak el a metalmatze/alertmanager-bot segítségével — szintén Dockerben
  • tor a bot számára, hogy a bot értesíthesse azokat az eseteket, amikor van internet, de a Telegram mégsem működik, és a bot sem tud csatlakozni
  • alkalmazás értesítések: NodeVPNTroubles (nincs ping a VPS-ig), BirdVPNTroubles (nincs Bird session), AntifilterDownloadTroubles (hibás IP-címek letöltése), SiteTroubles (nem elérhető a szerencsétlen Telegram)
  • rendszeres értesítések, például, HostGrowingDiskReadLatency (a cheap SD card not readable)

Monitorozás telepítési példája:

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

Az auto discovery a Prometheus számára be van állítva a /etc/prometheus/auto_http mappára, itt egy példa, amely bemutatja, hogyan lehet egy hostot hozzáadni a monitorozáshoz (alapértelmezés szerint a hostok nincsenek monitorozva):

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 failover

Amihez jön, tervezem, hogy két szolgáltatóhoz csatlakozom, hogy az internet továbbra is működjön, még akkor is, ha az egyik szolgáltatónál problémák merülnek fel a hálózattal, vagy elfelejtették kifizetni az internetet, stb., és egyéb emberi tényezők.

A legfejlettebb felhasználói élmény a multi-wan témában van leírva itt a Mwan3 rendszerhez az Openwrt alatt. Ennek a megoldásnak gazdag funkcionalitása van, de a multi-wan beállítása és üzemeltetése elég körülményes. Egy példa: ha néhány weboldalra egyszerre két IP-címmel érkezünk, az nem biztos, hogy kedvezően érinti őket, és megállnak a működésükkel => "az internet nem működik".

Figyelembe véve ezt a tapasztalatot úgy döntöttem, hogy a multihoming egyelőre nem prioritás, csak a failover. Bár úgy tűnik, a legújabb linux verziókban mindez egyetlen parancssal működnie kellene:

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

Tehát, hogy ne legyen egyetlen hibapont, két BPI-t használunk, mindegyiket egy-egy szolgáltatóhoz csatlakoztatunk, összekötjük őket és a közöttük lévő kapcsolatot dinamikus irányítással biztosítjuk a bird/OSPF segítségével.

Ezenkívül mindenhol ugyanazt az IP-címet hirdetjük, ha a szolgáltatás elérhető (internet, DNS). Tehát az alapértelmezett útvonalat nem magunk állítjuk be, hanem a bird segítségével. Ezt a megoldást láttam itt .

Ezt a funkciót még nem valósítottam meg, a alattomos koronavírus is közbeszólt (nem minden érkezett meg az aliexpressről; egy másik internetes bolt, a Layta, azt ígérte, hogy egy héten belül szállít, de már több mint egy hónap eltelt; a második szolgáltató nem tudta a kábelt behúzni a karanténig, csak egy lyukat fúrt a falba a kábelnek).

Hogyan rendeljem meg az R64-et

A maga lapja az hivatalos boltban SinoVoip.
Érdemes lenne azonnal rendelni:

  • tápegység + jelezd a csatlakozó EU vagy USA szabványát
  • hőleadó: radiátorok/ventilátorok; mert a CPU is felmelegszik, és a switch chip is
  • antennát a wifi-hez, például

Van egy sajátosság – a szállítási költség egy bizonyos idő után aránytalanul magas lett az hivatalos boltban. Judy Huang menedzser azt állította, hogy nincs hiba, és választható az ePacket 5 dollárért, de láttam, hogy Oroszország számára csak EMS áll rendelkezésre >33 dollárért. Ez kellemetlen, de nem kritikus. Valójában ha bármely más országot választunk a szállításhoz (átmentem az összes kontinensen), a szállítás körülbelül 5 dollár lesz. Oroszfóbok?.. De később megtudtam, hogy Franciaországban is a szállítás ára körülbelül 30 dollár, és megnyugodtam.

Végül Judy azt javasolta, hogy rendeljem meg, de ne fizessek (hint: kevésbé tegyek a kártyára, hogy automatikusan a fizetés ne menjen át); írjak neki, és ő csökkenti a szállítási díjat normálra. Siker.

Problémák

Nem minden működik még tökéletesen.

Teljesítmény

Az Ansible=Python parancsok lassan hajtódnak végre, még a feleslegesek is 20-30 másodpercig tartanak; sokkal tovább, mint az x86-os laptopon. Eleinte elég gyorsan, ~3 másodperc alatt futnak le, majd hirtelen lelassulnak. Lehetséges, hogy a CPU felforrósodása (throttling) miatt történik ez. A Go-ban íródott kód is sokáig fut:

# запрос метрик для прометея из 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 az Armbian-on körülbelül egy nap múlva leáll, és ezt írja:

sa@bananapir64:~$ dmesg | grep -E 'mt7622_wmac.*timeout'
[470303.802539] mt7622_wmac 18000000.wmac: üzenet 38 (seq 3) időtúllépés
[470314.042508] mt7622_wmac 18000000.wmac: üzenet 50 (seq 4) időtúllépés
...

Csak a restart segít. Tovább kell nyomozni.

Ethernet

Az Ethernet működik, de körülbelül egy nap múlva a csomagok (DHCP) az R64-től leállnak.
A felület újraindítása segít:

ifdown br0; sleep 30; ifup br0

Az illesztőprogram új, a kernelbe még nem került be, remélem, a kínai Landen Chao kijavítja.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster