Hommel-Net Weblog

Andrea Bocelli und Brian May. Uff.

https://youtu.be/bD_c84faLws?si=9NizL3vf2hsTwp40

Ist euch das nicht auch schon passiert, dass ich mit vim eine Datei editiert habt und dann beim Speichern bemerkt, dass ihr keine Schreibrechte auf die Datei habt?

Jochen Lillich hat in seinem Blog einen Tipp, wie ihr die Datei mit root-Rechten speichern könnt:

:w !sudo tee %

Dieser Befehl speichert die Datei, danach könnt ihr sie mit :q! verlassen und die Warnungen ignorieren, die Änderungen sind dennoch gespeichert.

Alles weitere zur Funktionsweise des Befehls erfahrt ihr in Jochens Blogpost.

Der Firefox Webbrowser hat seit einiger Zeit eine eigene Funktion zum Übersetzen von Webseiten. Neulich hatte ich einen Artikel in Wallabag auf Deutsch übersetzt, wobei Firefox auch die englische Menüleiste mit übersetzt hast. Das Ergebnis ist ein wenig poetisch und ich möchte es mit euch teilen.

Zurück -
Originalartikel
Inhalt nachzubeten
Mark wie gelesen
Toggle mit
Löschen
Fügen Sie ein Tag
Themen-Knebel
Aktie
Druck
Springt zu einem zufälligen (sig!)
Export
Probleme?

Zu meinem Job beim Schulträger unseres Landkreises gehört auch die Administration der Netzwerkinfrastruktur in den Schulen. Die von uns genutzten Aruba 6300 Switches haben einen seriellen Konsolenanschluss im USB-C Format. Über diesen Port führe ich normalerweise routiniert die Konfiguration der Switches mit meinem Kubuntu 22.04 Laptop, einem USB-C Kabel und dem Tool minicom durch.

Nach dem Anschließen des Kabels am Laptop meldet sich der Switch auf der Schnittstelle /dev/ttyACM0 und ich verbinde mit mit minicom -D /dev/ttyACM0 und kann den Switch über die Konsole bedienen.

Diese Routine wurde heute je durchbrochen, als ich nach dem Anschluss des Kabels an meinen Laptop das vertraute Device nicht finden konnte. Stattdessen erstellte Kubuntu das Device /dev/ttyUSB0. Na gut, dann eben flux damit verbunden aber: Nach dem Verbinden mit der Switch-Konsole konnte ich keine Eingaben machen. Die Ausgaben des Switches konnte ich aber problemlos mitverfolgen. Der Versuch mit einem zweiten Switch der gleichen Baureihe ergab das gleiche Ergebnis.

Ein wenig Googeln brachte den Tipp, in den Settings von minicom die “Hardware Flow-Control” auf “Nein” zu setzen und siehe da, nun konnte ich auch wieder Eingaben in der Konsole machen.

Das Problem ist nun zwar praktisch gelöst, allerdings weiß ich noch nicht, worauf diese Änderung des Verhaltens zurückzuführen ist. Da sich an den Switch-Modellen nichts geändert hat, habe ich eine Software-Änderung bei meinem Kubuntu Laptop in Verdacht. Aber vielleicht hat jemand von euch dazu eine Idee, ich bin für sachdienliche Hinweise dankbar.

Serendipity - auch kurz S9Y - ist das Stück Opensource Software, mit dem dieser kleine Ort hier im Internet seit April 2006 betrieben wird. Und so ist es mir eine Pflicht aber auch ein Bedürfnis, darauf hinzuweisen, dass in der letzten Woche die Version 2.5.0 der besten Blog-Engine der Welt erschienen ist.

Das Hauptaugenmerk der neuen Version liegt in der Unterstützung von PHP8.2, im Hintergrund wurden aber auch viele Bibliotheken und Abhängigkeiten aktualisiert. Vielen Dank an alle Entwickler, die dieses kleine Softwareprojekt immer noch unterstützen und dazu beitragen. Happy blogging!

Ich bewege mich ja viel und oft im Linux-Terminal, um verschiedene Aufgaben zu erledigen. Manchmal ist es ganz nützlich, wenn man die Ausgabe des Terminals über die Zwischenablage in anderen Programmen weiter verwenden kann. Zwar hat man immer die Möglichkeit, die Ausgabe zu kopieren und mit den gängigen Methoden (Strg-C oder über Menübefehle der Konsolen-Anwendung) in die Zwischenablage zu befördern, allerdings ist das nicht immer praktikabel. Wenn zum Beispiel die Ausgabe so umfangreich ist, dass sie den Inhalt einer Bildschirmseite überschreitet, wird das Markieren ziemlich mühsam.

