Raspberry Pi 4 // OpenVPN

  • Hallo zusammen,

    ich verzweifele gerade ein wenig am Upgrade von Raspbian und / oder der Model 4... Vielleicht kann mir jemand helfen.

    Situation: Ich habe vor ein paar Jahren unter Jessie transparente VPN-Tunnel-Endpunkte gebaut. Die liefen auch im Grunde ohne Probleme, allerdings war die sichere Stromversorgung ab und an ein Problem. Es konnte also passieren, das der Strom ausfiel - und das resultierte ab und an in korrupten SD-Karten.

    Nun wollte ich mir das Overlay-Filesystem zunutze machen und habe mir 2 RP 4 Model B besorgt. Die konnten mit meiner Jessie-Version natürlich nichts anfangen. Also habe ich zuerst auf Stretch und dann auf Buster aktualisiert. Das zog sich recht lange hin, funktioniert unterm Strich aber ohne Fehlermeldung. Dann habe ich die SD-Karte in den 4er gesteckt, der bootet dann aber mit dem Regenbogen-Vollbild (vorher war eine Meldungsfenster "This board requires newer software"). boot_delay steht auf 30

    Testweise habe ich die SD-Karte in einem RP 3 Model B+ getestet, da läuft sie auch durch. Da werde ich mit dem 1GB Arbeitsspeicher aber wohl nicht auskommen...


    Ich bin ratlos was es sein kann. Ein Original-Netzteil war nicht zu bekommen und ich habe keines mehr. Ich habe einen Schnellader mit 2,4A, mein Oneplus Nord WarpCharger mit 2,1 und eine Powerbank mit 2,1A versucht. Was mich stutzig macht ist, dass das Ding mit einem falschen Image durchaus ein Bild zeigt, mit dem Image aber nicht. Es hängen keine weiteren Geräte am Pi, nichtmal Tastatur oder Maus. Ein zweiter Versuch mit einem anderen Image und einer anderen Karte war seltsamerweise erfolgreich. Blöde ist, eine Intenso-Billo-Karte tut es, eine Sandisk Ultra leider nicht. Bisher habe ich nie Probleme mit den Dingern gehabt, aber die 4er scheinen mich nicht zu mögen.


    Kann die Karte das Problem sein? Es geht um diese Karte (Affiliate-Link). Oder hat vielleicht jemand eine andere Idee?


    Danke!

    Matze

  • Entgegen anderslautender Aussagen hatte ich noch nie Probleme, die auf einen bestimmten Typ SD-Karte zurückzuführen war. Gut, ich verwende nur namhafte SD-Karten (Sandisk, Kingston, Samsung, Intenso) aus vertrauenswürdigen Läden , keine obskuren China-Fakes. Daher glaube ich nicht, dass es an der verlinkten SD-Karte liegt (wenn sie auch wirklich aus dieser Quelle stammt).


    Probiere anstatt eines aufwändigen Updates Jessie-->Stretch-->Buster(-->Bullseye) lieber mal, das aktuelle Image von der Foundation herunterzuladen und auf die SD-Karte (z.B. mit dem Raspberry Pi Imager der Foundation) zu flashen.


    Netzteil:

    Bei Handyladegeräten (Zitat: "... Charger") ist das Mysterium™ aller Ausreden zum Trotz ;) nicht zu vermeiden! Am Originalnetzteil führt in Fällen wie Deinem kein Weg vorbei!


    (so nix für ungut, jetzt bin ich meinen üblichen Klugschiss mal wieder losgeworden :lol: )

  • Nachtrag: Wenn du ein aktuelles OS hast, kannst du das OS, das EEPROM und die Firmware des Pi4 auch gleich noch mit sudo apt-update && apt dist-upgrade auf den neuesten Stand bringen.


    Netzteil:

    Bei Handyladegeräten (Zitat: "... Charger") ist das Mysterium™ aller Ausreden zum Trotz ;) nicht zu vermeiden! Am Originalnetzteil führt in Fällen wie Deinem kein Weg vorbei!

    Das kann man meist so unterschreiben. Man kann aber auch Glück haben.

    So wie bei meinem Handyladegerät, da läuft der Pi4 mit Touchscreen, Maus und Tastatur problemlos.

  • Es kann auch an einer zu kleinen Boot-Partition liegen. Ab Buster sind 256 MB erforderlich, damit alle Binarys für diverse Prozessoren/SoCs Platz haben.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Also habe ich zuerst auf Stretch und dann auf Buster aktualisiert.

    Das wird nicht offiziell von der Foundation unterstuetzt und nicht empfohlen. Es kann klappen - aber eben auch Probleme hervorrufen die Du sonst nicht haettest. Und dann suchst Du Dir den Wolf ... Ich upgrade deshalb nie sondern installiere immer das neue OS Release von Scratch. Das ist zwar i.d.R. etwas aufwaendiger wenn alle moeglichen installierten Applikationen und Dienste wieder neu aufgesetzt und konfiguriert werden muessen. Aber man hat nicht das Risiko Probleme zu bekommen die man sonst nicht haette :)

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."

    Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert =O Bei mir tut das raspiBackup automatisch ;)

  • Ok, ich lade mir mal auf eine Karte ein frisches OS und versuche das openVPN-Gelumpe identisch draufzubekommen. Bis die neuen Netzteile am Sonnabend kommen kann ich da ja schon mal eine Testumgebung basteln ;) Und dann darf ich das Gehäusedesign auch noch ändern, weil´s ja usb-c sein muss *grr*


    Mal sehen wie sich das entwickelt...

  • Erwartungsgemäß geht es nicht mehr. Nachdem meine Anleitung für OpenVPN nicht mehr passt habe ich pivpn versucht. Naja, ich ziehe mir jetzt noch einmal das Image frisch auf die Karte. Offensichtlich hat pivpn meine Netzwerkschnittstellen verändert, da ist jetzt keine mehr :i


    Hat jemand eine Seite mit einer aktuellen Anleitung für OpenVPN die funktioniert?

  • Hat jemand eine Seite mit einer aktuellen Anleitung für OpenVPN die funktioniert?

    Als ich noch OpenVPN u. a. auch mit meinen PIs benutzt habe, bin ich immer wie im Wiki von UU vorgegangen:

    https://wiki.ubuntuusers.de/OpenVPN/

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Vielen Dank rpi444, das hat prinzipiell schon mal funktioniert. Der Tunnel wird aufgebaut, nur Daten gehen keine drüber. Ich bekomme die Meldung


    Code
    WRR2021-11-22 18:31:29 us=721849 antenne1/192.168.101.64:48514 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> antenne1/192.168.101.64:48514
    2021-11-22 18:31:30 us=723033 antenne1/192.168.101.64:48514 MULTI: Outgoing TUN queue full, dropped packet len=17
    R2021-11-22 18:31:36 us=10420 antenne1/192.168.101.64:48514 MULTI: Learn: 02:00:50:b6:28:0f@0 -> antenne1/192.168.101.64:48514
    2021-11-22 18:31:37 us=11580 antenne1/192.168.101.64:48514 MULTI: Outgoing TUN queue full, dropped packet len=71


    Die Meldung TUN quere full kommt sobald Daten fließen wollen - also PING genügt.


    Meine Server-Konfiguration ist im großen und ganzen vom alten übernommen


    Ich finde meinen Fehler nicht, und die gefundenen Lösungsansätze konnten mir auch nicht helfen.

    Der Client bricht dann nach relativ kurzer Zeit entnervt ab...

    Code
    2021-11-22 17:28:04 us=575901 Preserving previous TUN/TAP instance: tap0
    2021-11-22 17:28:04 us=575941 Initialization Sequence Completed
    WWWWWW2021-11-22 17:29:04 us=705045 [vpnserver] Inactivity timeout (--ping-restart), restarting
    2021-11-22 17:29:04 us=705626 TCP/UDP: Closing socket
    2021-11-22 17:29:04 us=705887 SIGUSR1[soft,ping-restart] received, process restarting

    Da scheint noch irgendwas zu fehlen was früher nicht notwendig war - oder ich finde es nicht mehr.


    Hat jemand dazu eine Idee?


    Nachtrag: Die Meldung variiert...

    Code
    R2021-11-22 18:50:04 us=424090 antenne1/192.168.101.64:48558 Can't learn ff:00:50:b6:28:0f@0: network is a multicast address
    2021-11-22 18:50:04 us=424198 antenne1/192.168.101.64:48558 MULTI: bad source address from client [ff:00:50:b6:28:0f@0], packet dropped
    R2021-11-22 18:50:05 us=444488 antenne1/192.168.101.64:48558 Can't learn ff:00:50:b6:28:0f@0: network is a multicast address
    2021-11-22 18:50:05 us=444695 antenne1/192.168.101.64:48558 MULTI: bad source address from client [ff:00:50:b6:28:0f@0], packet dropped

    Edited once, last by matahari ().

  • matahari

    Changed the title of the thread from “Upgrade auf Raspberry Pi 4” to “Upgrade auf Raspberry Pi 4 // OpenVPN”.
  • Da scheint noch irgendwas zu fehlen was früher nicht notwendig war - oder ich finde es nicht mehr.

    Wie sind auf Server und Client, die Ausgaben von:

    Code
    ip a
    route -n
    arp -av
    sudo iptables -nvx -L
    sudo iptables -nvx -L POSTROUTING -t nat

    , wenn openvpn und das bridge-Script gestartet sind.

    BTW: Gibt es einen bestimmten Grund, warum Du ethernet-bridging mit OpenVPN benutzt?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Ja, die Geräte die ich verbinde reden Broadcast. Das kann ich leider nicht ändern. Ich muss also auf beiden Seiten das gleiche Netz haben.


    Hier die Ausgaben:

    iptables gibt nichts, bei der alten Version habe ich etwas in sudo iptables -nvx -L POSTROUTING -t nat, das stand

    Code
    Chain POSTROUTING (policy ACCEPT 89 packets, 7301 bytes)
        pkts      bytes target     prot opt in     out     source               destination
           0        0 MASQUERADE  all  --  *      eth0    10.0.0.0/8          !10.0.0.0/8

    Ich kann mich daran nicht mehr erinnern, allerdings kommt mir "out eth0" seltsam vor - aber wie gesagt, das war auf dem alten funktionierenden RP 2 Model B...

    Physikalisch sieht es so aus, das die onboard-Netzwerkkarte per DHCP mit dem Internet verbunden ist und eine USB-Netzwerkkarte an die beiden Geräte angeschlossen ist die kommunizieren sollen. Das lokale Gerät hat eine feste IP-Adresse 10.10.10.10. Wenn der Tunnel steht, also der Server kann den Client pingen, dann wird noch folgendes Python-Script gestartet

    Code
    os.system("sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 10.10.10.10:80")
    os.system("sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.10.10.10:80")
    os.system("sudo iptables -t nat -A POSTROUTING -p tcp -d 10.10.10.10 --dport 80 -j MASQUERADE")

    Das war bisher aber noch nicht der Fall :(

  • Ja, die Geräte die ich verbinde reden Broadcast. Das kann ich leider nicht ändern. Ich muss also auf beiden Seiten das gleiche Netz haben.


    Hier die Ausgaben:

    Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.


    BTW: Weil ich keinen Einfluss auf die Subnetze der Clients (peers) habe, benutze ich WireGuard.

    Als noch kein WireGuard gegeben hat, habe ich vtun mit tap-Interfaces benutzt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Code
    Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.

    Öhm, das überfordert mich gerade... Bitte wie mache ich das?


    Im Grunde ist es mir egal ob ich openvpn oder irgendetwas anderes nehme. Ich habe die Geräte vor knapp 5 Jahren gebaut, da hat sich die Frage nicht gestellt. Wenn es für Wireguard ein einfacheren Installationsleitfaden gibt kann ich auch wechseln.

  • Code
    Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.

    Öhm, das überfordert mich gerade... Bitte wie mache ich das?

    Auf dem Server:

    Code
    sudo arp -i br0 -d 10.10.10.252
    sudo arp -i br0 -s 10.10.10.252 00:50:b6:28:0f:1b
    arp -av

    Auf dem Client:

    Code
    sudo arp -i br0 -s 10.10.10.253 00:50:b6:28:14:b6
    arp -av
    ping -c 3 10.10.10.253

    Installiere auf Client und Server:

    Code
    sudo apt update
    sudo apt-get install iputils-arping
    sudo dpkg --configure -a

    Wenn der Ping nicht funktioniert, dann versuch den arping auf dem Client mit:

    Code
    sudo arping -c 3 -I br0 10.10.10.253
    ping -c 3 10.10.10.253

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Ändert nichts. Kommt auf dem Server weiterhin

    Code
    R2021-11-22 21:27:38 us=426003 antenne1/192.168.101.64:36000 Can't learn fb:0a:e7:ed:c6:3e@0: network is a multicast address
    2021-11-22 21:27:38 us=426127 antenne1/192.168.101.64:36000 MULTI: bad source address from client [fb:0a:e7:ed:c6:3e@0], packet dropped
    R2021-11-22 21:27:39 us=519210 antenne1/192.168.101.64:36000 MULTI: Outgoing TUN queue full, dropped packet len=71
    R2021-11-22 21:27:39 us=607231 antenne1/192.168.101.64:36000 Can't learn fb:0a:e7:ed:c6:3e@0: network is a multicast address
    2021-11-22 21:27:39 us=607332 antenne1/192.168.101.64:36000 MULTI: bad source address from client [fb:0a:e7:ed:c6:3e@0], packet dropped
    R2021-11-22 21:27:50 us=717483 antenne1/192.168.101.64:36000 MULTI: Outgoing TUN queue full, dropped packet len=17

    Ich verstehe das nicht. Selbst ohne irgendeine Konfiguration müssten sich Client und Server doch erreichen...

  • Ändert nichts. Kommt auf dem Server weiterhin

    Ich verstehe das nicht. Selbst ohne irgendeine Konfiguration müssten sich Client und Server doch erreichen...

    Dann poste von Server und Client, die Ausgaben von:

    Code
    ip a s br0
    route -n
    arp -av

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Sehr gerne


    Server

    Client

  • Client

    Code
    5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
        link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
        inet 10.10.10.252/24 brd 10.10.10.255 scope global br0
          
    ? (10.10.10.254) at <incomplete> on br0
    ? (10.10.10.252) at 00:50:b6:28:0f:1b [ether] PERM on br0

    Auf dem Client ist ein Fehler mit dem arp-cache-Eintrag für das br0-Interface.

    10.10.10.252 ist doch die IP-Adresse vom Client. Auf dem Client ist kein arp-cache-Eintrag für den server, oder?

    BTW: Welches Gerät hat die IP 10.10.10.254?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden