Operativt sambandsnett med DMR

Denne artikkelen vil presentere Digital Mobile Radio (DMR) og hvordan et sambandsnett kan utformes og betjenes med denne teknologien.

Anders Fongen, juni 2021

Innledende om sambandsnett

Med begrepet sambandsnett siktes det til kommunikasjonstjenester til støtte for redningsoperasjoner, katastrofearbeid, krigføring, store bygge- og anleggsprosjekter osv. Operasjonen kan være iverksatt av flere samarbeidende organisasjoner med et ledelseselement og et antall lag under denne ledelsen. Operasjoner er dynamiske, både med tanke på organisasjonens sammensetning av personell og fagområder, og med tanke på det geografiske området som omfattes av operasjonen.

Kommunikasjonsveiene i en operasjon er skjematisk vist på Figur 1 og kan inndeles på følgende måte:

  1. Ordregivning omfatter beskjeder om ledelsesbeslutninger som gis nedover i organisasjonshierarkiet til et antall lag.
  2. Situasjonsrapport omfatter beskjeder fra utførende lag til ledelsen som bygger opp et situasjonsbilde. Situasjonsrapporter kan bestå av posisjonsangivelser, personellopplysninger, ressursanmodninger, geografiske opplysninger osv.
  3. Synkronisering er informasjon som utveksles mellom sideordnede elementer i organisasjonen for å støtte nødvendig samordning.
Figur 1 – Kommunikasjonsveier i en sambandsoperasjon

Innad i lagene er det også et mulig sambandsbehov som følger et lignende mønster, men er ikke vist på Figur 1. Et lag vil typisk ha en lagfører som er kontaktpunktet til ledelseselementet.

Ønskede egenskaper ved et sambandsnett

For å gi tilfredsstillende kommunikasjonstjenester til en dynamisk og sammensatt operasjon er det en del krav som et sambandsnett må oppfylle:

  • Kanatilgjengelighet – Når en melding (tale, data) skal sendes langs en av linjene som vist i Figur 1 er det nødvendig at en kanal er tilgjengelig, og at denne kanalen har kapasitet og egenskaper forøvrig for overføringen. Ofte vil kanalen være opptatt, og det er da av betydning at kanalen blir ledig tidsnok til at meldingen oppfyller sin hensikt.
  • Separasjon av meldingstyper – Dersom alle meldinger blir mottatt av alle radioer i operasjonen vil dette forstyrre uvedkommende personell. Det er et mål at mottatte meldinger skal være relevante og nyttige for mottakeren, og ikke bidra til distraksjoner og svekket fokus på oppgavene. For å oppnå dette må ulike meldingstyper gis ulik utbredelse i sambandsnettet.
  • Tilstrekkelig dekningsområde – Meldinger må kunne sendes til alle aktører i operasjonsområdet i henhold til meldingstype. Dette innebærer ikke at alle meldingstyper skal kunne mottas overalt, men kun av aktuelle mottakere av den gitte meldingstypen. Lag trenger f.eks. ikke å være innen rekkevidde for synkroniseringsmeldinger mellom ledelseselementer.
  • Trygghetsfunksjoner – For bedret personellsikkerhet er det ønskelig at det kan formidle nødsignaler, alarmer, og posisjoner. Slike meldinger har hast og må kunne prioriteres i nettet og være gjenstand for særskilt betjening i radioutstyret (alarm-knapp, “dødmanns”-knapp).
  • Sikring mot misbruk – Det er ønskelig at nettet er beskyttet mot inntrengning og avlytting av uvedkommende. Falske meldinger kan forstyrre operasjonen, og meldinger under en redningsoperasjon kan f.eks. inneholde sensitive helseopplysninger. Det er også ønskelig at alle meldinger vises med identifisert avsender.
  • Posisjonsangivelser – Mange radioer har innebygd GPS-mottaker og mulighet for å formidle sin posisjon på radiosambandet. Slike meldinger kan inngå i “flåtestyring” og i trygghetsfunksjoner.

Analog vs. digital transmisjon

Teknologien som skal presenteres i denne artikkelen benytter såkalt digital transmisjon, i motsetning til tradisjonelle radioer med analog (frekvensmodulert) transmisjon. Forskjellen på disse to formene er vist på Figur 2, hvor utstrålt radioenergi blir plottet langs en horisontal tidsakse.

