Beiträge von mlohr

Zitat von Olgsi

Du scheinst sehr in der Thematik zu stecken, daher kurz Offtopic. Findest du netcup mit dem Webhostingpaket ist sicher genug? Oder sollte man zu Gmail forwarden? Danke dir.

Siehe Antwort von CmdrXay. Einen wirklichen Unterschied macht es nicht.

PGP ist - je nach Benutzung - ne Ende-zu-Ende-Signatur oder ne Ende-zu-Ende-Verschlüsselung, also genau dafür gedacht, über unsichere Kanäle zu schicken. Bei Verschlüsselung können weder Netcup noch Google den Inhalt mitlesen, die Metadaten müssen sie sehen, ansonsten ists recht schwer, Nachrichten dem richtigen Empfänger zuzustellen. Gleiches gilt für die Signatur: Mit einer funktionierenden Signatur kannst du sicherstellen, ob dein Mail-Provider (wie Netcup oder Google) deine Mails verfälschen, während Sie bei denen auf dem Speicher liegen. Kannst ja mal eine statistisch relevante Untersuchung starten, ob du herausfindest, wie oft die Mails einfach so verändert werden

Beim Thema Verschlüsselung geht man auch immer "vom schwächsten Glied in der Kette" aus. Bei Ende-zu-Ende-Verschlüsselung egal, aber z. B. bei Transportverschlüsselung relevant. Gehen deine Daten einmal unverschlüsselt übers Netz, egal wo, gelten sie aus wissenschaftlicher Sicht als öffentlich zugänglich. Von daher ist eine Weiterleitung von egal wo zu egal wo eigentlich immer ne schlechte Idee, weil man damit die Kette um eins verlängert und man schlechter rausfindet, wer nun das schwächste Glied in der Kette ist. Je mehr Hops, desto riskanter, weil einer könnte ja schwach abgesichert sein.

Zitat von eripek

Ich habe „hab ich schon mal gehört, hat irgendwas mit Verschlüsselung zu tun“ angeklickt.

Frag doch lieber mal nach GPG.

Naja. GPG ist einer der Clients für PGP. PGP ist das Konzept, GPG eine (von vielen) Softwares dazu. Mir gehts dadrum, wer das Konzept nutzt, unabhängig von der gewählten Software.

