Konfigurasjon av et Virtuelt Privat Nett

 452 total views,  1 views today

Et Virtuelt Privat Nett (VPN) er en beskyttet sammenkopling av lokale nett eller enkeltmaskiner. Typiske anvendelser for et VPN er:

  • Bruk av bedriftens it-ressurser utenfor bedriftens lokaler, på reise eller hjemmefra
  • Beskyttet kommunikasjon mellom samarbeidende bedrifter, f.eks. mellom apotek og legekontor
  • Adgang til felles laboratorium for samarbeidende bedrifter som ikke skal ha adgang til hverandres nettverk

Denne artikkelen vil forklare hvordan VPN kan inngå i flere typer nettverksanvendelser og hvordan programmet OpenVPN kan konfigureres i hvert enkelt tilfelle.

Tunnel-prinsippet

Om jeg vil sende et brev, men ikke ønsker at postverket skal vite hvem jeg sender det til, kan jeg levere brevet til budkontor som pakker brevet i en ekstra konvolutt som adresseres til et annet budkontor. Det mottagende budkontoret vil åpne den ytterste konvolutten og besørge leveringen av selve brevet. Budkontoret har ikke en landsdekkende transporttjeneste, kun lokal levering, men kan på denne måten by på landsdekkende brevtjeneste, og postverket vil ikke vite hvem som er de egentlige avsendere og mottakere.

Det samme prinsippet kan brukes for å beskytte sendinger mellom to datamaskiner mot innsyn og endring. Ved å sende IP-pakkene via to maskiner som mellom seg utveksler dataene i en kryptert form og lagt i en egen “konvolutt”, kan dette fortone seg som å sende data via en tunnel som ikke har noen forbindelse med overflaten over. Ingen på bakken over tunnelen kan se eller endre hva som beveger seg gjennom tunnelen.

Figur 1 viser hvordan en tunnel kan fremstilles som et rød forbindelse inne i en sort forbindelse. Dette er analogt med den tidligere beskrivelsen av en konvolutt (rød) som legges i en ny konvolutt (sort). Adressene på den indre konvolutten kalles røde endepunkter, og adressene på den ytre kalles sorte endepunkter. Sorte endepunkter er de “offentlige” IP-adressene, mens de røde er private adresser som ikke er synlig for omverdenen.

Figur 1: En “rød” IP-forbindelse inne i en “sort” ip-forbindelse

Hvorfor bruker vi OpenVPN i stedet for IPSec?

Det finnes flere typer VPN-protokoller som kan brukes til formålene listet opp ovenfor. De to mest kjente kalles IPSec og OpenVPN. Denne artikkelen vil beskrive bruk av OpenVPN fremfor IPSec av disse grunner:

  • OpenVPN er enklere å konfigurere, især på Windows
  • Det er enklere å sette opp rutingtabeller for OpenVPN
  • OpenVPN gir mulighet for å sette opp såkalte linklags-tunneler

Mens det finnes mange omfattende beskrivelser av alle konfigurasjonsmuligheter i OpenVPN, vil denne artikkelen beskrive 3 typiske scenarier for bruk av VPN, og hvordan OpenVPN kan konfigureres for å realisere disse.

Hvor finnes programvaren?

OpenVPN er gratis programvare (Open Source), og finnes for Windows, Linux, IOS, Android m.m. Kun versjoner for Linux og Windows er testet for denne artikkelen, og eksemplene som er vist er utviklet på Linux og siden verifisert på Windows. Erfaringsmessig er Linux mer fleksibelt enn Windows for tjener-anvendelser, så funksjonene på tjenersiden bør realiseres på Linux.

Oppstart av programvaren er forskjellig på Windows og Linux: Fra Windows høyreklikker man på tray-ikonet og velger “connect”, på Linux skriver man
$ sudo openvpn <konfigurasjonsfil>

For installasjon på linux: $ sudo apt-get install openvpn

For installasjon på Windows:

https://www.ovpn.com/no/guides/windows-openvpn-gui

