Keine Verbindung zu irgendeinem PP Server über Android mehr möglich

MiniCooper

Junior Member
Hallo zusammen,

seit heute Nacht kann sich keines der Android Telefone bei uns in der Familie mit irgendeinem PP Server über die PP eigene App verbinden. Getestet sowohl mit mobilen Daten wie auch mit zwei unterschiedlichen WLAN Netzwerken.

Am Abend zuvor funktionierte es bei allen problemlos. Alle Telefone haben Android 13 installiert. Alle Telefone wurde mehrfach neu gestartet.

Gibt es Probleme bei PP @PP Christian ?

Irgendeine andere Idee.

Danke vorab und schöne Feiertage.
 
Was mich wundert.... Selbst WENN alle in Urlaub wären...

Ich gehe doch davon aus, dass alle PP Mitarbeiter AUCH ihr VPN nutzen...
Somit sollten ALLE Mitarbeiter diegleichen Probleme haben wie wir...
Also sollte das Problem allen bekannt sein... und keiner tut was?

Extrem unwahrscheinlich...

An die Fachleute hier, die schon mal gepostet haben, dass Zertifikate abgelaufen sind...
Kann es sein, das sukzessive alle Zertifikate ausgelaufen sind...

Deshalb auch das langsame Sterben der Server zu unterscheidlichen Zeitpunkten?
 
Das Team hat bereits darauf hingewiesen, dass auf dem Basissystem, das sie aufsetzen, nahezu nichts vorhanden ist.
Es gibt lediglich einige Skripte & Anpassungen, die keine sensiblen Daten leaken, und alles wird in den RAM geladen. Der Vorteil dabei ist, dass die RAMs leer sind (ohne Strom -> Geleert / Gelöscht & nicht Wiederherstellbar), wenn die Server beschlagnahmt werden.
Möglicherweise müssen die anfallenden Arbeiten in diesem Zusammenhang stets manuell ausgeführt werden, da sie nicht automatisiert werden können (z. B. durch Crontabs, Skripte, Zertifikate usw.). Dies stellt natürlich eine wiederkehrende und zeitaufwendige Aufgabe dar.
So vermute ich es mal, da man dem PP Team leider nicht über die Schulter schauen kann.
 
Ja, das ist mir alles klar. Trotzdem müssen ja Sicherheitszertifikate hinterlegt sein, die beim Laden der nackten, virtuellen Maschine jeweils angezogen werden. Ich meine, dass diese eventuell alle abgelaufen sind...
 
Heute setzt niemand mehr einen Server auf, ohne ansible, puppet oder was es sonst noch alles gibt. Selbst in meiner winzigen Umgebung nutze ich das, seit mir mal eine Systemplatte gestorben ist und mich einen halben Vormittag an Arbeit gekostet hat, bis das Hauptsystem wieder lief.
Hatte "Gott|Allah|whatever" sei Dank einen cold standby/backup, der schnell wieder lief.
Bei mir sind *alle* systeme per LUKS verschlüsselt; wer meine Systeme mitnimmt bereitet mir zwar Unanehmlichkeiten, kommt aber nicht an meine Daten.

Übrigens haben echte Server mehrere redundante Netzteile, sodaß man bei Beschlagnahme theoretisch einen Stecker ziehen kann, dort eine USV anschließen und das ganze im laufenden Betrieb abtransportieren kann. Das ist bei Rack-systemen vielleicht etwas aufwändig.
Ob in unserem IT-rückständigen Land die Behörden sowas wissen oder tun, steht auf einem anderen Blatt.

Bei mir laufen bis auf Frankfurt alle Verbindungen problemlos, allerdings benutze ich auch nur openvpn.

p.s. bezüglich der Zertifikate - ich prüfe die Gültigkeit automatisch und kriege eine Warnung, falls eines abläuft. Die PP-certs bei mir haben:
/etc/openvpn/client/CA/pp_ca.crt expires on Jan 24 2026
/etc/openvpn/client/crt/pp_client.crt expires on Nov 25 2025
 
Danke theoth...

Ich habe jetzt mal auf meinem Android Handy versucht mit Amsterdam eine Verbindung aufzubauen...
Hier der relevante Auszug aus dem LOG:

Was sagt Dir die fette Markierung unten?

