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

They then store the required parameters into the vars file, which can be uncommented and edited:

$ vim vars
$ grep EASYRSA 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"
$

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):

The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used:

$ ./easyrsa build-ca nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating RSA private key, 2048 bit long modulus (2 primes)
......................................................................................+++++
......................+++++
e is 65537 (0x010001)
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.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/roland/pki-falcot/pki/ca.crt

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):

$ ./easyrsa gen-req vpn.falcot.com nopass
Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating a RSA private key
.................................................................................+++++
........+++++
writing new private key to '/home/roland/pki-falcot/pki/private/vpn.falcot.com.key.E5c3RGJBUd'
-----
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.
-----
Common Name (eg: your user, host, or server name) [vpn.falcot.com]:

Keypair and certificate request completed. Your files are:
req: /home/roland/pki-falcot/pki/reqs/vpn.falcot.com.req
key: /home/roland/pki-falcot/pki/private/vpn.falcot.com.key

$ ./easyrsa sign-req server vpn.falcot.com

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019


You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
    commonName                = vpn.falcot.com


Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
Using configuration from /home/roland/pki-falcot/pki/safessl-easyrsa.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'vpn.falcot.com'
Certificate is to be certified until Jun 14 10:44:44 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/roland/pki-falcot/pki/issued/vpn.falcot.com.crt

$ ./easyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]
DH parameters of size 2048 created at /home/roland/pki-falcot/pki/dh.pem

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

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating a RSA private key
....+++++
..............................+++++
writing new private key to '/home/roland/pki-falcot/pki/private/JoeSmith.key.mY21iP8ysv'
-----
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.
-----
Common Name (eg: your user, host, or server name) [JoeSmith]:

Keypair and certificate request completed. Your files are:
req: /home/roland/pki-falcot/pki/reqs/JoeSmith.req
key: /home/roland/pki-falcot/pki/private/JoeSmith.key

Now all certificates have been created, they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

10.2.1.2. Oppsett av OpenVPN-tjeneren

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.

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.

If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.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

# Create the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  ip route add 192.168.0.0/24 dev $1
fi

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

# Delete the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  ip route del 192.168.0.0/24 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     *