Installere programmet som vanlig, programmet starter automatisk etterpå. Ingen GUI-vindu vises, men et “tray-ikon” dukker opp nede til høyre. Det ser ut som en skjerm med hengelås på. Høyreklikk på dette ikonet og velg “settings”, deretter fanen “advanced”. For “Configuration files”, velg en egnet katalog (de foreslåtte verdiene er ok), her vil nøkkel- og konfigurasjonsfiler legges. Denne mappen vil vi heretter kalle konfigurasjonsmappen. Velg så en underkatalog “log” for loggfiler. 

Tre typiske scenarier

Tre varianter av VPN-konfigurasjoner vil dekke et stort antall bruksområder. Disse tre er:

  1. Nett-til-nett, hvor to private lokalnett blir koplet sammen gjennom en beskyttet tunnel som om det sto en vanlig ruter mellom dem.
  2. Road warrior, hvor mange klienter kan kople seg til et lokalnett mens de er hjemme eller på reise. Også kalt host-til-nett.
  3. Felles subnett, hvor et antall maskiner koples sammen som ett subnett, som om de er tilkoplet samme Ethernet-switch.

1. Nett-til-nett VPN

Figur 2 viser hvordan en OpenVPN-tunnel kan inngå i et nett-til-nett VPN. Green og Blue er to rutere som har en ubeskyttet forbindelse mellom seg, f.eks. gjennom Internet, og de har IP-adressene 9.8.7.6 og 4.5.6.7. Ruterne har OpenVPN programvare og kan sette opp en beskyttet tunnel mellom seg i form av en link og tunnelen har en selvvalgt subnett-adresse. Subnett-adressen velges fritt blant private IP-adresser som ikke finnes på nettet, f.eks. innenfor 10.0.0.0/8 eller 192.168.0.0/16. I det valgte eksemplet har tunnelen adressen 192.168.3.0/30, med 192.168.3.1 i venstre ende (Green) og 192.168.3.2 i høyre enden (Blue).

Tilkoplet ruterne Green og Blue finnes lokalnettene 10.1.0.0/16 og 10.2.0.0/16. Det er tunnelens oppgave å sørge for at maskiner på disse lokalnettene kan nå hverandre.

Figur 2: Nett-til-nett konfigurasjon av et VPN

Innsiden av en tunnel blir ofte kalt Rød side og merkes med rød farge på tegninger. Den røde siden er beskyttet fra omverdenen ved at trafikken er kryptert og pakket inn i en ekstra IP-pakke slik som vist på Figur 1.

Tunnelen settes opp ved å lage konfigurasjonsfiler og en felles krypteringsnøkkel på ruterne. Slik kan konfigurasjonsfilene se ut på henholdsvis Green og Blue:

Green:Blue:
dev tun
remote 4.5.6.7
secret greenblue.key
ifconfig 192.168.3.1 192.168.3.2
route 10.2.0.0 255.255.0.0
dev tun
remote 9.8.7.6
secret greenblue.key
ifconfig 192.168.3.2 192.168.3.1
route 10.1.0.0 255.255.0.0
Tabell 1: Konfigurasjonsfiler for Green og Blue

Krypteringsnøkkelen som skal brukes skal genereres med denne kommandoen

$ openvpn --genkey --secret greenblue.key

og overføres til den andre maskinen på en beskyttet måte, f.eks. med scp. Filen må ligge i samme katalog som konfigurasjonsfilen. Gitt at konfigurasjonsfilen på begge sider heter greenblue.conf startes nå tunnelen med Linux-kommandoen (må gjøres i begge ender)

$ sudo openvpn greenblue.conf

Resultatet på begge ruterne er at det nå oppstår et nytt adapter kalt tun0 (kan vises med kommandoen $ ip a) med adressene 192.168.3.1 og 192.168.3.2. Green og Blue kan “pinge” hverandre på disse adressene.

Tips til inspeksjon: Studere trafikken (med f.eks. tcpdump) som går mellom tun0-adaptrene mens det pinges, og notere at denne trafikken går i klartekst. Studere så trafikken mellom deres ytre adaptre (de med adresser 4.5.6.7 og 9.8.7.6) og legg merke til at den består av UDP-segmenter til port 1194 med kryptert innhold.

