07.06.2015, aktualisiert um 14:19:23 Uhr

3422

Autostart (Debian) funktioniert nicht

Hallo Forum,

habe ein kleines Problem mit dem Raspberry Pi 2 (OSMC),
Per SSH habe ich über das System (Debian) OpenVPN installiert und die VPN-Verbindung funktioniert, diese lasse ich per Autostart starten.

Wenn man das Gerät vom Strom getrennt wird, wird keine VPN-Verbindung mehr hergestellt wenn das Gerät wieder eingeschaltet wird.
Hier muss man manuel die Verbindung herstellen und bei jedem weiteren Neustart funktioniert es - nur nicht bei einer Stromtrennung.

Autostart über update-rc.d

#!/bin/sh
### BEGIN INIT INFO
# Provides:          OpenVPN
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Stellt eine OpenVPN-Verbindung her 
# Description:       
### END INIT INFO
 
# Actions
case "$1" in  
    start)
       openvpn /etc/openvpn/client.conf
        ;;
    stop)
        # STOP
        ;;
    restart)
       openvpn /etc/openvpn/client.conf
        ;;
esac
 
exit 0

Wo habe ich einen gemacht Fehler?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 273977

Url: https://administrator.de/forum/autostart-debian-funktioniert-nicht-273977.html

Ausgedruckt am: 23.12.2024 um 15:12 Uhr

24 Kommentare

Neuester Kommentar

Hi adm999,

Was steht denn in solch einem Fall in dem OpenVPN.log-File.
Meine letzte OpenVPN Konfiguration ist jetzt schon ein paar Jahre her
Über die Konfigurations-Datei lässt sich auch das Loglevel einstellen, das könnte man für die Fehlerbehebung auch erhöhen.

Könnte mir vorstellen, das OpenVPN sein eigenes PID-File finden und dann behauptet es würde bereits laufen und ein erneuter Start somit nicht nötig ist.
Wo hingegen bei einem Neustart durch das "Prozessbeenden-Signal" und der Beendigung von OpenVPN das PID-File ordnungsgemäß gelöscht wird und somit ein sauberes Starten möglich ist.

Das dürfte sich aber auch im Logfile wiederfinden.

Ich kann mich aber auch daran erinnern, das sich OpenVPN über die Konsole starten lässt OHNE in den Hintergrund zu wechseln. So das man sämtliche Ausgaben direkt angezeigt bekommt satt im Log zu landen nehme ich mal an.

~Arano

Wie wäre es, das RICHTIG einzurichten?

Entsprechendes Runlevel?

Lonesome Walker

@Arano - Wo finde ich die Logs?

@16568 - Welcher Fehler liegt im Runlevel?

Hallo...

steht in der Config-Datei

  status /var/log/openvpn-status.log
  #log /tmp/openvpn.log
  verb 3

Vielleicht musst du es auch erst einkommentieren.
Dann aber auch darauf achten das OpenVPN die nötigen Rechte hat die Log-Datei zu erstellen.

Mit verb kann man die "Geschwätzigkeit" des Loggens einstellen.

~Arano

Zitat von @adm999:
@16568 - Welcher Fehler liegt im Runlevel?

Die Runlevel selbst sind i.O.

WO liegt Dein Script?
Und required start haste auch vergessen...

Normalerweise liefert OpenVPN doch entsprechende Scripte mit...?

Lonesome Walker

Normalerweise liefert OpenVPN doch entsprechende Scripte mit...?

Richtig, und da bei Ihm der Client läuft, wird der automatisch eine Verbindung initiieren, wenn er die Möglichkeit dazu hat.
Es liegt also hier definitiv ein Fehler in der Config vor, die wir aber leider nicht kennen.
Der TO sollte die Verbindung einmal händisch mit...

openvpn /etc/openvpn/client.conf

...starten und die Ausgabe posten.
Gruß orcape

client
dev tun
persist-tun
persist-key
ping 5
ping-exit 30
nobind
comp-lzo adaptive
remote-random
ns-cert-type server
route-metric 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
remote 176.227.198.122
proto udp

Ähm...

die Ausgabe des Logs wäre trotzdem schön !

Der TO sollte die Verbindung einmal händisch mit...

openvpn /etc/openvpn/client.conf

...starten und die Ausgabe posten.

Ich weiß nicht ob es wirklich an der Konfig liegt, denn nach deiner Beschreibung funktioniert es im Normalbetrieb ja !
Also:

OpenVpn starten,
RasPi vom Strom ziehen,
wieder verbinden,
per SSH drauf,
openVpn-Befehl (s.oben) ausführen und
dessen Ausgabe hier posten.

