Dubbele 'router-on-a-stick'

[ktf]

Goedemiddag allen,

Momenteel ben ik bezig met het upgraden van een netwerk in een complex van fabriekshallen. Graag zou ik verschillende apparaten op verschillende VLANs zetten, om een zogenaamde router-on-a-stick configuratie te handhaven. Ik zit alleen met een vaag probleem met lussen dat ik niet begrijp. Ik heb helaas de komende 2 weken niet de mogelijheid om on-site dingen te proberen, maar misschien is het wel gewoon een basale denkfout die ik maak. Onderstaand is een diagram met alle aansluitingen



Ik gebruik hier L2-switches met VLAN capaciteiten. De rechterswitch, die direct aan de server hangt, werkt prima: de aangesloten IP-camera zit op VLAN A, de twee computers in de werkplaats zitten op VLAN B en de server zit op een tagged port/trunk. De (linux-)server heeft de VLAN poorten geconfigureerd aan een bridge (wat in linux-termen zoveel is als een softwareswitch), waarover ik met behulp van iptables probeer het verkeer uit elkaar te houden. Op die manier zitten de apparaten wel allemaal op hetzelfde subnet. De twee rode lijntjes zouden tagged moeten zijn

Het probleem is als volgt: Als ik de VLAN capaciteit op de linkerswitch uitzet, en het lijntje ernaartoe een op de andere switch een VLAN geef, werkt het prima. Als ik echter op de rechterswitch zowel de poort naar de server als naar de linkerswitch op tagged/trunk zet, en de VLAN capaciteit op de linkerswitch aanzet, ligt alles direct plat.

Mijn vraag is dus: kan ik op een switch wel twee tagged/trunk-poorten hebben? Kan ik een router-on-a-stick zoals ik die hier heb, eigenlijk wel 'stapelen'? Zoals je ziet zijn de lengtes zodanig dat ik niet even een extra draad kan trekken, en de rechterswitch is zelfs PoE-powered: er is in de buurt simpelweg geen 230V beschikbaar.

Alvast hartelijk dank

[CAPSLOCK2000]

Ja, je kan meerdere trunk-poorten hebben.
Heb je aangegeven welke vlans er over de trunk-poorten mogen?

Ik snap niet helemaal wat je met stapelen bedoelt.
Pas op met iptables en bridges, dat zou wel eens niet kunnen werken zoals je denkt. Zo'n bridge werkt eigenlijk op een ander niveau dan iptables. Het kan wel maar je moet goed weten wat je doet. Test je configuratie dus goed voor je er op vertrouwt.

[ktf]

CAPSLOCK2000 schreef op woensdag 20 mei 2015 @ 18:05:
Ja, je kan meerdere trunk-poorten hebben.
Heb je aangegeven welke vlans er over de trunk-poorten mogen?

Oke, dan zal het daar wel niet aan liggen. Ik heb de simpele configuratie aangehouden: de tagged-lijnen trekken alle VLANs. Ik zou inderdaad de configuratie geavanceerder kunnen maken, maar de hoeveelheid verkeer is laag en het levert vast meer gedonder op

Ik snap niet helemaal wat je met stapelen bedoelt.

Ik bedoel dat de tweede switch niet met een direct lijntje aan de router hangt, maar via een andere switch loopt, die óók als router-on-a-stick werkt.

Pas op met iptables en bridges, dat zou wel eens niet kunnen werken zoals je denkt. Zo'n bridge werkt eigenlijk op een ander niveau dan iptables. Het kan wel maar je moet goed weten wat je doet. Test je configuratie dus goed voor je er op vertrouwt.

Ik heb voor een paar configuraties ebtables toe moeten passen, maar een regel als

code:

-A FORWARD -m physdev --physdev-in eth1.[VLAN B] -d 192.168.2.0/24 -j DROP

om ervoor te zorgen dat een eventueel gehacked meetapparaat niet bij de kantoorcomputer kan (met ipv [VLAN] de bijbehorende VLAN ID) werkt prima.

[Ximon]

Volgens mij kan je jezelf een hoop moeilijkheden besparen door ergens een router en firewall vandaan te halen en die ergens in de buurt van de server te plaatsen. De server kan dan gewoon op een switchpoort aangesloten worden en kan in een (extra, eigen?) VLAN gezet worden. De nieuw te plaatsen router kan dan inter-VLAN routing en internettoegang regelen.

