Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: lukano 11. 01. 2020, 16:19:19

Název: Rozdělení switche
Přispěvatel: lukano 11. 01. 2020, 16:19:19
Resim jeden projekt kde to uplne nechci resit VLAN a tudiz me napada. Existuji switche napr 48 port ktere si primo ve switchi rozdelim na nekolik switchu? Priklad.... chci aby port 1-9 byl pro tu firmu (1port jejich router a zbyle porty 2-9 jejich datove zasuvky)
Název: Re:rozdeleni switche
Přispěvatel: robac 11. 01. 2020, 16:30:41
Ano, jakykoliv switch, ktery podporuje VLANy  :)

Pujde to u Mikrotiku. Kdyz jsem to delal naposledy, tak tusim RB 2011 mel porty rozdelene na sve casti (jedna jenom FastEthernet) a kazda mela svuj switch chip. Me by ale uz nikdo nedonutil pouzit Mikrotik jako switch, ikdyby me mucil mekkymi polstari  ;D

Normalne pouzije switch s VLAN a mate standardni a hlavne normalni reseni.
Název: Re:rozdeleni switche
Přispěvatel: lukano 11. 01. 2020, 16:44:05
ale ja prave nechci pouzivat vlany :-)
Název: Re:rozdeleni switche
Přispěvatel: _Jenda 11. 01. 2020, 18:31:18
Chceš, a pak zvolené porty dáš do té VLANy a nastavíš je jako netagované.
Název: Re:rozdeleni switche
Přispěvatel: veskotskujehnusne 11. 01. 2020, 18:39:13
Tak nám určitě prozradíš, proč nechceš použít ideální řešení, které kvůli tomu vzniklo.

ale ja prave nechci pouzivat vlany :-)
Název: Re:rozdeleni switche
Přispěvatel: Michal Šiman 11. 01. 2020, 19:46:55
nemusis pouzivat vlany, jen v ten switch rozdelis (oddelis skupiny portu) pomoci vlan, to je uplne normalni, tak se to dela. vlany nikde jinde pouzivat nebudes.

jinym zpusobem rozdeleni switche neudelas. tecka. :-) pak je lepsi proste pouzit vic mensich switchu.
Název: Re:rozdeleni switche
Přispěvatel: robac 11. 01. 2020, 21:52:36
Tak nám určitě prozradíš, proč nechceš použít ideální řešení, které kvůli tomu vzniklo.
Také by mě to zajímalo...
Název: Re:rozdeleni switche
Přispěvatel: f-k-r 11. 01. 2020, 23:16:39
Resim jeden projekt kde to uplne nechci resit VLANAMA a tudiz me napada. Existuji switche napr 48 port ktere si primo ve switchi rozdelim na nekolik switchu? Priklad.... chci aby port 1-9 byl pro tu firmu (1port jejich router a zbyle porty 2-9 jejich datove zasuvky)

Nedělá si z nás někdo šprťouchlata ?-)?
Název: Re:rozdeleni switche
Přispěvatel: sartori 12. 01. 2020, 00:16:57
Cisco NXOS umí "virtual device context", v podstatě switch rozdělí na několik zvlášť spravovatelných kusů. Je pro to potřeba použít vhodný hardware, z hlavy třeba Nexus 7000, Nexus 7700, pravděpodobně i něco z řady Nexus 9000.
Název: Re:rozdeleni switche
Přispěvatel: Michal Kubeček 12. 01. 2020, 00:57:07
U levnějších "domácích" switchů tomu říkají "port based VLAN"; sice to má v názvu "VLAN", ale s 802.1Q to nemá nic společného, prostě jen jednotlivým skupinám portů přiřadíte "VLAN" a porty pak komunikují jen v rámci skupin. Totéž ale nakonfigurujete i s normální VLAN konfigurací, jak už bylo řečeno: každému portu přiřadíte jen jednu VLAN jako untagged+PVID, tím pádem nikde žádné tagy nebudou a vy budete mít jednotlivé skupiny navzájem oddělené.

