Příspěvky

1

Sítě / Re:Jak získat vlastní IPv6 rozsah?

« kdy: 27. 11. 2025, 16:40:11 »

Co mi to jen připomíná… 

Jj, VISSADO :-)  Bylo to pro ukázku, kdo mi přišel nejblíže na paměť i s nějakým ceníkem pro tazatele...

Jenže když nemá ani dvě ty domácí linky s funkčním IPv6, tak reálně stejně skončí u nějaké té VPS varianty a tunel přes IPv4...

2

Sítě / Re:Jak získat vlastní IPv6 rozsah?

« kdy: 27. 11. 2025, 16:25:29 »

Z pohledu původního tazazele. Situace je stejná pro IPv4 i IPv6, získat blok PI (Provider Independent) adres (IPv4 /24 už nejsou, jen IPv6 /48). Je pár subjektů, co zo zajišťuje za nějaký bakšiš. Např: http://isp-servis.cz/?page_id=312

ALE, není to pro home usera, získat adresy je jedno, horší je domluvit routing se svými uplinky, to nebude nic pro SOHO linky.

Na doma (když beru řešení, kdy do toho nepletu další subjekt) pro IPv6 tak v podstatě jako "jednoduché" řešení použít IPv6 ULA adresy a k tomu provádět na odchozí lince NPT / NAT pro IPv6. V tomto případě má zařízení v LAN jen tu ULA (a link local adresu). Druhá cesta je dynamický renumbering, kdy zařízení má stabilní "vnitřní" ULA a k tomu jednu a více globálních IPv6 adres podle toho, jaké linky jedou. Ale dost to záleží, co umí ten domácí router. Většina jich s multi WAN na IPv6 moc nepočítá. :-(

Sám něco takového mám doma s mikrotikem a třemi WAN linkami. Používám ULA, ty mám i v interním DNS, globální prefixy se propagují z routeru, koncové krabice mají tak víc adres a router dle ne/dostupnosti linek mění ohlašovaný preferred lifetime na 0 u mrtvých linek.

3

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« kdy: 08. 11. 2025, 17:41:26 »

Nějaký manuál, application note zaměřený na venkovní instalace?

Obecně postupy řeší:
ČSN EN 61663-1 Ochrana před bleskem - Telekomunikační vedení - Část 1: Instalace s optickými kabely
ČSN EN 61663-2 Ochrana před bleskem - Telekomunikační vedení - Část 2: Vedení s kovovými vodiči
Zabývá se nadzemím i podzemím...

K prapůvodnímu tazateli: u nového bych šel do té optiky. Coax, pokud by tam nějaký už ležel a jen řešil jaké krabičky na to připojit.

4

Sítě / Re:Rozvod optiky po bytě T-Mobile

« kdy: 15. 10. 2025, 21:50:06 »

Nechat zakončit optiku v chodbě hned za dveřmi (řada operátorů to ani dál nechce tahat, protože při poškození by to museli opravovat) a koupit si tenký transparentní patchcord a klidně ho nadrzo přilepit na zeď transparentním mamutem někde pod stropem (ve výšce, kde neplánuji vrtat obrázky/hák na tchýni) a dotáhnout pak někam, kam si dám ten router.
Něco jako: https://www.tesshop.sk/opticky-patchcord-sc-apc-sc-apc-10m-0-9mm-simplex-sm-g657b3-transparentny_d5935.html
Tohle má i poloměr ohybu kolem 3 mm, takže ani v rohu není problém. U nás se dá asi sehnat u Opticordu nebo řeší Ali. :-)

5

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.

6

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.

7

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.

8

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.

9

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.

10

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

11

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

12

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

13

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

14

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


15

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}