Figur 2 – Analog vs. digital transmisjon
  • Analog transmisjon representerer et lydsignal, hvor amplituden (energinivået) i signalet kan ha et stort antall verdier. Forstyrrelser som oppstår under overføring vil påvirke det mottatte lydsignalet i form av forstyrrelser og støy. Jo lengre avstand det er mellom sender og mottaker jo dårligere vil kvaliteten på det mottatte lydsignalet være.
  • Digital transmisjon representerer en bitstrøm, og radiosignalet vil representere enten en 0-bit eller 1-bit. Forstyrrelser som oppstår under overføring kan i noen utstrekning rettes opp, fordi det er bare to mulige tilstander av signalet. Dette bidrar til at bitstrømmen overføres riktig også gjennom en dårlig radioforbindelse. Bitstrømmen som overføres kan inneholde et digitalisert lydsignal, tekst, posisjon, et digitalisert bilde m.m. Digital transmisjon kan derfor støtte mange ulike meldingsformer.

Figur 3 viser hvordan digital transmisjon presenterer et utmerket lydsignal mens signalet blir svakere, før det brått blir meget dårligere. Analog transmisjon gir et gradvis dårligere lydsignal etter hvert som avstanden øker.

Figur 3 – Oppfattet lydkvalitet for henholdsvis analog og digital transmisjon.
Kilde: REPORT ITU-R M.2474-0

Digital Mobile Radio i hovedtrekk

Digital Mobile Radio (DMR) betegner en spesifikasjon for et digitalt radiosystem, laget av organisasjonen ETSI. Spesifikasjonen er åpen, dvs. at alle kan produsere radioutstyr uten å betale for en lisens, og det finnes derfor DMR-radioer å kjøpe fra mange ulike produsenter som i noen utstrekning kan brukes om hverandre i samme sambandsnett. Andre nøkkelegenskaper ved DMR er:

  • De bruker radiokanaler med båndbredde på 12.5 kHz. Man kan derfor bruke eksisterende FM-kanaler (altså frekvenser som er tildelt FM-samband) uten videre med DMR-radioer. Dette er en stor fordel for organisasjoner som allerede disponerer FM-kanaler til eksisterende sambandsutstyr. De trenger altså ikke søke om å få bruke andre frekvenser.
  • Hver radiofrekvens kan romme to talekanaler ved at de skiftevis sender/mottar i tidsluker på 30 millisekunder, slik som vist på Figur 4. De kan befordre helt uavhengige samtaler, eller gjøre det mulig å lytte og sende samtidig (kalt full dupleks, slik som i et telefonapparat).
  • Alle sendinger er adressert til enten en enkeltradio (til en DMR-id, se nedenfor) eller til en talegruppe, hvor alle medlemmer i talegruppen mottar sendingen.
  • Et sambandsnett kan basere seg på direkte forbindelser, hvor alle radioene er innen radiorekkevidde av hverandre, eller på bruk av repeatere, hvor radioene kommuniserer via en sentral radio på en fjelltopp el. lign.
  • Konkurranse mellom radioprodusentene presser prisene ned. En DMR-radio koster fra kr. 1000 og oppover.
  • Digital transmisjon åpner opp for mange tilleggstjenester, de er presentert i neste avsnitt.
Figur 4 – Tidsluker på en DMR-frekvens gir to uavhengige kanaler

Tilleggsfunksjoner i DMR

