Klopt deze config met switches?

[Vuilnisauto]

Naar aanleiding van een post van mij waarbij ik op zoek ben naar een oplossing voor 2 signalen uit mijn router (IPTV en Internet) en maar 1 ethernetkabel naar de woonkamer.: https://gathering.tweaker...message/55955613#55955613 en aan de hand van dit stappenplan: https://gathering.tweaker...message/52734711#52734711
heb ik onderstaand schemaatje voor mezelf gemaakt.
Omdat VLANs en Switches een totaal nieuwe wereld voor me zijn was ik benieuwd of ik mijn interpretatie van het stappenplan goed heb toegepast?

De Draytek router heeft op port 1 en 2 internet en op port 3 en 4 IPTV.

Vanaf de Draytek Vigor 2132 router Port 1 een ethernetkabeltje naar port 1 van een Netgear GS105E switch, die ik VLAN1-untagged maak en vanaf port 4 van de router een ethernetkabeltje naar port 2 van de switch die ik VLAN640-untagged maak.
Port 3 op de switch maak ik VLAN1 & VLAN640 tagged.
Vanaf port 3 op de Netgear GS105E loopt een ethernetkabel naar port 1 van een Netgear GS108E switch, die ik ook weer VLAN1 & VLAN640 tagged maak.
Port 2 maak ik VLAN1-untagged, port 3 VLAN640-untagged, port 4 t/m 7 VLAN1-untagged

[CyBeR]

Klinkt goed.

[Yordi-]

Let wel op dat VLAN1 eigenlijk niet het beste VLAN is om productie (ha, thuisnetwerk.. "productie") te taggen op een trunk. Ik ken het Netgear platform niet, maar VLAN1 is vaak het native (untagged) vlan dat ook (default) wordt gebruikt voor management en control doeleinden. Vroeger was het zo dat dit VLAN ook niet te taggen was op een trunk. Beter is beginnen met 2,3, of nog beter, 10,20,...

[CyBeR]

