14.10. VPN via IPsec

ping 192.168.2.34

14.10.3.1. Stap 1: de “virtuele” netwerkverbinding maken en testen

Stel dat een gebruiker is aangemeld op de gatewaymachine in netwerk #1 (met publiek IP adres A.B.C.D en privaat IP adres 192.168.1.1) en de voert ping 192.168.2.1 uit, naar het private adres van de machine met IP adres W.X.Y.Z. Wat moet er gebeuren om dat te laten werken?

1. De gateway host moet weten hoe hij 192.168.2.1 kan bereiken. Met andere woorden: hij moet een route hebben naar 192.168.2.1.

2. Private IP adressen als de reeks 192.168.x horen in het algemeen niet thuis op internet. Ieder pakket naar 192.168.2.1 moet dus ingepakt worden in een ander pakket. Dit pakket moet afkomstig lijken van A.B.C.D en moet naar W.X.Y.Z verstuurd worden. Dit proces heet inkapseling (encapsulation).

3. Als dit pakket aankomt bij W.X.Y.Z dan moet het “uitgekapseld (unencapsulated)” worden en afgeleverd worden aan 192.168.2.1.

Dit is alsof er een “tunnel” moet bestaan tussen de twee netwerken. De twee “tunnelopeningen” zijn de IP adressen A.B.C.D en W.X.Y.Z en de tunnel moet op de hoogte zijn van de private IP adressen die door de tunnel mogen. De tunnel wordt gebruikt om verkeer met private IP adressen over het internet te leiden.

Deze tunnel wordt gemaakt door gebruik te maken van de generieke interface of gif apparaten op FreeBSD. De gif interface moet op iedere gatewaymachine ingesteld zijn met vier IP adressen: twee voor de publieke IP adressen en twee voor de private IP adressen.

Ondersteuning voor het gif apparaat moet in de FreeBSD kernel van beide machine gecompileerd worden. Dit kan door de volgende optie toe te voegen aan de kernelinstellingenbestanden op beide machines, dan de kernel te compileren, te installeren en dan gewoon te herstarten:

device gif

Het instellen van de tunnel gaat in twee stappen. Eerst moet de tunnel verteld worden wat de IP adressen aan de buitenkant (publiek) zijn met gifconfig(8). Daarna moeten de private IP adressen ingesteld worden met ifconfig(8).

Op de gatewaymachine op netwerk #1 moeten de volgende commando's uitgevoerd worden om te tunnel in te stellen.

gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

Op de andere gatewaymachine moeten dezelfde commando's uitgevoerd worden met omgedraaide IP adressen.

gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff

Daarna toont:

gifconfig gif0

de instellingen. Op netwerk #1 zou dat het volgende zijn:

# gifconfig gif0
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z

Er is nu een tunnel gemaakt tussen de fysieke adressen A.B.C.D en W.X.Y.Z en het verkeer dat door de tunnel mag is dat tussen 192.168.1.1 en 192.168.2.1.

Hiermee is ook een regel gemaakt in de routetabel op beide machines die te bekijken zijn met netstat -rn. Deze uitvoer komt van de gatewayhost op netwerk #1.

# netstat -rn
Routing tables

Internet:
Destination      Gateway       Flags    Refs    Use    Netif  Expire
...
192.168.2.1      192.168.1.1   UH        0        0    gif0
...

De “Flags” waarde geeft aan dat dit een hostroute is, wat betekent dat iedere gateway weet hoe hij de andere gateway kan bereiken, maar dat ze niet weten hoe ze bij de rest van elkaars netwerk kunnen komen. Dat probleem wordt snel opgelost.

Het is waarschijnlijk dat op beide machines een firewall draait. Die moet omzeild worden voor VPN verkeer. Het is mogelijk al het verkeer tussen de beide netwerken toestaan of firewallregels toe te voegen waarmee de beide netwerken die het VPN met elkaar verbindt tegen elkaar beschermd worden.

