Dotaz: Ja odhalit bridge na siti?

[manasekp]

zdravim,

toto bude asi ponekud zvlastni dotaz, prosim o shovivavost.

Mam v siti bridge vytvoreny ze dvou Nanostation M5, slouzi to k pripojeni vedlejsi budovy do firemni site. Bohuzel jsem to neinstaloval ja a nemam k tomu zadne informace takze nevim IP adresy tech dvou zarizeni. Pokousel jsem se to najit nmapem (nmap -sP), bohuzel to dane zarizeni nenaslo(manualne jsme prosel vetsinu nalezenych jestli na tom jede webove rozhrani ktere vim jak vypada). Znam ip adresy nekolika pocitacu za tim bridgem, podle nejake teorie by odpoved na ping mela prijit z adresy toho bridge, wiresharkem jsem toto zachytil, bohuzel tam bylo opet neco jineho.

Jednoduche reseni by samozrejme byl reset antenek do vychoziho nastaveni a nova konfigurace. Tomu bych se zatim chtel vyhnout.

Napada vas jak to resit?

Diky.

---

---

Odpovědi

[NN]

Dve moznosti, rozebrat krabicku a pripojit se na seriove rozhrani. Za predpokladu, ze zarizeni maji nejakou platnou MGMT adresu, proskenovat cely rozsah a dohledat korektni IP napriklad podle MAC OUI. 50c

[pavlix]

Pokud nekomunikují na adresách ze zcela odlišných rozsahů.

[Skokan, Pavel]

nevím, zda jsem to správně pochopil

pokud to je opravdu bridge, tak je to nižší vrstva síťování, než je ip (linková vrstva x síťová vrstva modelu ISO/OSI)

tím pádem to bude pro nmap transparentní (ten myslím bere v potaz dění minimálně na síťové vrstvě)

ani wiresharkem se to nemusí nechat zrovna snadno odhalit...

http://en.wikipedia.org/wiki/Bridging_(networking)

[manasekp]

o tom vim ale podle meho nazoru by to mel byt router v rezimu bridge, myslim ze tyto antenky jiny bridge neumi, prave to je vec se kterou jsem doufal ze by nekdo mohl mit zkusenost.

[j]

Ale kdepa ... transparentni (teda jak kdy a jak co) je to pro pruchozi komunikaci, ale ta krabka ma(predpokladam) svoji management IP. Tyhle IPcka se dost casto voli MIMO bezne pouzivany rozsah, casto na nejaky vlan, aby se k tomu jen tak nekdo nedostal.

Najit se to da pomerne snadno - vetsinou staci chvilu poslouchat na stejne fyzicke siti (= dat si tam HUB nebo dostatecne schopny switch nebo soho krabku a otravit ji).

[Michal Kubeček]

Znam ip adresy nekolika pocitacu za tim bridgem, podle nejake teorie by odpoved na ping mela prijit z adresy toho bridge,

Tak to je hodně divná teorie. I kdybych pominul, že bridge nemá do IP hlaviček vůbec zasahovat, tak pokud by se tak chovalo jakékoli zařízení, nebude komunikace přes něj fungovat.

[manasekp]

v pondeli/utery sem muzu postnout data z wiresharku, neco takoveho sem tam fakt videl.

[Jendа]

Resetnul bych to a koukal, jestli se to třeba nezeptá na nějaký ARP.

[frr]

+1 odpojit obě rádia od LAN, připojit si počítač s Wiresharkem a poslouchat, jestli se to po vypnutí/zapnutí na něco zeptá.

[lertimir]

podle nejake teorie by odpoved na ping mela prijit z adresy toho bridge

Z bridge na normální paket nepřijde nic. Ta teorie musela být z hospody.

Bridge je v podstatě jen název pro dvouportový switch. Tedy zařízení pracující na L2 vrstvě a přepínající pakety. To že uvnitř je konverze na wifi, nějaký fyzický přenos jiným mediem, fyzická vzdálenost nebo cokoliv dalšího nemá vliv na to, že takového zařízení na běžném paketu na síti není nijak identifikováno.

Nicméně manageovatelné switche a bridge mohou vysílat Spanning Tree Protocol, aby zamezily L2 smyčkám v síti. Vždy jsem tohle chápal jako součinnost dvou zařízení, siťově neviditelného bridge/switche a managujicího systému jedoucího na nějaké MAC adrese (IP adrese), který je ve stejné krabici a switch nastavuje a hlavně, který pro činnost switche/bridge tam vůbec nemusí být.

[pavlix]

Bridge je v podstatě jen název pro dvouportový switch.

Spíš je switch obchodní název pro hardwarem realizovaný bridge. Pokud vím, tak odpovídající standardy používají slovo bridge.

[Sten]

Bridge se dělí na transparentní a zdrojové. U zdrojového bridge skutečně dorazí MAC adresa toho bridge, ale to znamená, že ten bridge musí zasahovat do síťové vrstvy (např. přepisovat ARP zprávy) a způsobuje to problémy (např. fungují jen ty protokoly, které bridge zná, a neprojde přes něj DHCP). Proto se bridge mezi sítěmi, kde to jde (např. WiFi a Ethernet používají stejný formát MAC), snaží být transparentní a posílat MAC adresu cílového počítače.

