Skip to content

OpenWrt - LXC Container

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

    180017fe-f3cc-45b5-a4dd-4b1b4c58afd4-grafik.png

    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.

    3de9c53b-f651-42a2-84c7-3dcf5a755de8-grafik.png

    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,

  • 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,

    @FrankM

    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.

  • @FrankM

    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.

    @Dude Danke für die Tipps. Die Tools waren mir bekannt, auch wenn ich sie noch nicht selber getestet habe. Man kann ja nicht alles ausprobieren 🙂

    Unbound bot sich hier einfach als Test für die LXC Container an.

  • NanoPi R5S - Software

    NanoPi R5S
    3
    1
    0 Stimmen
    3 Beiträge
    257 Aufrufe
    FrankMF
    Die Samba Freigaben auf meinem Manjaro Desktop zu mounten waren ein Abenteuer. Aber, man findet fast immer eine Lösung im Netz, wenn man die richtigen Worte zum Suchen findet. Da das ganze jetzt doch etwas länger gedauert hat, als ich erhofft hatte, werde ich das Problem mal morgen ausführlich vorstellen. Weil, das fand ich mal richtig spannend Jetzt läuft aber alles so, wie ich es brauche.
  • NanoPi R5S - Nicht kaufen!?

    NanoPi R5S
    11
    0 Stimmen
    11 Beiträge
    615 Aufrufe
    FrankMF
    Kurzes Update Der 2. NanoPi R5S ist hier eingetroffen, diesmal nur die Platine. Mal kurz angeschlossen und das vorinstallierte FriendlyWrt (eMMC) startet. Bildschirmausgabe = Konsole vorhanden. Bei Anschluss meines Notebooks an den richtigen LAN Port kommt auch das Webinterface. Mein Idee zur 1. Platine, ich könnte die falsche SD-Karte eingesteckt haben, kann man mit falschen dtb eine Platine schrotten!? Ich kann mich erinnern, das sie ziemlich heiß geworden ist. Oder sie war von Anfang an Schrott!? Ein wenig schwierig mit der Chinesen Garantie
  • NanoPi R5S - Unterwegs

    NanoPi R5S
    7
    0 Stimmen
    7 Beiträge
    295 Aufrufe
    FrankMF
    Das ging nicht so, wie ich mir das so einfach vorgestellt hatte, aber na gut man lernt nie aus. Die OpenWrt Konfiguration hat doch ihre Stolperstellen. Aber, aktuell läuft es und ich denke ich habe auch verstanden, was ich die ganze Nacht falsch gemacht habe [image: 1660384295888-c337a5a8-930f-44c3-860e-7e4810f798c1-grafik.png] Docker Container laufen jetzt und meine Netzwerkkonfiguration ist auch auf der Kiste. Zu den ganzen Feinheiten und Problemen schreib ich noch was..
  • NanoPi R4S - OpenWrt upgraden !?

    NanoPi R4S
    4
    3
    0 Stimmen
    4 Beiträge
    577 Aufrufe
    FrankMF
    Ich schrieb ja oben über Daten Sichern bevor man was macht...... Ok, danach war die Installation lauffähig, aber das Webinterface kaputt. Kryptische Fehlermeldung, die ich auch mit Google nicht fixen konnte. Naja, es war nicht so schwer da ich ja noch einen R4S mit identischer Konfiguration hatte. SD_Karte getauscht und weiter geht's.... Aber!! Warum? Ich musste ganz schön lange suchen, bis ich heraus fand das es mittlerweile eine neue Version als Release Candidate gibt. https://openwrt.org/releases/21.02/notes-21.02.0-rc1 Diese Version habe ich dann installiert und das Upgrade ist gescheitert. Da ich auf der alten Installation auch schon eine ganze Menge getestet hatte und es evt. auch vermurkst hatte, war es ja nicht so verkehrt mal was frisches aufzusetzen. Kurz meine Konfigurationsdateien kontrolliert und nach kleineren Korrekturen und Reboot lief alles wieder wie vorher. Diesmal habe ich mir die SD-Karte als Image gesichert. Nur für den Fall, das ich das mal dringend brauche. Es bleibt weiterhin nicht ganz einfach eine OpenWrt Installation aktuell zu halten. Aber so einmal im Jahr kann man sich ja die Arbeit machen.....
  • NanoPi R4S - OpenWrt kompilieren Teil 2

    Angeheftet NanoPi R4S
    5
    5
    0 Stimmen
    5 Beiträge
    427 Aufrufe
    FrankMF
    Kurzes Update. Der R4S im Alugehäuse, der hier als Router / Firewall rumliegt, läuft jetzt seit 44 Tagen einwandfrei. [image: 1615410154967-98ef6d29-e822-4847-a038-f02a027fb6fe-grafik.png]
  • OpenWRT - Zonen

    Verschoben OpenWRT & Ubiquiti ER-X
    2
    3
    0 Stimmen
    2 Beiträge
    602 Aufrufe
    FrankMF
    Es ist was heller geworden [image: 1610188645165-7b86e97c-31a5-44b6-809f-25d9d1c2ee4a-image.png] Die besagte Forward Regel [image: 1610188840619-zonen.png] Diese Forward Regel zieht erst dann, wenn es mehrere Interfaces in einer Zone gibt. Aus der Doku INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone. OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone. FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone. Das heisst nun, das ein Forwarding zwischen zwei Zonen immer eine spezifische Regel unter Traffic Rules benötigt. Forwarding between zones always requires a specific rule. Somit ist ein Forwarding zwischen zwei Zonen in den Standard Einstellungen nicht erlaubt. Das kann ich hier auch so bestätigen. Das ist ja auch das was ich mit meiner "DMZ"-Zone erreichen möchte. Kein Zugriff auf LAN. Unter Zone ⇒ Forwardings kann man jetzt sehen, das das Forwarding von LAN in Richtung WAN und DMZ erlaubt ist. WAN ist logisch, sonst komme ich ja nicht ins Internet. DMZ habe ich eingestellt, damit ich auch Teilnehmer im DMZ Netz erreichen kann, wenn ich da mal ran muss. [image: 1610189307657-8a548c29-8bc5-4074-8099-66460bcea9a8-image.png] Stelle ich das jetzt so ein. [image: 1610189398985-dca8b393-f613-4cab-a377-ffbc2bb8ddf5-image.png] Dann kann ich von der DMZ Zone aus das LAN erreichen. Aha, so langsam verstehe ich Quelle: https://forum.openwrt.org/t/firewall-zones-and-settings/84369
  • OpenWRT - Firmware Selektor

    Verschoben OpenWRT & Ubiquiti ER-X
    1
    1
    0 Stimmen
    1 Beiträge
    244 Aufrufe
    Niemand hat geantwortet
  • Ubiquiti ER-X - Firewall

    Verschoben OpenWRT & Ubiquiti ER-X
    1
    2
    0 Stimmen
    1 Beiträge
    277 Aufrufe
    Niemand hat geantwortet