Adding SIP phones to an Allstarlink node

Introduction

Since the Allstarlink node is based on telephone switch (PBX) software (called Asterisk), it is possible to include a landline or VoIP telephone in the Allstarink community, allowing it to communicate and command the Allstarlink node with DTMF commands.

This short document gives step-by-step instructions in how to obtain this connection. You must be able to log into your Allstarlink node (with SSL or local console) and edit the configuration files in order to follow them.

Step 1: Preparing Asterisk for the SIP protocol

VoIP phones (and phone adapters) will use the SIP (Session Initiation Protocol) for setting up and taking down phone connections. By default, the Allstarlink’s configuration does not allow this, so it must be enabled in its configuration as follows:

Make the following modifications to /etc/asterisk/modules.conf:
Change the line: unload => chan_sip.so to load => chan_sip.so

Make the following modifications to /etc/asterisk/sip.conf:
In the section [general], change the line
bindaddr = 127.0.0.1 into bindaddr = 0.0.0.0 

Test procedure: Restart Asterisk with # service asterisk restart (the # sign indicates that this must be done in super user mode, write sudo bash to get there). Now the command $ netstat -anu should return a list with the following line included:

udp        0      0 0.0.0.0:5060            0.0.0.0:*

If not, fix the problem before moving to the next step.

Step 2: Register phone extension

The file /etc/asterisk/sip.conf must contain a list of extension numbers and related information. It should contain a number of sections like this:

[211]
type=friend
host=dynamic
username=211
secret=1234
dtmfmode=rfc2833
context=sip-phones
callerid="Anders-PC" <211>

In this example, the extension numbers are in the range 200-299. Make at least two copies of this section and change the numbers accordingly. The “secret” is a password used by the VoIP phone. If your Allstarlink node is reachable from the Internet, the password should be strong, not “1234”.

Test procedure: Restart Asterisk with # service asterisk restart. Install a SIP Phone app (often called softphone) on at least two devices in your network. I am using “MicroSIP” on Windows and “Mizudroid” on Android. Configure them according to the Allstarlink’s IP address, extension number and password. The following illustrations serves as an example on the MicroSIP configuration screen:

The MicroSIP main screen should now indicate “online” on the bottom line.

Configure two softphones on two different devices with different extension numbers, and make sure they are indicating a successful connection with the Allstarlink node. Do not move on to the next step until this is verified.

Step 3: Set up extension handling

The next step involves editing of /etc/asterisk/extensions.conf. First, make a copy of the original file in case you want to return to the original configuration later:

# cp extensions.conf extensions.conf.orig