Het testen wordt een stuk eenvoudiger als de firewall zo is ingesteld dat al het verkeer door het VPN wordt doorgelaten. Laten kunnen nog restricties toegevoegd worden. Met ipfw(8) wordt met

ipfw add 1 allow ip from any to any via gif0

al het verkeer tussen de twee eindstations van het VPN toegestaan zonder dat dit de andere regels van de firewall beïnvloedt. Dit commando moet natuurlijk wel op beide gatewayhosts uitgevoerd worden.

Deze instelling is toereikend om elke gateway machine het recht te geven de ander te pingen. Op 192.168.1.1 kan nu:

ping 192.168.2.1

gedraaid worden en moet een antwoord komen. Op de andere machine kan dezelfde test gedaan worden.

Maar nu zijn de andere machines op het interne netwerk nog niet te bereiken. Dat komt door de routering: hoewel de gateway machines elkaar nu weten te vinden, weten ze nog niet hoe ze het netwerk achter elkaar kunnen bereiken.

Om dat probleem op te lossen moet een statische route worden toevoegd op iedere gateway machine. Het commando daarvoor is:

route add 192.168.2.0 192.168.2.1 netmask 0xffffff00

Dit betekent: “om hosts op het netwerk 192.168.2.0 te bereiken moeten pakketten naar de host 192.168.2.1 sturen”. Een zelfde dient op de andere gateway uitgevoerd te worden, maar dan met de 192.168.1.x adressen.

IP verkeer van hosts op het ene netwerk kan nu hosts op het andere netwerk bereiken.

Hiermee is tweederde van het VPN tussen twee netwerken aangelegd in de zin dat het “virtueel” is en er een “netwerk” is. Maar het is nog niet privaat. Dit wordt aangetoond met ping(8) en tcpdump(1). Voer op de gateway host het volgende commando uit:/para>

tcpdump dst host 192.168.2.1

Voer vanuit een andere sessie op de host het onderstaande commando uit:

ping 192.168.2.1

De uitvoer is ongeveer als volgt:

16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply

Het is zichtbaar dat de ICMP berichten niet versleuteld heen en weer gaan. Als met tcpdump(1) de parameter -s was gebruikt om meer bytes te tonen uit de pakketten, dan was meer informatie te zien geweest.

Dit is natuurlijk onacceptabel. In de volgende paragraaf gaat het dan ook over het beveiligen van de verbinding tussen de twee netwerken zodat al het verkeer automatisch wordt versleuteld.

Samenvatting:

• Stel voor beide kernels het “pseudo-device gif” in.

• Wijzig /etc/rc.conf op gateway host #1 en voeg de volgende regels toe (wijzig IP adressen naar wens).

  gifconfig_gif0="A.B.C.D W.X.Y.Z"
  ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
  static_routes="vpn"
  route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
  

• Wijzig het firewallscript (/etc/rc.firewall of iets dergelijks) op beide hosts en voeg het volgende toe:

  ipfw add 1 allow ip from any to any via gif0
  

• Maak gelijksoortige wijzigingen in /etc/rc.conf op gateway host #2 en draai de volgorde van de IP adressen om.

14.10.3.2. Stap 2: de verbinding beveiligen

Om de verbinding te beveiligen wordt IPsec gebruikt. IPsec biedt een mechanisme waarmee twee hosts samen een sleutel hebben en die sleutel dan gebruiken om gegevens te versleutelen tussen die twee hosts.

Hiervoor moet op twee plaatsen een aanpassing gemaakt worden in de instellingen.

1. Er moet een mechanisme zijn voor de twee hosts om het eens te worden over het versleutelingsmechanisme dat gebruikt gaat worden. Als de twee hosts het daar over eens zijn, dan hebben ze een zogenaamde “beveiligingssamenwerking (security association)”.

2. Er moet een mechanisme zijn waarmee wordt aangegeven welk verkeer versleuteld moet worden. Tenslotte moet niet al het uitgaande verkeer versleuteld worden, maar alleen het verkeer dat onderdeel is van het VPN. De regels die worden opgesteld om te bepalen welke verkeer versleuteld wordt heten “beveiligingsbeleid (security policies)”.

