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

Stran: [1] 2 3 ... 25
1
Windows identifikuje siet pomocou NLA:

1) domenove meno (DHCP domain name) a ci k danej domene existuje znama AD
2) ip rozsah subnetu
3) dostupnost konektivity a verejna ip (probe na msftncsi.com)

2
Sítě / Re:Dvouportový PoE switch pro kamery
« kdy: 25. 06. 2025, 10:34:24 »
Mikrotik robi 4-portovy extender GPeRx4 -- co nie je switch v pravom zmysle slova, porty sa vedia bavit iba s portom 1, nie navzajom -- co na kamery vyhovuje. Na napajanie z uplinku vyzaduje PoE++ (bt), na jednotlive porty potom distribuuje PoE af/at.

Okrem toho robia aj realny 2-portovy switch GPeR, ale to sluzi na trocha iny ucel.

3
Sítě / Re:Vodafone (exUPC) vs. PODA (GPON) Internet
« kdy: 09. 06. 2025, 13:44:59 »

...I ten proklínaný iTunes na Windows prostě funguje.

USB mají všechny mobily a i flashy pro lightning existují, často duální s USB na opačném konci.

Itunes pre Windows este existuje? Pretoze pre MacOS uz davno nie. (Neviem, nemam prehlad o situacii iOS+Windows, pytam sa).

USB ma kazdy mobil; koniec koncov 99% pouzivatelov ho cez USB nabija. Od zavedenia USB-C je mozne pripajat aj kluce a inu bizuteriu bez OTG adapterov.

4
Server / Re:Migrace Samba AD na Windows server
« kdy: 09. 06. 2025, 12:44:20 »
A este je tu jedna vec, s ktorou sa pri migracii Samby da strelit do nohy: FSMO role.

Po pripojeni noveho DC treba premigrovat FSMO role, az potom odstavit Sambu. Pokial sa na to zabudne, je to... zle.

https://samba.tranquil.it/doc/en/samba_fundamentals/about_fsmo.html

5
Server / Re:Migrace Samba AD na Windows server
« kdy: 09. 06. 2025, 12:37:44 »
Pozor, verzie ktora sa bavi s ktorou je Domain Functional Level, nie verzia Windows Server!

Problem je v tom, ze 2008 functional level, ako aj Samba 4.10 su praveke verzie. Mozno by to islo postupnym upgrade, aby sa jednotlive verzie medzi sebou bavili.

Verzie Samby a podpora funkcnych urovni: https://wiki.samba.org/index.php/Raising_the_Functional_Levels

Verzie Windows Server (<=2012R) a funkcnych urovni: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754918(v=ws.10)

Verzie Windows Server (2016+) a funkcnych urovni: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels

Takze ak nie je mozne upgradovat Sambu na 4.20+, tam povysit domenu na 2016 a potom premigrovat na aktualne windows je to mozne urobit naopak, s dvoma migraciami windows: na sambe 4.10 nastavit 2008R2, nainstalovat Server 20212R2, premigrovat domenu, povysit na functional level 2012r2, nasledne premigrovat na 2022 (zvlada functional level 2012r2) a nakoniec povysit na pozadovany functional level.

6
Sítě / Re:IPsec a problém s SMB
« kdy: 27. 05. 2025, 10:47:35 »
Protoze widle si ukladaji domenovy heslo (ano heslo...) ktery si vygenerujou, a ktery ma zivotnost prave ten +- mesic. Lokalne si pak do cache ukladaji usery ktery se nejak behem pripojeni k domene prihlasili a prave ti se muzou prihlasit i offline.

Toto podedili z Kerberosu. To, co si ukladaju, je machine keytab, teda kluc specificky pre pocitac, v podstate ekvivalent host/$hostname@$REALM. A ano, treba ho z casu na cas refreshut.

Co sa tyka nacachovanych userov, tak ano, vedia sa prihlasit k lokalnemu stroju, ale ak im expiroval kerberos tgt (by default 24 hodin), tak novy nedostanu. Tym padom sa nevedia autentifikovat voci inym sluzbam. Pri smb moze nastat NTLMv2 fallback, ak ho maju povoleny, pri inych moze byt problem, az pokym uspesne neprebehne kinit.

7
Sítě / Re:Vodafone (exUPC) vs. PODA (GPON) Internet
« kdy: 15. 04. 2025, 11:27:06 »
To bude možná tím, že vlastní ONT u PODA prakticky nikdo nemá a tudíž to ani PODA zatím nijak neřeší. Ale pokud by takových userů přibývalo, tak sotva bude PODA všem přidělovat /30 (4x IPv4), když jich má sama nedostatek. Neboli bych rozhodně nesázel na to, že když teď má někdo s vlastním ONT k dispozici 4x IPv4, tak mu to vydrží navěky věků. Ostatně i ve smlouvě se garantuje IPv4 jedna jediná.