Mocht nieuwe hardware aanschaffen lastig zijn dan kan je ook een die je nog hebt staan PC met pfSense of Sophos UTM Essential en wat extra netwerkkaarten inzetten.

Overigens zou ik me over het algemeen meer zorgen maken over gehackte kantoorcomputers die bij de meetapparatuur kunnen

[johnkeates]

Het is zelfs zonder extra hardware te doen: installeer een hypervisor op je server, virtualiseer wat er nu op staat en voeg pfSense toe.

[Question Mark]

ktf schreef op woensdag 20 mei 2015 @ 17:27:
Kan ik een router-on-a-stick zoals ik die hier heb, eigenlijk wel 'stapelen'?

Welke router on a stick bedoel je?

Een router on a stick is een L3 netwerkdevice die intervlan routering verzorgd en is ontsloten met één Nic op je netwerk. Die vind ik niet terug in je plaatje.

[ktf]

Ximon schreef op woensdag 20 mei 2015 @ 19:29:
Volgens mij kan je jezelf een hoop moeilijkheden besparen door ergens een router en firewall vandaan

Wat schiet ik er precies mee op om een software-oplossing (die ik goed begrijp, uitbreidbaar is, al jaren werkt etc.) te vervangen door een hardware-oplossing?

johnkeates schreef op woensdag 20 mei 2015 @ 19:33:
Het is zelfs zonder extra hardware te doen: installeer een hypervisor op je server, virtualiseer wat er nu op staat en voeg pfSense toe.

Daarmee maak ik het mezelf alleen maar moeilijker? Even een nieuwe server met AMD-V of Intel VT-x aanschaffen, nee, dat is een oplossing Ik smijt er honderden euro's tegenaan, en wat verbetert er dan?

Question Mark schreef op woensdag 20 mei 2015 @ 20:23:
Een router on a stick is een L3 netwerkdevice die intervlan routering verzorgd en is ontsloten met één Nic op je netwerk. Die vind ik niet terug in je plaatje.

Oke, het is dan misschien geen router-on-a-stick maar een switch-met-filtering-on-a-stick. Het idee is hetzelfde: de VLANs worden alleen gebridged in plaats van gerouterd via de server. (Oh, en even voor de duidelijkheid: de server heeft dus 3 NICs, één naar de rechterswitch in de fabriekshal, één naar kantoor en één naar de modemrouter)

[ Voor 5% gewijzigd door ktf op 21-05-2015 00:11 ]

[johnkeates]

ktf schreef op donderdag 21 mei 2015 @ 00:00:
[...]

Daarmee maak ik het mezelf alleen maar moeilijker? Even een nieuwe server met AMD-V of Intel VT-x aanschaffen, nee, dat is een oplossing Ik smijt er honderden euro's tegenaan, en wat verbetert er dan?

[...]

Nee, op je huidige server zoals ik postte. En daar heb je geen AMD-V of VT-x voor nodig, behalve als je devices wil doorgeven (en dan heb je voornamelijk VT-d nodig).

De reden dat ik dat suggereerde is om dat je dan geen nieuwe hardware hoeft te kopen en dan toch een router kan toevoegen, want die staat nu niet in het plaatje en lijk je ook niet te hebben.

[ktf]

johnkeates schreef op donderdag 21 mei 2015 @ 01:03:
De reden dat ik dat suggereerde is om dat je dan geen nieuwe hardware hoeft te kopen en dan toch een router kan toevoegen, want die staat nu niet in het plaatje en lijk je ook niet te hebben.

Zoals ik al zei: ik router/bridge met de server, via de standaard linux-tools. Daarom mijn vraag: wat is het grote verbeterpunt dat te vervangen door andere software?

[Ximon]

ktf schreef op donderdag 21 mei 2015 @ 00:00:
[...]

Wat schiet ik er precies mee op om een software-oplossing (die ik goed begrijp, uitbreidbaar is, al jaren werkt etc.) te vervangen door een hardware-oplossing?


[...]

Daarmee maak ik het mezelf alleen maar moeilijker? Even een nieuwe server met AMD-V of Intel VT-x aanschaffen, nee, dat is een oplossing Ik smijt er honderden euro's tegenaan, en wat verbetert er dan?


[...]

Oke, het is dan misschien geen router-on-a-stick maar een switch-met-filtering-on-a-stick. Het idee is hetzelfde: de VLANs worden alleen gebridged in plaats van gerouterd via de server. (Oh, en even voor de duidelijkheid: de server heeft dus 3 NICs, één naar de rechterswitch in de fabriekshal, één naar kantoor en één naar de modemrouter)