Beveiligingssamenwerking en beveiligingsbeleid worden beiden onderhouden door de kernel en kunnen aangepast worden met programma's in userland. Maar voor dit mogelijk is, moet de kernel geschikt gemaakt worden voor ondersteuning van IPsec en het Encapsulated Security Payload (ESP) protocol. Dit kan door de volgende regel op te nemen in het kernelinstellingenbestand:

options IPSEC
options IPSEC_ESP

Daarna dienen hercompilatie en installatie van de kernel plaats te vinden en moet de machine gereboot worden. Dit moet voor beide gateway hosts uitgevoerd worden.

Het is mogelijk twee wegen te bewandelen voor het opzetten van beveiligingssamenwerking. Als het met de hand wordt opgezet dan moeten een versleutelingsalgoritme, coderingssleutels, enzovoort gekozen worden. Er kan ook een daemons gebruikt worden die het Internet Key Exchange protocol (IKE) implementeert om dit uit te voeren.

Het advies is voor het laatste te kiezen. Los van andere overwegingen is het makkelijker in te stellen.

Voor het wijzigen en weergeven van het beveiligingsbeleid is er setkey(8). Ter vergelijking: setkey is voor het beveiligingsbeleid van de kernel wat route(8) is voor de routetabellen van de kernel. setkey kan ook de huidige beveiligingssamenwerkingen weergeven en om de vergelijking door te zetten is het in die zin verwant aan netstat -r.

Er zijn een aantal daemons beschikbaar voor het bijhouden van beveiligingssamenwerking in FreeBSD. In dit artikel wordt beschreven hoe dat met racoon gaat. racoon is in de FreeBSD Portscollectie beschikbaar vanuit security/ipsec-tools.

Racoon moet draaien op beide gateway hosts. Op iedere host moet het IP-adres van de andere kant van het VPN ingesteld worden en een geheime sleutel (die door de gebruiker zelf is gekozen en die hetzelfde moet zijn op beide gateways).

De twee daemons zoeken dan contact met elkaar en stellen vast dat ze zijn wie ze beweren te zijn (door gebruik te maken van de geheime sleutel die is ingesteld). De daemons maken dan een nieuwe geheime sleutel aan en gebruiken die om het verkeer over het VPN te versleutelen. Ze wijzigen die sleutel periodiek zodat een aanvaller er niets aan heeft in het geval hij achter een van de sleutels zou komen. Dit is theoretisch trouwens vrijwel onuitvoerbaar. Tegen de tijd dat de sleutel gekraakt is, hebben de twee daemons al een nieuwe gekozen.

De instellingen van racoon worden opgeslagen in ${PREFIX}/etc/racoon. Daar tref staat een instellingenbestand aan dat niet ingrijpend hoeft te wijzigen. De andere component van de instellingen van racoon die gewijzigd moet worden is de “wederzijds bekende sleutel (pre-shared key)”.

Standaard verwacht racoon dat die in ${PREFIX}/etc/racoon/psk.txt staat. Het is belangrijk op te merken dat de wederzijds bekende sleutel niet de sleutel is die gebruikt wordt om het verkeer van de VPN verbinding te versleutelen. Het is gewoon een token die de sleutelbeheerdaemons in staat stelt elkaar te vertrouwen.

psk.txt bevat een regel voor iedere locatie waarmee verbinding bestaat. In dit voorbeeld zijn er twee locaties en dus bevat ieder psk.txt bestand één regel (omdat de ene kant van de VPN alleen iets te maken heeft met één andere kant).

Op gateway host #1 ziet dat er als volgt uit:

W.X.Y.Z            secret

Er staat dus het publieke IP adres van de andere kant, witruimte ;- spatie(s) of tab(s) - en een stuk tekst met de geheime sleutel. Natuurlijk dient “secret” niet als sleutel gebruikt te worden. Ook hier gelden de normale regels voor wachtwoorden.

Op gateway host #2 ziet dat er dan zo uit:

A.B.C.D            secret