Utover arkitekturegenskapene som ble presentert i forrige avsnitt, spesifiserer DMR også en del funksjoner og tilleggstjenester som i varierende grad blir implementert i radioapparatene:

  • Tekstmeldinger – Radioapparater kan formidle korte tekstmeldinger som skrives inn på nummertastaturet og sendes til enkeltmottagere, evt. også til hele talegrupper. I motsetning til SMS i mobiltelefonnettet er det nødvendig at mottakeren befinner seg innen radiorekkevidde da det ikke er noen lagringstjeneste. Avsender kan spesifisere at meldingen skal kvitteres, og kan på den måten få en indikasjon på om meldingen ble levert.
  • Identifikasjon av radioer – Hver DMR-radio er konfigurert med en unik DMR-id som identifiserer avsender av en melding. Dersom radioen er utstyrt med en adresseliste vil radioen vise det tilhørende navnet, ikke id-nummeret. DMR-id kan også brukes for å gjøre direkte oppkall til enkeltradioer. Mange radioer kan enkelt sette sin egen DMR-id, så den er ikke egnet for å beskytte mot meldinger fra falske avsendere, men bidrar til å øke situasjonsforståelsen for de som deltar i operasjonen.
  • GPS-rapportering – mange radioer har en innebygget GPS-mottaker og kan rapportere sin posisjon på flere ulike måter: Som en ekstraopplysning knyttet til hver sending, eller regelmessig sendt til en bestemt adresse. I begge tilfeller kan dette bidra til bedre situasjonsforståelse: Ledelsen kan ha et kart med angitt posisjon for ulike personellfunksjoner, og ved direkte oppkall kan mottakeren få en angivelse av avstand og retning til avsenderen.
  • Alarm- og trygghetsfunksjoner – Radioene kan konfigureres med en alarmknapp, som sender en forutbestemt melding til en bestemt adresse når den trykkes inn. Radioen kan konfigureres til å la andre aktivisere senderen, slik ledelsen kan lytte inn fra radioen uten at den blir betjent. Radioen kan også utstyres med en “lone worker” funksjon: da må operatøren betjene radioen med jevne mellomrom, ellers sendes en alarmmelding. Dette minner om “dødmannsknappen” i visse typer utstyr.
  • Skjerming mot avlytting – Alle med en DMR-radio kan i prinsippet stille inn frekvens, tidsluker og talegrupper og lytte på sambandet. Dersom det er et behov for å beskytte seg mot dette kan man kryptere trafikken. Da må man legge inn kodenøkler i alle radioer, og kanalene settes opp til å benytte disse kodenøklene for sending og mottak. En uvedkommende DMR-radio uten riktige kodenøkler vil oppfatte disse sendingen kun som støy. Kryptering er egentlig ingen del av DMR-spesifikasjonen og radioprodusentene gjør dette på ulike måter. Kryptert trafikk kan ikke påregnes å fungere mellom radioer av ulikt fabrikat.
  • Datatrafikk – DMR-spesifikasjonen inkluderer støtte til overføring av data med IP-protokollen, men de enkle radioene tilbyr ikke noen mekanisme for å kople til en PC og sette opp et datanettverk via DMR-forbindelser. Det er også verd å merke seg at bitstrømmen i én tidsluke er 3600 bits per sekund, som er ganske lite for å støtte f.eks. overføring av bilder. I praksis må man se etter utstyr som kan spre trafikken på begge tidsluker og flere frekvenser, egenskaper som ikke er realistisk å finne i en håndholdt radio.

Separasjon av trafikktyper

Å ha én talekanal for alle funksjonene i en operasjon, der alle hører alt som blir sendt, er en dårlig idé. Personellet vil da måtte høre på en mengde meldinger som ikke vedkommer dem. Resultatet kan bli redusert oppmerksomhet på de mottatte meldingene, og dessuten distraksjon av det pågående arbeidet. Det er også viktig at kanalene ikke er for sterkt trafikkert, av hensyn til at hastemeldingene skal komme raskt frem.

Derfor skal sambandsnettet separere meldinger slik at de sendes til mottagere som har nytte av dem. Figur 1 viser nettopp hvordan de tre ulike veiene i sambandsnettet faller sammen med meldingstyper, og det er fornuftig å separere meldingtrafikken i henhold til disse skillelinjene.

Sambandsnettet har to kanaler for hver frekvens (delt i to tidsluker), og hver kanal kan logisk deles inn av talegrupper. Trafikk kan gå samtidig på kanalene, mens talegruppene deler kanalen mellom seg. Det betyr at mens en kanal sender melding for en talegruppe vil kanalen være opptatt og vil ikke kunne brukes for andre talegrupper. “Talegruppe” er forøvrig ikke noe som kjennetegner kanalen som sådan, men en adresse som påføres meldingen.

Likestilt med talegrupper er mottakeradresse. Dersom en sending påføres en mottakeradresse (i form av DMR-id) vil den kun mottas av denne mottakeren, men kanalen den sendes over er utilgjengelig for alle andre i dette tidsrommet.

Sambandsdesign innebærer å separere trafikktypene på frekvens, tidsluke, og talegruppe i henhold til krav om tilgjengelighet, trafikkvolum og dekningsområde.

Prinsipper for hvilke kanaler som talegrupper kan legges til:

  • Kanaler for trafikk med krav til kort responstid (hastemeldinger) bærer talegrupper med kortvarig trafikk: Anrop, alarmer, GPS-posisjoner
  • Kanaler for trafikk med krav til stort dekningsområde bærer talegrupper med nasjonal/regional trafikk: Myndighetskontakt, sivil/militær, luftfartøyer
  • Kanaler for trafikk med liten utbredelse (kun én repeater) bærer talegrupper med lokal trafikk: Innad i laget, mellom lagfører og kommandoplass

Utvidelse av dekningsområdet med repeatere