edit: Fast richtig. OpenPGP ist der Standard (laut Wikipedia, https://de.wikipedia.org/wiki/OpenPGP)

P.S.: netcup: Wollt ihr nicht auch PGP Keys für verschlüsselten Support anbieten?

Ich benutze es tatsächlich regelmäßig, sowohl für den geschäftlichen als auch universitären Austausch von Mails. Ich benutze dafür einen YubiKey, auf dem mein Private Key untergebracht ist.

Meine Uni-Kollegen signieren tatsächlich regelmäßig, manche verschlüsseln auch. Manche Anbieter, bei denen ich Kunden bin, schicken auch signierte Mails raus und bieten ihre Keys auch für verschlüsselte Kommunikation an.

Meine Kunden fragen mich manchmal genau eben diese Frage, was das für ne komische Datei im Anhang ist. Dann erkläre ich denen kurz, dass das n Sicherheits-Feature ist, und sie, wenn sie denn möchten, damit die Echtheit meiner Mail überprüfen können. Lessons Learned: Nicht von PGP reden. "Sicherheit" ist das Wort, was alle gut finden. Klar, es hat mit Sicherheit nix zu tun, wenns keiner überprüft. Aber wenn man es gar nicht nutzt, ists auch nicht sicherer. So gibt es zumindest die Möglichkeit, dass andere Menschen die Echtheit meiner Nachrichten überprüfen können - wenn sie es denn wollen.

Außerdem signiere ich tatsächlich jeden meiner Git-Commits.

Moin,

um mal einen kleinen Eindruck zu bekommen, wie so die Lage aussieht... wer hat hier eigentlich schonmal was von PGP gehört, wer nutzt es, etc..?

Viele Grüße
Matthias

What means "chroot is not working"? Are you sure you selected the right boot device?

Moin,

eine direkt Antwort auf deine Frage weiß ich nicht.

Aber kennst du den "Trick" mit Mailbox-Delimeter? Damit ist es möglich, E-Mail-Adressen wie du+amazon@abc.de, du+netcup@abc.de zu nutzen. Das ist normalerweise (glaube ich) aktiviert, d.h. du richtest nur die E-Mail-Adresse du@abc.de ein, alle anderen mit du+*** werden automatisch dahin zugestellt. Da muss man also nix einrichten. Würde das dein Problem lösen?

Viele Grüße
Matthias

Moin,

ich habe gestern eine der (seltenen) Mails über den Ausfall einer meiner vServer bekommen. Dort enthalten ist die vServer-ID und die gebuchte Produktbeschreibung (z.b. "v1234567890 - - VPS 1000 G7SEa1 12M". Da ich mehrere vServer habe, ist das leider nicht sehr erhellend, um welchen Server es genau sich handelt. Von daher würde ich vorschlagen, den Server-Spitznamen und/oder den Hostname der primären IP-Adresse in die E-Mail mit einzufügen, dann weiß ich auch, ob ich irgendwelche Kunden informieren muss oder einfach den Dingen ihren Lauf lassen kann.

Viele Grüße
Matthias

So, Weihnachten ist nun ja schon rum, das nächste Weihnachten dauert noch n Weilchen, aber der Bedarf an Maschinchen wächst und wächst... Gibt es demnächst wieder ein spannendes Ereignis (Geburtstag von Felix, Firmenjubiläum, Integer-Überlauf bei Netcups Umsatzzahlen), die eine bevorstehende Sonderaktion vermuten lassen? Ansonsten muss ich ja tatsächlich unglaublich teure 2,69€ für einen kleinen vServer zahlen...

Bin mal auf das Ostereiersuchen gespannt...

Treffer würde ich sagen

Ja, die Daten habe ich schon gesehen, die lassen aber auch nicht drauf schließen, dass die Domain zeitnah wieder frei wird. Was mir auch aufn Keks geht sind solche bescheuerten Anbieter wie https://realnames.com/ (ja, das Geschäftsmodell ist legitim, macht aus unternehmerischer Sicht schnell Sinn, aber es klaut mir meine Domanis)

Ich hab dann inzwischen auch mal zugeschlagen. Das, was ich sonst so an Erfahrungen gelesen habe ist, dass ich im Falle eines fehlgeschlagenen Transfers wenigstens das Geld zurückbekomme. Die fragliche Domain war mir den Preis wert, mir ist vor allem wichtig, dass ich sie dann auch bekomme und das Geld nicht verpufft.

Ist ne 4stellige .net-Domain. Die einzige aus der Liste der "bekannteren" TLDs, die überhaupt noch irgendwie zu haben ist. .web wäre noch ein würdiger Kandidat, aber da tut sich ja seit längerer Zeit nix mehr und ich hab inzwischen das Warten dicke

Moin,

bin mir nicht ganz sicher, ob das hier das richtige Forum dafür ist, aber ich würde die Frage gerne mal mit euch diskutieren: Hat jemand von euch Erfahrungen mit dem Domainhandel über Sedo? Hat jemand dort schonmal eine Domain erworben?

Ich würde gerne eine Domain, die dort zum Verkauf steht, erwerben und frage mich wie seriös/sicher das Ganze ist... Letztendlich ist ja nicht Sedo der aktuelle Registrar der Domain sondern eben der Verkäufer.

Bin mal auf die Meinungen hier gespannt

Viele Grüße
Matthias

Joa, das bestätigt das, was wir hier alle vermuten.

Allerdings steht da nicht, dass deine Domain kein DNSSEC hat. Da steht, dass netcup.net kein DNSSEC hat.

Dann gehe ich mal davon aus, dass DNSSEC für deine Domain klappt. Und jetzt müsste man rausfinden, was dieser Mailcheck eigentlich checked. Alles andere ist Spekulation und die Glaskugel hab ich gerade verliehen.

Was hat ein Mail-Versand mit DNSSEC zu tun? Ja, die E-Mail-Domain könnte über DNSSEC abgesichert sein, auch die Domain des Mailservers könnte abgesichert sein. Was davon meinst du?

Probiers doch mal damit: https://dnssec-analyzer.verisignlabs.com/

Moin,

per in b) genannter Client-Konfiguration gebe ich einem der Clients eine fest IP-Adresse. Alle anderen erhalten IP-Adressen aus dem Pool. Alle Clients bekommen die selben Routen (incl. default) gepushed.

Firewall-Regeln:

In der Firewall-Konfiguration kommt zuerst eine Regel, die auf die spezifische (Absender-)IP-Adresse prüft. In den Firewall-Regel-Einstellungen ist kein explizites Gateway konfiguriert, es wird daher das Standard-Gateway (WAN Richtung Netcup) verwendet.

Als nächstes kommt eine Regel, die auf alle (bisher unmatched) Pakete zutrifft und dann wie in a) beschrieben explizit das Gateway auf das Upstream-Gateway setzt.

Warum möchte ich die Default-Route übersteuern (die funktioniert ja - mein Client-Traffic kommt ja bei der pfSense an)? Ich verstehe, was diese Routen machen, aber nicht, warum mir das helfen könnte (aktuell sehe ich keine Kollision). Oder setzt die in a) genannte Firewall-Regel nochmal ne neue Route?