Als het al jaren werkt, vanwaar dan jouw vraag? Het is an sich een prima streven om dingen simpel te houden (en daarmee minder foutgevoelig, makkelijker te onderhouden etc etc) maar ik vraag me af of hier de juiste oplossing gebruikt wordt.

• Is het noodzakelijk dat de meetapparatuur en IP-camera's ook te bereiken zijn vanaf de werkplaats of kantoor-PC's?
• Zijn er naast de verschillende VLAN's ook verschillende IP-subnetten in gebruik?

Je kan een LAN segmenteren door middel van VLAN's zonder ook gelijk verschillende subnetten te gebruiken, maar je moet dan wel goed in de gaten houden wat met wat moet kunnen communiceren. Jouw oplossing werkt nu denk ik volledig op OSI laag 2 en ik denk dat de Linux server misschien een loop tussen twee VLAN's maakt. Bijvoorbeeld: (broadcast)verkeer uit VLAN A wordt gebridged naar VLAN B, wordt weer teruggeswitched naar de server via VLAN B, wordt weer gebridged naar VLAN A enzovoorts. Dit heet een broadcast storm.

Dit kan opgelost worden door de netwerken verder te segmenteren d.m.v. verschillende subnetten. Binnen elk VLAN wordt dan ook een apart subnet gebruikt, en de Linux server routeert het verkeer van het ene naar het andere subnet indien nodig.

Je hoeft geen extra hardware of zelfs software in te zetten; iptables (wat iets anders is dan ebtables) kan dit ook. Het grote verbeterpunt van bijvoorbeeld pfSense t.o.v. standaard Linux tools is een mooie webinterface die een stuk sneller werkt bij het aanpassen van de firewall rulesets en het managen van interfaces. Dit is lang niet het enige, maar de overige extra mogelijkheden heb je misschien in jouw netwerk niet nodig

Dat gezegd hebbende: als de meetapparatuur en IP-camera's alleen bereikbaar moeten zijn vanaf de Linux server zie ik uberhaupt de noodzaak tot bridgen niet. Als je op de Linux server de (sub)interfaces op de juiste manier configureert is alles bereikbaar vanaf de server, maar kunnen de IP-camera's, meetapparatuur, werkplaats- en kantoor-PC's niet met elkaar praten en werkt alles zoals bedoeld?

[ktf]

Ximon schreef op donderdag 21 mei 2015 @ 08:41:
Als het al jaren werkt, vanwaar dan jouw vraag?

Het hele systeem (wat voor 90% werkt) omgooien omdat er ik ergens een loopje heb is m.i. met een kanon op een mug schieten. Ik wist niet precies waar te beginnen met zoeken, maar de antwoorden geven aan dat er met deze manier van VLANs gebruiken an sich niets mis is, en dat het probleem ws in de serverconfiguratie zit. Dat is mooi, dat was ik weten wilde

• Is het noodzakelijk dat de meetapparatuur en IP-camera's ook te bereiken zijn vanaf de werkplaats of kantoor-PC's?
• Zijn er naast de verschillende VLAN's ook verschillende IP-subnetten in gebruik?

Voor beide nee, maar de meetapparatuur moet wel bij het internet kunnen. Ik ga niet uitleggen waarom. Ik kan de IP-camera's inderdaad wel op een eigen subnet zetten.

en ik denk dat de Linux server misschien een loop tussen twee VLAN's maakt.

Dan ga ik, zodra ik daar de kans toe eens zie, daar eens goed aan troubleshooten.

Dit kan opgelost worden door de netwerken verder te segmenteren d.m.v. verschillende subnetten.

Helaas doet de modemrouter de DHCP (dat kan niet uitgezet worden) en moet ik daardoor alles wat aan het internet moet hangen wel op hetzelfde subnet houden. Oftewel, ik kan alleen de IP-camera's een eigen subnet geven.

Het grote verbeterpunt van bijvoorbeeld pfSense t.o.v. standaard Linux tools is een mooie webinterface

Ik prefereer iptables. Goed gedocumenteerd, ondubbelzinnig en hele ruime mogelijkheden. Ik geloof niet dat een webinterface alle mogelijkheden die ik op de commandoregel heb kan ontsluiten.

Ik moet zeggen, tot nu toe is het de discussie veel vruchtbaarder geweest dan ik van tevoren had verwacht Bedankt daarvoor!