~Arano

Also:

OpenVpn starten,
RasPi vom Strom ziehen,
wieder verbinden,
per SSH drauf,
openVpn-Befehl (s.oben) ausführen und
dessen Ausgabe hier posten.

..genauso.
Auch mal die Ausgabe von route -n.
In der Client.config.....
- remote 176.227.198.122 (hier fehlt der Port, z.B. 1194)
Hier mal das Bsp. einer Client.conf....

client
dev tun
proto udp
remote 79.183.69.66 1196       # statische Server-IP + VPN-Port
resolv-retry infinite
nobind
persist-key
persist-tun
tun-mtu 1432
ca /etc/openvpn/ca.crt              # Pfad zu den Zertifikaten
cert /etc/openvpn/client.crt        #
key /etc/openvpn/client.key       #
ns-cert-type server
comp-lzo
verb 3

Gruß orcape

Vielen Dank erstmal für die zahlreiche Unterstützung!

Habe nach dieser Anleitung die OpenVPN-Verbindung automatisiert und hergestellt.
Einmal verbunden im laufenden Betrieb läuft die OpenVPN-Verbindung auch nach einem Neustart; NUR beim Auschalten (vom Strom trennen)

Konfigurationsdatei in /etc/openvpn/VPN.conf

client
dev tun
persist-tun
persist-key
ping 5
ping-exit 30
nobind
comp-lzo adaptive
remote-random
ns-cert-type server
route-metric 1

route -n
status /var/log/openvpn-status.log 
log /tmp/openvpn.log 
verb 3

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
remote uk.vpnunlimitedapp.com 1194
proto udp

Status in /var/log/openvpn-status.log

Mon Jun  8 16:24:13 2015 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
Mon Jun  8 16:24:13 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Mon Jun  8 16:24:13 2015 Socket Buffers: R=[163840->131072] S=[163840->131072]
Mon Jun  8 16:24:13 2015 UDPv4 link local: [undef]
Mon Jun  8 16:24:13 2015 UDPv4 link remote: [AF_INET]88.150.180.82:1194
Mon Jun  8 16:24:13 2015 TLS: Initial packet from [AF_INET]88.150.180.82:1194, sid=3711bef7 b695c21d
Mon Jun  8 16:24:13 2015 VERIFY OK: depth=1, C=US, ST=NY, L=New York, O=Simplex Solutions Inc., OU=Vpn Unlimited, CN=server.vpnunlimitedapp.com, name=server.vpnunlimitedapp.com, emailAddress=support@simplexsolutionsinc.com
Mon Jun  8 16:24:13 2015 VERIFY OK: nsCertType=SERVER
Mon Jun  8 16:24:13 2015 VERIFY OK: depth=0, C=US, ST=NY, L=New York, O=Simplex Solutions Inc., OU=Vpn Unlimited, CN=openvpn.vpnunlimitedapp.com, name=openvpn.vpnunlimitedapp.com, emailAddress=support@simplexsolutionsinc.com
Mon Jun  8 16:24:14 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jun  8 16:24:14 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jun  8 16:24:14 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jun  8 16:24:14 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jun  8 16:24:14 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jun  8 16:24:14 2015 [openvpn.vpnunlimitedapp.com] Peer Connection Initiated with [AF_INET]88.150.180.82:1194
Mon Jun  8 16:24:16 2015 SENT CONTROL [openvpn.vpnunlimitedapp.com]: 'PUSH_REQUEST' (status=1)
Mon Jun  8 16:24:16 2015 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.200.0.1,reneg-sec 0,rcvbuf 262144,sndbuf 262144,ping 5,ping-exit 30,route 10.200.0.1,topology net30,ifconfig 10.200.54.38 10.200.54.37'
Mon Jun  8 16:24:16 2015 Options error: option 'reneg-sec' cannot be used in this context ([PUSH-OPTIONS])
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mon Jun  8 16:24:16 2015 Socket Buffers: R=[131072->327680] S=[131072->327680]
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: route options modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jun  8 16:24:16 2015 ROUTE_GATEWAY 192.168.0.2/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:13:c6:49
Mon Jun  8 16:24:16 2015 RESOLVE: Cannot resolve host address: -n: No address associated with hostname
Mon Jun  8 16:24:16 2015 OpenVPN ROUTE: failed to parse/resolve route for host/network: -n
Mon Jun  8 16:24:16 2015 TUN/TAP device tun0 opened
Mon Jun  8 16:24:16 2015 TUN/TAP TX queue length set to 100
Mon Jun  8 16:24:16 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Jun  8 16:24:16 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Jun  8 16:24:16 2015 /sbin/ip addr add dev tun0 local 10.200.54.38 peer 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 88.150.180.82/32 via 192.168.0.2
Mon Jun  8 16:24:16 2015 /sbin/ip route add 0.0.0.0/1 via 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 128.0.0.0/1 via 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 10.200.0.1/32 via 10.200.54.37 metric 1
Mon Jun  8 16:24:16 2015 Initialization Sequence Completed

