Kategorie: IT

Wetterstation: Luftdruck richtig eingestellt

Die Wet­ter­sta­ti­on mißt also den Luft­druck, und sie kann nur den mes­sen, der da ist. Der ist aber nur ver­gleich­bar mit ande­ren Luft­drü­cken in der­sel­ben Höhe, das ist zum Bei­spiel beim DWD erklärt. Da mei­ne Sta­ti­on etwa 20 Meter üNN liegt, muß ich also ca. 2,5 abzie­hen vom Meß­wert, um auf den rela­ti­ven Luft­druck zu kommen.

Nichts leich­ter als das:

Und der Effekt:

Home Assistant schön(er) gemacht

Bei mir läuft Home Assi­stant in einem Docker-Con­tai­ner auf einem Raspber­ry Pi 4, schon sehr lan­ge. Anfangs als nati­ve Instal­la­ti­on, da wur­de dann aber die Update­rei bald ner­vig, des­halb Docker, da geht das Updaten (und Down­gra­den) deut­lich schmerz­frei­er — mitt­ler­wei­le küm­mert sich watch­tower dar­um, das geht alles voll­au­to­ma­tisch, sehr schick.
Dann kam irgend­wann der Wunsch auf, die Instal­la­ti­on auch aus dem Inter­net zugäng­lich zu machen. Der nächst­lie­gen­de Gedan­ke war, auf dem Rou­ter ein­fach ein Port­for­war­ding zu schal­ten: Router:TCP/443 -> Pi:TCP/443. Das hat aber min­des­tens zwei Probleme:

  • DNS-Name. Ich habe zwar die Domain sokoll.com, aber die IP des Rou­ters ändert sich zwar sel­ten, aber eben doch ab und an. Dann müß­te das DNS nach­ge­zo­gen wer­den. Unter der Vor­aus­set­zung, daß man den Wech­sel der IP über­haupt bemerkt hat.
  • TLS-Zer­ti­fi­kat für den Web­ser­ver. Natür­lich will ich nichts selbst­si­gnier­tes, Let’s Encrypt soll es schon sein. Dann geht aber die HTTP chal­len­ge nicht. DNS chal­len­ge gin­ge, mache ich ohne­hin, aber dann müß­te ich wild mit cron­jobs ham­peln und das Zer­ti­fi­kat von mei­nem Net­cup-Ser­ver holen.

Alles nicht so fein. Also muß­te eine ande­re Lösung her: der DNS-Name zeigt auf mei­nen Ser­ver bei Net­cup, dort läuft ein Apa­che als rever­se proxy:

<VirtualHost 185.207.105.125:443 [2a03:4000:1e:181::1]:443>
  Protocols h2 http/1.1
  ServerName hass.sokoll.com
  ServerAlias home.sokoll.com
  ServerAdmin webmaster@sokoll.com
  ErrorLog ${APACHE_LOG_DIR}/hass.sokoll.com-error.log
  CustomLog ${APACHE_LOG_DIR}/hass.sokoll.com-access.log combined
  SSLCertificateFile /etc/dehydrated/certs/wildcard_sokoll.com/fullchain.pem
  SSLCertificateKeyFile /etc/dehydrated/certs/wildcard_sokoll.com/privkey.pem
  ProxyRequests off
  ProxyPreserveHost On
  ProxyPass /api/websocket wss://91.66.45.77/api/websocket
  ProxyPassReverse /api/websocket wss://91.66.45.77/api/websocket
  ProxyPass / https://91.66.45.77/
  ProxyPassReverse / https://91.66.45.77/
  SSLProxyEngine on
  SSLProxyCheckPeerCN off
  SSLProxyCheckPeerExpire off
  SSLProxyCheckPeerName off
</VirtualHost>

(die IP ist schon lan­ge nicht mehr gültig)
Das heißt: Der Request kommt bei Net­cup an, und der Apa­che dort schubst ihn dann wei­ter zu mei­nem Rou­ter, dort gibt es ein Port­for­war­ding auf den Pi. Nicht son­der­lich ele­gant, funk­tio­niert aber.

Nun änder­te sich kürz­lich die IP wie­der, und ich muß­te die Web­ser­ver-Kon­fi­gu­ra­ti­on ändern, hat­te mich ver­tippt, ging nicht, Feh­ler suchen und fin­den und behe­ben, bis zum nächs­ten IP-Wech­sel, das ist doch alles Mist.
Auf dem Ser­ver läuft ein #Wire­guard, das ver­sorgt ein Tele­fon und einen Lap­top mit #Piho­le, das könn­te doch auch den Pi bedie­nen? Wenn dann der Pi den Tun­nel auf­baut, hät­te ich immer die­sel­ben IPs und könn­te mir das gan­ze Geham­pel mit Port­for­war­ding auf dem Rou­ter sparen.
Wire­guard ist sim­pel. Auf dem Server:

~$ ssh -l root big wg
interface: wg0
  public key: RzZAu5Js3c8/5yQBPlhKg2b0jkOlxHT6vLreiC1BCgo=
  private key: (hidden)
  listening port: 51820

peer: yS2cSLvEovdsLLT8ne/lixoiU87o821TgBkzrVHRFS4=
  endpoint: 91.66.61.253:35710
  allowed ips: 192.168.3.6/32
  latest handshake: 1 minute, 21 seconds ago
  transfer: 16.10 MiB received, 1.83 MiB sent

peer: RF22N9Kb6AO0N+jqZvSIdPxtZj3CxgasdgwuW6ktGys=
  endpoint: 91.66.61.253:58623
  allowed ips: 192.168.3.5/32
  latest handshake: 1 minute, 45 seconds ago
  transfer: 50.42 MiB received, 715.71 MiB sent

peer: OAbhrovugDdR8he1UIzy67Szh798C4lxWelSwrd3Z3o=
  endpoint: 91.66.61.253:1024
  allowed ips: 192.168.3.4/32
  latest handshake: 1 minute, 49 seconds ago
  transfer: 19.73 MiB received, 77.50 MiB sent
~$

Auf dem Pi:

~$ ssh -l root r4 wg
interface: wg0
  public key: yS2cSLvEovdsLLT8ne/lixoiU87o821TgBkzrVHRFS4=
  private key: (hidden)
  listening port: 35710

peer: RzZAu5Js3c8/5yQBPlhKg2b0jkOlxHT6vLreiC1BCgo=
  endpoint: 185.207.105.125:51820
  allowed ips: 192.168.3.1/32
  latest handshake: 15 seconds ago
  transfer: 1.03 MiB received, 8.97 MiB sent
  persistent keepalive: every 25 seconds
~$

In der Apa­che-Kon­fi­gu­ra­ti­on oben noch die VPN-Adres­se des Pi ein­tra­gen und Apa­che reloaden.
Fertsch. Funk­tio­niert traumhaft.
Gut. Ein Pro­blem hat­te ich: Der Tun­nel wird von innen auf­ge­baut, solan­ge da kei­ne Pake­te lau­fen, ist der Tun­nel unten, und das gan­ze schö­ne Kon­strukt funk­tio­niert nicht. Man könn­te einen Dau­er-ping im Hin­ter­grund lau­fen las­sen, aber das wäre nun wirk­lich uncool. Und dann ent­deck­te ich eben persistent keepalive, was das Pro­blem ele­gant löst.

Wire­guard rockt da house!

Q: Warum? A: Weil es geht!

Ich habe bei AWS (Nord Vir­gi­nia) eine VM in der kleins­ten (kos­ten­lo­sen) Ausführung.
Auf der läuft ein Wire­guard, mein Tele­fon ist prak­tisch stän­dig ein­ge­loggt. Funk­tio­niert. Wo ich frü­her bei etwa Spie­gel Online Wer­bung hat­te, wel­che die bes­ten Rechts­an­wäl­te in Greifs­wald sei­en, sehe ich nun Wer­bung, wo in Ashburn VA SUVs fast ver­schenkt werden 🙂
Da ich ja krank geschrie­ben bin und also Zeit habe, habe ich mir ein mei­nem Heim­netz mal ein Pi-Hole instal­liert. Das funk­tio­niert erstaun­lich effek­tiv, damit hat­te ich nicht gerech­net. Sicher, ein Wer­be­blo­cker im Brow­ser funk­tio­niert noch erfolg­rei­cher, aber bei Mobil­ge­rä­ten ist das meist nicht mög­lich, und sobald es zu gene­ri­schen Apps kommt, ist es ganz vor­bei. Und da scheint Pi-Hole einen her­vor­ra­gen­den Job zu machen.
Aller­dings: Wenn ich im VPN bin, nützt das nichts. Ich könn­te zwar den Pi-Hole im LAN als DNS-Ser­ver ein­tra­gen, aber wenn ich mobil unter­wegs bin, ist der ja nicht mehr erreichbar.
Aber: anders als es der Name ver­mu­ten läßt, kann man Pi-Hole nicht nur auf einem Raspber­ry Pi instal­lie­ren, son­dern prak­tisch über­all, wo ein dns­masq lau­fen könn­te. Also auch auf mei­ner Ama­zon-VM, das ist ein Debi­an. In Wire­guard auf dem Tele­fon wird das wg0 des VPN-Ser­vers als DNS-Ser­ver eingetragen:


Scheint sofort zu funktionieren 🙂

 

Hüb­sche Spie­le­rei mit Nutzeffekt.

 