[Ximon]

Ok, helder. Ik zit nog over mijn eigen voorstel voor een oplossing te denken, en kan geen reden verzinnen waarom de broadcast storm optreedt wanneer de connectie naar de linkerswitch omgezet wordt naar een trunk. Het lijkt me dat 1 switch met trunk naar de server voldoende is om een loop tussen twee VLANs te maken. Misschien zie ik iets over het hoofd, of ontbreekt er een cruciaal detail op de netwerktekening maar ik ben vrij zeker dat dit het probleem is (en het komt wel vaker voor )

In het algemeen zou ik op laag 3 filteren in plaats van op laag 2. Je kan hiervoor de server gebruiken, door met iptables bepaalde delen van het subnet te blokkeren of door te laten. Tenzij de applicaties niet via IP communiceren natuurlijk.

[ Voor 3% gewijzigd door Ximon op 21-05-2015 14:33 ]

[johnkeates]

pfSense is niet zozeer voor de GUI, maar voor pf en BSD, wat qua netwerksupport toch altijd nog tien keer beter dan Linux is ;-)

Anyway, terug naar het daadwerkelijke probleem: trunk doorlussen moet geen probleem zijn, de vraag is natuurlijk: wat hebben de switches er over te melden? Ik heb nog geen referentie qua switch error logs of server logs gezien. Het zou zomaar kunnen dat een switch bijvoorbeeld besluit dat er ergens een loop zit (ook als ie er niet zit) en dan maar niks meer door laat. Hoe staat STP op het moment ingesteld? Niet dat je dat met deze setup nodig hoort te hebben, maar het kan zo maar zijn dat je met STP overal aan meer informatie krijgt over wat te switches en server denken dat er aan de hand is.

[Freeaqingme]

johnkeates schreef op donderdag 21 mei 2015 @ 14:40:
pfSense is niet zozeer voor de GUI, maar voor pf en BSD, wat qua netwerksupport toch altijd nog tien keer beter dan Linux is ;-)

Op welke BSD doel je dan precies? Ik heb afgelopen tijd de nodige serieuze productiebakken opgetuigd die high traffic doen, meerdere routetabellen nodig hebben, qos, ecmp, etc. En een aantal keer bleek dat FreeBSD met PF gewoon niet _kon_ doen wat ik wilde, waar Linux dat wel kon. Daarnaast kwamen we de nodige obscure bugs tegen in FreeBSD/PF, terwijl Linux/Iptables eigenlijk altijd gewoon deed wat we wilden dat 't deed...

Edit: To be fair, staat wel tegenover dat Linux vaker wat security updates nodig heeft.

[ Voor 6% gewijzigd door Freeaqingme op 21-05-2015 14:50 ]

[johnkeates]

Freeaqingme schreef op donderdag 21 mei 2015 @ 14:45:
[...]


Op welke BSD doel je dan precies? Ik heb afgelopen tijd de nodige serieuze productiebakken opgetuigd die high traffic doen, meerdere routetabellen nodig hebben, qos, ecmp, etc. En een aantal keer bleek dat FreeBSD met PF gewoon niet _kon_ doen wat ik wilde, waar Linux dat wel kon. Daarnaast kwamen we de nodige obscure bugs tegen in FreeBSD/PF, terwijl Linux/Iptables eigenlijk altijd gewoon deed wat we wilden dat 't deed...

Edit: To be fair, staat wel tegenover dat Linux vaker wat security updates nodig heeft.

Voornamelijk FreeBSD 8 en FreeBSD 10, de enige bugs die ik tegen kwam die van toepassing waren op onze setups waren hypervisor gerelateerd en vrij eenvoudig op te lossen. De meeste setups zijn echter alleen maar voor 4x1Gbit trunks in gebruik en niet veel hoger. Die 4Gbit pompen ze vrij eenvoudig door. Op 10Gbit nog niet gebruikt, daar hebben we spul van Cisco/Juniper/HP voor staan (vaak gewoon wat er al voor handen was ).

[ktf]

Afgelopen weekend heb ik eindelijk de mogelijkheid gehad dit eens uitgebreid te bestuderen, en na een ongelofelijke hoop gepruts werkt het dan eindelijk. Ik heb geen idee wat ik nu precies de eerste keer verkeerd heb gedaan dat het niet meer werkte (het zal inderdaad vast in de firewall gezeten hebben), maar het is dus nu geregeld.

Bedankt voor de ondersteuning