Dus het publieke IP adres van de andere kant en dezelfde geheime sleutel. psk.txt moet in mode 0600 staan (alleen lees en schrijfrechten voor root) voordat racoon zal werken.

Racoon moet draaien op beide gatewaymachines. Er moeten ook een aantal firewallregels toegevoegd worden om IKE verkeer toe te staan, dat over UDP naar de ISAKMP (Internet Security Association Key Management Protocol) poort loopt. Nogmaals: deze regels staan bij voorkeur zo vroeg mogelijk in de firewallregels.

ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp

Als racoon eenmaal draait, dan kan de ene gateway host vanaf de andere gepingd worden. De verbinding is dan nog steeds niet versleuteld, maar racoon stelt wel de beveiligingssamenwerking tussen de twee hosts op. Dat kan heel even duren en dat uit zich in een kleine vertraging voordat er een antwoord op de ping komt.

Als de beveiligingssamenwerking tot stand is gekomen, dan kan deze getoond worden met setkey(8):

setkey -D

Het bovenstaande commando toont de beveiligingssamenwerkingsingsinformatie.

Dat is de ene helft van het probleem. De andere helft is het instellen van het beveiligingsbeleid.

Voor er een zinvol beveiligingsbeleid opgesteld kan worden volgt eerst een samenvatting van wat tot nu toe is bereikt. Het volgende geldt voor beide kanten van de verbinding.

Ieder IP pakket dat wordt verzonden heeft een kop die gegevens over het pakket bevat. De kop bevat het IP adres van zowel de bron als de bestemming. Zoals bekend horen private IP adressen zoals de reeks 192.168.x.y niet thuis op internet. Ze moeten eerst ingepakt worden in een ander pakket. Voor dat pakket moeten het publieke bron en bestemmingsadres op de plaats van de private adressen gezet worden.

Dus als een uitgaand pakket als volgt begon:

Dan wordt het ingepakt in een andere pakket dat er ongeveer als volgt uitziet:

Het gif apparaat zorgt voor het inpakken. Het pakket heeft nu een echt IP adres aan de buitenkant en het originele pakket zit ingepakt als data in het pakket dat het internet opgestuurd gaat worden.

Nu moet het verkeer over het VPN natuurlijk versleuteld worden. Dat kan als volgt worden weergegeven:

“Als een pakket A.B.C.D verlaat met als bestemming W.X.Y.Z, versleutel het dan met de benodigde beveiligingssamenwerkingen.”

“Als een pakket aankomt van W.X.Y.Z en het heeft A.B.C.D als bestemming, ontcijfer het dan met de benodigde beveiligingssamenwerkingen.”

Dat klopt bijna, maar niet helemaal. Als dit gebeurde, dan zou al het verkeer van en naar W.X.Y.Z, zelfs als dat geen deel uit zou maken van het VPN, versleuteld worden. Dat is niet wenselijk. Het correcte beleid ziet er zo uit:

“Als een pakket A.B.C.D verlaat en dat pakket bevat een ander pakket en als het W.X.Y.Z als bestemming heeft, versleutel het dan met de benodigde beveiligingssamenwerkingen.”

“Als een pakket aankomt van W.X.Y.Z en het pakket bevat een ander pakket en het heeft A.B.C.D als bestemming, ontcijfer het dan met de benodigde beveiligingssamenwerkingen.”

Dat is een subtiele aanpassing, maar wel noodzakelijk.

Beveiligingsbeleid wordt ook ingesteld met setkey(8). setkey(8) biedt een instellingtaal voor het definiëren van beleid. Instructies kunnen via STDIN gegeven worden of met de -f optie uit een bestand komen dat de instellingen bevat.

De instellingen op gateway host #1 (die het publieke IP adres A.B.C.D heeft) om al het uitgaande verkeer naar W.X.Y.Z te laten versleutelen is:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Deze commando's kunnen in een bestand (bv. /etc/ipsec.conf) gezet worden om uitgevoerd te worden:

# setkey -f /etc/ipsec.conf

