Velg rett VPN-løsning

Bruken av VPN slår om seg i stadig større grad. Denne guiden forsøker å vise vei i dagens voksende VPN-jungel.

Publisert Sist oppdatert

Overgangen fra dyre, leide linjer med konstant båndbredde til fleksible virtuelle forbindelser over pakkesvitsjede nett som Frame Relay eller ATM, har gitt oss virtuelle private nett (VPN). Flere kundenett multiplekses på en sikker måte over en felles mellomliggende infrastruktur som driftes av en tjenestetilbyder.

Det stadig sterkere innslaget av IP-teknologi i kommunikasjonsnettene har videre forflyttet VPNene over på moderne ruterplattformer. De senere årene har det fremstått flere nye varianter av slike IP-baserte VPN.

Vi skal her gi en oversikt over hvilke typer VPN som finnes, samt belyse forskjeller og likheter mellom disse. Ut fra dette vil vi også kunne se fordeler og ulemper som følger med de ulike løsningene.

For å virkelig forstå hvordan disse VPNene fungerer, kommer vi ikke unna betraktninger rundt lagdelte kommunikasjonsprotokoller. Dette gjelder både hva slags grensesnitt som tilbys til kunden, og det gjelder den interne implementasjonen av VPN-tjenestene. Det hele dreier seg om svitsjing og ruting – i store doser.

Klassifisering av VPN

De ulike VPN-typene kan klassifiseres langs to akser: Hvilke protokollag de fungerer på, og hvor tjenesten implementeres – i tilbyderens nett eller i kundens eget nett.

For det første skiller man mellom Lag 2 VPN (L2VPN) og Lag 3 VPN (L3VPN). Det protokollaget det er snakk om her, er hvilket lag kundens trafikk opererer på idet det overleveres til tilbyderens nettverk. Dreier det seg om svitsjet Ethernet-trafikk (på lag 2) eller rutet IP-trafikk (på lag 3) for eksempel?

Standardiseringen av VPN-teknologien innen IETF deles også opp på denne måten. Det finnes både en L2VPN og en L3VPN arbeidsgruppe. Begge har kommet relativt langt i standardiseringen av sine arkitekturforslag, og noen mer detaljerte spesifikasjoner begynner også å bli klare. L2VPN ser imidlertid ut til å ligge et lite skritt bak L3VPN.

Implementeringen av et VPN kan utføres av kunden selv. Alt som trengs fra en tilbyder er i så fall selve Internett-aksessen. VPNet konfigureres da i kantruteren på grensen mot Internett. Dette utstyret omtales vanligvis som Customer Edge (CE), og er i dag en innarbeidet betegnelse i bransjen.

Avhengig av kompetansen hos kunden, vil det i mange tilfeller også være aktuelt å outsource driftingen av CE-utstyret til en tjenestetilbyder. Det kan også være aktuelt at tilbyderen også står for selve utstyret og leier dette ut til kunden.

Den alternative modellen som i dag tilbys i stadig flere varianter er at hele VPN-implementasjonen ligger i tjenestetilbyderens nettverk. Kundenettverket vil dermed fungere helt uten å inneholde funksjonalitet for VPN-håndteringen.

Tjenestetilbyderen implementerer da tjenesten på kanten av sitt nettverk og tilbyr et standard grensesnitt til kundens tilknytningspunkter. Kantruterne til tilbydernettverket omtales som Provider Edge (PE). En PE-basert implementasjon av VPN betyr at utstyret må kunne håndtere flere parallelle VPN og skille trafikken i disse fra hverandre.

Lag 2 VPN

Lag 2 VPN kan deles opp i to grupper: Punkt-til-punkt-nettverk og punkt-til-multipunkt-nettverk. Disse gruppene har fått de offisielle betegnelsene Virtual Private Wire Service (VPWS) og Virtual Private LAN Service (VPLS).

VPWS

Virtual Private Wire Service minner sterkt om de tradisjonelle ATM- og Frame Relay-baserte VPN-løsningene. Kundene tilbys et sett med emulerte wirer (tilsvarer virtuelle forbindelser) som knytter sammen kundenes ulike lokasjoner. VPWS vil fungere som en elegant erstatning for nettopp disse tradisjonelle løsningene for kunder som migrerer over til IP-basert transport.

For tjenestetilbyderne betyr dette at man kan flytte slike pakkesvitsjede virtuelle forbindelser over på én felles IP-basert infrastruktur. Man slipper dermed å drifte flere parallelle nett med ulike teknologier.

De emulerte wirene implementeres ved hjelp av tunnelering. Tunneleringen vil vanligvis realiseres som en IP/MPLS-løsning. En emulert wire tilsvarer da en Label Switched Path (LSP) i MPLS-nettet. Med mange kunder knyttet til et slikt tilbydernett, blir det mange LSPer å administrere.

For at denne metoden skal skalere til store nettverk, er begrepet pseudowire innført. En LSP, eller en LSP-tunnel som den kalles i en slik sammenheng, benyttes her som en felles ressurs til å multiplekse flere pseudowirer på.