Viele Grüße
Matthias

Um das nochmal kurz klarzustellen: Das Problem (bei mir) tritt dann auf, wenn ich ohne Upstream-VPN unterwegs bin. Also "kleine" Pakete. Mit Upstream-VPN (also den potentiell größeren Paketen, also dem höheren Risiko in ein MTU-Problem reinzurennen) ist es schnell.

Falls das soweit verstanden ist, verstehe ich noch nicht, wie das mit der MTU in diesem Fall zum Problem werden kann.

Moin,

erstmal vielen Dank für die Rückmeldung, leider scheint aber das Problem noch nicht korrekt kommuniziert zu sein ch dachte ich hatte es klargestellt, dann eben nochmal, in anderen Worten:

In beiden Setup ist es der selbe Client, mit der selben OpenVPN-Konfiguration, selbes Betriebssystem. Die OpenVPN-Verbindung wird, wie oben beantwortet, über L(ayer)2, also tap, aufgebaut, Protokoll ist UDP. Es ist die selbe pfSense-Firewall, der selbe OpenVPN-Server zu dem ich verbinde, selbe Server-Konfiguration. pfSense besitzt (die ganze Zeit) (logischerweise) eine WAN-Verbindung, eben den virtuellen Netcup-Netzwerkstöpsel. Außerdem ist (die ganze Zeit) eine VPN-Client-Verbindung von der pfSense zum Upstream-VPN-Server aktiv (der natürlich die WAN-Verbindung nutzt, wie soll er sonst irgendwohin kommen). Damit verfügt die pfSense über 2 (wenn wir über v4/v6-Dual-Stack reden 4) Gateways: WAN, Upstream-VPN. Dieses Setup existiert die ganze Zeit und ist bei beiden Testfällen identisch. Es gibt kein TCP in TCP und erst recht kein TCP in TCP in TCP.

Nun zu dem einzigen Unterschied: In der pfSense existiert eine Regel für den innerhalb der eingehenden VPN-Verbindung ankommenden Traffic, also alles das, was der Client-Rechner in das VPN-Netzwerk steckt. In dieser Regel kann man in den Advanced-Settings ein Gateway definieren, über das der eingehende Traffic weitergeroutet werden soll. Meine einzige Änderung: Ich wechsle zwischen WAN und Upstream-VPN.

Resultat (speedtest.net) aus Sicht des Client-PCs in Abhängigkeit des in der pfSense eingestellten Gateway für eingehende Daten innerhalb des (eingehenden) VPN-Dienstes, aktuell gemessen an einer 100MBit-Leitung (synchron):

WAN Upstream: 40-55 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

WAN Downstream: 5-7 MBit/s, pfSense-CPU-Auslastung: ca. 20-30%

Upstream-VPN Upstream: 40-50 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

Upstream-VPN Downstream: 40-50 MBit/s, pfSense-CPU-Auslastung ca. 80-90%

• Wäre der Wert mit Upstream-VPN niedriger als der bei WAN, hätte ich nix gesagt, da es ja eigentlich ein Hop mehr und eine zusätzliche Verschlüsselung ist und die Bandbreite zum Upstream-VPN durch die WAN-Bandbreite limitiert ist. Die Tatsache, dass WAN signifikant langsamer ist als Upstream-VPN (über WAN), macht mich stutzig
• Die Tatsache, dass lediglich der Downstream (also die Daten vom Internet hin zum WAN-Port des pfSense-Servers) wirklich signifikant einbricht, ist extrem auffällig.
• IPSec hat mit dem Problem nichts zu tun, das ist zwar auch konfiguriert, aber für das Problem irrelevant, da die fraglichen Daten dort nicht langlaufen. Hatte es nur der Vollständigkeit halber erwähnt.

Meine Schlüsse (zur Diskussion freigegeben):

• Der Client hat keine Ahnung wie er terminiert wird. Von daher gehe ich davon aus, dass das Problem nicht auf der Strecke zwischen Client-PC und pfSense liegt, da diese in beiden Fällen identisch ist.
• Es hat nichts mit der MTU zu tun, da die Tunnel einwandfrei funktionieren, es bremst erst, wenn ein Nicht-Tunnel (WAN) involviert ist. Noch ein weiterer Grund, der gegen die MTU spricht: Die Pakete, die die pfSense absendet (Upstream), werden schnell bestätigt. Daher scheint die MTU auf meiner Seite zu stimmen. Auf die MTU der Gegenseite (das wäre der Netcup-Router) habe ich keinen Einfluss, nehme aber mal dreist an, dass die in Ordnung ist.