Abhilfe schafft hier das kleine Tool xclip, das ihr auf den meisten Distributionen über den jeweiligen Paketmanager installieren könnt. Danach habt ihr die Möglichkeit, die Ausgabe im Terminal auf xclip umzuleiten.

So leitet

ls | xclip -sel clip

die Ausgabe des ls-Befehls direkt in die Zwischenablage und ihr könnt das systemweit in jeder Anwendung wieder einfügen. xclip kann noch ein paar Dinge mehr, hierzu empfehle ich die Manpage.

Aloha!

Im letzten Jahr hatte ich schon ein wenig gejammert, weil ich mein Ziel von mindestens 1.000 Laufkilometern aus gesundheitlichen Gründen nicht erreicht hatte.

Danach war ich hoffnungsvoll und motiviert in die Saison 2023 gestartet und die ersten zwei Monate waren auch richtig gut. Leider hat mich ein kleiner Laufunfall mit einer Rippenprellung dann wieder zurückgeworfen. Es hat fast zwei Monate gedauert, bis ich komplett schmerzfrei war und die Laufrunden wieder aufnehmen konnte.

Im Jahresverlauf wurde es dann allerdings auch auf der Arbeit stressig und ich konnte keine ordentliche Regelmäßigkeit beim Training herstellen, so dass das Jahresendergebnis der Laufkilometer mit 778 Kilometer noch schlechter ausgefallen ist als im letzten Jahr.

Ich habe in den letzten Monaten des Jahres einiges umstrukturiert und ein langzeiterkrankter Kollege ist wieder zurück im Geschäft. Ich bin also guter Dinge, dass das Laufjahr 2024 wieder besser wird und die 1.000er-Marke wieder in erreichbare Nähe rückt. Wichtig ist für mich vor allem, dass die Freude an der Bewegung nicht verloren geht und ich einen Ausgleich zur Arbeit am Rechner habe.

Ich wünsche uns allen ein gesundes und gutes Jahr 2024, machen wir das Beste daraus.

Im letzten Jahr habe ich im Weihnachts-Blogpost geschrieben, dass das Jahr wahnsinnig schnell verflogen ist und das Blog in diesem Jahr ziemlich verwaist war. Im Grunde könnte ich das gleiche heute wieder schreiben. Die Zeit ist gefühlt noch schneller vergangen und es hat sich hier noch weniger getan.

Trotzdem möchte ich mein kleines Lagerfeuer im Netz nicht aufgeben, ich hoffe immer, dass ich mich wieder motivieren kann, hier wieder mehr zu schreiben. Einige Ideen sind in (schon länger) in meinem Kopf und vielleicht schaffe ich es eines Tages, sie umzusetzen. Stay tuned.

Die Zeit ist übrigens so schnell vergangen, dass dieser Weihnachts-Post sich einen Tag verspätet hat. Für die restlichen Feiertage und den Jahreswechsel wünsche ich allen Leserinnen und Lesern eine gute, ruhige und gesunde Zeit. Ich werde es gemütlich angehen und den ein oder anderen Stream vom 37C3 konsumieren.

Mein Dank geht raus an alle Menschen, die den Laden auch über die Feiertage am Laufen halten, die auf uns aufpassen und sich um andere Menschen kümmern. Ihr seid großartig.

Frieden.

Wie immer gibt es an dieser Stelle eine Version meines Lieblingsweihnachtslieds. Ende November ist der Sänger der Pogues, Shane MacGowan leider verstorben. Auf seiner Beerdigung gab es viel Musik und auch “Fairytales Of New York” wurde gespielt. Hier ist das Video dazu und die Stimmung in der Kirche ist besonders, wenn die Menschen am Ende des Lieds zu tanzen beginnen.

Bitte schön.

‘Fairytale of New York’ played at Shane MacGowan’s funeral - YouTube

Aloha. Da bin ich wieder.

Seit ein paar Wochen mache ich einen Selbstversuch und versuche, jeden Tag den ungefähr gleichen Schlafrhythmus einzuhalten. Das bedeutet, ich gehe jeden Abend ungefähr zur gleichen Zeit schlafen und stehe morgens ungefähr zu selben Zeit auf. Mittlerweile hat sich mein Körper darauf eingestellt und ich wache morgens meistens von allein auf.

Warum erzähle ich das alles? Auch heute am Sonntag war ich also früh wach, habe am Rechner eine Tasse Kaffee getrunken, diverse Timelines mehr oder weniger durchgelesen und mich dann auf die sonntägliche Laufrunde begeben. Soweit nichts besonderes, aber heute war ungewöhnlich viel los auf meiner "Hausstrecke". Viele Spaziergänger mit Kinderwagen und Hunden kamen mir entgegen oder wollten von mir überholt werden. Keine Ahnung, was die heute morgen alle aus dem Haus getrieben hat, das Wetter kann es nicht gewesen sein, obwohl es trocken war und ein herbstlich frischer Wind wehte.