Jediný problém by asi byl, kdybyste potřeboval v rámci toho "podswitche" používat 802.1Q. K tomu pak slouží "nested VLAN" (802.1ad).
Název: Re:rozdeleni switche
Přispěvatel: mmenphis 12. 01. 2020, 02:24:55
Některé levné switche tohle umí i bez 802.1Q. Např. TP-Link umí nastavit, které porty na switchi si mohou mezi sebou předávat provoz. V administraci je to skryto pod označením "Port Isolation"
Název: Re:rozdeleni switche
Přispěvatel: lubor 12. 01. 2020, 02:36:37
Cisco VDC. Ale to je min. nad Nexus 7K.
Název: Re:rozdeleni switche
Přispěvatel: František Ryšánek 13. 01. 2020, 12:43:30
Tak nám určitě prozradíš, proč nechceš použít ideální řešení, které kvůli tomu vzniklo.
Také by mě to zajímalo...
Ano. Taky mi vrtá hlavou, jestli je za tím zcela konkrétní technická obava z jediné společné FDB/CAM tabulky (takže lze mezi VLANami páchat DoS útok únosem MAC adresy), nebo obecně bezpečácká obava se sdíleného kusu hardwaru, kterým by se teoreticky mohl někdo probourat nebo ho položit (opět DoS), nebo jestli nakonec zcela banálně tazateli připadají VLANy složité na konfiguraci...
Název: Re:rozdeleni switche
Přispěvatel: _Jenda 14. 01. 2020, 00:31:12
Já bych to tipl na to, že tazatel nevěděl, že port ve VLAN může být untagged.
Název: Re:rozdeleni switche
Přispěvatel: František Ryšánek 14. 01. 2020, 21:59:41
Já bych to tipl na to, že tazatel nevěděl, že port ve VLAN může být untagged.
Nojo, pokud bych žil v představě, že kvůli nasazení VLAN budu muset trunkovat i proti všem klientům (tzn. na klientech to nastavit), tak bych se asi taky VLAN bál jak čert kříže :-) Shodou okolností jsem před časem sesmolil takové velmi začátečnické obrázkové intro, a doufám nebude vadit, když si přihřeju polívku (http://support.fccps.cz/download/adv/frr/VLAN/vlan.html)...
Název: Re:rozdeleni switche
Přispěvatel: FKoudelka 15. 01. 2020, 21:56:13
Já bych to tipl na to, že tazatel nevěděl, že port ve VLAN může být untagged.
Nojo, pokud bych žil v představě, že kvůli nasazení VLAN budu muset trunkovat i proti všem klientům (tzn. na klientech to nastavit), tak bych se asi taky VLAN bál jak čert kříže :-) Shodou okolností jsem před časem sesmolil takové velmi začátečnické obrázkové intro, a doufám nebude vadit, když si přihřeju polívku (http://support.fccps.cz/download/adv/frr/VLAN/vlan.html)...
Moc pekny, dik
Název: Re:rozdeleni switche
Přispěvatel: SB 16. 01. 2020, 14:59:16
...z jediné společné FDB/CAM tabulky (takže lze mezi VLANami páchat DoS útok únosem MAC adresy)...

...přihřeju polívku (http://support.fccps.cz/download/adv/frr/VLAN/vlan.html)...

„...it's possible to force a switch to re-learn a MAC address to a "wrong" port (= away from the correct port) by sending a packet with the "attacked" MAC address as a source address in the attacking frame (= MAC address spoofing), from an untagged port belonging to a different VLAN.“

Jak by to mělo fungovat? Přepínač odešle následné pakety určené pravému příjemci do VLAN útočníka? Když zavysílá pravý příjemce ze své VLAN, tabulka se opět přepíše zpět a útok končí? Co když má přepínač (jako např. Mikrotik RB260) zamykání portů k MAC?
Název: Re:rozdeleni switche
Přispěvatel: Miroslav Šilhavý 16. 01. 2020, 16:07:09
„...it's possible to force a switch to re-learn a MAC address to a "wrong" port (= away from the correct port) by sending a packet with the "attacked" MAC address as a source address in the attacking frame (= MAC address spoofing), from an untagged port belonging to a different VLAN.“

Jak by to mělo fungovat? Přepínač odešle následné pakety určené pravému příjemci do VLAN útočníka? Když zavysílá pravý příjemce ze své VLAN, tabulka se opět přepíše zpět a útok končí? Co když má přepínač (jako např. Mikrotik RB260) zamykání portů k MAC?

Nenapadá mě, jak by se to dalo zneužít kromě DoS útoku - switch si bude myslet, že MAC adresa je v jiné VLAN, ale mezi VLAN packety nepředá. Tedy "odstřihne" od sítě oprávněného uživatele, nic víc se nestane. Nechci teď kecat, ale myslím, že lepší switche mají ARP oddělenou podle vlan, tam nehrozí ani to.

Některé switche umí zamknout port na stejnou MAC adresu - buďto úplně na pevno, nebo s karenční dobou (dalších X hodin je port uzamknutý). Tam, kde se řeší bezpečnost, se to používá. VLAN není jediným řešením bezpečnosti, je to jen jeden z nástrojů a jejich použití se řídí požadovanou úrovní bezpečnosti.
Název: Re:rozdeleni switche
Přispěvatel: František Ryšánek 16. 01. 2020, 21:40:49
„...it's possible to force a switch to re-learn a MAC address to a "wrong" port (= away from the correct port) by sending a packet with the "attacked" MAC address as a source address in the attacking frame (= MAC address spoofing), from an untagged port belonging to a different VLAN.“

Jak by to mělo fungovat? Přepínač odešle následné pakety určené pravému příjemci do VLAN útočníka? Když zavysílá pravý příjemce ze své VLAN, tabulka se opět přepíše zpět a útok končí? Co když má přepínač (jako např. Mikrotik RB260) zamykání portů k MAC?

Nenapadá mě, jak by se to dalo zneužít kromě DoS útoku - switch si bude myslet, že MAC adresa je v jiné VLAN, ale mezi VLAN packety nepředá. Tedy "odstřihne" od sítě oprávněného uživatele, nic víc se nestane. Nechci teď kecat, ale myslím, že lepší switche mají ARP oddělenou podle vlan, tam nehrozí ani to.

Některé switche umí zamknout port na stejnou MAC adresu - buďto úplně na pevno, nebo s karenční dobou (dalších X hodin je port uzamknutý). Tam, kde se řeší bezpečnost, se to používá. VLAN není jediným řešením bezpečnosti, je to jen jeden z nástrojů a jejich použití se řídí požadovanou úrovní bezpečnosti.

Přesně tak, lze to použít jenom pro DoS útok. I tohle riziko ale může někomu vadit.

A pak jsou nějaké... obskurní a staré rodiny protokolů nad Ethernetem v "průmyslu", které třeba používají tutéž MAC adresu na jakékoli síti pro nějakou well-known funkci. Potíž je, když takových sítí pustíte do VLANového switche několik paralelně. Polezou si navzájem do zelí.

Ano, některé lepší switche umí oddělené FDB per VLAN.
Název: Re:rozdeleni switche
Přispěvatel: Miroslav Šilhavý 16. 01. 2020, 21:44:52
Ano, některé lepší switche umí oddělené FDB per VLAN.

Díky za potvrzení. Právě jsem matně vzpomínal, že na Catalystech jsem někdy (většinou to byly chyby!) viděl MAC na více vlanách a marně jsem si dnes lámal hlavu, proč by měly mít switche jen jednu tabulku bez odlišení, jestli je k tomu racionální důvod (kromě zlevnění návrhu).
Název: Re:Rozdělení switche
Přispěvatel: M_D 17. 01. 2020, 07:59:26
Tak u slušnějších swichtů je to i konfigurovatelné, zda chci/nechci, aby brala FDB v potaz VLANu (tím pádem zda MAC přeskakuje mezi VLANama nebo může stejná MAC existovat současně ve víc VLANách) a případně i kolik záznamů per VLAN nebo port dovolím max využít. Obvykle nadávky SVL/IVL (shared / independend VLAN learning).
Název: Re:rozdeleni switche
Přispěvatel: František Ryšánek 17. 01. 2020, 12:05:16
Ano, některé lepší switche umí oddělené FDB per VLAN.

Díky za potvrzení. Právě jsem matně vzpomínal, že na Catalystech jsem někdy (většinou to byly chyby!) viděl MAC na více vlanách a marně jsem si dnes lámal hlavu, proč by měly mít switche jen jednu tabulku bez odlišení, jestli je k tomu racionální důvod (kromě zlevnění návrhu).

Podle mého je to prostě výsledek postupného inkrementárního vývoje. Když se do switchových čipsetů přidávaly VLANy, tak na mechanismy fungování FDB vlastně nebylo třeba šáhnout (učení adres a následně procházení tabulky při forwardovacích rozhodnutích), jenom se přidal nějaký filtr podle VLAN ID a logika přidat/odstranit značku (per port). Per-VLAN FDB znamená, že je třeba FDB rozšířit o další pole (Vlan ID) a "třídící klíč" tím o pár bitů narostl... Ani nevím, jestli je sdílená FDB stanovena jako součást 802.1Q. On s tím tuším taky dál souvisí třeba Spanning Tree Protocol. Ten taky standardně nejede "per VLAN", ale globálně (untagged i na trunku?) Jak moc volně/těsně souvisí per-VLAN STP a FDB, to teď z hlavy nedám...
Název: Re:rozdeleni switche
Přispěvatel: Miroslav Šilhavý 17. 01. 2020, 12:11:07
...

Mám v tomto omezené zkušenosti, ale co znám Cisco Catalysty od C2950 (rok 2008), tak měly v ARP tabulce jak field pro VLAN, tak možnost nastavit PVST (Per-VLAN-Spanning-Tree).

Takže nějaký postupný vývoj mi do toho nesedí, spíš bych to tipoval na šlendrián zoufalých výrobců, aby nějak-rychle-levně uměli implementovat 802.1Q a nedoimplementovali spoustu dalších potřebných mechanismů. Když se tak zamyslím, tak všude u sebe a u klientů mám Catalysty, nebo nepoužívám VLANY. Takže zkušenost s ostatními mám nulovou.
Název: Re:Rozdělení switche
Přispěvatel: luvar 17. 01. 2020, 21:13:06
Vidim tu odbornu diskusiu a neda mi nespytat sa. Co v pripade, ze sa jedna o domacu automatizaciu (sitara https://www.ti.com/lit/an/sprac97/sprac97.pdf (https://www.ti.com/lit/an/sprac97/sprac97.pdf), CMUSphinx - https://cmusphinx.github.io/ (https://cmusphinx.github.io/), videovratnik a ine somarinky vratane sialenosti ako je arduino a ethernet shield :), ktoru by som mal rad "offline" a nepusta ju na Internet? Ma zmysel v takomto pripade mat dva fyzicke switche? Jeden pre domcu automatizaciu a druhy pre pocitace, notebooky, wifi routre a nejaky ten Internet?

Vyhody:

Nevyhody:

Su tam nejake ine nevyhody, alebo dovody na pouzitie vlan-ov?
Název: Re:Rozdělení switche
Přispěvatel: Miroslav Šilhavý 17. 01. 2020, 21:23:15
Přesně na toto se používají vlan. Koupíte jen lepší switch namísto dvou horších. V rozvaděči pak máte patch panel, organizér a switch. Změny přiřazení děláte konfigurací, ne překolíkováváním drátů.

Dokonce se často dělá i toto:

port 1 - inernetová přípojka (VLAN 10)
port 2-10 - LAN (VLAN 20)
port 11-15 - interní zařízení (VLAN 30)
port 16 router a v něm 802.1q trunk (povolené VLAN 10, 20 a 30)

Do routeru Vám pak vede jen jeden kabel a po něm běží provoz do všech tří VLAN a do nich to rozhodí switch.
Proto profesionální routery mívají 2-3 porty a ne víc, protože zbytek se rozhodí na switchi. Nebývá vůbec výjimkou mít router připojený jen jedním kabelem.

Když potřebujete dostat "ostrý" internet do nějakého zařízení (třeba jen dočasně), překonfigurujete mu port do VLAN 10 a ejhle, už to běží. Potřebujete dostat internet do interních zařízení? Stejný postup.

Na zapojení bez VLAN a třeba přes dva switche taky není nic špatného, ale je to méně pohodlné.

Z hlediska bezpečnosti je to naprosto totožné, vlan jsou mechanismus na L2, zatímco směrování internetu je L3.
Název: Re:Rozdělení switche
Přispěvatel: Petr M 19. 01. 2020, 12:38:14
Tak doma mám právě kvůli oddělení sítí GS-1900 a jeden fous do routeru. No a pomocí VLAN je to rozstřeleno aktuálně na tři sítě.
- Tagovaná část - switch-router, pracova-router a APčka (kvůli několika SSID).
- Klasická LAN s PC
- "Dirty" LAN s IPTV, mobilama, TV,... - co chce net a nevěřím tomu z pohledu bezpečnosti
- Síť bez internetu - tiskárna, NAS, případně IoT srandy a tak

A je to fakt jednoduchý na nastavení - GS1900 jede ve factory defaultut interně na VLAN1 a všechny porty jsou untagged. Jenom stačilo vytvořit další LANky, na uplinku zapnout všechny VLAN na jeden port jako Tagged, na downlinku vybrat jednu z nich a poslat jako untagged. Jde to v klidu naklikat v jejich webovým rozhraní, je to jenom jedna taková tabulka.

Resim jeden projekt ... chci aby port 1-9 byl pro tu firmu (1port jejich router a zbyle porty 2-9 jejich datove zasuvky)

Jo takhle, pán je expert. Na vytváření SPOF. Jeden vyhořelý brouk, pět firem bez konektivity. A jeden společný firewall/router je tam taky, aby to hackeři měli jednodušší a virus se mohl z jedné firmy bez překážek šířit do druhé?

Když pak dostane přístup k managementu switche jedna firma, klidně vytuneluje data z jiné... To samý, když se uklikneš a uteče jim nějaký know-how.

Boha, managovaný 16p 1G switch začíná na ceně za plnou nádrž LandRoveru majitele takové firmičky, takový šetření je pěkně na ... A vzhledem  k tomu, že mgmt neumíš používat, jsi s odděleným switchem na ceně plné nádrže u mopedu.
Název: Re:Rozdělení switche
Přispěvatel: Miroslav Šilhavý 20. 01. 2020, 19:37:30
Spolehlivost se opravdu netvoří tím, že si nasázíte mnoho switchů a mnoho routerů. Naopak "profesionální" klasikou je pořídit jeden router a jeden switch, které za něco stojí. Stejně tak bezpečnost, řeší se jednoduchými, ale funkčními nastaveními.

Pokud jde o spolehlivost prvků proti havárii, řeší se to zapojením do zdvojení. Přívod do dvou switchů, ty propojeny do kříže, z každého switche do kříže do dvou routerů. To už je komplikovanější nastavení. Díky tomu dvěma switchi a dvěma routery eliminujete SPOF pro větší počet přípojek (firem), než dvě.

Pokud jeden switch a jeden router pro pět firem nahradíte pěti routery a pěti switchi, spolehlivost nezvýšíte. Dopad bude menší (chcípne jen jedna firma), ale četnost incidentů úměrně násobná. Výslednice = 0.

Bezpečnost se řeší primitivně. Nemít na routeru otevřené nic, co není potřeba (na router nepatří DNS a podobné chujoviny), management přes SSH a ověření klíčem. Jste-li víc paranoidní, dají se routery i switche konfigurovat přes RS232 a síťový management mít zakázaný. Nic nového pod sluncem.
Název: Re:Rozdělení switche
Přispěvatel: FKoudelka 20. 01. 2020, 22:27:16
Vidim tu odbornu diskusiu a neda mi nespytat sa. Co v pripade, ze sa jedna o domacu automatizaciu (sitara https://www.ti.com/lit/an/sprac97/sprac97.pdf (https://www.ti.com/lit/an/sprac97/sprac97.pdf), CMUSphinx - https://cmusphinx.github.io/ (https://cmusphinx.github.io/), videovratnik a ine somarinky vratane sialenosti ako je arduino a ethernet shield :), ktoru by som mal rad "offline" a nepusta ju na Internet? Ma zmysel v takomto pripade mat dva fyzicke switche? Jeden pre domcu automatizaciu a druhy pre pocitace, notebooky, wifi routre a nejaky ten Internet?

Vyhody:
  • zvladnem to aj ja, bez studoania aky hw kupit a ako ho nastavit a urcite to bude oddelene :)
  • ten switch na home automation moze byt o level lacnejsi/horsi. Tam nebudem vyzadovat gigabitove porty pravdepodobne a urcite nie viac ako gigabitove, ak nahodou.

Nevyhody:
  • dva switche (velka plechova skatulka s malym plosacikom dnuka)
  • viac obsadenych zasuviek

Su tam nejake ine nevyhody, alebo dovody na pouzitie vlan-ov?
IMHO, na doma dobrý, pokud neni cas a chut to studovat a platit za managovatelny  switch.
Jediné co ztratíš, je flexibilita.
Mmch “skatulka s malym plosacikom dnuka”,  to je kouzelný :-)

Název: Re:Rozdělení switche
Přispěvatel: FKoudelka 20. 01. 2020, 22:39:04

IMHO, na doma dobrý, pokud neni cas a chut to studovat a platit za managovatelny  switch.
Jediné co ztratíš, je flexibilita.
Mmch “skatulka s malym plosacikom dnuka”,  to je kouzelný :-)
Pofederační synek to přeložil jako “krabička s malým plochým dnem“. :-)
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: František Ryšánek 22. 01. 2020, 16:52:31
Odpusťte malý přílepek. Náhodou jsem narazil na cosi "pro mě nového" k VLANám a vzpomněl jsem si na tohle nedávné téma (které už stejně mezitím trochu převálcovalo původní dotaz, takže se snad nic nestane, když přidám ještě toto).

