43 total views,  4 views today

Det finnes flere alternative teknologier og produkter som kan tilby Virtuelle Private Nett (VPN), og i denne artikkelen skal vi studere WireGuard (WG). WG sies å være enklere å sette opp og bruke enn f.eks. OpenVPN, som vi har omtalt i en tidligere artikkel.

For en innledende forklaring om hva et VPN kan tilby, og en presentasjon av noen brukstilfeller, vil jeg foreslå de første par sidene av denne artikkelen.

Med en forutsetning om litt bakgrunnskunnskap om tunneler og røde/sorte endepunkter skal vi gjennomgå arkitekturen til WG og hvordan disse tre brukstilfeller kan løses:

1. Host-til-host: To maskiner ønsker beskyttet kommunikasjon seg i mellom, nettverkene på begge sider er ikke en del av løsningen. Maskinenes IP-adresser er kjent og konstante.
2. Road Warrior: Et kallenavn på en omreisende enkeltmaskin som trenger adgang til et beskyttet nettverk. En omreisende medarbeider som trenger adgang til bedriftens interne forretningssystemer fra hoteller og flyplasser er et eksempel på dette brukstilfellet.
3. Nett-til-nett: Flere interne nett ønskes sammenkoplet med beskyttede forbindelser slik at ressurs- og klientmaskiner kan kommunisere som om de var ett felles nett.

Wireguard er enklere enn OpenVPN

Underveis i denne artikkelen WG bli sammenlignet med OpenVPN, som er populær og utbredt, men har ord på seg for å være komplisert å sette opp. WG er et enklere produkt, som i mindre grad løser alle behovene i sine konfigurasjonsfiler. WG forutsetter at du selv, eller hjelpeprogrammer, setter opp nettverksporter, rutingtabeller og brannvegger med riktige parametre.

WG er en nettverksport

WG oppretter en nettverksport (network interface) med bestemte egenskaper, og den kan kommunisere med en WG nettverksport i en annen maskin. For at denne kommunikasjonen kan foregå over et ubeskyttet nettverk (slik som Internet er) er det valgt å lage en tunnel hvor IP-pakkene som utveksles (kalt røde) blir kryptert og lagt inni en annen IP-pakke (kalt sorte). De røde IP-adressene er adskilt fra de sorte IP-adressene (tilhører ulike subnett). De sorte IP-adressene er de “virkelige” IP-adressene som ruterne i Internet bruker for å sende pakken til riktig mottaker, mens de røde IP-adressene vises bare hos de partene som kommuniserer. Figuren nedenfor illustrerer dette forholdet.

Innledningsvis vil jeg beskrive oppsettet av WG i Linux-maskiner. Dette gir best forståelse av hvordan de ulike delene av et VPN spiller sammen. Siden vil jeg vise hvordan WG settes opp i Windows, ChromeOS, Android og iPadOS. For å sette opp en WG nettverksport med sort adresse 10.10.0.1/24 må du være i “sudo”-modus og skrive slik i et Linux konsollvindu:

$ sudo bash
# ip link add wg1 type wireguard
# ip addr add 10.10.0.1/24 dev wg1
# ip link set up wg1