Außerdem hat mich heute noch ein berufliches Projekt für die nächste Woche beschäftigt. Normalerweise versuche ich, am Wochenende wirklich die Freizeit zu genießen und nicht so viel an die Arbeit zu denken. Allerdings wollen wir in der nächsten Woche die Inbetriebnahme einer Netzwerkinfrastruktur an einer größeren Schule vornehmen. In dieser Größenordnung wird das ein Pilot und deshalb ist es schon ein wenig aufregend für uns alle. Also konnte ich es auch heute am Sonntag nicht ganz lassen, noch das ein oder andere in Gedanken oder in Form von Dokumentation für die nächste Woche vorzubereiten. Ihr könnt im Verlauf der Woche sicher noch das ein oder andere dazu hier im Blog lesen.

Bei einem Verwandtschaftsbesuch haben wir dann noch den neuen Dackelwelpen kennengelernt, Cuteness Overload!

Ach ja, und wenn ihr mal eine Pause von allem braucht, kann ich diesen Thread auf Mastodon empfehlen: https://mastodon.social/@flexghost/111274209612952439

Betreibt man Firewalls auf einem Linux-Router mit iptables, kommt man früher oder später in die Verlegenheit, Portforwarding machen zu müssen. Schaut man dann einschlägige Anleitungen im Internet an, findet man solche, die das allein über ein DNAT (Destination Natt ing) in der Prerouting-Chain lösen, manche wiederum sagen, dass man unbedingt auch ein SNAT (Source Natting) in der Postrouting-Chain machen muss, sonst würde das überhaupt nicht funktionieren.

Ich hatte das Problem letztens und möchte das hier mal etwas aufdröseln, damit ich beim nächsten mal nicht wieder Schaubildchen malen muss. Vielleicht hilft es ja auch dem ein oder anderen von euch, wenn ihr mal einen ähnlichen Routing-Fall lösen müsst.

Ich gehe in diesem Artikel nicht auf die Grundlagen des Routings und Firewallings ein, sondern möchte nur den oben erwähnten speziellen Fall genauer beschreiben.

Zunächst schauen wir uns grob an, wie so ein IP-Paket die einzelnen Chains (Ketten) unserer Firewall durchläuft.

Wie man sieht, haben wir zwei NAT-Chains (Network Adress Translation), nämlich die Prerouting- und die Postrouting-Chain. Jedes IP-Paket enthält unter anderem eine Absender-IP und eine Empfänger-IP. In diesen beiden Ketten kann iptables diese beiden Adressen umschreiben, nämlich die Empfänger-Adresse im Prerouting und die Absender-Adresse im Postrouting. Das besondere ist, dass diese Adressen, sobald die Antwort auf so ein verändertes Paket wieder bei unserem Router ankommen, auch wieder zurück übersetzt werden können.

Unsere Router zu Hause machen das übrigens ständig, wenn wir im Internet surfen. Bei allen Paketen wird die private IP-Adresse aus unserem Heimnetz in die öffentliche IP-Adresse ausgetauscht, die wir von unserem Provider erhalten haben. Kommt eine Anwort zurück, tauscht der Router die Adresse wieder zurück und sendet die Internetinhalte an das Gerät in unserm LAN, das sie auch angefordert hat.

Diese spezielle Form des SNAT in der Postrouting-Chain nennt man auch Masquerading.

Doch nun zu einem etwas komplexeren Setting, bei dem wir spezielle Adressumschreibungen benötigen, die über ein pauschales Masquerading hinaus gehen.

Wir haben als Beispiel eine Firewall mit drei Netzwerkkarten, eine (eth0) zeigt ins Internet mit einer öffentlichen IP-Adresse 1.2.3.4, eine Karte (eth2) zeigt in unser internes Firmennetz und hat die IP 192.168.1.1/24. Die dritte Karte (eth1) mit der IP 192.168.10.1/24 zeigt auf ein Netzwerk, in dem zwei Webservices laufen, die aus dem Internet erreichbar sein sollen.

Alle Pakete aus dem Internet, die auf für die IP-Ports 80 und 443 ankommen, sollen auf einen Reverse-Proxy weitergeleitet werden, der dann den Verkehr weiter an die zuständigen Rechner für die jeweiligen Services verteilt.

Das ganze schaut schematisch so aus:

Die beiden Adressen “service_a.example.com” und “service_b.example.com” werden vom DNS auf die IP-Adresse 1.2.3.4 geleitet. Also müssen unsere Firewall anweisen, alle Pakete, die auf der IP-Adresse 1.2.3.4 auf Port 80 und 443 ankommen, an unseren Reverse-Proxy zu forwarden.

Dazu müssen wir zunächst das Forwarding für diese Ports in der FORWARD-Chain erlauben:

iptables -A FORWARD -i eth0 -o eth1 -p TCP --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p TCP --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Dann kommt das eigentliche Portforwarding, also das Umschreiben der Empfängeradresse im Paket.

iptables -t nat -A PREROUTING -d 1.2.3.4 -p TCP --dport 80 -j DNAT --to-destination 192.168.10.10:80

iptables -t nat -A PREROUTING -d 1.2.3.4 -p TCP --dport 443 -j DNAT --to-destination 192.168.10.10:443

Das funktioniert zunächst für alle Pakete, die aus dem Internet (hier als Beispiel von der IP-Adresse 3.4.5.6) kommen. Die Empfänger-Adresse wird auf den Proxy umgeschrieben:

Source          Dest
3.4.5.6         1.2.3.4  -> DNAT -> 192.168.10.10

und auf dem Rückweg:

Source          Dest
3.4.5.6         1.2.3.4  <- DNAT <- 192.168.10.10

Der Absender 3.4.5.6 erhält also als Antwort auf sein Paket, dass mit der Empfängeradresse 1.2.3.4 abgesendet wurde.

Das gleiche funktioniert auch, wenn ein Rechner aus dem internen Netz ein Paket an einen unserer beiden Services sendet. Der Router sorgt auch hier wieder für den Aus- und Zurücktausch der Empfänger-Adresse des Pakets.

Jetzt kommen wir aber zu einem Fall, in dem das so nicht funktioniert. Nehmen wir einmal an, der Rechner “service_a.example.com” muss ein IP-Verbindung zu “service_b.example.com” herstellen. Da “service_b.example.com” auch im internen Netz mit der IP 1.2.3.4 übersetzt wird, geht unser IP-Paket also an unseren Router, der auch wieder brav die Empfängeradresse austauscht.

Source          Dest
192.168.10.50   1.2.3.4  -> DNAT to 192.168.10.10

Das Paket geht zunächst ordnungsgemäß an unseren Reverse-Proxy, der an 192.168.10.60 (service_b) vermittelt. Nun soll der Proxy eine Antwort an den Absender schicken und hat folgendes IP-Paket vorliegen:

Source          Dest
192.168.10.50   192.168.10.10

Ah, das Paket kommt von einer IP aus dem eigenen Netz, die ganz ohne Routing direkt erreicht werden kann, also wird die Antwort direkt an 192.168.10.50 gesendet.

Dieser Rechner kann aber mit der Antwort nichts anfangen, denn er hat nie ein Paket an die IP 192.168.10.10 gesendet, sondern an 1.2.3.4.

Also wird die Antwort verworfen, die IP-Verbindung kommt in diesem Fall nicht zustande. Hier haben wir den Fall, in dem ein DNAT für das Portforwarding nicht ausreicht.

Um dafür zu sorgen, dass die Antwort den gleichen Weg nimmt wie das Ursprungspaket auf dem Weg zum Reverse-Proxy und damit der Router die Daten des Pakets wieder auf den ursprünglichen Wert zurücksetzt, müssen wir in der Postrouting-Chain die Absender-Adresse des Pakets auf die IP des Routers ändern:

iptables -t nat -I POSTROUTING -s 192.168.10.0/24 -d 192.168.10.10 -p tcp --dport 80 -j SNAT --to-source 192.168.10.1

iptables -t nat -I POSTROUTING -s 192.168.10.0/24 -d 192.168.10.10 -p tcp --dport 443 -j SNAT --to-source 192.168.10.1

Zusätzlich benötigen wir an dieser Stelle eine Forwarding-Regel, die das Forwarding auch von eth1 zu eth1 erlaubt:

iptables -A FORWARD -i eth1 -o eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Dadurch stellen wir sicher, dass das Paket bei Beantwortung zunächst wieder an den Router geschickt wird, der dann die IP-Adressen wieder auf die alten Werte korrigiert.

Als Regel kann man festhalten, dass wir immer dann eine SNAT-Regel für das Portforwarding benötigen, wenn durch das umschreiben der Empfänger-Adresse (DNAT) das IP-Paket so geändert wird, dass sich der Routing-Pfad auf dem Rückweg so ändert dass der Router, der das Natting durchgeführt hat, nicht mehr beteiligt ist. Dann ist es notwendig, auch die Absenderadresse so zu manipulieren, dass das Paket den gleichen Weg zurück nimmt und am NAT-Router wieder umgeschrieben wird.