Above the last line in the file (#includeifexist….) include this section in extensions.conf

[sip-phones]
exten => _2XX,1,Dial(SIP\/${EXTEN},60,rT)
exten => 300,1,Ringing()
exten => 300,n,Wait(2)
exten => 300,n,Answer()
exten => 300,n,rpt(51201|P); Change 51201 to your own node mumber
exten => 300,n,Hangup

The first exten-line allows the softphones to connect to each other, so we try this first. The lines with “exten => 300…” allows the phones to connect to the repeater. Remember to enter your own node number in the place of the “51201”

Test procedure: Restart Asterisk with # service asterisk restart. From one softphone, dial the number of the other and check that there is a voice connection between them. Connect also in the opposite direction. Do not move on until this is successful (there are often some problems in this step which needs to be sorted out.

Now you may try to dial “300” to connect to the repeater. You should hear one “ring” in the softphone and then silence. You are hopefully now connected to the repeater, and can command it with DTMF, e.g. *712 to have it say the time of day. You can connect the repeater to another node with *3xxxxxx and start talking. Your PTT is pressed with the *99 code and released with #.

Enjoy your new function and move on to the next step if you want to allow the repeater to connect to the softphones from a radio handset.

Step 4: Connecting to VoIP phones from a local radio handset

This step will enable a handset local to the Allstarlink node to set up a voice connection to a SIP phone using DTMF codes. To dial from a handset local to a different Allstarlink node does not require more configuration and is described in Step 5.

The file /etc/asterisk/rpt.conf should be modified as follows: Uncomment these lines around line no. 232 and give them this content:

61=autopatchup,noct=0,quiet=1,farenddisconnect=1,dialtime=5000
62=autopatchdn

These lines will allow the radio side to initiate a phone connection through the use of DTMF codes *61xxx and disconnect with *62 (unless the phone hangs up first). The call will be given the default context value “radio” and processed by the rules in extensions.conf.
There are several ways to modify this file to obtain the desired effect, one of which is shown here:

Modify the file /etc/asterisk/extensions.conf as follows: Make sure that the [radio] section has the following content:

[radio]
exten => _2XX,1,Dial(SIP/\${EXTEN})

The other lines in the same section should be commented out. The pattern _2XX matches the number range 200-299 and may be changed according to your own number plan.

This is the simplest possible modification to extensions.conf, but it breaks the neat logic in the distributed file. Please study this logic structure if you want a more “proper” modification.

You may not succeed in disconnecting with *62 if your repeater uses simplex communication (same frequency for transmit and receive) while the squelch indicator is lit. If noone picks up the phone, the ringing tone you hear in the handset will stop you from disconnecting (because the repeater doesn’t listen while it is transmitting), and you will have to wait until the ringing times out.

Test procedure: Restart Asterisk with # service asterisk restart. From a radio handset, dial *61210 (given that your SIP phone has extension 210). The phone should now ring, and when you answer the call you should be communicating with the handset without the use of DTMF codes *99 and #. You will still need to press PTT on the handset prior to talking. The phone is given a VOX function, which means that the handset should not press PTT while the squelch indicator is lit.

Step 5: Connecting to VoIP phones on a different node

It is now even possible to connect to a VoIP phone from a handset connected to a different Allstarlink node. With the radio handset, follow these steps:

  1. Connect to the other node (where the VoIP phone is connected) with DTMF *3xxxxx
  2. Set the other node in “command mode” with *4xxxxx (same node numer as in line 1)
  3. Call the VoIP phone with *61210 (given the extension 210)

Test procedure: Follow the steps above and observe the result. The comments from the test procedure in Step 4 applies as well.

Finally

I hope this little text may provide fun and a little experience in the configuration of Asterisk. Another fun addition is to connect a landline phone through a VoIP adapter, e.g. the Linksys SPA2102, which I bought from Ebay for $15. Get the nostalgic feeling of talking to a repeater net through a landline phone!

Finally, do not hesitate to send suggestions for improvements and clarifications.

Hvordan konfigurere et Virtuelt Privat Nett?

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.

Figur 1: En “rød” IP-forbindelse inne i en “sort” ip-forbindelse

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:

  1. Nett-til-nett, hvor to private lokalnett blir koplet sammen gjennom en beskyttet tunnel som om det sto en vanlig ruter mellom dem.
  2. Road warrior, hvor mange klienter kan kople seg til et lokalnett mens de er hjemme eller på reise. Også kalt host-til-nett.
  3. 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.

Figur 2: Nett-til-nett konfigurasjon av et VPN

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
Tabell 1: Konfigurasjonsfiler for Green og Blue

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
Tabell 1: Konfigurasjonsfiler for en ekstra tunnel

Forøvrig startes tunnel nr. 2 i et eget konsoll på samme måte som de andre.

2. Read 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.pem

Programmet 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

Tabell 2: Konfigurasjonsfiler for Host-til-nett bruk av OpenVPN

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.

Figur 3: Host-til-nett konfigurasjon av et VPN

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
Figur 4: OpenVPN konfigurert som svitsjet felles subnett.

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:

  1. Konfigurasjonsfilen på OpenVPN-tjeneren (Blue) kan bruke et server-direktiv for å tildele IP-adresser til klientenes tap0-adaptre, og push-direktiv for å gi rutinginformasjon.
  2. 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.
  3. 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:

Bygg din egen hjemmeruter med Raspberry Pi

En Raspberry Pi kan erstatte din hjemmeruter, eller komplettere hjemmeruteren med smarte og fleksible tilleggstjenester. Les mer om det her.

Innledning

En ruter er en datamaskin, og en datamaskin er en ruter.

Har du en Raspberry Pi eller en gammel datamaskin som du kan avse til dette formålet, kan du utvikle din egen hjemmeruter med flere funksjoner enn en “standard hjemmeruter”, og med større fleksibilitet for å møte dine behov. Her er noen eksempler:

  • Det er behov for å ha tjenermaskiner inne i ditt lokalnett, og du ønsker å anrope dem med internet-navn, ikke med IP-adresser.
  • Det er ønske om å bruke IP-protokoll versjon 6 (IPv6)
  • Du trenger å bruke Virtuell Private Nett, men ønsker ikke å kople dette opp og ned til stadighet. La ruteren gjøre dette og tilby adgangen til VPN for hele lokalnettet ditt.
  • Det er behov for å bruke en Dynamisk DNS-tjeneste, men ruteren støtter ikke den ene du ønsker å benytte deg av.
  • Du ønsker å kombinere ruteren med en web-tjener, en mediatjener, filtjener eller andre tjenester som hele lokalnettet skal kunne ha glede av.
  • Det er ønske om adgang til lokalnettet fra utsiden av ruteren (Internet), men også ønske om en sterkere beskyttelse mot angrep og hacking.
  • Ruteren skal brukes til “smart home” oppgaver.
  • Ruteren skal være en telefonsentral for Internet-telefoni

Denne artikkelen skal beskrive tre forskjellige måter å benytte en Raspberry Pi på, enten som fullstendig erstatning for hjemmeruteren, eller som et supplement hvor større eller mindre deler av tjenestene i ruteren beholdes slik de er, men suppleres av Raspberry Pi. Disse tre alternativene er vist som alternativ a-c på Figur 1.

Figur 1: Tre måter å bruke Raspberry Pi på

I alternativ (a) har Raspberry Pi helt erstattet hjemmeruteren, og tar hånd om kontakten med Internet-leverandøren og spredningen i lokalnettet med Ethernet og WiFi. Alternativ (b) lar Raspberry Pi besørge kontakten med Internet, mens hjemmeruteren er beholdt for spredning til lokalnettet. I alternativ (c) har hjemmeruteren som tidligere kontakt med Internet og ansvaret for spredning i lokalnettet, mens Raspberry Pi utfører et sett med ektraoppgaver for å gjøre nettet med funksjonelt og fleksibelt.

Figur 2 viser et funksjonsdiagram for en hjemmeruter. Ruteren tilbyr tjenester knyttet til DNS, DHCP, NAT, brannvegg, ruting, vitsjing, og muligens VPN. Alt dette skal erstattes av en Raspberry Pi om alternativ 1 realiseres. Alternativ 2 er vist som den grønne firkanten nede til høyre, hvor ruterens spredefunksjoner for Ethernet og WiFi er beholdt, og ikke besørget at Raspberry Pi.

Figur 2: Funksjonelt diagram av en hjemmeruter

De neste avsnittene vil drøfte fordeler og ulemper med de ulike alternativene, og gi en del veiledning i hvordan de kan realiseres.

a. Raspberry Pi som selvstendig hjemmeruter

En Raspberry Pi (heretter kalt RPi) har et WiFi-adapter og et Ethernet-adapter innebygget, samt 4 USB-porter. Ethernet-adapteret (kalt eth0) koples til Internet-kontakten. WiFi-adapteret settes opp som et aksesspunkt (AP) som maskiner på lokalnettet kan kople seg til.

Om man i tillegg ønsker Ethernet-kabling i lokalnettet løses dette ved å anskaffe Ethernet-adaptere med USB-plugg. Man kan plugge inn flere slike, eller kople den til en Ethernet-svitsj. Denne artikkelen vil videre vise hvordan et slikt USB-Ethernet-adapter skal konfigureres. Du trenger egentlig ikke kjøpe en egen Ethernet-svitsj, fordi din gamle hjemmeruter kan brukes til dette.

Linux tillater ikke lenger at maskiner tilkoplet henholdsvis WiFi og Ethernet befinner seg i samme IP subnett. Derfor blir det laget to separat subnett for disse. I eksemplene brukes IP-adressene 192.168.3.0/24 og 192.168.4.0/24 for disse to.

Grunnkonfigurasjonen av en RPi blir ikke forklart her. Du kan gjerne laste ned en “lite”-versjon av operativsystemet for å spare plass, fordi du ikke får bruk for et grafisk betjeningssystem allikevel. Likeså blir ikke grunnleggende betjening av RPi forklart, så finn ut hvordan man logger seg inn, restarter osv.

Kommandoer som innledes med #-tegnet krever administrator (sudo) tillatelser. Skriv sudo bash for å oppnå dette. Kommandoer som innledes med $-tegnet krever ikke dette.

Programvare som må installeres

Du installerer en rekke ekstra programmer i RPi for å komme i gang. Dette er programmer som kreves for de ulike oppgavene.

# apt-get update
# apt-get install hostapd openvpn dnsmasq dnsutils lighttpd

For å installere en såkalt pubsub-broker: # apt-get install mosquitto
For å installere en telefonsentral: # apt-get install asterisk
For å installere filtjener: # apt-get install samba
For å installere Dynamic DNS-klient: # apt-get install ddclient

(Under installasjonen av ddclient kreves det noen svar på konfigurasjonsspørsmål, men man kan skrive inn hva som helst her. Siden skal riktige konfigurasjonsfiler skrives).

Sett maskinen til å rute ipv4:

# nano /etc/sysctl.conf

Sett inn linjen net.ipv4.ip_forward=1 (fjern evt. kommentar tegn foran linjen som allerede finnes der). Reboot er nødvendig, men det kan vente til senere.

Fjerne også kommentargnet på linjen net.ipv6.conf.all.forwarding=1 om det er ønske om å tillate bruk av IPv6.

Tildele adresser til adaptrene

Skriv følgende innhold i filen /etc/network/interfaces:

# nano /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
    address 192.168.3.1/24
auto wlan0
iface wlan0 inet static
    address 192.168.4.1/24

Sett opp WiFi aksesspunkt

Programmet hostapd setter opp WiFi-adapteret som et Aksesspunkt, som andre maskiner kan kople seg til.

# nano /etc/default/hostapd

Endre linjen DAEMON _CONF= til DAEMON_CONF=”/etc/hostapd/hostapd.conf” (husk anførselstegnene)

# nano /etc/hostapd/hostapd.conf

Sett inn dette innholdet:

interface=wlan0
ssid=MinHjemmeruter
country_code=NO
hw_mode=g
channel=7
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=MittPassord
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_group_rekey=86400
ieee80211n=1
wme_enabled=1

(teksten i rødt kan du erstatte med dine egne verdier)

# systemctl unmask hostapd
# systemctl enable hostapd

NB! Hostapd-tjenesten har erfaringsmessig problemer med enkelte WiFi-kretser, inkludert noen som står på RPi-kretskortet. Om det ikke lykkes å få dette til å virke, vurder heller alternativ (b), som overlater WiFi-kontrollen til den eksisterende hjemmeruteren.

Sette opp DHCP- og DNS-tjeneste

Programmet dnsmasq vil sørge for disse tjenestene, og programmet konfigureres ved å redigere filen /etc/dnsmasq/dnsmasq.conf. På eksemplet nedenfor vises at det tilbys IP-adresser til klienter som kopler seg til eth1 og wlan0, siden IP-adressene på disse adaptrene omfattes av de to dhcp-range setningene. Server-ordet brukes for å si hvor dnsmasq skal videresende DNS-spørringer som den ikke kan svare på med opplysningene i /etc/hosts.

# nano /etc/dnsmasq/dnsmasq.conf
server=8.8.8.8
dhcp-range=eth1,192.168.3.100,192.168.3.200,255.255.255.0,24h
dhcp-range=wlan0,192.168.4.100,192.168.4.200,255.255.255.0,24h

Denne konfigurasjonen medfører at klienter som kopler seg til Ethernet får tildelt en adresse i området 192.168.3.100-200, mens WiFi-klienter får tildelt adresser i området 192.168.4.100-200. Alle får tildelt adressen til RPi som default gateway og DNS-tjener. DNS-tjeneren vil hente data fra 8.8.8.8 (Googles DNS-tjener) dersom den ikke finner navneopplysninger i /etc/hosts eller i egen DNS-tjener.

Dnsmasq har mange konfigurasjonsmuligheter for å f.eks. reservere bestemte adresser til tjenermaskiner osv. Dette beskrives i dnsmasq.conf slik:

dhcp-host=11:22:33:44:55:66,192.168.3.25

Merk at i dette tilfellet vil maskinen med denne MAC-adressen kun få den reserverte IP-adressen dersom den er koplet via Ethernet, ikke via WiFi. Ellers vil den få en dynamisk adresse.

Hver gang det er gjort endringer i /etc/dnsmassq.conf eller /etc/hosts må den laste inn konfigurasjonsfilen på nytt. Det gjøres med denne kommandoen:

# service dnsmasq restart

Konfigerere brannvegg og NAT-funksjon

Programmet iptables styrer noen kompliserte filter- og behandlingsfunksjoner i nettverksprogramvaren. Her følger de reglene som gir en fornuftig brannvegg og NAT (Network Address Translation, klikk her for en egen beskrivelse).

Iptables kan konfigureres på flere måter, men vi nøyer oss i denne omgang med å bruke kommandoer som skrives inn i et konsollvindu, eller lagres i et skall-skript. Et eksempel på en fornuftig konfigurasjon av iptables er vist under, under den forutsetning at adaptrene eth1 og wlan0 er koplet til lokalnettet som skal beskyttes mot angrep fra Internet via eth0. Denne listen av kommandoer legges inn i filen /etc/rc.local slik at kommandoene utføres når maskinen starter opp.

iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -i wlan0 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i eth0 -m conntrack --ctstate ESTABLISHED,RELATED 
		-j ACCEPT (på samme linje som over)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


Port forwarding:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 
                 -j DNAT --to 10.10.3.10:8080 (på samme linje som over)
iptables -A FORWARD -p tcp -d 10.10.3.10 --dport 8080 -j ACCEPT

Linjen merket i rødt er eksempel på regler som slipper inn helt spesifikk trafikk. I dette tilfellet slipper UDP-segmenter til port 1194 inn til RPi, som er endepunktet for OpenVPN-tjenesten.

I andre sammenhenger ønsker man å gjøre tilgjengelig tjenester på maskiner inne i lokalnettet, noe som løses med såkalt port forwarding. Metoden går ut på at UDP- eller TCP-trafikk med en bestemt mottakerport sendes videre til en spesifikk adresse på lokalnettet. IP-adressene endres fra ruterens eth0-adresse til den lokale tjenestens adresse, og portnummret kan endres om ønskelig. Eksemplet nedenfor viser en port forwarding regel som sender innkommende TCP-pakker med mottakerport 80 videre til adressen 10.10.3.10 og port 8080. En tjeneste på dette endepunktet vil dermed bli gjort tilgjengelig for omverdenen på adressen til eth0-adapteret og port 80. Slike port forwarding-regler legges sammen med de øvrige brannvegg-reglene vist ovenfor i filen /etc/rc.local.

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 (linjen fortsetter)
         -j DNAT --to  10.10.3.10:8080
iptables -A FORWARD -p tcp -d 10.10.3.10 --dport 8080 -j ACCEPT

Tjenester til omverdenen – Dynamisk DNS

Tjenester i lokalnettet kan gjøres tilgjengelig for omverdenen ved hjelp av port forwarding. Da vil du trenge å knytte IP-adressen på eth0-adapteret til et DNS-navn (Internet-navn) slik at andre kan finne frem til tjenesten din. Dette fordrer at du kjøper (eller får gratis) en DNS-tjeneste fra et web-hotell eller lignende. Man kan reservere egne DNS-domener eller registrere seg i et eksisterende, men dette ligger utenfor temaet for denne artikkelen.

Eth0-adapteret får en dynamisk IP-adresse fra Internet-leverandøren som skiftes regelmessig, og det skaper problemer for slik DNS-registrering. Det trengs derfor en mekanisme som oppdaterer DNS-databasen i web-hotellet hver gang eth0 får en endret IP-adresse. Dette besørges av et program som kalles ddclient og som innledningsvis ble installert på RPi.

Programmet ddclient overvåker IP-adressen på eth0 og gir beskjed om endringer til en leverandør av Dynamic DNS, heretter kalt DDNS. Det er flere slike DDNS-leverandører, og noen få tilbyr en enkel gratistjeneste, mens en “premium” tjeneste koster litt penger. I dette eksemplet blir det vist konfigurasjon mot tjenesten noip.com.

# nano /etc/ddclient.conf
- Filen skal ha slikt innhold:
use=web
ssl=yes
protocol=noip
login=<noip brukernavn>
password=<noip password>
<valgt DNS-navn>

# nano /etc/default/ddclient
- Filen skal ha slikt innhold:
run_dhclient=”false”
run_ipup=”false”
run_daemon=”true”
daemon _interval=”300”

- Sett opp ddclient som en kjørende tjeneste i RPi på denne måten:
# sudo service ddclient start

- Jeg er usikker på om denne "pollingen" har en betydning. Man må uansett
  bekrefte adressen manuelt minst månedlig.
# nano /etc/cron.weekly/ddclient
- Filen skal ha dette innholdet
#!/bin/sh
/usr/sbin/ddclient -force

- Sett så filen “executable” med kommandoen
# chmod +x /etc/cron.weekly.ddclient

Konfigurasjon av OpenVPN

Virtual Private Networks (VPN) kan tilby beskyttede koplinger mellom private nettverk, slik at man f.eks. kan bruke arbeidsplassens IT-ressurser hjemmefra eller på reise, at et felles laboratorium kan utnyttes av mange firmaer i fellesskap uten å gi adgang inn i hverandres nettverk. Ikke minst åpner også VPN en mulighet for å nå inn til alle adresser i det lokale nettet fra en hvilken som helst posisjon i Internet slik at de tjenestene som etableres i lokalnettet kan benyttes på reise o.l.

Det finnes flere produkter som kan tilby slike VPN-tjenester, men her vil OpenVPN brukes, fordi det er enklere å konfigurere enn StrongSwan/IPSec. OpenVPN ble installert innledningsvis og noen eksempler på konfigurasjon er omtalt i en annen post.

b. Raspberry Pi som ruter, men uten WiFi

Alternativ (a) slik som beskrevet over gir god kontroll over rutingen, bruk av VPN, egne DNS-navn og diverse tilleggstjenester. Men den har noen ulemper som er nødvendig å leve med:

  • Linux-kjernen er ikke villig til a svitsje mellom WiFi og Ethernet, så tilkoplede klienter vil tilhøre to IP-subnett. Det betyr at trafikk som ikke kan rutes mellom subnettene (f.eks. uPnP og SSDP) vil hindre noen ellers nyttige tjenester.
  • Det er erfaringsmessig en del bugs knyttet til Hostapd-programvaren som skal sette opp WiFi-adapteret i AP-modus.
  • WiFi-adapteret på Raspberry Pi har liten utgangseffekt og ingen utvendig antenne, så det kan ikke påregnes å ha den samme rekkevidden og overføringskapasitet som en egen hjemmeruter.

Om disse ulempene gjør alternativ (a) uakseptabelt kan alternativ (b) brukes, slik det er vist i Figur 1. Her legges ruterfunksjonene til RPi og lokalnettfunksjonene til hjemmeruteren. Ruterfunksjonen i hjemmeruteren benyttes ikke, og RPi’s eth1-adapter koples til en LAN-port på ruteren. DHCP-tjenesten på hjemmeruteren kan ikke kombineres med DHCP-tjenesten i Dnsmasq (på RPi) så én av dem må skrus av. Anbefalingen er å skru av DHCP-tjenesten i hjemmeruteren.

Fordelen med denne konfigurasjonen vil være at alle klienter på lokalnettet (tilkoplet via Ethernet eller WiFi) vil være på samme subnett og kan få DHCP-adresser fra samme adresseområde. Konfigurasjonen av Dnsmasq blir noe forenklet, og all konfigurasjon av WiFi-adapteret på RPi kan sløyfes, inkludert oppsettet av Hostapd. VPN-, NAT- og brannvegg-konfigurasjonen på RPi blir den samme som før.

Alternativ (b) gir den samme fleksibilitet i ruting- og sikkerhetsfunksjonene, og overlater lokalnett-funksjonene til en enhet med flere ethernet-porter og bedre rekkevidde for WiFi-signalet.

c. Rapsberry Pi med ekstra ruterfunksjoner

Alternativ (b) dekker det samme som alternativ (a), men med et mulig gjenstående problem knyttet til ytelse. En Raspberry Pi har begrenset overføringskapasitet, og en mulig forbedring vil være å la hjemmeruteren besørge ruting- brannvegg- og NAT-funksjonene i tillegg til lokalnettfunksjonene slik som i alternativ (b), mens RPi besørger de ønskede ekstratjenestene, som DNS, VPN, web-tjener, filtjener osv.

Alternativ (c) er vist på Figur 1 hvor hjemmeruteren står koplet på sin vanlige plass, og en RPi er tilkoplet på lokalnettsiden. Dette er endringer som må gjøres i konfigurasjonsn av hjemmeruteren:

  • DHCP må skrus av
  • DNS vil ikke være i bruk, og kan skrus av om mulig
  • VPN-trafikk må slippes inn til RPi. Det kreves derfor an port forwaring regel for UDP-trafikk på port 1194
  • Applikasjonstjenester som skal være tilgjengelig fra Internet (utenom en VPN-tunnel) må gis en port forwarding-regel.

RPi får nå den viktige oppgaven med å besørge en DHCP-tjeneste. DHCP-tjenesten forsyner lokale maskiner med IP-adresse/nettmaske, IP-adressen til DNS-tjenesten og evt. ekstra rutinginformasjon.

RPi skal gjennom DHCP-tjenesten sørge for at “vanlig” internet-trafikk (web-surfing, meldingsformidling m.m.) rutes til hjemmeruterens adressse (gjennom opplysninger om default gateway) og dermed ikke bidrar til noen flaskehals i RPi. Trafikk til adresser som inngår i VPN-tunneler blir derimot rutet til RPi, som vedlikeholder alle endepunkter for tunnelene. DNS-tjenesten i RPi (med Dnsmasq) skal lagre internet-navn (dns-navn) med IP-adresser for alle lokale tjenester, samt endepunkter som når gjenom VPN. Forespørsler om andre adresser vidersendes til hjemmeruteren. RPi må også besørge oppdatering av en DDNS-tjeneste når ruterens ytre adresse endres.

Med en slik konfigurasjon vil RPi begrense seg til DHCP-, DDNS- og DNS-tjeneste samt besørge trafikk gjennom VPN-tunnelene. Annen trafikk, samt oppgaver knyttet til NAT-funksjon og brannvegg (som er potensielt ganske krevende) vil betjenes av hjemmeruteren. Konfigurasjonen av RPi vil derfor begrense seg til å konfigurere Dnsmasq for DHCP- og DNS-trafikk, ikke helt ulikt alternativ (a), men med disse forskjellene i dnsmasq.conf:

  • Default gateway skal ikke være DHCP-tjenestens IP-adresse, men hjemmeruterens. Dette må angis eksplisitt med dhcp-option=3,192.168.4.1 (hjemmeruterens lokaladresse)
  • Dersom alle VPN-tunnelene kan samlet i et fåtall subnett, kan disse adressene rutes til RPi (som i dette eksemplet har IP-adresse 192.168.4.2). Lokale maskiner må derfor ha rutinginformasjon for å rute disse subnettene dit. I dnsmasq.conf uttrykkes dette slik: dhcp-option=121,10.10.0.0/16,192.168.4.2 (10.10.0.0/16 er eksempel på VPN-subnett).
  • DHCP-tjenesten trenger nå kun én dhcp-range, siden lokalnettet kun er ett subnett.

Alternativ (c) krever noe mer vedlikehold knyttet til endringer i VPN-konfigurasjonene, idet det kan kreve at ny rutinginformasjon blir utdelt. Alternativ (c) er mindre fleksibelt siden f.eks. brannvegg- og NAT-funksjonene ikke kan konfigureres så fritt som om de besørges av iptables i RPi. Om IP versjon 6 er nødvendig å ta hensyn til, så kan også hjemmeruteren representere en begrensning, siden slike produkter i varierende grad kan behandle IPv6-trafikk.

Oppsummering

Denne artikkelen har forklart hvordan du på ulike måter kan konfigurere en RPi for å videreutvikle hjemmenettverket med flere og bedre tjenester. Tre alternativer er presentert med sine fordeler og ulemper. I tillegg til et forbedret og videreutviklet hjemmenett vil du oppnå mye ferdigheter i bruk av Linux, feilsøking i nettverk og forståelse av prinsippene bak IP-protokollen.

Ekstralesning:

Hva er Network Address Translation?

Kan du finne ut hvilken IP-adresse maskinen din bruker når du bruker Internet hjemmefra? Om du har en Windows-maskin kan du hente frem et konsollvindu (skriv Win-R og CMD), skrive ipconfig og trykke enter. Da får du listet opp informasjon om alle nettverksadaptrene på maskinen, inkludert det som du bruker for å kommunisere med Internet. Finn ut hvilken IP-adresse som brukes.

Figur 1: IP-adressen lokalt på Ethernet-adapteret



Bruk så web-leseren på maskinen for å finne ut hvilken IP-adresse andre ser når du kommuniserer. Hent web-siden http://fongen.no/myip.php og noter den IP-adressen som fremkommer. Sammenlign disse to verdiene, og med stor sannsynlighet er de ulike.

Figur 2: IP-adressen som web-tjeneren “ser”



Denne observasjonen viser at den IP-adressen som maskinen din er konfigurert med, ikke er den som vises ut på nettverket. Om du sjekker denne adressen med andre som bruker det samme lokalnettet (skole, jobb, hjemme), vil du trolig observere at alle bruker den samme IP-adressen ut mot selve Internet, selv om de har sin egen adresse på maskinen sin.

Heretter vil vi omtale maskinen som endepunkt, fordi det ikke bare er datamaskiner som er koplet til nettet. Et endepunkt skiller seg fra en ruter ved at den ikke videresender andres IP-pakker.

Årsaken til at endepunktene opererer med to ulike adresser på denne måten, har å gjøre med knappheten på IP-adresser. IP-adressen har 32 biter, og det kan derfor ikke være flere adresser på Internet enn litt mer enn 4 milliarder. Antall endepunkter som bruker Internet er mye større enn dette tallet, og de som styrer Internet måtte finne en måte å dele på Internet-adresser for at alle skulle «få plass». Denne prosessen går ut på at alle på et lokalnett deler den samme IP-adressen mot Internet, og at den «interne» IP-adressen, altså den som er konfigurert på selve endepunktet, ikke er unik, men finnes også på endepunkter i andre lokalnett.

Erstatter IP-adresser i ruteren

Figur 3: Her vises hvordan IP-pakkens avsender- og mottakeradresser endres idet den passerer gjennom en NAT-enhet. Kilde: Wikipedia

Figur 3 viser et forenklet bilde av hvordan hjemmeruteren din bedriver noe som kalles Network Address Translation, forkortet NAT.

  • En IP-pakke som sendes fra endepunktet (“Host”) til Internet får sin avsender IP-adresse erstattet med ruterens eksterne IP-adresse, dvs. adressen på det adapteret som er koplet til Internet, i dette tilfellet 150.150.0.1.
  • En IP-pakke som ankommer fra Internet vil ha mottagers IP-adresse lik den på ruteren (150.150.0.1), og den vil bli erstattet med endepunktets IP-adresse, i dette tilfellet 10.0.0.1. Så vil pakken bli sendt til dette endepunktet på lokalnettet.

Dette arrangementet vil være “usynlig” både for endepunktet og web-tjeneren (“Server”), som kommuniserer som om de hadde en virkelig IP-rute seg i mellom. Endepunktet “ser” web-tjeneren med dens virkelig IP-adresse, og web-tjeneren “ser” ruteren (150.150.0.1) som sin klient.

Erstatter portnumre i ruteren

Siden endepunktet til venstre på Figur 3 ikke er alene i dette lokalnettet, men deler internet-forbindelsen med mange andre, er det et nærliggende spørsmål om hvordan ruteren erstatter mottakeradresser på innkommende IP-pakker: Hvilken av de lokale endepunktene skal motta pakken?

Løsningen på dette problemet finner vi i TCP-protokollen. Mange slags nettverksprogrammer benytter seg av TCP-protokollen for å transportere data mellom to prosesser på en kontrollert og pålitelig måte. Prosessene som er endepunkter i en TCP-forbindelse kjennetegnes ved to portnumre, og mellom to endepunkter har alle TCP-forbindelser unike par av portnumre.

En TCP-forbindelse kjennetegnes ved IP-adressene til endepunktene og de portnumrene som brukes av prosessene i hver ende. Et endepunkt som sender TCP-trafikk påført avsender port X vil motta TCP-trafikk påført mottaker port X, dvs. at TCP-protokollen forutsetter at samme portnummer benyttes for å sende og motta trafikk.

Ved å studere både avsender IP-adresser og TCP-mottakerportnummer i kan NAT-enheten videresende innkommende IP-pakker til riktig endepunkt på lokalnettet. NAT-enheten vedlikeholder en tabell for dette formålet, som har disse kolonnene:

Innside IPUtside IPInnside portInnside ny portUtside port
10.6.6.6182.6.4.222227777443
10.6.6.6228.2.4.63333888880
10.6.6.6328.2.4.63333999980
Tabell 1: NAT-tabellen i samsvar med Figur 4

Tabellkolonnene skal forstås på denne måten:

  1. Innside IP er den lokale IP-adressen til endepunktet bak NAT-enheten
  2. Utside IP er Internet-adressen til motsatt endepunkt (altså ikke NAT-enhetens Internet-adresse)
  3. Innside port er nummeret på TCP-porten som benyttes av det lokale endepunktet
  4. Innside ny port betegner et portnummer som erstatter Innside port i TCP-trafikk som sendes til Internet
  5. Utside port er nummeret på TCP-porten som brukes av motsatt endepunkt

Når NAT-enheten mottar en IP-pakke med innhold fra TCP-protokollen vil den lete i denne tabellen etter verdier i kolonnene 2, 4 og 5 som svarer til IP-pakkens avsenderadresse og TCP-portnumre. Så vil IP-pakkens mottakeradresse erstattes med verdien i kolonne 1, og nummeret for TCP-mottakerport vil erstattes med verdien i kolonne 3.

Figur 4 viser hvordan NAT-tabellen vist ovenfor kan bidra til å skille trafikk til tre endepunkter på lokalnettet. Endepunktene B og C benytter samme TCP avsenderport 3333 til samme endepunkt (28.2.4.6), derfor trenger vi kolonne 4 til å erstatte avsenderporten med et unikt tall, i dette tilfellet 8888 og 9999.

Dynamic PAT - Inbound Response Flow
Figur 4: Kilde: https://www.practicalnetworking.net/series/nat/dynamic-pat/

TCP-protokollen har enda en egenskap som forenkler vedlikeholdet av NAT-tabellen, nemlig at all trafikk forusetter en oppkopling, og siden en nedkopling av forbindelsen. En melding fra et lokalt endepunkt om å kople opp en forbindelse vil observeres av NAT-enheten som henter ut nødvendige opplysninger til kolonne 1, 2 3 og 5, og oppretter så en ny rad. Tilsvarende vil en melding om å kople ned forbindelsen bidra til at denne raden slettes igjen.

NAT ved bruk av UDP-protokoll

Som nevnt i forrige avsnitt har TCP-protokollen de nødvendige egenskaper for at NAT-enheten kan opprette og slette rader i NAT-tabellen. Dessuten foregår all trafikk mellom endepunktene mellom det samme paret av portnumre.

For nettverksprogrammer som bruker UDP-protokoll gjelder ikke dette. Her skjer det ingen opp- eller nedkopling av noen forbindelse, men IP-pakkene med UDP-trafikk sendes uten videre. Ofte vil UDP-kommunikasjons benytte det samme paret av portnumre for trafikk begge veier, men det er ikke et krav. Dette kompliserer vedlikeholdet av NAT-tabellen betraktelig, og NAT-enheten må ty til noen “hacks” for å gjøre så godt den kan:

  1. En UDP-pakke som sendes fra et lokalt endepunkt og som ikke har en rad i NAT-tabellen for behandling, vil medføre at det opprettes en slik rad, knyttet til en tidsfrist. Dersom det ikke sendes eller mottas noe UDP-trafikk som passer til denne raden innenfor denne tidsfristen vil raden slettes.
  2. NAT-enheten kan være programmert med kunnskap om nettverksprogrammer som benytter UDP-porter på en uregelmessig måte (f.eks. at programmet sender og mottar på ulike portnumre). I slike tilfeller vil det genererer flere rader i NAT-tabellen for å ivareta dette forholdet.

Som det fremgår av disse mekanismene vil det ikke finnes noen garanti for at et UDP-basert nettverksprogram vil fungere gjennom en NAT-enhet basert på disse mekanismene alene. Derimot kan gjenværende problemer løses med bruk av port forwarding.

Port forwarding gjennom NAT-enheten

Det er kun når en TCP-forbindelse koples opp fra et endepunkt i lokalnettet at NAT-enheten kan sette opp NAT-tabellen riktig, det er nemlig kun da at dette endepunktet kan identifiseres med sin lokale IP-adresse. Noe lignende gjelder også UDP-trafikk, at det er kun når den første IP-pakken med UDP-innhold kommer fra et lokalt endepunkt at NAT-tabellen kan settes opp slik at den siden kan videresende IP-pakker til riktig endepunkt i det lokale nettet (på “innsiden” av NAT-enheten).

Dette er til hinder for at et endepunkt i det lokale nettet kan virke som en tjener for endepunkter i Internet. Dersom en slik konfigurasjon er ønskelig, f.eks. at du ønsker å sette opp en web-tjener på et endepunkt i hjemmenettverket ditt, kan du sette opp NAT-enheten med faste regler for å vidersende IP-pakker basert på TCP- eller UDP-mottakerporten. For en web-tjener er dette normalt port 80, og en regel for port forwarding av web-trafikk trenger å vite den lokale IP-adressen til dette endepunktet.

Port forwarding vil gjøre at NAT-enheten erstatter IP-pakkens mottageradresse på innkommende IP-pakker, og avsenderadressen for utgående IP-pakker.

Port forwarding kan også bidra til at ukurante UDP-baserte programmer kan kjøres over NAT-enheten. Husk derimot at port forwarding er en sikkerhetsrisiko, fordi dette lokale endepunktet kan, om det blir overtatt av en kjeltring, bli et springbrett for å angripe andre endepunkter på det lokale nettet.

Hvilke adresser kan benyttes i det lokale nettet?

De IP-adressene som benyttes på det lokale nettet kan ikke også brukes i Internet, fordi de ikke vil kunne nås fra endepunkter i det lokale nettet. Det er derfor satt av Private Address Space, tre forskjellige adresseserier som ikke skal brukes på endepunkter i Internet, kun i lokale nettverk tilkoplet gjennom en NAT-tjeneste. Disse adresseområdene er:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Når lokale nett bak en NAT-enhet skal konfigureres skal endepunktene ha adresser innenfor disse områdene.