DMR-standarden legger stor vekt på bruk av repeatere i sambandsdesign: En repeater er en dobbel-radio som mottar radiosendinger på én frekvens og sender det samme signalet ut på en annen frekvens. Radioapparatene sender og mottar på motsatte frekvenser.

Slik kan alle radioer innen rekkevidde av repeateren kommunisere via repeateren, selv om de ikke er innen rekkevidde for hverandre. Repeateren kan plasseres høyt og fritt i terrenget og på denne måten skape et stort dekningsområde.

Radioer som er utenfor repeaterens dekningsområde kan derimot ikke kommunisere med hverandre, selv om de er innen rekkevidde av hverandre. Dette skyldes at de ikke lytter på den frekvensen de andre sender på. Man gjør seg dermed helt avhengig av at repeateren er innen rekkevidde og i drift.

Slik som beskrevet hittil er dette identisk med en repeater for et FM-samband. For DMR gjelder det samme prinsippet, men ekstrafunksjonene beskrevet ovenfor kommer i tillegg: Trafikken kan krypteres, deles inn i talegrupper, det kan sendes tekstmeldinger, GPS-posisjoner og alarmer. Og repeateren tilbyr to kanaler på frekvensen, basert på tidslukene.

DMR-radioer kan også settes opp med en funksjon kalt “talk around”. Om denne blir aktivert vil radioen gå over til direkte-forbindelse på repeaterens sendefrekvens (dvs. både motta og sende på denne frekvensen). Da kan andre høre dennes sendinger og selv aktivisere talk-around for å svare. Siden kan alle slå av funksjonen for å returnere til vanlig samband via repeateren. Talk-around lar dermed radioene kommunisere seg i mellom utenfor repeaterens dekningsområde, eller dersom repeateren faller ut av drift.

Linkede repeatere

Repeatere kan i tillegg til lokal utsending av mottatte signaler også videresende gjennom et digitalt nettverk til andre repeatere som igjen sender ut på sine frekvenser og sender videre til enda flere repeatere. Et slikt repeater-nett kan være svitsjet, i den forstand at forbindelsene mellom repeaterne kan koples opp og ned etter behov for større eller mindre dekningsområdet for sendingene.

I et digital nett hvor sendingene er knyttet til talegrupper er det selvsagt mulig å selektere talegrupper som skal videresendes til andre repeatere. På denne måten kan talegrupper gis ulik dekningsområde der hvor det er fornuftig.

Tilsvarende kan en repeater i et digitalt nett utveksle sendinger med andre digitale nett med annen teknologi, fordi det er en velegnet oppgave for en datamaskin å konvertere digitale sendinger, inkludert adresser, kontrollsignaler og digitalisert lyd.

Systemer for å linke repeatere er utviklet av utstyrsleverandørene og i form av åpne standarder og protokoller, som f.eks. Brandmeister og TGIF. Disse løsningene tilbyr både linking mellom DMR-repeatere og til repeatere for D-star, Yaesu System Fusion, Allstarlink, Echolink m.fl.

Enda en nyttig egenskap ved DRM er mulighet for at radioapparatene kan “roame” mellom repeatere, dvs. selv finne en repeater med egnet signalstyrke. Dette er ikke mulig ved bruk av FM-samband, der må operatøren selv finne frem til egnede repeaterfrekvenser. Roaming er en egenskap som konfigureres i radioapparatene, repeaterne har ingen rolle i den prosessen.

På Figur 5 vises hvordan “Repeater site 1” betjener stasjonene på venstre side, men også videresender mottatte signaler til “Repeater site 2” via et nettverk. Overføringen gjennom nettverket kan filtrere talegrupper, og konvertere de digitale dataene til andre systemer. Illustrasjonen viser også hvordan “radio-løse” stasjoner (Stasjon B) kan delta i sambandet gjennom ordinære datamaskiner (såkalt Voice over IP, VoIP)

Figur 5 – Prinsipptegning av linkede repeatere

Single Frequency Repeater

En DMR-repeater er en spesialbygget enhet med to radiomoduler og passbåndfiltre for å hindre forstyrrelser mellom dem, med robust kjøling for å tåle lange sendeperioder og en datamaskin som styrer trafikken mellom radiomodulene.