Všiml jsem si na taiwanských průmyslových switchích různých značek fičury zvané "private VLAN" - v průběhu posledních let několikrát, ale nevěnoval jsem tomu pozornost, považoval jsem to za čínskou inovaci. Ale když jsem potkal třetí značku, která to má ve firmwaru, začal jsem "větřit změnu počasí". Taiwanci to nemívají nikde v kostce popsáno "v koncepční rovině" - a jednotlivá konfigurační okýnka mívají v návodu popis cca "toto je konfigurační okýnko". No a usvědčil jsem se z neznalosti - ono to zřejmě přišlo původně od Cisca. Už před 10 lety o tom psal Petr Bouška na Samurajovi (https://www.samuraj-cz.com/clanek/cisco-ios-19-private-vlan-a-protected-port/). V trochu sušším podání se lze něco dočíst na Wikipedii (https://en.wikipedia.org/wiki/Private_VLAN).

O co jde? Dá se tím detailněji regulovat "viditelnost" mezi porty v rámci VLANy navzájem. Dá se nastavit jeden port (obvykle L3 default gateway) jako "promiskuitní" (dá všem), a klientské porty jako "navzájem izolované". Nebo lze nastavit i klientské porty jako "komunitní" = smí se bavit mezi sebou navzájem. Na Ciscu je to tak, že v rámci konkrétní rodičovské VLANy se dají vykolíkovat menší podmnožiny / sub-VLANy, a v každé z nich se dá říct, jestli mají být porty v jejím rámci "izolované", nebo "komunitní". Přitom se všechny smí bavit s týmiž "promiskuitními" porty v rámci VLANy a klidně sdílejí L3 subnet. Číňani to zřejmě mají implementováno o něco jednodušeji / v detailech jinak, ale pozoruju tam podobné konfigurační opšny. Prostě doteď jsem žil v představě, jak jsou VLANy jednoduchá a přehledná záležitost, včetně třeba Q-in-Q, a teď jsem poznal jeden stinný kout, kde... Sodoma Gomora. Ono se tím zřejmě dá např. stáhnout i L3 provoz v rámci L2 segmentu tak, aby tekl skrz default gateway, kde se dá na L3 ofiltrovat (je potřeba tomu trochu pomoct proxy ARPem).

Zatím jsem si na to nesáhl rukama a není mi jasné, co to má za dopad třeba na funkce založené na L2 broadcastu (jiné než kde broadcastuje default GW). Může to být asi dost mazec.
Na první pohled mám pocit, že o toto by se měl starat někdo, kdo ví co dělá a dokáže dost podrobně ladit případné konfigurační přehmaty/nedomyšlenosti. Nic pro čarodějova učně, který zrovna zvládnul základní bezelstné VLANy.
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: Miroslav Šilhavý 22. 01. 2020, 17:12:54
Zrovna dneska jsem v práci něco rekonfiguroval a narazil jsem na to na C3650 a připomnělo se mi to taky. Nikdy jsem to ale nepoužíval.

Ono se tím zřejmě dá např. stáhnout i L3 provoz v rámci L2 segmentu tak, aby tekl skrz default gateway, kde se dá na L3 ofiltrovat (je potřeba tomu trochu pomoct proxy ARPem).

Nechápu..?

Zatím jsem si na to nesáhl rukama a není mi jasné, co to má za dopad třeba na funkce založené na L2 broadcastu (jiné než kde broadcastuje default GW). Může to být asi dost mazec.

Nemám vyzkoušeno, ale mělo by to fungovat tak, že broadcasty z promiscuous uslyší všichni. Broadcasty z community uslyší všichni v rámci komunity + všichni promiscuous. Broadcasty z private uslyší jen promiscuous porty.

Na některých switchích jsem viděl ještě horší věc: port, který je v access režimu a zároveň ve více VLAN. To teprve musí být bordel a bezpečnost vniveči.
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: František Ryšánek 22. 01. 2020, 20:54:23
Ono se tím zřejmě dá např. stáhnout i L3 provoz v rámci L2 segmentu tak, aby tekl skrz default gateway, kde se dá na L3 ofiltrovat (je potřeba tomu trochu pomoct proxy ARPem).

Nechápu..?
[...]
Nemám vyzkoušeno, ale mělo by to fungovat tak, že broadcasty z promiscuous uslyší všichni. Broadcasty z community uslyší všichni v rámci komunity + všichni promiscuous. Broadcasty z private uslyší jen promiscuous porty.

Takže si představte "primární" VLAN ošetřenou pomocí jediné PVLAN v režimu "isolated", na ní několik klientů a jedna gateway v režimu "promiscuous". Mezi klienty v rámci subnetu chcete navzájem na L3 omezeně komunikovat, ale nechcete, aby se viděli přímo na L2. Takže jim "isolated" režimem zabráníte, aby o sobě na L2 navzájem jakkoli napřímo věděli. Pokud takto izolovaný klient pošle ARP "who has", bez dalšího ošetření by se mu nikdo neozval. Proto je údajně možnost, na gatewayi rozjet "proxy arp", tipuju automatický pro celý subnet. Prostě když se izolovaný klient zeptá ARPem na libovolnou adresu, ozve se mu (ARP "is at") bez rozmýšlení gateway: "já gateway mám tuhle adresu". A klient pošle svůj dotaz "sousedově IP adrese" na MAC adresu gatewaye. Gateway ten paket přijme, na třetí vrstvě prohlédne, zjistí že ho má poslat zpátky do rozhraní, ze kterého paket přišel, ale s tím se počítá - pokud paket vyhoví pravidlům, odešle ho zpátky tímtéž rozhraním, ovšem jinému izolovanému klientovi... A aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Na některých switchích jsem viděl ještě horší věc: port, který je v access režimu a zároveň ve více VLAN. To teprve musí být bordel a bezpečnost vniveči.
Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: Miroslav Šilhavý 22. 01. 2020, 21:16:16
Takže si představte "primární" ... aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Rozumím. A co je v tom za problém?

Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.

Já si myslím, že port nastavený do dvou VLAN to pošle do obou. ARP mu odpoví (snad) jen z jedné. Ale účel toho fakt nechápu.
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: František Ryšánek 22. 01. 2020, 21:48:09
Takže si představte "primární" ... aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Rozumím. A co je v tom za problém?

...tak... já jsem asi neměl v úmyslu, dělat z toho tragédii :-) ale děkuji za nahrávku ;-)

