Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - M_D

Stran: [1] 2 3 ... 25
1
Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN
« kdy: 03. 04. 2025, 23:33:45 »
Hele, pohledme do manuálu od AX1800, tak mám podezření, že ten OpenVPN server v TPlinku moc nepočítá s tím, že by se na něj připojovala celá síť? Možná počítá, že se připojuje jen koncový klient (jedne počítač). Takže můžeš mít problém mu říci, že do spojení 1 routovat segment 192.168.80.0/24 a na spojení 2 posílat 192.168.81.0/24.
Dle manuálu to má umět i wireguard, tam by asi mohlo jít toto zařídit pomocí nastavení allowed IPs (client)?

2
Desktop / Re:Možnosti RDP na linuxovém desktopu
« kdy: 03. 04. 2025, 10:18:22 »
ArnoldBorice: Pokud je to jen pro admin přístup, kdy mi stačí jeden ten dektop/připojení, tak ten NoMachine je asi celkem příjemná cesta. Tohle udělá i ta verze zdarma. Buď převezme a posílá ti existující fyzický dekstop (umí ho začernit při vzdáleném připojení) nebo pokud neexistuje, tak si vytvoří jeden virtuální a k němu se připojuješ (když třeba nemám vůbec grafiku v serveru).
Až kdybych chtěl víc desktopů a opravdu víc současně připojených lidí, kde si kažsdý šmrdlá ty svoje okénka, tak to jsou až ty placené verze.
Pro admina by ais stačilo i to x11vnc, spustí si jeden virtuální desktop a k němu se připojuješ pomocí VNC klienta. Pokud ho máš přímo ve svém distru, tak také cesta. NoMachine umí navíc to sdílení tisku/usb/přenosy souborů/mapování disků/...

3
Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN
« kdy: 03. 04. 2025, 09:46:19 »
Při myšlence přidat si tam malý Mikrotik a Zerotier, tak pozor na to, že jen pro některé architektury CPU to Mikrotik umí. Zdá se, že stále platí omezení pro modely s ARM/ARM64 procesorem: https://help.mikrotik.com/docs/spaces/ROS/pages/83755083/ZeroTier

Jiná možnost je nějaké malé RPi, do toho Zerotier nebo jiný typ VPN půjde nacpat...

Žádná krabice neí dokonalá. A kdy už umí vše, tak zase je udělaná tak, že nesplňuje třeba požadavky na EMC. :-)

4
Server / Re:Forward proxy, ktera umi zakazat ipv6
« kdy: 03. 04. 2025, 09:37:39 »
Ve squidu jsem používal:
Kód: [Vybrat]
## pro IPv4 pouze provoz
tcp_outgoing_address 89.a.b.c


## IPv4/6 rezim
# pravidlo detekujici spojeni na IPv6 cil
acl to_ipv6 dst ipv6
tcp_outgoing_address 89.a.b.c !to_ipv6
tcp_outgoing_address 2a02:a:b:c::d to_ipv6

5
Desktop / Re:Možnosti RDP na linuxovém desktopu
« kdy: 02. 04. 2025, 22:17:15 »
Tazatel popsal celkem jasně, že připojení má vytvořut novou grafickou sešnu a v ní si chce lebedit graficky podobně, jak když přistupuje textově pomocí SSH... Nu, doba starému a nedobrému XDMCP už odzvonila....
Takže tomu nejblíže odpovídá to xrdp, kde si vystačí s RDP klientem. Jiné řešení jsou ty varianty nad starší verzí NX protokolu FreeNX, X2go, .... S xvnc se dá něco podobného dosáhnout, kdy si ty desktopy naspouštím dopředu a pak se na ně připojuji. Ale je to asi stále vše pro X.org, který začíná být trochu out of day. :-(
Je zmíněn originální NoMachine. Ten zdarma (nebo placený NoMachine Desktop) nevytváří nový virtuální desktop pro připojené, je to přístup k živému fyzickému desktopu na styl VNC, TeamViewer, RustDesk, ...
Placené verze NoMachine Workstation/Terminal server dělá co chce (liší se cenou, funkcemi, počtem virtuálních desktopů) a umí i Wayland. Umí to přistupovat i k tomu fyzickému desktopu.
Takže otázka je, zda existuje pro linux a multi user grafický přístup něco rozumně použitelného dalšího (včetně těch případných dalších příjemností - typu sdílení a předávání dekstopu mezi víc lidí, usb, tisk, disky, smartcard, ...). {Ano, Citrix VDI vím, ale to je asi trochu jiný level}

6
Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN
« kdy: 02. 04. 2025, 22:00:32 »
Pokud se mu podaří dostat do těch TP linků OpenWrt, tak pro něj už je třeba Zerotier klient k mání. Co pak zkusit tunelovat pomocí toho? Pokud ty CG-NATy před tím nejsou typu "symmetric", tak to centrální Zero servery použije jen k proražení UDP a jede provoz napřímo.
Podobných řešení je víc, tohle je takové user friendly outboxové. :-)