Bridge lze většinou detekovat pomocí pravidelných zpráv STP a ty novější často reagují i na LLTD (Windows Network Map), LLDP (lldptool) a DNS-SD (linuxové Avahi a macovské Bonjour).

[pavlix]

Bridge se dělí na transparentní a zdrojové.

Zdroj? Především k té terminologii.

U zdrojového bridge skutečně dorazí MAC adresa toho bridge, ale to znamená, že ten bridge musí zasahovat do síťové vrstvy (např. přepisovat ARP zprávy) a způsobuje to problémy (např. fungují jen ty protokoly, které bridge zná, a neprojde přes něj DHCP).

To ano, ale když člověk instaluje nanostation, tak zpravidla využívá toho, že tyto stroje umějí spolu komunikaci plně bridgovat pomocí čtyřadresních rámců (2x MAC pro fyzické spojení, 2x MAC pro link). Klasickou wifi museli navrhovat lidé s kritickým nedostatkem fantazie, když si mysleli, že se bridgovat bude vždy jen na straně AP.

[Filip Jirsák]

Myslím, že Nanostation umí vyhledávat ostatní Nanostation v síti. Buď je to některý ze standardních protokolů, které popisoval Sten, nebo byste mohl zkusit půjčit další Nanostation a vyhledat ty dvě pomocí něj.

[manasekp]

diky, dalsi nanostation mam, vyzkousim to.

[Jimmy]

Nanostation není potřeba. Stačí použít na PC Device Discovery Tool od UBNT a nebýt za nějakým routerem. V lokálním segmentu to najde všechny UBNT zařízení včetně jejich IP.

[frr]

Souhlas... tak jako Mikrotik má svůj Winbox, který najde v LANce všechny živé routerboardy bez ohledu na subnet (jede přes nějaké broadcasty) tak zřejmě i Ubiquiti má nějaký takový software.

[TomM]

Pokud to nebylo pri konfiguraci zakazano, tak ty UBNT krabicky periodicky (default 120s) vytrubuji do site pomoci CDP. Tcpdump si s tim moc nerozumi, ale po pridani -vv se rozkeca natolik, aby byla videt IP adresa.
Default IP maji 192.168.1.20/24, takze pokud nejsou vyhmatatelne nmap-em v pouzivanem prefixu, mohou byt tady. Bacha, pokud jsou spojene, asi nastane chaos.

[manasekp]

Pouzil jsem ten tool od Ubiquity a antenky jsem (nejspis) uspesne odhalil, bohuzel jim nefunguje webove rozhrani, bud je rozbite nebo ho nekdo vypnul. Zatim to nechavam tak a casem to budu muset resetovat.

[frr]

Ten detekční tool... ukáže IP adresy, na kterých lze ty dvě "rádia" managovat? Patrně ano, jinak byste neříkal, že na těch adresách nefunguje HTTP... Odpusťte pitomý dotaz: než jste zkusil rozpoutat HTTP, vyřešil jste, zda se o to pokoušíte z adresy ve shodném subnetu, jako mají rádia? Nebo musíte mít vyřešený routing (default gateway v rádiích atd.) což je myslím složitější podmínka. Toto je obvyklé začátečnické zaškobrtnutí u různých takovýchto detekčních toolů - samotná detekce a případně konfigurace IP adresy probíhá přes L2 nebo L3 broadcasty, ale "nosná vrstva" pro kompletní konfiguraci už potřebuje košer konfiguraci subnetu (jede přes unicasty).

[manasekp]

ano naslo to dve ip adresy v rozsahu ktery mame vyhrazeny pro firmu, na 80 portu by melo byt webove rozhrani ale neni. nmapem jsem se dival jestli neni na nejakem jinem portu, taky ne.

[frr]

Tak to potom jo... pak už bych maximálně koukal, jestli tam nejsou jiná vrátka, ale to byste asi v nmapu našel a pak bych se sháněl po telefonu na lidi, co to pojítko montovali. Dál už jenom popřeju hezký den

[pocitujlasku]

https tam nebude zapnute? v nano bezi busybox, tak min. ssh by tam mohlo byt zapnute. Este je varianta, ze ten, ktory to nastavoval obmedzil prisptup do administracie len z urcitej ip adresy.

[Lavy Jozko]

Necital som vsetky komentare, takze sa ospravedlnujem za pripadne chyby.

Z textu vyplyva (ak som to spravne pochopil), ze tie krabicky maju IP vrstvu zapnutu, predpokladam nejake webove klikatko.

Solution: Ak maju zapnutu IP vrstvu, broadcastnes L2 domenu, a na zaklade mac addries, OUI cisla najdes svoje zariadenie

http://www.adminsub.net/mac-address-finder/ubiquiti - OUI cislo mac adries.

S pozdravom

Astar Seran