DMR har som kjent to kanaler som vekselvis sender på samme frekvens i tidsluker. Dette er blitt utnyttet til å tillate en annen form for repeaterfunksjon som kun benytter én frekvens. En såkalt Single Frequency Repeater (SFR) vil lytte på tidsluke 1 og sende ut på tidsluke 2. Den skifter altså mellom mottak og sending hvert 30. millisekund, og fordi den aldri sender og mottar samtidig trengs kun én radiomodul, og spesielle passbåndfiltre er ikke nødvendige. Radioapparatene som skal bruke en SFR må stille inn en direktekanal med sending på tidsluke 1. På en direktekanal vil radioapparatene lytte på begge tidslukene, ikke bare nr.2.

Med SFR må alle talegruppene legges i samme tidsluke, så man har mindre kapasitet til rådighet enn for vanlige repeatere, som videresender begge tidslukene.

En interessant egenskap ved SFR er at dersom radioene kommer utenfor dekningsområdet til repeateren (eller at den faller ut av drift), vil radioene uten videre kunne kommunisere dersom de er innen radiorekkevidde av hverandre (i motsetning til ordinære DMR-repeatere, som krever at “talk-around” funksjonen aktiveres). Dette gjelder fordi radioene lytter på begge tidslukene og vil motta sendinger fra andre radioer på tidsluke 1 såvel som fra repeateren på tidsluke 2.

Fordi en SFR ikke er en spesialbygget radio kan en vanlig DMR-radio bli en SFR dersom den har programvare for det. Denne egenskapen, kombinert med at den har kun én kanal, gjør at en SFR tenkes brukt som en improvisert måte å utvide dekningsområdet på ved at en radio settes til SFR-funksjon og bringes opp på en fjelltopp.

Eksempler på radioer med SFR-funksjon er Hytera PD985GMD (pris ca. 10.000,-, krever tilleggslisens) og Anytone D578UV (pris ca. 4200,-). Merk at slike radioer ikke er dimensjonert for kontinuerlig sending (høy duty cycle) med henblikk på batterkapasitet og kjøling.

Figur 6 viser SFR-prinsippet hvor radioen oppe til venstre mottar signal både på tidsluke 1 fra radioen nede til venstre og fra repeateren på tidsluke 2.

Figur 6 – Single Frequency Repeater omgitt av radioer satt til direkte forbindelser

Konfigurasjon av radioene

Det kan inngå et vesentlig antall radioer i en sambandsoperasjon, og det er nødvendig med en effektiv metode for konfigurasjon av dem. Det er f.eks. ikke ønskelig med individuell konfigurasjon av hver enkelt radio gjennom dens betjeningspanel. Andre krav til konfigurasjonen kan være at operatøren ikke skal kunne gjøre endringer selv, men at servicepersonell utfører denne oppgaven i henhold til en besluttet policy.

DMR-radioer konfigureres i hovedsak gjennom et PC-program kalt Customer Programming Software (CPS), hvor alle konfigurasjonsopplysninger legges inn i et omfattende skjema, som f.eks.

  • Radioens DMR-id (nummer)
  • Kanaler (frekvenser og tidsluker) med angivelse av navn, utstrålt effekt, trygghets- og sikkerhetsfunksjoner m.m.
  • Talegrupper, med gjenkjennelige navn
  • Adresselister, for å gjenkjenne avsendere
  • Tilpasning av betjeningsfunksjonene (f.eks. sperre visse funksjoner)
  • Passord for endring av konfigurasjonen
  • Tidsgrenser for automatisk power-off, maksimal sendetid
  • m.m

Slike opplysninger resulterer i en konfigurasjonsfil kalt Code Plug som lastes til radioen med hjelp av CPS. Det blir dermed mulig å lage en Code Plug for hver radio-“rolle” fremfor en for hver radio. Hvert radiofabrikat har sin egen CPS, og den resulterende Code Plug kan heller ikke brukes på andre radiofabrikater.

Dersom flere radiofabrikater inngår i en sambandsoperasjon er det nødvendig å bruke CPS på en slik måte at det ikke oppstår interoperabilitetsproblemer. Mer om det i neste avsnitt.

Figur 7 viser et skjermbilde fra en bestemt CPS (til en TYT MD-2017). Et omfattende sett av opplysninger inngår i en Code Plug og det knytter seg en viss lærekurve til bruken av CPS fordi en del av konfigurasjonsopplysningene dreier seg om “dype” tekniske detaljer i DMR-protokollene.

Figur 7 – Skjermbilde fra et CPS

Radiomarkedet for DMR

DMR er en åpen spesifikasjon, og det finnes Open Source programvare for DMR-protokollene som tillater produksjon av DMR-radioer uten veldig store utviklingskostnader. Resultatet er at det er mange ulike fabrikater på markedet, inkludert billige kinesiske radioer av varierende kvalitet på elektronikken og programvaren.

