Prohledávání zařízení v podsítích

[JurajP]

Chcel by som sa spytat, ci je mozne ziskat zariadenia resp IP adresy zariadeni v subnetworks inych ako je samotny pc? Chceme totizto rozsirit funkcionalitu v nasej aplikacii, ze mozme najst aj zariadenia v inych sietach, nakolko niektori nasi zakaznici maju tieto zariadenia pripojene v inych subnetoch, ako bezi samotna aplikacia. Predpokladam, ze bez nejakej informacie ako vyzera samotny subnet (napr 192.168.10.0/24) to nebudeme vediet. Dakujem za info

[Reklama]

[ja.]

Závisí, čo používate na discovery.

Pokiaľ klasický multicast DNS (mDNS), tak existuje mdns reflektor / repeater, ktorý beží na zariadení, ktoré má interface v oboch (alebo viacerých) subnetoch -- napr. na samotnom routeri -- a je v podstate mdns proxy medzi jednotlivými subnetmi.

Pokiaľ iný protokol založený na broadcaste, tak to treba riešiť podobne, akurát asi nebude niečo hotové k dispozícií.

[JurajP]

Je to v c# a broadcast cez udp

[FKoudelka]

Chcel by som sa spytat, ci je mozne ziskat zariadenia resp IP adresy zariadeni v subnetworks inych ako je samotny pc? Chceme totizto rozsirit funkcionalitu v nasej aplikacii, ze mozme najst aj zariadenia v inych sietach, nakolko niektori nasi zakaznici maju tieto zariadenia pripojene v inych subnetoch, ako bezi samotna aplikacia. Predpokladam, ze bez nejakej informacie ako vyzera samotny subnet (napr 192.168.10.0/24) to nebudeme vediet. Dakujem za info

No já nevím, ale asi bych začal discovery sítí u zákazníka a pak periodicky skenoval tyto sítě na port, na kterém poslouchají ta zařízení. Ale spíß bych vynechal ten první krok a radši se zeptal zákazníka v jakých subnetech ta zařízení můžou být a zda v těch subnetech můžu skenovat. Jinak to trochu smrdí :-)

[Foreigner]

Je to v c# a broadcast cez udp

To ti neprojde pres router. Pokud je síť routovaná tak se na ni nedostanes.

[Reklama]

[JurajP]

Jinak to trochu smrdí :-)

V zasade je to poziadavka zakaznika, aby si mohol pridat zariadenie, ktore je v inom subnete.

Je to v c# a broadcast cez udp

To ti neprojde pres router. Pokud je síť routovaná tak se na ni nedostanes.

Samozrejme, v tomto pripade nie.

[Medo77]

ze mozme najst aj zariadenia v inych sietach

Najst znamena, moznost komunikovat, a komunikacia musi byt povolena. Port scan je trochu - nedokonale riesenie.
Isiel by som cestou p2p. Osobne sa mi to nepaci, ale vyriesi to vela problemov. (podmienka plati za predpokladu, ze sa zariadneie vie dobuchat von).
Zariadenia nech oznamuju info o sebe k Vam, a appka si to zoberie zo servera. Samozrejme treba namysliet, kto co moze ziskat za info. (nech zakaznici o sebe nevedia co nemusia). Zaroven nie je z otazky zrejme, ako bude fungovat uz naozajstna komunikacia appka vs zariadenie. Bud pojdu napriamo (origo IPv6 , resp. ipv4 port forward a podobne) alebo budu musiet mat spolocny bod, ktory im umozni sa vidiet. (co by zase riesil Vas server - sice je to zaroven trochu Point of Failure, ale bezne sa takto funguje).(komunikaciu  zabalit napr do SSH a ist voci nejakemu serveru).

[ja.]

Pani, nejako nechápem, čo tu vlastne riešite. Port scan, SSH von? Seriously?

Na discovery služieb v sieti existujú štandardné protokoly - mDNS (Avahi, Zeroconf, Bonjour; mDNS je kombinácia DNS-SD a multicastu), WS-Discovery, SSDP. Keďže fungujú na princípe broadcastu, ich limit je presne to, čo bolo predmetom otázky: ako s tým cez hranice subnetu?