(Kommandolinjer som må skrives i “sudo”-modus er angitt med #-tegnet, ellers $-tegnet.)

Overføringen av IP-pakker skal beskyttes

En god beskyttelse av overføringen gjennom et ubeskyttet nett skal sikre:

1. Konfidensialitet: Ingen kan tilegne seg kunnskap om den røde IP-pakken gjennom avlytting av overføringen
2. Integritet: Ingen kan endre innholdet i den røde IP-pakken uten at det oppdages hos mottakeren.
3. Autentisitet: Det skal være mulig for mottakeren å fastslå avsenderens identitet.

Alt dette kan man oppnå gjennom kryptering. WG benytter seg av å kryptere med et nøkkelpar, dvs at mottaker og avsender benytter ulike nøkler. Avsender benytter seg av en privat nøkkel for å kryptere og signere en rød IP-pakke før sending, og mottakeren benytter avsenderens offentlige nøkkel for å gjenopprette innholdet og kontrollere signaturen.

Kommunikasjon mellom to maskiner gjennom en WG-tunnel vil ikke forholde seg til navn eller andre identifikatorer på partene, men kun de offentlige nøklene. Fordi motparten presenterer data signert med sin private nøkkel, vil mottageren av denne signaturen forvisse seg om at det er eieren av den offentlige nøkkelen som sender, ikke en som bruker en offentlig nøkkel som tilhører en annen. Sikkerheten i en slik metode hviler på at den private nøkkelen ikke blir stjålet eller delt med andre, og det er en forutsetning som faktisk er ganske krevende å oppnå.

Jeg har tidligere skrevet en artikkel om Autentisering, og anbefaler å lese den om disse mekanismene er ukjent.

For å fremskaffe et nøkkelpar skriver du følgende inn i et Linux-konsoll (WG foretrekker at du legger disse filene på filområdet /etc/wireguard):

$ sudo bash
# cd /etc/wireguard
# wg genkey | cat > privkey
# wg pubkey < privkey > pubkey
# chmod 400 privkey 

Den offentlige nøkkelen (pubkey) deles fritt med andre, mens din private nøkkel (privkey) er din hemmelighet. Den skal lagres slik at ingen andre kan lese den.

WG og klienten må kjenne hverandres offentlige nøkler for å gi denne beskyttelsen

Teksten videre vil kreve noe kunnskaper om hvordan IP-adresser representeres og inngår i subnett og rutingtabeller. Om dette er ukjent stoff kan jeg anbefale denne artikkelen nå. Den gir nødvendig bakgrunninformasjon.

Ved overføring av en IP-pakke må avsenderens maskin kjenne dens private nøkkel, og mottakerens maskin må kjenne avsenderens offentlige nøkkel. Partene må konfiguere WG for dette formålet eksempelvis på denne måten:

# wg set wg1 listen-port 51820 private-key privkey \
peer <offentlig-nøkkel> allowed-ips 10.10.0.2/32 \
endpoint 192.168.9.12:51820

I dette eksemplet skrives det at

1. Parten ønsker å lytte etter mottatte IP-pakker på UDP port 51820
2. Den private nøkkelen ligger i filen privkey
3. Motpartens sorte IP-adresse er 10.10.0.2/32
4. Motpartens offentlige nøkkel er angitt bak ordet peer
5. Motpartens sorte endepunkt (adresse:port) er 192.168.9.12:51820

Et praktisk eksempel – Host-til-Host

En demonstrasjonsvideo for dette eksemplet:

Den enkleste konfigurasjonen, nemlig å kople opp en beskyttet kanal mellom to parter, skjer på følgende måte. Her viser jeg konfigurasjonsfilene etter hverandre, merk at de sorte ip-adressene (192.168.2….) er kun eksempler, og må endres for bruk andre steder.

Digresjon: WG opererer med “to lag” av sorte ip-adresser: Den virkelige adressen som viser vei gjennom det virkelige nettet (i dette tilfellet 192.168.2.124) og adresser knyttet til WG-nettverksportene (i dette tilfellet 10.10.0.1/30)

Vi forutsetter videre at nøklene er bli generert på forhånd, og at partenes private nøkler ligger i filen privkey. Den offentlige nøkkelen er med i konfigurasjonen hos motsatt part, så partene må ha utvekslet disse verdiene på forhånd.

Venstre maskin – wg-left.sh:

$ sudo bash
# ip link add wg1 type wireguard
# ip addr add 10.10.0.1/30 dev wg1
# ip link set up wg1
# cd /etc/wireguard
# wg set wg1 listen-port 51820 private-key privkey \
  peer 3aTXg7SbFDOc7rbscBUqKZsRqoHpvowHRkb+mNwuXRk= \
  allowed-ips 10.10.0.2/32 \
  endpoint 192.168.2.124:51820

Høyre maskin – wg-right.sh

$ sudo bash
# ip link add wg1 type wireguard
# ip addr add 10.10.0.2/30 deb wg1
# ip link set up wg1
# cd /etc/wireguard
# wg set wg1 listen-port 51820 private-key privkey \
  peer 9/c6yQloq6h3RRxyPrHHXO2b72GFT6aN5hGGRPY6YXw= \
  allowed-ips 10.10.0.1/32
 

Etter at disse kommandofilene er utført på begge partene kan de “pinge” hverandre med hverandres røde adresser: left pinger 10.10.0.2 og tilsvarende 10.10.0.1 for right. Om vi gir kommandoen sudo wg på left, vil utskriften se slik ut:

root@anders-medion:/home/anders# wg
interface: wg1
public key: 9/c6yQloq6h3RRxyPrHHXO2b72GFT6aN5hGGRPY6YXw=
private key: (hidden)
listening port: 51820

peer: 3aTXg7SbFDOc7rbscBUqKZsRqoHpvowHRkb+mNwuXRk=
endpoint: 192.168.2.124:51820
allowed ips: 10.10.0.2/32

Dynamisk adresse i endepunktet

En detalj som er nødvendig å merke seg er at right ikke har oppgitt noe endpoint for sin motpart. Den kan følgelig ikke pinge left uten denne informasjon, men den tilegner seg den informasjonen første gang den mottar et ping fra left. Det kan vi fastslå ved å gi wg-kommandoen på right før og etter den har mottsatt sin første ping fra left. Dette er en nyttig detalj dersom den ene parten ikke har fast IP-adresse, noe som er tilfelle når man kopler seg til Internet fra hoteller og restauranter. En slik part kalles ofte for Road Warrior, og neste avsnitt vil beskrive hvordan vi kan lage en konfigurasjon med flere Road Warriors.

Avslutningsvis vil vi påpeke to egenskaper med denne konfigurasjonen: (1) Den er mer nyttig enn den først synes, fra et terminalkonsoll i left kan en bruker logge seg inn på right, og deretter benytte seg av tjenester og innlogging tilgjengelig i right sitt beskyttede nettverk. (2) Én av de to partene må ha en adresse som kan nås via en internet-adresse. Enten ved maskinen faktisk står med en virkelig Internet IP-adresse, eller bak en brannvegg (med Internet IP-adresse) som har satt opp port forwarding til maskinen.

Road Warriors – for å bruke hovedkontorets interne systemer

En bedrift har sine forretningssystemer som trolig er beskyttet med passord for innlogging, men et enkelt passord gir for dårlig beskyttelse mot angrep fra Internet. En bedre beskyttelse kan de oppnå med et VPN. En Road Warrior konfigurasjon vil skille seg fra det i forrige avsnitt ved at:

1. Det er ikke kun én Road Warrior som har ukjent IP-adresse og som vil kople seg til en sentralt plassert part, men flere. Det er altså behov for lagring av flere offentlige nøkler og sorte IP-adresser.
2. Det er ikke den sentralt plasserte parten som kjører de ønskede forretningssystemene, så den sentrale parten må rute trafikken videre inn i det beskyttede nettet.
   
   Den sentrale parten blir heretter kalt en VPN-ruter. Klientkonfigurasjonen (som brukes av den omreisende parten) trenger de samme opplysningene som før, men vi skal nå lagre dem i en konfigurasjonsfil.

Her følger en demonstrasjonsvideo om Road Warrior-konfigurasjon:

WG konfigurasjonsfil

Vi vil konfigurere VPN-ruteren med en konfigurasjonsfil fremfor bruk av direkte kommandoparametre. I en konfigurasjonsfil har vi plass til å liste opp en rekke motparter og deres offentlige nøkler og sorte IP-adresser. Konfigurasjonsfilen (i dette tilfellet kalt wg1.conf) kan se slik ut:

[Interface]
PrivateKey = oOWwjJHkckYU3uNgI5UoJpLENPjtDa4bvW3Rj82bV0M=
Listenport = 51820

[Peer]
# Desktop Linux
PublicKey = M0YMsn88TZPEedCKzI33RhdS9VWR0qpXm6e2zhQBpSA=
allowedIPs = 10.0.1.2/32

[Peer]
# Raspberry Pi 5
PublicKey = 60cdqn+GgVodrNDdfPVCv39aZCvpeNKm75kF2lJC+Fs=
allowedIPs = 10.0.1.3/32

[Peer]
# Medion Laptop
PublicKey = n/Eriwa1pZ7T2R5Qd4n96tQ8Ptq0SUfblIY8ZvswehY=
allowedIPs = 10.0.1.4/32

Og selve kjørefilen (shell-skriptet) kan se slik ut (må kjøres i sudo-modus):

ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.0.1.1/24 dev wg1
wg setconf wg1 wg1.conf
ip link set up wg1

Husk å legge disse filene på /etc/wireguard. Merk at konfigurasjonsfilen ikke inneholder opplysninger om andres endpoint, av samme grunn som nevnt i forrige avsnitt. Disse partene kan nemlig kople til VPN-ruteren med ulike IP-adresser hver gang.

Setningen allowedIPs angir hvilke IP-adresser som VPN-ruteren kan bruke for å sende til en klient med en bestemt offentlig nøkkel. Ved å angi dette som en enkelt adresse, angitt med /32 prefiks, tvinges klienten til å bruke denne røde adressen, og på den måten unngå at flere klienter bruker samme sorte IP-adresse.

Denne konfigurasjonen tillater tre Road Warriors å kople seg til, presentere sin offentlige nøkkel, sin sorte IP-adresse og sitt endepunkt (sorte IP-adresse og UDP port). I tillegg presenterer de et dataelement kryptert med sin private nøkkel, for å bevise at de “eier” denne nøkkelen.

Konfigurasjonen av en Road Warrior

Klientkonfigurasjonen vil nå bruke en egen konfigurasjonsfil. I det følgende ekemplet skal klienten kunne adressere IP-pakker til nettverket “bakenfor” VPN -ruteren, og dette må deklareres i en allowed-ips-setning som et IP subnett, i dette eksemplet 192.168.2.0/24. Det samme subnettet må legges inn i maskinens rutingtabell med ip route add...Vi lar shell-skriptet for klientkonfigurasjonen se slik ut:

ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.0.1.4/24 dev wg1
ip link set up wg1
ip route add 192.168.2.0/24 via 10.0.1.4
wg setconf wg1 wg1.conf

Skriptet henviser til konfigurasjonsfilen wg1.conf, innholdet av den er som følger:

[Interface]
PrivateKey = n/Eriwa1pZ7T2R5Qd4n96tQ8Ptq0SUfblIY8ZvswehY=
ListenPort = 51820

[Peer]
PublicKey = 9gUrCU32BQS4pzBe+jbs1P5T1VMDcti11tg7VkRYH0U=
Endpoint = hos.fongen.no:51820
AllowedIPs = 10.0.1.0/24
AllowedIPs = 192.168.2.0/24

I dette tilfellet er det [Interface]-delen som beskriver konfigurasjonen av egen maskin, mens [Peer]-delen beskriver VPN-ruteren. Forøvrig er all informasjon i disse to filene allerede drøftet, så ingen ytterlig forklaring vil bli gitt.

VPN-ruteren må videresende IP-pakker

En Road Warrior kan altså kople seg til VPN-ruteren på nevnte måte, men er først og fremst interessert i å kommunisere med et internt/beskyttet nett innenfor ruteren, koplet til ruteren gjennom en nettverksport. For dette eksemplet kaller vi denne nettverksporten for eth0. IP-pakker med mottakeradresser i det interne nettet skal sendes dit, og IP-pakker i motsatt retning skal sendes gjennom WG-tunnelen tilbake til klienten. To kommandoer i VPN-ruteren samt en mulig konfigurasjon av stedets brannvegg vil fikse dette:

1. Ruteren må settes til å rute IP-pakker. Skriv denne kommandoen i sudo-modus:
   # echo 1 > /proc/sys/net/ipv4/ip_forward
   Denne innstillingen må gjøres igjen for hver oppstart, men du kan også redigere filen /etc/sysctl.conf (evt. opprette den) og skrive inn setningen net.ipv4.ip_forward = 1 og deretter restarte maskinen.
2. IP-pakkene som rutes fra VPN -ruteren til det interne nettet vil ha avsenderens røde IP-adressen som avsenderadresse, og maskinene der vil ikke uten videre vite hvordan IP-pakker med slike adresser skal sendes tilbake til VPN-ruteren. En løsning på dette problemet er at avsenderadressen på IP-pakkene fra en RoadWarrior gis VPN-ruterens adresse med en såkalt NAT-funksjon. Les denne artikkelen for å lære om NAT dersom dette er ukjent stoff. NAT-funksjon på eth0 lages med denne kommandoen i sudo-modus:
   # iptables -t nat - A POSTROUTING -o eth0 -j MASQUERADE
   
3. Det beskyttede nettet (som VPN-ruteren befinner seg i) vil mest sannsynlig være isolert fra Internet gjennom en brannvegg. For at IP-pakker utenfra skal finne veien til VPN-ruteren kreves en konfigurasjon i brannveggen som kalles port forwarding. Dette innebærer at IP/UDP-pakker med brannveggens IP-adresse og UDP-portnummer (i dette eksemplet) 51820 vil sendes inn i nettet med VPN-ruterens IP-adresse. Alle hjemmerutere og brannvegger har denne muligheten.

Bruk av WG på andre plattformer enn Linux

Programvare som støtter en Road Warrior finnes på flere plattformer enn kun Linux. Her følger erfaringer med et antall av dem

Android/iPadOS

Appene for RoadWarrior for iPadOS og Android kommer fra samme utvikler, og de er så lik hverandre at vi ikke gir begge en separat omtale.

Jeg har installert og testet Android-appen “WireGuard” fra “Wireguard development Team” (det høres ut som en offisiell app). Versjonen jeg testet var 1.0.2. For å opprette og konfigurere et VPN, gjør følgende:

• Fra grunnbildet i appen, trykk på ‘+’-tegnet nederst til høyre for å opprette et VPN. I dette tilfellet, velg “Create from scratch”. Appen kan generere et nøkkel om du ikke ønsker å skrive inn en eksisterende.
  • I skjemaet som nå vises skrives følgende informasjon:
  • Name – selvvalgt navn (uten mellomrom)
  • Private key – Skriv inn en du har, eller få den laget av appen
  • Public key – Denne avledes av privatnøkkelen, men du kan kopiere fra dette feltet for å sende til andre.
  • Adresses – Din sorte IP-adresse. Valgt fritt, men må være i samme IP subnett som VPN-ruterens adresse
  • Listen port – 51820 er en fin verdi
  • DNS servers – Om det er behov for å benytte en DNS-tjeneste i det interne nettet, kan du skrive inn dens IP-adresse her.
  • [Peer] Public key– VPN-ruterens offentlige nøkkel, tilsendt.
  • PreShared key – Ikke brukt i disse eksemplene. Kan gi styrket kryptografisk beskyttelse
  • PersistentKeepalive – Ikke brukt i disse eksemplene. Kan lage “hjerteslag” for å holde brannveggen “åpen”
  • Endpoint: VPN -ruterens sorte endepunkt. En “virkelig” IP-adresse
  • AllowedIPs – subnett som klienten ønsker å adressere “bak” VPN-ruteren.

Trykk på diskettsymbolet for å lagre, og du kan siden slå denne oppkoplingen av og på.

ChromeOS

WireGuard er forhåndsinstallert i ChromeOS, som er operativsystemet i en Chromebook. På panelet for for bl.a. nettverksinnstillinger (se bilde nedenfor) er det en knapp for “VPN”, og bak den knappen ligger det mulighet for å opprette nye VPN-instanser merket “+”. Panelet for å konfigurere et VPN ber om de samme opplysningene som i konfigurasjonsfilene for Linux.

Opplysningene som kreves for en konfigurasjon av et WG VPN er disse (lskjemaet leses fra toppen og ned)

Tjenestenavn – selvvalgt
Leverandørtype – “WireGuard”
Klient IPadresse – klientens sorte IP-adresse, i samme subnett som VPN-ruterens.
Navnetjenere – DNS-tjener i det beskyttede nettet, ellers ubrukt.
Nøkkel – Om det allerede er laget nøkler, velg “jeg har et nøkkelpar”, og kopiere inn privatnøkkel i feltet under (ikke vist på bildet). Man kan også velge “generer et tilfeldig nøkkelpar”. Når skjemaet er utfylt og “kople til” er trykket, gå tilbake til panelet og finne den offentlige nøkkelen som må oppgi til VPN-ruterens administrator
Motpart/offentlig nøkkel – her kopieres inn VPN-ruterens offentlige nøkkel
Forhåndsdelt nøkkel – ikke brukt i disse eksemplene
Sluttpunkt – VPN-ruterens sorte IP-adresse og UDP portnummer
Tillatte IP-adresser – VPN-ruterens røde IP-adresse, og det subnettet du ønsker adgang til. Om du velger å skrive 0.0.0.0/0, vil all trafikk, også til Internet forøvrig, gå via VPN-ruteren.
Vedvarende keepalive-intervall – kan stå tomt for denne gang

Se knappene for “Kople opp” og “Kople ned”. Nå bør ressursene i det aktuelle nettet være tilgjengelig. Også Linux-konsollet og Android-apper på Chromebook får adgang til de samme ressursene.

Windows

WG er ikke ferdig installert i Windows, og må lastes ned og installeres separat. Appen kan lastes ned fra https://download.wireguard.com/windows-client/ og installeres på vanlig måte.

Når WG for Windows startes, viuses et vindu som lister opp eksisterende WG-konfigurasjoner, og som med tastetrykket Ctrl-N vil generere nøkler for en ny WG-konfigurasjon og vise redigeringvinduet som er vist nedefor. I bildet nedenfor vises de vante opplysningene fra Linux-konfigurasjonen. Her brukes en konfigurasjonsfil for klienten, slik at [Interface]-delen nå beskriver maskines egen konfigurasjon, mens [Peer]-delen viser endepunkt og offentlig nøkkel for VPN-ruteren. Tilbake til startvinduet finnes en “Aktivér”-knapp som kopler opp WG-tunnelen. Som tidligere må den genererte offentlige nøkkelen bli installert i VPN-ruterens konfigurasjon på foirhånd. Et nytt element i konfigurasjonsfilen er “Address”-linjen, som inneholder klientens sorte IP-adresse. Ellers er dette helt likt Linux-konfigurasjonen, med den forskjell at det ikke er nøvendig å sette opp rutingtabeller selv.

WireGuard i nett-til-nett konfigurasjon, et fyldig eksempel

Som nevnt gir WireGuard en en beskyttet link mellom to endepunkter, og befatter seg ikke med f.eks. ruting. Når vi ønsker at interne nett skal knyttes sammen slik at maskinene i alle nettene skal kunne kommunisere, trenges en ruter i hvert nett og linker mellom dem. En slik konfigurasjon kan vises på denne måten:

IP-adressene i hvert av de 4 nettene på figuren må danne separate subnett, og ruterne må kjenne til adressene på alle “grenene”. Figuren over viser slik informasjon, men hver enkelt maskin trenger også informasjon om hvilken “vei” IP-pakkene skal sendes for å nå mottakeren i flere hopp. Les denne artikkelen dersom dette ikke er kjent stoff.

Linken mellom R1 og R2 på figuren over bør beskyttes om den går gjennom offentlige nettverk, og VPN-teknologi er godt egnet for det formålet. Tidligere i denne artikkelen brukte i WireGuard for å beskytte linken mellom to maskiner, og vi skal bruke et lignende oppsett for å knytte sammen VPN-rutere. Vi skal altså ta med elementer fra Host-til-host og RoadWarrior løsningene videre.

Vi velger å sette opp et fyldig eksempel: Tre nettverk, A, B og C, skal knyttes sammen med beskyttede WG-linker. Sammenknytningen skal gjøres med bruker av VPN-rutere som både håndterer WG-parametrene og videresending av IP-pakker basert på rutingtabeller.

I tillegg skal en gruppe Road Warriors kunne kople seg til fra hoteller og flyplasser og få adgang til ressurser i alle de tre andre nettverkene. Her kommer erfaringene med Road Warrior eksemplet tidligere i artikkelen til nytte.

PDF-tegningen nedenfor er stor og viser arkitekturen i denne nettverket, og utdrag av rutingtabellene og WG-parametrene som inngår. Trykk på Download-knappen for å se tegningen i full størrelse. De sorte linjene er linker som bruker Internet og må derfor beskyttes. En full presentasjon av konfigurasjonsfilene for hver maskin i dette nettverket vil presenteres på slutten av denne artikkelen.

Rutingtabellene på figuren kan studeres for å fastslå at IP-pakker sendes til riktige røde nettverk (A-D) basert på deres IP-adresse. Detaljer knyttet til nøkkelutveksling og konfigurasjon av WG-parametre er i noen grad utelatt, men følger de samme reglene som ble presentert i gjennomgangen av Host-til-Host kommunikasjon. På figuren representerer noden A-h1 en enkel brukernode (host) i nett A, men svitsj-symbolet indikerer at mange maskiner kan befinne seg i nett A, og de vil ha identisk konfigurasjon.

IP-adressene i nettverkene A, B og C følger reglene for IP-subnett og gjør det overflødig å benytte noen NAT-funksjoner. Basert på rutinginformasjonen i maskiner og VPN-rutere vil alle adresser som forekommer i dette samlede nettet finne frem til sin adressat.

Noe annet gjelder RoadWarriors som utgjør nett D. De har alle mulig adresser ettersom hvor de befinner seg, og addresser som endrer seg fra gang til gang. Dette er ikke et problem for WG, som gjerne setter opp forbindelser under slik forhold, men det finnes ingen fornuftig metode for å sørge for at IP-pakker med alle slags ukjente avsenderadresser skal finne tilbake til riktig sted når de ankommer på denne måten. Derfor er det plassert en NAT-enhet i utgangen fra D-vpn, på samme måte som i RoadWarrior-eksemplet tidligere.

En kort sammenligning mellom OpenVPN og WireGuard

WireGuard kommer med en enklere idé om å sette opp en tunnel mellom ta maskiner, eksponert gjennom vanlige nettverksporter. Den bruker kryptonøkler på en enklere måte enn hva man gjør i et “Public Key Infrastructure” (PKI), men mister da også noen av fordelene som et PKI faktisk tilbyr:

Et PKI vil bruke digitale sertifikater for å attestere hvilken person/bruker/gjenstand den offentlige nøkkelen tilhører. OpenVPN kan settes opp til å godta offentlige nøkler som er sertifisert med bestemte navneregler eller utsteder. Det gjør det unødvenig å registrere hver klient direkte inn i VPN-tjenerens konfigurasjon, noe som gjør administrasjonen av et stort VPN med mange klienter mer håndterlig. Et prinsipp jeg fremholder er at “infrastrukturkomponenter skal ikke drive tillitshåndtering”, og det oppnår vi ved å skille trafikkhåndtering og brukeradministrasjon slik OpenVPN tilbyr.

En veldig viktig egenskap med nøkkelsertifikater (og en av hovedgrunnene til at nøkkelsertifikater ble oppfunnet) er at man unngår man-in-middle angrep fordi nøklene er uløselig knyttet til en identifikator (som representerer eieren av nøkkelen). Den sikkerheten tilbyr ikke WireGuard, og overføringen av offentlige nøkler mellom VPN -tjeneren og klientene (og alle parter som vil kommunisere via WG) må skje via autentiserte kanaler som hindrer partene å utgi seg for andre.

Men gitt at dette blir håndtert på en trygg måte, så unngår WG den jungelen av interoperabilitetsproblemer som herjer i anvendelser som benytter PKI. Sertifikater kan utformes og valideres på et utall forskjellige måter. Det resulterer i at sertifikater laget for én anvendelse ofte ikke kan brukes i en annen, og at sikkerheten i sertifikatvalidering ikke lar seg teste og kontrollere på en tilfredsstillende måte.

Min overfladiske observasjon av WG er at den enkle bruken av nøkler og kryptoalgoritmer gjør det enklere å f.eks. flytte sin klientkonfigurasjon fra én maskin til den neste. Nøklene har en enkel og kortfattet tekstrepresentasjon som kan overføres gjennom alle slags tekstbasert kanaler. Og jeg ble positivt overrasket over at WG-appene for Windows, Android m.m. var enkle å sette opp og virket tilfredsstillende uten for mye plunder.

Min vurdering er at WireGuard er god egnet for småskala applikasjoner, men har egenskaper som gjør den mindre egnet enn OpenVPN dersom antallet maskiner og klienter er høyt.

Samlede konfigurasjonsfiler

Som et appendix vises her konfigurasjonsopplysninger for hver av de 8 nodene på figuren. Netplan (deklarasjon av IP-adresser), rutingtabell, oversikt over alle nettverksportene, oppstartsskript for WG og WG-konfigurasjonsfil. Noen detaljer i disse filene er ikke blitt behandlet i teksten, f.eks. er nettverket 192.168.100.0/24 brukt som underliggende nettverk for de sorte linkene. Videre er VirtualBox brkt for å kjøre nodene som Virtuall Maskiner, og nettverk mellom VM’ene er ikke vist direkte, men i hovedsak er de konfigurert separat for hvert rødt nett, og ett felles for de sorte linkene.

A-h1

KONFIGURASJON AV A-h1:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.10.101/24
            routes:
                - to: 192.168.20.0/24
                  via: 192.168.10.1
                - to: 192.168.30.0/24
                  via: 192.168.10.1
    version: 2

RUTINGABELL:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.20.0    192.168.10.1    255.255.255.0   UG    0      0        0 enp0s8
192.168.30.0    192.168.10.1    255.255.255.0   UG    0      0        0 enp0s8

IP ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 85671sec preferred_lft 85671sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.10.101/24 brd 192.168.10.255 scope global enp0s8
       valid_lft forever preferred_lft forever

B-h1

KONFIGURASJON AV B-h1

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.20.101/24
            routes:
                - to: 192.168.10.0/24
                  via: 192.168.20.1
                - to: 192.168.30.0/24
                  via: 192.168.20.1
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
192.168.10.0    192.168.20.1    255.255.255.0   UG    0      0        0 enp0s8
192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.30.0    192.168.20.1    255.255.255.0   UG    0      0        0 enp0s8

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84917sec preferred_lft 84917sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.20.101/24 brd 192.168.20.255 scope global enp0s8
       valid_lft forever preferred_lft forever

C-h1

KONFIGURASJON AV C-h1:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.30.101/24
            routes:
                - to: 192.168.10.0/24
                  via: 192.168.30.1
                - to: 192.168.20.0/24
                  via: 192.168.30.1
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
192.168.10.0    192.168.30.1    255.255.255.0   UG    0      0        0 enp0s8
192.168.20.0    192.168.30.1    255.255.255.0   UG    0      0        0 enp0s8
192.168.30.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84260sec preferred_lft 84260sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.30.101/24 brd 192.168.30.255 scope global enp0s8
       valid_lft forever preferred_lft forever

A-vpn

KONFIGURASJON AV A-vpn:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.10.1/24
        enp0s9:
            dhcp4: no
            addresses:
                - 192.168.100.1/28
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.11.12.0      0.0.0.0         255.255.255.252 U     0      0        0 wg1
10.11.12.4      0.0.0.0         255.255.255.252 U     0      0        0 wg2
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.20.0    10.11.12.1      255.255.255.0   UG    0      0        0 wg1
192.168.30.0    10.11.12.5      255.255.255.0   UG    0      0        0 wg2
192.168.100.0   0.0.0.0         255.255.255.240 U     0      0        0 enp0s9

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 83258sec preferred_lft 83258sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.10.1/24 brd 192.168.10.255 scope global enp0s8
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.100.1/28 brd 192.168.100.15 scope global enp0s9
       valid_lft forever preferred_lft forever
5: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.11.12.1/30 scope global wg1
       valid_lft forever preferred_lft forever
6: wg2: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.11.12.5/30 scope global wg2
       valid_lft forever preferred_lft forever

STARTSKRIPT:
# Create link to AVPN
ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.11.12.1/30 dev wg1
ip link set up wg1
wg setconf wg1 wg1.conf
ip route add 192.168.20.0/24 via 10.11.12.1

# Create link to CVPN
ip link del wg2 || true
ip link add wg2 type wireguard
ip addr add 10.11.12.5/30 dev wg2
ip link set up wg2
wg setconf wg2 wg2.conf
ip route add 192.168.30.0/24 via 10.11.12.5

WG1.CONF:
[interface]
privateKey = iD9fo3ezXcn8njwhmireyxea6vP9HA8s0rVWf9Wjcl4=
listenPort = 51820

[peer]
publicKey = EIhO9XcyQG8yYvlR11aORUQ8NBYGcQMI0yHeguPfeh8=
allowedIPs = 10.11.12.2/32
allowedIPs = 192.168.20.0/24
endpoint = 192.168.100.2:51820

WG2.CONF
[interface]
privateKey = iD9fo3ezXcn8njwhmireyxea6vP9HA8s0rVWf9Wjcl4=
listenPort = 51821

[peer]
publicKey = 6tl3fRAgUPDhAqOrT0Nr2tyIecp7UDgpl2nKh0n1+HM=
allowedIPs = 10.11.12.6/32
allowedIPs = 192.168.30.0/24
endpoint = 192.168.100.3:51821

B-vpn

KONFIGURASJON AV B-vpn:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.20.1/24
        enp0s9:
            dhcp4: no
            addresses:
                - 192.168.100.2/28
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.11.12.0      0.0.0.0         255.255.255.252 U     0      0        0 wg1
192.168.10.0    10.11.12.2      255.255.255.0   UG    0      0        0 wg1
192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.30.0    10.11.12.2      255.255.255.0   UG    0      0        0 wg1
192.168.100.0   0.0.0.0         255.255.255.240 U     0      0        0 enp0s9

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 85780sec preferred_lft 85780sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.20.1/24 brd 192.168.20.255 scope global enp0s8
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.100.2/28 brd 192.168.100.15 scope global enp0s9
       valid_lft forever preferred_lft forever
5: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.11.12.2/30 scope global wg1
       valid_lft forever preferred_lft forever

STARTSKRIPT:
ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.11.12.2/30 dev wg1
ip link set up wg1
wg setconf wg1 wg1.conf
ip route add 192.168.10/24 via 10.11.12.2
ip route add 192.168.30/24 via 10.11.12.2

WG1.CONF
[interface]
privateKey = GBXJpAu9SV+5HGQKitiur1By0lVDSA2WtT7JSN2iLF8=
listenPort = 51820

[peer]
publicKey = AGlXvCzKsYF7rooofmzNbIB3tSHUJ6R5vkyTd1+BUlc=
allowedIPs = 10.11.12.1/32
allowedIPs = 192.168.10.0/24
allowedIPs = 192.168.30.0/24
endpoint = 192.168.100.1:51820

C-vpn

KONFIGURASJON AV C-vpn:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.30.1/24
        enp0s9:
            dhcp4: no
            addresses:
                - 192.168.100.3/28
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.11.12.4      0.0.0.0         255.255.255.252 U     0      0        0 wg1
192.168.10.0    10.11.12.6      255.255.255.0   UG    0      0        0 wg1
192.168.20.0    10.11.12.6      255.255.255.0   UG    0      0        0 wg1
192.168.30.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.100.0   0.0.0.0         255.255.255.240 U     0      0        0 enp0s9

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 85155sec preferred_lft 85155sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.30.1/24 brd 192.168.30.255 scope global enp0s8
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.100.3/28 brd 192.168.100.15 scope global enp0s9
       valid_lft forever preferred_lft forever
5: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.11.12.6/30 scope global wg1
       valid_lft forever preferred_lft forever

STARTSKRIPT:
ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.11.12.6/30 dev wg1
ip link set up wg1
wg setconf wg1 wg1.conf
ip route add 192.168.10.0/24 via 10.11.12.6
ip route add 192.168.20.0/24 via 10.11.12.6

WG1.CONF
[interface]
privateKey = gOhx12lAqnqcVOF9qVXeaQlaDuMsOumDvAUpoSF4O1I=
listenPort = 51821

[peer]
publicKey = AGlXvCzKsYF7rooofmzNbIB3tSHUJ6R5vkyTd1+BUlc=
allowedIPs = 10.11.12.5/32
allowedIPs = 192.168.10.0/24
allowedIPs = 192.168.20.0/24
endpoint = 192.168.100.1:51821

D-vpn

KONFIGURASJON AV D-vpn:

NETPLAN:
network:
    ethernets:
        enp0s3:
            dhcp4: true
        enp0s8:
            dhcp4: no
            addresses:
                - 192.168.10.2/24
            routes:
                - to: 192.168.20.0/24 
                  via: 192.168.10.1
                - to: 192.168.30.0/24
                  via: 192.168.10.1
        enp0s9:
            dhcp4: no
            addresses:
                - 192.168.2.9/24
    version: 2

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.0.2.3        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s9
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8
192.168.20.0    192.168.10.1    255.255.255.0   UG    0      0        0 enp0s8
192.168.30.0    192.168.10.1    255.255.255.0   UG    0      0        0 enp0s8

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84672sec preferred_lft 84672sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s8
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.2.9/24 brd 192.168.2.255 scope global enp0s9
       valid_lft forever preferred_lft forever


STARTSKRIPT:
ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.11.13.1/24 dev wg1
ip link set up wg1
wg setconf wg1 wg1.conf
iptables -t nat -A POSTROUTING -o enp0s8 -j MASQUERADE

WG1.CONF:
[interface]
privateKey = iABCVCYnoe3Hh4xup1L7GPgJ+pEGsN71l+stTq+mamg=
listenPort = 51820

[peer]
# Linux client
publicKey = 3aTXg7SbFDOc7rbscBUqKZsRqoHpvowHRkb+mNwuXRk=
allowedIPs = 10.11.13.2/32

[peer]
# Android client
publicKey = c9pYVjABCNWyA6BhAjUhjnjXtMsR42Bim5G5X+Da+yk=
allowedIPs = 10.11.13.3/32

D-rw

KONFIGURASJON AV D-rw:

RUTINGTABELL:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 enp0s31f6
10.11.13.0      0.0.0.0         255.255.255.0   U     0      0        0 wg1
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.10.0    10.11.13.2      255.255.255.0   UG    0      0        0 wg1
192.168.20.0    10.11.13.2      255.255.255.0   UG    0      0        0 wg1
192.168.30.0    10.11.13.2      255.255.255.0   UG    0      0        0 wg1

IP-ADRESSER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.2.206/24 brd 192.168.2.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 38451sec preferred_lft 38451sec
3: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.11.13.2/24 scope global wg1
       valid_lft forever preferred_lft forever

STARTSKRIPT:
ip link del wg1 || true
ip link add wg1 type wireguard
ip addr add 10.11.13.2/24 dev wg1
ip link set up wg1
wg setconf wg1 wg1.conf
ip route add 192.168.10/24 via 10.11.13.2
ip route add 192.168.20/24 via 10.11.13.2
ip route add 192.168.30/24 via 10.11.13.2

WG1.CONF:
[interface] 
privateKey = eA8MDscVpkhm/cAJcE8AeOx2+ozz+CeD0OADuFdrznk=
listenPort = 51820

[peer]
publicKey = 76+YJu/TMaGJgh2dEZaB3RasxeZ1fXTPw5a2u9XXAB0=
allowedIPs = 10.11.12.9/32,192.168.0.0/16
endpoint = 192.168.2.9:51820

 80 total views

Luckfox Pico Mini er en mikrokontroller til 220 kroner, som kjører fullt Linux operativsystem. Den plasserer seg dermed mellom enklere mikrokontrollere (ESP32, RP2040) og dyrere datamaskiner som Raspberry Pi. Vi har brukt litt tid på å studere den, og formidler noen erfaringer og observasjoner i denne artikkelen.

(c) Anders Fongen, april 2026

Som kjent kjører operativsystemet Linux i såkalte “embedded systems”, i små ettkorts datamaskiner, hvor Raspberry Pi utmerker seg som mest kjent. Vi kom over en produkt som kalles Luckfox Pico Mini, som presser et komplett Linux-system inn på en frimerkestort kretskort og som koster ca 220 kroner. Ikke til å motstå, altså.

Utrustningen

Kretskortet har en port for tilkopling av et kamera, et kortspor for mikroSD, en USB-C kontakt, 64 MB minne (som deles mellom lager og arbeidsminne). Programvaren på maskinen inkluderer de vanligste programmene og kommandoene, og etablerer en IP-forbindelse til en vertsmaskin via USB-kabelen, ved bruk av RNDIS-protokoll. Konsolltjenester (SSH og Telnet) tillater innlogging fra vertsmaskinen for betjening med et vanlig kommandoskall (shell).

Filsystem på et microSD-kort blir “automountet” i filsystemet slik vi ønsker det. Et minnekort blir dermed et opplagt medium både for overføring av filer og utvidelse av lagerplassen.

Kontrolleren er ikke utstyrt med WiFi- eller ethernet-adapter, så nettverkskommunikasjonen foregår gjennom USB-forbindelsen via vertmaskinen som blir satt opp som en IP-ruter. Videoen som er lenket inn nedenfor demonstrerer dette.

Det kan tilføyes at det finnes et WiFi-kort som kan plugges inn i miniSD-sprekken, men bruken av den krever en ny bygging av OS-kjernen, og vil dessuten hindre brukes av et minnekort. WiFi-kortet er vist på bildet ovenfor.

Installering av programvare

Kontrolleren er beskjedent utstyrt med minne og lager, og en del programmer er utelatt. Vi noterer oss (med forbehold om hva vi kan ha oversett) at dns, cc, perl, rsync, cron, pip er utelatt.

Det finnes ikke noe programvarelager (repository) for dette produktet, heller ikke er det ressurser for å kompilere programvare internt i kontrolleren. Nødvendig programvare kan fremskaffes på én av to måter:

1. Krysskompilering på en ordinær Linux-maskin, med påfølgende filoverføring til kontrolleren (med f.eks. SCP)
2. Overføring av Python kildekode og programbiblioteker til kontrolleren, evt. redigering av kildekode med en editor på kontrolleren (nano). Siden Python-kode er portabel mellom maskinarkitekturer så kunne pip-programmet vært kjekt å ha her.

Pkt. 2 beror på at Luckfox har “voksenpython” versjon 3.11 installert, i motsetning til ESP32- og RP2040-baserte kontrollere som har Mikropython. Dette tillater bruk av større og mer avanserte programbiblioteker. Erfaringsmessig gir lokal redigering av programvare som kjøres i en tolk uten nødvendig krysskompilering og filoverføring en raskere “testing/feilretting”-sløyfe. Trolig er programutvikling med Python det mest attraktive alternativet på dette produktet. Men dersom noen tar seg bryderiet med å krysskompilere populære opensource-programmer for denne prosessoren, vil et arkiv med kjørbar kode være svært velkommen.

I/O-porter

Kontrolleren er som ventet utstyrt med et antall gpio-porter som støtter de vanlige funksjonene: digital i/o (både 3,3v og 1.8v), pulsbreddemodulerte signaler, analog-til-digitale innganger, I2C- og SPI-buss, samt seriekommunikasjon. Dette skulle rekke for et bredt spekter av anvendelser. Bruk av gpio-portene kan skje både fra Python-programmer og skall-programmer (siden portene også er lagt ut i filsystemet), og leverandørens wiki-side har gode programeksempler.

Demonstrasjonsvideo

Denne videoen demonstrerer hvordan vertsmaskinen og kontrolleren kan konfigureres for betjening og progamutvikling.

Oppgradering av programvare

Selve operativsystemet på kontrolleren kan lett oppgraderes, og det finnes to versjoner av Linux som kan brukes: Buildroot og Ubuntu 22.04. Ubuntu er for stor til å få plass i det interne minnet og krever lagring på et microSD-kort (med de ytelseskonsekvenser det gir). Eksemplaret som jeg anskaffet kjørte en eldre versjon av Buildroot som ikke støttet SSH, men den lot seg lett oppgradere:

1. Programmet upgrade_tool lastes ned fra nettet og pakkes ut (adresser i lenken nedenfor)
2. Ønsket versjon av Buildroot lastes ned fra nettet og pakkes ut på vertsmaskinens disk.
3. Buildroot-filene innholder filen update.img Flytt til denne katalogen.
4. Luckfox-kontrolleren koples til vertsmaskinen mens boot-knappen holdes inne.
5. sudo upgrade_tool uf update.img

Disse Wiki-sidene gir nøyaktive opplysninger om nettadresser o.l., så de vises ikke her.

Konklusjon

LuckFox er absolutt et interessant produkt, som plasserer seg mellom Micropython-baserte kontrollere og små Linux-maskiner som Raspberry Pi. Den gjør ingenting som ikke Raspberry Pi kan gjøre, men Pi koster tusenlappen, mens Luckfox koster 220 kroner og bruker dessuten vesentlig mindre strøm. Hovedfordelen, etter vårt syn er tilbudet om “voksen-Python”, men vi ser også et paradoks mellom å kunne titlby store og komplekse Python-anvendelser i en maskinvare som i mindre grad klarer å kjøre dem.

Les gjerne denne blogartikkelen for en lignende vurdering av LuckFox Pico.

 962 total views,  2 views today

Har du en Raspberry Pi liggende er det en enkel jobb å lage en Internet-radio med akkurat den betjeningen du liker best. Her forklarer vi hvor enkel og grei denne oppgaven er.

(c) Anders Fongen, april 2024

Innledning

Min daglige radiolytting starter til frokosten, hvor jeg foretrekker at ett trykk skal starte radioen og gi meg morgensendingen fra NRK. Jeg har en DAB-radio som gjør dette, men jeg ønsker også å lytte på stasjoner som ikke finnes på DAB-nettverket der jeg bor, men som kun finnes som Internett-strømmer.

I noen år hadde jeg en stemmestyrt Google Nest som tok inn radiostasjoner basert på TuneIn-appen, men siden den gang har NRK sluttet å strømme via TuneIn, så da ble det en periode DAB-radio side om side med en Bluetooth-mottaker for å spille TuneIn-stasjoner.

Jeg er ingen “storbruker” av Internet-radio, og er fornøyd med 6-8 stasjoner, inkludert NRK sine. Jeg stiller heller ingen andre krav til betjeningen enn at den skal være enkel og uten krav til øyekontakt. Den skal kunne betjenes i mørke og når jeg ikke har brillene på meg. Altså ingen touch-skjerm, men heller en knapperad.

Eller enda bedre: KUN ÉN KNAPP!

Betjeningsdesign

Internet-radioen trenger egentlig bare én knapp, som slår radioen av og på, og som kan brukes til å stege gjennom listen av forhåndlagrede stasjoner.

• Radio av: Ett trykk slår på radioen og spiller den første stasjonen i listen
• Radio på: Ett trykk skifter avspillingen til neste stasjon i listen, eller går til toppen av listen ved siste stasjon.
• Radio på: Langt trykk slår av radioen

Lydsignalet fra Internet-radioen går til en separat forsterker, der finnes volumkontrollen.

Valg av maskinvare

I denne bloggartikkelen har jeg forklart hvordan en Internett-radio kan bygges på en mikrokontroller (Raspberry Pico) og en separat MP3-dekoder. Dette var et morsomt prosjekt, men denne gangen skal jeg presentere noe enklere som lar seg realisere på én kveld:

Jeg har noen eldre Raspberry Pi versjon 3 liggende. Disse kan startes med Linux, de har programvare for å dekode MP3, og de har en analog lydutgang som kan koples til en forsterker eller et headsett. De har også WLAN-adapter som kan motta datastrømmer via hjemmenettet. I sum er Raspberry Pi noe dyrere enn de to komponentene jeg brukte i nevnte bloggartikkel, men i tillegg til en enklere konstruksjon oppnår vi også å ha hele kretsen inni et standard kabinett for Raspberry Pi.

Den ene knappen som tillater brukerbetjeningen er av den typen som ofte brukes til eksperimentering. Den koples til GPIO-bussen og limes til lokket på kabinettet.

Den analoge lydporten på Raspberry Pi hadde et rykte for dårlig lydkvalitet i tidligere versjoner av maskinvaren, men i Pi versjon 3 er denne kvaliteten tilfredsstillende.

Valg og konstruksjon av programvare

Ved installasjon av den anbefalte Linux-versjonen for Raspberry Pi, kalt Raspbian, blir det også installert et avspillingsprogram som heter VLC. Dersom man kopler skjerm og tastatur til Pi er VLC egentlig alt vi trenger for å strømme radioprogrammer. Brukerdesignet som vi har bestemt, utelukker derimot denne løsningen, vi skal kun ha Rasperry Pi i en boks ved siden av forsterkeren vår.

Vi kommer derfor til å lage et enkelt Python-program som avleser tilstanden på betjeningsknappen (trykket ned eller fri), som har en liste over adresser til de lagrede radiostasjonene, og som starter og stopper VLC-programmet med den ønskede radiostasjonen. Programkoden er vist lenger ned i denne artikkelen.

La oss starte med hvordan betjeningsknappen kan avleses av Pythonprogrammet. Python på Raspberry Pi kommer med ferdiginstallerte moduler for å behandle data (sende og motta) via GPIO-bussen, som er raden med pinner langs kanten av kretskortet.

Vi kopler knappen til pin 3 (også kalt GPIO2) og pin 6, som er jordforbindelse. GPIO2 er koplet til en intern pull-up motstand, som medfører at det står en spenning på porten når knappen er fri (avlest verdi 1) og med jordkontakt når knappen er trykket ned (avlest verdi 0). Koden for å avlese verdien på pin 3 ser slik ut:

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.board)
GPIO.setup(3,GPIO.IN) # Setter pin 3 som inndata-port
verdi = GPIO.input(3) # avleser verdien på pin 3.

