Her skal du dele et nettverk i segmenter og begrunne hvilken trafikk som skal få passere. Du trenger adresse, prefiks, gateway og port fra IP, subnett og standard gateway og nettverksprotokoller.
Begynn med VLAN-eksemplet, Oppgave 1 og brannmurøvelsen. Grunnløypen er en tilgangsplan med forventet tillatt og blokkert trafikk. Praktisk endring krever eget, godkjent testmiljø og en vei tilbake til forrige oppsett. Uten slik tilgang bruker du eksemplet til planlegging; du skal ikke endre skolens nett. Subnettberegning og DHCP-oppsett er viderevalg.
Hvorfor segmentere?
Segmentering deler nettverket i mindre deler. VLAN skiller trafikken på lag 2. En ruter eller lag-3-svitsj kan fortsatt formidle trafikk mellom dem; brannmur eller tilgangsregler bestemmer hva som faktisk tillates.
| Fordel | Forklaring |
|---|---|
| Sikkerhet | Tilgangsregler kan begrense hvilke tjenester et IoT-kamera når |
| Ytelse | Mindre broadcast-trafikk per segment |
| Kontroll | Ulike regler for ulike brukergrupper |
| Feilsøking | Lettere å isolere problemer til et bestemt segment |
Et praktisk eksempel
Dette er en tenkt inndeling, ikke skolens faktiske oppsett eller ferdige brannmurregler:
- VLAN 10: Administrasjon - Lønn, HR, ledelse. Strengt begrenset tilgang.
- VLAN 20: Ansatte - Lærere og andre ansatte. Tilgang til fellesmapper og printere.
- VLAN 30: Elever - Kun internettilgang og læringsplattformer.
- VLAN 40: IoT - Printere, smartskjermer, kameraer. Ingen internettilgang (eller svært begrenset).
- VLAN 50: Servere - Interne servere. Tilgang fra andre VLAN bare til avtalte tjenester.
Hva er et VLAN?
Et virtuelt lokalnett (Virtual Local Area Network, VLAN) deler en fysisk svitsj i logiske nettverk. VLAN-ID-en angir hvilket VLAN trafikken tilhører. Adgang mellom VLAN må styres i tillegg.
Video: Slik deler VLAN opp et fysisk nettverk
Videoen forklarer hvordan VLAN deler ett fysisk nettverk inn i flere logiske nettverk og skiller trafikken mellom dem.
I dette eksemplet bruker hvert VLAN et eget IPv4-subnett:
| VLAN | Navn | Subnet | Gateway |
|---|---|---|---|
| 10 | Administrasjon | 10.0.10.0/24 | 10.0.10.1 |
| 20 | Ansatte | 10.0.20.0/24 | 10.0.20.1 |
| 30 | Elever | 10.0.30.0/24 | 10.0.30.1 |
| 40 | IoT | 10.0.40.0/24 | 10.0.40.1 |
| 50 | Servere | 10.0.50.0/24 | 10.0.50.1 |
Subnetting kort forklart
Eksemplets /24-subnett har 254 vanlige vertsadresser (.1 til .254), inkludert adressen gatewayen bruker. IP og subnett forklarer beregningen; du trenger ikke regne den på nytt for brannmurøvelsen.
10.0.10.0/24gir adresser fra10.0.10.1til10.0.10.254- Gatewayen er som regel den første adressen (
.1)
Tagget vs. utagget trafikk
For at VLANer skal fungere over flere switcher (eller mellom switch og ruter), brukes tagging:
| Type | Forklaring | Bruk |
|---|---|---|
| Utagget (access) | Porten tilhører ett VLAN. Enheten vet ikke om VLAN. | PCer, printere, telefoner |
| Tagget (trunk) | Porten bærer trafikk fra flere VLAN, merket med VLAN-ID. | Mellom switcher, mot ruter |
En vanlig PC kobles gjerne til en access-port uten selv å merke trafikken med VLAN-ID. En trunk kan bære flere tillatte VLAN, ikke nødvendigvis alle. En trunk kan også ha et utagget, såkalt native VLAN. Les portprofilens faktiske oppsett før du tolker trafikkveien.
Oppgave 1 - Se VLAN i praksis
Har du tillatelse til å lese nettverksoppsettet i UniFi eller et annet verktøy, undersøker du uten å endre:
- Se på hvilke VLAN som er konfigurert
- Hvilke porter er satt som access, og hvilke som trunk?
- Sammenlign PC-ens IP-oppsett med subnett og portprofil. IP-adressen alene bekrefter ikke VLAN-tilhørigheten.
Uten administrasjonstilgang: Bruk eksempeltabellen. En klient har adressen 10.0.30.10/24 og gateway 10.0.30.1. Hvilket av eksemplets subnett passer den i, og hvilken porttype ville du valgt til en vanlig PC? Forventet svar er elevsubnettet og en access-port i VLAN 30. Dette er en tolkning av eksemplet, ikke en måling av ditt eget nett.
Brannmurregler mellom VLAN
Beskriv først hvem som skal starte en forbindelse, til hvilket mål og på hvilken protokoll/port. En generell merkelapp som «ansatte til servere» er for grov til å konfigurere direkte. Tabellen er en eksempelpolicy som må konkretiseres:
| Fra (kilde) | Til (mål) | Tillatt? | Begrunnelse |
|---|---|---|---|
| Elever | Internett | ✅ Ja | Nødvendig for undervisning |
| Elever | Serveradministrasjon | Nei | Elevtilgang til en app gir ikke rett til serveradministrasjon |
| Ansatte | Avtalte servertjenester | Avgrenset ja | Åpne bare tjenestene som trengs til arbeidet |
| IoT | Internett | ❌ Nei (eller begrenset) | IoT-enheter trenger sjelden internett |
| IoT | Elever/Ansatte | ❌ Nei | IoT skal være isolert |
| Servere | Klient som startet tillatt forbindelse | Svartrafikk | En tilstandsbasert brannmur kan tillate svar på en etablert forbindelse |
Svartrafikk betyr ikke at serveren skal få starte nye forbindelser til alle. Regler for established/related og rekkefølgen på reglene må passe brannmuren. Trafikk mellom enheter i samme VLAN går vanligvis ikke gjennom brannmuren som styrer ruting mellom VLAN.
Standard: blokker alt, tillat det du trenger
En god brannmurpolicy starter med å blokkere all trafikk mellom VLANene, og så åpner du kun det som trengs. Det er mye tryggere enn å starte med alt åpent og prøve å blokkere det du ikke vil ha.
Dette er ønsket sluttpolicy, ikke en beskjed om å slå på en bred blokkering først i et nett som er i bruk. Behold nødvendig administrasjon, DNS og DHCP mens et avgrenset testoppsett endres.
Øvelse: Klient via proxy, ikke direkte til app
Bruk disse eksempelrollene eller tilsvarende kjente verdier fra et testmiljø:
| Enhet | VLAN | Adresse og tjeneste |
|---|---|---|
| Klient | 30 | 10.0.30.10 |
| Proxy | 50 | 10.0.50.10, HTTP på TCP 80 |
| App | 50 | 10.0.50.20, HTTP på TCP 5000 |
Klienten skal få åpne appen via proxyen, men ikke direkte på app-porten. Docker Level 3 viser hvordan proxy og app settes opp og kontrolleres. Skriv planen i eget dokument:
| Kilde | Mål | Protokoll/port | Handling | Forventet kontroll |
|---|---|---|---|---|
| Klient-VLAN 30 | Proxyens adresse | TCP 80 | Tillat | Appens forventede /status-svar gjennom appnavnet |
| Klient-VLAN 30 | Appens adresse | TCP 5000 | Blokker ny forbindelse | Ingen HTTP-forbindelse direkte fra klienten |
Proxy og app ligger i samme VLAN i eksemplet. Forbindelsen mellom dem testes direkte, men er ikke styrt av disse reglene mellom VLAN. En vellykket test gjennom proxyen viser at appen var tilgjengelig denne veien; en feilet direkte test alene beviser ikke at brannmuren blokkerte riktig.
Praktisk prøve i et godkjent testmiljø
Bruk et allerede fungerende proxy-/appoppsett. Noter normaltilstand og gjeldende regler, og behold konsoll eller annen administrasjonsvei slik at endringen kan rulles tilbake. Kontroller kilde, mål, port, retning og regelrekkefølge før du endrer én avgrenset regel.
Fra klienten tester du appnavnet gjennom proxyen. For direkte app-tilgang kan du bruke:
curl --fail --show-error --connect-timeout 5 --max-time 10 http://10.0.50.20:5000/status
Adressen er fra eksemplet; erstatt den med testmiljøets appadresse. Etter blokkeringen skal denne klienten ikke få opprettet HTTP-forbindelsen. En timeout kan ha andre årsaker; sammenhold resultatet med brannmurlogg eller regelteller når verktøyet gir det, og kontroller samtidig at appen fortsatt svarer gjennom proxyen. HTTP 404 eller 500 fra app-porten viser at HTTP-forbindelsen kom fram, selv om curl --fail avslutter med feil.
Kontrollpunkt: Planlagt og faktisk tilgang
Vis begge testene med kilde, mål, forventet og faktisk resultat. Forklar regelen og hva testene bekrefter. Ved avvik undersøker du én regel eller én trafikkvei om gangen og gjentar kontrollen. Rull tilbake dersom endringen bryter nødvendig tilgang.
Har du bare brukt eksemplet, merker du resultatene som forventede og forklarer hvilke prøver som gjenstår. Da er planen klar, men implementering og faktisk virkning er ikke demonstrert. Subnettberegning og DHCP under er valgfrie utvidelser etter denne kontrollen.
Subnetting
Ny på prefiks og subnett?
🌐 IP, subnett og standard gateway forklarer hva prefikset faktisk betyr, før du bruker det til å planlegge VLAN-subnett her.
Viderevalg: Bruk IP og subnett når du skal velge et annet adresseområde. Tallene under gjelder vanlige IPv4-subnett og viser antall vertsadresser etter nettverks- og kringkastingsadressen:
| Prefiks | Nettverksmaske | Vertsadresser | Typisk bruk |
|---|---|---|---|
/24 | 255.255.255.0 | 254 | De fleste VLAN |
/25 | 255.255.255.128 | 126 | Mindre segment |
/16 | 255.255.0.0 | 65 534 | Store nettverk |
Oppgave 2 - Regn ut et subnet
Valgfri beregningsøvelse: Bruk framgangsmåten fra IP-oppslaget eller en subnettkalkulator, for eksempel subnet-calculator.com:
- Skriv inn
10.0.60.0med maske/24. Hvor mange adresser får du? - Hva skjer om du endrer til
/25? Eller/23? - Hva ville du valgt for et klasserom med 30 elever?
Kontroll: /24 gir 254 vertsadresser, /25 gir 126 og /23 gir 510. Begrunn valget ut fra alle enheter som trenger adresse, også gateway og annet utstyr; antall elever er ikke hele adressebehovet.
DHCP per VLAN
Valgfritt oppslag: Klienter som skal få IP-oppsett automatisk, trenger DHCP som gir riktig oppsett for subnettet. Statiske adresser trenger ikke DHCP. Nettverkstjenester og serverroller forklarer DHCP og reservasjon.
Eksempel for Elev-VLANet:
| Innstilling | Verdi |
|---|---|
| Subnet | 10.0.30.0/24 |
| Gateway | 10.0.30.1 |
| DHCP-range | 10.0.30.100 - 10.0.30.250 |
| DNS | Navnetjenesten som kjenner testmiljøets interne appnavn |
Oppsummering
- Segmentering deler nettverket i deler der trafikken kan kontrolleres
- VLAN er virtuelle nettverk på samme fysiske switch
- Access-porter kobler enheter til ett VLAN, trunk-porter bærer flere VLAN
- Brannmurregler bestemmer hva som er tillatt mellom VLANene
- I eksemplet har hvert VLAN eget subnett; DHCP er aktuelt når adresser skal tildeles automatisk
- Sluttpolicy: blokker unødvendig trafikk, tillat de avtalte tjenestene
Kilder: UniFi: tilgangsregler og svartrafikk og access-/trunk-porter.