Jedno riešenie som tu už dal: mDNS reflektor. Niektoré routery to zvládajú (napr. Ubiquiti), iné nie, a môže to bežať na nejakom inom zariadení, ktoré je v broadcast doméne oboch subnetov. Výhoda je, že netreba upravovať aplikáciu ani službu, obe uvidia discovery pakety tak, ako keby to bolo v jednom subnete. Nevýhoda je, že kombinujete broadcast traffic oboch subnetov.

Druhé riešenie je DNS-SD bez multicastu. Do DNS nahodiť SRV záznamy, buď manuálne (keď zákazník vie, kde presne to bude bežať), alebo umožniť službe, aby si záznamy v DNS manažovala sama (napr. keď je v sieti AD, tak to nie je problém, principal dostane právo updatovať daný záznam). Klientska aplikácia si v DNS pozrie SRV pre _mojasluzba._tcp.domena.tld a vie, s kým má komunikovať. Výhoda je, že v manažovanej sieti to nie je problém zariadiť, nevýhoda je, že treba upraviť službu (aby si udržiavala záznam) a aplikáciu (aby hľadala aj v DNS).

[arpanet]

Resil jsem obdobny problem v rozlehle siti (cca 8000 zarizeni)
nakonec jsem skoncil na tom ze mam SNMP read prava na vetev ktera vycita interface a arpy ..... poolem vycitam (SNMP3 bulk walk ) a kdyz to jde tak paruju informace o IP s jmenem pomoci AD (DNS query na reverz zaznam)..

tj.: oslovim default gateway vyctu arpy , vyctu LLDP ,vyctu MAC na interfacech SWITCHU a SSID APECEK, ktere najdu pomoci LLDP , vyloucim TRUNK porty, sparuju DEVICE/PORT/MAC/IP a zkusim pomoci DNS najit jmena....

a tak ... rekurze ... az do blba

[JurajP]

trochu to tu opat obnovim, nakolko sme to zacali aktivne riesit. tak ako som spominal, riesime to cez UDP broadcast, zariadenia maju nejaku port, na ktory sa posiela sprava a prijata odpoved je dane zariadenie. Cize napr. 10.42.8.255 atd. Dopatral som sa k jednej moznosti a to konkretne directed broadcast. Myslite, ze to je mozna cesta?

[František Ryšánek]

Jinak to trochu smrdí :-)

V zasade je to poziadavka zakaznika, aby si mohol pridat zariadenie, ktore je v inom subnete.

Je to v c# a broadcast cez udp

To ti neprojde pres router. Pokud je síť routovaná tak se na ni nedostanes.

Samozrejme, v tomto pripade nie.

trochu to tu opat obnovim, nakolko sme to zacali aktivne riesit. tak ako som spominal, riesime to cez UDP broadcast, zariadenia maju nejaku port, na ktory sa posiela sprava a prijata odpoved je dane zariadenie. Cize napr. 10.42.8.255 atd. Dopatral som sa k jednej moznosti a to konkretne directed broadcast. Myslite, ze to je mozna cesta?

Jsou dvě varianty broadcastu:

A) globální broadcast = cílová adresa 255.255.255.255 .
Toto podle mého neproleze routerem, nejspíš to ani není konfigurovatelné (na Ciscu).
V rámci L2 LAN globální broadcast funguje velmi dobře. Pokud hledaná zařízení ještě ani nemají IP adresu ve správném subnetu (mají nějaký default), můžete použít broadcast pro dotaz i odpověď, případně pro druhou transakci, ve které nastavíte žádanou unikátní IP adresu a masku, aby se dál už dalo bavit unicastem v rámci legitimního subnetu.