Ale oni musia pridelovat /30 z technickych dovodov; (to neznamena, ze moze pouzivat vsetky 4: jedna padne na adresu siete, jedna na gateway na strane isp, jedna na router zakaznika, jedna broadcast). Niektore routery zvladaju /31 (rfc 3021, predpoklada sa point to point, stacia dve adresy, jedna pre router zakaznika, druha pre gateway na strane ISP), ale tipoval by som, ze infrastruktura na strane poda nie. Ak by chceli ist na 1 IP adresu na zakaznika, tak im zostava NAT 1:1, alebo kulehy so zdielanim rovnakej IP na rozlicnych interfaces, (ktore boli tu na roote popisane).

8
Desktop / Re:Náhrada Skype pro Linux
« kdy: 08. 04. 2025, 15:28:05 »
Upoutal mě Jitsi Meet. 
https://flathub.org/apps/org.jitsi.jitsi-meet
Vypadá pěkně a video kvalita zatím nejlepší.
Taky to je systém primárně na video hovory. Chat chybí. Kontakty taky. Škoda. Je to takový open source Zoom.
Naplánujete si video meeting, vygenerujete kód meetingu a ten pošlete tomu s kým chcete mluvit.
Fungu je to, ale náhrada Skype to není.

Vo firme mame rozchodny self-hosted jitsi meet spolu so zulipom. Jitsi je na video/audio, zulip na chat (taky open source Slack). V zulipe sa da jednym klikom v chate vygenerovat linka na adhoc meeting v jitsi a prijemcovia si na nu len kliknu. Obe su za SSO, takze neotravuje s dalsim loginom (ale desktopovy jitsi meet ma problem, nevie spravne handlovat jwt tokeny od OIDC SSO. Desktopovy klient na linuxe dlhu dobu bezal na historickom electrone, takze dlho nevedel hidp a aj zdielanie obrazovky pod waylandom je novinka v 2025.2. Browserovi a mobilni klienti su ok).

Minusom je rozchodit to, nie je to uplne jednoduche a treba sa o to starat. Je jednoduchsie zaplatit za teams.

Pre normalnych domacich userov s linuxom sa mi najviac pozdava telegram. Je to nativna aplikacia v qt, ziadny pochybny home-made electron wrapper ako teams-for-linux, oficialne podporovana a so 100% funkcnostou na linuxe (na rozdiel od whatsapp), nikto s tym nemal problem, ze by nieco nefungovalo. Jedina vytka bola, ze nema normalne skupinove hovory, ktore by ostatnym ucastnikom zvonili, ale v skupine musi vlastnik skupiny vytvorit hovor a ostatni sa musia pripojit (v podstate ako teams).

9
Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN
« kdy: 23. 02. 2025, 20:02:53 »
Caute chlapy,
sorry, ze zase ozivujem tuto temu, ale asi nie je vhodne stale zakladat nove temy, ked tak nech ma moderatori upozornia a zalozim novu. Stale mam problem s tlaciarnou (tiskarnou) a myslim si, ze problem bude vo firewalle, ale neviem kde, takze sem vyprintujem cely filter.
Situacia sa v podstate dotyka styroch vlan:
...

V akych interface listoch su jednotlive vlany? A ostatne interfejsy?

Inak v pripade mikrotiku odporucam exportovat nastavenie cez terminal; /interface/list/export a /ip/firewall/filter/export. Alebo pre cely config /export. Pre RouterOS < 7 pridat hide-sensitive=yes.

10
Sítě / Re:Více než /64 IPv6 adres u O2
« kdy: 18. 02. 2025, 13:36:55 »
A pokud si to trochu sumarizuju, tak v podstatě pár relevantních technických obtíží spočívá v podpoře DHCPv6-PD a to jak u ISP, kde by to museli na mobilních sítích implementovat (to by pravděpodobně neslo i určité další náklady včetně souběhu s bezstavovým SLAAC pro hromady "legacy" zařízení), tak na straně některých platforem (jestli se nepletu, tak třeba Android tohle pořád neumí).

Pozor, DHCP-v6 a DHCP-PD su dve rozlicne veci! Je uplne v poriadku mat v sieti SLAAC a DHCP-PD; PD je "prefix delegation", nim si zariadenie pyta dalsie prefixy pre siete, do ktorych routuje (to by sa Androidu potencioalne tykalo len pri tetheringu). DHCP-v6 resp SLAAC je pre priradenie adresy samotnemu zariadeniu.

Zaroven SLAAC nie je legacy a DHCP-v6 nie je new hotness. SLAAC je plne dostacujuci a DHCP-v6 je len pre tych, co nepochopili IPv6 a prenasaju svoje navyky z IPv4 ;-).

11
Software / Re:max.com na Linuxu nejede ve FullHD
« kdy: 11. 02. 2025, 22:01:05 »
Nemá zmysel toto riešiť, nejde ti to viac ako 720p, lebo na druhej strane ti viacej nepustia.

Tá zázračná akceleračná technológia vo Windows sa nazýva obchodná dohoda, keď sa Microsoft dohodol s poskytovateľmi obsahu, že to takto bude. Ani Chrome nepustia viac ako 1080p, 4K, nebodaj HDR obsah na počítači býva len pre Edge + Windows DRM.

