Dotaz: OpenWRT občas propustí packety z LANu do WANu bez maškarády?

[Harvie.CZ]

Ahoj, resim zvlastni problem... Mam domaci router Asus s OpenWRT a nedavno jsem ho upgradoval na nejnovejsi stabilni Attitude Adjustment. Funguje to fakt dobre podle mejch predstav az na jeden detail... Bohuzel od ty doby tak jednou za 2 tejdny ten router udela neco, co na cisco switchi u ISP (centrio/centronet) aktivuje nejakej security mod a trvale vypne port az do doby nez zavolam na jejich helpdesk, aby to zas odblokovali... Je to dost otravny, obzvlast kdyz tam nejsou kazdej den...

Na helpdesku tvrdili, ze to blokujou v pripade, ze na tom routeru vidi packety od vic MACovek... Jinde sem zas slysel, ze to muze delat STP. Ale overil jsem, ze STP je vypnuty na vsech bridgich. Puvodne jsem myslel, ze to je tim, ze se nejak vyresetuje nastaveni toho interniho switche v tom routeru a prepne se to do nejakyho hloupyho rezimu, kdy switchuje mezi vsema portama, ale to by se pravdepodobne stavalo jenom treba pri resetu nebo upgradu firmwaru nez se ten switch nastavi korektne...

Netusite nekdo, jak muze u OpenWRT dojit k tomu, ze ISP na WAN interfacu vidi vic MACovek nez jenom tu toho routeru?

Odpovědi

[pokus]

asi bych to zkusil nasledovne, teda pokud si nezkousel: 1/ restart routeru do tovarniho nastaveni 2/ provest novou konfiguraci 3/ vypnout vsechny zbytecne featury nechat jen zaklad (NAT, firewall) 4/ procist seznam zmen v novem fw

Mohl by to delat klidne i dhcp relay pokud by byl zaplej. Proste over jestli mas opravdu zaple jen to co potrebujes. At ti poskytovatel zdeli v pripade blokace mac adresu ktera se na portu objevila jako sekundarni. Muzes se zkusit podivat jestli to je z tve vnitrni site nebo je generovana routerem.

[Harvie.CZ]

S tovarnim nastavenim to neni tak snadny, pac je to tak trochu image na miru... Proti standartnimu OpenWRT jsou tam navic nainstalovany/nakonfigurovany jenom tyhle veci:

forwarding portu
OpenVPN klient
6to4 + radvd
p910nd printserver
syslog klient
ntp klient
UPnPd

Takhle jsem to sestavil:

make image PACKAGES="kmod-usb-core kmod-usb-uhci kmod-usb2 kmod-b43 6in4 6to4 kmod-ipv6 kmod-usb-printer kmod-sit kmod-tun luci miniupnpd mtr nano ip openvpn p910nd radvd usbutils wireless-tools wol kmod-usb-serial kmod-usb-serial-ftdi kmod-usb-serial-pl2303 htop iperf netcat ngrep screen -ppp -ppp-mod-pppoe -kmod-ppp -kmod-pppoe -luci-proto-ppp

[Petr Šobáň]

Asi bych zrušil UPnPd zda to nedělá.

Taky by se to tam mohlo procpat nějak přes IPv6.

Takže taky bych spíš upravil firewall aby lokální IP nemohly ven, a omezit wan na tu jednu MAC.

Jinak co je to za dementního ISP když po pár vadných paketech odstřihne linku natrvalo?

Neřeknu kdyby to vytěžovalo linku či byl tam velký provoz.... taky by ISP měl říct uživatelovi co mu vadí a předložit ten vadný paket aby se dohledal původ paketu.

[pavlix]

Nevím, proč by UPnP nebo cokoliv od třetí úrovně výše mělo způsobovat více MAC adres. Buď to zavírají z jiného důvodu, nebo to nejspíš tyhle technologie nebudou.

[Petr Šobáň]

Protože můžou spůsobit při přestavování pravidel firewalu průchod nějakého bordelu přes switch, nat co já vím.

Samotné je to divné jak změna MAC může mít vliv na přenos paketů....

Pak mě napadá ještě jedna varianta prostě má tam připojený ještě nějaký prvek se stejnou MAC a pak se neví na kterou odpovídat a vznikne kolize a nefunguje to potom bych si vymyslel nějakou MAC a tu nastavil na wan rozhraní - aby byla jiná.

[pavlix]

Protože můžou spůsobit při přestavování pravidel firewalu průchod nějakého bordelu přes switch, nat co já vím.