B) lokální = per subnet = "directed" broadcast, např. 192.168.3.255/24 (vymyslel jsem si).
Toto lze na routerech zapnout - přinejmenším na Ciscu. Příkaz "no ip directed-broadcast" býval v začátečnických kursech Cisco mezi zcela základními bezpečnostními pravidly, od verze 12 se jedná o default (který není vidět v "show running") - ale dá se stále povolit.
Pokud routeru předáte paket s cílovou adresou, která je lokálním broadcastem v některém "directly connected" subnetu, tak ji přeloží na L2 broadcast s kýženým výsledkem.
Pozor, pokud se pokusíte broadcastem oslovit subnet, který router *nezná* jako "directly connected", tak se directed broadcast mine účinkem (skončí na default routu, nebo na nějakém specifickém routu který není "directly connected", pokud takový existuje v konfiguraci).
V rámci L2 segmentu (bez průchodu routerem) samozřejmě můžete "directed broadcast" používat zcela svobodně, pokud vám Vaše programovací prostředí dovolí. Ale jste omezen znalostí lokálního subnetu, a musí s ním umět pracovat i oslovené slave zařízení = musí být už nakonfigurované na správný subnet a mít přidělenou IP adresu (a jenom se znuděně ozve "jo jasně, tady jsem", klidně unicastem). Ještě jsem uvažoval tím směrem, že by slave mohl poslouchat na raw socketu (nebo lipbcap), aby vzal úplně všechno bez ohledu na subnet, a pokud vidí directed broadcast (= "konkrétní IP adresu" ale na L2 broadcast FF:FF:FF:FF:FF:FF) tak se ho může "chytit" - ovšem pokud nemá zatím přidělenu IP adresu z dotyčného subnetu, tak by si nemělo žádnou konkrétní svévolně vzít, tzn. jako řešení vidím jedině, použít v odpovědi opět "directed broadcast" adresu, a to jako cíl i jako zdroj. Možná by v tom případě bylo jednodušší, aby si slave prostě po zapnutí líznul DHCP. Pak může chytat directed broadcasty normálně přímo, bez blbnutí s raw socketem apod.

A pak mě ještě napadá, zkusit to multicastem :-) Ale je s tím spíš práce navíc, má to svoje problémy a bugy a konfigurace na routerech (a switchích!) apod. Radši se držte broadcastu, ten by měl prolézt aspoň v rámci L2 všude.

Tzn. docela důležitou otázkou zůstává: je to skrz router, nebo jenom v rámci L2 média? ...

[JurajP]

dakujem za vycerpavajucu odpoved.

Direct broadcast neprejde u zakaznika. Je to povazovane ako security issue a to nedovolia.

Tzn. docela důležitou otázkou zůstává: je to skrz router, nebo jenom v rámci L2 média?

Tazko povedat, ako to ma zakaznik nakonfigurovane. Moze to byt v ramci L2, ale takisto moze mat tu siet routovanu. Do toho uz my nevidime.

Pravdepodobne sa budeme uberat smerom, ze nasa aplikacia bude poznat (nastavi to technik povedzme) default gateway a pevnu IP adresu daneho devicu (device bude mat tiez nastavenu default gateway aby vedel odpovedat). Aj ked tu sa mi naskytuje otazka: Nestacilo by poznat default gateway a na nu robit broadcast s tym ze IP adresa by bola dynamicka?

[FKoudelka]

dakujem za vycerpavajucu odpoved.

Direct broadcast neprejde u zakaznika. Je to povazovane ako security issue a to nedovolia.

Tzn. docela důležitou otázkou zůstává: je to skrz router, nebo jenom v rámci L2 média?

Tazko povedat, ako to ma zakaznik nakonfigurovane. Moze to byt v ramci L2, ale takisto moze mat tu siet routovanu. Do toho uz my nevidime.

Pravdepodobne sa budeme uberat smerom, ze nasa aplikacia bude poznat (nastavi to technik povedzme) default gateway a pevnu IP adresu daneho devicu (device bude mat tiez nastavenu default gateway aby vedel odpovedat). Aj ked tu sa mi naskytuje otazka: Nestacilo by poznat default gateway a na nu robit broadcast s tym ze IP adresa by bola dynamicka?

Pokud by byla adresa dynamická, z jejich DHCP serveru, nešlo by to zařízení kontaktovat přes hostname na spárovaném DNS serveru? Pojmenovat zařízení vám známým jménem a to by se propagovalo do jejich DNS?