Når man avleser knapper på denne måten må man ta hensyn til såkalt prell (switch bouncing), og vi har i denne koden valgt å måle tilstanden over noen millisekunder for at prellet skal roe seg. Derfor er Python-koden mer omstendelig enn om prell ikke fantes.

Utenom denne koden for å avlese langt og kort trykk på betjeningsknappen finner vi også kode for å starte VLC-programmet gjennom en såkalt subprosess, som utføres i parallell med resten av Python-programmet. Dermed kan vi avlese knappetrykk også mens VLC-programmet kjøres.

Trenger ikke grafisk brukergrensesnitt

VLC kjører normalt med et grafisk brukergrensesnitt, men det er bortkastet ressursbruk i vårt tilfelle hvor ingen skjerm er tilkoplet. Vi bruker derfor programmet CVLC, som gjør det vi ønsker med konsollbetjening (kommandolinje) og mindre ressursbruk. Et eksempel på hvordan vi starter og stopper CVLC i en subprosess ser slik ut:

import subprocess,time
url = "http://lyd1.lokalradio.no/oradio_hq"
p = subprocess.Popen(['cvlc',url]) # Starter avspillng
time.sleep(5)                      # Venter i 5 sekunder mens cvlc spiller
p.kill()                           # Stopper så avspillingen