Jistě uznáte, že je to uspořádání dost nezvyklé. Obecně proxy ARP je taková berlička, historicky pro zařízení s dementním IP stackem, kterému nešlo nastavit default route (nepočítal s provozem mimo lokální subnet). Tradičně se o tom tvrdilo, že je to nečistá věc, narušuje normální života běh, zvyšuje zátěž na routeru, přidělává správci bolení hlavy a po nocích žere osamělá malá koťátka.

Zas pokud "promiskuitní" gateway odpovídá na *všecky* ARPy "jasně, to jsem já", tak s tím asi moc práce navíc nemá, protože prohledávat nějaký seznam nemusí. ARP tabulka se seznamem klientů v LAN funguje v gatewayi zřejmě normálně. Čili zbývá případná námitka, že protáhnout všechen provoz v LAN segmentu skrz gateway a zase zpátky je mrháním kapacitou LAN a výkonem gatewaye, ale v principu... pokud tohle nakonfigurujeme, tak přeci přesně tohle jsme chtěli, žejo?

Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.

Já si myslím, že port nastavený do dvou VLAN to pošle do obou. ARP mu odpoví (snad) jen z jedné. Ale účel toho fakt nechápu.

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Jinak ono i na tagovaném (trunkovém) portu reálně žije dost netagovaného provozu - především všelijaké režijní protokoly. Třeba STP nebo všelijaké průmyslové protokoly pro kruhovou redundanci jedou nad LLC, což je "režijní subvrstva" v rámci L2, enkapsulovaná v rámcích 802.2/802.3 - kdežto užitečná TCP/IP data jedou v enkapsulaci "Ethernet II" (a těch se týká tagování/trunkování). Ono lze na VLANu nahlížet buď jako na "rouru pro payload", nebo jako bezbranný atribut v hlavičce paketu. A co jsem viděl, jak se switche chovají třeba k IEEE1588=PTP, tam je VLAN tag taky spíš jako atribut, než jako roura. Případně může jet PTP mezi switchi netagovaně, smícháno s tagovanými rámci ostatního payloadu...
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: Miroslav Šilhavý 22. 01. 2020, 21:54:53
Já pořád nějak nechápu, proč bych měl v PVLAN dělat proxy ARP, k čemu by mi to bylo?

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Podle mě by neposílal dva packety. Představte si switch, který má jednu ARP pro všechny VLAN společnou. Potřebujete odeslat packet a zeptáte se Who Has IP a povolíte to proswištět do všech portů v obou VLAN. Odpoví však jen jeden konkrétní. Získáte MAC a pak už switch ví, kam další (L3) provoz posílat. VLAN fungují na mnoha switchích "jen" jako filtr, které porty vynechat při přepínání.
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: František Ryšánek 22. 01. 2020, 23:04:45
Já pořád nějak nechápu, proč bych měl v PVLAN dělat proxy ARP, k čemu by mi to bylo?
No v technické rovině, pokud chcete aby na sebe "izolované" porty v rámci PVLAN navzájem neviděly, tak halt se nebudou vidět ani pro potřeby ARPu. Napřímo neproleze ani ARP request, ani ARP response. Proto jim bude promiskuitní default gateway dělat prostředníka ("proxy") i v tom ARPu. Potažmo skrz gateway pak poteče i všechen užitečný provoz.