#wire­guard #pi-hole #piho­le

EdgeOS, IPv6 and hwnat

For the archive

IPv6 rou­ting sucks on the ER‑X, tes­ted with iperf3 from a LAN station:

pi@r4:~ $ iperf3 -6 -c iperf.par2.as49434.net -p 9231
Connecting to host iperf.par2.as49434.net, port 9231
[ 5] local 2001:470:6d:c40:828b:eb2f:26f:523e port 49342 connected to 2a0f:9240:1018::2 port 9231
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 172 KBytes 1.41 Mbits/sec 1 1.38 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.38 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 1 1.38 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.38 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 1.38 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.38 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.38 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.38 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 1 1.38 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.38 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 172 KBytes 141 Kbits/sec 5 sender
[ 5] 0.00-10.07 sec 39.9 KBytes 32.4 Kbits/sec receiver

iperf Done.
pi@r4:~ $

From the rou­ter itself:

ubnt@sokoll-router:~$ iperf3 -6 -c iperf.par2.as49434.net -p 9231
Connecting to host iperf.par2.as49434.net, port 9231
[ 5] local 2001:470:6c:c40::2 port 46362 connected to 2a0f:9240:1018::2 port 9231
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.81 MBytes 31.9 Mbits/sec 0 382 KBytes
[ 5] 1.00-2.00 sec 6.11 MBytes 51.3 Mbits/sec 42 421 KBytes
[ 5] 2.00-3.00 sec 5.25 MBytes 44.0 Mbits/sec 5 333 KBytes
[ 5] 3.00-4.00 sec 4.76 MBytes 39.9 Mbits/sec 0 364 KBytes
[ 5] 4.00-5.00 sec 5.31 MBytes 44.5 Mbits/sec 0 385 KBytes
[ 5] 5.00-6.00 sec 4.32 MBytes 36.3 Mbits/sec 0 395 KBytes
[ 5] 6.00-7.00 sec 4.57 MBytes 38.3 Mbits/sec 2 292 KBytes
[ 5] 7.00-8.00 sec 3.83 MBytes 32.1 Mbits/sec 0 316 KBytes
[ 5] 8.00-9.00 sec 3.77 MBytes 31.6 Mbits/sec 3 239 KBytes
[ 5] 9.00-10.00 sec 2.90 MBytes 24.4 Mbits/sec 3 182 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 44.6 MBytes 37.4 Mbits/sec 55 sender
[ 5] 0.00-10.14 sec 43.5 MBytes 36.0 Mbits/sec receiver

iperf Done.
ubnt@sokoll-router:~$

That comes clo­se to my regu­lar upload bandwidth.

Now if I dis­able off­loading for NAT:

ubnt@sokoll-router:~$ configure
[edit]
ubnt@sokoll-router# set system offload hwnat disable
[edit]
ubnt@sokoll-router# commit
[edit]
ubnt@sokoll-router#

results in

pi@r4:~ $ iperf3 -6 -c iperf.par2.as49434.net -p 9231
Connecting to host iperf.par2.as49434.net, port 9231
[ 5] local 2001:470:6d:c40:828b:eb2f:26f:523e port 37006 connected to 2a0f:9240:1018::2 port 9231
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 4.26 MBytes 35.7 Mbits/sec 0 443 KBytes
[ 5] 1.00-2.00 sec 5.81 MBytes 48.7 Mbits/sec 40 433 KBytes
[ 5] 2.00-3.00 sec 5.56 MBytes 46.6 Mbits/sec 0 491 KBytes
[ 5] 3.00-4.00 sec 6.05 MBytes 50.8 Mbits/sec 40 368 KBytes
[ 5] 4.00-5.00 sec 4.08 MBytes 34.2 Mbits/sec 36 286 KBytes
[ 5] 5.00-6.00 sec 3.71 MBytes 31.1 Mbits/sec 0 311 KBytes
[ 5] 6.00-7.00 sec 4.94 MBytes 41.5 Mbits/sec 0 324 KBytes
[ 5] 7.00-8.00 sec 4.39 MBytes 36.8 Mbits/sec 0 330 KBytes
[ 5] 8.00-9.00 sec 4.32 MBytes 36.3 Mbits/sec 0 330 KBytes
[ 5] 9.00-10.00 sec 4.32 MBytes 36.3 Mbits/sec 0 330 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 47.4 MBytes 39.8 Mbits/sec 116 sender
[ 5] 0.00-10.06 sec 46.4 MBytes 38.7 Mbits/sec receiver

iperf Done.
pi@r4:~ $

It’s magic!

I’ll moni­tor the CPU load and see whe­ther dis­ab­ling hwnat impacts the router’s performance.

CEO Fraud

