Schlagwort: pihole

Smart TV

IT
Comments

Heu­te kam ein neu­es Smart TV, das alte hat nach ca. 13 Jah­ren den Geist auf­ge­ge­ben (genau­er: ver­ständ­li­chen Ton auf­ge­ge­ben) Dyon heißt die Mar­ke, hat­te ich noch nie gehört, angeb­lich sogar ein deut­scher Her­stel­ler (https://www.dyon.eu/) — ich glau­be das nicht, ver­mut­lich kom­men die Gerä­te doch direkt aus China.

Da wir kein Anten­nen- oder Sat-TV haben, ging die Inbe­trieb­nah­me schnell von­stat­ten, auch Netz war sofort da:

Die 192.168.1.88 ist ein piho­le, der Fern­se­her soll ja auch was gutes bekommen.
Alles funk­tio­niert also, die diver­sen Strea­ming-Diens­te sind ein­ge­rich­tet und funktionieren.

Abschlie­ßend wer­fe ich noch einen Blick in die Logs des piho­le um zu sehen, zu wel­chen Heim­te­le­fo­nier-Sei­ten der Fern­se­her pet­zen möch­te. Stellt sich raus: Der Fern­se­her benutzt den piho­le gar nicht! (und auch nicht die 192.168.1.41)
Ein Ver­dacht kommt auf. Ich log­ge mich also auf dem Rou­ter ein und mache:

root@sokoll-router:/config# tcpdump -i switch0 -n host 192.168.1.92 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:17:09.293692 IP 192.168.1.92.49962 > 8.8.8.8.53: 45092+ AAAA? logs.netflix.com. (34)
21:17:09.293699 IP 192.168.1.92.49962 > 8.8.8.8.53: 17557+ AAAA? nrdp.prod.cloud.netflix.com. (45)
21:17:09.293704 IP 192.168.1.92.49962 > 8.8.8.8.53: 15435+ A? nrdp51-appboot.netflix.com. (44)
21:17:09.293708 IP 192.168.1.92.49962 > 8.8.8.8.53: 49981+ AAAA? nrdp51-appboot.netflix.com. (44)
21:17:09.293715 IP 192.168.1.92.49962 > 8.8.8.8.53: 52581+ A? nrdp.nccp.netflix.com. (39)
21:17:09.293719 IP 192.168.1.92.49962 > 8.8.8.8.53: 42306+ AAAA? nrdp.nccp.netflix.com. (39)
21:17:09.293724 IP 192.168.1.92.49962 > 8.8.8.8.53: 27213+ A? api-global.netflix.com. (40)
21:17:09.321424 IP 192.168.1.92.49962 > 8.8.8.8.53: 60092+ A? logs.netflix.com. (34)
21:17:09.344818 IP 8.8.8.8.53 > 192.168.1.92.49962: 45092 6/0/0 CNAME logs.dradis.netflix.com., CNAME logs.eu-west-1.internal.dradis.netflix.com., CNAME apiproxy-logging-7d0bf81651765786.elb.eu-west-1.amazonaws.com., AAAA 2a05:d018:76c:b684::5a89:1099, AAAA 2a05:d018:76c:b680::5a89:1099, AAAA 2a05:d018:76c:b682::5a89:1099 (254)
21:17:09.346588 IP 8.8.8.8.53 > 192.168.1.92.49962: 17557 6/0/0 CNAME nrdp.prod.dradis.netflix.com., CNAME nrdp.prod.eu-west-1.internal.dradis.netflix.com., CNAME apiproxy-nrdp-prod-nlb-1-bc4243efc68f31ae.elb.eu-west-1.amazonaws.com., AAAA 2a05:d018:76c:b685:9ae6:e07a:670d:52e4, AAAA 2a05:d018:76c:b683:194f:a5df:2ad1:ab02, AAAA 2a05:d018:76c:b684:b7f5:7e97:3e99:751e (283)
21:17:09.346728 IP 8.8.8.8.53 > 192.168.1.92.49962: 52581 8/0/0 CNAME nrdp.nccp.dradis.netflix.com., CNAME nrdp.nccp.eu-west-1.origin.prodaa.netflix.com., A 52.19.104.71, A 52.49.155.216, A 54.76.160.164, A 52.210.130.122, A 52.210.124.147, A 52.18.41.61 (214)
21:17:09.346868 IP 8.8.8.8.53 > 192.168.1.92.49962: 49981 10/0/0 CNAME appboot.dradis.netflix.com., CNAME appboot.eu-west-1.origin.prodaa.netflix.com., AAAA 2a01:578:3::3410:ea4e, AAAA 2a01:578:3::34d3:322, AAAA 2a01:578:3::34d4:c576, AAAA 2a01:578:3::34d3:3154, AAAA 2a01:578:3::3430:8bf6, AAAA 2a01:578:3::369a:f1ed, AAAA 2a01:578:3::22f0:a04c, AAAA 2a01:578:3::36f6:b554 (343)

Au weia! Es wird unge­be­ten Goo­gles DNS verwendet!
Fra­gen kom­men auf: Das Teil erkennt die per DHCP zuge­wie­se­nen Name­ser­ver — und ver­wen­det sie nicht. War­um? Das­Teil hat kein v6 und fragt doch nach AAAA. Warum?
Nun, ich zise­lie­re mir eine Firewall-Regel:

ubnt@sokoll-router:~$ show configuration commands
[…]
set firewall group address-group google-dns address 8.8.4.4
set firewall group address-group google-dns address 8.8.8.8
[…]
set firewall name LAN_OUT rule 20 action reject
set firewall name LAN_OUT rule 20 description 'Dem Fernseher Google DNS verbieten'
set firewall name LAN_OUT rule 20 destination group address-group google-dns
set firewall name LAN_OUT rule 20 destination port 53
set firewall name LAN_OUT rule 20 log disable
set firewall name LAN_OUT rule 20 protocol udp
set firewall name LAN_OUT rule 20 source address 192.168.1.92
set firewall name LAN_OUT rule 20 source mac-address '18:84:c1:bf:66:f1'
[…]

Und das wirkt, tataa!

root@sokoll-router:/config# tcpdump -i switch0 -n host 192.168.1.92 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:32:35.659906 IP 192.168.1.92.34723 > 8.8.8.8.53: 23537+ A? logs.netflix.com. (34)
21:32:35.659911 IP 192.168.1.92.34723 > 8.8.8.8.53: 44326+ AAAA? nrdp.prod.cloud.netflix.com. (45)
21:32:35.659916 IP 192.168.1.92.34723 > 8.8.8.8.53: 22112+ A? nrdp51-appboot.netflix.com. (44)
21:32:35.659920 IP 192.168.1.92.34723 > 8.8.8.8.53: 57120+ AAAA? nrdp51-appboot.netflix.com. (44)
21:32:35.659924 IP 192.168.1.92.34723 > 8.8.8.8.53: 44242+ A? nrdp.nccp.netflix.com. (39)
21:32:35.659928 IP 192.168.1.92.34723 > 8.8.8.8.53: 19783+ AAAA? nrdp.nccp.netflix.com. (39)
21:32:35.659932 IP 192.168.1.92.34723 > 8.8.8.8.53: 25321+ A? api-global.netflix.com. (40)
21:32:35.662950 IP 192.168.1.92.43839 > 8.8.8.8.53: 22191+ AAAA? api-global.netflix.com. (40)
21:32:35.662958 IP 192.168.1.92.43839 > 8.8.8.8.53: 64306+ A? secure.netflix.com. (36)
21:32:35.663031 IP 192.168.1.92.43839 > 8.8.8.8.53: 32983+ AAAA? secure.netflix.com. (36)
21:32:35.663041 IP 192.168.1.92.43839 > 8.8.8.8.53: 58766+ A? uiboot.netflix.com. (36)
21:32:35.663049 IP 192.168.1.92.43839 > 8.8.8.8.53: 59032+ AAAA? uiboot.netflix.com. (36)
21:32:35.663094 IP 192.168.1.92.43839 > 8.8.8.8.53: 47968+ A? customerevents.netflix.com. (44)
21:32:35.663132 IP 192.168.1.92.43839 > 8.8.8.8.53: 27882+ A? ichnaea.netflix.com. (37)
21:32:35.663181 IP 192.168.1.92.43839 > 8.8.8.8.53: 18226+ A? cdn-0.nflximg.com. (35)
21:32:35.663231 IP 192.168.1.92.43839 > 8.8.8.8.53: 20002+ A? nrdp.prod.ftl.netflix.com. (43)
21:32:35.663263 IP 192.168.1.92.43839 > 8.8.8.8.53: 42457+ AAAA? nrdp.prod.ftl.netflix.com. (43)
21:32:35.883642 IP 192.168.1.92.43839 > 8.8.8.8.53: 13421+ A? nrdp.prod.cloud.netflix.com. (45)
21:32:36.634192 IP 192.168.1.92.43839 > 8.8.8.8.53: 13421+ A? nrdp.prod.cloud.netflix.com. (45)
21:32:36.787647 IP 192.168.1.92.43839 > 8.8.8.8.53: 44242+ A? nrdp.nccp.netflix.com. (39)

Er befragt wei­ter­hin Goog­le, bekommt aber kei­ne Ant­wor­ten mehr 🤓
Und gleich­zei­tig füllt sich das Log vom piho­le. Und natür­lich funk­tio­niert das Smart am TV immer noch.

Hm, mir fällt gera­de auf, daß ich

set firewall name LAN_OUT rule 20 protocol udp

auf

set firewall name LAN_OUT rule 20 protocol all

ändern soll­te, nicht daß das Teil auf TCP umschwenkt irgendwann.

Was machen 99% der Smart­TV-Nut­zer? Die haben weder das Wis­sen noch die Tech­nik, dem Spio­nie­ren wenigs­tens ein wenig ent­ge­gen­zu­tre­ten. Klar könn­te man das Ether­net zie­hen und einen Fire­stick oder so direkt an HDMI anflan­schen. Aber ob der weni­ger spio­nie­ren würde?
Wobei ich sagen möch­te: Dem TV-Her­stel­ler wer­fe ich kei­ne Bös­ar­tig­keit vor, er lie­fert sei­ne Kun­den man­gels Sorg­falt ein­fach den Daten­kra­ken aus, was im End­ef­fekt aber egal ist. Das TV soll ein­fach das anneh­men, was man ihm sagt, und gut wäre es.

 

Home Assistant schön(er) gemacht

Home Automation, IT
Comments

Bei mir läuft Home Assistant 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 Upda­ten (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 chall­enge nicht. DNS chall­enge 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!

IT
Comments

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 Ashb­urn 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