Ja fakt nechápem, prečo za toto platíte. Keď vám vendor povie, že Linux je nepodporovaná platforma pre ich streaming, treba mu povedať naspäť, že ich služba je teda nepodporovaná vašou peňaženkou. Keď sa vás nájde dostatočný počet, vtedy pochopia a začne to fungovať. Keď nie a potrebujete latest shiny, tak nie.

12
Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku
« kdy: 11. 02. 2025, 13:32:33 »
No ako sledujem tu debatu, tak sa asi vykaslem na Mikrotik DNS a rozbeham radsej pihole pod proxmox. BTW: Preco by ste preferovali DoT pred DoH?

Pihole nevie ani DoT, ani DoH. Na to potrebuje bud proxy, ako je stubby, alebo rovno cely resolver, ako je unboud. Takze pokial nejde o filtrovanie, pihole straca vyznam.

13
Sítě / Re:Nastavení a ověření DoH DNS na MikroTiku
« kdy: 10. 02. 2025, 22:31:51 »
- Po takto nastavenom DNS som cez sniffer zistil, ze na WAN rozhrani cez port 53 UDP prebieha komunikacia medzi branou od mojho ISP a DNS servermi Google (8.8.8.8). Vobec nerozumiem na zaklade coho sa tam objavuju DNS Google pretoze v DNS nastaveniach ani v DHCP nemam servery Google.

Urcite je to z portu WAN, alebo je to forwardnute zvnutra? Nemas v sieti Chromecast alebo nejake ine embedded zariadenie, ktore zvysoka kasle na to, co hovori DHCP a pouzije well-known resolver lebo chce?

14
Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN
« kdy: 06. 02. 2025, 16:18:42 »
Ahojte, dodatocne som zistil, ze mam problem s tlaciarnou (tiskarnou) HP M377dw, ktora je v IoT VLAN:
1. Po nejakom case prestane byt pristupna na webe cez hostname.local aj ked cez ip je web pristupny. Tlaciaren tiez po nejakom case presta byt automaticky objavitelna v ramci novych "instalacii", ale na zariadeniach na ktorych uz je "nainstalovana prostrednictvom mDNS"  reaguje v poriadku na tlacove / scan ulohy aj ked je nefunkcny web.

2. Tlaciaren nie je mozne vyhladat na zariadeniach v hostovskej VLANe.

Suvisiace pravidla: ip -> firewall -> filter:

Kód: [Vybrat]
13    chain=forward action=accept in-interface=fix_vlan out-interface=all-vlan log=no log-prefix=""
19    ;;; Tlac_Host
      chain=forward action=accept dst-address-list=tlaciaren log=no log-prefix=""
23    chain=forward action=drop src-address-list=!fix_ip in-interface=fix_vlan log=no log-prefix=""
28    chain=forward action=drop in-interface=veci_vlan out-interface=fix_vlan log=no log-prefix=""
 chain=forward action=drop log=no log-prefix=""

Pravidlo 19 nespracovalo ziadne pakety, tlaciaren nema povolenu ziadnu komunikaciu do domacej siete (fix_vlan).

Na akych zariadeniach to nie je mozne resolvovat? Android, Mac/iOS, Windows 10, 11?

Obzvlast Windows 10 je jeden velky bordel, kazda jedna verzia (22H2, 1903, atd) je ina, na starsie verzie bolo treba instalovat Apple Bonjour, na novsie uz nie.

Tlaciarni staci established,related. Na tlaciaren treba 631 pre ipp a cokolvek je nastavene ako web port. Na tlaciarni si treba spontrolovat povolene protokoly, aj discovery (HP vie aj vyssie spominany WS-Discovery, tak ci sa Windows nesnazi o to).

15
Sítě / Re:MikroTik mDNS: nefunguje video napříč VLAN
« kdy: 03. 02. 2025, 01:22:07 »
Musim si nastudovat ako zmonitorovat komunikaciu. Ked som to pravidlo prepisal len na established, related tak sa obnovil predchadzajuci nefunkcny stav.

Vyssie som uviedol linku, kde Google dokumentuje, co potrebuje mat otvorene:

  • k pouzivanemu DNS serveru 53/udp, 53/tcp
  • do internetu https: 443/tcp, 443/udp a rtm: 19305/tcp, 19305/udp
  • inbound googlecast: 8008-8009/tcp
  • inboud: 1-65535/udp
  • outboud: 1-65535/udp
  • outbound tcp: established, related

Pre VLC sa k tomu pridava nasledovne (VLC si vytvori server, a posle receiveru linku na seba; receiver si teda taha data od pocitaca, na ktorom bezi VLC):

  • outbound http 8010/tcp (default, da sa zmenit v nastaveniach, zobrazit vsetko, vystup streamu, sout stream, chromecast, port http)
  • outbound 32768-61000/udp (t.j. uspokoji sa s mensim rozsahom, ako normalny cast)

Na pocitaci ak ma lokalny firewall to treba otvorit tiez.

Stran: [1] 2 3 ... 25