IKE] received cert request for "C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy IPSEC CA, E=admin@perfect-privacy.com"
[IKE] sending cert request for "C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy IPSEC CA, E=admin@perfect-privacy.com"
[IKE] establishing CHILD_SA android{4}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from 192.168.2.134[40939] to 212.7.209.237[4500] (333 bytes)
[NET] received packet: from 212.7.209.237[4500] to 192.168.2.134[40939] (1248 bytes)
[ENC] parsed IKE_AUTH response 1 [ EF(1/2) ]
[ENC] received fragment #1 of 2, waiting for complete IKE message
[NET] received packet: from 212.7.209.237[4500] to 192.168.2.134[40939] (521 bytes)
[ENC] parsed IKE_AUTH response 1 [ EF(2/2) ]
[ENC] received fragment #2 of 2, reassembled fragmented IKE message (1704 bytes)
[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
[IKE] received end entity cert "C=CH, O=Perfect Privacy, CN=amsterdam3.perfect-privacy.com"
[CFG] using certificate "C=CH, O=Perfect Privacy, CN=amsterdam3.perfect-privacy.com"
[CFG] using trusted ca certificate "C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy IPSEC CA, E=admin@perfect-privacy.com"
[CFG] subject certificate invalid (valid from Sep 26 02:00:00 2024 to Dec 25 01:00:00 2024)
[IKE] no trusted RSA public key found for 'amsterdam.perfect-privacy.com'

[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
 
Richtig. Das hat man nicht nur vergessen, nein, man ist auch einfach mal seit fast zwei Wochen konsequent offline bzw. scheisst drauf. Mit anderen Worten schaut da wochenlang keiner, was auf den Server los ist oder guckt mal in die Supporttickets.
Das geht als Unternehmen einfach gar nicht, egal wie groß oder klein das Team ist.

Das ist auch ein massives Sicherheitsproblem, da die offensichtlich überhaupt nicht mitbekommen, was mit ihren Servern ist.
 
Das Team hat bereits darauf hingewiesen, dass auf dem Basissystem, das sie aufsetzen, nahezu nichts vorhanden ist.
Es gibt lediglich einige Skripte & Anpassungen, die keine sensiblen Daten leaken, und alles wird in den RAM geladen. Der Vorteil dabei ist, dass die RAMs leer sind (ohne Strom -> Geleert / Gelöscht & nicht Wiederherstellbar), wenn die Server beschlagnahmt werden.
Möglicherweise müssen die anfallenden Arbeiten in diesem Zusammenhang stets manuell ausgeführt werden, da sie nicht automatisiert werden können (z. B. durch Crontabs, Skripte, Zertifikate usw.). Dies stellt natürlich eine wiederkehrende und zeitaufwendige Aufgabe dar.
So vermute ich es mal, da man dem PP Team leider nicht über die Schulter schauen kann.

Ich arbeite bei einem sehr großen Unternehmen im Bereich Infrastruktur und Clustersysteme.

Eine RAM-Disk schützt nur vor dem Wiedereinschalten des Servers, sofern dieser stromlos geschalten wurde.
Server sind per Default mit mind. 2 redundanten Netzteilen ausgelegt....ich brauche nur eine USV und kann den Server problemlos laufend ausbauen und mitnehmen....das kann auch ein 10 jähriger.
D.h. tatsächlicher "Schutz" ist nur gegeben, wenn der Betreiber die Systeme selbst im "Notfall" ausschaltet.

Jetzt ist aber ein Server normalerweise nicht aus, sondern läuft - abgesehen von Wartungsfenstern - durchgehend 24/7/365.

Die Server komplett und sicher zu härten (bspw. nach CIS, da gibt es mehr als genug Anlaufstellen) ist nicht trivial und ist keine einmalige Sache....das Ganze "lebt" und wird kontinuierlich an neue Gegebenheiten angepasst.
Zusätzlich haben wir u.a. Sicherheitslücken (CVE) die laufend ausgewertet und priorisiert werden müssen.
Das ist eine riesen Palette.

Dafür benötigt man Fachbereiche, die den Ganzen Tag nichts anderes machen.

D.h. bspw. 2 Leute in Vollzeit hätten hier alleine schon über die Ressource "Zeit" nicht die Befähigung, dass konform abzudecken.....das geht schlicht nicht.

Deswegen betrachte ich "kleine Teams/Unternehmen" immer mit Vorsicht.....weil diese aufgrund des Personalkörpers schon eingeschränkt sind.
 
Es kommt immer drauf an, was auf dem Server läuft. Wenn die Zahl der Apps überschaubar ist, kann man durchaus automatisiert und ohne großen Aufwand updates machen. Man muß natürlich die CERT-Meldungen im Auge behalten und wenn sie zutreffen schnell reagieren.

Bislang war meiner Meinung nach nur selten was wirklich kritisches für diese Umgebung (squid, openvpn linux etc.) dabei und apt upgrade + reboot war schnell gemacht.
Mit der Einstellung von PP (nicht auf einzelne Standorte achten) läßt sich das auch wunderbar machen. Fix auf einem Server einspielen Server wieder onlne nehmen und wenn sich eine Weile niemand beschwert hat, kann man die restlichen Systeme nachziehen.

Anders sieht das aus, wenn auch noch webserver und java/datenbank-backends oder gar webshops mit php dazu kommen. das kann ganz schnell sehr viel Arbeit machen. Das dürfte bei pp aber nur ein zentrales system betreffen.

p.s. sowas wie oben mit den Zertifikaten ist natürlich übel. Mir ist das vor Jahren aber auch schon passiert, daß ich abgelaufene Zertifikate präsentiert hatte.
Ich hatte damals einfach versäumt die upgedateten von der PP-Seite rechtzeitig herunterzuladen und zu installieren. Daher habe ich jetzt auch die automatische Prüfung mit Erinnerung 30 Tage vor Ablauf.
 
Last edited:
Ich arbeite bei einem sehr großen Unternehmen im Bereich Infrastruktur und Clustersysteme.

Eine RAM-Disk schützt nur vor dem Wiedereinschalten des Servers, sofern dieser stromlos geschalten wurde.
Server sind per Default mit mind. 2 redundanten Netzteilen ausgelegt....ich brauche nur eine USV und kann den Server problemlos laufend ausbauen und mitnehmen....das kann auch ein 10 jähriger.
D.h. tatsächlicher "Schutz" ist nur gegeben, wenn der Betreiber die Systeme selbst im "Notfall" ausschaltet.

Jetzt ist aber ein Server normalerweise nicht aus, sondern läuft - abgesehen von Wartungsfenstern - durchgehend 24/7/365.

Die Server komplett und sicher zu härten (bspw. nach CIS, da gibt es mehr als genug Anlaufstellen) ist nicht trivial und ist keine einmalige Sache....das Ganze "lebt" und wird kontinuierlich an neue Gegebenheiten angepasst.
Zusätzlich haben wir u.a. Sicherheitslücken (CVE) die laufend ausgewertet und priorisiert werden müssen.
Das ist eine riesen Palette.

Dafür benötigt man Fachbereiche, die den Ganzen Tag nichts anderes machen.

D.h. bspw. 2 Leute in Vollzeit hätten hier alleine schon über die Ressource "Zeit" nicht die Befähigung, dass konform abzudecken.....das geht schlicht nicht.

Deswegen betrachte ich "kleine Teams/Unternehmen" immer mit Vorsicht.....weil diese aufgrund des Personalkörpers schon eingeschränkt sind.
Natürlich. Die Fiberleitungen muss man aber beim de-racken abklemmen. Demnach verliert der Server natürlich seine connection. Die Ethernetkabel fürs idrac und ilo oder whatever muss man dann auch abklemmen um die Kiste aus dem Rechenzentrum zu transportieren. Das würde dem Betreiber der Server dann aber auffallen. Also normalerweise ... Ich meine ja nur ... 🤣

RAM disk ist auch eine geile Sache schützt aber nur wenn man die Maschine vom Strom abklemmt. Dann sind die Daten futsch. Ich gehe mal stark davon aus dass die Kisten von PP verschlüsselt sind und deren Remote Zugänge gut abgesichert sind. Dann kommt man auch mit laufendem Server nicht ganz so einfach da rein.
 
Dann lassen wir Dich mal arbeiten, bitten aber zwischendurch um Info... vielleicht um 12h oder so...

Was ist los?
Was für Sofortmaßnahmen wurden ergriffen?
Wie lange wird die Störung ungefähr noch dauern?
Wann gibt es das nächste Statusupdate?

Später dann:
Was lernen wir daraus?
Welche Maßnahmen trefft ihr um sowas zukünftig zu vermeiden?
Wie gedenkt ihr den Ausfall zu kompensieren?
 
Back
Top