Demonstrasjonsvideoer: Linux til Linux forbindelse

Linux til Windows forbindelse

Ruting mellom lokalnettene

Vi forutsetter at Green og Blue begge er konfigurert til å rute IPv4-pakker. De må nå kunne rute trafikk mellom lokalnettene, dvs. at trafikk fra Green til 10.2.0.0/16 skal rutes via 192.168.3.2. Dette besørges av linjen “route 10.2.0.0 255.255.0.0” i konfigurasjonsfilen, som setter opp en linje i rutingtabellen med nettopp denne opplysningen. Det tilsvarende skjer i Blue.

Alle maskinene i lokalnettet 10.1.0.0/16 må også vite om at ruten til 10.2.0.0/16 går via Green’s IP-adresse (la oss anta at dette er 10.1.0.1). OpenVPN har ingen kommunikasjon med disse maskinene, så slik rutinginformasjon må enten legges inn manuelt i hver enkelt maskin, eller den kan komme fra DHCP-tjeneren. Dersom programmet dnsmasq brukes for DHCP-tjenesten kan denne linjen legges inn i /etc/dnsmasq.conf:

dhcp-option=121,10.2.0.0/16,10.1.0.1

Dersom Green også har oppgaven med å kople lokalnettet til Internet vil den være default gateway for maskinene der, og da vil ingen ekstra rutinginformasjon være nødvendig. Trafikk til 10.2.0.0/16 vil sendes til samme adresse som alle andre ukjente adresser, og Green vil sørge for å vidersende gjennom tunnelen, ikke til Internet. Dette forholdet er vist for Blue på Figur 2.

Det vil være en vanlig situasjon at tunnelen mellom Blue og Green vil gå gjennom Internet, selv om den på Figur 2 later til å være en separat forbindelse. Figur 2 er utformet slik for å understreke at tunnelen kan benytte enhver kommunikasjonstjeneste for sitt formål, ikke bare Internet.

Koordinering av IP-adresser

I Internet er tildeling av IP-adresser en nøyaktig planlagt prosess, som skal sikre at adressekonflikter unngås. Ved sammenkopling av lokalnett må dette besørges uten hjelp utenfra.

Lokale nett bør tildeles såkalte private IP-adresser. Dette er adresser som aldri tildeles til noder på Internet, slik at man unngår konflikter når noder på lokalnettet skal nå noder på Internet. Private adresser ligger i adresseområdene 10.0.0.0/8, 192.168.0.0/16 og 172.16.0.0/12.

Dersom lokalnettene vist på Figur 2 har samme eller overlappende adresseområde, f.eks. 10.1.0.0/16, ville de ikke kunne koples sammen, fordi rutere bare kan rute mellom ulike subnett, ikke like. Det er vanskelig å forutse fremtidige behov for sammenkopling, og mulige adressekonflikter ved sammenkopling av private nettverk er umulig å gardere seg mot. I dette eksemplet vil det være nødvendig å endre adresseplanen på ett av lokalnettene, i beste fall ved å konfigurere DHCP-tjeneren til et annet adresseområde og så restarte alle maskinene, samt rekonfigurering av ruterporter og tjenermaskiner.

Man kan derimot redusere sannsynligheten for at slike situasjoner oppstår ved å velge “uvanlige” subnettadresser. F.eks. ikke velg 192.168.1.0/24, for det er det svært mange andre som gjør.

Tunneler i flere retninger

Dersom man trenger flere tunneler mot andre nettverk kan man starte OpenVPN flere ganger med ulike konfigurasjonsfiler, én for hver tunnel. I dette tilfellet vil det kjøres flere OpenVPN-prosesser som ikke kan bruke samme UDP-port for sin kommunikasjon. Det er derfor nødvendig at konfigurasjonsfilene refererer til distinkte portnumre. Standard portnummer for OpenVPN er UDP/1194, dvs. den porten som brukes dersom ingenting annet er angitt. For VPN-tunnel nr. 2 kan vi gjerne bruke 1195 og videre oppover. Dette angis i konfigurasjonsfilen slik:

Green:Blue:
dev tun
port 1195
remote 4.5.6.7
secret greenblue.key
ifconfig 192.168.5.1 192.168.5.2
route 10.2.0.0 255.255.0.0
dev tun
port 1195
remote 9.8.7.6
secret greenblue.key
ifconfig 192.168.5.2 192.168.5.1
route 10.1.0.0 255.255.0.0
Tabell 1: Konfigurasjonsfiler for en ekstra tunnel

Forøvrig startes tunnel nr. 2 i et eget konsoll på samme måte som de andre.

2. Road Warrior VPN

I denne konfigurasjonsvarianten er det ikke to likestilte parter som kopler seg mot hverandre, men en klient-tjener konfigurasjon hvor et (potensielt høyt) antall klienter kopler sine enkeltmaskiner (ikke nettverk) til en tjener for å få tilgang et nettverk (derfor kalt host-til-nett). Det hører også med at klientene bruker varierende IP-adresser fordi de er stadig på farten og kopler seg opp fra hoteller o.l.

OpenVPN krever en sterkere kryptografisk beskyttelse av en slik forbindelse gjennom bruk av offentlige nøkler og sertifikater. Klienten har en privat nøkkel som må holdes hemmelig, og en offentlig nøkkel i form at et sertifikat som inngår i kryptering og autentisering og som alle kan kjenne til. Generering av nøkler og sertifikater er beskrevet i neste avsnitt

Generere nøkler og sertifikater

På en Linux-maskin vil programmet OpenSSL alltid være installert, og nødvendige nøkler og sertifikater for en VPN konfigurasjon kan genereres ved hjelp av skallprogrammet vist nedenfor. Merk at de to linjene med innrykk skal følge på linjen over.

# Generate keys and certificates for OpenVPN
#  Generate keys
openssl genrsa -out ca_key.pem 2048
openssl genrsa -out server_key.pem 2048
openssl genrsa -out client_key.pem 2048
#  Generate CA certificate
openssl req -new -x509 -days 1000 -key ca_key.pem -out ca_cert.pem -outform PEM -subj '/C=NO/O=CIS/CN=CA'
#  Generate Server certificate
openssl req -new -key server_key.pem -out server_csr.pem -subj '/C=NO/O=CIS/CN=OpenVPNServer'
openssl x509 -req -in server_csr.pem -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out 
        server_cert.pem -days 1000 -sha256
openssl verify -CAfile ca_cert.pem server_cert.pem
#  Generate Client certificate
openssl req -new -key client_key.pem -out client_csr.pem -subj '/C=NO/O=CIS/CN=OpenVPNClient'
openssl x509 -req -in client_csr.pem -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out
        client_cert.pem -days 1000 -sha256
openssl verify -CAfile ca_cert.pem client_cert.pem
#  Generate DH parameters
openssl dhparam 2048 > dh2048.pem
#  Remove unneccesary files
rm *_csr.pem

Programmet vil generere ett nøkkelpar for alle klientene i fellesskap. Ønskes separate nøkkelpar for hver klient kan skallprogrammet enkelt endres. Sertifikatopplysningene, f.eks. eierens navn (-subj) endres etter ønske.

De resulterende filene som skal overføres til tjener og på klientene er:

Til tjener: ca_cert.pem, server_cert.pem, server_key.pem, dh2048.pem
Til klient: ca_cert.pem, client_cert.pem, client_key.pem

Konfigurasjonsfilene

Konfigurasjonsfilene kan se slik ut:

Green/Red (klient):Blue (tjener):
dev tun
remote 4.5.6.7
client
keepalive 10 60
cipher AES-256-CBC
ca ca_cert.pem
cert client_cert.pem
key client_key.pem
dev tun
mode server
tls-server
keepalive 10 60
duplicate-cn
server 192.168.3.0 255.255.255.0
push "route 10.2.0.0 255.255.0.0"
cipher AES-256-CBC
dh dh2048.pem
ca ca_cert.pem
cert server_cert.pem
key server_key.pem

Tabell 2: Konfigurasjonsfiler for Host-til-nett bruk av OpenVPN