Zase na druhou stranu, když něco nevím, tak to nepíšu. Už tak vznikne dost balastu z toho, když se člověk v dobré víře splete.

Samotné je to divné jak změna MAC může mít vliv na přenos paketů....

Jedna z možností byla vysvětlena už v dotazu.

[Harvie.CZ]

A nejdivnejsi je, ze to udela jenom jednou za 2 tejdny...

[a1bert]

a jakej ma ten openwrt uptime po tom co se to stane?

H0: dochazi k restaru routeru pri kterem, integrovany switch (na chipu), drive nez jsou z nej poskladana virtualni rozhrani, propusti par paketu (jako switch)..

[pavlix]

H0: dochazi k restaru routeru pri kterem, integrovany switch (na chipu), drive nez jsou z nej poskladana virtualni rozhrani, propusti par paketu (jako switch)..

Myslel jsem si, že už jsem tenhle odhad do diskuze poslal, ale očividně jsem ho nechal viset a zavřel prohlížeč.

[Harvie.CZ]

Tohle me napadlo taky, akorat nepredpokladam, ze by se router tak casto sam od sebe restartoval... Nicmene kdyz ho nekolikrat po sobe vyrestartuju rucne (jak softwarove, tak vytazenim z elektriky), tak se nic nedeje...

Uptime si bohuzel neprectu, pac to pokazdy resim na dalku a jsem tudiz odriznutej...

Je pravda, ze poprvy problem nastal pri flashovani novy verze OpenWRT. Ta verze co jsem tam mel predtim to nedelala vubec. Po naflashovani se nerozsvitil WAN port. Coz predpokladam je presne z tohodle duvodu, ze to zacalo switchovat po tu dobu nez se to flashovani dokoncilo.

Takze poucka je, ze je dobry pred flashovanim odpojit router od uplinku, pokud neni pod moji spravou...

[Petr Šobáň]

Ledky s tím nemají nic co do činění ty ovládá CPU a né HW switch.

Taky flash s tím nic neudělá pokud nemáš vlastní přeložený FW kde máš chybu.

Samozřejmě při nějakém resetu se může HW přepnout že se to bude chovat jako hub, ale to je snad 1s a za tu dobu může projít pouze pár paketů a z toho důvodu ti to isp odpojí????

Já si myslím že ti ISP lže má nějaké poruchy na lince z kterých se mu nevzpamatuje jeho HW a svádí to na tebe, prostě ať dodá laskavě ty vadné pakety a můžeme se pak kouknout kde je problém.

A další věc ať si budu vymejšlet jakoukoliv MAC a každý paket odešlu s jinou MAC tak mi nemá provider co odpojovat linku, maximálně ty pakety s jinou MAC má zahodit, ale s tou správnou má propouštět normálně dál, tak stejně pokud budu na linku pouštět pakety s různou IP má propustit tu správnou (kterou mi přidělil) a ostatní zahodit - samozřejmě já se mám snažit aby z mé sítě nelezl bordel, ale ani on by to neměl odpojovat po pár vadných paketech - případně by mě měl zdělit kde je problém a vyřešit ho společně.

[pavlix]

Samozřejmě při nějakém resetu se může HW přepnout že se to bude chovat jako hub

Předpokládal bych spíše switch.

A další věc ať si budu vymejšlet jakoukoliv MAC a každý paket odešlu s jinou MAC tak mi nemá provider co odpojovat linku, maximálně ty pakety s jinou MAC má zahodit

To je sice pravda, na druhou stranu pokud tazatel neposlal providera do řiti doteď, asi má k tomu dobrý důvod, takže mu tohle moc nepomůže. Jenom jednou mi bylo platné člověku od providera říct do telefonu, že krmí nesmyslama, a to byl člověk, kterého jsem znal osobně. Pikantní na tom bylo, že nakonec byla chyba v zařízení zákazníka, protože Mikrotik, ale bez pomoci providera by bylo docela náročné to zdetekovat.

[Petr Šobáň]

Předpokládal bych spíše switch.

Když se resetne switch tak se to chová jako hub prostě to pošle všem portům a kde dojde odpověď tak si to poznačí a pak to posílá už pouze tam.

[pavlix]

prostě to pošle všem portům a kde dojde odpověď tak si to poznačí a pak to posílá už pouze tam.

Tedy se to chová jako switch a nikoliv jako hub.

[Petr Šobáň]

Vlastně máš pravdu.

Ale doufám že jsi pochopil co jsem chtěl říct že jednu chvíli to pošle prostě všude a pokud ISP vadí pár paketů tak nevím.......

