Docker – nettverk og svermer

Anders Fongen, september 2022

Dette er et blogginnlegg som skal diskutere nettverk av Docker-kontainere, hvordan de kan kommunisere gjennom beskyttede interne nett, og hvordan de kan opptre i svermer under styring av en sentral kontrollnode. Forutsetningen for å få godt ubytte av denne teksten er grunnleggende kjennskap til bygging og kjøring av vanlige Docker-komponenter (eng. images)

Vi kan enkelt tenke oss fornuftige anvendelser hvor en Docker-komponent har nytte av å påkalle tjenester fra en annen komponent. Dette er da typisk en komponent som ikke betjenes med en HTML-basert web -dialog, men som benytter maskin-til-maskin kommunikasjon (m2m). Slik kommunikasjon kan gjerne være basert på HTTP-protokoll og benytte programmeringsbiblioteker for dette, men vil ha innholdet kodet med XML eller JSON. Slike komponenter forbinder vi med begrepet Service Oriented Architecture (SOA). Jeg kommer ikke til å komme inn på slik programmering her, men det finnes mengder av læremidler der ute basert på ditt favoritt programmeringsspråk.

Beskyttet nettverk internt i Docker

Når en komponent ønsker å kalle en annen, er det selvfølgelig mulig å utplassere den kalte komponenten slik at den kan kalles fra “utsiden” (evt. hele Internet) og bruke denne utvendige IP-adressen som servicepunkt. Det er lett å tenke seg hvorfor dette ofte ikke er ønskelig: Uvedkommende kan fritt utnytte og sabotere tjenesten med mindre man lager mekanismer for adgangskontroll, noe som strengt tatt ikke burde vært nødvendig.

Docker tilbyr derimot “interne” nettverk som kun er synlig for Docker-kontainere på den samme maskinen og som er koplet til det interne nettverket. I det man skaper et slikt nettverk:
$ docker network create my-internal-network
$ docker network ls
$ docker network inspect my-internal-network

vil det også bli tildelt en subnett-adresse, og forsynes med tjenester for tildeling av adresser fra subnettet (lik DHCP) og tjenester for å finne IP-adresser til de tilkoplede kontainerne (lik DNS). For siden å kople en kontainer til nettverket kan vi velge to metoder:

  1. Kople til nettverket i det kontaineren skapes, f.eks slik:
    $ docker run -p 80:80 --name mycontainer --net my-internal-network image-name

    Med denne metoden vil kontaineren mycontainer være knyttet til kun my-internal-network. Om kontaineren skal være knyttet til flere nettverk, bruk metode nr.2:
  2. Lage kontaineren, kople til nettverket og starte programmet, i tre steg (eksempelvis)
    $ docker create -p 80:80 -name mycontainer image-name
    $ docker network connect my-internal-network mycontainer
    $ docker network connect my-second-internal-network mycontainer
    $ docker network disconnect bridge mycontainer
    $ docker start mycontainer

    Denne listen av kommandoen viser bruken av create, som oppretter en kontainer uten å starte den, network connect som kopler kontaineren til interne nettverk, og disconnect, som kopler fra nettverk. Deretter starter kjøringen av programmet i kontaineren med $docker run.

Det forholder seg nemlig slik at en kontainer som standardinnstilling koples til et nettverk kalt bridge. Alle andre kontainere vil også ha forbindelse til denne, noe som i mange tilfeller ikke er ønskelig. Metode nr.1 vil erstatte bridge-forbindelsen med en forbindelse til my-internal-network. Metode nr.2 vil legge nye forbindelser til eksisterende.

Eksempel 1 – BusyBox

Som eksempel på viste metode nr.2 kan komponenten BusyBox brukes. Den gir et lite Linux-kjøremiljø som vi kan skrive kommandoer til.

Først lister vi opp eksisterende nettverk og skaper to nye:


Vi er interessert i å vite subnet-adressene til disse to nye nettene:


Vi skaper en kontainer med BusyBox-komponenten og knytter den til de to nye nettverkene, i tillegg til bridge:


Nå starter vi kontaineren bb med BusyBox inni, og skriver kommandoen ip a for å se nettverkskonfigurasjonen på komponenten:

Fra denne kommandoen ser vi de tre ethernet-adaptrene eth0, eth1 og eth2 med subnettadresser som tilsvarer nettverkene bridge, my-net-1 og my-net-2. Som nevnt tidligere ville vi trolig koplet fra bridge for å unngå påvirkning fra uvedkommende komponenter.

Eksempel 2 – Trafikk mellom to Docker-komponenter

Det første eksemplet viste kun konfigurasjon av nettverksforbindelser, ikke hvordan vi kan bruke dem. Derfor vil vi nå sette opp komponenten first slik at vi kan kalle den fra busybox med linux-kommandoen wget og vise html-innholdet som first sender. Komponenten first er beskrevet i et tidligere blogginnlegg.


Her brukes kommandoene som er vist som metode nr.1 ovenfor og vi starter henholdsvis first og busybox med forbindelser til my-net-3. I busybox bruker vi kommandoene slik:

  1. ip a for å se at vi har fått et nettverksadapter med en adresse fra subnettet til my-net-3
  2. ping first for å vise at det foreligger en navnetjeneste som kopler navnet first (navnet på kontaineren) til ip-adressen 172.27.0.2, og at det foreligger en virkelig forbindelse dit.
  3. wget first:8080 for å sende et http-forespørsel til 172.27.0.2, port 8080 og lagre svaret på filen index.html.
  4. more index.html for å vise innholdet av denne filen på konsollet.

Vi har altså med dette eksemplet demonstrert at to komponenter kan ha en nettverksforbindelse som er skjermet fra andre komponenter. Det som er verd å huske er:

  • Interne nettverk får automatisk en subnett-adresse.
  • Containere som kopler seg til et internt nettverk får tildelt IP-adresse automatisk.
  • Interne nettverk (unntatt bridge) har en navnetjeneste som returnerer IP-adressen til navngitte containere. Derfor er det lurt å gi containere et navn med --name parameteren.

Av en eller annen grunn er det ingen navntjeneste i nettverket bridge, slik at ping first ikke vil fungere dersom komponentene ønsket å kommunisere over det nettverket.

Docker-compose

En applikasjon vil gjerne bestå av flere Docker-containere som samarbeider og må konfigureres og startes på en kontrollert måte. Enkeltkommandoer som vist i eksemplene ovenfor kan kanskje settes sammen i en kommandofil (.bat, .sh) og kjøres samlet. Dette forutsetter at du har konsoll-adgang til maskinen som skal kjøre applikasjonen, og at ulike maskiner kan forstå denne kommandofilen. Dette er forutsetninger som ikke kan garanteres. Docker-compose vil øke portabiliteten av applikasjoner og forenkle konfigurasjonen, siden alt foregår i én fil.

Derfor kommer Docker-compose inn som et verktøy hvor detaljer vedrørende konfigurasjon og kjøring for alle komponentene i applikasjon kan uttrykkes i én fil. Denne filen har en såkalt YAML-syntaks, som skal vises i eksemplet som følger.

