Att skydda kunder från andra kunder är en fråga som varit på tapeten många gånger.
Enkla åtgärder som att partitionera nätet med egna VLAN och subnät är bara några av de saker vi gör för att förbättra prestanda i nätet genom att minska ”skräp”-trafik. Ibland behövs ytterligare lite nätverks-magi.
I denna post kommer jag beskriva en av de metoder vi använder för att skydda våra nätverk på länklagret (layer 2).
Här om dagen fick jag en historia berättad för mig där en kille had stoppat in en kabel i fel nätverksport på sin skola.
Tydligen hade det sänkt hela kommunens nätverk när en switch-loop uppstått.
Här har vi ett solklart exempel på när nätverks-ansvarig inte gjort sin läxa.
Vad som hände här var att switchar får multipla vägar som trafiken kan gå. Ethernet är inte alltid så smart så att det kan förstå när nån gör fel. Den försöker bara matcha vad som händer på det fysiska lagret.
Ett värre exempel var nyligen då ett sjukhus datornätverk gick ned helt och hållet.
Detta berodde på att någon sjuksköterska hade kopplat in en nätverkskabel i fel nätverksuttag. Felet upptäcktes inte förrens man gått igenom varje avdelning där det fanns nätverk.
Vad som skapar detta fel om man inte vidtagit åtgärder mot detta är att när en port aktiveras och en ny väg till samma switchar märks så uppstår en loop. Paketen skickas runt runt, arp requests skickas fel och eventuell broadcast storm .
En lösning är att sätta upp korrekta spanning tree protocol (STP) konfigurationer. Beroende på switch-tillverkare och modell så aktiverar man STP per VLAN och port. Anger vilken port som kommer vara primär, och vilken som kommer vara sekundär vid eventuellt bortfall för att få redundans.
För cisco så finns det en superb beskrivning på Ciscos portal här .
Själv föredrar jag att lösa redundans i core och distribution på andra vis – men problemet med loopar kan fortfarande uppstå. Detta löser jag på ett smidigare sätt än STP.
Svaret på detta problem (och som kommunens it-tekniker borde kunnat) är BPDU guard.
Det är så enkelt och går snabbt att implemetera på ciscoutrustning och annan utrustning som stödjer det.
I cisco-miljö görs det på följande vis:
CatOS Command
Console> (enable) set spantree portfast bpdu-guard enable Spantree portfast bpdu-guard enabled on this switch. Console> (enable)
Cisco IOS Software Command
CatSwitch-IOS(config)# spanning-tree portfast bpduguard CatSwitch-IOS(config)
Vad detta gör är att när en switch loop upptäcks försätts ena anslutningen i inaktiverat (disable) läge.
Om man vill att switchen ska försöka återansluta efter ett tag kan man konfigurera automatiskt retry. Annars kommer den felande länken vara inaktiverad tills man löser det manuellt.
CatOS Commands
Console> (enable) set errdisable-timeout interval 400 Console> (enable) set errdisable-timeout enable bpdu-guard
Cisco IOS Software Commands
CatSwitch-IOS(config)# errdisable recovery cause bpduguard CatSwitch-IOS(config)# errdisable recovery interval 400
Note: The default timeout interval is 300 seconds and, by default, the timeout feature is disabled.
BPDU Guard bör man konfigurera på alla kritiska switchar där loopar kan uppstå. Det räcker med något så enkelt som att koppla en kabel från en port till en annan på samma switch ibland för att skapa en loop.
Källa: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009482f.shtml
Hur tycker du man ska göra för att skydda sin kundmiljö då?
Där kunder själva har root-access på en virtuell server, och tilldelad en ip-adress i ett redan existerande vlan?
Det är ju i teorin möjligt för kunder att lägga till fler ip-adresser eller nyttja andras ip-adresser i samma subnät då.
Finns det någon lösning?
Nu tar jag vmware som exempel.
Ett av sätten att göra detta är att låta vmware hantera arp-tabeller och översättning.
Görs i virtuell switch / distributed virtual switch. Du får leta där helt enkelt, du kan t.ex. låta virtuella maskiner endast ta DHCP tilldelat från VM host (ESXi systemet). Liknande tekniker som de flesta virtual private server kontrollpaneler använder sig av för att tilldela de enda IP-adresser som går att använda. Det är lite pill med detta så förklarar inte i detalj hur detta görs.
En annan enklare metod är att faktiskt hantera dina virtuella maskiner som om de vore fysiska på nätverket och helt enkelt sätta upp egna subnät på eget vlan ända ut till den virtuella maskinens virtuella nätverkskort.
Din VM host (t.ex. VMWare ESXi) får en fysisk nätverksport kopplad mot en managerad switch där porten är konfigurerad att tillåta flera vlan att passera till switchen (så kallad switchport mode trunk / otaggade paket tillåts) . Rekommenderar att strängt definera vilka VLAN id som får tillåtas av säkerhetsskäl, står i manualer till det switchfabrikat du använder dig av.
På VMhosten konfigurerar du ditt management network att använda rätt VLAN id eftersom du nu måste tagga alla paket som går ut fysiskt – även managerings ip.
För att tagga virtuella maskinerna så tilldelar du dom rätt interface på VM hostens virtual switch / distributed virtual switch och sätter virtuella nätverksportar med respektive vlan (motsvarar switchport access vlan i cisco miljö) .
Detta görs under ”Configuration -> Networking” (för vmware ESXi hsoten) respektive under ”Edit settings” på din virtuella maskin.
Förutsätter att du själv får luska ut sen hur du sätter ett IP subnät tilldelat per vlan i din fysiska eller virtuella router om det är en sådan du använder 🙂