OpenVPN STATISTICS
Updated,Mon Jun  8 16:35:14 2015
TUN/TAP read bytes,2280
TUN/TAP write bytes,2280
TCP/UDP read bytes,15149
TCP/UDP write bytes,15096
Auth read bytes,4248
pre-compress bytes,0
post-compress bytes,0
pre-decompress bytes,0
post-decompress bytes,0
END

route -n hat nichts in der OpenVPN Client.conf zu suchen.
Du solltest mir nur mal Dein Routing-Protokoll des Raspi zeigen.

Das kannst Du also getrost wieder entfernen.
Gruß orcape

Kleiner Nachtrag....
Falls Du irgendwann mal Probleme mit der Datenübertragung hast und ein Teil Deiner Pakete verworfen werden...

Mon Jun 8 16:24:16 2015 /sbin/ip link set dev tun0 up mtu 1500

...dann liegt das an der MTU-Größe.
Hatte ich Dir aber schon in einem Deiner letzten Threads gepostet...

- tun0 up mtu 1500
MTU 1500 solltest Du reduzieren, das kann (muss nicht) zu Problemen führen.

Gruß orcape

> - tun0 up mtu 1500
> MTU 1500 solltest Du reduzieren, das kann (muss nicht) zu Problemen führen.

Stimmt; welcher Wert wäre hier angebracht?

Aus welchem Grund verliert Debian/Raspberry Pi die Autostartinformationen?

Stimmt; welcher Wert wäre hier angebracht?

..das kommt auch auf die Art Deiner Verbindung an, aber MTU 1432 ist ein guter Wert.
Bei mir musste ich nach einer technischen Änderung durch den Provider noch unter 1400 gehen, weil ich oberhalb noch Paketverlust hatte.
Du musst das aber nicht allein auf dem Client ändern, Server nicht vergessen.

Aus welchem Grund verliert Debian/Raspberry Pi die Autostartinformationen?

...kann ich Dir so nicht sagen.
Normalerweise sind bei Debian die Zertifikate und Keys unter /etc/openvpn in einzelnen Files zu finden.
In der client.conf wird nur der Pfad zu diesen eingetragen.
Fährst Du einen Multiclienttunnel oder ist das ein einzelner Tunnel, würde man an Hand der Server.conf sehen.
Auch route -n in der Konsole eingegeben, würde da schon näheres erklären.

Gruß orcape

Die Werte in Konfigurationsdatei sind von einem VPN-Anbieter; bin nur Kunde.
Bzgl. Multi Client Tunnel liegt leider ausserhalb meiner Wissensbereiches, da ich keinen Zugriff auf den Server habe.

Route -n bei einer bestehenden OpenVPN-Verbindung

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0         10.200.54.45    128.0.0.0       UG    0      0        0 tun0
0.0.0         192.168.0.2     0.0.0.0         UG    0      0        0 eth0
200.0.1      10.200.54.45    255.255.255.255 UGH   1      0        0 tun0
200.54.45    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
0.0.0       10.200.54.45    128.0.0.0       UG    0      0        0 tun0
227.198.122 192.168.0.2     255.255.255.255 UGH   0      0        0 eth0
168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
168.0.2     0.0.0.0         255.255.255.255 UH    0      0        0 eth0

Warum ausgerechnet verliert der Raspberry Pi/Debian Wheezy bei Stromverlust die VPN-Autostart-Funktion teilweise aber das restliche System läuft Störungsfrei? Seltsam..

Die Werte in Konfigurationsdatei sind von einem VPN-Anbieter; bin nur Kunde.

Damit klärt sich zwar nicht Dein Problem, aber einiges.
Das hättest Du schon mal gleich posten sollen, ist für mich aber nun auch an Hand der Routingtabelle klar.
Somit kannst Du auch eine Änderung der MTU-Größe vergessen, da diese vom Provider auf dem Server vorgegeben wird.
Wenn Du die Vorgabe des Providers zur Einrichtung des Tunnels richtig umgesetzt hast, sollte das auch funktionieren.
Ich würde an Deiner Stelle mal beim Tunnel-Provider nachhaken.
Gruß orcape

