Dotaz: mikrotik, nevysvetlitelny traffic

[jany2]

Mam taky zvlastny problem na domacej LAN. Kedze nie som sietar, mam problem to vyriesit. Diskutovat som zacal uz davnejsie tuna ale zatial problem stale pretrvava (je tam toho dost citania, tak skusim popisat problem tu aj s novymi skutocnostami).
Zdroj internetu mam VDSL. Modem mam nastaveny v bridge mode a PPPoE vytacam na RB450 (RB450 je hlavny router, gateway, dhcp atd .... (cela siet je bridgovana)).
Takze s modemu je WAN na RB450 na ETH1. ETH2 je LAN pre celu siet pripojena do switcha D-Link DGS-108/E. Z tohto switcha su dalej pripojene nejake PC a dalsie switche a routery (v bridge mode).
Z jedneho routera je dalej napojeny RB433 (tiez bridge), ktory je na komine a obsluhuje 2 NS5ky.
Cela siet fungovala v pohode (uptime na RB bolo bez problemov aj 100 dni). Kedze som mal na RBeckach dost stare ver, ROS (3.x a 4.x) rozhodol som sa upgradovat na 6.33.3 (to bolo niekedy v decembry 2015).
Po upgrade znova vsetko fungovalo v pohode, ale asi raz za 2-3 tyzdne som mal velmi vysoky traffic na RB 433 (niekedy to bol aj 30-40 Mib/s). Ten traffic trval cca 5, 10, 15 min ... ale niekedy aj hodinu a viac. Najprv som si myslel, ze ten traffic sposobuje wifi klient, ale po case som zistil ze wifi klient to nie je. Po odporucaniach na ispfore som si spustil torch a sledoval co sa deje ak je vysoky traffic. Traffic bol medzi takymi lokalnymi IP adresami, ktore ani neboli pripojene k LAN sieti. Dokonca raz ked som sa prihlasil k MK cez winbox a sputil torch, tak som zistil, ze traffic je medzi PC na ktorom som prave bol a jednou NS5, ktoru som mal polozenu na stole v krabici (chystal som sa ju prave montovat do suseda). Ak som svoj PC vypol a pripojil sa cez winbox z ineho PC, tak traffic stale bezal (cize pre mna to bol nevysvetlitelny traffic).
Ono by ma to az tak netrapilo ten vysoky traffic, ale problem bol v tom, ze ak ten traffic zacal, tak mi zacala padat siet. Nieco vsak fungovalo a nieco padlo. Nedokazal som sa pripojit z PC na winbox.
Ked som pisal vyssie, ze som sa pripojil na MK cez winbox a sledoval torch, tak to sa mi podarilo len vynimocne, alebo som bezal k inemu PC s ktoreho sa este dalo pripojit.
Medzi tym casom som vymenil niektore switche, niektore som zrusil, pretoze problem som videl v starych switchoch a odchadzajucich portoch, ale problem sa nepodarilo vyriesit.
Uz som vlastne bezradny, tak ma napadlo, ci problem nebude niekde vo firewalle, ale na ISPfore sa skor priklanali k HW problemu.
Kedze az tak moc do konfiguracie firewallu nevidim, tak som skopiroval pravidla na ispforum a vlastne sa zistilo, ze firewall bol volajako rozhadzany, konfigy neboli uplne a posledne pravidlo, ktore malo vsetko ostatne dropovat, bolo vypnute, cize firewall ako keby tam ani nebol. To asi sposobilo upgrade na novu ver. a stary config nebol celkom kompat. s novou ver.
Volajako som si dal firewall do poriadku a od vtedy cuduj sa svete, vypadky ako keby prestali. Avsak ten vysoky traffic sa stale objavuje, ale siet uz zrejme nepada. Ten vysoky traffic vyzera asi nejak takto.
Na ispfore mi poradili odsledovat to wiresharkom, ale nejak celkom mi to neslo. Ono je to dost blbe, ze ten problem sa objavuje nahodne (pred nedavnom som mal 3 dni pokoj, ale uz sa stalo, ze to bolo aj 3x denne (nastastie siet nepadla)).
Bolo by to mozne nejak odsledovat tcpdumpom ? Alebo vie mi niekto poradit, ako zistit co sa vlastne v sieti deje ? Ale bohuzial nie som sietar profik :)

Odpovědi

[Max]