7
Add původní tazatel: Pokud jsou ty kamery mimo přímý zásah blesku a i odstup je rozumný, tak z pohledu chránění zbytku v místě toho switche, tak zvažovaný switch (dle toho odkazu) má SFP, takže napojit na zbytek LAN v baráku přes optiku. Switch má dle fotky zemnící šroub a plechařina na DIN lištu, tak přizemnit. Na tu napájecí linku 48 Vdc dát příslušnou DC48V přepěťovku a také přizemnit. Jestliže tam mám přivedenu Cu10, tak pokud by to dál ke kamerám bylo dle kostelního pořádku, tak je to dostačující, stačila by Cu4. Pokud není, vhodnější by byla Cu16, ale i desítka je o řády lépe, než Cu2,5 v zásuvce. :-)
Plusem by bylo, pokud ty Ethernet kabely ke kamerám jsou stíněné, pak stínění před switchem mezi sebou propojit a přizemnit přímo také, to dokáže dost zachránit. Ideál by byly přepěťovky na ty signálové Ethernet vodiče, to omezí to, ať ti bordel od jedné kamery nedoběhne k druhé, případně do switche. Ono do signálových vodičů proleze nějaký bordel i skrz to stínění. Ale už to naskáče na ceně, pokud tam bude 8 kamer a switch stoji jen 1500 Kč. :-) Leda nějaké pěkný patchpanel, co by to měl rozumně integrováno. Samozřejmě by ty kabely ke kamerám se měly dost vyhýbat ostatním LAN v baráku.
Kostelní pořádek by chtěl, aby ty Ethernety v místě prostupu z baráku ven měly přepěťovky na sobě a bylo to tam přitaženo přímo Cu4 na zem domu, ale tím se to již komplikuje. A pokud od této přepěťovky je k vlastní kameře dál, jak metr-dva, tak teoreticky i přímo přepěťovka u ni, ale to už hraje ta cena kamery, zda ji neobětovat (a navíc zde by jsi měl mít už svod na patu domu Cu16 a k tomu chycenou i konzoli kamery). Ale i be ztohoto ti to dává šanci, že to přežije bordle vzduchem od zásahu někde vedle, přímo do baráku již nikoliv.
Jinak je zmíněno, že ten rozvod 48Vdc je živen z FVE, ta asi nebude ve sklepě? Pak je snad věnována podobná péče i té straně FVE do baráku, ať ti nepřiběhne bordel tudy. :-)

8
bobr: No,  pokud to máš bez bleskosvodu, tak těsně pod taškama se bere stejně jak nad nima. :-(
Respektive se považuje, že prostor chráněný před přímým zásahem blesku je 2 metry uvnitř pod střechou. Takže pokud celou tu sestavu (i s anténou) mám na půdě a 2 metry uvnitř od střechy, tak jsi na tom stejně, jak původní tazazel, pokud on má ty kamery venku ve "stínu" bleskosvodu.
Chápu, že ti nahoru vede metalický Ethernet a dvojlinka s 24 V. Ethernet poslat optikou, když tam máš SFP. Barák snad bude mít dole zemnič a něco jako hlavní uzemňovací svorku baráku - od ní přivést Cu 16 nahoru (ideálně v nějakém odstupu od té dvojlinky) a tam prozemnit k tomu. Na tu dvojlinku tam osadit přepěťovku DC24V a také přizemnit k tomuto. Stejně tak by bylo vhodně dát DC24V přepěťovku dolu, kde máš ten rack a tam to prozemnit mezi sebou a přivést aspoň Cu4 k hlavní svorce.
To je ten pohled ochrany proti "útoku zhora". Samozřejmě doplnění bleskosvodu je doporučení vhodná varianta, stejně tak ochrany na přípojku napájení do baráku. :-)

