10.2. Privat virtuelt nettverk

Et virtuelt privat nettverk Virtual Private Network (VPN for kort) er en måte å koble to forskjellige lokale nettverk via Internett ved hjelp av en tunnel; tunnelen er vanligvis kryptert for konfidensialitet. VPN brukes ofte for å integrere en ekstern maskin i et selskaps lokale nettverk.

Flere verktøy har dette. OpenVPN er en effektiv løsning, enkel å implementere og vedlikeholde, basert på SSL/TLS. En annen mulighet er å bruke IPsec for å kryptere IP-trafikk mellom to maskiner; denne krypteringen er gjennomsiktig, hvilket betyr at applikasjoner som kjører på disse vertene ikke behøver modifiseres for å ta hensyn til VPN. SSH kan også brukes for å tilveiebringe en VPN, i tillegg til mer konvensjonelle egenskaper. Endelig kan en VPN etableres ved hjelp av Microsofts PPTP-protokollen. Andre løsninger finnes, men er utenfor siktemålet med denne boken.

10.2.1. OpenVPN

OpenVPN er et stykke programvare med formål å lage virtuelle private nettverk. Oppsettet innebærer å skape virtuelle nettverksgrensesnitt på VPN-tjeneren og på klienten(e); både tun (for IP-nivå tunneler) og tap (for Ethernet-nivå tunneler) -grensesnitt er støttet. I praksis, skal tun-grensesnitt oftest brukes unntatt når VPN-klienter er ment til å bli integrert i tjenerens lokale nettverk ved hjelp av en Ethernet-bro.

OpenVPN avhenger av OpenSSL for all SSL/TLS kryptografi og tilhørende funksjoner (konfidensialitet, autentisering, integritet, ikke-fornekting). Den kan settes opp enten med en felles privat nøkkel eller ved hjelp av X.509-sertifikater basert på en infrastruktur med fellesnøkler. Sistnevnte oppsett er sterkt foretrukket fordi den gir større fleksibilitet når den står overfor et økende antall brukere som bruker VPN utenfra.

10.2.1.1. Offentlig nøkkel-infrastruktur: easy-rsa

RSA-algoritmen er mye brukt i offentlig-nøkkel kryptografi. Det innebærer et «nøkkelpar», som består av en privat og en offentlig nøkkel. De to nøklene er nært knyttet til hverandre, og deres matematiske egenskaper er slik at en melding som er kryptert med den offentlige nøkkelen, kun kan dekrypteres av en person som kjenner den private nøkkelen, noe som sørger for konfidensialitet. I motsatt retning kan en melding kryptert med den private nøkkelen dekrypteres ved at noen kjenner den offentlige nøkkelen, noe som gjør det mulig å autentisere opprinnelsen til en melding siden bare noen med tilgang til den private nøkkelen kan generere den. Når den er knyttet til en digital nøkkelfunksjon (MD5, SHA1, eller en nyere variant), fører dette til en signaturmekanisme som kan brukes til en hvilken som helst melding.

Imidlertid kan hvem som helst lage et nøkkelpar, lagre en hvilken som helst identitet på den, og foregir at at dette er den valgte identiteten. En løsning innebærer konseptet med en Certification Authority (CA), formalisert av X.509-standarden. Dette konseptet omfatter en enhet som har et pålitelig nøkkelpar kjent som et rotsertifikat. Dette sertifikatet er kun brukt til å signere andre sertifikater (nøkkelpar) etter at riktige skritt er blitt tatt for å sjekke identiteten som er lagret i nøkkelparet. Applikasjoner som bruker X.509 kan da sjekke sertifikatene som blir presentert for dem, hvis de vet om de klarerte rotsertifikater.

OpenVPN følger denne regelen. Siden offentlige CA-er kun utsteder sertifikater i bytte for en (heftig) avgift, er det også mulig å opprette en privat sertifiseringsinstans i selskapet. easy-rsa-pakken inneholder verktøy for å tjene som en X.509 infrastruktur for sertifisering, implementert som et skriptsett som bruker openssl-kommandoen.