Filen skal hete docker-compose.yml. Som eksempel på utforming skal vi bruke konfigurasjonen i eksempel nr.2 ovenfor. Innholdet i filen er som vist under:

Syntaksen og mulige informasjonselementer i denne YAML-filer (uttales “jammel”) er ganske omfattende, og en oversikt finner du her. Derfor velger jeg heller å demonstrere ett bestemt kjent tilfelle med en typisk struktur: nettverksforbindelse, volumer, eksponerte porter. Elementene under disse to vil være tilsvarende de parametrene vi tidligere ga på kommandolinjen. For first, legg merke til at build: nå må ha et stinavn til der hvor kildefilene til first ligger.

Syntaksen i den viste docker-compose.yml skal forstås som et hierarki der innrykk av teksten viser en “tilhørighet” til linjen ovenfor med kortere innrykk. Her har vi altså tre hovedkategorier: services, volumes, networks. Før en kontainer kan knyttes til et volum eller nettverk må disse først deklareres på denne måten. Under networks finner vi hvilket nett som skal brukes i applikasjonen og hva dette skal hete.

Under services finner vi de to vi har arbeidet med så langt, bb og firsts. For bb kommer det to linjer knyttet til stdin_open og tty, som har å gjøre med at vi ønsker konsolltilgang til denne kontaineren, noe som i mange tilfeller ikke vil være aktuelt. Derfor vil denne viste filen ha de fleste av de egenskapene du i praksis vil trenge.

La oss nå gi denne filen til Docker-compose og se hva som kommer ut av det. Arbeidskatalogen (current directory) må være den som inneholder docker-compose.yml . Oppstart skjer med kommandoen $ docker-compose up:


Nå er både bb og first started i hver sine kontainere, men vi får ingen konsolltilgang til å skrive kommandoer i. Til forskjell fra eksempel nr.2 må vi skrive dette i tilegg:
$ docker exec -it bb sh
Denne kommandoen utfører kommandoen sh i kontaineren som heter bb. Parameteren -it gjør at sh også kommuniserer med konsollet, så vi får en interaktivt Linux-konsoll. Nå kan vi teste at det er kommunikasjon mellom bb og first:


Dette må dog skrives i et annet CMD-vindu, fordi vinduet der vi startet docker-compose er opptatt. Der kan vi derimot lukke applikasjonen og stanse kontainerne ved å trykke ctrl-C noen ganger:


Kommandoen $ docker ps -a viser en liste over kontainerne og at disse er stoppet. Vi kan nå slette én og en kontainer med kommandoen $ docker rm bb first, men en enklere måte er $ docker container prune, som sletter alle inaktive kontainere under ett. Inaktive kontainere kan okkupere en del ressurser i systemet, og det er sunt å rydde regelmessig.

Docker swarms

I et storskala informasjonssystem vil en web-tjeneste kjøre på mange maskiner i parallell. Da oppnår man at maskinene kan fordele kundetrafikken mellom seg for å oppnå høyere total ytelse (kalt lastfordeling), og at noen av maskinene kan falle ut av drift uten at systemet som sådan blir utilgjengelig (kalt fail-over). Denne formen for ressursorganisering krever en sjef (manager), som fordeler forespørsler mellom arbeiderne (workers) og som holder oversikt ettersom maskiner går inn eller ut av drift.

Docker-arkitekturen egner seg godt til å inngå i en slik storskala arkitektur, siden tilstandsløse komponenter kan dupliseres på flere maskiner og utføre nøyaktig den samme tjenesten. Kunder vil se ett eneste servicepunkt (IP-adresse og port) og ikke merke noe til at tjenesten er fordelt på mange maskiner. La oss derfor se på hvordan Docker-komponenter kan organiseres som en Docker swarm:

Bruk helst Linux-maskiner

Selv om kommandoene for Docker-svermer også finnes på Windows-versjonen av Docker-systemet, er det en del egenskaper som simpelthen ikke virker som forventet. Det er derfor å anbefale at et eksperiment med Docker-svermer kun benytter Linux-maskiner. Husk også at Docker-komponenter ikke er arkitekturnøytrale, de kan ikke kjøre både på X86- og ARM-maskintyper. Ikke blande f.eks. Raspberry Pi (ARM) med ordinære PCer (X86) i en Docker-sverm.

Alt foregår fra sjefen

For å bygge opp en sverm må maskinene kunne nå hverandre gjennom et IP-nettverk, det er ikke tilstrekkelig at sjefen kan nå alle arbeiderne, arbeiderne må også kunne kommunisere med hverandre. For først å bygge opp en sverm gjør vi følgende:

  1. Bestem hvilke maskiner som skal delta, skriv ned deres IP-adresser og lag et kart som viser hvem som er sjef og hvem som er arbeidere. Fra konsollet til sjefen, logg inn (med ssh) på alle arbeiderne i separate konsollvinduer. Alle kommandoer som vises som eksempler må kjøres i sudo-modus (skriv sudo bash for komme dit).
  2. På alle maskinene i svermen, sørg nå for at alle kontainere er stanset ($ docker stop ..., $ docker rm ...) og kontroller resultatet med $ docker ps -a.
  3. På sjefens maskin, sjekk om det allerede er en sverm med $ docker node ls. Dersom det finnes en, fjerne dem med kommandoen $ docker swarm leave --force.
  4. På sjefens maskin, opprett en sverm med kommandoen $ docker swarm init. Reponsen kan se omtrent slik ut:
    Swarm initialized: current node (icv8b9vnemxfmym4lb1gbto7f) is now a manager
    To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-0ezzbg9iw2glu6d7xd6c2shjvhadr7zlemwuf4l9besxl2iogl-a1yngnqehgyub0phopuslysly 192.168.2.116:2377
  5. Ta en kopi av den uthevede teksten, og lim den inn i konsollvinduet til alle arbeiderne slik at kommandoen utføres der. De vil nå kople seg til sjefen (til ip-adressen som er vist i kommandoen) og slutte seg til svermen. Nå vil de etterhvert få opprettet kontainere for applikasjonstjenester og motta klientforespørsler.
  6. Fra sjefens konsoll skriv $docker node ls for å kontrollere at alle arbeiderne er kommet inn i svermen.

Utplassering av en tjeneste i svermen

Nå kan sjefen plassere en tjenesten inn i svermen. Dette betyr, som tidligere nevnt, at en applikasjon blir plassert ut på én eller flere av arbeiderne (inkludert sjefen), og en forespørsel fra en klient blir betjent av én av dem.

Hvilken IP-adresse leder inn til den utplassert tjenesten? Svaret er at alle IP-adressene i svermen (altså endepunktet til alle arbeiderne og sjefen) gir adgang til tjenesten, også de arbeiderne som ikke betjener selve tjenesten. Det eksisterer et eget “overlay” nettverk mellom maskinene som fremforhandler fordelingen av arbeidsoppgaver og som videresender forespørsler fra klienter til en kandidat-arbeider.

