WLAN

November 2002 begynte man å sette opp trådløst nettverk på Samfundet, basert på standard 802.11-utstyr. August 2014 kjøpte vi trådløskontroller, og oktober 2014 hadde vi fjernet alle APer som var for gamle til å stå på den.

Kanalplan og sendestyrke styres av kontrolleren. Nettene 193.35.54.0/23 og 2001:67c:29f4:1::/64 (med flere IPv6-nett, se IPv6 og Kvadratsky) rutes fra merete til altersex.

Det har også tidligere vært satt opp trådløst nett på Samfundet – selv om dette ikke lenger er i drift, kan det ha historisk interesse, så den gamle dokumentasjonen på dette er fortsatt tilgjengelig. Det har dessuten vært mye endringer i WLAN-oppsettet; gammel informasjon ligger historisk i wikinoden.

Normal drift

All trafikk går først innom kontrolleren som CAPWAP-pakker, som behandler dem, dekapsulerer dem og kjører dem ut igjen på VLAN 15.

Det finnes to ESSIDer; Samfundet, som er ukryptert og åpent, men autentiseres med en captive portal, samt et eksperimentelt 802.1x-autentisert (og -kryptert) ESSID, Samfundet.1x.

Captive portal (ESSID Samfundet)

ESSIDen Samfundet er ukryptert og åpen; det er bare å koble seg til. DHCPv4 kommer via cirkus; altersex kjører dhcrelay (for å sende DHCPv4-pakkene videre til cirkus) og radvd (for å sørge for IPv6-konnektivitet). Alle brukere må autentisere seg, ettersom vi ikke ønsker at tilfeldige folk skal komme og få tilgang på vårt interne nett og vår nettlinje. Denne tilgangen går på MAC-adresse – ideelt sett ville man hatt noe som var vanskeligere å forfalske, men det duger som en brukbart sikker mellomløsning. All info og logging lagres i en PostgreSQL-database (`wlan') på cirkus.

Man får tilgang ved å gå til https://wlan.samfundet.no/, en adresse som kun gir mening fra WLANet (wlan.samfundet.no er satt opp i cirkus til å peke på altersex, men dette gir bare mening for å gå inn på statussiden som ligger på https://wlan.samfundet.no/admin.pl. Her må man autentisere seg med brukernavn/passord mot medlemsdatabasen – stemmer dette, legges MAC-adressen til for de neste 24 timene, og man har normal tilgang inn/ut. Lengden på innloggingen er ikke lenger hardkodet og ligger i samme tabellen med default verdi 24 timer. Om man trenger lange/permanent innlogging for noe reelt kan man gå inn i SQL-en og øke duration manuelt for det aktuelle innslaget.

Alle forsøk på trafikk ut (dvs. trafikk som ikke går rett mot altersex) før man er autentisert vil rett og slett bli sperret (vi svarer med rett ICMP-pakker for å vise at nettet er sperret), med ett unntak: All trafikk på port 80 (http) vil bli redirectet til altersex, som sender en 302 Moved mot https://wlan.samfundet.no/ (vha. mod_rewrite) slik at folk blir bedt om å autentisere seg. (Vi kan ikke gjøre dette trikset med IPv6, så IPv6-forespørsler til altersex på port 80 nektes bare på vanlig vis. Da skal klientene bare prøve på nytt på IPv4, og dermed bli videresendt til login-siden. Dette ser ut til å fungere i alle OS vi har prøvd.)

802.1x (også kjent som WPA2 Enterprise)

ESSIDen Samfundet.1x krever kryptering og autentisering for å koble seg til.

Kontrolleren snakker RADIUS med altersex, som kjører FreeRADIUS. Autentisering med TTLS-PAP skjer i to stadier: Først oppretter klienten en TLS-sikret forbindelse med RADIUS-tjeneren, hvor klienten kan kontrollere sertifikatet til tjeneren. Deretter gjøres PAP-autentisering inne i den krypterte forbindelsen (såkalt inner tunnel). På denne måte slipper både klient og tjener å stole på aksesspunkter, kontroller og annen telematikk. PAP er en simpel klartekstprotokoll for sending av passord, men siden kommunikasjonskanalen er sikret, går det helt fint.

FreeRADIUS linker inn perl, så autentiseringen skjer ved hjelp av en perl-modul som sjekker brukernavn og passord mot hhv. MDB2 og Kerberos. perl-modulen er sjekket inn sammen med øvrig kode for wlan.samfundet.no. Samfundet.1x er på samme VLAN som Samfundet, så i tillegg til å sjekke brukernavn og passord setter koden inn iptables-regler på samme måte som om brukeren hadde brukt https://wlan.samfundet.no/, slik at hin slipper å bli videresendt dit.

Klientstøtten for TTLS-PAP er litt variabel, se WPA2Enterprise for klientstøtte for forskjellige 802.1x-metoder. TTLS-PAP er valgt fordi det er den eneste metoden som både gir akseptabel støtte i klienter og hindrer at vi må lagre klartekstpassord (som vi ikke gjør) eller ustede X.509-sertifikater til alle klientene. Windows 7 er det eneste relevante OSet som ikke støtter TTLS-PAP ut av boksen (men det finnes tredjepartsprogramvare med støtte, for eksempel Intels WLAN-drivere).

CA for SSL til EAP

Linux-/iOS-/macOS-/Android-klienter

Siden disse klientene ikke har noen liste over CAer de stoler på for 802.1x, er det ikke noe poeng at RADIUS gir dem sertifikater i RADIUS signert av en annen utsteder; i praksis må vi shippe CA-sertifikat til klienten uansett. Derfor har 802.1x-oppsettet en egen CA i altersex:/root/samfundet-wpa2-ca/. CAen brukes på følgende vis for å lage nye sertifikater:

altersex:~/samfundet-wpa2-ca# mkdir $(date +%Y-%m-%d)
altersex:~/samfundet-wpa2-ca/2014-09-21# openssl genrsa -out freeradius.key.pem 4096
altersex:~/samfundet-wpa2-ca/2014-09-21# openssl req -sha256 -new -key freeradius.key.pem -out freeradius.csr.pem -config ../openssl.cnf 
[Godta standardsvarene]
altersex:~/samfundet-wpa2-ca/2014-09-21# cd ..
altersex:~/samfundet-wpa2-ca/CA# openssl ca -keyfile CA/samfundet-wpa2-ca.key.pem -cert CA/samfundet-wpa2-ca.pem -in 2014-09-21/freeradius.csr.pem -out 2014-09-21/freeradius.cert.pem -config openssl.cnf 

Nøkkelen og sertifikatet refereres til i FreeRADIUS-konfigurasjonen.

Windows-klienter

Siden Windows ikke klarer å begrense et CA-sertifikat til EAP-bruk, vil et privat CA-sertifikat måtte installeres globalt. Dette er dårlig stil, så vi bruker heller Let's Encrypt for Windows-klienter. RADIUS klarer ikke å presentere begge sertifikatene samtidig, så vi misbruker heller feltet Anonymous Identity til å fortelle RADIUS hvilket sertifikat som skal presenteres. Årsaken til at vi ikke bruker Let's Encrypt for andre klienter enn Windows, er at dette vil kreve rekonfigurering av nåværende klienter, samt at vi ikke har kontroll over hva som skjer med Let's Encrypt sin CA.

For å utstede LE-sertifikater bruker vi en dns-01-challenge, se Let's Encrypt. Dette blir gjort av en cronjobb på altersex.

Åpne WLAN-et

Er det vedlikehold på cirkus eller database er nede av en eller annen grunn kan man åpne WLAN-et midlertidig med kommandoen "wlan" på altersex.

Rute om WLAN-et

Hvis du trenger å flytte rutingen av WLAN-et fra altersex, så gjør du følgende:

På merete:

int vlan 15 
 ip address 193.35.54.1 255.255.254.0 
 ip helper-address 193.35.52.30 
 no ip access-group igmp-only in 
! 
no ip route 193.35.54.0 255.255.254.0 193.35.52.31 
service dhcp 
no ipv6 route 2001:67C:29F4:1::/64 2001:67C:29F4::31 
ipv6 route 2001:67C:29F4:1::/64 vlan15

I /etc/dhcp/dhcpd.conf på cirkus må du sette

option domain-name-servers 193.35.54.1;
til
option domain-name-servers 193.35.52.30;

For å rute tilbake til altersex gjør du følgende:

På merete

int vlan 15
 ip address 100.64.42.1 255.255.255.254
 ip access-group igmp-only in
 no ip helper-address 193.35.52.30
 no ipv6 address 2001:67C:29F4:1::1/64
!
ip route 193.35.54.0 255.255.254.0 193.35.52.31 
no service dhcp 
no ipv6 route 2001:67C:29F4:1::/64 vlan15
ipv6 route 2001:67C:29F4:1::/64 2001:67C:29F4::31 

I /etc/dhcp/dhcpd.conf på cirkus må du sette

option domain-name-servers 193.35.52.30;
til
option domain-name-servers 193.35.54.1;

Internt oppsett

Aksesspunktene på Samfundet er koblet i PoE-switchen georg. altersex får inn VLAN15 tagget.

Webgrensesnittet på altersex er noen få små Perl-scripts, som forhåpentligvis skulle være ganske greie å forstå, gitt at de er relativt godt dokumentert og ikke bruker for mange sære hacks.

Hver time, via cron (og hver gang en ny maskin autentiseres, og ved boot) kjøres scriptet /usr/local/sbin/iptables-setup som root. Dette henter ut listen over gyldige MACs fra PostgreSQL, og bygger opp iptables-reglene fra scratch basert på dette. (Forhåpentligvis vil dette gå på såpass kort tid at man ikke vil merke noe til `nedetiden' – ettersom default-policy på forward-kjeden er DROP vil det ikke åpnes sikkerhetshull mens prosessen kjøres.)

Oppsett for hvordan koble et nytt aksesspunkt til kontrolleren finnes i noden CAPWAP.

Hvordan utvikle

  1. Start med en utsjekk av koden fra /home/cassarossa/itk/felles/git/wlan
  2. Legg til din utsjekk i /etc/apache2/sites-enabled/wlan.samfundet.no* på altersex, Alias /dev/bruker /home/cassarossa/itk/bruke/sti/til/wlan/koden/web
  3. Bruk config-sample til å lage en config-fil
  4. Bruk ports-sample til å lage en ports-fil
  5. Bruk whitelist-sample til å lage en whitelist-fil
  6. Lag evt en test db utifra sql filene i VCS
  7. Besøk dev instansen din på http://wlan.samfundet.no/dev/bruker

Configfiler

Configfilen inneholder databasepassord, SNMP-innstillinger samt noen debugflagg. Ports-filen brukes kun til å lagre navn på stedene; denne må være skrivbar av brukeren apache kjører som (derav separat fil fra config). whitelist-filen brukes til å liste MAC-adresser som alltid skal ha tilgang. Filen parses ved at alt etter # fjernes og tomme linjer ignoreres. Vi forventer at den inneholder en MAC-adresse per linje (etter at kommentarer er strippet bort).

Lenker: Start, farger, nettverk, pst, servere, til nye itkere, utdatert dokumentasjon, vlan

Mail: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2018-01-18 20:47 | Revisjon: 268 (historie, blame) | Totalt: 1419 kB | Rediger