Beiträge von mlohr

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

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

CmdrXay schrieb:

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.

Moin,

ich habe auf einem VPS 200 G8 die Firewall-Distribution pfSense installiert, das läuft soweit erstmal ohne Probleme. Zusätzlich habe ich IPSec-Tunnel zu den FritzBoxen meiner Eltern und meiner Wohnung eingerichtet. Außerdem läuft unter pfSense noch ein OpenVPN-Server, über den ich mich von überall in dieses Netzwerk einwählen kann. Das funktioniert ziemlich perfekt, ich kann von überall aus (Eltern, eigene Wohnung, unterwegs) alle Rechner egal wo erreichen (NAS bei meinen Eltern, mein NAS, etc...). Alles übrigens mit Dual Stack, also IPv4+IPv6. Soweit so gut.

Was ich auch (zeitgleich) mit eingerichtet habe, war eine weitere OpenVPN-Client-Verbindung von pfSense zu einem anderen VPN-Server, um dort auch externe Knoten zu erreichen. Damit verfügt meine pfSense sozusagen über 4 Gateways (also Endpunkte über die aus dem Netzwerk ausgehender Traffic terminiert werden kann): Netcup v4, Netcup v6, Uplink-VPN v4 und Uplink-VPN v6. Da ich nicht der einzige bin, der sich per VPN auf die pfSense einwählt, habe ich als Standardgateway für eingehende VPN-Verbindungen den Uplink-VPN konfiguriert, d.h. eine Firewall-Regel erstellt, die besagt, das alles, was aus einer bestimmten IP-Range kommt, nämlich das des pfSense-VPN-Servers, über das Uplink-VPN geschickt werden soll. Klappt perfekt, Durchsatz etwa 20 MBit Down/Up. Jetzt dachte ich mir: Das ist bestimmt voll der Umweg. Da ich selbst nicht auf das Uplink-VPN-Netzwerk zugreifen muss, kann ich mir per Client-Sonderregel ja ne feste IP zuweisen und der festen IP per Regel das Netcup-Gateway verpassen. Resultat: Nur noch 2 Mbit Downstream (witzigerweise 20 Up). Ich hab kein Rate Limiting in der Firewall noch sonst eine Idee, woher das kommt. Erwartet hätte ich, dass eine direkte Terminierung beim vServer (deutlich) schneller ist als noch ein weiteres mal die Daten durch VPN zu schicken und da erst terminieren zu lassen (also de-facto ein Hop mehr). Ich hab auch aktuell keine Ahnung, nach was ich suchen soll.

Kann mir eventuell von euch jemand einen Tip geben? Danke!

Viele Grüße
Matthias

Wo hostest du denn deine Domain? Die meisten Domain-Hoster, die ich kenne, bieten das Feature HTTP-Redirect direkt an. Dann brauchst du auch keinen externen Webhosting-Account.

Btw: Für wirklich nur ne Weiterleitung wären mir selbst 50 Cent pro Monat zu viel. Ne Domain ist ja fast gleichteuer. Bookmarks sind billiger (Und nach dem ersten mal Eintippen merkt sich der Browser sowas sogar freiwillig!)