Zitat

Wie schaut denn das Traceroute innerhalb des Tunnels für beide Varianten aus? Spielt da etwas Routen-Ping-Pong?

Innerhalb des Tunnels zwischen Client-PC und pfSense identisch. Von pfSense zu 8.8.8.8 über Netcup 5 Hops, über den Upstream-VPN 8 Hops. Wie sehe ich, ob da Routen-Ping-Pong gespielt wird?

Zitat

Etwaige MTU-Unterschiede und würde tracepath ebenso wie asymmetrische Routen gut aufzeigen.

Falls meine Annahme, dass es nichts mit der MTU zu tun hat, falsch ist: Wie finde ich das mit tracepath heraus?

Zitat

netstat -rn

Internet:
Destination        Gateway            Flags     Netif Expire
default            ne.tc.up.gw        UGS      vtnet0
10.4.0.1           10.13.212.235      UGHS        lo0
10.13.212.0/24     10.13.212.1        UGS      ovpnc2
10.13.212.1        link#8             UH       ovpnc2
10.13.212.235      link#8             UHS         lo0
ne.tc.up.ip/22     link#1             U        vtnet0
ne.tc.up.gw        link#1             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.137.0/24   192.168.137.2      UGS      ovpns3
192.168.137.1      link#9             UHS         lo0
192.168.137.2      link#9             UH       ovpns3
192.168.160.0/24   link#7             U        ovpns1
192.168.160.1      link#7             UHS         lo0

Client-Routing-Tabellen sind aus besagten Gründen in beiden Fällen identisch.

Zitat von CmdrXay

Habe ich das richtig verstanden, dass wir hier prinzipiell einen Tunnel im Tunnel haben?

Ne, das habe ich wohl zu kompliziert erklärt. Folgende 2 Wege können die Daten nehmen:

• Client <--[OpenVPN]--> pfSense <--[Netcup Leitung] --> WWW (2 MBit/s)
• Client <--[OpenVPN]--> pfSense <--[OpenVPN]--> Upstream VPN - WWW (20 MBit/s)

Es ist also kein Tunnel im Tunnel. Und insofern seltsam, weil die Daten Richtung Upstream VPN ja auch über das "Netcup-WWW" rausgehen - eben Richtung Upstream-VPN.

Gleichermaßen müsste damit die MTU auch unverdächtig sein, da sie ja im unteren Fall funktioniert. Ich hab das Bandbreitenproblem ja witzigerweise genau dann, wenn ich den Upstream-VPN nicht nutze.

Zitat

Welche CPU-Last hat denn dein Server wenn du einen Speedtest machst?

Genaue Werte sind da schwer abzulesen, das hüpft auf dem Dashboard fleißig mal auf ~80-90% und dann wieder 20-30% (bei Tests sowohl mit Uplink-VPN als auch Netcup als Gateway).

Zitat

Wie ist dein ‚Uplink VPN Server‘ hardwaretechnisch dimensioniert?

Details kenne ich leider nicht, aber definitiv ne GBit-Anbindung, die man auch voll ausnutzen kann. Sollte aber für mein Problem egal sein, da der ja bei dem 2Mbit-Problem nicht involviert ist.

Zitat

L2 oder L3 VPN?

Von meinem Rechner zum pfSense L2, von pfSense zum Uplink-VPN L3.

Zitat

Ich kann mir vorstellen, dass der kleine VPS einfach mit dem ganzen Abhandeln der NAT Verbindungen nicht klar kommt die entstehen sobald du aus dem VPN austrittst.

Keine Ahnung, wie viel Leistung man Grundsätzlich für ein NAT braucht (wie viel Leistung hat denn so ne FritzBox, die 100MBit schafft?). Was gegen deine Theorie spricht, ist, dass ich auch gegenüber dem Uplink-VPN NAT mache, und da 20MBit möglich sind. Von daher schließe ich, dass im Falle der 2MBit nicht die CPU der limitierende Faktor ist. VPN wird ja einmal "terminiert", wenn die Pakete von meinem Rechner zur pfSense gekommen sind. Die Weiche dort wirft sie entweder direkt ins WWW (über das Netcup Gateway) oder muss sie wieder in VPN Einwickeln und an den Uplink-Server schicken. Ich hätte jetzt angenommen, dass letzteres aufwändiger und damit langsamer sein müsste. Aber genau das Gegenteil ist ja der Fall.

Zitat

Hast du Hardware Offloading usw. bei der pfSense am VPS von Netcup deaktiviert?

Ähm... erstes mal davon gehört. Aber nach kurzem Lesen und nachschauen: Ist deaktiviert.