Příspěvky

1

Studium a uplatnění / Re:Trh práce pro samouky a rekvalifikační kurzy

« kdy: 18. 03. 2025, 16:14:46 »

Přítelkyně absolvovala změnu oboru z personalistiky, kterou dělala 20 let, směrem k práci s daty. Teď je dva roky ve firmě, kde začínala na juniorní pozici BI specialisty, rychle se posunula na mediorní pozici a aktuálně začíná řídit nějaké projekty včetně komunikace s klienty.
Její cesta k této změně oboru vedla přes samostudium, absolvování nějakých kurzů  - někdo tu už zmínil Czechitas - tak tam, co si vzpomínám, absolvovala kurz Javy, datové analýzy, SQL, Power BI a dalších. To portfolio bylo vcelku široké, snažila se mít obecný přehled, než úzkou specializaci.
Žádné vlastní projekty neměla, jen to co absolvovala v těch kurzech. Obešla pár pohovorů a u té firmy, kde zakotvila, zřejmě zjistili, že má, kromě nějakých znalostí oboru i jistý způsob uvažování, který jim vyhovuje, je ochotná se učit a dál se rozvíjet a tak si plácli. Během těch dvou let se neskutečně posunula, aktuálně jí na její žádosti o pomoc s problémy říkám, že v tom oboru je už mnohem dál než já a pomoct jí neumím.

2

Vývoj / Re:Projekt na Raspberry Pi a Python

« kdy: 08. 01. 2025, 18:17:23 »

Z vlastní zkušenosti dodávám, že fotorezistor není jen hodně pomalá součástka, ale je to fakt extrémně pomalá součástka, jejíž odezva bývá běžně v řádu nižších stovek milisekund a je pro jakýkoli digitální přenos velmi špatně použitelná.
Raději bych se zaměřil na fotodiody, které nabízejí odezvu o několik řádů rychlejší a pro datové přenosy se hodí podstatně více.

Kdysi dávno jsem měl funkční Ronju: https://cs.wikipedia.org/wiki/Ronja.
Tam by mohl autor vlákna jít pro inspiraci, jaké součástky použít.

Ono totiž na vzdálenost větší než malou bude potřeba ten signál z fotočlenu zesílit a neztratit se v šumu. Tam dělič stačit nebude.

http://ronja.twibright.com/
http://ronja.twibright.com/schematics/
http://ronja.twibright.com/ds.php

3

Vývoj / Re:Projekt na Raspberry Pi a Python

« kdy: 08. 01. 2025, 18:06:00 »

Z vlastní zkušenosti dodávám, že fotorezistor není jen hodně pomalá součástka, ale je to fakt extrémně pomalá součástka, jejíž odezva bývá běžně v řádu nižších stovek milisekund a je pro jakýkoli digitální přenos velmi špatně použitelná.
Raději bych se zaměřil na fotodiody, které nabízejí odezvu o několik řádů rychlejší a pro datové přenosy se hodí podstatně více.

Kdysi dávno jsem měl funkční Ronju: https://cs.wikipedia.org/wiki/Ronja.
Tam by mohl autor vlákna jít pro inspiraci, jaké součástky použít.

http://ronja.twibright.com/
http://ronja.twibright.com/schematics/
http://ronja.twibright.com/ds.php

4

Odkladiště / Re:Fotovoltaický ohřev vody

« kdy: 28. 06. 2023, 12:01:03 »

Další otázka je, co udělá současný solární boom s cenami energie v době, kdy slunce svítí a všichni vyrábí ( a myslí si, že šetří ). 
Přitom by v té době třeba mohli odebírat "zadarmo", jen za cenu distribučních poplatků.
To pák může návratnost mizet někde v nekonečnu.
Bohužel nikdo nedokáže předpovědět, jak to bude.

Ono se to vcelku predikovat dá. Stačí se mrknout na https://www.ote-cr.cz/cs/kratkodobe-trhy/elektrina/denni-trh?date=2023-06-25. Tohle je třeba stav v neděli, kdy svítilo jak o život a nebyla spotřeba. I v jiných dnech je vidět, jak ráno, večer a v noci je cena za MWh jinde, než přes den. S rostoucím podílem FVE se tohle bude stávat častěji.  Jinak, co se týká běžného spotřebitele, tomu je to jedno, kdy odebírá, protože to má za stejnou cenu. Např. já mám tarif D57d kvůli tepelnému čerpadlu a rozdíl v ceně EE v NT a VT je tam minimální.

Co se týče tématu ohřevu TUV pomocí FVE, taky se na to chystám a to formou bojleru, předřazenému před TČ. Bohužel bydlím v místě, kde nemám povolen přetok do DS, takže tímto budu FVE vytěžovat a ušetřím kompresor TČ v létě.
Navíc, dneska všichni obchodníci vykupují přetoky z FVE za spotovou cenu, tedy i za tu zápornou, takže v okamžiku, kdy FVE vyrábí nejvíc, inkasuje nejmíň, nebo i doplácí. K tomu poplatek za dodávku do DS je pořád stejný.

5

Sítě / Re:OpenVPN a síť za klientem

« kdy: 23. 06. 2023, 11:40:46 »

Tak abych to shrnul, kombinací různých návodů jsem dospěl k cíli. Není třeba nastavovat žádná pravidla v iptables ani na VPS, ani na klientovi, který je "bránou" do LAN.

1) Na VPS jsem vytvořil adresář /etc/openvpn/ccd
2) V tomto adresáři jsem vytvořil soubory, které musí mít stejná jména, jako jsou pojmenováni klienti při jejich vytváření

V mém případě:

Kód: [Vybrat]

