Så sätter jag upp ett företagsnätverk – från första mötet till stabil drift
När jag sätter upp ett nätverk börjar jag aldrig med att bara koppla in utrustning och hoppas att allt ska fungera. Jag börjar med att förstå verksamheten. För mig är det grunden till allt. Ett nätverk ska inte bara fungera tekniskt. Det ska passa hur företaget faktiskt arbetar varje dag.
Jag vill bygga nätverk som är stabila, säkra, tydliga och lätta att förvalta. Det ska vara lätt att förstå hur allt hänger ihop, lätt att hitta fel när något händer och lätt att bygga vidare på när företaget växer.
Jag börjar med att lyssna på företaget
Det första jag gör är att prata med företaget och ta reda på hur de arbetar. Jag vill förstå hur vardagen ser ut innan jag bestämmer hur nätverket ska byggas.
Jag brukar fråga hur många användare som finns idag, hur många datorer som används, om personal arbetar hemifrån, vilka system som är viktigast, om det finns känslig information och om företaget planerar att växa framöver.
Det här steget är viktigt, för ett litet kontor med tio personer behöver inte samma lösning som en verksamhet med flera avdelningar, servrar, gästnät, skrivare, kameror och fjärrarbete. Om jag förstår verksamheten först blir det mycket lättare att bygga rätt från början.
Sedan ritar jag upp nätverket
När jag har förstått behoven gör jag alltid en nätverksritning. Jag använder ett diagramverktyg, och ibland ett AI-verktyg som hjälper mig att snabbt visualisera strukturen. Sedan justerar jag den själv så att den blir tydlig och realistisk.
I ritningen visar jag internetanslutning, brandvägg, switchar, accesspunkter, servrar, klientdatorer, olika nätverkszoner, IP-områden, VLAN, viktiga tjänster och hur trafiken ska gå mellan olika delar av nätverket. Jag markerar också var kryptering används, till exempel vid VPN eller säkra anslutningar mellan system.
Det här gör att jag kan se hela topologin innan jag börjar bygga. Då upptäcker jag ofta designfel tidigt, innan de hinner bli problem i verkligheten.
Jag inventerar utrustningen först
Innan installationen börjar vill jag veta exakt vad som finns i miljön. Jag inventerar datorer, servrar, skrivare, nätverksenheter, accesspunkter, licenser och operativsystem. Jag dokumenterar gärna modell, plats, funktion och vem som använder vad.
Det här kan kännas som ett tråkigt steg, men det sparar mycket tid senare. När något ska bytas ut, felsökas eller dokumenteras är det en stor fördel att redan ha ordning på miljön.
Jag försöker också märka upp det som går, till exempel kablar, patchpaneler, rackplatser, switchportar och nätverksuttag. Det är en sådan där detalj som kanske inte syns utåt, men som gör verklig skillnad när något ska felsökas snabbt.
Jag planerar IP-strukturen tidigt
En tydlig IP-plan är något jag alltid sätter tidigt. Jag vill att olika typer av enheter ska ligga i olika nät. Klientdatorer kan ligga i ett nät, servrar i ett annat, skrivare i ett tredje, gästnät i ett fjärde och exempelvis kameror eller andra IoT-enheter i ett femte.
Det gör nätverket enklare att förstå, enklare att säkra och enklare att felsöka. När jag ser en IP-adress vill jag direkt kunna förstå ungefär vad det är för typ av enhet och var den hör hemma.
Samtidigt bestämmer jag namnstandard. Servrar, klienter, switchar, accesspunkter och administratörskonton ska namnges på ett konsekvent sätt. Det låter som en liten detalj, men i större miljöer blir det mycket lättare att arbeta när namnen faktiskt säger något.
Jag simulerar ofta designen innan installation
Innan jag bygger nätverket i verkligheten brukar jag ofta simulera designen i Cisco Packet Tracer. Där kan jag testa hur topologin beter sig, hur VLAN är uppdelade, hur routing fungerar och om adressplanen ser rimlig ut.
Det här är ett bra sätt att upptäcka designfel tidigt. Om något inte fungerar i simuleringen är det bättre att rätta till det där än efter att allt redan är installerat på plats.
Jag använder alltså Packet Tracer för att testa själva designen innan installation. När nätverket sedan är byggt på riktigt använder jag andra verktyg för att analysera verklig trafik, verklig prestanda och verkliga fel.
Jag bygger infrastrukturen steg för steg
När planeringen är klar börjar jag bygga själva infrastrukturen. Jag brukar börja med internetanslutningen och brandväggen, och sedan fortsätta inåt i nätet.
Brandväggen först
Brandväggen är nätverkets ytterdörr. Här sätter jag regler för vad som får gå in och ut, hur fjärråtkomst ska fungera och hur olika delar av nätverket ska separeras från varandra.
Jag konfigurerar bland annat NAT, VPN, brandväggsregler och i vissa miljöer även skydd som kan upptäcka eller blockera misstänkt trafik. Jag försöker alltid hålla samma grundprincip: inget ska vara öppet i onödan. Det som inte behövs ska inte släppas igenom.
Switchar och intern struktur
När brandväggen är på plats sätter jag upp switcharna. Jag använder nästan alltid managed switchar, alltså switchar som går att konfigurera och övervaka. Det gör att jag kan arbeta med VLAN, trunkportar, portsäkerhet, övervakning och tydlig segmentering.
Jag ser också till att uplinks mellan switchar är korrekt konfigurerade, att portar är dokumenterade och att hastigheter och länkar ser rimliga ut. Små fel i switchkonfigurationer kan skapa stora och konstiga problem längre fram, så jag försöker göra detta noggrant från början.
Wi-Fi och gästnät
Det trådlösa nätet planerar jag separat. Jag delar nästan alltid upp det i minst två delar: ett internt nät för personal och ett gästnät för besökare. Gästnätet ska inte kunna nå företagets interna resurser. Det ska bara ge internet.
När det går använder jag stark autentisering även för det trådlösa nätet, så att åtkomst kan styras per användare och inte bara med ett gemensamt lösenord som alla känner till.
Jag delar upp nätverket med VLAN
Jag bygger sällan ett helt platt nätverk där alla enheter ligger i samma nät. I stället delar jag upp miljön med VLAN. Det betyder att jag skapar flera logiska nät i samma fysiska infrastruktur.
Jag brukar till exempel ha separata VLAN för klienter, servrar, skrivare, gästnät, administration av nätverksutrustning och ibland telefoni eller kameror.
Det här gör nätverket både säkrare och enklare att hålla ordning på. Om ett problem uppstår i en del påverkar det inte automatiskt allt annat. Jag får också mycket bättre kontroll över vilken trafik som ska vara tillåten mellan olika delar.
Jag tänker på redundans så tidigt som möjligt
Jag försöker undvika det som brukar kallas single point of failure, alltså att en enda enhet kan fälla hela miljön. I mindre företag går det inte alltid att bygga full redundans överallt, men jag tänker ändå igenom var riskerna finns.
Det kan handla om två switchar i stället för en, RAID i servrar, två internetanslutningar, UPS vid strömavbrott eller en andra DNS-server som kan ta över om den första faller bort.
Även när man inte har budget för dubbla allt går det ofta att minska riskerna med smart planering, reservdelar och tydliga återställningsrutiner.
Jag bygger gärna servermiljön virtuellt
Om miljön passar för det kör jag gärna servrarna virtuellt. Det gör det enklare att ta backup, fördela resurser, flytta tjänster och bygga en renare struktur. I stället för att varje tjänst kräver en egen fysisk maskin kan flera tjänster köras i virtuella maskiner med tydlig separering.
Det viktiga för mig är inte vilken virtualiseringsplattform man väljer, utan att miljön blir lätt att förvalta och lätt att återställa om något händer.
Så brukar jag sätta upp Windows Server 2025
När jag bygger en Windows-miljö lägger jag mycket fokus på grunden. Om grunden blir rörig blir resten också rörigt. I en miljö med Windows Server 2025 börjar jag med de centrala rollerna och ser till att allt är tydligt från början.
Active Directory
Jag sätter upp Active Directory som nav för användare, datorer, grupper och rättigheter. Jag organiserar det i tydliga delar så att det blir lätt att förstå vilka objekt som hör till vad. Jag skapar till exempel separata strukturer för användare, klientdatorer, servrar, grupper och servicekonton.
Jag försöker arbeta med grupper i stället för att ge rättigheter direkt till enskilda personer. Det gör administrationen mycket enklare och mycket renare över tid.
DNS
DNS är en av de viktigaste tjänsterna i ett nätverk. Om DNS inte fungerar känns det ofta som att hela nätverket beter sig konstigt. Därför sätter jag upp intern DNS ordentligt från början och ser till att klienterna verkligen använder rätt DNS-servrar.
Jag använder gärna minst två DNS-servrar i miljöer där det är möjligt, så att namnuppslagning fortsätter fungera även om en server blir otillgänglig.
DHCP
DHCP delar ut IP-adresser automatiskt till klienterna. Jag sätter tydliga intervall, reservationer där det behövs och dokumenterar vad som delas ut var. Skrivare, nätverksenheter och vissa servrar får ofta fasta adresser eller reservationer, medan vanliga klienter kan få sina adresser automatiskt.
Om miljön kräver det sätter jag även upp DHCP-failover, så att en andra server kan fortsätta dela ut adresser om den första skulle sluta fungera.
Group Policy
Group Policy använder jag för att styra klientdatorerna centralt. Där kan jag sätta säkerhetsregler, konfigurera skrivare, mappa nätverksmappar, styra uppdateringar, ställa in brandväggsregler och mycket annat.
Jag försöker hålla policys tydliga och uppdelade efter funktion. Jag vill inte ha en enda stor policy som gör allt, för det blir snabbt svårt att förstå vad som egentligen händer.
Tidsynkronisering
Jag ser alltid till att tiden är korrekt i miljön. Det låter enkelt, men fel tid kan orsaka problem med inloggningar, certifikat, loggar och felsökning. Därför sätter jag upp tydlig tidssynkronisering med NTP, så att alla system använder samma tidskälla.
Jag använder också Linux där det passar bäst
Jag använder ofta Linux för tjänster som övervakning, logghantering, Wazuh, backup, proxy eller andra driftnära funktioner. När jag installerar Linux börjar jag med en så ren installation som möjligt.
Jag uppdaterar direkt, stänger av sådant jag inte behöver, begränsar åtkomst och använder helst SSH-nycklar för administration där det passar. Jag försöker vara konsekvent även här: tydlig dokumentation, tydliga portar, tydliga roller och så få onödiga tjänster som möjligt.
Så hanterar jag användare och konton på ett professionellt sätt
Jag vill inte skapa användare manuellt på varje dator. Det blir långsamt och ger lätt fel. I stället skapar jag användarna centralt och låter datorerna hämta rätt inställningar automatiskt.
När en ny person börjar skapar jag kontot i Active Directory, lägger användaren i rätt grupper och ser till att rättigheter, mappar, skrivare och policys följer med automatiskt. Då blir det både snabbare och mer konsekvent.
Om jag har många användare använder jag gärna PowerShell och mallar, till exempel via CSV-import, så att jag kan skapa konton på ett enhetligt sätt. Det gör också att det ser professionellt ut i miljön, eftersom samma struktur används överallt.
Jag skiljer också på vanliga användarkonton och administratörskonton. En person som arbetar i IT ska helst inte använda sitt admin-konto för vardagligt arbete. Vanligt konto för vanligt arbete, administratörskonto bara när administration faktiskt behövs.
Jag tänker lika mycket på avslut som på start. När någon slutar ska kontot stängas av direkt, åtkomster tas bort och utrustning återlämnas. Offboarding är minst lika viktigt som onboarding.
Jag ger bara den åtkomst som behövs
En princip jag nästan alltid följer är least privilege. Det betyder att användaren bara ska ha den åtkomst som behövs för arbetet, inte mer.
Det är lätt att ge för mycket rättigheter för att det går snabbare i stunden, men det skapar nästan alltid större problem senare. Vanliga användare ska inte ha lokala administratörsrättigheter om det inte finns ett mycket tydligt skäl. Delade mappar ska inte vara öppna för alla bara för att det är bekvämt.
Det här minskar både risken för misstag och risken att skadlig kod får för stort utrymme om något går fel.
Jag lägger till MFA där det går
När det är möjligt använder jag MFA, alltså inloggning i två steg. Det betyder att lösenord inte räcker ensamt, utan att användaren också behöver bekräfta inloggningen på ett annat sätt, till exempel i mobilen.
Det här gör stor skillnad, särskilt för VPN, fjärråtkomst, administratörskonton och molntjänster. Ett starkt lösenord är bra, men tvåfaktorsinloggning gör mycket mer för säkerheten.
Jag standardiserar klientdatorerna
När serverdelen och nätverket fungerar går jag vidare till klientdatorerna. Jag vill att de ska installeras så lika som möjligt. I mindre miljöer kan det göras manuellt, men med samma struktur varje gång. I större miljöer använder jag gärna nätverksbaserad installation eller andra automatiserade metoder.
Jag ser till att datorerna kommer in i domänen, får rätt namn, rätt policyer, rätt uppdateringar och rätt säkerhetsinställningar. Jag vill att en ny dator snabbt ska bli användbar utan att jag behöver göra allt från grunden varje gång.
Jag tänker också på klientskydd. Antivirus, EDR, diskkryptering och tydliga brandväggsregler hör för mig ihop med drift, inte som något som ska komma i efterhand.
Jag testar helst ändringar i en staging-miljö först
När det går bygger jag en staging-miljö, alltså en testmiljö där jag kan prova ändringar innan de går ut i produktion. Det kan vara Group Policies, uppdateringar, script, nya tjänster eller ändrade nätverksregler.
Poängen är enkel: jag vill inte att användarna ska bli testmiljön. Om något går sönder vill jag att det ska hända där jag kan rätta till det lugnt, inte mitt under en vanlig arbetsdag.
Jag patchar regelbundet och med plan
Patchning är en naturlig del av drift. Jag uppdaterar operativsystem, klienter, servrar, brandväggar, switchar och andra enheter regelbundet så att säkerhetshål stängs och buggar rättas till.
Jag installerar inte uppdateringar blint. Jag läser vad de gör, testar vid behov i testmiljö, väljer rätt tidpunkt och dokumenterar större förändringar. Det gör att patchning blir en kontrollerad del av driften i stället för något som bara sker när ett problem redan har uppstått.
Jag dokumenterar förändringar medan jag arbetar
Jag försöker inte hålla allt i huvudet. När jag gör större ändringar skriver jag ner vad som ändrades, när det ändrades och varför. Det kan vara en ny brandväggsregel, en ändrad Group Policy, ett nytt VLAN eller en flytt av en tjänst.
Det behöver inte vara komplicerat. Det viktiga är att det går att förstå i efterhand. När något ska felsökas flera veckor senare är det ofta den här typen av anteckningar som gör att man hittar orsaken snabbt.
Jag tänker också på rollback, alltså hur jag backar om något går fel. Innan större ändringar vill jag veta hur jag tar mig tillbaka till ett fungerande läge.
Jag sparar konfigurationer från nätverksutrustningen
Brandväggar, switchar, accesspunkter och andra viktiga enheter ska inte bara vara konfigurerade. Deras konfiguration ska också sparas. Jag tar backup på konfigurationer och ser till att de går att hitta.
Om en enhet går sönder är det mycket bättre att kunna återställa en känd fungerande konfiguration än att försöka bygga om allt från minnet.
Jag använder Wazuh och central loggning för säkerhet och överblick
När grunddriften fungerar vill jag också ha överblick över säkerheten. Där använder jag ofta Wazuh. Jag samlar loggar från servrar, klienter och ibland nätverksutrustning till en central plats.
Wazuh fungerar som en SIEM-lösning, alltså ett system som samlar och analyserar säkerhetsrelaterad information. I praktiken betyder det att jag kan upptäcka ovanliga inloggningar, misstänkta ändringar i filer, brute force-försök, policybrott och annan aktivitet som kan vara viktig.
Jag centraliserar också loggar med syslog där det passar, så att brandväggar, switchar och Linux-servrar skickar sina loggar till en samlingsplats. Då behöver jag inte jaga information på flera ställen när något ska felsökas.
Jag använder också vanlig övervakning, inte bara säkerhetsloggar
Säkerhetsloggar räcker inte för att driva ett nätverk bra. Jag behöver också se hur systemen mår. Därför använder jag övervakningsverktyg som kan visa CPU, minne, disk, tjänster, portar, temperaturer och nätverksbelastning.
Till nätverksutrustning använder jag gärna SNMP, så att jag kan läsa status från switchar, brandväggar, routrar och accesspunkter. Då kan jag se portstatus, belastning, felräknare och andra detaljer innan användarna ens hinner märka att något är fel.
Bra övervakning handlar mycket om att upptäcka problem innan de blir akuta.
Jag kontrollerar alltid latency och verklig nätverksprestanda
När nätverket är installerat räcker det inte att allt går att nå. Jag vill också veta att det fungerar snabbt och stabilt. Därför kontrollerar jag alltid latency, alltså fördröjningen i nätverket.
Jag börjar ofta med enkla tester som ping för att se svarstider och traceroute för att se vilken väg trafiken tar. Om något känns långsamt eller instabilt går jag vidare med djupare analys.
Wireshark
När jag vill analysera trafiken i detalj använder jag Wireshark. Där kan jag se paket, protokoll, DNS-frågor, retransmissions, märklig trafik och många andra detaljer som hjälper mig att förstå vad som faktiskt händer i nätverket.
tcpdump
På Linux-servrar använder jag ofta tcpdump. Det är snabbt, enkelt och väldigt användbart när jag vill se om trafik verkligen når fram till en server eller om något blockeras på vägen.
Cisco NetFlow
Om nätverket har stöd för det använder jag gärna Cisco NetFlow eller motsvarande flödesdata. Det gör att jag kan se vilka enheter som skickar mest trafik, vilka tjänster som används mest och om något sticker ut ovanligt mycket. Det är ett bra sätt att hitta flaskhalsar eller misstänkt aktivitet.
Switchens egna analysverktyg
Jag tittar också på switchens egna analysverktyg. Många managed switchar visar portfel, CRC-fel, tappade paket, överbelastning och andra detaljer som är väldigt användbara vid felsökning. Ibland ligger svaret där och inte i servern man först misstänkte.
Belastning och kapacitet
I miljöer där prestanda är extra viktig testar jag också hur nätverket beter sig under belastning. Jag vill inte bara veta att det fungerar när nästan ingen använder det. Jag vill veta att det fungerar när flera användare arbetar samtidigt, flyttar filer, använder databaser eller kör fjärråtkomst.
Jag isolerar känsliga system
Alla system ska inte kunna nå alla andra system. Jag isolerar gärna känsliga delar som backupserver, administrativa servrar, databaser eller management-nät för nätverksutrustningen.
I vissa miljöer använder jag också en bastion host eller jump server. Det är en särskild server som administratörer använder för att nå känsliga system på ett kontrollerat sätt. Det gör administrationen säkrare och tydligare.
Backup är inte klart förrän återställning är testad
Jag tar alltid backup, men jag ser inte backup som färdig förrän jag har testat att återställa. Annars vet jag egentligen bara att data har kopierats, inte att den går att få tillbaka.
Jag försöker följa 3-2-1-principen. Det betyder tre kopior av data, på två olika typer av lagring, där minst en kopia finns på en annan plats. Det kan till exempel vara lokal backup, en NAS och en kopia utanför platsen eller i molnet.
Jag tar inte bara backup på filer. Jag tänker också på virtuella maskiner, konfigurationer, viktiga script och dokumentation. Och jag testar återställning med jämna mellanrum, för det är ofta då man ser om upplägget verkligen fungerar.
Jag tänker också på katastrofläge och återhämtning
När miljön är viktig för verksamheten tänker jag inte bara på vanlig backup, utan också på hur snabbt företaget måste vara tillbaka om något större händer.
Jag brukar tänka i två enkla frågor: Hur mycket data får vi förlora som mest? Hur länge får systemen ligga nere som mest?
När man har svar på de frågorna blir det mycket lättare att bestämma rätt backupintervall, rätt redundans och rätt återställningsplan.
Jag glömmer inte fysisk säkerhet
Nätverkssäkerhet är inte bara brandväggar och konton. Fysisk säkerhet betyder också mycket. Jag tänker på låsta rack, vem som har tillgång till serverrum, ordning i kablage, rätt ventilation och UPS vid strömavbrott.
Jag vill inte att någon ska kunna dra ut fel kabel, stänga av en kritisk enhet av misstag eller få åtkomst till administrationsportar utan kontroll.
Jag dokumenterar hela miljön ordentligt
När installationen närmar sig slutet ser jag till att dokumentationen faktiskt går att använda. Jag sparar nätverksritning, IP-plan, VLAN, adressreservationer, portar, serverroller, brandväggsregler, backupupplägg, logglösningar, driftinformation och kontaktvägar.
Bra dokumentation ska göra att en annan tekniker kan förstå miljön även utan att jag sitter bredvid och förklarar allt muntligt.
Jag planerar också för framtiden
Jag bygger inte bara för idag. Jag försöker lämna lite utrymme för att företaget ska kunna växa. Det kan vara fler lediga portar, plats för fler accesspunkter, möjlighet att lägga till fler VLAN eller resurser nog i servermiljön för att hantera fler tjänster framöver.
Det behöver inte vara överdimensionerat, men det ska inte heller vara så pressat att varje liten förändring blir ett större projekt.
Jag gör alltid en tydlig avslutande kontroll
När allt är klart gör jag en sista genomgång. Jag kontrollerar att användare kan logga in, att DNS fungerar, att DHCP delar ut rätt, att Group Policies slår igenom, att backup kör, att övervakning larmar, att loggar samlas centralt och att viktiga system går att nå som de ska.
Det är också här jag gör en sista acceptanskontroll med verksamheten. Jag vill säkerställa att nätverket inte bara ser rätt ut ur teknisk synvinkel, utan också fungerar som företaget behöver i praktiken.
Min grundidé i allt det här
Mitt mål är inte att bygga det mest komplicerade nätverket. Mitt mål är att bygga ett nätverk som går att lita på. Jag vill att användarna ska kunna arbeta utan störningar, att problem ska gå att hitta, att säkerheten ska vara genomtänkt och att miljön ska vara möjlig att förvalta över tid.
För mig syns riktigt sysadmin-arbete inte i hur många svåra ord man använder, utan i hur lugnt, tydligt och hållbart man bygger.
När nätverket fungerar så bra att användarna knappt tänker på det längre, då vet jag att jag har gjort ett bra jobb.