Kommandoen skal skrives på sjefens konsoll. Sånn kan den se ut:

$ docker service create --name first --replicas 3 --publish 8080:8080 andfon7a/first

Den eneste nye parameteren siden de tidligere eksperimentene er --replicas som angir det maksimale antall arbeidere (inkl. sjefen) som skal laste denne applikasjonen. Legg også merke til at Docker-komponenten ikke må ligge på sjefens egen maskin, den kan hentes fra Docker-hub om nødvendig (og den må da evt. plasseres der på forhånd med $ docker push andfon7a/first).

Med kommandoen $ netstat -ant på alle maskinene i svermen kan man nå konstatere at port 8080 er “åpen”. Med en web-leser kan man kontake én av maskinenes IP-adresse på port 8080 og konstatere at tjenesten utføres korrekt.

For å inspisere tjenesten bruk kommandoen $ docker service inspect --pretty first. For å fjerne den skrives $ docker service rm first.

Opp- og nedskalering: Det opplagt nyttige i svermen er muligheten for å endre kapasiteten ved å øke eller redusere antall maskiner som deltar i en tjeneste. Det gjøres som følger (i dette eksemplet reduseres antallet fra 3 til 2):

$ docker service scale first=2

Konklusjon

Målet med dette blogginnlegget var å gi en kortfattet, men ukomplett, innføring i hvordan man setter opp nettverk og svermer av Docker-komponenter. Det fulle omfanget av muligheter og detaljer er mye større, men er blitt utelatt fordi det er lagt vekt på å vise konkret hvor enkelt det er å sette opp en grunnleggende tjeneste.

Jeg anbefaler først leseren å gjennomføre disse eksemplene på eget utstyr og så gjøre nødvendige endringer etter egen interesse: F.eks. hvordan en sverm kan operere med permanent lagring gjennom en filtjener eller en SQL-database. Slike komponenter er ikke enkle å replikere i en sverm og vil naturlig ligge i egne tjenester, gjerne i frittstående Docker-kontainere med muligheter for å lagre data i volumes.

Utplassering av Docker-komponenter i Microsoft Azure

Anders Fongen, september 2022

Å konstruere Docker-komponenter og utplassere (eng. deploy) dem i en lokal kontainer på egen maskin er en ganske overkommelig oppgave. Mer omstendelig er det å sette slike komponenter i drift i en sky. De store skytjenestene (f.eks. Amazon AWS, Google Cloud og Microsoft Azure) er svært store og komplekse installasjoner som skal kunne betjene kunder med helt ulike behov. De tilbyr alle en web-tjeneste (portal) som lar kunden laste opp egenutviklet programvare og konfigurere samspillet med de tjenestene som skyen tilbyr (f.eks. sikkerhet, backup, navnekataloger, fillagring og SQL-databaser). For alle disse skyene blir denne portalen svært omfattende og omstendelig å bruke. Kvaliteten på dokumentasjonen er dessuten svært varierende.

Jeg har tatt for meg utvikling, utplassering, feilsøking og drift av Docker-komponenter med påfølgende utplassering i Microsoft Azure. Etter vellykket utplassering er tjenesten tilgjengelig på Internet. Dette blogginnlegget vil vise hvordan det kan skje.

Hvorfor er skyen en god idé?

Visst er det mulig å sette opp en webtjener på ditt eget hjemmenett, bestille fast IP-adresse hos Internet-leverandøren, sette opp port forwarding på hjemmeruteren, og gi hjemmeadressen et DNS-navn. Denne prosessen har jeg forøvrig beskrevet i et eget blogginnlegg.

Med et slik løsning må du selv ta hånd om sikkerhet, backup, reserveløsninger ved systembrudd, brukertillatelser, og fremfor alt skalering. En vellykket tjeneste på Internet kan oppnå en svært rask vekst i kundemengden, og dersom du ikke klarer å opprettholde en akseptabel responstid under slike forhold har du mislykkes.

Disse kravene kan skyen innfri, fordi de besitter store datasentraler med høy nettverkskapasitet, og de kan raskt øke kapasiteten på tjenesten din, de kan endog gjøre det automatisk. Personellet i datasentralene er eksperter på skalering, sikkerhet, overvåking og etterforskning, og de har ingen annen jobb enn å passe på at tjenestene leverer stabilt og raskt. Du har andre oppgaver og vil ikke klare å gjøre denne jobben like godt.

Docker

Programvare som skal kjøres som en skytjeneste må skrives etter bestemte regler, og utplasseringen trenger noen opplysninger som må fremskaffes av kunden. Docker er programvare for å lage og kjøre skytjenester. Jeg skal ikke forklare Docker grundig her, fordi det finnes mye informasjon om nettopp dette på nettet:

Det er nødvendig å gå gjennom noen eksempler på bygging og kjøring av Docker-komponenter på lokal maskin: Når Docker-komponenter kjøres på lokal maskin, f.eks. BusyBox, kan de kommunisere med brukeren gjennom konsollet, dvs. skjermen som brukes for å bygge og starte komponenter. Dette er ikke mulig på Azure, hvor komponenten må kommunisere med omverdenen gjennom nettverket (Internet).

Nettverkstrafikk kan omfatte protokoller som ssh, http, mqtt og det meste annet, men komponenten må selv besørge selve protokollen, Azure besørger bare UDP- og TCP porter, samt en brannvegg for å beskytte mot angrep via nettverket. Vi skal demonstrere bruk av Azure med web-komponenter som benytter http-protokoll.

Installasjon av programvare

For å kommunisere med Azure trengs programvaren Docker Desktop, installert på Windows eller Mac (bruk lenken ovenfor). I CMD-konsollet (Windows) kan man nå skrive $ docker for å utføre diverse kommandoer.

I den påfølgende tekst vil jeg bruke “$”-symbolet for å vise en kommando slik den skal skrives inn i CMD-konsollet. Dollartegnet skal altså ikke skrives inn.

For å utplassere Docker-komponenter på Azure trenger du følgende brukerkontoer:

  1. Hos hub.docker.com. Her plasserer du dine komponenter slik at andre kan laste dem ned til seg og bruke dem. Kontoen er gratis.
  2. Hos portal.azure.com. Her foregår selve kontrollen av Azur-aktivitetene. Duu må registrere et betalingskort, men du får også en romslig kvote gratis som du kan eksperimentere med.

Eksperimentprogrammer

To små Python-programmer blir brukt i denne demonstrasjonen: De ene er et enkelt tilstandsløst web-program som adderer to tall og viser resultatet, det andre web-programmet benytter en tekstfil som lagres på et permanent lager. Skillet mellom disse to programmene er hvordan de bruker permanent lager. Programmene ser slik ut:

Summere to tall (tilstandsløst web-program)

first.py:
import web
urls = ('/','index')

class index:
   def GET(self):
      f = open("first.html","r")
      return f.read()
   def POST(self):
      i = web.input()
      if i.a.isnumeric() and i.b.isnumeric():
         return "Svaret er %d" % (int(i.a)+int(i.b))
      else:
         return "Kun numerisk inndata er lovlig"