[Jooky (inactive)]

Pravda je niekde medzi :) Switch, nez si spravi MAC tabulku, tak sa sprava ako HUB.

btw. o aky model asusu ide ? Ja som sa hral s RT-N10U a ten ma hardwarovo odeleny wan port. Takze nejaky "medzi stav" nie je mozny na wan porte.

[pavlix]

Switch, nez si spravi MAC tabulku, tak sa sprava ako HUB.

Nesmysl.

Takhle se to možná říká ve škole, aby se to moc nekomplikovalo lidem, kteří to v životě nebudou potřebovat.

[Jooky (inactive)]

Mozes my vysvetlit v com je to nezmysel ? :o)

Ak na switch pride ramec s cielovou MAC, ktora nie je v MAC tabulke, tak ramec preposle na vsetky porty a poznaci si zdrojovu mac adresu do tabulky. Teda spravanie presne vystihuje termin HUB.
Pre tu konkretnu cielovu adresu sa bude spravat ako HUB az do momentu, kedy masina s tou MAC adresou nieco posle a dojde k zapisu MAC do tabulky. Ked uz cielova adresa je v tabulke, tak vsetky ramce budu smerovane len na konkretny port, kde sa nachadza. Takze v tom momente sa uz sprava podla terminu SWITCH.

Zo switchu sa pre konkretnu komunikaciu (alebo aj vsetku), moze znova stat HUB. Staci ak z nejakeho dovodu "vyprchaju" udaje v MAC tabulke, potom sa znova opakuje situacia popisana hore.

[pavlix]

Mozes my vysvetlit v com je to nezmysel ? :o)

V tom, že chování switche je značně odlišné od chování hubu. Od začátku do konce. Pokud chceš znát detaily, bohatě postačí anglická wikipedie nebo nějaká česky/slovensky psaná kniha na tohle téma.

Teda spravanie presne vystihuje termin HUB.

Až na to, že klasický HUB žádné rámce nenačítá a nepřeposílá a ani neumí pracovat v režimu, v jakém se dneska běžně switche používají. Ne vždy se dají školské poučky aplikovat na reálný svět. Bylo by docela fajn, kdybys přestal diskuzi plnit nesmysly.

[Jooky (inactive)]

ma vobec cenu na toto reagovat ? Bud sa potrebujes s niekym hadat, alebo trolovat. Staci pozriet aj ostatne tvoje prispevky k tejto otazke.

To, ze sa switchu povie "hub" ak ma prazdnu, alebo vysaturovanu tabulku je uplne prirodzene aj v enterprise prosteredi. Ano, aj tak pouziva "store&forward", alebo "cut-through", no vysledok je ten isty. Ramce skoncia na kazdom porte ... a o to ide. Otazku polozil zrejme nie uplne znaly clovek, takze meditovat ci to je 100% spravne, alebo nie, neni uplne na mieste ...

ps. mam za sebou Cisco certifikaciu a viac ako 8 rokov v enterprise prosteredi, takze viem o com hovorim :o)

[pavlix]

mam za sebou Cisco certifikaciu a viac ako 8 rokov v enterprise prosteredi, takze viem o com hovorim

A zjevně ani to ti nebrání zde šířit bludy.

[Petr Tomášek]

případně by mě měl zdělit

chi a pak budes vejpul

[pavlix]

Tohle me napadlo taky, akorat nepredpokladam, ze by se router tak casto sam od sebe restartoval... Nicmene kdyz ho nekolikrat po sobe vyrestartuju rucne (jak softwarove, tak vytazenim z elektriky), tak se nic nedeje...

Dneska jsem nad tím přemýšlel a napadlo mě, jestli při tom testu neděláš nějakou chybu nebo jestli je ten test dostatečně průkazný.

Uptime si bohuzel neprectu, pac to pokazdy resim na dalku a jsem tudiz odriznutej...

Uptime si přečteš hned po opětovném zprovoznění a porovnáš ho s časem uplynulým od počátku výpadku. Doporučil bych to už jen proto, abys mohl restart celého zařízení vyloučit. Dále by bylo dobré pečlivě ověřit logy z té doby, především pokud jde o kernel, jestli nedošlo k nějakému mikrorestartu třeba toho switche samotného. Pokud to ovšem ovladače nehlásí, tak smůla. Samozřejmě je třeba ověřit, zda někdo v té době nezasahoval do konfigurace.