Dette gjøres ved å benytte to MPLS-labler til å styre trafikken. Den ytre labelen identifiserer tunnelen, mens den indre identifiserer pseudowiren. PE-ruterne må kunne håndtere begge lablene, mens de mellomliggende ruterne svitsjer trafikken kun basert på den ytre labelen.

Oppkoblingen av pseudowirene kan utføres enten med LDP (Martini-varianten) eller BGP (Kompella-varianten). LDP (Label Distribution Protocol) ser den protokollen som vanligvis brukes til å koble opp MPLS-stier. BGP (Border Gateway Protocol) er den velkjente interdomene rutingprotokollen. Men i dette tilfellet dreier det seg om en utvidelse av protokollen som kalles multiprotokoll-BGP som kan transportere med seg ulike typer tilleggsparametere.

Kompella-varianten har den smarte effekten at den i tillegg til å signalere oppkoblingen av stiene, også kan automatisk distribuere informasjon om de ulike VPNenes lokasjoner mellom PE-ruterne. Det blir derfor tilstrekkelig å konfigurere de lokale tilknytningene av VPNet ved CE-PE-forbindelsene. Deretter vil informasjonen om dette automatisk spres til de andre PE-ruterne som har tilknytning til samme VPN.

VPLS

Virtual Private LAN Service gir en Ethernet-aktig tjeneste gjennom tilbydernettet. Denne emulerer en punkt-til-multipunkt-forbindelse mellom de ulike lokasjonene til et VPN. For å få dette til, opprettes et maskenett av pseudowirer mellom PE-nodene.

Hver PE-node utfører MAC-adresselæring på samme måte som en Ethernet-bro eller Ethernet-svitsj. Lag 2-trafikken til kundene videresendes så over de aktuelle pseudowirene. Sett fra kundens tilknyttede nettverk opptrer tilbydernettet som om det var en lag 2-svitsj.

Den store forskjellen fra vanlig Ethernet at rekkevidden til den emulerte LAN-tjenesten er like stor som en WAN-tjeneste. Samtidig kan kundens nettverk kobles til uten tanke på rutingprotokoller og liknende.

For å forhindre at trafikken går i løkker i tilbydernettverket, samtidig som man ikke ønsker å kjøre spanning tree-algoritmen i dette store nettverket, benyttes split horizon. Dette består i at en PE-node som tar imot trafikk fra en pseudowire, aldri videresender denne ut på andre pseudowirer.

Også for VPLS står valget mellom LDP og BGP for etablering av pseudowirene. IETF har foreløpig hatt en agnostisk holdning til dette og overlater til markedskreftene å avgjøre hva som er den beste metoden.

Det kan synes mest naturlig å bruke BGP for labeldistribusjon i og med at BGP også støtter autokonfigurering. Men på den annen side brukes LDP allerede av MPLS-utstyret for den grunnleggende MPLS-funksjonaliteten.

IPLS

Når man betrakter skaleringsevne til en VPLS-implementasjon, er det største problemet MAC-tabellene. Kravet til prosessering og i særdeleshet minneforbruket er stort dersom mange VPN tilknyttes samme PE-node.

En spesialløsning for VPLS som kalles IP-only LAN-like Service (IPLS) fjerner dette skaleringsproblemet. IPLS tillater kun overføring av IP-trafikk i VPNet, noe som nå til dags ofte vil være tilstrekkelig.

I praksis implementeres IPLS ved at CE-utstyret er IP-rutere (og ikke lag 2-svitsjer). MAC-adressene som blir synlige for PE-nodene i dette tilfellet begrenses dermed til å omfatte kun CE-nodenes. Resultatet av dette er at MAC-tabellene blir vesentlig mindre.

IPLS krever på den annen side at kunden kjører en eller annen rutingprotokoll (OSPF for eksempel) i full maskekonfigurasjon over VPNet for å kunne rute trafikken til riktig CE-node. Selv om dette smaker av lag 3, er dette et lag 2-VPN fordi CE-ruterne kun snakker på lag 2 mot selve VPN-utstyret til tjenestetilbyderen.

Lag 3 VPN

L3VPN arbeidsgruppen har sett på tre ulike lag 3 VPN-arkitekturer. Disse består av to ulike PE-baserte løsninger, henholdsvis IP-VPN som benytter BGP/MPLS og IP-VPN som benytter virtuelle rutere. Dessuten innbefatter arbeidet deres CE-baserte VPN som benytter IPsec.

BGP/MPLS

I og med at IP-VPN som benytter BGP/MPLS er en lag 3-teknologi, baserer denne seg på utveksling av IP-rutinginformasjon. Dette kan enten settes opp som en statisk konfigurasjon på CE-PE-sammenknytningene, eller det kan utveksles dynamisk med en rutingprotokoll (typisk BGP).