Normalerweise sind bei Debian die Zertifikate und Keys unter /etc/openvpn in einzelnen Files zu finden.
In der client.conf wird nur der Pfad zu diesen eingetragen.

Ist es wirklich ratsam diese auszulagern oder nur eine Empfehlung?

Damit klärt sich zwar nicht Dein Problem, aber einiges.
Das hättest Du schon mal gleich posten sollen, ist für mich aber nun auch an Hand der Routingtabelle klar.

Mein Versehen; Kritik angenommen und wird in Zukunft umgesetzt.

Die Leitung funktioniert einwandfrei beim Einwählen inwiefern ist das ganze mit dem Stromverlust des RPi's und den Vorgaben des Anbieter usw. zusammen zu bringen? Ist das eher nicht eine lokales Softwareproblem mit Debian?

Bzgl. Umsetzung des OpenVPN's habe ich den Klienten installiert und die Konfigurationsdatei des Anbieters genutzt.

Werde beim Anbieter nachhacken.

Ist es wirklich ratsam diese auszulagern oder nur eine Empfehlung?

Bei mir laufen nur private OpenVPN-Tunnel und da sind Zertifikate und Key in extra Files untergebracht.
Ob das überhaupt etwas mit Deinem Problem zu tun hat, ist fraglich.
Wie sehen denn die Anweisungen Deines Providers aus ?
Daran solltest Du Dich halten.

Ist das eher nicht eine lokales Softwareproblem mit Debian?

...könnte schon sein.
Wenn das händische starten des OpenVPN ohne Fehlermeldungen funktioniert und kein Autostart, so könnte das schon mit Deinem System zusammenhängen.
Die Konfigurationsdatei des OpenVPN-Clients unter Debian heisst...

/etcopenvpn/client.conf

...bei Dir....

Konfigurationsdatei in /etc/openvpn/VPN.conf

Wenn die Datei bei Dir eine Namensänderung erfahren hat, könnte das schon dazu führen, das der Tunnel nicht wieder automatisch startet.
Einen Netzwerkmanager wird es ja wohl auf dem Raspi nicht geben, der da Querschlägt.
Gruß orcape

Hallo

Die Konfigurationsdatei des OpenVPN-Clients unter Debian heisst...

/etcopenvpn/client.conf

...bei Dir....

Konfigurationsdatei in /etc/openvpn/VPN.conf

Wenn die Datei bei Dir eine Namensänderung erfahren hat, könnte das schon dazu führen, das der Tunnel nicht wieder automatisch startet.

Und in deinem init-Script steht auch client.conf, das muss schon gleich lauten !

Irgend wo müssen wir das ja mal eingrenzen, können ja nicht an allen Stellen gleichzeitig "basteln" - dann funktioniert erst recht nichts. links repariert, aber rechts was kaputt gemacht

Schau doch mal, ob das init-Script überhaupt ausgeführt wird in dem du es etwas erweiterst:

/bin/echo "ovpn init-script CALL" >>"/tmp/init-test.log"  
case "$1" in   
    start) 
       /bin/echo "ovpn init-script START" >>"/tmp/init-test.log"  
       openvpn /etc/openvpn/client.conf 
       /bin/echo "ovpn init-script START = $?" >>"/tmp/init-test.log"  
        ;; 

    [...]

/bin/echo "ovpn init-script DONE" >>"/tmp/init-test.log"  

Vielleicht ist da wirklich etwas das den Aufruf des init-Scripts verhindert... oder falls das zuverlässig funktioniert, es doch ein Konfigfehler ist.
Aber dann wissen wir es !

~Arano

@orcape Auch die Umbennung von "VPN" in "CLIENT" zeigte keine Wirkung.
Einmal verbunden im laufenden Betrieb läuft die OpenVPN-Verbindung auch nach einem Neustart; NUR beim Auschalten (vom Strom trennen)

@Arano Habe die Methode aufgegeben und nach einem anderen Weg mit der /etc/default/openvpn (AUTOSTART="client") getestet.

Habe nach dieser Anleitung die OpenVPN-Verbindung automatisiert und hergestellt.

Vielleicht ist da wirklich etwas das den Aufruf des init-Scripts verhindert... oder falls das zuverlässig funktioniert, es doch ein Konfigfehler ist.
Aber dann wissen wir es !

Neustart (/tmp/init-test.log)

ovpn init-script START
ovpn init-script DONE

