Seks måter å koble sammen kontorer og brukere på. Her ser du hvordan de virker, hva som må være på plass, og hvilke fordeler og ulemper de har i en bedrift.
Alle VPN-er lager en kryptert «tunnel» over internett. Det som skiller dem, er hva som kobles sammen: to nett, en bruker og et nett, eller en bruker og én app.
Nett til nett
Rutere eller brannmurer snakker med hverandre. Brukerne merker ingenting. Typisk: IPsec og SD-WAN.
Bruker til nett
Brukeren får en adresse «inne» i nettet og når i utgangspunktet alt. Typisk: SSL/TLS-VPN, IPsec med klient.
Bruker til app
Brukeren slipper bare inn til appene policyen tillater. Resten av nettet er usynlig. Typisk: ZTNA.
Se forskjellen
Fem typer i samme oppsett. Velg en type og se hvor tunnelen går, og hva brukeren faktisk når.
IPsec site-to-site
Vanlig trafikkKryptert i tunnelen
To kontorer kobles fast sammen. Gatewayene bygger tunnelen, og trafikken mellom sitene krypteres automatisk. PC-er og servere vet ikke at VPN-en finnes.
Én bruker kobler seg til bedriften med en VPN-klient på PC-en. Når tunnelen er oppe, er PC-en i praksis «på kontoret» og kan nå alt der. Kalles også client VPN eller client-to-site.
Hver site har flere linjer, og edge-en bygger tunneler over alle. En sentral controller bestemmer hvilken linje hver app skal bruke, og flytter trafikken når en linje faller ut eller blir dårlig.
Brukeren får aldri adgang til nettet – bare til de appene hen har lov til å bruke. Hver tilkobling sjekkes mot identitet og enhet, og alt annet er usynlig.
Alle siter har en fast tunnel til hubben. Når to siter skal snakke sammen, går første pakke via hubben, og så setter de opp en direkte tunnel seg imellom ved behov.
Den klassiske måten å koble to kontorer sammen på. Brannmuren eller ruteren i hver ende setter opp en kryptert tunnel, og trafikken mellom nettene går gjennom den. IPsec er en åpen standard, så brannmurer fra ulike leverandører kan snakke sammen, også med en tunnel i skyen.
Slik setter to rutere opp tunnelen
Bli enige: A foreslår kryptering og Diffie-Hellman-gruppe. B velger et forslag den også støtter. Med Diffie-Hellman regner begge ut den samme hemmelige nøkkelen uten at den noen gang sendes over nettet.
Bevis hvem dere er: Nå er praten kryptert. Hver side viser identiteten sin med en delt nøkkel (PSK) eller et sertifikat. De blir også enige om hvilke nett som skal gjennom tunnelen (traffic selectors).
Send data: Pakkene pakkes inn i ESP og sendes. Nøklene byttes jevnlig (rekey), og «er du der?»-meldinger (DPD) oppdager om motparten har falt ut.
Hva skjer med pakken?
To måter å styre hva som går i tunnelen
Policy-basertEn regel (ACL) sier «trafikk fra 10.1.0.0/24 til 10.2.0.0/24 skal krypteres». Enkelt for én tunnel, men hvert nytt nett krever nye regler i begge ender, og du kan ikke kjøre rutingprotokoller.
Rute-basert (VTI)Tunnelen blir et eget grensesnitt, og du ruter trafikk inn i det med statiske ruter, BGP eller OSPF. Gir enkel redundans med to tunneler og nye nett uten å røre IPsec-oppsettet. Tunnelgrensesnittene trenger gjerne et eget /31-linknett.
Må være med
Motpartens offentlige IP-adresse (eller DNS-navn), og at den kan nås.
Like forslag i begge ender, både for IKE og for selve tunnelen (Child SA/ESP): kryptering, integritet, DH-gruppe og levetid. Hvis én side bruker PFS, må begge gjøre det. Bruk for eksempel AES-256-GCM, SHA-256 og DH-gruppe 19, 20 eller 14. Unngå DES/3DES, MD5, SHA-1 og DH-gruppe 1, 2 og 5.
Samme PSK eller gyldige sertifikater, og riktig IKE-ID i hver ende. ID-en glemmes ofte når en side står bak NAT.
Traffic selectors som speiler hverandre (A sier «mine → dine», B sier «dine → mine»), eller VTI med ruter i begge ender.
Åpent i brannmuren: UDP 500, UDP 4500 og IP-protokoll 50 (ESP).
Fordeler for bedriften
Åpen standard: fungerer mellom ulike leverandører, skyleverandører og partnere.
Innebygd i nesten alle brannmurer og rutere. Ingen ekstra lisens.
Alltid på: brukerne gjør ingenting. Kontoret er «på nettet» så lenge linja er oppe.
Rask: mange brannmurer krypterer i maskinvare.
Ulemper
Mange parametere som må stemme helt. Én feil gir en tunnel som ikke kommer opp, ofte med en vag feilmelding.
Skalerer dårlig i full mesh: 20 kontorer som skal nå hverandre direkte trenger 190 tunneler.
Ingen kjennskap til apper: velger ikke beste linje for Teams og er ikke laget for flere linjer.
Gir tilgang til hele nett hvis du ikke strammer inn med brannmurregler.
Passer når: noen få faste kontorer, kobling til sky (Azure, AWS) eller til en partner, og som reserve eller grunnmur under det meste annet.
SSL/TLS-VPN (remote access)
TLS over TCP 443 · DTLS over UDP 443 · klient på PC-en
Den vanligste måten å la ansatte jobbe hjemmefra på. En klient på PC-en kobler seg til en VPN-gateway på port 443, samme port som vanlige nettsider. Derfor kommer den gjennom nesten alle nett, også på hotell og mobil. Brukeren får en intern IP-adresse og kan jobbe som om hun satt på kontoret.
Koble til: Klienten åpner en TLS-forbindelse til gatewayen på port 443 og sjekker at gatewayens sertifikat er ekte.
Logg inn: Brukeren logger inn, helst via bedriftens identitetsleverandør (SAML eller OIDC) med MFA. RADIUS og LDAP er eldre alternativer.
Sjekk enheten (valgfritt): Gatewayen kan kreve at PC-en er bedriftens egen, er oppdatert og har antivirus. Dette kalles posture.
Få adresse og ruter: PC-en får et virtuelt nettkort med en IP-adresse fra en pool, DNS-servere og en liste over hvilke nett som skal gå i tunnelen.
Send trafikk: Helst over DTLS (UDP), som er raskere. Er UDP blokkert, faller klienten tilbake til TLS over TCP.
Split tunnel eller full tunnel?
Split tunnelBare trafikk til interne nett går i tunnelen. Teams, YouTube og Microsoft 365 går rett ut. Det sparer linja hjem og gir bedre lyd og bilde, men du ser og filtrerer ikke brukerens internettrafikk.
Full tunnelAll trafikk går hjem og ut gjennom bedriftens brannmur. Det gir full kontroll og logging, men linja og gatewayen må tåle all trafikken, og skytjenester får en omvei.
Hvorfor DTLS? (TCP-i-TCP-problemet)
Kjører tunnelen over TCP, og brukeren også bruker TCP inni, har du to lag som begge sender på nytt når en pakke forsvinner. Ved litt pakketap kan de forsterke hverandre, så farten faller kraftig. DTLS er TLS over UDP, og da er det bare det indre laget som sender på nytt.
Må være med
Gyldig TLS-sertifikat på gatewayen fra en offentlig CA, med samme navn som klienten kobler til. Ellers advarer klienten, eller den nekter å koble til.
Kobling til brukerkatalogen (IdP via SAML eller OIDC, eller RADIUS/LDAP) og MFA. Uten MFA er et stjålet passord nok til å komme inn.
En IP-pool som ikke overlapper med interne nett eller vanlige hjemmenett. Unngå 192.168.0.0/24 og 192.168.1.0/24.
Returrute: interne nett må vite at pool-en (f.eks. 10.99.0.0/24) nås via gatewayen.
DNS: interne DNS-servere og domenesuffiks, ellers virker IP-adresser men ikke navn.
Brannmurregler fra pool-en til de interne nettene brukerne skal nå.
Klienten installert og oppdatert på hver PC.
Fordeler for bedriften
Kommer gjennom nesten alt, siden port 443 sjelden er blokkert.
Brukerstyrt: tilgang etter gruppe i brukerkatalogen, med MFA og enhetssjekk.
Velkjent og modent: de fleste IT-avdelinger kan det, og det støtter alle typer apper og protokoller.
Ofte inkludert i brannmuren du allerede har.
Ulemper
Gatewayen står åpen mot internett. SSL-VPN-bokser har de siste årene vært blant de mest angrepne enhetene, og flere alvorlige sårbarheter er utnyttet før oppdatering fantes. Den må patches raskt.
For bred tilgang: en kompromittert PC kommer ofte til hele nett og kan bevege seg videre derfra (lateral bevegelse).
Flaskehals: gatewayen og linja hjem begrenser når alle jobber hjemme samtidig.
Leverandørspesifikk klient og ofte lisens per samtidig bruker.
Passer når: ansatte trenger bred tilgang hjemmefra, mange eldre apper skal virke uten tilpasning, eller ZTNA ikke takler en bestemt protokoll.
SD-WAN
overlay over flere linjer · sentral kontroller · valg av linje per app
SD-WAN er ikke én protokoll, men en måte å drive hele bedriftsnettet på. Hvert kontor får en edge-boks koblet til flere linjer, for eksempel fiber og 4G/5G. Boksene bygger krypterte tunneler (som regel IPsec) over alle linjene. En sentral kontroller bestemmer hvilken linje hver app skal bruke, og boksene måler linjene hele tiden og bytter på sekunder når en linje blir dårlig.
Plugg inn: Edge-boksen kobles til linjene, finner kontrolleren og henter sitt eget oppsett automatisk. Dette kalles zero-touch provisioning, og ingen trenger å reise ut for å konfigurere.
Bygg overlay: Boksen setter opp krypterte tunneler til hovedkontor og andre kontorer over alle linjene. Tunnelene kalles overlay, og de fysiske linjene under kalles underlay.
Mål: Små testpakker måler forsinkelse, jitter og pakketap på hver linje, hele tiden.
Velg linje per app: Boksen kjenner igjen appene og sender hver over linja som oppfyller kravet i policyen. Teams trenger lav forsinkelse, mens backup bare trenger kapasitet.
Lokal breakout: Trafikk til Microsoft 365 og andre skytjenester går rett ut på internett fra kontoret, i stedet for omveien via hovedkontoret.
Må være med
Minst én linje med internett på hvert sted. To ulike linjer, for eksempel fiber og 4G, gir den virkelige gevinsten.
Kontakt med kontrolleren (i skyen eller egen drift), og at boksen er registrert der med serienummer eller sertifikat og lisens.
Policy: hvilke apper som er viktige, og hvilke krav de har til forsinkelse og tap.
Tilkobling til resten av nettet: ruting mot LAN og datasenter, ofte med BGP eller OSPF, og en plan for overgangen fra gammelt WAN.
Sikkerhet for lokal breakout: brannmur i boksen eller en sikkerhetstjeneste i skyen. Kontoret går rett ut på internett, ikke via hovedkontorets brannmur.
Fordeler for bedriften
Billigere linjer: vanlig internett og 4G/5G kan erstatte dyre MPLS-samband.
Robust: faller en linje ut, flyttes trafikken på sekunder uten at brukerne merker det.
Sentral styring: én policy for 5 eller 500 kontorer, og nye kontorer kommer raskt i drift.
Innsyn: du ser hvilke apper som bruker linjene, og hvor godt de fungerer.
Ulemper
Leverandørlåsing: ulike SD-WAN-løsninger snakker ikke sammen, så å bytte betyr å bytte alle boksene.
Løpende kostnader: som regel abonnement per boks og båndbredde.
Mer å forstå ved feil: du må feilsøke både overlay og underlay, og kontrolleren er en kritisk del.
Lokal breakout flytter sikkerheten ut til hvert kontor eller til skyen. Ofte ender det med SASE (SD-WAN + sikkerhet fra skyen).
Passer når: mange avdelinger, flere linjer per sted, mye bruk av skytjenester, eller når MPLS-avtalen skal fornyes.
ZTNA (Zero Trust Network Access)
tilgang per app · identitet + enhet · ingen åpne porter inn
ZTNA snur tankegangen. I stedet for å slippe brukeren inn i nettet og stole på henne der, får hun tilgang til én app om gangen, og bare etter at både hvem hun er og hvilken enhet hun bruker er sjekket. Prinsippet kalles zero trust: ingen er klarert bare fordi de er «innenfor».
Connectoren ringer ut: En liten connector inne ved appene (i datasenteret eller i skyen) kobler seg utgående til megleren. Ingen porter trenger å stå åpne innover, så appene er usynlige fra internett.
Brukeren logger inn via bedriftens identitetsleverandør med MFA, enten med en agent på PC-en eller bare i nettleseren.
Megleren sjekker hvem brukeren er, hvilken gruppe hun er i, om PC-en er bedriftens og oppdatert, og eventuelt sted og tid. Alt holdes opp mot policyen for akkurat den appen.
Forbindelsen sys sammen: Er alt i orden, kobler megleren brukeren til appen via connectoren. Hun når bare den appen og den porten, ikke nettet rundt.
Løpende kontroll: Endrer noe seg, for eksempel at antivirus slås av eller brukeren blir deaktivert, kan tilgangen trekkes med en gang.
Må være med
En identitetsleverandør med brukere og grupper som er til å stole på. ZTNA er aldri bedre enn brukerkatalogen.
Oversikt over appene: navn eller IP, port og protokoll for hver, og hvem som skal ha tilgang. Dette er ofte den største jobben.
Connector(er) som når appene (DNS og ruter) og kan gå ut på 443. Bruk gjerne to for redundans.
Policy per app: hvilke grupper, hvilke enheter og hvilke krav som gjelder.
Enhetsstyring (MDM) hvis du vil kreve at enheten er bedriftens og oppdatert.
Fordeler for bedriften
Minst mulig tilgang: en kompromittert PC når bare de få appene brukeren har lov til, og ikke hele nettet.
Ingen eksponert VPN-gateway å angripe, og appene er usynlige fra internett.
Lik opplevelse hjemme, på reise og på kontoret, og ingen flaskehals i en boks på hovedkontoret.
Konsulenter og partnere kan få tilgang til én app via nettleseren, uten å installere noe.
God logging: hvem brukte hvilken app, når, fra hvilken enhet.
Ulemper
Tar tid å innføre: alle apper og tilganger må kartlegges. Mange bruker måneder på overgangen.
Ikke alt passer: trafikk som starter fra serveren mot klienten, enkelte telefoni- og fjernstyringsløsninger og eldre protokoller kan være vanskelige.
Avhengig av leverandørens sky: faller den ut, mister alle tilgangen. Trafikken går også via deres datasentre, så sjekk hvor de står (GDPR).
Abonnement per bruker, og ofte låst til én leverandør.
Passer når: brukerne trenger et kjent sett med apper, mange er konsulenter eller jobber utenfor kontoret, eller den gamle VPN-gatewayen skal fases ut. Mange beholder et lite SSL/TLS-VPN for det ZTNA ikke takler.
Også verdt å kjenne til
WireGuard
UDP · Noise · i Linux-kjernen siden 2020
En moderne, liten VPN-protokoll med få valg. Hver side har et nøkkelpar, og du lister hvilke adresser hver motpart får sende (AllowedIPs). Det er alt.
Fordeler: svært rask, enkel å sette opp, lite kode å revidere, fungerer både mellom nett og for brukere.
Ulemper: ingen innebygd brukerinnlogging, MFA eller IP-pool, så nøkler må deles ut og trekkes tilbake manuelt. Kryptografien er ikke FIPS-godkjent, noe enkelte bransjer krever.
Må være med: nøkkelpar i hver ende, motpartens offentlige nøkkel og endepunkt, AllowedIPs og én åpen UDP-port (standard 51820).
I bedrifter: ofte bygget inn i produkter som legger brukerstyring oppå.
Dynamiske tunneler (hub-and-spoke)
IPsec / IKEv2 · hub-and-spoke med direkte tunneler ved behov
Løser full mesh-problemet: avdelingene har bare en fast tunnel til hovedkontoret (hub-and-spoke). Når to avdelinger skal snakke sammen, får de vite om hverandre via hub-en og setter opp en direkte tunnel ved behov. Prinsippet er det samme hos alle, men hver leverandør har sin egen variant.
Fordeler: skalerer til hundrevis av kontorer, ny avdeling krever ingen endring på hub-en, og rutingprotokoller kjører over tunnelene.
Ulemper: virker bare mellom utstyr fra samme leverandør, og krevende å feilsøke. I nye prosjekter er det ofte erstattet av SD-WAN, som bruker samme idé.
Må være med: hub med fast adresse, IPsec-profil, oppsett for direkte tunneler mellom avdelingene og en rutingprotokoll (ofte BGP) over tunnelene.
Dette må være på plass – uansett type
Når en VPN «ikke virker», er det nesten alltid ett av disse punktene. Gå gjennom dem i rekkefølge.
Endepunktene når hverandre. Minst én side må kunne nås fra internett, med fast IP eller et DNS-navn som holdes oppdatert (DDNS). Står begge bak NAT, må én av dem alltid starte forbindelsen.
Brannmuren slipper VPN-trafikken inn på riktige porter og protokoller (se tabellen under), både hos deg og hos eventuelle mellomledd.
Begge sider er enige om krypteringen. Ett felles forslag holder, men det må finnes.
Begge sider beviser hvem de er med delt nøkkel, sertifikat eller brukerinnlogging. Sertifikater krever riktig klokke (NTP) og at utstederen er klarert.
Ruting begge veier. Hver side må vite at motpartens nett ligger bak tunnelen. Den vanligste feilen er manglende returrute: pakken kommer frem, men svaret går ut feil vei.
Ingen overlappende adresser. Bruker begge kontorer 192.168.1.0/24, vet ingen hvor pakken skal. Da må du endre adressene eller bruke NAT i tunnelen.
Regler for trafikken inne i tunnelen. At tunnelen er oppe betyr ikke at brannmuren slipper trafikken gjennom.
MTU og MSS er justert, ellers henger store pakker. Ping virker, men nettsider og filoverføring stopper opp.
For brukere: IP-pool, DNS for interne navn og en liste over hvilke nett som skal gå i tunnelen.
Begge rutene må finnes. Mangler B sin rute, kommer forespørselen frem, men svaret sendes ut på internett i stedet for gjennom tunnelen og forsvinner.
Porter som må være åpne
Type
Porter og protokoller
Merk
IPsec
UDP 500, UDP 4500, IP-protokoll 50 (ESP)
ESP er en egen protokoll, ikke en port. Med NAT på veien pakkes ESP inn i UDP 4500 (NAT-T).
SSL/TLS-VPN
TCP 443, UDP 443 (DTLS)
OpenVPN bruker UDP 1194 som standard, men kan kjøre på TCP 443.
SD-WAN
Varierer med leverandør
Som regel IPsec eller DTLS over UDP, pluss kontakt med kontrolleren. Sjekk leverandørens liste.
ZTNA
Utgående TCP 443
Ingen innkommende porter, verken hos brukeren eller ved connectoren.
WireGuard
UDP 51820
Standardport, kan endres.
Dynamiske tunneler
UDP 500, UDP 4500, ESP
Som IPsec. Bruker varianten GRE inne i IPsec, trenger ikke GRE åpnes ut mot internett.
Hvor mye tunnelen spiser av pakken
Innkapsling
Ekstra byte
Typisk MTU inne i tunnelen
GRE
24
1476
IPsec ESP (tunnel, AES-GCM)
ca. 55–75, mer med NAT-T
1400 er et trygt valg
GRE over IPsec
ca. 80–100
1400
WireGuard
60 over IPv4, 80 over IPv6
1420 (standard)
SSL/TLS-VPN
varierer
settes av gatewayen, ofte 1300–1400
Tommelfingerregel: sett MTU 1400 på tunnelgrensesnittet og TCP MSS 1360 (MTU minus 40 byte for IP- og TCP-hodet). Da slipper du at store pakker forsvinner når ICMP er blokkert et sted på veien.
Ord du møter
Tunnel
En pakke pakket inn i en annen pakke, så den kan reise over internett mellom to punkter. Med kryptering ser ingen hva som er inni.
IKE
Internet Key Exchange. Protokollen IPsec bruker for å bli enige om krypto og nøkler. Bruk versjon 2 (IKEv2).
SA
Security Association. Avtalen mellom to parter om nøkler og kryptering. IKE SA beskytter forhandlingen, Child SA beskytter dataene.
ESP
Encapsulating Security Payload. IPsec-delen som krypterer selve dataene. Egen IP-protokoll, nummer 50.
NAT-T
NAT Traversal. Pakker ESP inn i UDP 4500 så det kommer gjennom rutere som oversetter adresser.
PSK
Pre-shared key. Et felles passord i begge ender. Enkelt, men bør være langt og tilfeldig. Sertifikater er bedre når det er mange tunneler.
Diffie-Hellman (DH)
Matematikk som lar to parter lage en felles hemmelig nøkkel uten å sende den. «Gruppen» sier hvor sterk den er.
PFS
Perfect Forward Secrecy. Nye nøkler lages helt på nytt ved hver rekey, så én lekket nøkkel ikke åpner gammel trafikk.
Traffic selectors
Hvilke nett som skal gjennom tunnelen. Må speile hverandre i de to endene.
VTI
Virtual Tunnel Interface. Tunnelen som et eget grensesnitt du kan rute til.
DTLS
TLS over UDP. Unngår TCP-i-TCP-problemet i SSL/TLS-VPN.
Split tunneling
Bare trafikk til interne nett går i tunnelen. Resten går rett ut på internett.
Overlay / underlay
Overlay er de logiske tunnelene. Underlay er de fysiske linjene de går over.
MPLS
Privat WAN-samband fra en operatør. Stabilt og med garantier, men dyrt. Det SD-WAN ofte erstatter.
Zero trust
Ingen er klarert bare fordi de er «innenfor». Hver tilgang sjekkes for seg (NIST SP 800-207).
Posture
Enhetens tilstand: er den bedriftens egen, oppdatert, kryptert og med antivirus?
IdP
Identitetsleverandør. Der brukerne og gruppene bor, og der innloggingen med MFA skjer.
SASE / SSE
SSE er sikkerhetstjenester levert fra skyen: ZTNA, webfilter og skybrannmur. SASE er SSE pluss SD-WAN.
Lateral bevegelse
En angriper som har kommet inn på én maskin, bruker den til å nå videre i nettet.
Hvordan velge?
Noen få faste kontorer, eller kobling til sky og partnere: IPsec, rute-basert, gjerne med to tunneler og BGP for redundans.
Mange avdelinger, flere linjer og mye skybruk: SD-WAN. Regn med lisenskostnaden og at du binder deg til én leverandør.
Ansatte som trenger bred tilgang hjemmefra: SSL/TLS-VPN med MFA og enhetssjekk. Hold gatewayen oppdatert, og begrens hva pool-en når.
Brukere og konsulenter som trenger et kjent sett med apper: ZTNA. Start med de viktigste appene, og flytt resten etter hvert.
Egne servere, hjemmelab eller enkel kobling mellom Linux-maskiner: WireGuard.
I praksis blir det ofte en blanding: SD-WAN eller IPsec mellom kontorer, ZTNA for brukere, og et lite SSL/TLS-VPN for det ZTNA ikke takler.