Je možný, že tám máš loopy v síti a vzniká ti broadcast storm. Jako první bych zkontroloval, zda máš na všech MK bridgích povolený rstp.
+ sem hoď konfiguraci těch dvou MK (viz příkaz export file=mk1.cfg) + v nastavení případně zahvězdičkuj IP, které nemají být vidět + hesla, která nemají být vidět (PSK apod.).
Zdar Max
PS: před delší dobou jsem přešel na ROS 6.34.6 a spokojenost

[jany2]

Chcem sa opytat. Mam v MK dost vela poloziek vo filtri, nat atd .... ktore su disablovane (nechcem ich ale vymazavat). Je mozne urobit export tak, aby tie polozky, ktore su disablovane vo vyslednom configu neboli ?? Pretoze teraz je ten config dost dlhy a je tam vela poloziek, ktore zneprehladnuju config.

btw teraz mi siet bezala cca 12 dni bez problemov a dnes znova neskutocny traffic.

[NN]

nechcem ich ale vymazavat

Proc? Naopak, v tvem pripade by "cista louka" dost pomohla objasnit situaci.

[NN]

Ten spike muze byt zavirovane PC, ktere ti vyflooduje pripojku. Nastav si na firewallu na routeru prisnejsi pravidla..

[GeorgeWH]

Alebo este skor na bridgoch.

BTW, ani sa necudujem takemu stavu siete, ked nie som sietar.

[jany2]

Mam len 2 MK a jeden mam nastaveny v bridge (RSTP som tam ale nemal povolene, ale povolil som ho teraz). Uvidime co bude dalej. Conf mozem poslat, ale je dost dlhy. Skusim ho hodit zajtra na nejaky web ....

btw nepoznate web, kde by som mohol ulozit config, aby bol pristupny napr. aj na editaciu (kedysi som videl, kde sa dali ukladat rozne configy, skripty, kde boli aj farebne zvyraznene, napr. tagy a pod (proste ako nejaky txt editor, napr. geany, ale online).

[jany2]

Nasiel som aj vhodnu stranku na ulozenie configu (aby bol mozno co najprehladnejsi).
Hlavny mikrotik RB450
Wifi mikrotik RB433
Skutocne som vymazal napr. len zhodne pravidla vo firewalle, alebo pridelene ip adresy v dhcp lease, alebo vacsiu cast simplequeue (nechal som vsade len zaciatok napr. zaciatocne IP adresy, zvysok je vymazany a potom koncove IP adresy). To co by nemalo byt verejne som oznacil **** alebo xxxx

[GeorgeWH]

Pridelujes ip adresy z roznych rozsahov interfacom, ktore su v bridge, a potom este na ten bridge das dhcp server. Aky to ma cele zmysel? Mam pocit, ze netusis, co robis.

[jany2]

No tak moment, v dhcp servery mam definovanu jednu siet. (192.168.1.0/24). Bola vytvorena pre ETH2_LAN-KLIENTS. Ostatne interfaces boli nenakonfigurovane (cize v pouzivani boli len ETH1_T-COM a ETH2_LAN-KLIENTS.
Po urcitom case som potreboval zapojit do dalsieho portu ETH3_LAN-HOME dalsi PC, takze som vytvoril bridge medzi ETH2_LAN-KLIENTS a ETH3_LAN-HOME. A to bol vsetko. Adresy sa prideluju z jedneho rozsahu (pokial viem). A vzdy kazdy prihlaseny dostane IP adresu 192.168.1.x (interface ETH3_LAN-HOME sa uz vlastne vobec nevyuziva, mam ho len do zalohy, ak by som potreboval niekedy pripojit PC)

[erotel]

To RB433 je OK.

U RB450 je špatně

/ip address add address=192.168.1.1/24 interface=ETH2_LAN-KLIENTS network=192.168.1.0

add address=192.168.2.1/24 interface=ETH3_LAN-HOME network=192.168.2.0

add address=192.168.3.1/24 disabled=yes interface=ETH4_ZALOHA1 network=\ 192.168.3.0

add address=192.168.4.1/24 disabled=yes interface=ETH5_ZALOHA2 network=\ 192.168.4.0

Pokud máš všechny interface v bridge musí být rozsah 192.168.1.0/24 na dán na bridge jinak to blbne.

add address=192.168.1.1/24 interface=bridge_eth2_eth3 network=192.168.1.0

Tohle,ale z nevysvětlitelným trafficem nemá nic společnýho.

Zkus nastavit na RB450

interface bridge set bridge_eth2_eth3 protocol-mode=rstp

a na RB433

interface bridge set Most protocol-mode=rstp

[jany2]

Teoreticky si tam bridge mozem zrusit celkom, lebo uz ho tam nepotrebujem a dat napr. switch (len musim zistit ako :) )

[jany2]

Problem stale pretrvava. Zda sa, ze uz ale nevypaduje siet (minimalne na server ktory je v LAN sa dokazu pripojit aj klienti z wan) Ako pisal hore max, mozno ide o nejaky loop, ale ako to zistit. Ak som momentalne na PC a pretane fungovat siet, tak na RB 450 sa cez winbox nedostanem. Dostanem sa vsak na RB 433 (kde prave ten vysoky traffic je) a cez torch vidim z akej ip na aku prebieha vysoky traffic.

Tie IP su ale niekedy velmi zvlastne. Niekedy su obidve z LAN a tie PC ani niesu k sieti pripojene. Traffic trva rozne dlho, niekedy 5 minut, niekedy 20 minut a niekedy 3 hodiny. Ak to nahodou zistim, tak pomoze odpojit od siete switch d-link toto ale nie je riesenie.

V poslednej dobe mam takyto traffic kazde rano o cca 07:10 do 07:15 niekedy je to 30Mbps, inokedy 10Mbps. Tu je napr. ako to vypada v mikrotiku a tu je graf zo vcera.

Co sa tyka bridgu na RB 433, tak tam som nastavil na bridgi RSTP. Dalsi bridge som mal este na RB 450, medzi LAN2 a LAN3, tak ten som zrusil celkom.

[Vantomas]

A když se to děje, bliká ten DLink jak vánoční stromeček? Opravdu je ověřeno, že ze switche vede každý kabel do nějakého počítače? Když se tohle děje, zkoušel jsi vypojovat kabel po kabelu ze switche a sledovat zda ten traffic nezmizí?

[jany2]

Vypojovat porty som zatial neskusal, ale urobim to (najskor cez vikend, lebo v tom case, ked sa to deje, tak som v praci). Co sa tyka blikania, tak switch blika stale, nie je to nic strasne, len signalizuje konektivitu (je mozne, ze ak sa deje traffic, tak to bude blikat inak ako bezne, tiez to este preverim).

zatial thx budem cakat na dalsi traffic :)