DMR-spesifikasjonene tillater teknologien brukt i mange brukstilfeller, men de billige radioene retter seg med sine funksjoner mot enkle samband, direktekontakt eller via repeatere. Funksjoner som f.eks. full dupleks tale (for samtrafikk med telefonnettet) og dataoverføring med IP-protokoll finnes ikke i det billige prissegmentet, men er å finne i dyrere “enterprise”-type produkter. Radioprodusentene er også systemleverandører, og ønsker at avansert bruk av DMR skal tilbys gjennom produkter med høyere pris.

Interoperabilitet

Et vesentlig moment med DMR og dens “åpenhet” knytter seg til interoperabilitetsproblemer, dvs. at ulike radioer implementerer funksjoner på ulik måte, og at slike funksjoner bare virker mellom radioer av samme fabrikat. Et eksempel er sikkerhetsfunksjoner, hvor krypteringsfunksjonene ikke virker på tvers av radiofabrikater.

Det krever mye undersøkelser for å kartlegge interoperabilitetsproblemer. Målet må være å komme frem til et felles sett av funksjoner som dekker behovet til sambandsoperasjonen. I dette arbeidet er CPS-programvaren sentral, siden det er der disse detaljene konfigureres.

Sammendrag

DMR er en digital teknologi med en rekke egenskaper som gjør den svært velegnet for sambandsnett. DMR støtter talegrupper, digitale tilleggstjenester og trygghetsfunksjoner. DMR-standarden er åpen og det er mange utstyrsprodusenter å velge mellom.

Dersom man ønsker å kjøpe DMR radioutstyr av flere fabrikater må man være oppmerksom på mulige interoperabilitetsproblemer. Erfaringsmessig er det mange digitale tilleggstjenester som ikke lar seg benytte i et heterogent system.

The QYT KT8900 radio with an Allstarlink node