Stromverlust (/tmp/init-test.log)

ovpn init-script START = 0
ovpn init-script DONE

Erneuter Neustart (/tmp/init-test.log)

ovpn init-script START
ovpn init-script DONE

Keine weiteren Lösungen?

Oh Hi!
Sorry, mir war der untere Teil deiner Antwort entgangen, dachte das kommt später mit einer neuen Antwort.

Wie es aussieht wird immerhin das init-Script jedesmal ausgeführt, am "Autostart" liegt es also nicht.

Ich hatte in der zw.Zeit dein Script so wie es ist auf mein RasPi kopiert und ein update-rc.d -n ovpn oder ähnlich gemacht (-n = nur anzeigen was gemacht werden würde wenn). Bei mir wollte er das als "S01ovpv" in meinen runlevel verlinken.
Damit würde ovpn als einer der ersten zusätzlichen Dienste gestartet werden, eventuell noch vor dem Netzwerk.

Mit welcher Priorität wurde das denn bei dir erstellt ?
Wie LonesomeWalker schon erwähnte: den required-Tag im init-Script anpassen.

~Arano
via Mobile

Es klappt bei mir weder über die Methoden update-rc.d noch über die Konfigurationdatei openvpn mit dem Befehl "AUTOSTART="VPN"".

Mit welcher Priorität wurde das denn bei dir erstellt ?

Es wurde keine Priotität gesetzt.

Wie LonesomeWalker schon erwähnte: den required-Tag im init-Script anpassen.

Wie trage ich ein, dass es nachdem die Verfügbarkeit vom Netzwerk/Internet vorhanden ist startet?

Hi,

Mit welcher Priorität wurde das denn bei dir erstellt ?

Es wurde keine Priotität gesetzt.

Ich schätze mal da missverstehen wir uns !
Beim einrichten deines Init-Scripts mittels update-rc.d sollte in /etc/rc2.d/ ein symbolischer Link erstellt worden sein. Möglicherweise wie bei mir S01openvpn. Die Ziffernfolge "01" ist in diesem Fall "die Priorität der Reihenfolge der Scripte". Kleine Zahlen zuerst, große Zahlen zuletzt.

pi@raspberrypi ~ $ ls -l /etc/rcS.d/S11networking 
lrwxrwxrwx 1 root root 20 Jan  7  2014 /etc/rcS.d/S11networking -> ../init.d/networking

pi@raspberrypi ~ $ ls -l /etc/rc2.d/S02ntp 
lrwxrwxrwx 1 root root 13 Jan  7  2014 /etc/rc2.d/S02ntp -> ../init.d/ntp

pi@raspberrypi ~ $ head /etc/rc2.d/S02ntp 
#!/bin/sh

### BEGIN INIT INFO
# Provides:        ntp
# Required-Start:  $network $remote_fs $syslog
# Required-Stop:   $network $remote_fs $syslog
# Default-Start:   2 3 4 5
# Default-Stop: 
# Short-Description: Start NTP daemon
### END INIT INFO
pi@raspberrypi ~ $ 

rcS.d ist das runlevel für den Systemstart, hier werden unter anderem die Netzwerkadapter konfiguriert und gestartet/verbunden. Danach wird in das gewünschte runlevel gewechselt und weitere Programme/Dienste gestartet.
Natürlich kann es sein, das z.B. das Netzwerk noch gar nicht vollständig aufgebaut ist aber schon in den nächsten runlevel gewechselt wird, dann kann z.B. auch OpenVPN oder NTP nicht korrekt starten weil beide einen verfügbaren Netzwerkadapter benötigen.
Dafür der "Required-Start", dann kann init noch weiter steuern die das nun geht weiss ich aber auch nicht.

Als erste Möglichkeit also einfach mal "S01openvpn" in z.B "S99openvpn" umbenennen. Dann vergeht vielleciht noch mehr zeit zwischen dem Netzwerksetup und dem Start von OpenVPN - kann ja schon ausreichen.
Oder besser gleich das init-Script um nötige Bedingungen ergänzen.
https://wiki.debian.org/LSBInitScripts

> Falls das das Problem ist <

~Arano

Frage Linux Debian

Mehr von adm999

Windows Server 2012 in einer Updatesschleifeadm999 - 6 Kommentare

Modem für Glasfaser und DSLadm999 - 7 Kommentare

Zyxel DSL-Router - VPN einrichtenadm999 - 9 Kommentare

SQL Express - der Benutzer war nicht autorisiertadm999 - 11 Kommentare

Heiß diskutiert