[GeorgeWH]

no neviem, ale ja tam vidim

192.168.1.46  <->  31.13.92.5  -  8.9Mbps
192.168.1.46  <->  31.13.84.2  -  9.2Mbps

$ host 31.13.92.5
5.92.13.31.in-addr.arpa domain name pointer edge-mqtt-shv-01-frt3.facebook.com.

$ host 31.13.84.2
2.84.13.31.in-addr.arpa domain name pointer edge-mqtt-shv-01-vie1.facebook.com.

[jany2]

Ano niekedy je to IP z vonka, ale viac krat som uz videl IP adresy z LAN 192.168.1.x (voci sebe).

BTW ked uz si zoberieme konkretnu IP adresu 192.168.1.46, tak ta je napojena podla tejto schemy zo switcha dlink (dalej som to uz nerozkresloval, ale z dlinku to ide este cez switch airlive a wifi routra tplink az pak na PC s IP 192.168.1.46).

Ale ked si to logicky zoberieme, preco ten traffic je na RB 433 ?? Ved s konkretneho PC s IP 192.168.1.46 to ide (ako som napisal vyssie) na wifi router tplink, potom cez switch airlive, nasledne to putuje do dlinku a cez RB 450 by to malo prechadzat na DSL.

Preco je potom traffic na RB 433 ??? Toto je pre mna nelogicke ...

[Vantomas]

A je ten switch opravdu switch a nikoliv hub? Když se ten traffic objevuje na RB433, tak je na interfacu vidět jen v RX nebo to přes tu 433 opravdu jde a pak je to vidět rozdělené na RX/TX? A teď nemluvím o tom jak to ukazuje torch, ten kouká na hlavičky paketů a ukazuje to podle nich, ale reálně podle toho jak se to ukazuje ve sloupečku RX/TX rate v interfaces.

[jany2]

2 vantomas - Je to switch a je novy. Co sa tyka RX a TX, tak na tomto obrazku je to vidiet. Na Wlan je to TX a na eth1 je to RX. Skusil som raz Wlan vypnut a traffic pokracoval dalej len na eth1. Myslel som si, ze ked prerusim ten stream medzi wlan a eth1, tak sa to zastavi, ale nezastavilo sa.