Disse konfigurasjonsfilene skal skrives inn på henholdsvis tjener- og klientsiden. Hver enkelt linje vil ikke forklares her, de fleste av dem forklarer seg selv. OpenVPN startes som i forrige konfigurasjon, og utlistingen på skjermen vil indikere når forbindelsen er satt opp. Maskinen Red er nå lagt til som en ekstra klient for å demonstrere muligheten for flere klienter koplet til samme tjener. Red og Green har nøyaktig samme konfigurasjon. OpenVPN startes på samme måte på hver node med konfigurasjonsfilene og nøkkelfilene liggende på samme katalog.

Studere nå IP-adressene på tun0-adapteret og rutingtabellene på hver maskin. Opplysningene der kan virke forvirrende, så her følger en forklaring på den strukturen som OpenVPN bygger for dette formålet, som vist på Figur 3.

Figur 3: Host-til-nett konfigurasjon av et VPN

Server-direktivet hos Blue instruerer OpenVPN at det skal dannes et rødt nett med dette adressesommet, 192.168.3.0/24. Adresserommet blir delt i subnett med prefiks /30 og hver klient får ett subnett. Den ene adressen i subnettet gis til klientens eller tjenerens tun0-adapter, den andre adressen tildeles en port i en tenkt ruter i det røde nettet.

Denne modellen forklarer hvorfor Green’s tun0-adapter har IP-adressen 192.168.3.10 med eneste nabo 192.168.3.9, og at ruten til 192.168.3.1 går gjennom denne naboen. Adressene på den tenkte ruteren lar seg ikke pinge, men man kan sette opp ruter via dem. Av rutingtabellene i Green og Red fremgår det også at de ikke har noen rute mellom seg, og forsøk på å pinge hverandres IP-adresser lykkes ikke.

Direktivet push "route 10.2.0.0 255.255.0.0" i Blue’s konfigurasjonsfil instruerer Blue til å levere rutinginformasjon til klientene når de kopler seg opp. I dette tilfellet vil Red få en rute til 10.2.0.0/16 via 192.168.3.5, og Green via 192.168.3.9. Siden disse gateway-adressene er ulike for alle klientene skal de ikke inngå i direktivet, men utledes under oppkoplingen. Med dette direktivet kan Green og Red oppnå en rute til nettverket som står “bak” Blue, noe som er hovedhensikten med konfigurasjonen.

Autentisering av tjeneren

Slik klientkonfigurasjonen nå er satt opp vil den kople seg til enhver tjener med et gyldig sertifikat. I dette tilfellet, der sertifikatene er utstedt for dette ene formålet, kan det være godt nok, men i prinsippet bør vi forvisse oss om identiteten til tjeneren. Det kan oppnås ved å legge til denne linjen i klientens konfigurasjonsfil:

verify-x509-name 'C=NO, O=CIS, CN=OpenVPNServer'

Dette direktivet vil forlange at tjeneren bruker et sertifikat med nettopp navnet 'C=NO, O=CIS, CN=OpenVPNServer' (se skallprogrammet overfor for å lage sertifikat med dette navnet)

OpenVPN-klient på Windows

Den viste klientkonfigurasjonen fungerer som den skal på Windows. Legg konfigurasjonsfilen (den må ha etternavnet .ovpn) sammen med de tre nøkkelfilene på OpenVPN’s konfigurasjonskatalog og kople opp gjennom å høyreklikke på tray-ikonet og velget “kople til/connect”. Noen advarsler vises, knyttet til sertifikatsjekken som kan unngåes ved å bruke direktivet som vist i forrige avsnitt.

Isolere klientene fra hverandre

I et Road Warrior brukstilfelle vil det oftest være fornuftig å isolere klientene fra hverandre, slik at Red og Green ikke kan kommunisere. I utgangspunktet kan de ikke det, men det beror på at det ikke finnes rutinginformasjon for dette. Det er derimot ingenting i veien for at Red setter opp en rute til Green via 192.168.3.5 slik:

# route add -host 192.168.3.10 gw 192.168.3.5 dev tun0

Tilsvarende må Green sette opp en rute til Red for at de skal kunne kommunisere. Vi har altså ingen tvungen separasjon av klientene, men tjeneren kan hindre slik trafikk ved å sette opp et iptables-filter (trafikken mellom Red og Green går faktisk via Blue og kan stoppes der). Bruk følgende kommando på Blue:

# iptables -A FORWARD -i tun0 -s 192.168.3.0/24 -d 192.168.3.0/24 -j DROP

Bruk av NAT (network address translation)

For at Green og Red skal kommunisere med nettet bak Blue (10.2.0.0/16) må alle maskinene på dette lokalnettet ha en rute tilbake til Green og Red (192.168.3.0/24) via Blue. Siden disse maskinene ikke er VPN-klienter kan man ikke bruke “push”-direktivet for dette formålet. Maskinene kan få denne ruten via DHCP, eller de kan bruke sin default gateway rute dersom Blue også er deres rute til Internet (slik som vist på Figur 3).

En slik løsning er ikke mulig dersom Blue ruter trafikk fra Red og Green videre til Internet. Da er det nødvendig med en NAT-tjeneste i Blue på det adapteret som forbinder til Internet (antar eth0 for dette eksemplet). En NAT-tjeneste settes opp med iptables ved hjelp av denne kommandoen:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Merk at dersom eth0 kopler et helt nettverk til Internet bør det også settes opp en brannvegg i dette punktet. Det gjøres også med iptables, og er omtalt i denne artikkelen.

Demonstrasjonsvideo:

3. Felles subnett VPN

Den tredje varianten av VPN-konfigurasjon som skal presenteres er å sette alle maskiner sammen som om de er koplet til samme Ethernet-svitsj som vist på Figur 4. Det innebærer at det nå er Ethernet-rammer som utveksles, ikke IP-pakker. Denne konfigurasjonen er fornuftig dersom:

  • Flere nettverksprotokoller skal brukes, f.eks. både versjon 4 og 6 av IP.
  • Kringkastingsprotokoller skal brukes
  • Det er nødvendig med bedre kontroll med tildelte IP-adresser.
  • Klientene skal kommunisere med hverandre, f.eks. i peer-to-peer programmer
Figur 4: OpenVPN konfigurert som svitsjet felles subnett.

Grunnkonfigurasjonen av denne varianten vil identifisere endepunktene, autentisere dem og sette opp virtuelle ethernet-adaptre, kalt tap0. Derfra kan konfigurasjonen av adaptre og rutingtabeller skje med assistanse av OpenVPN, eller ved bruk av maskinens ordinære konfigurasjonsverktøy:

  1. Konfigurasjonsfilen på OpenVPN-tjeneren (Blue) kan bruke et server-direktiv for å tildele IP-adresser til klientenes tap0-adaptre, og push-direktiv for å gi rutinginformasjon.
  2. Hver klient kan konfigureres med statiske IP-adresser og statisk ruting-informasjon, f.eks. (Linux) i filen /etc/network/interfaces eller /etc/netplan/.... Dette hører inn under ordinær nettverkskonfigurasjon og omtales ikke videre her.
  3. Konfigurasjonen kan besørges av tjenester utenom OpenVPN, f.eks. DHCP og routing-protokoller. Kringkastingsrammer kan sendes i denne VPN-varianten, så alle vanlige kringkastingsprotokoller (DHCP, ARP, uPnP, SSDP m.m.) kan brukes.

Valget av metode fra denne listen vil bero på antall klienter i bruk, behovet for identiske konfigurasjonsfiler, og hvilken rolle Blue skal spille i nettvkeret utover å sette opp VPN-tunneler. Det kan nå være andre klienter som besørger rutingen til lokalnett og Internet, og som tilbyr DHCP-tjenester m.m.

Her er eksempel på konfigurasjonsfiler for alternativ 1 fra listen over:

Green/Red (klient):Blue (tjener):
remote 4.5.6.7
client
del tap
keepalive 10 60
cipher AES-256-CBC
route 10.8.0.0 255.255.0.0
verify-x509-name 'C=NO....
ca ca_cert.pem
cert client_cert.pem
key client_key.pem
dev tap
mode server
tls-server
keepalive 10 60
server 10.11.0.0 255.255.0.0
push "route 5.6.7.0 255.255.255.0"
duplicate_cn
client_to_client
cipher AES-256-CBC
dh dh2048.pem
ca ca_cert.pem
cert server_cert.pem
key server_key.pem

I dette tilfellet vil klientene tildeles dynamiske IP-adresser (innen området 10.11.0.0/16), men dynamiske adresser er ikke praktisk dersom de skal kunne nås fra andre klienter. Ruteinformasjon i klienten kan settes både av tjeneren (push "route.." og implisitt i tildeling av IP-adresse) og av klienten selv (route...). Direktivet client_to_client er viktig fordi det åpner for kommunikasjon direkte mellom klientene.

For alternativ 2 og 3 fra listen over er konfigurasjonsfilene nærmest identiske:

Green/Red (klient):Blue (tjener):
remote 4.5.6.7
client
del tap
keepalive 10 60
cipher AES-256-CBC
ifconfig 10.12.0.3 255.255.255.0
verify-x509-name 'C=NO....
ca ca_cert.pem
cert client_cert.pem
key client_key.pem
dev tap
mode server
tls-server
keepalive 10 60
ifconfig 10.12.0.1 255.255.255.0
duplicate_cn
client_to_client
cipher AES-256-CBC
dh dh2048.pem
ca ca_cert.pem
cert server_cert.pem
key server_key.pem

Direktivet ifconfig brukes for å sette IP-adresse på det lokale tap0-adapteret. Klientens tap0-adapter får her adressen 10.12.0.3/24 og tjenerens 10.12.0.1/24. Med disse konfigurasjonsfilene skjer ingen koordinert tildeling av IP-adresser, dette må i så fall besørges på annet vis.

Dersom ifconfig-direktivet på klienten (merket med rødt) fjernes, skjer det ingen konfigurering av tap0-adapteret, dette må besørges av operativsystemet eller av en DHCP-tjeneste. DHCP-tjenesten må tilbys fra en maskin som er tilknyttet OpenVPN-subnettet, siden maskinene i lokalnettet 10.2.0.0/16 tilhører et annet subnett.

Demonstrasjonsvideo:

Konfigurasjonsmengde, trafikkmengde

Denne konfigurasjonen representerer stor fleksibilitet, men mange funksjoner som blir ivaretatt av OpenVPN nå må besørges av nettverkets ordinære tjenester for konfigurasjon og ruting. Dessuten vil trafikkmengden trolig øke i en slik konfigurasjon fordi all kringkastingstrafikk vil sendes til alle klientene i VPNet og konsumere overføringskapasitet.

Dersom alle maskinene står bak brannvegger/NAT

Dersom Blue står bak en NAT-enhet, eller bak en brannvegg, må det lages en port forwarding-regel i brannveggen for at UDP-pakker til port 1194 sendes til Blue’s IP-adresse. Alle maskiner som står bak brannvegger/NAT og som skal motta oppkoplingsmeldinger må ha en slik innretning. De maskinene som alltid oppretter OpenVPN-forbindelser (typisk for klientmaskiner) trenger ikke dette.

Oppsummering

Denne artikkelen har gitt en praktisk og kortfattet introduksjon av OpenVPN og gitt eksempler på konfigurasjon for ulike bruksscenarier. Detaljeringsgraden i forklaringene er redusert med vilje for å gi mer plass til diskusjon av hvilke alternativer som foreligger og konsekvensene av å velge dem. Eksemplene på konfigurasjonsfiler og skallprogrammer er noenlunde komplette og kan skrives inn i aktuelle systemer med små tilpasninger (adresser, adapternavn osv.).

Det finnes mange kilder på Internet til detaljert dokumentasjon av OpenVPN, f.eks. denne:

One thought on “Konfigurasjon av et Virtuelt Privat Nett

  1. Pingback: CMS – Et lettvekts samarbeidssystem for mindre brukergrupper | Nettverk, distribusjon, radio

Leave a Reply

Your email address will not be published. Required fields are marked *

eleven + 18 =