Full programkode

Denne forklaringen av virkemåten burde være dekkende for å forstå den aktuelle programkoden som brukes. Den ser slik ut:

import RPi.GPIO as GPIO
import time,subprocess

button = 3
GPIO.setmode(GPIO.BOARD)
GPIO.setup(button,GPIO.IN)

b = GPIO.input(button)

radio_urls = ["http://lyd.nrk.no/nrk_radio_p1_innlandet_mp3_m?_hdr=0",\
              "http://lyd.nrk.no/nrk_radio_klassisk_mp3_m?_hdr=0",\
              "http://lyd.nrk.no/nrk_radio_jazz_mp3_m?_hdr=0",\
              "https://dispatcher.rndfnk.com/br/br2/live/mp3/mid",\
              "http://lyd1.lokalradio.no/oradio_hq",\
              "http://freshgrass.streamguys1.com/folkalley-128mp3"]
current_channel_number = 0

def start_radio_channel(url):
    return subprocess.Popen(['cvlc',url])

def this_channel():
    return radio_urls[current_channel_number]

def switch_channel():
    global current_channel_number
    global radio_urls
    current_channel_number = (current_channel_number+1) % len(radio_urls)
    return this_channel()

def button_switch():
    global button
    if GPIO.input(button) == 0:
        # Debounce, wait for 100 ms
        time.sleep(0.1)
        if GPIO.input(button) == 0:
            return 1 # True
    return 0