spdadd vertelt setkey(8) dat er een regel toegevoegd moet worden aan de database met het beveiligingsbeleid. De rest van de regel geeft aan op welke pakketten dit beleid van toepassing is. A.B.C.D/32 en W.X.Y.Z/32 zijn de IP adressen en netmaskers waarmee het netwerk of de hosts worden aangegeven waarop het beleid van toepassing is. In dit geval is het van toepassing op het verkeer tussen twee hosts. ipencap vertelt de kernel dat dit beleid alleen van toepassing is op pakketten waarin een ander pakket ingepakt zit. -P out betekent dat dit beleid van toepassing is op uitgaande pakketten en ipsec betekent dat de pakketten beveiligd moeten worden.

Het tweede deel geeft aan hoe een pakket versleuteld wordt. esp is het protocol dat gebruikt moet worden en tunnel geeft aan dat het pakket ingepakt moet worden in een IPsec pakket. Het herhaalde gebruik van A.B.C.D en W.X.Y.Z heeft te maken met het aangeven welke beveiligingssamenwerking gebruikt moet worden en als laatste is het door require verplicht dat de pakketten versleuteld worden als deze regel van toepassing is.

Deze regel is alleen van toepassing op uitgaande pakketten. Er moet ook nog een regel komen voor inkomende pakketten.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Let wel dat hier dus in staat in plaats van out en dat de IP adressen zijn omgedraaid.

Op de andere gateway host (met een publiek IP adres W.X.Y.Z) zijn soortgelijke regels nodig.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Tenslotte moeten de firewalls ESP en IPENCAP pakketten naar beide kanten toestaan. Deze regels moeten op beide hosts toegevoegd worden.

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D

Omdat deze regels symmetrisch zijn, kunnen ze op beide gateway hosts gebruikt worden.

Uitgaande pakketten zien er nu ongeveer zo uit:

Als ze ontvangen worden door de andere kant van het VPN dan worden ze eerst ontcijferd (met de beveiligingssamenwerking die door racoon tot stand is gebracht). Daarna komen ze de gif interface binnen die de tweede laag uitpakt zodat het binnenste pakket overblijft, dan nu naar het interne netwerk kan reizen.

De beveiliging kan gecontroleerd worden met dezelfde ping(8) test die eerder is uitgevoerd, door eerst aan te melden op de A.B.C.D gateway machine en het onderstaande uit te voeren:

tcpdump dst host 192.168.2.1

In nog een sessie op dezelfde host kan dan het volgende commando uitgevoerd worden:

ping 192.168.2.1

Nu hoort de volgende uitvoer te zien te zijn:

XXX tcpdump output

tcpdump(1) toont nu de ESP pakketten. Als deze pakketten verder bekeken worden met de optie -s dan is de uitvoer onbegrijpelijk vanwege de versleuteling.

Gefeliciteerd. Nu is het VPN tussen de twee locaties opgezet.

Samenvatting

• Stel beide kernels in met:

  options IPSEC
  options IPSEC_ESP
  

• Installeer security/ipsec-tools. Wijzig ${PREFIX}/etc/racoon/psk.txt op beide gateway hosts en voeg een regel toe voor het IP adres van de host aan de andere kant en een geheime sleutel die aan beide kanten bekend is. Dit bestand hoort mode 0600 te hebben.

• Voeg de volgende regels toe aan /etc/rc.conf voor iedere host:

  ipsec_enable="YES"
  ipsec_file="/etc/ipsec.conf"
  

• Maak /etc/ipsec.conf op iedere host die de benodigde spdadd regels bevat. Op gateway host #1 zou dat zijn:

  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  

  En op gateway host #2 is dat:

  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  

• Voeg firewallregels toe om IKE, ESP en IPENCAP verkeer toe te staan naar beide hosts:

  ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
  ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
  ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
  ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
  

De voorgaande twee stappen zouden voldoende moeten zijn voor het opzetten van het VPN. Machines op ieder netwerk kunnen elkaar nu bereiken op basis van IP adressen en al het verkeer over de verbinding wordt automatisch en veilig versleuteld.