Good news: The QYT KT-8900 and KT-8900D radios are well suited for running an Allstalink node. The configuration menu REP-M (#43 on KT-8900, #51 on KT-8900D) allows two radios to make a repeater by connecting a cable between the two microphone connectors (RJ45 plugs). The configuration feeds a RPT-CTLR signal when the squelch opens (or subtone received) through the mic connector which is wired to the PTT on the other radio.


The RPT-CTLR is effectively a COR signal which can be wired to the DMK URI for Allstarlink operation, and no modification to the radio circuit board is necessary. As a proof of concept, I sacrificed an ethernet cable and soldered a DB25 plug on it according to the wiring shown on the picture. This works as expected and with good sound quality. The KT-8900D offers much radio for the money, and I believe it should be interesting for use in private Allstarlink nodes.
The RPT-CTLR is active low, so you need to set “carrierfrom=usbinvert” in simpleusb.conf


After 3 hours operation on 95% duty cycle, the radio is only lukewarm, using low output power (10w)

The Allstalink node connected to the Mic connector of KT8900D

The wiring arrangement for the DB25 and the DMK URI board

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.

Allstarlink, verdensomspennende nettverk av radiorepeatere

Radioamatører har det med å holde seg med et håndapparat eller to. Min ser slik ut:

Et slikt apparat er billig, lett å ta med seg overalt, og enkel i bruk. Den har liten utgangseffekt, derfor kan den være batteridrevet, og ha en liten påmontert antenne som er trygg i bruk nær hodet.

Med lav effekt, liten antenne og høy radiofrekvens følger også kort rekkevidde. I beste fall noen titalls kilometer dersom er det siktlinje mellom radioene som snakker sammen. I kupert terreng eller bebygget område bare noen fåtalls kilometer.

Men disse håndapparatene kan også snakke sammen gjennom noen mellomstasjoner som kalles repeatere. Dette er ubetjente radiostasjoner som lytter på en bestemt frekvens, og sender videre alt de mottar på en annen frekvens. To radioer som ikke har direkte kontakt på grunn av avstand eller hindringer i terrenget kan nå snakke sammen indirekte via en repeater som de begge har innen rekkevidde.

Det finnes et hundretalls repeatere i Norge, her er du en liste:

Relestasjoner for norske radioamatører

Repeatere er nyttige fordi de utvider rekkevidden til håndapparater og andre enkle radiostasjoner (montert i bil, hjemme med enkel takantenne osv.), noe som betyr at de kan brukes til flere ulike formål og omfatte flere personer. Det er vanlig å ha møter mellom radioamatører ved at deltagerne stiller inn apparatet på frekvensen til en bestemt repeater. De én sender, kan alle andre høre.

Kilde: http://sheffieldwireless.org/2017/11/sheffields-abundance-of-repeaters-links/

Repeater-nettverk

Men repeatere kan også sende og motta seg i mellom, ikke bare til betjente radiostasjoner. På engelsk kalles dette Linked Repeaters eller Repeater Networks. Da vil det som mottas av én repeater bli sendt ut av alle repeaterne i nettverket. Et norsk eksempel på et repeater-nettverk er Innlandsnettet, som gir en samlet dekning i store deler av Innlandet fylke samt deler av Viken og Vestfold. Innlandsnettet benytter radiolinker for å knytte repeaterne sammen.

For fyldigere informasjon om repeatere og (litt om) repeater-nettverk:

Bruk av Internet

Repeatere kan selvfølgelig bruke alle slags kommunikasjonstjenester for å knytte seg sammen i nettverk, inkludert Internet. Og repeater-nettverk som benytter Internet for dette formålet er det flere eksempler på. Fordelene med et slikt arrangement er mange:

  • Nettverket kan være verdensomspennende
  • Lave kostnader, uavhengig av overført datavolum
  • Digital overføring av tale gir mindre kvalitetstap
  • Forbindelser mellom repeatere kan koples opp og ned etter behov for å lage ulike nettverk til ulike tider.

Det finnes flere repeaternettverk som benytter Internet, de kalles Echolink, IRLP, System Fusion, D-star, Brandmeister og Allstarlink. Denne artikkelen vil presentere og demonstrere Allstarlink.

Allstarlink

Allstarlink skiller seg ut fra andre lignende nettverk ved at det er svært enkelt å kople en radio til nettverket for å etablere en repeater: En Raspberry Pi (eller en annen Linux-maskin), et lydkort og en radio. Dette har gjort nettverket populært og der i dag ca. 5000 noder i daglig drift. Mesteparten av dem er i USA , mange i UK, og ellers spredd rundt i verden. Det er p.t. to noder i Norge, den herverende i Lillehammer (LA6UIA) og en i Oslo (LA3RIA). Her vises et kart over fordelingen av noder.

Eksempel på bruk

En håndapparat med forbindelse til en repeater kan bruke tastaturet til å sette opp forbindelser til andre rutere. Når tastene trykkes vil det sendes tonesignaler som oppfattes av repeateren, og kommandoer til repeateren sendes som en sekvens av tonesignaler: Trykkes *342567 vil repeateren forsøke å sette opp en forbindelse til repeateren 42567, og *142567 vil kople ned forbindelsen igjen. *806 kopler ned alle forbindelsene og *712 vil annonsere riktig klokke. *70 vil annonsere hvilke forbindelser som er oppkoplet på repeateren.

Dersom det settes opp en forbindelse til en annen repeater, vil man høre all tale som mottas av denne, i tillegg til all tale som mottas av andre repeatere direkte eller indirekte tilkoplet denne. En alle-til-alle forbindelse altså, som om alle deltagerne var innen hverandres radiorekkevidde.

Allstarlink er altså nettverket hvor man kan samle deltagere fra lokale områder i en stor samtale, eller for å gjøre alminnelig anrop (kalt CQ) til et stort antall lyttere. Og en node kan skifte mellom mange slike nettverk etter ønske. Utsnittet under viser et “snapshot” av et repeater-nettverk på Allstarlink. Noden med blå farge tilhører LA6UIA.

Repeater, Link, Headless

Med “node” menes en maskin som kan kople opp forbindelser til andre maskiner i Allstarlink og overføre tale. Noden kan være satt opp på ulike måter: Alle trenger en datamaskin med Internet-forbindelse, men de kan ha ulik konfigurasjon på “lokal”-siden:

  1. Repeater, dvs at den mottar og sender fra/til lokale radioer på to forskjellige frekvenser. Lokale brukere kan dermed høre hverandre og bruke noden som en ordinær repeater, uten nødvendigvis å benytte Allstarlink-nettverket.
  2. Link, hvor noden sender og mottar på samme frekvens. Flere lokale radioer kan bruke den til å snakke med Allstarlink (mot samme repeater-nettverk), men de kan ikke høre hverandre via noden (men muligens direkte om de er innen radiorekkevidde av hverandre).
  3. Headless, hvor noden ikke har en radio. Brukere av denne noden kan snakke med Allstarlink via en App, en IP-telefon eller et direkte tilkoplet headset.

Nedenfor vises hvordan de to første variantene kan koples til Allstarlink. Nodene oppe til venstre og nede til høyre er i prinsippe like: Den første viser en “ordentlig” repeater tilkoplet Allstarlink, mens den andre viser en “privat” repeater med enklere senderutstyr med kort rekkevidde.

Konfigurasjon av en Allstarlink-node

Illustrasjonen nedenfor viser i detalj hvordan en linknode kan bygges opp. En linknode er enklere å konstruere fordi den ikke trenger en full dupleks radio.

Konstruksjon av en Allstarlink linknode

Man trenger:

  1. En Linux maskin med Internett-tilgang. Det opplagte valget er en Raspberry Pi (gjerne v.3, da den avgir mindre varme enn v.4). Det finnes ferdiglaget programvare som lastes ned fra Internet og overføres til et minnekort som plasseres i maskinen. Det finnes to varianter av denne programvaren: HamVoip og ASL. Mange regner den førstnevnte som enklest å bruke, fordi den krever mindre forkunnskaper om Linux.
  2. Et lydkort som er tilpasset programvaren i Raspberry Pi. Lydkortet må være i stand til å signalere PTT (push-to-talk) og COR (Carrier Operated Relay), noe som snevrer inn utvalget kraftig. Illustrasjonen viser to muligheter, (1) Et ferdig bygget lydkort fra DMK Engineering, eller (2) et billig lydkort fra Ebay som du må modifisere selv.
  3. En kabel mellom lydkortet og radioen. Denne bør du lage selv, fordi ulike radioer har ulike tilkoplingsmuligheter. Lydkortet fra DMK Engineering bruker en DB25 plugg. Linjene for Tx (sendt tale) og Rx (mottatt tale) kan koples til radioens mikrofon/høyttalerutgang, og tilkopling for PTT (som aktiverer senderen) finnes gjerne på radioens mikrofonkontakt. Verre er det med COR signalet (som lydkortet trenger for å starte sending til Allstarlink, skal typisk være aktiv når squelch er åpen), ofte må man åpne radioen og hente signalet et sted fra kretskortet. Dersom radioen har kontakt for såkalt pakkeradio kan man regne med å finne tilkopling for alle disse 4 signalene der.
  4. En FM-radio for kontakt med lokale radioapparater. Her kan en enkel radio gjøre nytten, men man skal unngå å sette utgangseffekten til høyeste verdi, fordi en slik radio er ikke dimensjonert for å være i sendemodus i lange perioder av gangen. Man skal også vurdere om en tonesquelch (CTCSS-kontroll) kan brukes for å unngå at tilfeldige radiosignaler åpner squelchen og starter sending til repeater-nettverket.

    Min første konfigurasjon benyttet en billig Baofeng UV-5R radio som krevde at COR-kabelen ble loddet til hovedkortet. De andre signalene ble koplet via mikrofon- og headsett-kontakten. Radioen fungerte fint til privat bruk, men den lille bordladeren hadde for liten strømstyrke til å holde radioen i drift over mange timer.
Modifikasjon av kretskortet for å få COR-signal. Ved den røde pilen.

Når alt er koplet sammen kreves det litt justeringer i Raspberry Pi-programmet for å sette riktig polaritet på COR og PTT, samt justere lydnivå på talesignalene.

For å registrere seg i Allstarlink

Du må registrere deg i Allstarlink for å få et nodenummer og et passord. Dette gjør du online, og du må fremvise ditt kallesignal, fordi dette er forbeholdt radioamatører med sendetillatelse. På https://wiki.allstarlink.org/wiki/Beginners_Guide finner du opplysninger om dette og mye annet som du vil ha nytte av å vite.

Allstarlink-miljøet er hjelpsomt, og du får fort hjelp om du spør, f.eks. på Facebook-gruppen Allstar Link Network.

Demonstrasjonsvideo

Denne artikkelen er ikke ment som en komplett instruksjon for å konstruere en Allstarlink-node, men derimot å vekke interesse for å gå worldwide med lette og billige radioapparater. Jeg har laget en demonstrasjonsvideo hvor jeg viser hvordan min node er satt opp, og der viser jeg også hvordan man deltar i nettmøter (kalt “Nets”) gjennom Allstarlink. Videoen finner du rett nedenfor.

Spesifikt for min egen Allstarlink-node har jeg lagt ut noen driftsopplysninger på qrz.com:

https://www.qrz.com/db/la6uia

Jeg håper denne artikkelen har vært leseverdig. Send meg gjerne kommentarer om noe burde vært lagt til eller endret.

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.