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:
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.
Men repeatere kan også sende og motta seg i mellom, ikke bare til betjente radiostasjoner. På engelsk kalles dette Linked Repeaters eller Repeater Networks. Da vil det som mottas av én repeater bli sendt ut av alle repeaterne i nettverket. Et norsk eksempel på et repeater-nettverk er Innlandsnettet, som gir en samlet dekning i store deler av Innlandet fylke samt deler av Viken og Vestfold. Innlandsnettet benytter radiolinker for å knytte repeaterne sammen.
For fyldigere informasjon om repeatere og (litt om) repeater-nettverk:
Bruk av Internet
Repeatere kan selvfølgelig bruke alle slags kommunikasjonstjenester for å knytte seg sammen i nettverk, inkludert Internet. Og repeater-nettverk som benytter Internet for dette formålet er det flere eksempler på. Fordelene med et slikt arrangement er mange:
Nettverket kan være verdensomspennende
Lave kostnader, uavhengig av overført datavolum
Digital overføring av tale gir mindre kvalitetstap
Forbindelser mellom repeatere kan koples opp og ned etter behov for å lage ulike nettverk til ulike tider.
Det finnes flere repeaternettverk som benytter Internet, de kalles Echolink, IRLP, System Fusion, D-star, Brandmeister og Allstarlink. Denne artikkelen vil presentere og demonstrere Allstarlink.
Allstarlink
Allstarlink skiller seg ut fra andre lignende nettverk ved at det er svært enkelt å kople en radio til nettverket for å etablere en repeater: En Raspberry Pi (eller en annen Linux-maskin), et lydkort og en radio. Dette har gjort nettverket populært og der i dag ca. 5000 noder i daglig drift. Mesteparten av dem er i USA , mange i UK, og ellers spredd rundt i verden. Det er p.t. to noder i Norge, den herverende i Lillehammer (LA6UIA) og en i Oslo (LA3RIA). Her vises et kart over fordelingen av noder.
Eksempel på bruk
En håndapparat med forbindelse til en repeater kan bruke tastaturet til å sette opp forbindelser til andre rutere. Når tastene trykkes vil det sendes tonesignaler som oppfattes av repeateren, og kommandoer til repeateren sendes som en sekvens av tonesignaler: Trykkes *342567 vil repeateren forsøke å sette opp en forbindelse til repeateren 42567, og *142567 vil kople ned forbindelsen igjen. *806 kopler ned alle forbindelsene og *712 vil annonsere riktig klokke. *70 vil annonsere hvilke forbindelser som er oppkoplet på repeateren.
Dersom det settes opp en forbindelse til en annen repeater, vil man høre all tale som mottas av denne, i tillegg til all tale som mottas av andre repeatere direkte eller indirekte tilkoplet denne. En alle-til-alle forbindelse altså, som om alle deltagerne var innen hverandres radiorekkevidde.
Allstarlink er altså nettverket hvor man kan samle deltagere fra lokale områder i en stor samtale, eller for å gjøre alminnelig anrop (kalt CQ) til et stort antall lyttere. Og en node kan skifte mellom mange slike nettverk etter ønske. Utsnittet under viser et “snapshot” av et repeater-nettverk på Allstarlink. Noden med blå farge tilhører LA6UIA.
Repeater, Link, Headless
Med “node” menes en maskin som kan kople opp forbindelser til andre maskiner i Allstarlink og overføre tale. Noden kan være satt opp på ulike måter: Alle trenger en datamaskin med Internet-forbindelse, men de kan ha ulik konfigurasjon på “lokal”-siden:
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.
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).
Headless, hvor noden ikke har en radio. Brukere av denne noden kan snakke med Allstarlink via en App, en IP-telefon eller et direkte tilkoplet headset.
Nedenfor vises hvordan de to første variantene kan koples til Allstarlink. Nodene oppe til venstre og nede til høyre er i prinsippe like: Den første viser en “ordentlig” repeater tilkoplet Allstarlink, mens den andre viser en “privat” repeater med enklere senderutstyr med kort rekkevidde.
Konfigurasjon av en Allstarlink-node
Illustrasjonen nedenfor viser i detalj hvordan en linknode kan bygges opp. En linknode er enklere å konstruere fordi den ikke trenger en full dupleks radio.
Konstruksjon av en Allstarlink linknode
Man trenger:
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.
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.
En FM-radio for kontakt med lokale radioapparater. Her kan en enkel radio gjøre nytten, men man skal unngå å sette utgangseffekten til høyeste verdi, fordi en slik radio er ikke dimensjonert for å være i sendemodus i lange perioder av gangen. Man skal også vurdere om en tonesquelch (CTCSS-kontroll) kan brukes for å unngå at tilfeldige radiosignaler åpner squelchen og starter sending til repeater-nettverket.
Min første konfigurasjon benyttet en billig Baofeng UV-5R radio som krevde at COR-kabelen ble loddet til hovedkortet. De andre signalene ble koplet via mikrofon- og headsett-kontakten. Radioen fungerte fint til privat bruk, men den lille bordladeren hadde for liten strømstyrke til å holde radioen i drift over mange timer.
Modifikasjon av kretskortet for å få COR-signal. Ved den røde pilen.
Når alt er koplet sammen kreves det litt justeringer i Raspberry Pi-programmet for å sette riktig polaritet på COR og PTT, samt justere lydnivå på talesignalene.
For å registrere seg i Allstarlink
Du må registrere deg i Allstarlink for å få et nodenummer og et passord. Dette gjør du online, og du må fremvise ditt kallesignal, fordi dette er forbeholdt radioamatører med sendetillatelse. På https://wiki.allstarlink.org/wiki/Beginners_Guide finner du opplysninger om dette og mye annet som du vil ha nytte av å vite.
Allstarlink-miljøet er hjelpsomt, og du får fort hjelp om du spør, f.eks. på Facebook-gruppen Allstar Link Network.
Demonstrasjonsvideo
Denne artikkelen er ikke ment som en komplett instruksjon for å konstruere en Allstarlink-node, men derimot å vekke interesse for å gå worldwide med lette og billige radioapparater. Jeg har laget en demonstrasjonsvideo hvor jeg viser hvordan min node er satt opp, og der viser jeg også hvordan man deltar i nettmøter (kalt “Nets”) gjennom Allstarlink. Videoen finner du rett nedenfor.
Spesifikt for min egen Allstarlink-node har jeg lagt ut noen driftsopplysninger på qrz.com:
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.
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)
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.
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.
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.
