Nachdem ich gestern ziemlich viel Zeit erfolglos verballert habe, einen Docker Container in OenWrt über die WAN-Seite zu erreichen, bin ich heute mal wieder über einen Kommentar gestolpert, der mich neugierig macht.
That is a good reason :slight_smile: I myself moved to LXC containers: they just work and do not require messing with firewall rules.
Quelle: https://forum.openwrt.org/t/pihole-in-a-docker-no-internet-access/131035/33
Ok, der Begriff LXC ist mir nicht neu, das kenne ich schon von der Proxmox. Aber, ob das auch auf dem NanoPi R5S läuft 
Warum brauche ich das denn überhaupt?
Ich habe wie wohl viele, eine Fritzbox, damit fängt mein Netzwerk an. Dahinter trenne ich das in verschiedene Netzwerke auf, je nachdem wie viel ich den Geräten vertraue.
Dazu dient mir aktuell eine OpenWrt Installation, die auf einem NanoPi R5S läuft und mit der ich sehr zufrieden bin.
Aktuell läuft dort auch ein Docker Container, der mir mein DokuWiki spiegelt.
Ich nutze als Werbeblocker für mein Handy einen unbound mit entsprechendem Script. Das lief mal auf meiner Proxmox, aber die ist ja durch die hohen Energiekosten dem Rotstift zum Opfer gefallen 
Ein Dienst, den ich wieder in meinem Netz haben möchte, läuft aktuell auf irgendeinem Hetzner Server. (Vorsicht Werbung)
Also mal die Anleitung dazu bei OpenWrt rausgesucht. Nachdem ich geprüft hatte ob das Meiste installiert war, habe ich die paar fehlenden Tools nachinstalliert.
Das bekommt ihr auch hin, so schwer war das nicht 
Ich habe das dann wie in der Anleitung mal alles nachgemacht und siehe da, der erste LXC Container lief.
Ein wenig herum gespielt und für gut befunden. Sollte gut nutzbar sein um den Unbound laufen zu lassen.
In dem Debian 11 Bullseye den unbound und mein Script installiert, ein paar kleine Anpassungen und dann ausprobiert. Hmm, der Dienst war nicht erreichbar, bzw. mit telnet bekam ich eine funktionierende Verbindung mit dig aber keine Antwort!?
Also mal auf dem LXC Container nachgesehen
netstat -tulpn | grep 53
Da lauscht doch noch ein anderer Dienst auf Port 53, kein Wunder das ich den unbound nicht erreichen kann.
service systemd-resolved stop
systemctl disable systemd-resolved.service
Danach hing nur noch der unbound am Port 53. Nun ging es an erste Tests. Der LXC Container hat ein voll funktionierendes Netzwerk, mit ipv4 und ipv6.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: eth0@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:ff:dd:bb:cc:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.3.19/24 brd 192.168.3.255 scope global dynamic eth0
valid_lft 37254sec preferred_lft 37254sec
inet6 2a02:908:xxxx:xxxx::1ff/128 scope global dynamic noprefixroute
valid_lft 6131sec preferred_lft 2531sec
inet6 fd00:ab:cd:2::1ff/128 scope global dynamic noprefixroute
valid_lft 42132sec preferred_lft 2531sec
inet6 fd00:ab:cd:2:2ff:ddff:febb:cc02/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 2a02:908:xxxx:xxxx:2ff:ddff:febb:cc02/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6132sec preferred_lft 2532sec
inet6 fe80::2ff:ddff:febb:cc02/64 scope link
valid_lft forever preferred_lft forever
Da er in meinem LAN hing, konnte ich erste Tests von meinem Haupt-PC aus durchführen.
[frank-ms7c92 ~]# dig @192.168.3.19 linux-nerds.org
; <<>> DiG 9.18.5 <<>> @192.168.3.19 linux-nerds.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49432
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;linux-nerds.org. IN A
;; ANSWER SECTION:
linux-nerds.org. 600 IN A 23.88.100.106
;; Query time: 323 msec
;; SERVER: 192.168.3.19#53(192.168.3.19) (UDP)
;; WHEN: Thu Sep 08 15:45:20 CEST 2022
;; MSG SIZE rcvd: 60
Dazu muss der unbound natürlich auch so konfiguriert sein, das er die Anfragen auch annimmt und drauf antwortet. Stichwort:
access-control: 192.168.3.0/24 allow
Sehr gut, jetzt musste ich den nur noch durch den NanoPi R5S hindurch erreichen, also WAN -> LAN. Dazu muss man in der Firewall einen Port Forward einrichten.
Hoppla, braucht noch einen vernünftigen Namen Danach konnte ich den Unbound durch WAN -> LAN erreichen. Perfekt!
In meiner Wireguard Einstellung angepasst und mein Werbeblocker ist wieder ordentlich in meinem Netz.
Damit habe ich jetzt mit Docker Container auf dem OpenWrt rumgespielt und mit LXC Containern. Mir gefällt im Moment LXC besser, mal sehen ob das in 14 Tagen auch noch so ist.
Heute Morgen beim 
noch schnell probiert, ob der Container automatisch startet, macht er nicht.
Aber in der oben verlinkten Anleitung ist auch das dokumentiert.
opkg install lxc-auto lxc-autostart
uci show lxc-auto
uci add lxc-auto container
uci set lxc-auto.@container[-1].name=myLMS
uci set lxc-auto.@container[-1].timeout=30
uci show lxc-auto
uci commit lxc-auto
Danach startet der Container automatisch, wenn OpenWrt neugestartet wird,
Hallo Frank,
alternativ kann man auf dem R5S auch AdGuard laufen lassen läuft nativ ohne Container nutze das bzw. teste das momentan mit SmartDNS als Server als Cache, bisher 1Monat am laufen DNS requests werden so im schnitt mit 2ms abgearbeitet (gefilter usw..)
um nur werbung zu blocken gibts auch einen einfachen adblocker im openwrt.