ich weiss nicht, ob es bei Ritto ebenfalls so ist, aber üblicherweise stürzen die 12(18)V beim klingeln auf 5V(o.ä.) ab.
Ich hatte jetzt nicht das Multimeter dran hängen - aber ich denke schon, dass da etwas in der Richtung passiert. Wie gesagt, da muss ich mir wohl nen kleinen Puffer bauen.
Die Netzteile für diese Anlagen sind ganz schon knapp kalkuliert - dort wirst du kaum Headroom haben, deine paar Watt zu ziehen.
Wenn jemand klingelt, stürzt der Pi ab. War wohl keine allzu gute Idee. Vielleicht mal noch nen ausreichend dimensionierten ELKO oder ne kleine Powerbank dazwischen hängen. 
1. Strom (0.5W) heißt was genau? 5V blabla für arduino-zeug?
2. Sind alle Tasten am Telefon funktionsbelegt?
3. Wohneigentum?
Genau, hat sich auch schon erledigt. Habe nach ewiger Suche doch noch einen Belegungsplan der Pins gefunden und nun funktioniert alles wie gewünscht. Es gab etwas Verwirrung, weil die Kabelfarben nicht dem Standard entsprochen haben. 
Fürs Verständnis - die 12V, welche anliegen, werden auf 5V umgewandelt. Da gibt es in der Bucht ganz praktische Step Down Converter dafür.
Kennt sich hier jemand mit Wohntelefonen/ Klingelanlagen aus?
Es geht um das klassische Wohntelefon in der Wohnung jedes Mehrfamilienhauses. Liegt bei diesen Geräten bzw. den dazugehörigen Kabeln, die aus der Wand kommen, irgendwo Dauerplus an? Hintergrund ist, dass ich genau an dem Ort, wo das Ding (Ritto 6630.00) bei mir ist, Strom (0,5W) brauche. Und da ist natürlich keine Steckdose.
[ich erlaube auf meinem Mailserver von diesem Dienstleister ausschließlich Verbindungen per IPv4 und habe damit
erreicht dass gar keine SPAMs davon mehr kommen ...]
2a01:111::/32 REJECT 5.7.1 Use IPv4, your MX doesn't support IPv6 either
Würdest du einmal den dafür notwendigen Konfigurationsschnipsel mit uns teilen? Mir gefällt diese Idee.
Lecker, mit Erdnusssoße...
Erdnusssoße habe ich noch nie gegessen... klingt interessant.
Was soll das bringen, wenn ein netcup Server selbst für mehr als 50 % des UCEPROTECT Level3 Listings verantwortlich ist? Wer im Glashaus sitzt, tut sich schwer mit Steinewerfen...
Die selben Regeln sollten natürlich selbstredend auch für Netcup eigene Server gelten. Man kann ja z.B. die Webhostings sogar als Relay für andere Server benutzen (oder konnte man mal, vor einiger Zeit) - das ist halt alles eher ungeil, da müsste halt auf jeden Fall mal dran gearbeitet werden.
Aber wie war das... fürs Aufräumen, Refactoren und Abbauen von technischen Schulden zahlt der Kunde nicht. Also hat es maximal wenig Priorität in der Abarbeitung des Backlogs. Das ist gefühlt überall in der IT so.
War da nicht was mit einer Quota-Einstellung im CCP?
(Ich habe derzeit keinen und kann daher nicht nachsehen.)
Genau, da gibt es ein Quota, was man setzen kann.
Sorry, hatte Limit übersehen?
Warum wird das Limit via default auf 100G gesetzt wenn ich 250G gekauft habe?
Gute Frage. Eigentlich ist das Quota ja da, weil bei Überschreiten der z.B. 250GB Zusatzkosten entstehen. Warum das per Default auf 100GB gesetzt wird, erschließt sich mir auch nicht. Vielleicht ist es ja eine Standardeinstellung der NetApp oder so.
Ich habe das ganze Setup nun (endlich) fertiggestellt.
Nebst dem Failover Script im Router (siehe oben), habe ich nun eine VM mit einem Bind Server laufen. Pushe ich nun in mein GitLab Repository mit meinen DNS Zonen, werden diese von DNSControl einmal zu desec deployed und zusätzlich als Bind Zonefile gerendert. Die Zonefiles werden dann per SSH/rsync auf die VM kopiert und mit einem Deployment-Script in der Bind Konfiguration eingepflegt. Im Router existiert nun ein FWD Record, welcher die Anfragen für die jeweiligen Domains an den Bind weiterleitet.
Aktuell gibt es da noch das kleine Problem, dass es ab und an mal laggt. Ich selber merke das nicht direkt, aber in meinem Monitoring macht sich das aktuell bemerkbar. Der Monitoringserver steht ebenfalls hier im Homelab und wirft ab und an mal kurzzeitig Fehler ala '"abc.xyz.de" is not a valid hostname' oder 'Zu diesem Hostname gehört keine Adresse' oder ähnliches. Ich vermute mal, dass das ein Bug in RouterOS ist. Evtl. baue ich mir einen Schalter, sodass der FWD Record mit dem Failover Script aktiviert und deaktiviert wird.
Alles anzeigenDa habe ich aber schon andere Berichte hier gelesen. Es kann auch nicht meine Aufgabe sein, ein Problem zu lösen, das ich nicht verursacht habe. Zumal das ja das Problem nicht löst. Meine IP mag dann freigeschaltet sein, Hunderte andere IPs von ebenso "unschuldigen" Kunden sind weiterhin gesperrt. Es gab mal vor einiger Zeit wenigstens einen Link in der Nachricht von MS, wie man sich freischalten kann. Jetzt sind nur noch die SMTP Statuscodes verlinkt, der auftretende steht da nicht drin. Im Gegenteil, es steht im Klartext drin, dass ein Teil des Netzwerks meines Provides, also netcup, auf der MS Blockliste steht. Ich soll mich an meinen Provider wenden. Und genau das will ich auch. Ticket geht morgen raus. Es kann nicht sein, dass sich Hunderte Kunden einzeln durch die Bürokratie vom Microsoft wühlen müssen um ihre IP freischalten zu lassen, weil einer oder einige Netznachbarn Mist gebaut haben und damit das ganze Subnetz gesperrt ist. Da muss eben der für das Subnetz Verantwortliche sich darum kümmern, dass es wieder entsperrt wird. Dazu gehört auch, die Verursacher herauszufinden und einen Wiederholungsfall möglichst zu verhindern.
Falls das nicht wirtschaftlich ist, muss man es eben wirtschaftlich machen, indem man den Preis für solche "managed" IPs hoch genug ansetzt. So wie es derzeit ist, können netcup IPs für geschäftliche E-Mail Accounts praktisch nicht genutzt werden, weil die Zustellung halt doch sehr unzuverlässig ist. Im September konnte ich von der selben IP noch meinen MS-Mail-Testaccount erreichen, jetzt nicht mehr. Da bin ich gern bereit, mehr zu bezahlen, um die Zuverlässigkeit zu erhöhen. Man könnte solche IPs ja aus einem oder mehreren speziell dafür reservierten Subnetzen nehmen, die dann entsprechend überwacht und nötigenfalls wieder aus den Blacklists oder der MS Blockliste rausgeholt werden. Klare, aber realistische Regeln für den Umgang mit E-Mails aufstellen und bei Zuwiderhandlung bzw. absichtlichem Spam rigoros durchgreifen, spätestens im Wiederholungsfall. Dann gerät man auch gar nicht erst so oft auf die entsprechenden Listen, hat auf Dauer weniger Arbeitsaufwand und Kosten damit. Mit realistischen Regeln meine ich, dass Newsletter und sonstige Massenmails an externe Empfänger über ein festzulegendes Limit hinaus ein NoGo sind, aber normaler, geschäftlicher Mailverkehr möglich sein muss. Mail innerhalb kundeneigener Domains sollte z.B. nicht limitiert sein. Wozu auch, da besteht ja keine Gefahr irgendwo blockiert zu werden.
Natürlich kann man hier, wie auch in anderen Fällen, die niedrigen Preise von netcup als Grund anführen. Das stimmt zwar, passt aber zumindest mit dem Qualitätsanspruch von netcup nicht zusammen. Hohe Qualität trotz niedrigen Preisen. Wo sich das nicht vereinbaren lässt, muss man eben auf eins davon verzichten und das dann auch entsprechend kommunizieren. Ist mir schon bewusst, dass hohe Qualität bei niedrigen Preisen schwerlich machbar ist.
Man könnte aber auch Produktlinien auf verschiedenen Preis- und Qualitätsleveln anbieten. Oder ganz gezielt einzelne Services anbieten, die man kostenpflichtig dazubuchen kann, wenn man sie benötigt. Also so etwas wie die schon vorhandenen Service Level, aber eben nicht nur auf Erhöhung der Verfügbarkeit bzw kürzere Reaktionszeit beschränkt. Also z.B. ein extra Service Level für die Zustellbarkeit von Mail. Natürlich muss man das dann aber auch leisten können und es ist mir durchaus bewusst, dass Fachkräfte momentan knapp sind.
Ich glaube, das ist so ein Katz und Maus Spiel. Ich meine... Hand aufs Herz. Mir fällt kein klassischer VPS-Provider an, der sowas anbietet. Selbst Cloudprovider bieten dir sowas i.d.R. nicht an - AWS bietet dir z.B. SES als ein managed Relay an.
Das würde ich auch bei Netcup sehr begrüßen - ein managed Relay und Port 25 outbound ist generell dicht. Das Relay ist in meinen Augen aus diesem Grund besser, dass Netcup die Einhaltung von SPF, DMARC, DKIM whatever voraussetzt und validiert. Passt das nicht, wird die Mail direkt abgelehnt. Und den Versand von Massenmails kann man auch unter Kontrolle bringen.
Eventuell baue ich das nochmal um. Ich habe das mit dem Fehler catchen beim ROS Scripting noch nie gemacht. Das muss ich mir nochmal anschauen.
Ich glaube, das hier ist besser...
Sieht hart nach Mikrotik aus.
Magst du ein bisschen auf die eingesetzten Pakete und Scriptingmöglichkeiten eingehen?
Grenzt ja fast an SDN - finde ich Wunderbar.
Ist es auch. RouterOS 7 auf meinem CCR2004-16G-2S+.
Pakete nutze ich keine speziellen - das sind alles Bordmittel, die ROS 7 von Werk aus mitbringt.
Was das Scripting betrifft. Naja, prinzipiell ist es recht simpel. Mikrotik Geräte kann man ja auch per Kommandozeile (SSH/Serial/WebTerminal/...) steuern. Mit entsprechender Befehlssyntax. Und die kann man auch zum Scripten nutzen.
In meinem Fall habe ich das Script direkt in der Netwatch Konfiguration drin, was heißt, dass bei einem neuen Status (z.B. "up" auf "down") der Scriptschnipsel ausgeführt wird. Quasi eine Art Hook.
Im Normalfall kann ich in ROS 7 zwar konfigurieren, dass mehrere DNS Server genutzt werden sollen, allerdings keine Priorität oder Reihenfolge. Dort wird dann immer ein Lastausgleich o.Ä. auf alle eingetragenen Ziele gefahren. Und genau das war mein Problem - ich wollte, solange er verfügbar ist, ausschließlich meinen eigenen Unbound durch besagten Wireguard Tunnel hindurch benutzen.
Daher habe ich mir wie gesagt diesen Umschaltmechanismus gebaut. Netwatch macht alle 10 Sekunden einen TCP Connect auf Port 53 meines VPN Servers. Schlägt dieser fehl, wechselt der Status auf "down" und das Script bei "On Down" wird ausgeführt. Dieses schaltet dann auf alternative DNS Server um.
Theoretisch hätte man es noch ein bisschen eleganter bauen können. In meinem Falle wird nicht erkannt, wenn der Unbound zwar läuft, aber z.B. nur noch SERVFAIL liefert. Theoretisch könnte man auch das Script "plain" hinterlegen und als eine Art Cronjob laufen lassen. Dort könnte man dann mit einem /resolve versuchen, den Zielserver eine Domain auflösen zu lassen. Dabei könnte man dann widerum potenzielle Fehler catchen und darauf basierend einen anderen DNS Server setzen.
Eventuell baue ich das nochmal um. Ich habe das mit dem Fehler catchen beim ROS Scripting noch nie gemacht. Das muss ich mir nochmal anschauen.
Ich glaube, ich habe jetzt die "beste" Lösung gefunden.
Was ich gemacht habe - ich habe DoH am Router ausgeschalten, damit die FWD Records wieder funktionieren. Statt öffentlichen DNS Servern, nutze ich nun allerdings den Unbound Recursive Resolver meines VPN Servers. Der VPN Server ist so oder so per Wireguard Tunnel an meinen Router angebunden.
Um das ganze halbwegs ausfallsicher zu haben, habe ich mir mittels Netwatch einen Failover-Mechanismus gebaut:
Ist die Unbound Instanz auf meinem VPN Server nicht mehr erreichbar, wird auf normale, öffentliche DNS Server umgeschalten. Und anders herum.
Was jetzt noch fehlt, ist, dass ich einen Bind aufsetze und mir ein Deployment aus DNScontrol heraus bastel. Wo genau der am Ende laufen wird, weiß ich selber noch gar nicht... dort deploye ich dann aber auf jeden Fall meine DNS Records aus der Pipeline heraus hin und lege auf meinem Router die passenden FWD Records an.
Ich glaube, dass ich das Problem damit einigermaßen elegant gelöst bekomme.
Das solltest Du noch mal kontrollieren. Die kupferbasierten DACs (aka. Twinax), die wir bei meinem Ex-Arbeitgeber hatten, haben wesentlich weniger Strom verbraucht, als die SR Optiken. Vom Preis ganz zu schweiden. Aber wir mussten auch bei 'ner Apotheke kaufen. Nur wenn die 5m langen DACs zu kurz waren, lohnten sich Optiken.
Laut Datenblatt SR: 1 Watt,, DAC: 0,1 Watt
Danke für den Hinweis. Kontrolliere/vergleiche ich mal, wenn der Kram geliefert wurde.
Ich habe nur irgendwo mal gelesen, dass pro 10G Kupferport-/strecke schnell mal ~5W oder mehr einzuplanen sind.
Alles anzeigenLaut Internet sollen Mikrotik und Mellanox mit Cisco Branding kein Problem haben, das Kabel sollte demnach grundsätzlich funktionieren.
Am Ende stellt sich bei deinem Setup glücklicherweise die Frage nicht, weil du recht "normale" Hersteller hast die einfach funktionieren.
Ich würde SFP+ Module mit OM4/5 als Best Practice sehen bzw. wenn es Reibungslos gehen muss. Bei Mellanox kannst du auch einfach "generisch" verwenden. Ich hab damals glaub ich auch mellanox branding genommen, aber die waren auch mit "normalos" glücklich.
Hab mir das jetzt mal bestellt. 10Gbit standen eh auf der Liste lol
Ach und das war der Hersteller 10Gtek mit den Kochenden Modulen. Zumindest sind Sie für mich raus. Rohzangen haben im Serverraum nix verloren
Ich habe mir die beiden Karten auch bestellt. Funktionieren beide. Das DAC funktioniert, ist aber ein reinfall, weil Kupfer... funktioniert zwar, aber 10G Kupfer ist halt Strom- und Temperaturmäßig immer nur dynamisch geil. Im Nachhinein betrachtet hätte ich das aber auch vorher sehen können - Lehrgeld also.
Ich habe mir jetzt mal noch bei fs.com SFP+ Module und LWL Kabel bestellt. Die Low Profile blenden verkauft einem der Händler von Ebay auch... witzigerweise: kauft man das selbe Bundle über seinen Shop anstatt über Ebay, dann bekommt man zwei LP Blenden zum selben Preis mit dazu. Ebenfalls Lehrgeld.
Hi,
dieses nette Tool hier ist dein Freund.
Afaik brauchst du:
Ich hoffe, das ich da jetzt nichts vergessen habe. Falls ja, sagt dir das das eingangs erwähnte Tool.
weiss man denn, was das für ein dns-service auf routeros ist?
Irgendwas proprietäres... also nichts "gängiges", wo man sich nen Workaround basteln könnte.
ich würde mit dnscontrol bind-zones schreiben lassen, die zone auf den router kopieren und via dhcp-lease-trigger (dhcp-lease-script) die statics importieren.
So ähnlich ist jetzt auch mein Plan.
Leider kann der Router keine Bind Zones (RouterOS halt), daher habe ich den Bind9 auf den Pi geschmissen, wo auch mein PiHole drauf liegt. Da muss ich mir noch eine Magie bauen, die dann aus der Pipeline raus die Bind files per SCP auf den Pi kopiert und den Bind dort neustartet/reloadet.
Mein Hauptproblem ist eigentlich. Der DNS Server von RouterOS kann mit sog. FWD Records so konfiguriert werden, dass er bestimmte Domains an einen bestimmten, weiteren DNS Server forwardet. Das funktioniert aber nicht, wenn man diesen als Upstream DNS Server DNS-over-HTTPS nutzen lässt. Keine Ahnung, warum man das so programmiert.
Eine Idee habe ich da noch, die habe ich aber noch nicht getestet. Wenn die Internetleitung wegknackt, sollte das DoH nicht funktionieren und er sollte auf normales DNS zurückfallen. Vielleicht funktionieren dann die FWD Zones. Das würde ja eigentlich schon ausreichen.
Es gibt noch die Möglichkeit, die eingehenden DNS Anfragen mit DPI in der Firewall mittels NAT an ein anderes Ziel zu leiten. Aber das ist... nun ja. Etwas unsauber.
Nutzt du denn lokal auch die FQDNs die nicht .local oder so sind?
Ja, definitiv. Das DHCP autogenerierungs Hostname Zeug nutze ich gar nicht.
Im lokalen Netz würde ich trotzdem immer versuchen mit Einträgen zu arbeiten, die unabhängig von der Erreichbarkeit externer NameServer sind.
Das ist es halt. Ich könnte auch einfach die TTL höher nehmen. Wenn dann aber Eintrag X wieder im DNS Cache fehlt, gehen die Probleme wieder los.
Also du hast aktuell deine Domains bei Netcup liegen mit "externen" DNS Server der von desec.io bereitgestellt werden, korrekt?
Soweit so richtig, ja. Also meine NS Records sind afaik "ns1.desec.io." und "ns2.desec.org.".
aber dein Implementationsdesign ist bisschen wirr.
Genau das ist mein Problem. Ich weiß nicht, was ich so genau will. Das ist aber auch eigentlich der Grund, warum ich frage...
Generell ist das technisch etwas schwierig. Ich habe halt keinen lokalen Recursor rumstehen, sondern nur den DNS Server im Router, der die Anfragen per DoH an einen externen Recursor weiterleitet. Split Horizon DNS habe bzw. brauche ich dank IPv6 nicht.
Das Problem, nochmal konkretisiert ist, dass mein Homelab bei Ausfall der Internetleitung theoretisch nach wie vor funktioniert (weil die Ressourcen alle nach wie vor miteinander reden können). Praktisch können sie sich aber doch nicht erreichen, weil sie den DNS Namen ihres Ziels nicht in eine IP Adresse auflösen können.
Prinzipiell wären alle meine Zonen als statische Einträge im DNS Server des Routers, glaube ich, am elegantesten. Aber das lässt sich halt leider nicht ganz so elegant deployen.
Aber danke für deinen Input.