Every now and then, an email arri­ves at my com­pa­ny mailserver.

From: surname_big_boss lastname_big_boss <attacker@example.com>
To: surname_victim lastname_victim <victim@mycompany.com>

It is always the same: the atta­cker asks for the victim’s mobi­le num­ber or Whats­app num­ber, — and in the end, they will trick the vic­tim into trans­fer­ring money to the atta­cker. See https://en.wikipedia.org/wiki/Email_spoofing#Business_email
And unfor­tu­n­a­te­ly, I had user in the past who replied 🙁

Of cour­se, you can­not block the attacker’s email address, becau­se it chan­ges with every new attack.
But what if we block ever­ything with the dis­play name “surname_big_boss lastname_big_boss” and an email domain that is NOT one of ours? With post­fix and regu­lar expres­si­ons, that is qui­te easy:

~# grep ^header_checks /etc/postfix/main.cf
header_checks = pcre:/etc/postfix/header_checks_map
~#

Sil­ly naming, I know. It is not a map. But names are not important 😉

And now in /etc/postfix/header_checks_map

/^From: +surname_big_boss +lastname_big_boss +<.+@(?!mycompany\.(de|com)).*>$/i REJECT Go away phisher

Don’t for­get to rel­oad post­fix after you made the change.

Of cour­se, this works not so good if your boss is “Peter Smith”… Mine has a more uni­que name.

Die digitale Transformation im Gesundheitswesen — hat sie jemand gesehen?

Im Jahr 2022 bekommt man als Pati­ent sei­ne Rönt­gen-Daten auf einer CD (für die jün­ge­ren: so sil­ber­ne Schei­ben, dar­auf hat man frü­her Daten gespei­chert) aus­ge­hän­digt. Im DICOM-For­mat (was durch­aus sinn­voll ist). Ein View­er wird mit­ge­lie­fert. Einer. Für ein Betriebs­sys­tem, das eben­so wie die Ver­wen­dung von sil­ber­nen Schei­ben völ­lig aus der Zeit gefal­len ist und bes­ten­falls noch Lega­cy für Boo­mer, die am Alt­her­ge­brach­ten hängen.

DAS HABEN WIR SCHON IMMER SO GEMACHT!!!

 

Platz wäre genug, um noch ande­re Betriebs­sys­te­me zu berücksichtigen:

Allein:
DAS HABEN WIR NOCH NIE SO GEMACHT!!!

Fullfeed RSS

Wer in sei­nem Feed­rea­der mehr als nur zwei News-Sei­ten hat, wird das Pro­blem ken­nen: Es gibt kei­nen full feed, son­dern nur einen Anreiß­text, um den voll­stän­di­gen Arti­kel lesen zu kön­nen, muß man auf die Web­site gehen. Das ist zwar mit einem Maus­klick erle­digt, aber doch ärger­lich und umständlich.
Tech­nisch könn­te die News-Sei­te natür­lich den Arti­kel auch kom­plett via RSS/Atom aus­lie­fern, so daß man die Web­site gar nicht besu­chen muß zum Lesen — und genau das möch­te der Betrei­ber natür­lich ver­hin­dern, ent­ge­hen ihm doch  Klicks (neu­deutsch: Impres­si­ons) Man­che Anbie­ter bie­ten einen full feed gegen Bezah­lung — im Prin­zip ein fai­rer Deal, aber das wird irgend­wann zu teuer.

Doch gibt es Abhil­fe: https://morss.it/ Da wirft man die Url zum Feed ein (Ach­tung, es geht nur RSS, kein Atom!) und bekommt eine neue Url zurück mit dem vol­len Feed. Offen­sicht­lich par­sen die den Ori­gi­nal-Feed, holen sich den kom­plet­ten Arti­kel, berei­ten den etwas auf und stel­len ihn dann in den eige­nen Feed. Ob das so wirk­lich legal ist?
Nun ja, jeden­falls funk­tio­nierts. Das Ergeb­nis sieht zwar nicht ganz clean aus, aber mir gefällt das so bes­ser als der Umweg über die ori­gi­na­le Website.
Man­che Feeds funk­tio­nie­ren nicht, der von golem.de etwa. Müßt ihr probieren.

#feed #rss #atom

Die Cloud, collateral damage

Ich brow­se gera­de durch einen Issue bei #Git­lab und lese dies:

As you know, Git­Lab was migra­ted to goog­le cloud and this ser­vice is not acces­si­ble from Iran. I did not know about the sta­te of this issue until you men­ti­on me.

Egal, ob nun Goog­le, Apple, Micro­soft, Ora­cle… — die­ses “der Algo­rith­mus ent­schei­det” ist ganz ganz gro­ßer Mist. Davor soll sich nie­mand ver­ste­cken dürfen.