9
Odkladiště / Re:Co přinese sloučení Nej.cz s O2?
« kdy: 26. 03. 2025, 12:59:01 »
Ve vší obecnosti: Služba O₂ Security blokuje stránky s nelegálním obsahem (nacistické, pedofilní,…), ale i tzv. dark weby, stránky obsahující pornografii a erotické materiály. :-)
Detialy možná zde: https://www.o2.cz/osobni/internet/o2security

10
Myslím, že původní tazatel se už neozve a raději odletěl. :-)
Jak to zapojit má třeba zde https://www.saltek.eu/files/document/19/Prirucka_Slaboproude_systemy.pdf obrázek 66 na straně 29 a IP kameru si představí tam, kde je ta venkovní wifi parabola a PoE switch místo toho routeru. Předpoklad je, že ty kamery jsou v místě chráněné před přímým zásahem. Pak tam někde dál popisují doporučení pro kamerové systémy (kapitola 7).
Pokud je kamer víc, tak se dá řešit jinak, protože se to začne prodražovat, pak se jde cestou obětování PoE switche a ochrany až od něj dál. Ale to bez bližšího popisu situace je jen zmíněná možnost...

11
Hardware / Re:DIY PowerWall
« kdy: 17. 03. 2025, 18:57:31 »
FEKT na VUT a nebo FEL na CVUT nemaji nejaky On-Line kurz?archive.md/nlzDJ
Tohle online ti fakt nikdo nedá. :-(
Ale pokud chceš touto cestou, tak tady je třeba první krok na celkem dlouhé cestě: https://jubela.cz/rekvalifikacni-kurzy/kurz/elektrikar/
Myslím, že to Bluetti bude levnější a rychlejší cesta. :-) Už vtip toho zákona 250/2021 Sb. je schovaný v tom, že nepřipouští, abych si něco takového hobby doma dělal. Předpokládá, že to dělá právnická osoba nebo OSVČ s příslušnými papíry a ne soukromá fyzická osoba pro sebe...
A nepomůžeš si, pokud by jsi šel druhou cestou (kterou bude mít za sebou ta Bluetti bedna), přes uvádění nového výrobku na trh (zákon č. 22/1997 Sb.), skončíš u stejných norem/věcí, jako když to půjde cestou instalace dle 250/2021 Sb...

12
Server / Re:SSH heslo vs. klíč?
« kdy: 17. 03. 2025, 18:36:18 »
Krome hesla a klice je jeste k dispozici kerberos ticket (popr ssh certifikat, ale k tomu neexistuje rozsirena infrastruktura).
Kerberos je imho jeste lepsi volba.

S tím Kerberosem (GSSAPI) souhlasím na úrovni jednoho subjektu/firmy - lezu na X serverů v rámci jedné řízené domény, tak je to hodně přijemné.
Pokud musím skákat po jednom/dvouch serverech u X jiných subjektů, tak ten SSH klíč je asi základ/standard.

On jde i ten SSH klíč nebo certifikát automatizovat třeba přes LDAP, ale je to už je to větší pakárna na údžbu. Jakási integrace je v kombinaci s SSSD, ale jde si to naskriptovat v sshd asi čímkoliv a jakkoliv s voláním AuthorizedKeysCommand / AuthorizedPrincipalsCommand.