Dat is imo een nogal achterhaald concept, wat er van uitgaat dat je op end-user beschikbare poorten (dwz, wcd's) meerdere vlans hebt zitten. Belangrijker dit gaat om bedrijfsnetwerken, voor thuis maak je 't alleen maar moeilijker als je default vlan niet gewoon vlan 1 is imo.

[Verwijderd]

Ik gebruik VLAN 1 als doodlopende straat (anti hopping, switch local). VLAN 2 voor lokaal mgmt (poort 1 op grotere switches). VLAN 3 is voor remote mgmt (bereikbaar via trunks / SFP).

Ik ben het met @CyBeR eens. 1 untagged VLAN per WCD. Dan voorkom je o.a. VLAN hopping op client niveau (never trust your users/clients).

[Geim]

Zo heb ik het ook een tijdje gehad bij Solcon fiber, tv kijken was geen probleem, maar uitzendig gemist wilde nog wel eens stoppen. Uitendelijk maar een 2e netwerk kabel getrokken.
Tegenwoordig bij xs4all fiber en daar gaat alles over hetzelfde lan.

[Vuilnisauto]

Yordi- schreef op zondag 29 juli 2018 @ 10:49:
Let wel op dat VLAN1 eigenlijk niet het beste VLAN is om productie (ha, thuisnetwerk.. "productie") te taggen op een trunk. Ik ken het Netgear platform niet, maar VLAN1 is vaak het native (untagged) vlan dat ook (default) wordt gebruikt voor management en control doeleinden. Vroeger was het zo dat dit VLAN ook niet te taggen was op een trunk. Beter is beginnen met 2,3, of nog beter, 10,20,...

Dus VLAN1 kan ik beter bijv VLAN10 noemen?

[Vuilnisauto]

Ik interpreteer van verschillende plekken dat dat de poorten die beide switches verbinden trunks moeten zijn en dat de poorten die van de eerste switch verbonden zijn met de router ook trunks moeten zijn, heb ik dat goed begrepen?
Zoals hier: https://www.computernetwo...lained-with-examples.html

[Vuilnisauto]

Verwijderd schreef op zondag 29 juli 2018 @ 15:03:
Ik gebruik VLAN 1 als doodlopende straat (anti hopping, switch local).
Ik ben het met @CyBeR eens. 1 untagged VLAN per WCD. Dan voorkom je o.a. VLAN hopping op client niveau (never trust your users/clients).

Gelukkig is het enkel voor thuisgebruik en heb ik niet t emaken met clients of onbetrouwbare users..

[DukeBox]

Ik zou vlan1 gewoon overal untagged houden. Ook tussen de 2 switches in.

[Verwijderd]

Vuilnisauto schreef op zondag 29 juli 2018 @ 17:16:
Gelukkig is het enkel voor thuisgebruik en heb ik niet t emaken met clients of onbetrouwbare users..

Je hebt wel te maken met virussen en andere crap die je netwerk kan aanvallen. Wat is vertrouwen in een netwerk?

[Vuilnisauto]

Verwijderd schreef op zondag 29 juli 2018 @ 17:28:
[...]

Je hebt wel te maken met virussen en andere crap die je netwerk kan aanvallen. Wat is vertrouwen in een netwerk?

Sterk punt!

[DukeBox]

Verwijderd schreef op zondag 29 juli 2018 @ 17:28:
Je hebt wel te maken met virussen en andere crap die je netwerk kan aanvallen.

Dan nog, VLANS zijn bedoeld voor (eenvoudig) beheer, niet als security oplossing (ondanks dat het vooralsnog veilig is gebleken).

[Verwijderd]

DukeBox schreef op zondag 29 juli 2018 @ 18:32:
Dan nog, VLANS zijn bedoeld voor (eenvoudig) beheer, niet als security oplossing (ondanks dat het vooralsnog veilig is gebleken).

En dat baseer je op (RFC)? Het heeft i.m.h.o niets met beheer te maken (behalve het beheer VLAN of dedicated beheer poort).

VLAN's zijn bedoeld om traffic te scheiden (verschillende broadcast domains), wat gebruikt kan worden als security. Hoe zie jij een i-port / p-port (PVLAN)? Dat is een leuke layer 2 feature.
Camera's behoren niet met elkaar te praten (i-port). Er is ergens een device die de streams van camera's request (allowed by firewall). Zelfde geld voor printers, voip, etc.

De firewall policy staat natuurlijk op 'default deny' (of het nou een externe firewall is, of layer3 switch met firewall), waardoor er geen traffic plaatsvind tussen de verschillende (broadcast) domains.

[Pietervs]

Het feit dat verkeer gescheiden wordt door vlans en netwerken daardoor veiliger worden is een fijne bijkomstigheid van vlans. Maar primair zijn vlans m.i. in het leven geroepen om verkeer te scheiden om op die manier netwerken beter beheersbaar te maken.

[Verwijderd]

Pietervs schreef op maandag 30 juli 2018 @ 00:39:
Maar primair zijn vlans m.i. in het leven geroepen om verkeer te scheiden om op die manier netwerken beter beheersbaar te maken.

"Beheersbaar" is zwaar relatief. En vooral geen Cisco pagina's refereren. Maargoed, om die pagina even te quoten:

A VLAN is a group of end stations in a switched network that is logically segmented by function or application, without regard to the physical locations of the users.

Dit klinkt aardig als "security". En wat is 802.1X? Dat is een ACL/NAC t.b.h.v. security, met VLAN's.

RFC3069:
It may also ease administration of IPv4 addresses within the network.

Daar komt de "beheersbaarheid" t.b.h.v. VLAN's vandaan waar Cisco het over heeft.

RFC5517:
This document describes a mechanism to achieve device isolation
....
In an Ethernet switch, a VLAN is a broadcast domain in which hosts
can establish direct communication with one another at Layer 2. If
untrusted devices are introduced into a VLAN, security issues may
arise because trusted and untrusted devices end up sharing the same
broadcast domain.

Ik kan nog wel een tijd doorgaan met RFC's quoten, heb ze bijna allemaal gelezen.
Er is nog steeds geen RFC die zegt dat VLAN's niet voor security bedoeld zijn, eerder het tegenovergestelde.

In the end I'll win! That's my job!

[Brahiewahiewa]

Verwijderd schreef op maandag 30 juli 2018 @ 01:49:
[...]
Dit klinkt aardig als "security". En wat is 802.1X? Dat is een ACL/NAC t.b.h.v. security, met VLAN's.

Je kletst uit je nek. 802.1x is een security mechanisme voor VLAN's omdat VLAN's uit zichzelf niet secure zijn

[Verwijderd]

Brahiewahiewa schreef op maandag 30 juli 2018 @ 05:51:
[...]

Je kletst uit je nek.

Ok, einde discussie.

802.1x is een security mechanisme voor VLAN's omdat VLAN's uit zichzelf niet secure zijn

802.1x is een protocol met nogal veel flaws. Het wordt er niet echt veel veiliger op.
VLAN's op zich zijn secure.

[Pietervs]

Verwijderd schreef op maandag 30 juli 2018 @ 01:49:
[...]

"Beheersbaar" is zwaar relatief. En vooral geen Cisco pagina's refereren. Maargoed, om die pagina even te quoten:

Ok, je hebt een aversie tegen Cisco. Dat kan.
Maar zoals je zelf vervolgens constateert publiceren ze dus geen onzin.

Dit klinkt aardig als "security". En wat is 802.1X? Dat is een ACL/NAC t.b.h.v. security, met VLAN's.

Ik zeg niet dat VLANs niet gebruikt kunnen of mogen worden voor beveiliging. Ik zeg dat ze daar niet primair voor in het leven zijn geroepen.

Ik kan nog wel een tijd doorgaan met RFC's quoten, heb ze bijna allemaal gelezen.
Er is nog steeds geen RFC die zegt dat VLAN's niet voor security bedoeld zijn, eerder het tegenovergestelde.

In the end I'll win! That's my job!

Fijn, ieder zijn hobby.
Maar "winnen en verliezen"? Dat maakt je per definitie een verliezer: ik lees niet mee of reageer niet om te winnen of verliezen, ik doe dat uit belangstelling, in de hoop iemand te helpen en er zelf ook wat van op te steken.

Fijne avond.

[Verwijderd]

Pietervs schreef op maandag 30 juli 2018 @ 22:50:
Ok, je hebt een aversie tegen Cisco. Dat kan.

Nee, ik prefereer RFC's. Omdat die duidelijker zijn.

Maar zoals je zelf vervolgens constateert publiceren ze dus geen onzin.

Het is hoe je de tekst wil lezen. Ik zie "is logically segmented by function or application" als een security feature.
Al staat het woord er niet exact, er zijn wel meer systemen/talen waar niet alles security heet, maar het wel zo gebruikt wordt. In de security wereld wordt segmentation veel gebruikt.

Als ik naar Network segmentation kijk (op wikipedia), dan staat daar in de 1e paragraaf: Advantages of such splitting are primarily for boosting performance and improving security.

En PVLAN's zijn zeker bedoeld voor security. De titel van het document is: Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment

Maar "winnen en verliezen"?

Ik sta bekend als "RFC warrior". Niet alles te serieus nemen!

[ Voor 82% gewijzigd door Verwijderd op 30-07-2018 23:40 ]

[Pietervs]

Verwijderd schreef op maandag 30 juli 2018 @ 23:23:

Nee, ik prefereer RFC's. Omdat die duidelijker zijn.

Het is hoe je de tekst wil lezen. Ik zie "is logically segmented by function or application" als een security feature.
Al staat het woord er niet exact, er zijn wel meer systemen/talen waar niet alles security heet, maar het wel zo gebruikt wordt. In de security wereld wordt segmentation veel gebruikt.

Dat druist wel in tegen de eerder door jou gewenste duidelijkheid: je ziet iets, dat is een aanname, een interpretatie. Overigens wel een aannemelijke hoor.

Als ik naar Network segmentation kijk (op wikipedia), dan staat daar in de 1e paragraaf: Advantages of such splitting are primarily for boosting performance and improving security.

Kijk, dat is interessant! Maar wel wikipedia, en geen RFC. En geen woord over vlans, alleen over netwerk segmentatie. Daar zijn meerdere manieren voor, niet alleen vlans! Hoewel vlans natuurlijk de makkelijkste zijn.

En PVLAN's zijn zeker bedoeld voor security. De titel van het document is: Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment

Waarmee Cisco beschrijft hoe ze een onderdeel van vlans inrichten voor beveiliging. Die inrichting noemen ze Private Vlans. Dat is dus zeker geen algemeen verhaal m.b.t. vlans! Ik betwijfel of deze feature als zodanig wel bestaat bij de concullega's van Cisco (zoals Juniper of Huawai), maar helaas heb ik daar geen ervaring mee.

[Verwijderd]

Pietervs schreef op dinsdag 31 juli 2018 @ 14:57:
Dat druist wel in tegen de eerder door jou gewenste duidelijkheid: je ziet iets, dat is een aanname, een interpretatie. Overigens wel een aannemelijke hoor.

Er zijn wel wat meer documenten dan alleen RFC's. Bijvoorbeeld de regenboog serie.
^{Een deel van de regenboog is gepubliceerd (kuch, gelekt) tijdens de koude oorlog.}

Het is alweer een paar jaar geleden dat ik die gelezen heb. Ik heb een mooi ingebonden boek met de meest belangrijke kleuren (bij een ex-werkgever geprint met een volautomatische printer/inbinder).

Kijk, dat is interessant! Maar wel wikipedia, en geen RFC. En geen woord over vlans, alleen over netwerk segmentatie. Daar zijn meerdere manieren voor, niet alleen vlans! Hoewel vlans natuurlijk de makkelijkste zijn.

Je kan ook tig fysieke switches plaatsen per gesegmenteerd netwerk, maar dat is wat zonde van de resources (behalve bij staats-/bedrijfs-geheime netwerken). RFC's lezen best duidelijk. Segmentation (of zoneing) is altijd een security feature geweest (in de 60's/70's, of misschien zelfs verder terug. ook fysieke zoneing).

offtopic:
De telecom wereld had lang geen segmentation. DTMF control tones als inband signaling (i.p.v. outband).

Wat voor andere manieren had jij in gedachten?

Waarmee Cisco beschrijft hoe ze een onderdeel van vlans inrichten voor beveiliging. Die inrichting noemen ze Private Vlans. Dat is dus zeker geen algemeen verhaal m.b.t. vlans! Ik betwijfel of deze feature als zodanig wel bestaat bij de concullega's van Cisco (zoals Juniper of Huawai), maar helaas heb ik daar geen ervaring mee.

PVLAN's worden door de meeste grote vendors ondersteund (Juniper, Huawei (MUX VLAN), Extreme Networks, etc), omdat het een veelgebruikte techniek is. Cisco heeft niet voor niets een RFC geschreven/gepubliceerd, zodat meerdere partijen in de internet community het kunnen implementeren.

[ Voor 6% gewijzigd door Verwijderd op 31-07-2018 19:19 . Reden: typo's, verbeterde zinnen, etc. en een smilie toegevoegd ]

[Yordi-]

Vuilnisauto schreef op zondag 29 juli 2018 @ 17:15:
Ik interpreteer van verschillende plekken dat dat de poorten die beide switches verbinden trunks moeten zijn en dat de poorten die van de eerste switch verbonden zijn met de router ook trunks moeten zijn, heb ik dat goed begrepen?
Zoals hier: https://www.computernetwo...lained-with-examples.html

Ja. Dat betekent wel dat je router dit moet ondersteunen. Met een trunk tag je verkeer en kun je onderscheidt maken tussen verkeer in ieder vlan.

Het beste is inderdaad VLAN1 untagged (en native op trunks) houden en voor je VLANs VLAN10,11,12 of VLAN10,20,30,... aan te houden.

De discussie die verder ontstaat ga ik maar niet op in, ik wil alleen even melden dat...

Brahiewahiewa schreef op maandag 30 juli 2018 @ 05:51:
[...]

Je kletst uit je nek. 802.1x is een security mechanisme voor VLAN's omdat VLAN's uit zichzelf niet secure zijn

niet klopt. Dot1x heeft niets met VLANs (of VLAN security) te maken behalve dat je vlans dynamisch kan toewijzen door middel van dot1x. .1x is een port security methodiek. Maar dit lijkt me al behoorlijk off-topic.

[Pietervs]

Verwijderd schreef op dinsdag 31 juli 2018 @ 16:43:
[...]


Wat voor andere manieren had jij in gedachten?

Oh, vooral fysieke scheidingen. Of indelingen met behulp van routers.

En inderdaad, vaak is dat niet de meest efficiënte of kostentechnisch beste oplossing. Maar soms is het wel beter, bijvoorbeeld met het oog op afsplitsing van een bedrijfsonderdeel: als de afsplitsing een feit is hoeven allee de betrokken switches waar men aan verbonden is ingepakt te worden en mee het pand uit te verhuizen

[Verwijderd]

Pietervs schreef op dinsdag 31 juli 2018 @ 21:37:
Oh, vooral fysieke scheidingen. Of indelingen met behulp van routers.

Zeker! Maar dat is niet altijd/overal nodig.

Als de afsplitsing een feit is hoeven allee de betrokken switches waar men aan verbonden is ingepakt te worden en mee het pand uit te verhuizen

Voor dat soort dingen zou ik i.d.d. scheiding aanbrengen (eigendomsrecht is w.d.b. een goeie referentie). Al kunnen ze alles met mijn main git-repo en hun eigen git-repo (combinatie daarvan vormt hun IT). Er kan dus letterlijk een bedrijfs(onderdeel) afbranden zonder risico (BCM ftw).

W.d.b. gebruik ik veel VLAN's. Iedere applicatie (op server niveau) een eigen VLAN, met daarin b.v. webserver(s) en databases specifiek voor het desbetreffende doel.

code:

HA border routers ---> ...berg meut... ---> untagged VLAN ---> TOR switch+router
                                                                   |
                                                                   v
                                              50 VLAN's in een 19" 40U rack.

Die TOR-router staat alleen verkeer van applicatie-VLAN (LAN) naar internet (WAN) toe. Website1 (VLAN 51) hoeft niet bij Website2 (VLAN 52). Zo maak ik een 'internet rack', 'intranet rack', etc. Als gebruiker kan je bij services. Als aanvaller kan je niet uitbreken.

De TOR-router beschermt tegen exploitation van de hypervisors. VM naar hypervisor exploits, waardoor complete servers gehackt kunnen/mogen worden. Men komt nooit verder dan de eigen zone (b.v. intranet/extranet/internet). Intranet, extranet en internet zijn al 3 losstaande omgevingen (hypervisors), en ook 3 security zones.

^{TOR=Top of Rack}

Ochja, duizend-en-een-mogelijkheden!

[Pietervs]

@Verwijderd 50 vlans in een 19 inch rack?
vlan: virtueel, rack: fysiek

Maar leuke opzet! Ook een prettige scheiding van verkeer, hoewel ik me voor kan stellen dat het ook fors wat administratie met zich meebrengt: welk vlan is waarvoor en wat wordt waar getrunkt zodat iedereen toch bij de benodigde informatie kan?

[Verwijderd]

Pietervs schreef op woensdag 1 augustus 2018 @ 20:45:
Hoewel ik me voor kan stellen dat het ook fors wat administratie met zich meebrengt: welk vlan is waarvoor en wat wordt waar getrunkt zodat iedereen toch bij de benodigde informatie kan?

Met Ansible (en wat git repo's, o.a. met mijn eigen roleset) als SSOT, lig ik niet wakker van een interface meer of minder. Daarmee beheer ik switches, routers, servers, etc.

Vaak gebruik ik Debian met Shorewall als (TOR-router(s)), daar trunk ik de VLAN's op naar de TOR-switch. Vanaf de TOR-switch met trunks (en dedicated cable/VLAN voor BMC) naar hypervisors. Beheren van switch(es) is het probleem niet. Het ingewikkeldste is de TOR-router/firewall configureren (berg publieke IP-space, custom SSH access ports zodat alle servers op alle VLAN's te beheren zijn via 1 publiek IP).

De complete RFC1918 en VLAN ID's range recycle ik per rack/omgeving. Dan hoef ik geen rekening te houden met het complete plaatje.

En er is totaal geen sprake van topic-kaping!

[ Voor 15% gewijzigd door Verwijderd op 01-08-2018 23:41 ]

[Vuilnisauto]

Yordi- schreef op dinsdag 31 juli 2018 @ 20:54:
[...]


Ja. Dat betekent wel dat je router dit moet ondersteunen. Met een trunk tag je verkeer en kun je onderscheidt maken tussen verkeer in ieder vlan.


[...]

De huidige router (Draytek Vigor 2132fvn) ondersteunt dat volgens mij wel maar als we verhuizen krijgen we een andere van T-Mobilethuis opgestuurd, dus het is nog even afwachten wat dat wordt.

Yordi- schreef op dinsdag 31 juli 2018 @ 20:54:
[...]


Het beste is inderdaad VLAN1 untagged (en native op trunks) houden en voor je VLANs VLAN10,11,12 of VLAN10,20,30,... aan te houden.

De discussie die verder ontstaat ga ik maar niet op in, ik wil alleen even melden dat...


[...]

Ok duidelijk!

[Vuilnisauto]

Verwijderd schreef op woensdag 1 augustus 2018 @ 23:39:
[...]


Met Ansible (en wat git repo's, o.a. met mijn eigen roleset) als SSOT, lig ik niet wakker van een interface meer of minder. Daarmee beheer ik switches, routers, servers, etc.

Vaak gebruik ik Debian met Shorewall als (TOR-router(s)), daar trunk ik de VLAN's op naar de TOR-switch. Vanaf de TOR-switch met trunks (en dedicated cable/VLAN voor BMC) naar hypervisors. Beheren van switch(es) is het probleem niet. Het ingewikkeldste is de TOR-router/firewall configureren (berg publieke IP-space, custom SSH access ports zodat alle servers op alle VLAN's te beheren zijn via 1 publiek IP).

De complete RFC1918 en VLAN ID's range recycle ik per rack/omgeving. Dan hoef ik geen rekening te houden met het complete plaatje.

A haaaaa