10.3. 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 denne funksjonaliteten. 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 transparent, hvilket betyr at programmer 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-protokoll. Andre løsninger finnes, men er utenfor siktemålet til denne boken.

10.3.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.3.1.1. Oppsett av OpenVPN-tjeneren

Etter at alle sertifikater er opprettet (følg instruksjonene fra Seksjon 10.2.2, «Offentlig nøkkel-infrastruktur: easy-rsa»), må de kopieres der det er hensiktsmessig: rotsertifikatets fellesnøkkel (pki/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 (pki/issued/vpn.falcot.com.crt går til /etc/ssl/certs/vpn.falcot.com.crt, og pki/private/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 de tilsvarende Diffie-Hellman-parametrene (pki/dh.pem) installert til /etc/openvpn/dh.pem. Klientsertifikater er installert på den tilsvarende VPN-klienten på en tilsvarende måte.

Som forvalg forsøker OpenVPN-initialiseringskriptet å 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 vanlig oppsatt 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/dh.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, eller en udev regel kan bli lagt til den enden. OpenVPN-oppsettfilen 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.3.1.2. 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 systemctl start openvpn@name start og systemctl stop openvpn@name stop (der forbindelsen name sammenfaller med den som er definert i /etc/openvpn/name.conf).

The network-manager-openvpn-gnome package contains an extension to Network Manager (see Seksjon 8.2.5, «Automatisk nettverksoppsett for roaming-brukere») that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.

10.3.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:

→ https://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

VPN over SSH bør derfor begrenses til engangstunneler uten ytelsesbegrensninger.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the first of these options.

Først installerer vi libreswan pakken. Konkrete termer inneholder hver verts /etc/ipsec.conf inneholder parameterne for IPsec-tunnels (eller Security Associations, i IPsec-terminologien) som gjelder verten. Det finnes mange oppsetteksempler i /usr/share/doc/libreswan/, og Libreswans elektroniske dokumentasjon har flere eksempler med forklaringer:

→ https://libreswan.org/wiki/

IPsec-tjenesten kan kontrolleres med systemctl; for eksempel vil systemctl start ipsec starte IPsec-tjenesten.

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.3.4. PPTP

PPTP (som betyr punkt-til-punkt tunnelingsprotokoll, på engelsk Point-to-Point Tunneling Protocol) bruker to kommunikasjonskanaler, en for styringsdata og en for nyttelastdata; sistnevnte bruker GRE-protokollen (som betyr generisk ruting innkapsling, på engelsk Generic Routing Encapsulation). En standard PPP-forbindelse blir da satt opp over datautvekslingskanalen.

10.3.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.3.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: localip
# TAG: remoteip
#       Specifies the local and remote IP address ranges.
#
#       These options are ignored if delegate option is set.
#
#       Any addresses work as long as the local machine takes care of the
#       routing.  But if you want to use MS-Windows networking, you should
#       use IP addresses out of the LAN address space and use the proxyarp
#       option in the pppd options file, or run bcrelay.
#
#       You can specify single IP addresses seperated by commas or you can
#       specify ranges, or both. For example:
#
#               192.168.0.234,192.168.0.245-249,192.168.0.254
#
#       IMPORTANT RESTRICTIONS:
#
#       1. No spaces are permitted between commas or within addresses.
#
#       2. If you give more IP addresses than the value of connections,
#          it will start at the beginning of the list and go until it
#          gets connections IPs.  Others will be ignored.
#
#       3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#          you must type 234-238 if you mean this.
#
#       4. If you give a single localIP, that's ok - all local IPs will
#          be set to the given one. You MUST still give at least one remote
#          IP for each simultaneous client.
#
# (Recommended)
#localip 192.168.0.1
#remoteip 192.168.0.234-238,192.168.0.245
# or
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
localip 192.168.0.199
remoteip 192.168.0.200-250

PPP-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

# Enable connection debugging facilities.
# (see your syslog configuration for where pppd sends to)
#debug

# Name of the local system for authentication purposes
# (must match the second field in /etc/ppp/chap-secrets entries)
name pptpd

# Optional: domain name to use for authentication
## change the domainname to your local domain
domain falcot.com

# Authentication
## these are reasonable defaults for WinXXXX clients
## for the security related settings
auth
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
require-mppe-128

# Network and Routing
## 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     *