Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: googler2 01. 02. 2025, 20:15:00
-
Caute, viem, ze na tomto fore sa velmi neriesia taketo "home" temy, ale skusim to. Konecne som sa dokopal k pokusu rozbehat MDNS na Mikrotiku, Funguje to tak napolovicu, strucne napisat co som urobil:
- Na Mikrotiku som povolil port 5353 z predmetnych VLAN do inputu a v IP - DNS som povolil MDNS na predmetnych VLANach
- Na TP-Link smart switch som povolil IGMP
- Na Ubiquiti AP som povolil multicast v predmetnych VLANach
Vysledok:
- Tlaciaren je pristupna napriec VLANami v poriadku
- Mirroring Chrome prehliadaca funguje, s vinimkou prehravania videa na webe, ale to bude asi problem iba niektorych webovych prehravacov
- Vobec nefunguje mirroring videa (cast) priamo cez Windows resp. Windows nevidi TV, v inej VLANe, ako cast zariadenie.
- VLC (na rovnakom Windowse) cez funkciu Render danu TV vidi, pokusi sa video aj prehrat (na TV sa zobrazi prehravac s nazvom videa, ale prehravanie na TV sa nespusti.
Testoval som to aj na inom Windows zariadeni a problemy su rovnake (Linux som neskusal). Len podotknem, ze v jednom pripade islo o TV a PC, ktore su do switchu zapojene cez kabel a v druhom pripade islo o NTB (wifi) a TV (kabel).
Ma niekto tipy na mozne riesenie? THX
-
Caute, viem, ze na tomto fore sa velmi neriesia taketo "home" temy, ale skusim to. Konecne som sa dokopal k pokusu rozbehat MDNS na Mikrotiku, Funguje to tak napolovicu, strucne napisat co som urobil:
OK
- Na Mikrotiku som povolil port 5353 z predmetnych VLAN do inputu a v IP - DNS som povolil MDNS na predmetnych VLANach
Dobry krok, len si treba uvedomit, ze mDNS je len discovery. Tu jednotlivi klienti len ziskaju informaciu, na akej ip, akom porte bezi dana sluzba. Este musia mat moznost sa na nu aj pripojit.
- Na TP-Link smart switch som povolil IGMP
Naco presne? IGMP pouziva multicast, ale nie vsetok multicast je IGMP. Pouzivas nejaky zdroj videa z multicastu (IPTV)? To je vtedy tiez trocha zlozitejsie, nez len povolit IGMP. Na mDNS IGMP nepotrebujes.
- Na Ubiquiti AP som povolil multicast v predmetnych VLANach
OK.
Vysledok:
- Tlaciaren je pristupna napriec VLANami v poriadku
Tak zjavne port 631 (ipp) ma prestup medzi VLAN.
- Mirroring Chrome prehliadaca funguje, s vinimkou prehravania videa na webe, ale to bude asi problem iba niektorych webovych prehravacov
Chromecast (aj ten v TV) potrebuje mat pristup na Internet. Pri castovani tabu z prehliadaca ide stream z pocitaca, ale pri castovani video streamu taha renderer stream priamo zo zdroja. (Preto je mozne pocitac/telefon/whatever vypnut a castovanie pokracuje).
Poziadavky na siet pre renderer (receiver): https://support.google.com/chrome/a/answer/12256492?hl=en
- Vobec nefunguje mirroring videa (cast) priamo cez Windows resp. Windows nevidi TV, v inej VLANe, ako cast zariadenie.
To preto, ze Windows nepouziva mDNS, kedze je to "konkurencna" technologia. Windows pouziva SSDP alebo WS-Discovery, podla toho, aky stary je prislusny komponent, co robi discovery. Mikrotik toto neriesi.
- VLC (na rovnakom Windowse) cez funkciu Render danu TV vidi, pokusi sa video aj prehrat (na TV sa zobrazi prehravac s nazvom videa, ale prehravanie na TV sa nespusti.
VLC tlaci stream cez port 8010. Ma prestup?
Testoval som to aj na inom Windows zariadeni a problemy su rovnake (Linux som neskusal). Len podotknem, ze v jednom pripade islo o TV a PC, ktore su do switchu zapojene cez kabel a v druhom pripade islo o NTB (wifi) a TV (kabel).
OK
Ma niekto tipy na mozne riesenie? THX
Tip: Wifi nema rada multicast -- pretoze tam nie je ack. Nemoze teda vediet, ci bol multicast packet doruceny alebo nie. Preto pri multicaste spomaluje na co najnizsi link rate a zvycajne aj dole na 802.11b. Pri discovery packetoch sa to da prezit, tych nie je vela, ale streaming cez multicast a wifi nie je to prave orechove. Prave preto existuju nastroje ako udpxy, ktore prevedu multicast na unicast.
-
Vo firewalle mam pravidlo, ze vlana s domacimi pc a ntb ma pristup do vsetkych vlan, cize aj do tej kde je tv, takze si myslim, ze tym by mal byt pristup vyrieseny a TV ma pristup na net, ale casting nejde
-
Vo firewalle mam pravidlo, ze vlana s domacimi pc a ntb ma pristup do vsetkych vlan, cize aj do tej kde je tv, takze si myslim, ze tym by mal byt pristup vyrieseny a TV ma pristup na net, ale casting nejde
Možná se ptám blbě, ale naopak z té IoT VLANy jsou povolena established/related spojení zpátky do VLANy s notebooky a PC (případně paušálně ve forward chainu bez uvedení ifacu)?
Jak už bylo zmíněno, tím že to discovery zafunguje, tak ten relaying mDNS zpráv na úrovni ROS evidentně funguje.
Pak už je komunikace jen normální unicast mezi senderem a receiverem.
Možná bych dočasně zkusil dočasně otevřít plnou komunikaci mezi všemi VLANami, pokud to začne castovat, tak bude jasnější, že je třeba se podívat na nějaká filtrační pravidla.
-
tak mal si pravdu, ked som povolil obojsmernu komunikaciu medzi tv vlan a pc vlan, tak uz funguje v podstate vsetko okrem castingu priamo cez Windows, ten stale TV nevyhlada ako zariadenie dostupne na castovanie, ale ako tu uz niekto spomenul, ten problem asi nebude vo VLAN (MDNS).
Dost mi ale vadi, ze aby bol chromecast plne funkcny, tak musi byt povolena obojsmerna komunikacia, to potom pouzitie VLAN straca zmysel, no myslim si, ze z bezpecnostneho hladiska je dobre mat srandicky typu smart TV a ine multimedia boxy izolovane od zbytku siete. Takze asi budem musiet ozeliet funkciu castingu v prospech bezpecnosti.
PS: Vobec nerozumiem tomu preco by mala TV ako receiver spatne komunikovat so sender zariadenim. Ved sender posiela video do TV, ktora ho uz nema posielat spet do siete sendera, ale ma ho len zobrazit.
-
tak mal si pravdu, ked som povolil obojsmernu komunikaciu medzi tv vlan a pc vlan, tak uz funguje v podstate vsetko okrem castingu priamo cez Windows, ten stale TV nevyhlada ako zariadenie dostupne na castovanie, ale ako tu uz niekto spomenul, ten problem asi nebude vo VLAN (MDNS).
Dost mi ale vadi, ze aby bol chromecast plne funkcny, tak musi byt povolena obojsmerna komunikacia, to potom pouzitie VLAN straca zmysel, no myslim si, ze z bezpecnostneho hladiska je dobre mat srandicky typu smart TV a ine multimedia boxy izolovane od zbytku siete. Takze asi budem musiet ozeliet funkciu castingu v prospech bezpecnosti.
PS: Vobec nerozumiem tomu preco by mala TV ako receiver spatne komunikovat so sender zariadenim. Ved sender posiela video do TV, ktora ho uz nema posielat spet do siete sendera, ale ma ho len zobrazit.
Hmm.. mám tu bohužel spíš Apple věci, žádný Chromecast ani televizi, abych to ozkoušel. Spíš jsem to nastavoval tak různě po známých, naposled někde na Ubiquity FW.
Ale podle mě by receiver sám o sobě komunikovat se senderem neměl. Proto jsem zmiňoval, že by měla být povolená existující spojení - established, related. (neměla by být potřeba nová spojení založená z izolované VLANy)
Jestli si to pamatuju dobře, tak Chromecast casting jede zhruba takhle.
Po objevení zařízení a zvolení k posílání se vytvoří obousměrný websocket kanál ze senderu na receiver.
Pak to streamuje v podstatě dvěma způsoby.
- casting z nějaké podporované aplikace (která má odpovídající appku na receiveru). Např. YouTube. Předá se odkaz s pozicí, stream už si pak tahá dál receiver a sám pokračuje v přehrávání.
- mirroring, kdy se použije RTP/UDP s nějakou kompresí jako H.264, VP9 a aktivně ty pakety posílá zas sender
Všechny věci ohledně přehrávání (ovládání, pozice, nějaké řízení toku atp.) se odehrává jen přes ten už existující websocket kanál.
Případně to zkusit nějak dál zmonitorovat..
-
Musim si nastudovat ako zmonitorovat komunikaciu. Ked som to pravidlo prepisal len na established, related tak sa obnovil predchadzajuci nefunkcny stav.
-
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.
-
Diky, ano vsimol som si tu dokumentaciu, ale je v nej uvedeny tak brutalne siroky rozsah portov, ze to uz rovno mozem povolit plnu obojsmernu komunikaciu medzi vlanami
-
Aha, sorry, prvykrat som tu dokumentaciu nepochopil spravne. Z TV VLAN do PC VLAN staci povolit porty 8008-8010 a funguje Chromecast aj VLC ;)
-
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:
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).
-
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:
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).
-
Řešeí: mDNS je úplně na 💩 a nikdo normální to nepoužívá.
-
mDNS naopak používají všichni, protože se to používá samo. Automatické objevování tiskáren, automatické objevování televizí pro YouTube, automatické objevování reproduktorů a podobně. Tohle je mDNS a funguje to krásně.
-
Tohle je mDNS a funguje to krásně.
Jojo, proto tady už přes týden řešíme, proč to nefunguje. LOL.
-
Jojo, proto tady už přes týden řešíme, proč to nefunguje. LOL.
Akorát, že to mDNS vůbec nesouviselo s tím, že nebyl povolený control port na ChromeCast.
Jinak to mDNS obecně funguje dobře na macOSu a Linuxu přes Avahi jsem s tím nikdy neměl žádné zásadnější problémy. Jak už zmínil ja, na Windows je to trochu bordel, protože s tou původí Apple knihovnou a providerem (Bonjour Print Services for Windows) to bylo v pohodě. Pak se objevily MS nativní implementace, plus třeba některé aplikace nepoužívaly systémové knihovny a měly bundlované své knihovny na discovery.
V každém případě se to docela snadno debugguje, jsou na to nástroje počínaje Wiresharkem, přes Bonjour browser na Windows, avahi-discover na Linuxu.
-
tak po resete tlaciarne sa zda, ze uz funguje relativne vsetko okrem toho, ze webove rozhranie stale vypadava na W10 aj iOS a android. Tlacove ulohy aj discovering je zatial funkcny, ale v nastaveniach ohladom discoveringu nie je nic extra. Je tam len moznost zapnut wifi direct a airprint (obe su a boli vzdy zapnute). Myslim, ze problem s webom je sposobeny proste samotnou tlaciarno.
-
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:
- base je management vlana, ktora ma pristup do celej LAN, teda do vsetkych vlan
- fix je vlana pre bezne domace zariadenia (PC, NTB, mobily). Docasny pristup do celej LAN
- host je vlana pre navstevy
- veci je IoT vlana, v ktorej je aj tlaciaren
z fix a host vlan je tlaciaren pristupna, ale zvlastne je, ze cez pravidlo 14, ktore by malo zabezpecit pristup z host vlan nepretekaju ziadne pakety a tlaciaren je pristupna aj po vypnuti toho pravidla. Tlaciaren nie je vobec pristupna z base vlany, ktora by mala mat pristup do celej LAN - pravidlo 9, takze na zaklade toho by mala byt pristupna aj tlaciaren:
Flags: X - disabled, I - invalid; D - dynamic
0 chain=input action=accept connection-state=established,related
1 chain=input action=accept in-interface=fix_vlan log=no log-prefix=""
2 chain=input action=accept protocol=udp src-address-list=LAN_ip in-interface-list=LAN dst-port=5353 log=no log-prefix=""
3 chain=input action=drop connection-state=invalid
4 chain=input action=jump jump-target=WAN>INPUT in-interface-list=WAN log=no log-prefix=""
5 chain=input action=drop log=yes
6 chain=forward action=accept connection-state=established,related log=no log-prefix=""
7 chain=forward action=accept protocol=udp src-address-list=LAN_ip dst-address-list=dns in-interface-list=LAN dst-port=53 log=no log-prefix=""
8 chain=forward action=accept in-interface-list=LAN out-interface-list=WAN log=no log-prefix=""
9 chain=forward action=accept in-interface=base_vlan out-interface-list=LAN log=no log-prefix=""
10 chain=forward action=accept in-interface=fix_vlan out-interface-list=LAN log=no log-prefix=""
11 chain=forward action=accept src-address-list=Bernardo out-interface-list=LAN log=no log-prefix=""
12 chain=forward action=accept protocol=tcp src-address-list=Budky_ip in-interface=media_vlan out-interface=fix_vlan dst-port=8008-8010 log=no log-prefix=""
13 chain=forward action=accept dst-address-list=NAS in-interface=media_vlan log=no log-prefix=""
14 ;;; Tlac_Host
chain=forward action=accept dst-address-list=tlaciaren in-interface=host_vlan log=no log-prefix=""
15 ;;; DSTNAT
chain=forward action=accept connection-nat-state=dstnat log=no log-prefix=""
16 chain=forward action=drop connection-state=invalid
17 chain=forward action=drop src-address-list=!base_ip in-interface=base_vlan log=no log-prefix=""
18 chain=forward action=drop src-address-list=!fix_ip in-interface=fix_vlan log=no log-prefix=""
19 chain=forward action=drop src-address-list=!media_ip in-interface=media_vlan log=no log-prefix=""
20 chain=forward action=drop src-address-list=!veci_ip in-interface=veci_vlan log=no log-prefix=""
21 chain=forward action=drop src-address-list=!nowan_ip in-interface=nowan_vlan log=no log-prefix=""
22 chain=forward action=drop src-address-list=!host_ip in-interface=host_vlan log=no log-prefix=""
23 chain=forward action=drop in-interface=host_vlan out-interface=fix_vlan log=no log-prefix=""
24 chain=forward action=drop in-interface=veci_vlan out-interface=fix_vlan log=no log-prefix=""
25 chain=forward action=drop in-interface=veci_vlan out-interface=host_vlan log=no log-prefix=""
26 chain=forward action=drop in-interface=veci_vlan out-interface=media_vlan log=no log-prefix=""
27 chain=forward action=drop in-interface=host_vlan out-interface=base_vlan log=no log-prefix=""
28 chain=forward action=drop dst-address-list=bogon log=yes log-prefix="bogon"
29 chain=forward action=drop log=no log-prefix=""
30 chain=WAN>INPUT action=drop log=no log-prefix=""
-
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.
-
/interface list
add name=WAN
add name="LAN PORT"
add name=LAN
/interface list member
add interface=ether1 list=WAN
add interface=fix_vlan list=LAN
add interface=host_vlan list=LAN
add interface=media_vlan list=LAN
add interface=veci_vlan list=LAN
add interface=ether2 list="LAN PORT"
add interface=base_vlan list=LAN
add interface=nowan_vlan list=LAN