13
/dev/null / Re:Ministerstvo nerozumi jak internet funguje
« kdy: 13. 03. 2025, 20:03:25 »
Ehm, než začnu shánět letenku do Severní Koreje, co se podívat přesně, jak se mění už cca 10 let platná legislativa?
Týká se to jen připojení, kde je koncák za CGNAT, kdo má veřejnou IP adresu, tak pro toho se nic nemění, ISP si jen vede seznam, kdo(kdy měl jakou IP přidělenu. Kdo je za CGNAT, tak už 12 let uchovává ISPík fakticky info o každém odchozím spojení (příloha k vyhlášce č. 357/2012 Sb.):
3.3.7 u služby přístupu k internetu s překladem adres IP
3.3.7.1 privátní adresa IP,
3.3.7.2 veřejná adresa IP a číslo portu nebo přidělený rozsah portů,
3.3.7.3 datum a čas zahájení překladu adres ve formátu DD.MM.RRRR HH:MM:SS,
3.3.7.4 datum a čas ukončení překladu adres ve formátu DD.MM.RRRR HH:MM:SS,
Nově návrh přidává bod:
3.3.7.5 adresa IP a číslo portu, ke kterým bylo připojení uskutečněno.

Dosud legislativně tak u CGNAT linek jsem  měl ukládat jen zdrojový IP:port CGNAT brány a k tomu info, který kocnák to byl. Nyní ukládám i kam to spojení mířilo, ale jen na úrovni IP:port. Fakticky se stejně ukládalo i toto, co teprve teď do to vyhlášky přiskakuje jako ten 3.3.7.5 bod, protože to v těch netflow datech je odjakživa.

14
Server / Re:HTTP/S a certifikáty v embedded zařízeních
« kdy: 12. 03. 2025, 10:55:09 »
Řeší se interní CA.

Díky. A jak s tím zkracováním akceptované délky platnosti certifikátů? Je nějaký standard pro vydávání certifikátů interní CA (něco jako ACME), který by se běžně na embedded zařízeních používal - tedy něco jako že se zadá jen název stroje s interní CA a ono si to už bude o certifikáty žádat samo, pomocí standardního protokolu, všechny "krabičky" stejným způsobem?

Zkracování se týká těch veřejných CA. Pokud si udělám vlastní privátní CA a naimportuji do prohlížeče/OS, tak stále ve Firefoxu, Chrome, Edge jedou dlouhé doby platnosti. Jen Safari to řeže a odmítá certy s platností nad 2 roky (nad cca 384 dní). Chrom na jabkách to také nějakou dobu takto dělal, co používal OS validátor, ale asi to už opravili.
Tohle je ale řešení pro firmu a interní/technologické systémy. Pro veřejnost ne.
Protokolů je několik, včetně historického SCEP, ale z pohledu embedded světa to skoro nic neumí. U řady ani nejde ručně vyměnit to, co tma je od výrobce/samo si vygenerovalo při zapnutí. V řadě případů u nejrůznějších technologických embedded krabic, tak i u nových, je HTTPS stále sprosté slovo. Nebo zapnutí HTTPS tu krabici totálně odvaří, protože je v tom CPU, co to nedává. Třeba si hraju teď s analyzátorem plynů, bedna za XX MKč, má to web, po zapnutí HTTPS přestane půlka věcí fungovat a přihlášení trvá cca 10 minut, proti pár vteřinám na HTTP a ve většině případů to skončí timeoutem. Něco, že by šlo třeba změnit default heslo, tak to je z říše snů.... To je ta technologicko/výrobní realita zmiňovaná o příspěvek výše. :-)

15
Server / Re:HTTP/S a certifikáty v embedded zařízeních
« kdy: 11. 03. 2025, 18:25:22 »
Řeší se interní CA. Ale občas ne jednou, protože řada věcí ani nerozdýchá certifikáty s SHA256 a spokojeně si mrzne v době MD5/SHA1 a podobné...
Jinak se řeší izolací, k tomu je virtuál s něčím jako Win7 a starší a v něm dostatečně starý prohlížeč. Což je také cesta, jak udržet některé takovéto stařešiny v provozu. Jsem zvědav, zda se dožiju vyhlazení Windows NT4.0 z mého středně vzdáleného technologického okolí. :-)

Stran: [1] 2 3 ... 25