2 GeorgeWH - ten tplink je tak tiez v bridge (ja mam celu siet v bridge (vsetky wifi routre su v bridge (samozrejme okrem hlavneho routra RB 450)).

2 Migilenik - neviem, mozno niekto ma win 10 (mam tu par ludi na sieti), ale v tomto problem nevidim. Ked si vsimnes obrazok (druhy link) tak je tam aj jedno okno netwatch s IP 192.168.1.1 a to je hlavny router. Ak je vysoky traffic, tak ten router ide do down, preto sa cez winbox ani na neho nedokazem pripojit (zaujmave ale je, ze eth1 co je vlastne wan, funguje).

[GeorgeWH]

tak tam proste pusti nejaky sniffer, a pozri co tam tecie. alebo ako ti uz bolo povedane, poodpajaj jeden kabel za druhym. inac to bude vsetko len varenie z vody...

[Vantomas]

Fajn, když se děje, že ten traffic teče přes 433, co je vidět v Bridge->Hosts za interface u MACovky, která patří IP brány (to bude ta RB450)? Jestli to ta 433 odbridguje směrem do bezdrátu, tak bridge pro to bude muset mít patřičný záznam v tabulce. Pokud tam bude interface bezdrátu, tak je tam nějaká smyčka a pokud jsou jako klienti Mikrotiky, lze to tímto způsobem na jednotlivých Mikrotikách odhalit. A pokud tam bude interface ethernetu, tak je to hustá záhada, která bude mít naprosto to nejméně logické řešení.

Až se to příště stane, zkontrolovat tedy bridge hosts tabulky, zda tam není něco podezřelého a teprve potom z DLink switche vypojovat postupně kabel po kabelu a zkusit odhalit co je příčinou.

[Martin]

Podle popisu to vypadá na nějaké přeposílání rámců kvůli špatné topologii na druhé vrstvě podle modelu OSI, je tam několik bridgů.

Lze nějak jednoduše grafovat provoz na všech portech? Pokud ano, tak by porovnáním grafů mělo být vidět, odkud kam provoz teče.

tcpdump - na linuxu lze ukládat do souboru a ten pak načíst ve Wiresharku. tcpdump -i eth0 -s 1500 -w /tmp/mujdump.dmp (-s - ukládá 1 500 bajtů nikoli jen hlavičky, -w cesta k souboru PC Windows - zachytávání lze pustit trvale a ukládat vše. Obojí by mělo podporovat omezení velikosti souboru, kam se data ukládají, a jeho přepisování. Po začátku toho provozu lze další ukládání zastavit a podívat se na data.

Pro hledání dat v odchytaném provozu se špatně radí předem. Doporučuji začít spuštěním poradce Expert info,jestli něco neporadí. Pokud tam nějaké rámce cyklují pořád dokola, tak se dají najít. Např.každý IP paket má jedinečný idetifikátor. Ten má 2 bajty, takže se časem musí opakovat, jak OS vytváří nové pakety. OS je obvykle sází postupně, takže ty opakující budou mezi nimi vyčnívat.

Jak radili jiní, lze v případě výskytu postupně odpojovat kabely, než to přestane. Akorát se tím nemusí poznat, které zařízení za to může.

Když se odpojí Internet, ja tam ten provoz pořád? Pokud ano, tak by to potvrzovalo teorii o smyčce. OS sám o sobě tolik dat posílat nebude.

Dále, pokud došel jednou provoz na wifi router RB-433 a to jako příchozí na drátové rozhraní a stejný objem odcházel na rádiové, tak to musel být provoz na neznámou MAC adresu (pak se posílá na všechny porty, když switch nemá záznam v tabulce MAC adres) nebo na MAC, která byla za rádiovým portem. Hodila by se odchytaná data z toho routeru.

[GeorgeWH]

ako mozes na rb433 vidiet rozsah, ktory je za tp-link routrom?

[Migi]

Nejsou v síti Windows 10? Na pomalych připojkach dokaze stahovani Anniversary Upgrade skutečně zabít veškerou ostatní komunikaci.

[jany2]

Hmmm .... ako na potvoru to dnes ide dobre ..... prave ked som to chcel preverovat minimalne odpajanim portov a kontrolou host tabulky.

[frr]

+1. Nedávno za mnou v práci přišel jeden mladý kolega zmlsaný rychlým internetem, a říká "ten internet máš dneska ňákej pomalej. Asi tu někdo jede bittorrent nebo co." Zavrčel jsem něco o nevděčném mládí a spustil na FW iptraf. A vida, jeden konkrétní desktop v LANce tahal jako vzdeklej, vystropoval 20 Mbps WAN uplink (dedicated optika po vlákně). Dohledali jsme tem stoj - a vida: kolega má desítky, a samy o sobě pravily, že tahají updaty. Za chvilku se update stáhl a ten blázinec skončil.

Zvláštní je, že v XP / sedmičkách nám aktualizace linku takhle nedusily. Nepoužíváme lokální repo v doméně, každý jednotlivý stroj si tahá updaty přímo od M$. Malá firma.

=> Buď má MS pro desítky výkonnější aktualizační servery, nebo (to spíš) do desítek zabudoval možnost tahat updaty od jiných uživatelů, technologií "peer to peer" a nejspíš více relacemi. Při instalaci desítek (možná se to dá změnit i dodatečně) jsem zaznamenal zatrhávací fajfku "povolit získávání aktualizací od jiných uživatelů" nebo tak něco - prostě že se různé stroje s Win10 navzájem najdou, nebo je MS centrála navzájem spojí, a samotná objemná užitečná data aktualizací už si předají mezi sebou. Zřejmě to dokážou i v rámci LANky. To je pak samozřejmě hukot Jestli se takhle aktualizuje třeba i moderní CTR office (spekulace, nemám potvrzeno) tak by to byla teprve síla.

Pokud ten p2p traffic prochází byť jenom v rámci LANky nějakým APčkem mezi LAN a WiFi, tak to chroupe procesor toho AP tzn. CPU bude vytížený. A lokální WiFi segment taky. Takže je možné, že ten p2p update "přibrzdí internet" i v případě, že se odehrává "pouze v rámci LAN".

Každopádně se přimlouvám za tcpdump - není nic horšího než wishful thinking. Je potřeba vidět přesně, co se děje. Bohužel na odposlech trafficu to chce managed switch co umí port mirroring (drahý) nebo hub (dnes těžko k sehnání) nebo soft bridge na nějakém Linuxu (stačí OpenWRT) a sniffovat buď přímo na něm, nebo vypnout MAC learning a vyvést třetím eth portem na PC s wiresharkem.

Provozovat síťku pro partu v zásadě cizích lidí s tím že "nejsem síťař" a BYOD je veselá situace Doporučuji schrastit nějaké levné odpadní železo a seznámit se aspoň trochu s Linuxem (prostě skočit do vody).

[Vantomas]

Každopádně se přimlouvám za tcpdump - není nic horšího než wishful thinking. Je potřeba vidět přesně, co se děje. Bohužel na odposlech trafficu to chce managed switch co umí port mirroring (drahý) nebo hub (dnes těžko k sehnání) nebo soft bridge na nějakém Linuxu (stačí OpenWRT) a sniffovat buď přímo na něm, nebo vypnout MAC learning a vyvést třetím eth portem na PC s wiresharkem.

Mikrotik v sobě má packet sniffer. Pakety umí buď streamovat na nějakou IP adresu nebo si nachytaný provoz uložit lokálně do souboru. Dokud se řeší sniffing na tom bezdrátu nebo na té gateway, tak je zbytečné strašit nějakým hubem

[Migi]

Ta funkce v desítkách skutečně je. Distribuce updatů v lokální síti jiz pomerne dlouho, ale jestli se nepletu, tak v jednom z upgradů mela prijit i moznost distribuce dal do internetu, zrejme s MS serverem jako prostrednikem.

[Peter Golis]

Zaujímalo by ma, ako sa k takémuto distribuovaniu záplat cez p2p stavajú v krajinách kde za p2p prenosy odpájajú internet.

[petr_p]

A co teprve obyčejný autorský zákon. Nevšiml jsem si, že by uživatelé měli právo šířit proprietární software.

[Peter Golis]

Toto bude pravdepodobne ošetrené v EULA pre Windows 10. Síce som ju nečítal, ale predpokladám že to tam nezabudli zahrnúť právnici firmy SCO.

Mňa ale zaujímala aktuálna legislatíva v krajinách kde ACTA/SOPA pretlačila prezumpciu viny a každý jeden prenos p2p je automaticky považovaný za nelegálne šírenie dát chránených autorským zákonom. Bez splnenia dôkaznej ťarchy. Takáto vlastnosť Win10 by automaticky odsudzovala užívateľov dlaždíc na odpojenie od internetu 3x a dosť. Ale to sa nestáva. Niečo mi tu teda nesedí.

[Jooky (inactive)]

S tym Win10 to mozem potvrdit. Vsetky masiny maju zakazany ten p2p update, cize win10 taha vsetko z M$ servra. Na uplinku mam QoS. Ked zacne Win10 tahat updaty tak sa to neda zastavit ... M$ servre vysaturuju tak linku, ze vsetko ide do ...

[Josef Kufner]

A nebylo by lepší jim ten P2P přenos povolit, aby si tu aktualizaci stahli jen jednou a pak rozdistribuovali po lokální síti mezi sebou?

[jany2]

Co sa tyka mojho trafficu, tak von to nejde, je to len v ramci LAN. Aspon tak to monitoruje cacti. Ale do wan to na 99.99% nejde, lebo ako vieme tak na slovensku je na VDSL linkach stale uplatnovany FUP (cca do 300 GB/mesiac) a ISP ma tiez svoju statistiku a priblizne sa zhoduje s mojim cacti na gateway.

Ako som uz viac krat spominal, tak v torch na mikrotiku vidim traffic medzi IP adresami, ktore ani niesu momentalne do siete pripojene.

Ale ako uz borci spominali, tak asi (pre nesietara ako som ja) je potrebne ist od zakladu a skusat odpajat jednotlive porty. A ja som to teda skusil. Vyssie som pisal, ze ak odpojim na 2-3 sekundy od napajania cely switch, tak traffic zmyzne a cela siet je zase OK.

Cize zacal som odpajat porty. Hned prvy port co som odpojil, tak traffic zmyzol. Na danom porte je dalej napojeny 1x switch a z neho dalej dalsie 2 switche a z kazdeho switcha dalsie wifi routery (spolu 3 wifi routery (vsetky v bridge mode)). Su to ale obycajne lacne routery, tenda, tplink a dlink. A z nich su potom napojene pc, ntb, smartfony, telky, ci uz cez LAN, alebo wifi .....

Pri dalsom trafficu musim potom ist dalej a odpajat postupne dalsie wifi routery (v switchy asi problem nebude (najskor to bude router (a mozno este skor nejaky PC))).

[frr]

mmchdm podíval jsem se Váš na screenshot z Torche a vidím toto: src:192.168.1.46 dst:31.13.92.5 TX:8.9Mbps src:192.168.1.46 dst:31.13.84.2 TX:9.2Mbps Hodně trafficu na veřejné adresy. Copak jsou asi zač? Nepatří MS nebo tak někomu?

frr@mail:~$ whois 31.13.92.5

inetnum:        31.13.92.0 - 31.13.92.255
netname:        AMS2
descr:          Facebook
country:        NL
admin-c:        RD4299-RIPE
tech-c:         RD4299-RIPE
status:         ASSIGNED PA
mnt-by:         fb-neteng
mnt-lower:      fb-neteng
mnt-routes:     fb-neteng
created:        2014-06-11T19:02:11Z
last-modified:  2014-06-11T19:02:11Z
source:         RIPE

frr@mail:~$ whois 31.13.84.2

inetnum:        31.13.84.0 - 31.13.84.255
netname:        VIE1
descr:          Facebook
country:        AT
admin-c:        RD4299-RIPE
tech-c:         RD4299-RIPE
status:         ASSIGNED PA
mnt-by:         fb-neteng
mnt-lower:      fb-neteng
mnt-routes:     fb-neteng
created:        2014-06-11T18:57:36Z
last-modified:  2014-06-11T18:57:36Z
source:         RIPE

Tvrdíte, že adresa 192.168.1.46 v lokální síti v tu chvíli neexistovala?
Podle čeho tak soudíte?
Neodpovídala na ping?
Co takhle arping, nezkoušel jste?
Máte v síti DHCP? Pokud ano, vidíte mu do logů / do seznamu aktivních leasů?
(Pokládám za nepravděpodobné, že by si stroj vzal sám namátkou nějakou adresu z LAN, takhe autokonfigurace ipv4 nefunguje. Takhle by fungoval lidský hacker, ale nepředpokládám, že Vám v síti někdo takový bydlí, a taky jsem neslyšel, že by se tak choval malware, ale pravda je, že to nesleduju.)

Co když je to nějaký matlafoun, na něm appka, ráno při snídani to někdo připojí k wifině nebo zapne "facebůkovou appku" a appka hrne a hrne, dokud člověk neodejde do práce... Omlouvám se, nepooužívám ksichtoknihu ani appky na matlafounu, takže nemám s těmito moderními výdobytky praktické zkušenosti.

Nepokládám za pravděpodobné, že by malware tlačil data na FB (ale nemám moc přehled, o bezpečnost se zajímám spíš z donucení než se zájmem).

[jany2]

Ten traffic vznika v ramci lan. Ak si pozres topologiu siete (uz to teraz je trocha inak, ale v principe je to to iste) tak zistis, ze je to volajako strasne zvlastne. Traffic je medzi IP adresami, ktore su zapojene do switch d-link a nejakymi wan adresami (casto aj medzi LAN adresami (zapojene len do d-linku)).

Najzaujmavejsie na tom je ale to, ze traffic sa prejavi vzdy na RB 433. RB 450 klakne, dalsie pc sa na net nedostanu lebo RB 450 je v pr**ly (cpu 80-100%), ale wan strana RB450 nevypadne (z internetu sa neodpoji). Po case (ktory trva rozne 5, 10, 20 min .... ) traffic prestane a vsetko funguje dalej.

Vyssie som spominal, ze som zistil postupnim odpajanim portov, ktory port to sposobuje (resp. ktory kabel). Ten kabel ide do switcha z ktoreho su napojene dalsie 2 switche a z kazdeho 1x wifi router (+ este z toho switcha do ktoreho ide dany kabel je napojeny 1x wifi router). Vsetky routre v sieti mam v bridge mode.

Nepytajte sa ma preco je to tak zapojene. Jednoducho to tak musi byt, lebo to nie je v jednej budove a niektore kable maju cez 70m.

Este si sa pytal, ze preco tvrdim, ze adresa v tu chvilu ked bol traffic neexistovala. Videl som v RB450 (niekedy ak je ten traffic mensi, tak sa mi podari cez winbox pripojit k MK) ze IP nebola v ARP liste a dokonca ani v dhcp IP neexistovala. A raz sa mi stalo ze traffic vytvaral PC (moj) pri ktorom som fizycky sedel a cital som si web. Klikol som na link, alebo som hodil nieco do googlu a videl som ze net nejde, tak hned som sa pripojil cez winbox na MK a videl som, ze traffic vytvara moja IP (ale ja som v PC na sietovke nemal ziadny traffic). Vypol som PC a presiel som k inemu PC a pripojil som sa (asi o 5 minut) k RB433 a tam som videl stale traffic na PC ktory uz bol 5 minut vypnuty. Ako moze vytvarat PC 30Mbps traffic, ktory je 5 minut vypnuty.

[JMP]

...Vypol som PC a presiel som k inemu PC a pripojil som sa (asi o 5 minut) k RB433 a tam som videl stale traffic na PC ktory uz bol 5 minut vypnuty. Ako moze vytvarat PC 30Mbps traffic, ktory je 5 minut vypnuty.

to by mohla být kolize IP adres, nebo dokonce dvě stejné MAC adresy v síti (stejné MAC adresy by mohly síť rozbíjet podstatně víc než stejné IP, kdy přestane síťovat jen jeden stroj)

jděte po MAC adresách a po tom, kde jsou připojené...

[frr]

Trochu zeširoka: jak jste se sám přesvědčil, ve větší síti, kde není vyloučen výskyt všelijakých kutilů, přestože je chcete považovat za svou rodinu, je velice vhodné, mít možnost koukat, co se děje. Ještě než tasíte wireshark a opřete se do toho rameny, první krok by myslím měl být, že si pořídíte managed switch. Managed především v tom smyslu, že z něj můžete vyrazit tabulku naučených MAC adres, s vyznačením fyzických portů, odkud daná MAC adresa chodí.

V této souvislosti poznámka: starší switche D-Link (DGS-1216T apod.) byly ochotné ukázat tabulku MAC adres jenom per port. Což stojí za vyliž - protože když hledáte, odkud smrdí konkrétní MAC adresa, musíte zběsile proklikat všech 16 portů. = chcete switch, který ukáže všechny MAC adresy pěkně pohromadě v jedné tabulce, setříděné podle MAC adresy. Tuším i D-Link už přišel k rozumu (na svých aktuálních web-smart switchích) - ale jsou i jiné levné značky, než D-Link.

Bohužel levné managed/websmart switche nemají příkazový řádek, který může být pro další zpracování textu vhodnější než HTML. Také nemívají SNMP, pomocí kterého byste si mohl celou síť olíznout skriptem z nějakého unixu a grepnout MAC adresu jedním příkazem z celé sítě. Takže na levném switchi musíte přece jenom klikat.

Pokud chcete začít "zlehka", mohl by Vás zajímat třeba Zyxel GS1900-8. Webový management, osmiport, myslím za dost příjemnou cenu. Umí tabulku MAC adres zřejmě za všechny porty hezky v kostce (browser v tom bude schopen textově vyhledávat), umí VLANy včetně trunkových portů (tagged provoz), umí port mirroring... aspoň podle manuálu (odkaz výše). Možná někdo navrhne vhodnější boxík. Tenhle switch bych posadil na nějaké strategické místo - sám budete vědět nejlíp.

Pokud by nevyhovoval management od Zyxelu, ale máte rád Mikrotik (a máte po kapsách nějaký zbytečný routerboard), můžete použít Zyxe na "rozplet" portů: co port to VLAN, jenom jeden port Zyxe zapíchnout jako trunk do Mikrotiku, a až v Mikrotiku VLANy navzájem probridgovat (oops - doufám že to jde. Mělo by. Určitě jde bridgovat mezi VLAN subinterfejsy různých rozhraní, a taky třeba mezi ESSIDy. A bridguje to softwarově Linux inside.) Prostě router on a stick. Akorát že tady by to byl spíš soft-bridge on a stick Pozor: je to dobré snad jako dočasné komfortní řešení, pro hledání zdroje toho problému - routerboard mezi VLANami bridguje/routuje softwarově, takže rozhodně nezvládne bridgovat "rychlostí L2 portu", jako to zvládá hardwarově samotný Zyxel (nebo libovolný jiný prašivý switch, i bez managementu). Pokud máte v LANce fileserver nebo jinou takovou rychlou službu, byl by routerboard úzkým hrdlem.

Viděl jsem motherboardy, které měly z výroby MAC adresu "samé nuly". Ty se samozřejmě neměly rády pohromadě na LANce Jinak když useři vědí, jaký je lokální subnet, ti schopnější si třeba vyberou IPčko podle svého. Lama nabyde dojmu, že spoléhat na DHCP je známkou slabosti, nebo chce mít pevnou adresu na domácím media serveru a už nedomyslí, že i pevné adresy musí někdo správcovat/přidělovat - vy jako admin nestačíte zírat. Nebo Vám někdo strčí do sítě svoje vlastní APčko, nechá na něm zapnuté DHCP, a aby se to nepletlo, nastaví v něm stejný pool, jaký máte v LANce... atd atp. Pokud si někdo půjčil Vaši IP adresu a hrne hodně dat skrz router do internetu, tak není divu, Vy sám máte problém se na router přihlásit. A není to nutně vytížením CPU na routeru, je to tím, že se perete o IP adresu, a ten slon co Vám ji ukradl má díky velkému počtu paketů statisticky mnohem lepší šanci, že si router podrží v ARP tabulce mapování daného IPčka právě na *jeho* MAC adresu. V této souvislosti není špatné, mít pro management na routeru samostatný subnet = nejmíň sekundární subnet na sdíleném L2 médiu, o kterém užovky nevědí (lépe fyzický port nebo "managementovou VLANu"). Pokud tenhle blok adres zvolíte dostatečně obskurní (někde uprostřed jednoho z privátních bloků) a neukážete ho ostatním, nikdo Vás o IPčko pouhou nedbalostí nepřipraví.

Pozor pokud máte v LANce bridgujicího WiFi klienta v režimu s třemi adresami, budou se stroje za tímto "WiFi client bridgem" tvářit vůči nadřízené síti (skrz normální bridgující AP) všechny jako jedna jediná MAC adresa. Client bridge provádí kvůli 3adresnímu režimu "MAC maškarádu". Jediná MAC adresa a na ní fůra IP adres. Pokud tohle máte, zvažte 4-adresní režim (což tuším zas nejde moc dohromady s "normálními" koncovými WiFi klienty). Jsou kolem toho nějaké proprietární hybridní varianty konfigurace... nebudu to tady rozmazávat

Od určité velikosti sítě (Vy jste jí patrně právě dosáhl) přestane být únosné, nevidět co se děje. Svého času jsem nastoupil do malé firmy, kde byl Ethernet postavený na unmanaged switchích, a byly tam i jisté nedostatky v kabeláži. Nasazením levných managed switchů a výměnou/učesáním kabeláže se síť výrazně stabilizovala. Přestaly se vyskytovat problémy typu "někde něco hnije" a pokud někdo začne v síti páchat jakousi podvratnou činnost, dá se docela snadno dohledat, která bije. Nemusíte hned koupit Cisco a stavět striktní hvězdu po celém baráku. Pravda je, že ty levné managed switche bývají po záruce zralé na repasi elytů (a výměnou elytů za solid polymer získají nesmrtelnost. Takže pak máte v síti dokonale živé deset let staré krámy, pro které nikdy nevyšel update firmwaru, a port OpenWRT je v nedohlednu. Což mě u switche v LAN trápí naštěstí trochu míň, než by mě to trápilo u firewallu.)