Příspěvky

1

Hardware / Re:Doporučte tankovou inkoustovou tiskárnu

« kdy: 03. 08. 2025, 09:47:16 »

Formát, funkce, požadavky třeba na spolehlivý tisk při zemětřesení... ?

Dělá Brother jen čisté bublifuky nebo už je to vše multifunkce? Já měl primární požadavek domů na sken A3 (mám 3x víc naskenováno než vytisknuto, načmárám něco v ruce a pošlu kresličům), takže ekonomicky a místem vycházel jen bublifuk. Takže jsem měl 15 let MFC-J6910DW. Vše OK, nezasychala.
Jen při neorigoš náplních zasychala, ale vždy  jen žlutá barva (od několika dodavatelů). Když se rozpadla hlava, řešil jsem náhradu před půl rokem.
Následovník je MFC-J6955DW, ale sáhl jsem po nižší řadě MFC-J3940DW. Zatím spokojenost, pokrok je vidět.

2

Sítě / Re:MikroTik mAP 2nd v ČEZ Battery Boxu

« kdy: 29. 07. 2025, 20:31:37 »

Také se mi jeví, že to mAP slouží jako lokální wifi AP na které se připojuje ten baterkový box a mAP má metalicky připojeno do toho Deco a odtud to jde dál. Samozřejmě to mAP může blbnout, nebo i ta wifina v tom boxu.
Ten box má normálně jen wifi konektivitu, jako klient (nepočítám možnost rozšiřující RS485 karty). Takže to mAP je asi dobastl, aby to mělo metalickou konektivitu, že jinak se na to Deco ze sklepa nebyl schopen bezdrátově připojit.
Hele, předhodil jsi otázku i výrobci -> https://www.oigpower.cz/podpora
Pokud se do mikrotiku dostaneš (přes web prohlížeč nebo Winbox aplikaci?), tak v době, kdy to funguje, bych se podíval, zda je pod wireless / wireless / registration vidět připojený klient (to by měl být ten ESP) a podobně se podívat, když to nefunguje, zda je připojen. Asi první nástřel. V logu toho mAP by mohlo být vidět, kdy se klient případně připojil/odpojil a zda ti to bude korelovat s ne/komunikací dál.

3

Server / Re:Housing - cena elektřiny

« kdy: 29. 07. 2025, 09:26:59 »

Jak si koupím elektrickou energii v Německu?

Ano, můžu. V podstatě buď koupím přímo od výrobce (od elektrárny) nějaký výkon na patě jeho elektrárny, ale asi se nechceš uvazovat na X let odběru.
Nebo můžeš koupit od jakéhokoliv registrovaného prodejce/dodavatele elektriky v rámci EU i jako koncový zákazník. Druhá věc, zda bude ochoten uzavřít smlouvu a drbat se s maloodběratelem v tramtárii. Ale nic tomu nebrání, je to tak perfektně v souladu se směrnicí EU o společných pravidlech pro vnitřní trh s elektřinou (u plynu je to trošku jinak). Situace se změní s rozdělením EU na samostanté obchodní zóny, což se už pár let diskutuje, pak nákup přes hranici zóny bude komplikovanější (omezenější/dražší).
Taktéž trochu to rozbijí nové alokační rovnice, které mají podpořit odběr od místní produkce (v čím větší dálce koupím, tím méně mi bude započteno v místě spotřeby), aby se podpořila místní spotřeba do 300 km - to se týká toho přímého nákupu od elektrárny.

4

Sítě / Re:Routing provozu z více WAN

« kdy: 17. 06. 2025, 09:36:51 »

Mikrotika bych ještě do žita neházel (je to neekologické). Nebyl uveden ten typ VPN, ale dle toho povzdechu nad Torch, tak asi jde o čistý IPsec tunel. S tím to fungovat nebude. Na straně VPN serveru to proběhne dobře pro příchozí pakety z Internetu, ale až se provoz vrací tunelem zpět, tak prochází stackem trochu jinak, že se neuplatní plně reverzní operace k těm prvotím NATům a paket se pošle do WAN s blbejma IPčkama (to je i vidět přes Torch).
Pokud trvám na IPsec, třeba kvůli HW akceleraci šifrování, tak bych použil GRE tunel a ten obalil pomocí IPsec transportu (nebo pokud ti koncoví klienti jsou za CGNAT nebo nemají pevné IPčka, tak spíče kombinaci L2TP/IPsec). Tím donutím vracející se paket plně projít stackem a bude to fungovat.
Také se to lépe chytá tím Torchem, protože do GRE nebo L2TP iface vidí. :-)
V druhém kole se můžu zbavit toho SRCNAT způsobem, jak bylo zmíněno. Označkuji si spojení došlé na VPN klientovi došlé z tunelu pomocí connection mark a pak na základě connection mark nastavím router mark na alternativní routovací tabulku, které pak vratí provoz natvrdo zpět do tunelu.

5

Sítě / Re:Routing provozu z více WAN

« kdy: 16. 06. 2025, 15:13:38 »

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále? Co to je zač a jaký typ VPN je použito? Ono občas nejde kombinovat některé věci v jednom, často je problém NAT a čistý IPsec tunel, pokud to je na jednom stroji, protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Čím realizuješ tu stranu VPN klienta? Routuješ správně na straně těch vzdálených sítí do tunelu tu IP,  kterou použiješ v tom SRCNAT na centrále? Samozřejmě by bylo hezčí řešení, pokud ten VPN klient na pobočkách je zároveň i wan brána do inetu, tak na něm pomocí značkování spojení si vést, co vracet do tunelu a co pustit přímo ven.

6

Sítě / Re:IPsec a problém s SMB

« kdy: 24. 05. 2025, 10:00:08 »

Čistý IPsec tunel site-to-site? Možná to rozbil ten Mikrotik, postřehl jsem nějaké nářky, že cca od ROS7.16, pokud IPsec začne fragmentovat, tak prohazuje pořadí jednotlivých fragmentů, což obvykle nedopadne pak dobře. To s tím oživením pomocí OpenVPN by napovídalo.
Ono při tom ověřování může proběhnout i něco přes UDP ohledně Kerberosu a na to nějaké mangle s mss neplatí. :-)
Pokud chci zachovat IPsec (třeba kvůli HW akceleraci šifrování), tak bych zkusil GRE tunel obalený pomocí IPsec transportu a MTU v GRE nastavit tak, aby už IPsec vrstva nemusela dělat fragmentaci. Já mám takto na GRE dané MTU1432 (ale to si musím poladit dle použitého algoritmu ESP).

7

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)?

8

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ů/...

9

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. :-)

10

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


11

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}

12

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é. :-)

13

Sítě / Re:Připojení PoE switch pro venkovní síť ke společnému DC napájení

« kdy: 26. 03. 2025, 16:10:51 »

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. :-)

14

Sítě / Re:Připojení PoE switch pro venkovní síť ke společnému DC napájení

« kdy: 26. 03. 2025, 15:48:58 »

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. :-)

15

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