Pokud by byla chyba skutečně v počátečním nastavení switche, pak by mohl pomoct hardware s odděleným WANem. Pokud jde o připojení k netu, lze vyzkoušet třeba i nějaký USB ethernet adaptér do začátku. Odposlech konkrétního paketu, který to způsobuje, by se mohl případně realizovat na samostatném zařízení, které by se postavilo mezi a které by rovněž mělo oddělené ethernety namísto jednoho switche.

To je vše, co mě k tomu zatím napadlo.

[R]

Pripoj WAN cez hub a do toho hubu pripoj PC s tcpdumpom alebo wiresharkom. Samozrejme, daj pozor, aby to PC nevysielalo ziadne pakety.

[pavlix]

1) Hub se dnes těžko shání.

2) Když jsem naposledy viděl někde v prodej hub, byl to ve skutečnosti switch.

3) Hub zásadním způsobem mění síť z pohledu providera, ať už se jedná o snížení rychlosti, vypnutí full duplexu, zapnutí řešení kolizí nebo cokoli jiného. Vzhledem k tomu, že problémy mají zvláštní charakter už teď, lze v reakci na připojení hubu očekávat takřka cokoliv, současné síťové prvky nebudou pravděpodobně s hubem vůbec testované.

4) Tazatel používá OpenWRT, takže naprostou většinu problémů může odchytit tcpdumpem spuštěným přímo na tom OpenWRT.

[R]

1) Novy tazko, ale stary hub ma dost ludi niekde zahrabany. Tu vo firme su tri - 24-portovy, 12-portovy a 8-portovy, z toho jeden pouzivam a druhy som akurat doniesol z vedlajsej budovy, kde bol docasne pripojeny.

2) To je mozne. Huby sa uz asi dost dlho nevyrabaju. Niekde som kedysi videl aj oznacenie "switching hub".

3) Nikdy sa mi nestalo, ze by nejake zariadenie, ktore ma v specifikacii "ethernet 10Mbps" na hube neslo. Ale ked je provider debil, tak je mozne vsetko, napriklad moze mat na porte nastavene natvrdo 100Mbps FD.

4) Kedze moze ist o HW problem, tcpdump to nemusi vidiet.

[pavlix]

1) Novy tazko, ale stary hub ma dost ludi niekde zahrabany

Ne každý provozuje vlasní skládku elektrošrotu.

3) Nikdy sa mi nestalo, ze by nejake zariadenie, ktore ma v specifikacii "ethernet 10Mbps" na hube neslo.

Nemám přehled o tom, jak které Cisco podporuje 10Mbps a/nebo

Ale ked je provider debil, tak je mozne vsetko

Podle popisu problému bych tam „debila“ docela předpokládal ;).

napriklad moze mat na porte nastavene natvrdo 100Mbps FD.

Nejsem znalý všech technologií, co se aktuálně u různých providerů používají, ale můžou tam mít cokoliv. A nemusí se jednat o to zmíněné Cisco, ale může to být nějaké zařízení mezi.

4) Kedze moze ist o HW problem, tcpdump to nemusi vidiet.

To bezpochyby.

[Lol Phirae]

OMG. Pošli ISP do zadele, "problém" vyřešen.

[rats]

Ehm... Chybi jedna podstatna informace, ktera muze zcela zmenit pohled na vec - predpokladam, ze pokud ISP filtruje provoz podle zdrojovych MAC adres, tak mezi tvym routerem a jeho switchem je prime spojeni (metalicke, opticke, ...), anebo maximalne L2 switch (byt treba s izolaci do port-based VLAN). Je tomu tak?

Za dalsi - pises o domacim "routeru" - tudiz tvuj pristup k ISP je routovany? Pres jeden WAN port routeru? Neni nahodou bridgovany (L2)? Neni to prilis pravdepodobne, ale mozne to je...

A jeste - vykasli se na HUB. Pouzij L2 managovatelný switch, a port mirroring, abys videl, co ti tam kde leze. Pripojeni takoveho prvku IPS nepozna, a tobe poleze do monitorovaciho PC veskery provoz.

Poznamka: Security-by-MAC-address je naprosto bezne pouzivana featura na switchi, a je rozhodne ferovejsi nez jakykoliv jiny druh "jednoducheho" omezovani pristupu do site na urovni L2.

[pavlix]

Myslím, že z příspěvku jasně vyplývá, že má připojený router s routovanou sítí přímo na linku ISP. Managed switch jde v tomto případě brát víceméně jako ekvivalent SW bridge.