A pokud se ptáte "ale k čemu to všechno", jako že konkrétní use-case / scénář... to je taky dobrá otázka. Třeba chceme šetřit adresním prostorem, proto všichni účastníci v jednom subnetu, ale zároveň nechceme, aby se navzájem ohrožovali, a jenom dost vyjímečně mají potřebu a nárok, bavit se navzájem zcela konkrétním a dobře filtrovatelným protokolem - a v tom případě je chceme nějak filtrovat routerem/firewallem (nad rámec toho, co zvládnou dnešní switche v hardwaru i "napřímo", a že toho zvládnou poměrně dost). Aneb dosaďte si své vlastní paranoidní zadání :-)

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Podle mě by neposílal dva packety. Představte si switch, který má jednu ARP pro všechny VLAN společnou. Potřebujete odeslat packet a zeptáte se Who Has IP a povolíte to proswištět do všech portů v obou VLAN. Odpoví však jen jeden konkrétní. Získáte MAC a pak už switch ví, kam další (L3) provoz posílat. VLAN fungují na mnoha switchích "jen" jako filtr, které porty vynechat při přepínání.

A tak to potom jo, takhle tomu rozumím.
Tzn. v rámci switche se nerozhoduje podle VLAN tagu, ale podle ingressového portu a sady filtrů.
Tzn. dilemma nastane ve chvíli, kdy je případně třeba paket označkovat = na egressu do nějakého trunku, který nese obě VLANy.
BTW nepleťte si prosím ARP tabulku (L3) s FDB=CAM tabulkou (L2) - ale kromě toho jednoho slůvka se zbytkem souhlasím, včetně toho jak ARP request už si svého adresáta najde, a pak se naučí MAC adresa tázaného stroje na konkrétním portu (objeví se v CAM tabulce) - toto napříč dvěma VLANami (implementováno filtrem).
Název: Re:Rozdělení switche - dodatek ohledně private VLAN...
Přispěvatel: Miroslav Šilhavý 22. 01. 2020, 23:10:45
A pokud se ptáte "ale k čemu to všechno", jako že konkrétní use-case / scénář... to je taky dobrá otázka. Třeba chceme šetřit adresním prostorem, proto všichni účastníci v jednom subnetu, ale zároveň nechceme, aby se navzájem ohrožovali, a jenom dost vyjímečně mají potřebu a nárok, bavit se navzájem zcela konkrétním a dobře filtrovatelným protokolem - a v tom případě je chceme nějak filtrovat routerem/firewallem (nad rámec toho, co zvládnou dnešní switche v hardwaru i "napřímo", a že toho zvládnou poměrně dost). Aneb dosaďte si své vlastní paranoidní zadání :-)

Jo takhle to myslíte. No asi jediné rozumné řešení je L3 switch a filtrovat to na IP. Druhé řešení, pokud nemáte L3 switch, je onen jeden port dát do extra VLAN a na routeru udělat bridge s filtrováním (což je de facto rozkouskovaný L3 switch :). Mrcasit se s proxy arp mi přijde šílené (zatím se mi vždy podařilo téhle šílenosti vyhnout, ale vlan+bridge+vlan už jsem řešil).

BTW nepleťte si prosím ARP tabulku (L3) s FDB=CAM tabulkou (L2)

Díky :).