768 total views, 2 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.
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:
- Nett-til-nett, hvor to private lokalnett blir koplet sammen gjennom en beskyttet tunnel som om det sto en vanlig ruter mellom dem.
- Road warrior, hvor mange klienter kan kople seg til et lokalnett mens de er hjemme eller på reise. Også kalt host-til-nett.
- 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.
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 |
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 |
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.pemProgrammet 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 |
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.
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
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:
- Konfigurasjonsfilen på OpenVPN-tjeneren (Blue) kan bruke et server-direktiv for å tildele IP-adresser til klientenes tap0-adaptre, og push-direktiv for å gi rutinginformasjon.
- 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.
- 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:
Pingback: CMS – Et lettvekts samarbeidssystem for mindre brukergrupper | Nettverk, distribusjon, radio