Pro člověka z oboru žádná security by MAC address nefunguje, pro uživatele OpenWRT už vůbec ne. Existuje jen omezování podle MAC adresy nebo detekce bridgů. To první bych viděl jako ochranu proti BFU, že když někde splaší router, tak musejí aspoň zavolat providerovi a on si může poznamenat, že mají vlastní router, aby za půl roku, až jim něco nepůjde, je mohl poslat doháje, že si to zkurvili sami. To druhé mi připadá, že je tu jenom proto, aby se lidé nenudili.

[rats]

Myslim, ze nemas nejmensi tuseni, o cem pises, ale hlavne ze pises... MAC adresa nema s routovanim nic spolecneho, jde o to, ze pokud uplatnuje ISP securitu na MAC adresu, musi byt router zakaznika i pristupove zarizeni providera na jednom fyzickem segmentu. Proto se ptam - je to spojene na L2, anebo je mezitim router nebo cokoliv jineho, co muze modifikovat zdrojovou MAC adresu?

Pro cloveka z oboru funguje security by MAC stejne jako pro kohokoliv jineho (OpenWRT na tom nic nemeni) - to je takovy oblibeny mytus "podvrhnu MAC adresu", ale v praxi to zdaleka tak jednoduche neni, zvlaste pokud neni mozne odpojit puvodniho majitele povolene MAC adresy.

Proste a jednoduse - na portu switche se objevi vice MAC adres typicky v pripade, ze je k nemu pripojen dalsi switch (pripadne hub) nebo bridge (napr.: virtualizace). Zadny NAT, portforwarding, firewall, zadne L3 aktivity s tim nemaji nic spolecneho.

[pavlix]

Myslim, ze nemas nejmensi tuseni, o cem pises

Mám z tebe na chlup stejný dojem. To, že si vymýšlíš tvrzení a pojmy, které jsem v příspěvku, na který reaguješ, ani nepoužil, to jenom potvrzuje.

[dustin]

Už jsem se setkal s tím, že linuxový router s NATem přestal natovat a k providerovi posílal packety se zdrojovou adresou vnitřní sítě. Co si pamatuji, musel jsem flushnout conntrack

conntrack -F conntrack

Příznaky byly jako např. http://www.linksysinfo.org/index.php?threads/possible-nat-table-ip_conntrack-issue.27122/

[Jooky (inactive)]

Kedze nam pavlix celkom tapetuje diskusiu len narazkami na ludi, ktory sa snazia pomoc, tak skusim zalozit nove vlakno.

V predchadzajucej casti mi chyba par podstatnych odpovedi:
- o aky HW ide (presny model) ?
- aku verziu OpenWRT pouzivas (verzia / build, dd-wrt ma buildy "vpn", "voip", etc.) ?
- je nejaka dalsia "krabicka" u teba na wan porte (ja mam napr. prevodnik ethernet -> optika) ?
- pouzivas "Clone MAC" na wan porte ?
- pouzivas nejake specialne funkcie OpenWRT (VPN, UPnP, ...) ?
- pouzivas VLANy a SWITCH inak ako vsetky porty v jednej grupe na LAN strane ?
- ked dojde k problemu, tak je mozne aby niekto odpojil, chvilu pockaj a spat pripojil kabel do wan portu ?
- je mozne aby vyjadrenie dal technik, nie len help desk (log so switcha na ich strane) ?

Ono ochrana, ktoru opisujes, sa vacsinou implementuje na pocet MAC addries na aktivnom porte. Po zapnuti portu sa nauci "prva" a ak sa objavi nejaka dalsia, tak sa port vypne. Ide o jednoduchu ochranu pred "viac zariadeniami" na jednom porte. Uz ako vznikne viac zariadeni moze byt rozne. Moze ist o nejaku SW/HW chybu, alebo medzistav pocas bootovania. Uz som videl aj enterprise grade switch, ktoremu trvalo niekolko minut nahodit vlany ...

[pavlix]

Kedze nam pavlix celkom tapetuje diskusiu len narazkami na ludi, ktory sa snazia pomoc, tak skusim zalozit nove vlakno.

Pokud bysis byl sebou skutečně tak jistý, neměl bys toto vůbec zapotřebí. Prostě bys založil vlákno nebo přidal příspěvek s novými radami, jako jsme to udělali my všichni ostatní. Nicméně nebuu ztrácet čas s někým, kdo má potřebu se v diskuzi ohánět certifikátama, to mi připadá tak směšné, až to bolí. Přeju hezký den plný lidí, co ti odkývají každou blbost.

[Lol Phirae]

Nejde ti nějak blbě kalendář?