Innad i det enkelte VPN i tilbydernettet spres rutinginformasjonen og lablene for MPLS-stiene med BGP-protokollen. Det kan enten benyttes maskekonfigurasjon av BGP-forbindelser, eller en sentral rutereflektor. Rutinginformasjonen holdes atskilt per VPN, slik at også overlappende private IP-adresser kan brukes i de ulike VPNene.

Et poeng med distribusjonen av VPNenes rutinginformasjon er at denne kun distribueres mellom PE-ruterne. De indre ruterne i tilbydernettet trenger kun å kjenne den interne topologien til sitt eget kjernenett. VPN-trafikken videresendes jo her ved hjelp av MPLS-lablene.

Denne VPN-tilnærmingen har eksistert en stund (RFC 2547), men er under videreutvikling hos L3VPN-arbeidsgruppen.

Virtuelle rutere

Den alternative IP-VPN-implementasjonen baserer seg på såkalte virtuelle rutere. Disse fungerer ved at PE-nodene emulerer ruterfunksjonen for hvert enkelt VPN. De virtuelle ruterne er logisk sett isolert fra hverandre slik at de ikke kan komme i kontakt med virtuelle rutere fra andre VPN, selv om disse skulle eksekvere på samme PE-node.

De ulike virtuelle ruterne som hører til samme VPN oppretter tunneler til hverandre gjennom tilbydernettet. De ulike VPNene kan benytte standard rutingprotokoller. Til forskjell fra dette benytter BGP/MPLS-metoden seg av en tilleggstransport (piggybacking) av VPN-medlemskapsinformasjon sammen med rutinginformasjonen.

Forskjellen mellom disse to L3VPN-løsningene er ikke så stor. BGP/MPLS-metoden benytter altså én felles BGP-instans for alle VPNene. Virtuelle rutere benytter derimot en egen rutingprotokollinstans for hvert enkelt VPN. De ulike VPNene kan i dette tilfellet til og med benytte forskjellige rutingprotokoller.

Ulempen med virtuelle rutere er at disse må ha separate tunneler seg imellom, mens BGP/MPLS-metoden benytter felles tunneler mellom PE-nodene. Mange tunneler fører til begrensninger i skalerbarheten.

IPsec

Den tredje typen L3VPN hører til de CE-baserte løsningene. Dette er den velkjente IPsec-tunneleringen som kan benyttes mellom ulike lokasjoner over det åpne Internett. VPNet kan dermed kontrolleres helt og holdent av bedriften selv, eller man kan engasjere tjenestetilbyderen til å administrere dette for seg.

IPsec har nokså nylig fått en oppussing og fremstår i ny versjon. Endringene er særlig merkbare for administrasjonsprotokollen Internet Key Exchange (IKE). IKE står for etableringen av sikkerhetsassosiasjonene. IKEv2 er forenklet i forhold til sin forgjenger.

Det stilles også visse forventninger til PKI-4-IPsec arbeidsgruppen i IETF. Her ser man på bruken avdigitale sertifikat og PKI-løsninger for IPsec-baserte VPN. Det utarbeides sertifikatprofiler som passer for IKEv1 og IKEv2. Gruppen ser også på metoder for sertifikatadministrasjon og livssyklushåndtering.

Hva med SSL/TLS?

Når vi kommer til SSL/TLS, er vi over i en helt annen anvendelse av VPN-teknologien. Til nå har vi sett på sammenknytningen av ulike nettverk gjennom et VPN. Men VPN-betegnelsen brukes også om tilknytningen av enkeltmaskiner over det åpne Internett mot et lukket nettverk.

Til dette formålet er det to hovedkandidater: IPsec eller SSL/TLS. IPsec-løsningen er tilsvarende den vi har sett på for nettverkssammenknytning. Men administrasjonen av dette er en større utfordring når vi snakker om enkeltmaskiner.

Vi får typisk et større antall maskiner å håndtere i motsetning til et begrenset antall rutere, såkalte sikkerhetsgatewayer. Og vi får en annen plattform å forholde oss til. PCene må ofte utstyres med egen VPN-klientprogramvare og tilhørende konfigurering må utføres.

Det er her SSL/TLS-løsningen kommer oss til unnsetning. Klientprogramvaren består i dette tilfellet av selve nettleseren som allerede er SSL/TLS-kapabel. Og når vi hele tiden har sammenlignet de ulike VPN-arkitekturene ut fra lagdelte kommunikasjonsprotokoller, må vi også ta med at SSL/TLS er en lag 4-teknologi.

VPN-gatewayene består i dette tilfellet av en slags proxyløsning som kan konvertere mellom HTTP/TLS-kommunikasjon på Internett-siden og andre applikasjonslagsprotokoller på intranettsiden. Da er vi ved utfordringen for denne VPN-teknikken. Det må finnes støtte for de aktuelle applikasjonene i VPN-gatewayen.

IPsec er en mer elegant løsning i og med at den er lagt til IP-laget. Det er jo dette laget som gir oss den felles kommunikasjonsplattformen som har æren for nettverkskonvergensen som vi elsker.