Falcot Corp-administratorene bruker dette verktøyet for å lage de nødvendige sertifikater, både for serveren og klientene. Dette tillater at oppsettet av alle klienter er lik siden de bare må settes opp til å stole på sertifikater fra Falcots lokale CA. Dette CA-et er det første som må lages; til dette formålet, setter administratorene opp en katalog med filene som kreves for CA-et på et passende sted, fortrinnsvis på en maskin som ikke er koblet til nettverket for å redusere risikoen for at CAs private nøkkel blir stjålet.

$ make-cadir pki-falcot
$ cd pki-falcot

De lagrer deretter de nødvendige parameterene i vars-filen, spesielt de som er navnet med et KEY_-prefiks; Disse variablene blir så integrert i miljøet:

$ vim vars
$ grep KEY_ vars
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=2048
export KEY_EXPIRE=3650
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Loire"
export KEY_CITY="Saint-Étienne"
export KEY_ORG="Falcot Corp"
export KEY_EMAIL="admin@falcot.com"
export KEY_OU="Certificate authority"
export KEY_NAME="Certificate authority for Falcot Corp"
# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
# export KEY_CN="CommonName"
$ . ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/roland/pki-falcot/keys
$ ./clean-all

Det neste trinnet er etableringen av selve CAs nøkkelpar (de to delene av nøkkelparet vil i dette trinnet bli lagret under keys/ca.crt og keys/ca.key):

$ ./build-ca
Generating a 2048 bit RSA private key
...................................................................+++
...+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [Falcot Corp CA]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:

Sertifikatet for VPN-tjeneren kan nå opprettes, så vel som Diffie-Hellman-parameterene som kreves for tjenersiden av en SSL/TLS-tilkobling. VPN-tjeneren er identifisert av sitt DNS-navn vpn.falcot.com; dette navnet gjenbrukes for de genererte nøkkelfilene, (keys/vpn.falcot.com.crt for det offentlige sertifikatet, keys/vpn.falcot.com.key for den private nøkkelen):

$ ./build-key-server vpn.falcot.com
Generating a 2048 bit RSA private key
.....................................................................................................................+++
...........+++
writing new private key to 'vpn.falcot.com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [vpn.falcot.com]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /home/roland/pki-falcot/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'FR'
stateOrProvinceName   :PRINTABLE:'Loire'
localityName          :T61STRING:'Saint-\0xFFFFFFC3\0xFFFFFF89tienne'
organizationName      :PRINTABLE:'Falcot Corp'
organizationalUnitName:PRINTABLE:'Certificate authority'
commonName            :PRINTABLE:'vpn.falcot.com'
name                  :PRINTABLE:'Certificate authority for Falcot Corp'
emailAddress          :IA5STRING:'admin@falcot.com'
Certificate is to be certified until Mar  6 14:54:56 2025 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
$ ./build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]

Det neste trinnet oppretter sertifikater for VPN-klienter; ett sertifikat kreves for hver datamaskin eller person som får lov å bruke VPN-en:

$ ./build-key JoeSmith
Generating a 2048 bit RSA private key
................................+++
..............................................+++
writing new private key to 'JoeSmith.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:Development unit
Common Name (eg, your name or your server's hostname) [JoeSmith]:Joe Smith
[…]

Nå er alle sertifikater blitt opprettet, og de trenger å bli kopiert når det må til: rotsertifikatets offentlige nøkkel (keys/ca.crt) vil bli lagret på alle maskiner (både tjener og klienter) som /etc/ssl/certs/Falcot_CA.crt. Tjenerens sertifikat er bare installert på tjeneren (keys/vpn.falcot.com.crt går til /etc/ssl/vpn.falcot.com.crt, og keys/vpn.falcot.com.key går til /etc/ssl/private/vpn.falcot.com.key med begrensede tillatelser slik at bare administratoren kan lese den), med tilhørende Diffie-Hellman-parametere (keys/dh2048.pem) installert til /etc/openvpn/dh2048.pem. Klientsertifikater blir installert på den tilsvarende VPN-klienten på en lignende måte.

10.2.1.2. Oppsett av OpenVPN-tjeneren

Som standard forsøker OpenVPN-initialiseringskript å starte alle virtuelle private nettverk som er definert i /etc/openvpn/*.conf. Å sette opp en VPN-tjener er derfor et spørsmål om å lagre en tilsvarende oppsettsfil i denne katalogen. Et godt utgangspunkt er /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, som leder til en temmelig standard tjener. Selvfølgelig må noen parametere tilpasses: ca, cert, key og dh må beskrive de valgte stedene (henholdsvis /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key og /etc/openvpn/dh2048.pem). server 10.8.0.0 255.255.255.0-direktivet definerer subnettet som skal brukes av VPN; tjeneren bruker den første IP-adressen i dette området (10.8.0.1), og resten av adressene er reservert for klienter.

Med dette oppsettet lager oppstarten av OpenVPN det virtuelle nettverksgrensesnittet, vanligvis med tun0-navnet. Imidlertid er brannmurer ofte satt opp på samme tid som det virkelige nettverksgrensesnittet, og skjer før OpenVPN starter. En god praksis er derfor å lage et varig virtuelt nettverksgrensesnitt, og sette opp OpenVPN til å bruke dette varige grensesnittet. Dette tillater videre å velge navnet til dette grensesnittet. For dette formål lager openvpn --mktun --dev vpn --dev-type tun et virtuelt nettverksbrukergrensesnitt med navnet vpn med type tun; denne kommandoen kan enkelt legges inn i brannmuroppsettets skript, eller i et up-direktiv i /etc/network/interfaces-filen. OpenVPN-oppsettsfilen må også oppdateres tilsvarende, med dev vpn og dev-type tun-direktiver.

For å sperre ytterligere virksomhet kan VPN-klienter kun få tilgang til selve VPN-tjeneren ved hjelp av 10.8.0.1-adressen. Å gi klientene tilgang til det lokale nettverket (192.168.0.0/24), krever at en legger til et push route 192.168.0.0 255.255.255.0-direktiv til OpenVPN-oppsettet slik at VPN-klienter automatisk får en nettverksrute som forteller dem at dette nettverket kan nås ved hjelp av VPN. Videre, maskiner på det lokale nettverket må også informeres om at ruten til VPN går gjennom VPN-tjeneren (dette fungerer automatisk når VPN-tjeneren er installert i porten). Alternativt kan VPN-tjeneren settes opp til å utføre IP-maskering, slik at tilkoblinger fra VPN-klienter ser ut som om de kommer fra VPN-tjeneren i stedet (se Seksjon 10.1, «Innfallsport (gateway)»).

10.2.1.3. Oppsett av OpenVPN-klienten

Å sette opp en OpenVPN-klient krever også at en lager en oppsettsfil /etc/openvpn/. Et standardoppsett kan fås ved å bruke /usr/share/doc/openvpn/examples/sample-config-files/client.conf som et startpunkt. remote vpn.falcot.com 1194-direktivet beskriver adressen og porten til OpenVPN-tjeneren; ca, cert og key må også tilpasses til å beskrive plasseringen av de viktigste filene.

Hvis VPN ikke skal startes automatisk ved oppstart, sett AUTOSTART-direktivet til none i /etc/default/openvpn-filen. Å starte eller stoppe en gitt VPN-forbindelse er alltid mulig med kommandoene service openvpn@navn start og service openvpn@navn stop (der forbindelsen navn sammenfaller med en som er definert i /etc/openvpn/navn.conf).

Pakken network-manager-openvpn-gnome inneholder en forlengelse til Network Manager (se Seksjon 8.2.5, «Automatisk nettverksoppsett for roaming-brukere») som tillater håndtering av OpenVPN virtuelle private nettverk. Det tillater hver bruker å sette opp OpenVPN-tilkoblinger grafisk, og styre dem fra nettverksadministrasjonsikonet.

10.2.2. Virtuelt privat nettverk med SSH

Det er faktisk to måter å lage et virtuelt privat nettverk ved hjelp av SSH. Den historiske innebærer å etablere et PPP-lag over SSH-linken. Denne metoden er beskrevet i et HOWTO-dokument:

→ http://www.tldp.org/HOWTO/ppp-ssh/

Den andre metoden er av nyere dato, og ble introdusert med OpenSSH 4.3: Det er nå mulig for OpenSSH å opprette virtuelle nettverksgrensesnitt (tun*) på begge sider av en SSH-tilkobling, og disse virtuelle grensesnitt kan settes opp akkurat som om de var fysiske grensesnitt. Tunnelsystemet må først aktiveres ved å sette PermitTunnel til «yes» i SSH-tjenerens oppsettsfil (/etc/ssh/sshd_config). Når SSH-tilkoblingen etableres, må det eksplisitt bes om at det lages en tunnel med -w any:any valget/alternativet (any kan erstattes med det ønskede tun enhetsnummeret). Dette krever at brukeren har administratorprivilegium på begge sider, for å kunne lage nettverksenheten (med andre ord, må forbindelsen etableres som rot).

Begge måter for å opprette et virtuelt privat nettverk over SSH er ganske greie. Men VPN-en er ikke den mest effektivt tilgjengelige; særlig håndterer den ikke høye trafikknivåer godt.

Forklaringen er at når en TCP/IP-stakk er innkapslet innenfor en TCP/IP-tilkobling (for SSH), er TCP-protokollen brukt to ganger, en gang for SSH-tilkoblingen og en gang inne i tunnelen. Dette fører til problemer, særlig på grunn av måten TCP tilpasser seg til nettverksforholdene ved å endre forsinkelser ved tidsavbrudd. Følgende nettsted beskriver problemet i mer detalj:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH bør derfor begrenses til engangstunneler uten ytelsespress.

10.2.3. IPsec

Til tross for å være standard i IP VPN, er IPsec snarere mer involvert i implementeringen. IPsec-motoren er selv integrert i Linux-kjernen; de nødvendige delene/komponentene bruker-plass deler, kontroll- og oppsettsverktøyet, gis av ipsec-tools-pakken. Helt konkret inneholder hver vert /etc/ipsec-tools.conf parametrene for IPsec tunneler (eller Security Associations, i IPsec terminologien) som angår verten; /etc/init.d/setkey-skriptene gir en måte å starte og stoppe en tunnel (hver tunnel er en sikker kobling til en annen vert koblet til det virtuelle private nettverket). Denne filen kan bygges for hånd fra dokumentasjonen som følger med manualsiden setkey(8). Imidlertid, å eksplisitt skrive parametrene for alle verter i et ikke-vanlig sett maskiner, blir fort en krevende oppgave, fordi antall tunneler vokser hurtig. Å installere en IKE-bakgrunnsprosess (for IPsec Key Exchange) slik som racoon, eller strongswan gjør prosessen mye enklere ved å bringe administrasjon sammen på et sentralt punkt, og sikrere ved å rotere nøklene med jevne mellomrom.

På tross av sin status som referanse; kompleksiteten ved å sette opp IPsec begrenser bruken i praksis. OpenVPN-baserte løsninger vil vanligvis bli foretrukket når de nødvendige tunnelene verken er for mange eller for dynamiske.

10.2.4. PPTP

PPTP (punkt-til-punkt tunneling protokoll: for Point-to-Point Tunneling Protocol) bruker to kommunikasjonskanaler, en for styringsdata og en for nyttelastdata; sistnevnte bruker GRE-protokollen (generisk ruting innkapsling: Generic Routing Encapsulation). En standard PPP-lenke blir da satt opp over datautvekslingskanalen.

10.2.4.1. Oppsett av klienten

Pakken pptp-linux inneholder en lett oppsettbar PPTP-klient for Linux. Følgende instruksjoner er inspirert fra den offisielle dokumentasjonen:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Falcot-administratorene laget flere filer: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot, og /etc/ppp/ip-down.d/falcot.

Eksempel 10.2. Filen /etc/ppp/options.pptp

# PPP-valg brukt med en PPTP-forbindelse
lock
noauth
nobsdcomp
nodeflate

Eksempel 10.3. Filen /etc/ppp/peers/falcot

# vpn.falcot.com er PPTP-tjeneren
pty "pptp vpn.falcot.com --nolaunchpppd"
# forbindelsen vil identifisere seg som "vpn"-brukeren
user vpn
remotename pptp
# kryptering trengs
require-mppe-128
file /etc/ppp/options.pptp
ipparam falcot

Eksempel 10.4. Filen /etc/ppp/ip-up.d/falcot

# Lag en rute til Falcot-nettet
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 er ikke-lokale Falcot-nettverket
  route add -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

Eksempel 10.5. Filen /etc/ppp/ip-down.d/falcot

# Slett ruten til Falcot-nettet
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 er det ikke-lokale Falcot-nettverket
  route del -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

10.2.4.2. Oppsett av tjenermaskinen

pptpd er PPTP-tjeneren for Linux. Hovedoppsettsfilen, /etc/pptpd.conf, krever svært få endringer: localip (lokal IP-adresse), og remoteip (ekstern IP-adresse). I eksempelet nedenfor bruker PPTP-tjeneren alltid 192.168.0.199-adressen, og PPTP-klienter mottar IP-adresser fra 192.168.0.200 til 192.168.0.250.

Eksempel 10.6. Filen /etc/pptpd.conf

# TAG: speed
#
#       Spesifiserer hastigheten som PPP-bakgrunnsprosessen skal snakke på.
#
speed 115200

# TAG: option
#
#       Spesifiserer plasseringen til PPP-tilvalgsfilen.
#       I utgangspunktet titter PPP i '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#
#       Slår på (mer) feilsøkingsinformasjon til syslog
#
# debug

# TAG: localip
# TAG: remoteip
#
#       Spesifiserer IP-addresseområdene på den lokal og den motsatte siden.
#
#       Du kan spesifisere enkelt-IP-adresser oppdelt med komma eller du kan skrive inn områder,
#       eller begge deler.  Et eksempel:
#
#               192.168.0.234,192.168.0.245-249,192.168.0.254
#
#       VIKTIGE BEGRESNINGER:
#
#       1. Ingen mellomrom tillates mellom komma og inne i adresser.
#
#       2. Hvis du oppgir flere IP-adresser enn MAX_CONNECTIONS, så vil PPP
#          starte på begynnelsen av listen og fortsette inntil den har fått
#          MAX_CONNECTIONS IP-adresser. De øvrige blir ignorert.
#
#       3. Ingen forkortelser i områdene! Med andre ord, 234-8 betyr ikke 234 to 238,
#          du må skrive inn 234-238 hvis det er dette du mener.
#
#       4. Hvis du oppgir en enkelt lokalt IP-adresse så er det OK - alle lokale IP-addresser
#          vil bli satt til dette. Du MÅ fortsatt oppgi minst en IP for den andre enden for hver
#          samtidige klient.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
#localip 10.0.1.1
#remoteip 10.0.1.2-100
localip 192.168.0.199
remoteip 192.168.0.200-250

OPS-oppsettet som brukes av PPTP-tjeneren krever også noen endringer i /etc/ppp/pptpd-options. De viktige parametre er tjenernavnet (pptp), domenenavnet (falcot.com), og IP-adressene for DNS- og WINS-tjenere.

Eksempel 10.7. Filen /etc/ppp/pptpd-options

## turn pppd syslog debugging on
#debug

## change 'servername' to whatever you specify as your server name in chap-secrets
name pptp
## change the domainname to your local domain
domain falcot.com

## these are reasonable defaults for WinXXXX clients
## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present!
auth
require-chap
require-mschap
require-mschap-v2
require-mppe-128

## Fill in your addresses
ms-dns 192.168.0.1
ms-wins 192.168.0.1

## Fill in your netmask
netmask 255.255.255.0

## some defaults
nodefaultroute
proxyarp
lock

Det siste trinnet innebærer registrering av vpn-brukeren (og tilhørende passord) i /etc/ppp/chap-secrets-filen. I motsetning til andre tilfeller hvor en asterisk (*) ville fungere, må tjenernavnet fylles inn eksplisitt her. Videre identifiserer Windows PPTP-klienter seg med DOMENE\\BRUKER-formen, i stedet for bare å gi et brukernavn. Dette forklarer hvorfor filen også nevner FALCOT\\vpn-brukeren. Det er også mulig å spesifisere individuelle IP-adresser for brukere; en stjerne i dette feltet angir at dynamisk adressering skal brukes.

Eksempel 10.8. Filen /etc/ppp/chap-secrets

# Hemmeligheter for autentisering vha. CHAP
# klient        tjener  hemmelighet      IP-adresser
vpn             pptp    f@Lc3au     *
FALCOT\\vpn     pptp    f@Lc3au     *