root@darked:/etc/openvpn/ccd# ls -la
drwxr-xr-x 2 root root 4096 Jun 23 10:49 .
drwxr-xr-x 5 root root 4096 Jun 23 10:12 ..
-rw-r--r-- 1 root root   79 Jun 23 10:45 mobil
-rw-r--r-- 1 root root   73 Jun 23 10:45 raspberry

3) Soubor raspberry, který přísluší klientovi, který je "bránou" do 192.168.100.0/24 má obsah:

Kód: [Vybrat]

ifconfig-push 10.8.0.60 255.255.255.0
iroute 192.168.100.0 255.255.255.0

4) Soubor mobil má obsah:

Kód: [Vybrat]

ifconfig-push 10.8.0.50 255.255.255.0
push "route 192.168.100.0 255.255.255.0"

Ostatní potenciální klienti analogicky s jinou přiřazenou statickou adresou

5) Do konfigurace OpenVPN serveru na VPS jsem přidal řádky:

Kód: [Vybrat]

client-config-dir /etc/openvpn/ccd
client-to-client
Teď si už i moje žena umí otevřít garáž pomocí mobilu, když si zabouchne klíče od domu

Pane Ryšánku, díky za konzultaci a nasměrování.

6

Sítě / Re:OpenVPN a síť za klientem

« kdy: 22. 06. 2023, 22:47:33 »

Taky jsem ještě hledal a asi jsem dospěl ke stejnému závěru https://www.pr-software.net/openvpn-routing/

7

Sítě / Re:OpenVPN a síť za klientem

« kdy: 22. 06. 2023, 22:05:07 »

Ještě jak jste navrhoval insertnout do chainu POSTROUTING to specifické pravidlo pro 192.168.100.0/24, nestálo by za pokus, namísto RETURN použít  ACCEPT...?
Pardon, asi blbost, pokud v tcpdumpu vidíte pakety odcházet do tun0.

Zkusil jsem, chová se to stejně.
Mám na VPS dva terminály, jeden s příchozí komunikací přes tun0 a druhý s odchozí přes tun0. V obou terminálech ten paket je vidět, ale na raspberry už vidět není ... kontroloval jsem na raspberry iptables a není tam nic, co by mělo vadit.

8

Sítě / Re:OpenVPN a síť za klientem

« kdy: 22. 06. 2023, 21:09:12 »

Máte tcpdump taky v té VPSce? Hodilo by se mrknout právě tam: zjistit, kde je provoz vidět, a kde už ne.

Ano, mám .. je tam vidět vše, co přijde na tun0 z VPN, mezi klienty vše OK, ping request z klienta na 192.168.100.x je vidět taky.

Nemáte v iptables v té VPSce pravidlo, které by zakazovalo, příchozí paket forwardnout ven tímtéž rozhraním? Protože z hlediska kernelu netdevice tun0 má namapovaný jediný subnet, ve kterém se zjevují přihlásivší se klienti.

Ne, nemám

Koukám nejspíš používáte režim server + dev tun + topology subnet... IPčka tunýlkům přidělujete staticky podle loginu?

Ano

Na VPS jsem zjistil, že všemu, co přijde z VPN a nemá cíl ve VPN, se změní source IP

s/zjistil/zajistil ? :-)

Proč vlastně tam máte ten překlad? Vy z té VPSky taky chodíte z tunelových klientů do divokého internetu?

zjistil

Ten překlad tam přidala instalace OpenVPN.

9

Sítě / OpenVPN a síť za klientem

« kdy: 22. 06. 2023, 20:04:13 »

Zdravím,

zprovoznil jsem si OpenVPN server na VPS a klienta na Raspberry v domácí síti a na mobilu. V rámci VPN (10.8.0.0/24) vše funguje, z mobilu si prohlédnu dashboard v Grafaně na Raspi, v tcpdump na Raspi vidím komunikaci atd.
V domácí síti mám i nějaké IoT (192.168.100.0/24), ke kterým bych měl rád taky přístup z mobilu, ale do VPN je přidat nemůžu.

Fórum jsem prostudoval, ale řešení jsem nenašel, proto se ptám tady.

Předpokládám, že musím zajistit aby:
1) pakety z mobilu (10.8.0.3) s dotazem na 192.168.100.x, které přijdou na VPN server (10.8.0.1),  odešly na Raspberry (10.8.0.2)
2) následně na Raspberry došlo k překladu z tun0 (10.8.0.x) na eth0 (192.168.100.x) a odpovědi zpět

Na VPS jsem zjistil, že všemu, co přijde z VPN a nemá cíl ve VPN, se změní source IP

Kód: [Vybrat]

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      400 38664 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:89.185.xxx.yyy

Předpokládám, že bych to mohl vyřešit takto:

Kód: [Vybrat]

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      143  8700 RETURN     all  --  *      *       10.8.0.0/24          192.168.100.0/24
2      400 38664 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:89.185.xxx.yyy

Dál jsem se díval do routovací tabulky na VPS:

Kód: [Vybrat]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         89.185.xxx.1    0.0.0.0         UG    0      0        0 ens192
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
89.185.xxx.0    0.0.0.0         255.255.255.0   U     0      0        0 ens192

Chyběla mi tam cesta k 192.168.100.0/24 přes tun0 na Raspi

Kód: [Vybrat]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         89.185.xxx.1    0.0.0.0         UG    0      0        0 ens192
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
89.185.xxx.0    0.0.0.0         255.255.255.0   U     0      0        0 ens192
192.168.100.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0

V tento okamžik jsem si myslel, že na Raspi uvidím v tcpdump na tun0 ping request s odesílatelem 10.8.0.3 a cílem 192.168.100.200 ale bohužel ...

Je moje uvažování zcela zcestné? Nebo není a mám tam chybu?
Díky za odpovědi.