def button_wait():
    # If button already pressed, wait until released
    while button_switch() == 1:
        time.sleep(0.1)

    while button_switch() == 0: #This call returns in 0.1s
        time.sleep(0.1) # Loop consumes 0.2s per iteration
    # Do not return until the button is released, but allow
    # a long press to switch off the radio
    loop_counter = 0
    while button_switch() == 1: # returns i 0.1s
        loop_counter += 1
        if loop_counter == 15: # 3 seconds hold
            return 2
        time.sleep(0.1) # Another 0.1s
    return 1

radio_process = None
while True:
    c = button_wait()
    if c==2 and radio_process != None:
        radio_process.kill()
        radio_process = None
    elif c==1:
        if radio_process == None:
            current_channel_number = 0
            radio_process = start_radio_channel(this_channel())
        else:
            radio_process.kill()
            radio_process = start_radio_channel(switch_channel())

Demonstrasjonsvideo

Her følger en kort demonstrasjonsvideo:

Oppsummering, forslag til flere funksjoner

Det finnes masse eksempler på Internet-radioer som bygges selv, denne som jeg her viser er svært enkelt og er laget for mine behov. For dine egne behov, bruk gjerne deler av denne programkoden og lag dine egne funksjoner. Eksempler på en videreutvikling kan inkludere slike funksjoner:

• Flere knapper, kanskje én for hver forhåndslagrede stasjon
• En roterende bryter (rotary encoder) for å velge stasjon
• Et display (LED eller OLED) som viser stasjonsnavn
• Et web-grensesnitt for å redigere stasjonslisten
• Klokkefunksjoner for automatisk avspilling (vekkerklokke)
• Bluetooth-mottaker for avspilling fra mobiltelefonen (beskrevet her)