if __name__ == '__main__':
   app = web.application(urls,globals())
   app.run()

first.html:
<html><body>
  <h1>Addere to heltall</h1>
  <form method='POST'>
     <input name='a', size='4'>
     <input name='b', size='4'>
     <input type='submit' value='finn sum'>
   </form>
</body></html>

Dockerfile:
FROM python:3.8
WORKDIR /usr/src/app
COPY . .
RUN pip3 install web.py
EXPOSE 8080
CMD ["python","./first.py"]

Dette webprogrammet kan startes direkte fra kommandolinjen og tilby en enkel tilstandsløs tjeneste. Vi kan når som helst restarte tjenesten uten å forstyrre klientene. Vi kan lage en Docker-komponent og kjøre den lokalt på vår egen maskin med disse kommandoene (de tre filene må ligge på samme katalog, og katalogen må være arbeidskatalog (current directory):

$ docker build -t first .
$ docker run --name container1 -d -p 8080:8080 first

Nå er denne webtjenesten tilgjengelig på http://localhost:8080/. For å stoppe og fjerne tjenesten (f.eks. før utplassering av en ny programversjon) kan disse kommandoene skrives:

$ docker ps -a
$ docker stop container1
$ docker rm container1

Dele en liten datafil (tilstandsfylt web-program)

third.py:
import web, os

urls = ('/','index')
os.environ['PORT'] = '80'
app = web.application(urls, locals())
filename = "message.txt"
class index:
   def GET(self):
      if not os.path.isfile(filename):
         f = open(filename,"w")
         f.close()
         message = "Ingen melding"
      else:
         f = open(filename,"r")
         message = f.read()
      resp ="<html><body><h2>Din siste melding var: %s"%(message)
      resp += "<p>Skriv inn melding:<form method='POST'><input name='m' size='20'>"
      resp += "<input type='submit' value='Lagre melding'></form></body></html>"
      return resp
   def POST(self):
      i = web.input()
      f = open(filename,"w")
      f.write(i.m)
      f.close()
      raise web.seeother('/')

if __name__ == '__main__':
   app.run()

Dockerfile:
FROM python:3.8
WORKDIR /usr/src/app
COPY . .
RUN pip3 install web.py
EXPOSE 80
CMD ["python","./third.py"]

Dette web-programmet vil ta imot en tekstlinje og lagre den på en fil, som siden kan hentes frem av denne eller andre klienter. En form for datadeling altså. Filen som lagrer tekstlinjen bør bevares også når programmet stopper og starter igjen. Dersom vi kjører third.py som et vanlig Python-program vil filen ligge på vertsmaskinens filsystem, og vil dermed bevares slik vi ønsker.

Dersom vi lager en Docker-komponent som med forrige eksempel, vil også denne tekstlinjen bevares og utveksles mens Docker-komponenten kjører. Dersom Docker-kontaineren stoppes og startes igjen:

$ docker stop container1
$ docker start container1

(gitt at kontaineren er gitt navnet container1 ved docker run – kommandoen), da vil fortsatt tekstlinjen bevares slik vi ønsker. Dersom vi derimot fjerner kontaineren og lager en ny:

$ docker stop container1
$ docker rm container1
$ docker run --name container1 -d -p 80:80 third

Da har tekstlinjen fått det innholdet den hadde da Docker-komponenten ble laget (evt. tom), og endringer etter det tidspunktet er gått tapt. Altså, ikke slik vi ønsker at webtjenesten vår skal fungere.

Docker-komponenter med volumes

For å kunne bevare data også når docker-kontaineren slettes og skapes på nytt, må dataene lagres utenfor kontaineren, i vertsmaskinens filsystem. Dette er mulig å få til gjennom å montere en del av vertsmaskinens filsystem inne i kontainerens. Vi skal først endre én programsetning i third.py:

filename = "/app/message.txt"

og bygger web-tjenesten på lignende måte:

$ docker build -t third .
$ docker run --name container3 -v textdata:/app -d -p 80:80 third

Da oppnår vi nemlig det vi ønsker, nemlig at innholdet på området textdata i vertskapets filområde (i et nærmere bestemt filområde inne i Docker-installasjonen) vises under katalogen /app inne i kontaineren, og data som lagres under /app blir bevart selv når kontaineren slettes og gjenskapes. Dette kan kontrolleres ganske enkelt i et eksperiment.

Merk at dette permanente lageret kan lagre alle slags objekter, ikke bare tekstfiler: Bilder, lyd og selvfølgelig en databasefil fra f.eks. SQLite.

Litt om tilstander i Azure/Docker

Azure, i likhet med andre skyleverandører, lar Docker-komponenter kjøre i omgivelser som støtter stor skala, høy sikkerhet og dynamisk konfigurasjon. Det vil si at web-tjenesten som kjører kan gis et elastisk ressurstilbud ettersom pågangen øker og minker. Slik automatisk skalering skjer gjennom at Docker-komponenter kjører samtidig på mange maskiner i parallell (kalt flere instanser) og fordeler forespørselene mellom seg, og at antallet samtidige maskiner øker og minsker dynamisk.

Med datalagring inne i komponenten, slik vi har demonstrert med third.py, vil ikke en slik skalering kunne finne sted, fordi alle instansene vil ha ulikt datainnhold siden de betjener ulike forespørsler. Nei, skalering krever at Docker-komponenten benytter en separat lagringstjeneste som behandler skrivbare data (som filen message.txt i third.py ovenfor). Kun lesbare data kan fortsatt legges inne i Docker-komponenten dersom mengden ikke er for stor.

Dette skillet mellom brukerbetjening, forretningslogikk og datalager er en populær og velprøvd konstruksjonsteknikk for store informasjonssystemer. Trafikken mot datalageret (kalt back-end) er ofte lavere enn mot front-end (web-tjenesten) og datalageret kan skaleres med andre teknikker enn en front-end. Derfor ser vi at dette skillet mellom utføring og lagring i adskilte tjenester går igjen hos alle skyleverandører.

Utplassering av third.py i Azure

Vi skal hoppe over utplassering av first.py i Azure fordi det skjer på samme måten som med lokal Docker-plattform med noen små endringer, som vil fremgå av forklaringen som følger. Jeg skal gå gjennom utplassering av third.py i Azure, etter at den ene programsetningen er endret (filename = "/app/message.txt). Trinn for trinn er prosessen denne:

  1. Bygge en lokal Docker-komponent. Navnet på komponenten må prefikses med brukernavnet i Docker-hub, som i mitt tilfelle er andfon7a:
    $ docker build -t andfon7a/third .
  2. Plassere komponenten i Docker-hub. Det er nemlig herfra at Azure skal hente den senere
    $ docker login (Her kreves brukernavn og passord til brukerkontoen din)
    $ docker push andfon7a/third
    $ docker logout
  3. Logge inn i Azure og opprette filområdet
    $ docker login azure (Får du feilmelding “Azure lookup failure”, har du feil
    versjon av Docker installert. Bruk nyeste versjon av Docker desktop)
    $ docker context create aci mycontext (velg “create new resource group”)
    $ docker context use mycontext
    $ docker volume create mydata --storage-account andfon7astorage
  4. Lag en kontainer og start komponenten i den. Den lastes inn fra Docker-hub
    $ docker run -p 80:80 --name third --domainname andfon7a -d -v andfon7astorage/mydata:/app andfon7a/third
  5. Sjekk at kontaineren kjører og hvilket DNS-navn den har fått.
    $ docker ps -a
    – Sjekk nå med en web-leser at du får tak i tjenesten med dette DNS-navnet

Microsofts egen infoside om denne prosessen finner du her. Docker sin tilsvarende veiledning finnes her.

For å stoppe/starte/fjerne kontaineren bruker du kommandoene:
$ docker stop third
$ docker start third
$ docker rm third

Starting av en kontainer kan ta lengre tid enn kun kommandoen i konsollet. Bruk $docker ps -a for å se status i oppstartsarbeidet.

Om DNS-registreringen: For bruk av --domainname parameteren gjelder det at DNS-navnet blir registrert på den tildelte IP-adressen med en TTL-verdi på 300 sekunder. Dersom du under f.eks. eksperimentarbeid statid starter containeren på nytt kan du komme i situasjonen hvor DNS-tjenesten fortsatt en stund returnerer den forrige IP-adressen. Om du utelater --domainname parameteren vil $docker ps vise deg IP-adressen i den samme kolonnen , som alltid er riktig.

Huskn

Når du vil igjen jobbe lokalt eller mot Docker-hub:
$ docker logout azure
$ docker context use default

Docker-tjenester fra Amazon AWS og Google Cloud

Amazon AWS og Google Cloud er to konkurrerende skytjenester som i det store bildet har mye til felles. Begge disse kan enkelt støtte tilstandsløse Docker-komponenter, enklest gjennom egne kontrollprogrammer (à la docker) som installeres i Windows-konsollet (cmd).

  • Google Cloud betjenes av programmet Gcloud som installeres på din lokale maskin. Opplastingen skjer direkte fra lokal maskin med commandoen gcloud run deploy, og nødvendige tilleggsopplysninger legges inn i den påfølgende dialogen.
  • For Amazon AWS skjer utplasseringen ved hjelp av en tilleggsfil som inneholder de nødvendige ekstraopplysningene (som ikke ligger i Dockerfile). For en veiledning for dette, sjekk avsnittet “Docker on AWS” på denne websiden.

Ingen av disse to skytjenestene støtter derimot Volumer, slik vi har vist er mulig i Azure. Derimot har begge database-tjenester som kan brukes av Docker-komponenter for lagring. Dette dekker noe av behovet for permanent lagring, men krever også at programvaren i større grad er tilpasset for dette og blir derfor mindre portabel enn hva som er ønskelig. Databasetjenester er dessuten krevende å konfigurere, sammenlignet med et filsystem.

RSA-algoritmen forklart

Om du kjenner prinsippene for public key kryptografi, har du sikkert hørt om RSA-algoritmen, som er den viktigste metoden for å kryptere med offentlig nøkkel. I dette videoforedraget gir jeg en forklaring på hvordan RSA-algoritmen virker, og gir et bevis på det matematiske grunnlaget for metoden. Jeg viser også hvordan nøkkelen for dekryptering kan utledes, og gir en begrunnelse for hvorfor RSA-algoritmen er vanskelig å knekke. God fornøyelse.

Space Information Networks

Anders Fongen, 03.01.2022

Kommunikasjonssatellitter har hatt en historisk utvikling fra å være enkle “speil” som reflekterer radiosignaler, til å danne nettverk med andre satellitter for å tilby høyere hastigheter, lavere forsinkelse og flere tjenester. Vi spår at denne utviklingen vil fortsette og at satellittnettverk vil utvide sine tjenester fra kun kommunikasjonstjenester til også databehandlingstjenester av ulik art. Vi ser nærmere på mulighetene for dette i denne artikkelen.

Innledning

Vi vil her omtale idéen om Cloud Computing in Space. Altså skytjenester i satellittnettverk, også kalt Space Information Networks (SIN). SIN innebærer at satellittnettverket ikke kun tilbyr kommunikasjonstjenester, men også tjenester knyttet til informasjonsbehandling og annet type samarbeid. Et SIN kan bygges slik at det tilbyr slike tjenester med global dekning og svært lave forsinkelser, og kan derfor støtte anvendelser som ikke det jordbaserte Internet kan. 

Vi velger å betrakte et SIN som et distribuert system, men med egenskaper som skiller jeg ganske mye fra ordinære distribuerte systemer slik vi vanligvis kjenner dem: I et SIN er klientene stasjonære, infrastrukturen er mobil, altså ganske omvendt av hva som er “vanlig”.

Et annet forhold som kjennetegner et SIN er forutsigbarhet. Én satellitt vil alltid vite hvor andre satellitter befinner seg hen, og hvilke som er innen rekkevidde for kommunikasjon mellom dem. Dessuten er de demografiske forholdene på jordoverflaten kjent, så det er mulig å forutse både mengden av forespørsler fra bakken, og hva slags type forespørsler det er (språk og kulturelle preferanser). 

I den resterende delen av denne artikkelen vil noen grunnleggende egenskaper knyttet til satellitter bli presentert. Skillet mellom LEO- HEO- og GEO-satellitter vil bli forklart og noe historie presentert. Hoveddelen av teksten vil beskrive de særegne egenskapene til et SIN, og hvordan informasjonstjenester kan konstrueres for best å tilpasses disse egenskapene.

Litt om geostasjonære satellitter

Idéen om å bruke romfartøy til støtte for radiokommunikasjon oppsto lenge før den første satellitten ble skutt opp i jordbane i 1957. Mest kjent er en artikkel fra 1945 skrevet av Arthur C. Clarke kalt “Extra-terrestrial Relays” hvor prinsippene for en såkalt geostasjonær satellitt ble skissert. Arthur C. Clarke var forøvrig ikke kjent som vitenskapsmann, men som science-fiction forfatter bl.a. av manuset til filmen “2001 – En romodyssé” (1968). 

En geostasjonær (GEO – Geosynchronous Earth Orbit) satellitt går i bane rundt jordas ekvator og med en omløpstid på 24 timer (egentlig litt mindre, blir forklart senere). En GEO-satellitt har et stort dekningsområde (er synlig for en stor del av jordoverflaten) men flyr så høyt over jordoverflaten at signalforsinkelsen blir merkbar. Et radiosignal sendt fra jorda og returnert fra satellitten bruker ca 250 ms på rundturen. GEO-satellitter har den store fordelen at de, sett fra jorda, står fast på samme posisjon på himmelen og krever derfor ikke bevegelige parabolantenner nede på bakken. 

Hvilken flyvehøyde har en GEO-satellitt? Den skal ligge i en bane hvor sentripetalakselerasjonen (tidligere kalt sentrifugalkraften) i den ene retningen er like stor som gravitasjonen i den andre retningen, vist med ligningen under:

  • G = gravitasjonskonstanten, 6.677*10-11 m3 kg-1 s-2
  • M = jordas masse, 5.972*1024 kg
  • T = varighet av et stjernedøgn, 86164 s
  • R = jordas radius, 6371 km
  • r = satellittens flyvehøyde over jordoverflaten

Løs denne likningen for r, du bør få 35783 km som svar.

Omløpstiden for satellitten er ikke 24 timer (som vi kaller et soldøgn), men litt kortere. Et soldøgn er tiden det tar før solen igjen står i samme posisjon på himmelen, men da har jorden dreiet litt mer enn 360 grader, fordi jorden har beveget seg rundt solen i det samme tidsrommet. Jorden snurrer faktisk 366,25 omdreininger på et år, ikke 365,25. Derfor må vi trekke fra litt for å regne tidsrommet som jorda bruker på en virkelig omdreining, og dette tallet kalles stjernedøgn. Utregning er som følger:

3600 sek/t * 24 t/sold *(365,25/366,25)sold/stjerned = 86164 sek/stjerned

Dette tallet bruker vi i likningen over og får at flyvehøyden er 35783 km. Samme likning kan vi bruke for å bestemme flyvehøyden for enhver omløpstid så lenge banen er sirkulær (ikke elliptisk). Vi kan naturligvis også løse likningen på T og finne omløpstiden når flyvehøyden er gitt.

Den første GEO satellitten het Syncom III, bygget av NASA og skutt opp i 1964. GEO-satellitter ble siden mest kjent for TV-overføringer, og alle private parabolantenner får sine TV-signaler fra slike. GEO-satellitter kan også brukes til telefoni. I mange år var dette svært dyrt og krevet avansert og plasskrevende bakkeutstyr, men utviklingen siden har bydd på enkle bærbare enheter og lavere brukskostnader.

GEO-satellitter er derimot ikke synlig lengst nord og sør på kloden, fordi banen alltid går langs ekvator. På hvilken breddegrad ligger en GEO-satellitt akkurat i horisonten? Denne verdien finner vi med en enkel trigonometrisk likning, vist med figur under:

Regn selv ut v og finn på kartet hvilke landområder som ligger nord for denne breddegraden, både nord og sør. Merk at vi ikke nødvendigvis har dekning på denne breddegraden, for dempingen av radiosignalet øker ned mot horisonten.

Hvorfor trenger vi parabolantenner? En GEO-satellitt flyr høyt over jordoverflaten og avstanden som radiosignalene skal sendes over er ca 35000 km. Over en slik avstand svekkes energien i radiosignalene såpass mye at en antennepisk (slik som vi ser på håndholdte radioer og gamle mobiltelefoner) ikke vil motta tilstrekkelig radiosignal for å gi godt mottak. Vi må da bruke såkalt direktive antenner, som samler opp energi fra en bestemt retning, fremfor en rundstrålende antenne som samler opp energi fra alle retninger (og stråler ut energi i alle retninger). En parabolantenne er direktiv og samler opp energi fra et ganske smal “stråle”, slik som en lommelykt sender lyset ut i en smal stråle og virker på større avstand enn om lyspæren stråler fritt i alle retninger.

Om lavbane (LEO) satellitter

Satellitter kan naturligvis settes i alle slags baner rundt jorden, men vil da muligens kreve bevegelige direktive antenner på bakken for å motta tilstrekkelig sterkt signal, avhengig av hvor høyt satellitten går i bane. Om de derimot går i lav bane (og med kort omløpstid) omtales de som LEO-satellitter (Low Earth Orbit) og har den fordelen at bakkeutstyret kan klare seg med enklere antenner direkte montert på håndholdt utstyr. LEO-satellitter er dessuten billigere å plassere ut i bane enn GEO-satellitter fordi dette kan gjøres med mindre og billigere raketter.

LEO-satellitter har lenge vært i bruk til værobservasjoner, etterretningsformål m.m. I slike tilfeller blir innsamlet sensorinformasjon (f.eks. bilder) oppbevart i satellitten inntil den kan lastes ned til en jordstasjon noen minutter eller timer senere. Satellitten klarer seg uten et nettverk av andre satellitter, men bruker derimot mer tid på leveransen. Satellitten opptrer som “brevdue” fremfor “telefonsentral”. 

En konsekvens av den lave banen er at “fotavtrykket” (eng. footprint), dvs. det området på jorda som har kontakt med satellitten (begrenset av horisonten og hva slags antenner som benyttes), er liten. I tillegg gjør den korte omløpstiden at utstyret på bakken har satellitten over horisonten kun en kort tid (typisk 10-20 minutter).

Disse egenskapene gir både fordeler og ulemper, sammenlignet med en GEO-satellitt:

Fordeler:

  • Banen kan legges i en vinkel på ekvator (kalt inklinasjon) slik at den passerer nær polområdene. Da vil også utstyr på bakken langt nord og langt sør kunne nå satellitten. Husk at GEO-satellitter har her en grense på ca. 81 grader nord og sør.

Bakkeutstyret kan være enklere, billigere og mer bærbart.

  • Fordi fotavtrykket er mindre, vil det være færre bakkestasjoner som skal betjenes til enhver tid, dvs. bakkeutstyret kan oppnå bedre tjenester (tilgjengelighet og kapasitet).

Ulemper:

  • Satellitten er tilgjengelig i kun korte perioder ad gangen. 
  • Bakkeutstyret må være relativt nærme hverandre for å kunne betjenes av samme satellitt. 

LEO-nettverk

De nevnte ulempene kan unngås ved å opprette et nettverk av LEO-satellitter som beveger seg i ulike baner slik at en stasjon på bakken alltid har en satellitt innen rekkevidde. Forutsetningen er da at satellittene kan kommunisere hverandre slik at en “hand-over” operasjon kan skje når bakkeutstyret må skifte sin forbindelse til en ny satellitt. Satellittene kan også ha radiolinker til hverandre og kan danne en sti hvor dataene kan videresendes til et annet sted på kloden.

For å tilby en overføringstjeneste (av f.eks. tale, data, alarmer og posisjoner) kan LEO-nettverket bruke to alternative metoder:

  1. Benytte et godt utbygget nett av bakkestasjoner som er sammenknyttet gjennom et bakkenett (f.eks. Internet). Data fra klienter på bakken sendes direkte til en bakkestasjon som videresender mot mottakeren, tilsvarende motsatt vei.
  2. Bruke kommunikasjonslinker mellom satellittene slik at den danner en sti hvor dataene kan videresendes mot den satellitten som brukes av mottakeren.

Alternativ 1 benytter altså det landbaserte nettet til å oppnå global dekning, mens alternativ 2 benytter nettverket i verdensrommet til å oppnå det samme.

Satellittnettverk har eksistert siden 1990-tallet, det mest kjente i daglig bruk er Iridium. Iridium tilbyr telefontjeneste, lavhastighet dataoverføring, tekst- og posisjonsmeldinger. 66 satellitter flyr i 6 polarbaner med inklinasjon 86.4 grader slik illustrasjonen viser, 11 i hver bane. Satellittenes fotavtrykk overlapper slik at det alltid er en satellitt tilgjengelig for bakkeutstyret. Iridium oppnår global dekning ved å utnytte linker mellom satellittene, slik som beskrevet i alternativ 2 over.

Merk at det er en matematisk sammenheng mellom størrelse på fotavtrykket, flyvehøyde og omløpstid, og dermed også antall satellitter som kreves for kontinuerlig dekning for utstyr på bakken. Lavere flyvehøyde krever flere satellitter, men betyr også enklere krav til antenner og radioutstyret på bakken, Et redusert fotavtrykk betyr også færre klienter som skal dele på den samlede overføringskapasiteten.

Fra radiospeil til datanettverk

Kommunikasjonsutstyret i de tidlige geostasjonære satellittene var relativt enkelt: Det besto av en transponder, som betegner en radio som mottar et helt frekvensspekter (ikke bare en bestemt frekvens) og sender det samme signalet ut på et annet frekvensspekter. Omtrent som et speil som reflekterer alle fargene i lyset. Oppdeling av frekvensspekteret, modulasjon, kanaldeling m.m. foregikk på bakkeutstyret. 

En slik arbeidsdeling mellom satellitten og bakkeutstyret medførte den gang at kompleksiteten i systemet kunne plasseres på bakken, noe som bidro til at nye tjenester kunne utvikles ved å skifte ut kun bakkeutstyret. I dag konstrueres radioer på en annen måte enn før, og bruken av Software Defined Radio (SDR) gjør det mulig å endre på mye av radioens virkemåte gjennom å endre programvaren i radioen, selv om den befinner seg i en satellitt i bane. Sammen med annen teknologisk utvikling er nå trenden at satellittnettverk bygges med en høyere systemkompleksitet og ivaretar flere aspekter av tjenestene enn før, f.eks. at de selv sørger for hand-off mellom satellitter, og veivalg når data skal sendes via andre satellitter. Satellitter har altså utviklet seg fra å være radiospeil til å være nettverkskomponenter.

Hvordan ser en satellittkonstellasjon ut?

En gruppe med LEO-satellitter som omkretser jorden vil bli plassert i nøye uttenkte baner: De skal ha et fotavtrykk og en inklinasjon som gir dekning for en del av jordkloden, de skal ha en passende avstand mellom seg (i samme bane og mellom baner) slik at de kan danne kommunikasjonslinker med hverandre. Flyvehøyden vil også påvirke kravene til antenner i bakkeutstyret og energiforbruket i satellitten.  Vi vil i denne diskusjonen begrense oss til sirkulære baner, ikke elliptiske, fordi det er det vanligste valget for LEO-satellitter. 

Mesteparten av jordas befolkning bor i nærheten av ekvator. Kun en liten del av befolkningen bor sør for 30 grader sørlig bredde, og enda færre (0.1 %) nord for 61 grader nordlig bredde (hvor jeg bor). En satellitt med lav inklinasjon vil tilbringe mer av tiden i befolkede områder, men vil aldri dekke områder lenger nord. For en høy inklinasjonsvinkel er det motsatt. Men alle satellitter trenger ikke å bruke baner med lik inklinasjon. Starlink lar grupper av satellitter bruke baner med ulik inklinasjon og kan derfor tilby dekning også i polarområdene, men med et mindre antall satellitter og med lavere kapasitet. 

For en gitt flyvehøyde vil det være en maksimal rekkevidde for en link mellom satellittene. Satellittene må være synlige for hverandre, altså over horisonten, men også slik at signalet ikke svekkes på vei gjennom ionosfæren. Synslinjen bør ikke komme nærmere jordoverflaten enn ca. 400 km. Den maksimale avstandene mellom satellittene, målt ved vinkelen φ, blir derfor lett å beregne som en funksjon av flyvehøyden. R betegner jordas radius.

Eksempel: To Iridium-satellitter med en flyvehøyde på 781 km vil ha en maksimal avstand på 37.6°. Avstanden mellom banene i Iridium-systemet er 30°.

Når jordoverflaten blir projisert på et plan, slik som vist nedenfor, blir satellittbanene vist som en “slangeform”. Dette er et fenomen som gjelder alle storsirkler, dvs. sirkler med sentrum i jordas sentrum. Fly, skip og radiobølger vil vise det samme fenomenet. Illustrasjonen nedenfor viser et eksempel på hvordan 150 satellitter kan spre seg ut i mange baner og danne forbindelser både med bakkeutstyr og med hverandre. 

Legg også merke til hvordan satellittene (i dette tilfellet) ikke har forbindelse mellom banene i nærheten av ekvator, men derimot nærmere polområdene. Dette skyldes at avstanden mellom to lengdegrader er større ved ekvator, selv om det ikke fremkommer av den valgte projeksjonen. Meridianene (linjene mellom polene) er vist som parallelle linjer i projeksjonen, men er ikke parallelle i virkeligheten.

Et annet forhold som trenger litt oppmerksomhet, er at satellittene ikke følger jordas rotasjon. Når de har fullført et omløp vil de befinne seg lenger vest fordi jorda har dreiet mot øst i mellomtiden. En enkelt satellitt vil derfor dekke hele jordkloden etter et antall omløp, noe som utnyttes av vær- og overvåkningssatellitter. Disse kan overvåke hele jordoverflaten stykkevis til bestemte tider, men ikke kontinuerlig.

Konstellasjonen på illustrasjonen over viser et antall satellittbaner som beveger seg i samme retning og dekker halve jordas omkrets ved ekvator. De beveger seg “side om side” nordover, over polen og sydover på motsatt side. Alternativet hadde vært at banene gis skiftevis motsatt omløp. Fordelen med den valgte konstellasjon er at satellitter i nabobaner har bedre tid på seg til å kommunisere seg imellom. Når de har lav relativ hastighet vil dessuten kommunikasjonen mellom dem blir mindre forstyrret av såkalt Doppler-effekt. Dette prinsippet benyttes bl.a. av Iridium-systemet.

Når satellittene beveger seg i en slik formasjon vil de alltid ha de samme naboene i øst og vest, noe som vi kan utnytte i situasjoner hvor vi ønsker at de skal samarbeide.

Satellitter i samarbeidsgrupper

Man kan utnytte det forholdet at satellittene flyr i formasjoner til å danne samarbeidsgrupper og la oppgaver løses av disse i fellesskap. I det viste eksemplet over har hver satellitt 6 direkte naboer (N-NV-NØ-S-SV-SØ). Om man nummererer satellittene 1-7 etter et slikt mønster som vist nedenunder, oppnår man at alle satellittene, uansett tildelt nummer, har de andre tallene som direkte naboer.

De satellittene i “ytterkant” som ikke har naboer på begge sider finner dem to hopp unna i motsatt retning via naboen i NØ eller SV.

Satellittnettverk som et Distribuert System

Med den forutsetningen oppfylt at hver satellitt har et stabilt nettverk av naboer rundt seg, kan vi bygge et satellittnettverk hvor grupper på 7 satellitter samarbeider om å løse oppgaver, og hver satellitt er medlem av 7 ulike slike grupper. Om vi deler slike oppgaver inn i 7 roller kan alle vite hvilken nabo man skal overlate en deloppgave til, og denne satellitten vil spille den samme rollen overfor medlemmene i 7 grupper. 

Et annet interessant forhold er at to satellitter med samme rollenummer vil kunne ha glede av å lære fra hverandre, f.eks. utveksle innhold av sine datalagre. Det kan skje når de kan danne en kommunikasjonslink seg imellom. Illustrasjonen over den globale konstellasjonen ovenfor antyder at slike linker kan dannes under to ulike forhold:

  1. Ved polområdene, hvor avstanden mellom nabobanene er liten
  2. I “sømmen” mellom nord- og sørgående satellitter der de passerer hverandre i motsatt retning.

For å utvikle idéen om SIN eller “Cloud Computing in Space” er det nødvendig å betrakte et satellittsystem som et Distribuert System og låne metoder og teknikker fra dette fagfeltet. Et SIN vil ha mange fellestrekk med tradisjonelle mobile og distribuerte systemer, men også noen interessante forskjeller:

  1. Tradisjonelle mobile systemer består av en stasjonær infrastruktur og mobile klientnoder. Her er det omvendt, med stasjonære brukere (sett fra rommet) og en mobil infrastruktur.
  2. Bevegelsesmønsteret er forutsigbart og kjent, og det fremtdige påtrykket fra  klientnoder kan estimeres.
  3. Topologien i infrastrukturen er kjent slik at det ikke er nødvendig med protokoller for å oppdage kommunikasjonslinker (link discovery). Routingprotokoller er da heller ikke nødvendige, alle kan kalkulere ruter basert på det kjente bevegelsesmønsteret.

Utnytte øde områder til vedlikeholdsoppgaver og ruting

Det er vel kjent at jordas befolkning er svært ujevnt fordelt og at flesteparten bor på sterkt befolkede områder. Illustrasjonen av den globale konstellasjonen ovenfor viser nettopp dette ved hjelp av fargekoder for befolkningstettheten. I løpet av et omløp vil en satellitt tilbringe mesteparten av tiden over ørken, hav eller polområder hvor den vil ha svært lite trafikk mot klienter på bakken, avløst av korte perioder med et intenst påtrykk av forespørsler. Og disse periodene er fullt forutsigbare, vi vet når de kommer og satellitten husker fra forrige gang hvor høyt påtrykket var. 

For at satellitten skal ha mest mulig ressurser til å betjene disse trafikktoppene er det fornuftig om den kan gjøre mest mulig av “husholdningsoppgavene” over de øde områdene, som f.eks. å oppdatere sine hurtiglagre (cacher), overføre filer som ikke haster, oppdatere programvare m.m.

Skille mellom haste- og venteoppgaver

For å kunne utbytte dette potensiallet som er nevnt i forrige avsnitt er det nødvendig å identifisere deloppgaver i tjenesten som kan tilhøre én av to kategorier: Hastoppgaver og venteoppgaver. Altså, operasjoner som enten må utføres så raskt som mulig, eller oppgaver som kan utsettes til senere. På engelsk benevnes disse oppgavene som delay sensitive og delay tolerant.

Hasteoppgaver er de som knyttes til interaktive tjenester, altså der hvor det sitter mennesker og venter på svar, og hvor ingen andre oppgaver kan utføres i mellomtiden. I denne kategorien finner vi henting av web-sider, bruk av søkemotorer, dataregistrering av ulik art, utveksling av lynmeldinger, tale- og videokonferanser. Også støttetjenester for disse har hast: Oppslagstjenester for DNS-navn, databaseoperasjoner, videresending av data langs en sti m.m. Dette er oppgaver som ikke kan utsettes til f.eks. satellitten er over ubebodde områder, men må gis prioritet og utføres med de ressursene som foreligger for øyeblikket.

Venteoppgaver er slike som kan vente noen minutter eller timer før de fullføres eller et svar foreligger. Det fremste eksemplet på slike oppgaver er e-post, fordi vi er vant til å fortsette med andre oppgaver i påvente av et svar på en e-post melding. Andre eksempler inkluderer oppdatering av adresselister og andre felles datalagre, sikkerhetskopiering, oppgradering til nyere programvareversjoner, fremstilling av statistikker og raporter m.m.

Til omlegging av skytjenester til å bruke et SIN som plattform inngår det følgelig et designarbeid som må følge litt andre arkitekturprinsipper for å fordele oppgaver og deloppgaver i passende porsjoner som egner seg for den ressursmengden som satellittnettverket disponerer over til enhver tid.

Et SIN kan også velge å sende hasteoppgaver videre til andre mindre belastede satelliter for utføring der dersom den har de nødvendige forutsetninger for dette, og at kommunikasjonsveien dit har ledig kapasitet.

Caching og replikering

For programmer og tjenester som utføres i SIN-skyen vil det være nødvendig å lagre data som tilhører klienten på bakken, f.eks. et dokumentarkiv. Men disse dataene vil være sekundærkopier av klientens data, primærkopien vil trolig befinne seg i et lager på bakken. Grunnen til dette er:

  1. Det vil være behov for sikkerhetskopiering til et mer stabilt lager enn en satellitt
  2. Dataene i satellitten vil måte overføres til neste satellitt i banen i forbindelse med “handover”-operasjoner med noen minutters mellomrom

Av disse grunnene vil det være fornuftig å kun lagre de mest brukte dataene i satellitten, mens øvrig innhold ligger lagret et annet sted. Denne teknikken kalles for caching, og innebærer at vi kopierer deler av et primærlager til et sekundærlager som er raskere og billigere i bruk (gjerne nærmere klienten). 

Hvilket utvalg som skal kopieres til en cache er et interessant problem med svar som varierer med anvendelsen, klienten og tidspunktet. En måte å finne dette utvalget er å benytte seg av såkalt passiv replikering, hvor data som blir etterspurt og hentes fra “hovedlageret” på bakken blir plassert i cachen. Om cachen allerede er full slettes det elementet som ikke har vært i bruk på lengst tid (kalt Least Recently Used) for å gi plass til det nye. Dette er en velkjent teknikk men slik replikering skaper forsinkelse og er en hasteoppgave.

Aktiv replikering, derimot, er en “spekulativ” teknikk hvor man antar hvilket innhold som vil bli etterspurt i fremtiden og kopierer dette til cachen før de blir etterspurt. Aktiv replikering kan utføres som en venteoppgave, og skaper ingen forsinkelse så lenge utvalget i cachen dekker klientens behov.

Avslutning

Et Space Information Network byr på en lang rekke med problemstillinger som må studeres og løses. Jeg har her omtalt noen ganske få. For at denne artikkelen skal bli for lang avslutter vi nå. Videre funn i forskningen på SIN vil publiseres i denne bloggen i separate artikler.

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

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.

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.

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.

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: