Posts by Der_Imperator

    Das Tutorial ist 8 Jahre alt, das von Chip 5 Jahre und funktioniert so nicht mehr unter Raspbian Buster.


    Es funktioniert immer noch genau so !


    Code
    pi@raspberrypi:~ $ sudo apt install proftpd


    Config Datei öffnen:

    Code
    pi@raspberrypi:~ $ sudo nano /etc/proftpd/proftpd.conf


    An das Ende anfügen :

    Apache Configuration
    DefaultRoot ~
    AuthOrder mod_auth_file.c mod_auth_unix.c
    AuthPam off
    RequireValidShell off
    AuthUserFile /etc/proftpd/ftpd.passwd


    In das Proftp Verzeichnus wechseln


    Code
    pi@raspberrypi: $ cd /etc/proftpd


    Einen Virtuellen User anlegen :


    Code
    pi@raspberrypi:/etc/proftpd $ sudo ftpasswd --passwd --name peter --uid 33 --home /var/www/html --shell /bin/false


    Neu starten :


    Code
    pi@raspberrypi:~ $ sudo systemctl restart proftpd.service


    Testen :




    Getestet auf einem PI :

    pi@raspberrypi:~ $ sudo uname -a

    Linux raspberrypi 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux

    pi@raspberrypi:~ $ cat /etc/debian_version

    10.6

    pi@raspberrypi:~ $

    es ist immer wieder erstaunlich. macht man ein neuen thread auf mekert jemand das es dazu bereits Themen gibt und man bitte die suche nutzen soll. macht man das erhält man die Meldung mach ein thread auf :)

    Du hast dies falsch verstanden.

    Den Hinweis dass es bereits Themen gibt und du suchen sollst schlägt dir vor dort zu schauen ob eine Lösung für dich passt.

    Passt keine Lösung, mach einen neuen Thread zu deinem Problem auf.


    Und schau vorher wie alt die Anleitung ist. In den letzten Releases hat sich einiges getan. Vieles geht jetzt anders als gewohnt/im Tut beschrieben.

    Sieht doch richtig aus.

    Dort steht AUTOSTART="all", meint dass alle *.conf in /etc/openvpn gestartet werden.

    Ich hatte schon mal eine Version wo in der Datei AUTOSTART="none" gesetzt war. Daher die Frage.

    Dazu braucht es kein iptables, das kann OpenVPN von Haus aus.


    Was du ausschalten möchtest nennt sich Split Tunneling.
    Du möchtest allen Traffic über das VPN routen, also keinen Split Tunneling.
    Dazu reicht ein
    push "redirect-gateway def1"
    in der OpenVPN Server Config.
    Damit wird jedweder Traffic über das VPN geroutet.


    Die ganze bisherige Diskussion, ob man solche User anlegen soll/kann/darf geht am Problem-Kern vorbei.


    So sieht das aus.
    Systemd muss bei einem User mit führenden Ziffern abbrechen und nicht den User ignorieren und den Dienst als Root starten als wäre gar kein User angegeben.
    Dies ist der Bug, welcher auch in einem gesonerten Report behandelt wird.

    Wo gibst die die Adresse ein, in deinem (W)LAN oder an einem fremden Internetanschluss? Mach mal einen Portscan aus dem Internet.


    Evtl. kann dein Router kein NAT-Loopback?


    Richtig.
    Die Speedports können nicht aus dem LAN herraus über die Public IP erreicht werden.
    NAT-Loopback (auch Hairpin-Nat) fünktionieren nur auf einigen Modellen, der W724V konnte dies mit einigen FW Versionen.


    Wer einen Speedport sein eigen nennt sollte das DynDNS über das Handynetz testen.



    /etc/crontab ist der Systemweite Crontab.
    Hier fehlt einfach der User welcher den Befehl ausführt.
    Bei Root kann natürlich sudo entfallen

    Code
    0-59/5 * * * * root bash /home/pi/camera/camera.sh >> /home/pi/camera/camera.log


    oder als www-data :

    Code
    0-59/5 * * * * www-data bash /home/pi/camera/camera.sh >> /home/pi/camera/camera.log



    btw: Statt 0-59/5 reicht auch ein */5

    Naja, es muss ja nicht unbekannt sein. Betr. die Pakete für 10.8.0.xxx, kann man auch eine definierte Route/gw (im Client/Server) konfigurieren und dann ist für diese Pakete, die default route (d. h. der Router) nicht (mehr) zuständig. Klar kann man das auch so machen wir Du es beschreibst (d. h. mit dem Router). Aber nur dann, wenn man auch Zugang zum Router hat.


    So geht routing nun mal.
    Wenn man zwei Netze miteinander verbinden möche, ob direkt oder über einen Tunnel, muß man sich wohl oder übel mit dem Routing auseinander setzen. Vorschläge die Routingeinträge der Clienten zu manipulieren halte ich für gelinde gesagt strafbar. Das funktioniert so lange bis Hänschen mit seinem Notebook zu Omma kommt und dort mal eben nach dem rechten sehen will. Dann zeigt die Route des Netz auf seinen PI daheim. Und dann ? Wieder manuell die Routen des Clienten ändern ?


    Und wenn der Teleplaste-Provider-Router keinen Zugriff auf Routingeinträge zulässt sollte man sich mal überlegen ob man nicht mal ein paar Euro in einen vernünftigen Router investiert.
    Wenn du soweit bist Netze zu verbinden hast du eh die Lust an dem Teleplaste-Provider-Router verloren und wünscht dir ne Fritzbox.


    Haste ne Fritzbox brauchste die PI nicht mehr, da geht VPN klicki-klicki zwischen zwei Boxen.


    Willste das dennoch des Interesses wegen mit dem PI machen, dann beschäftige dich gefälligst auch mit Routing.

    Naja, dein Server und Client sind an einem Router in einem LAN.


    Eben nicht.
    Der Server ist im 192.168.xx.xx und der VPN Client im 10.8.0.xx.


    Wenn jetzt der Router 192.168.xxx.1 ein Paket für 10.8.0.xxx erhält, woher soll der wissen das sich der Host hinter dem PI befindet wenn es keine Route dahin gibt ?
    Alles was unbekannt ist wird vom Router zum Default Gateway geroutet.


    Am Beispiel des Paketverlauf eines Ping.
    Ping von 10.8.0.100 (Ein VPN CLient) zu 192.168.0.200 (Ein PC im Netzwerk)


    10.8.0.100 -> 10.8.0.1(VPN Server) -> 192.168.0.100(PI LAN) -> 192.168.0.200 (PC LAN).
    Jetzt das Echo
    192.168.0.200 -> 192.168.0.1 -> Default Gateway


    Der PI hat ein Bein in beide Netzen. D.h. 10.8.0.0 & 192.168.0.0 sind local connected und es kann geroutet werden.
    Der PC (192.168.0.200) kennt das 10.8 nicht und schickt deshalb alle Pakete an das Def.Gateway, die 192.168.0.1.
    Die 192.168.0.1 kennt das 10.8 nicht und schickt die Pakete zum Def.Gateway, ins Internet.


    Und so kommt das Echo nie an.



    Code
    listen-address=172.30.0.10


    Dann Antwortet der DNS auch auf Anfragen anderer Hosts.

    Für die VPN-Verbindung zwischen Client und Server, solltest Du den Server nicht mit "client-to-client" konfigurieren.


    client-to-client besagt dass die Clients untereinander kommunizieren dürfen.

    Quote

    --client-to-client
    Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface.


    When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.