Australialainen RADIUS- ja suomalainen Internet-insinööriosaaminen yhteen

Tamperelainen Internet-ratkaisutoimittaja Arch Red Oy laajentaa toimintaansa ostamalla australialaisen ohjelmistoyrityksen Open System Consultants Pty Ltd:n (OSC). OSC:n päätuote Radiator RADIUS on markkinoiden monipuolisin Radius-palvelinohjelmisto, johon perustuu laaja portfolio langattomia verkkoja (WLAN, 3G, 4G) yhdistäviä käyttäjätunnistusratkaisuja. Arch Red on tuottanut näitä ratkaisuja operaattori- ja yritysasiakkailleen yhteistyössä OSC:n kanssa jo useiden vuosien ajan.

Yrityskaupan myötä Arch Redille avautuu OSC:n kymmenien aktiivisten jälleenmyyjien verkosto lähes 50 maahan sekä suorat asiakaskontaktit kymmeniin operaattoreihin ja vielä useampiin suuryrityksiin, yliopistoihin ja organisaatioihin ympäri maailman.

"Yhdistämällä Arch Redin ja OSC:n pystymme tarjoamaan yhteisille asiakkaillemme ratkaisuja Internet- ja käyttäjäntunnistus- ja hallintapalveluiden toteuttamiseen entistä paremmin ja monipuolisemmin", kertoo Arch Red Oy:n toimitusjohtaja, Karri Huhtanen ja jatkaa:

"Emme tule pelkästään jatkamaan Radiatorin kehitystä vaan haemme nopeasti merkittävää lisäkasvua tarjoamalla myös valmiita käyttäjäntunnistusratkaisuja Internetin yli muun muassa tilauspohjaisina pilvipalveluina."

Lisätietoja:

Karri Huhtanen

toimitusjohtaja, Arch Red Oy

+358 44 087 6546

www.archred.fi

Taustaa yrityksistä

Arch Red on Internet-asiantuntijayritys, joka tarjoaa sekä tuotteita että palveluita palveluntarjoajille langattomien verkkojen (WLAN, 3G, 4G) käyttäjäntunnistukseen, -hallintaan ja näiden väliseen verkkovierailuun. Arch Red tarjoaa myös ratkaisuja ja palveluita white-label WLAN- ja yhteisöverkkojen käyttäjien ja vieraiden tunnistukseen.

Open System Consultants on australialainen yritys, jonka päätuotteena on Radiator RADIUS-palvelinohjelmisto, jolla on asiakkaita 180 eri maassa ja jälleenmyyjiä yli 46 maassa maailman ympäri. Radiator RADIUS-palvelinohjelmistoa käytetään operaattori- ja palveluntarjoajaverkoissa käyttäjäntunnistuksen, provisioinnin ja konfiguraationhallintaan. Radius-palvelin on keskeinen komponentti, kun toteutettaan esimerkiksi WLAN-verkkojen käyttäjäntunnistusratkaisuja tai kun niitä yhdistetään 3G/4G-verkkojen käyttäjätunnistukseen.

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

Taustaa

Seuraava lista pohjautuu meidän (Arch Red) kokemuksillemme sekä eduroam Suomeen että Langattomaan Tampereeseen kuuluvien organisaatioiden ongelmien ratkaisussa koottuihin kokemuksiin. Jos listasta tuntuu puuttuvan syitä tai jotkin kaipaavat lisäkommentteja niin blogiartikkelin kommentteihin voi lisätä kysymyksiä tai omia näkemyksiään aiheista. Esitellyt ongelmat eivät ole missään erityisessä yleisyys- tai muussa järjestyksessä vaan niitä on kerätty sitä mukaa kun niitä on tullut mieleen. Alunperin nämä tuli kerättyä sähköpostiin, josta parhaita paloja on jo käsitelty MobileFunet-työryhmässä.

Päätelaitteiden konfigurointivirheet

Yleisellä tasolla päätelaitteiden konfigurointivirheet on ongelma numero 1. Virheet harvemmin johtuvat RADIUS-palvelinten väärinkonfiguroinnista. Juuripalvelinten tilastoinnissa epäonnistuneita autentikaatioita voi näkyä organisaatioiden osalta suurissakin määrissä, mutta niitä tulee jokatapauksessa koska yksikin virheellisesti konfiguroitu client pommittaa kyllä onnistuneesti organisaation kotipalvelinta kasvattaen virheiden tai epäonnistuneiden tunnistautumisten määrää tilastoissa.

Vanhemmat päätelaitteet ja tunnistamismenetelmäoletukset

Tälläisistä parhaana esimerkkinä toimivat Nokian vanhat puhelimet ja niissä 802.1X:n konfiguroinnin vaikeus. Symbian oletuksena tarjosi WPA/WPA2-autentikoiduille verkoille EAP-SIM/EAP-AKA -tunnistamista oletuksena. Tämä jouduttiin aktiivisesti kääntämään pois päältä sekä syöttämään sekä ulkoinen (eli vaikka anon@tut.fi) että sisäinen (karri@tut.fi) username erikseen sekä valikoimaan PEAP/EAP-TTLS asetuksista päälle. Tämä ongelma ei ole enää niin olennainen iOS-, Android- ja Windows Phone -laitteiden yleistyessä ja Symbianin vähitellen hävitessä. Myös kannettavien käyttöjärjestelmissä tämän konfigurointi on muuttunut helpommaksi, joskaan ei välttämättä turvallisemmaksi. Tämä virhe näkyy tyypillisesti 3gpp-realmien yrittämisenä organisaation proxyävällä RADIUS-palvelimena tai viimeistään juurella, jonne nuo realmit maadoitetaan.

Varmenteiden tarkistusongelmat

Kaikki WPA-asiakasohjelmat (WPA supplicant) eivät toimi samalla tavalla. Jotkut WPA-supplicantit on konfiguroitu toisia tiukemmaksi RADIUS-palvelimen varmenteen tarkastuksessa. Jos varmenteen tarkastus ei onnistu (tai tarkemmin jää kesken), eivät useimmat supplicantit luovuta vaan yrittävät aina vain uudelleen. Jotkut supplicantit eivät mahdollista varmenteen tarkistusta (ja joudutaan luottamaan MSCHAPV2 haaste-vasteeseen). Jotkut tarjoavat vain SSH:n tyyliin fingerprintin ja ilmoittavat uudelleen, jos varmenne on muuttunut (tämä ei ole varsinaisesti huono tapa). Jotkut taas vaativat, että supplicantille on määritelty palvelimen varmentavan CA:n varmenneketju, ja että RADIUS-palvelin palauttaa sen varmenteiden yhteydessä. Virheet RADIUS-palvelimen konfiguroinnissa tai käyttäjän tekemässä supplicantin konfiguroinnissa sitten aiheuttavat jälleen kerran epäonnistuneita autentikointiyrityksiä ja yleensä paljon ja nopeallakin vauhdilla.

Salasanan vaihtovaatimukset organisaatioissa

Tietyn kuukausimäärän sisään vaihtuvan salasanan käytäntö aiheuttaa sen, että käyttäjien päätelaitteisiin jää vanhoja salasanoja, jotka eivät kelpaa, mutta joita päätelaite sitten yrittää uudelleen ja uudelleen.

Kirjoitusvirheet konfiguraatiossa

Kirjoitusvirheet konfiguraatiossa esim. tuon aiemmin mainitun  ulomman kuoren ja sisemmän kuoren tunnusten määrittelyssä aiheuttavat päätelaitteita, jotka jatkuvasti yrittävät hakata päätään organisaation tunnistuspalvelimelle tai verkkovierailupalvelun seinään.

Organisaatioiden virheelliset konfiguraatio-ohjeet: Ei realmia ohjeistuksessa

Tätä Suomessa on käsittääkseni vähemmän tavattu, mutta kaikki ne organisaatiot, jotka hyväksyvät organisaationsa sisällä tunnistautumiset, joissa ei konfiguroida realmia sekä ulko- että sisä-EAP:piin, saisivat muuttaa ohjeistustaan ja konfiguraatiotaan niin, että ilman tuota realmia, autentikaatio ei onnistu organisaation sisälläkään. Tämän perustelu on se, että käyttäjä pystyy tekemään organisaation sisällä näennäisesti toimivan, mutta roamauskelvottoman konfiguraation, joka ei sitten tietenkään toimi vierailtaessa jossain muualla.

Organisaatioiden virheelliset konfiguraatio-ohjeet: RADIUS-palvelimen varmenteen tarkistuksesta lintsaaminen

Tätä harrastetaan jonkin verran Suomessakin, sillä vastaan on tullut useampiakin ammattikorkeakoulujen ja yliopistojen ohjeita, joissa ohjeistetaan kääntämään esim. Windowsissa RADIUS-palvelimen varmenteen tai nimen tarkistus pois päältä. Kun RADIUS-palvelimen varmenteen tarkistuksen ohjeistamisesta on tällä tavoin lintsattu, aiheutetaan ongelmia niille käyttäjille, joiden supplicant vaatii sitä, että se konfiguroidaan tarkemmin tuon palvelinvarmenteen varmentamista varten. Tyypillinen tälläiseen johtava virhe konfiguraatio-ohjeissa on se, että ohjeistetaan, että RADIUS-palvelinvarmenteen varmentaminen pitää kytkeä pois päältä. Tälläinen lintsaaminen olisi syytä kitkeä pois ja ohjeistaa sekä CA-varmenteiden asennus, että tuo fingerprintin tarkistus, joka esim. Mac OS X:ssä ja Windows 8:ssa on käytössä.

Päätelaitteiden bugit käyttöliittymässä ja varmenteiden hallinnassa

Mm. Nokian N900- ja Nokian N9- sekä joillain Android-laitteilla, laitteistovalmistaja on tehnyt itse supplicantin hallinnan, siihen varmenteiden konfiguroinnin ja yleisen käyttöjärjestelmän varmenteiden hallinnan. Mainituilla Nokian laitteilla mm. eräs ongelma oli, että RADIUS-palvelimeen varmenteen varmistusta varten ei pystynyt käyttöliittymästä konfiguroimaan olemassa olevia juurivarmenteita kelvolliseksi varmentamaan RADIUS-palvelimen varmennetta. Ongelmaa pystyi jossain määrin kiertämään asentamalla päävarmentajan varmenteen uudelleen tai käyttämällä privaattipäävarmentajaa.

Androidissa puolestaan jotkut laitteistovalmistajat eivät tarjoa mahdollisuutta ollenkaan varmistaa RADIUS-palvelimen varmennetta. Jos varmenteen tarkistus on mahdollista, päävarmentajan varmenteet on asennettava erikseen ja mitä vanhempi Android-versio, sen hankalampi käyttäjälle. Tilanne on hieman parantanut Android 4.0+:ssa, mutta turvallisen konfiguraation tekeminen sielläkin vaatii hyvää ohjeistusta tai automatisointia. Kuten muissakin tilanteissa, virheet näissäkin sitten kostautuvat lisääntyneinä virhemäärinä tilastoissa.

Puolinaisen konfiguraation teko päätelaitteisiin

Tämä ongelma perustuu tilanteeseen, jossa käyttäjä aloittaa konfiguraation teon, mutta tekee konfiguroidessa jonkun virheen ja viallinen/puolitoimiva konfiguraatio jää mobiililaitteeseen. Käyttäjän tietämättä mobiililaite kuitenkin yrittää tuolla viallisella konfiguraatiolla verkkoon aiheuttaen kuormaa ja virheitä tilastoihin. Esim. vaikka tilanne, että ulkoinen realm on kunnossa, mutta sisäinen käyttäjätunnus, salasana tai niihin liittyvät asetukset on pielessä. Jälleen saadaan virheitä tilastoihin ilman, että käyttäjä edes huomaa laitteensa yrittävän hakata itseään sisälle eduroam-verkkoon.

Vaihtelevat eduroam-verkon konfiguraatiot

Tämä tarkoittaa organisaatioissa olevia erilaisia eduroam-verkon konfiguraatioita ja niitä aiheutuvia ongelmia. Esimerkiksi se, että eduroam-verkko tarjoaa sekä WPA2 että WPA1 -kykyisen tunnistaumisen, voi aiheuttaa sen, että osa päätelaitteista konfiguroituukin käyttämään ja olettamaan, että eduroam tarjoaa aina molemmat autentikaatiotavat tai vähintään WPA1:n. Erityisesti Windows voi kunnostautua siinä, että sille ei kelpaa saman nimisestä verkosta sekä WPA- että WPA2-profiilit, vaan käyttäjän on valittava joko tai. Olisikin yleisen toiminnallisuuden kannalta suotavaa, että eduroam lukittaisiin jo WPA2 only -profiiliin kaikkialla Suomessa ja WPA1 sekä siihen liittyvät kryptot poistettaisiin konfiguraatioprofiileista kaikkialla.

Loppukommentit

Ehdottomasti suurin osa eduroamin ongelmista liittyy nykyään siihen, miten organisaatioiden pitäisi ohjeistaa ja hoitaa käyttäjien päätelaitteiden konfigurointi tai sen oikeellisuus. Terena Mobility -työryhmässä tätä on pyritty ratkomaan ja siellä on kokeiltu apuohjelmia mobiilipuhelimiin (tämä voi mielestäni auttaa) sekä erillisiä supplicanteja kannettaviin (tämä taas on mielestäni huonompi idea). Konfiguraatiota avustava ohjelma/webbipalvelu on mielestäni hyvä idea siksi, että sillä tavalla voidaan puskea varmemmin toimiva konfiguraatio päätelaitteisiin. Oma supplicant on puolestaan huono idea sen takia, että erilaisia laitteita on paljon ja tuollaisen asentaminen voi sotkea niiden toimintaa muuten. Omaa supplicantia parempi lähestyminen on, että pysytään niistä standardi WPA2-autentikointitavoissa, joita päätelaitteiden käyttöjärjestelmien omat supplicantit tukevat natiivisti ja keskitytään niiden konfiguraation ohjeistamiseen ja automatisointiin.

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

Idea näihin blogipostauksiin lähti CSC:n meiltä tekemästä kyselystä siitä, että olisiko meillä (Arch Redillä) Suomen eduroamin juuripalvelun ylläpitäjinä tietoja siitä, mitkä ovat 10 yleisintä autentikaatiovirhettä eduroam-verkoissa. Tälläisiä virheitä tulikin sitten mietittyä, mutta niitä analysoidessa kävi selväksi se, että mitkään niistä eivät varsinaisesti liittyneet tai olleet selvitettävissä tai ratkaistavissa juuripalvelun kautta. Päinvastoin suurin osa niistä oli selvitettävissä ainoastaan organisaatioiden omien tunnistuspalveluiden ja käytäntöjen kautta.

Ymmärtääkseen kuitenkin kokonaiskuvan on tärkeä hahmottaa ensin se, mikä on juuripalvelun rooli ja kyvyt eduroam-verkkovierailussa. Yksi eduroamin parhaista ominaisuuksista nimittäin on myös sen heikkous ajatellen yleistä vianselvitystä. Eduroamin autentikaatioliikennettä ei nimittäin pystytä välityspisteissä purkamaan vaan autentikointi tehdään salatun putken suojassa käyttäjät kotiorganisaatioon. Näin ollen myös lähes kaikki ongelmiin ja epäonnistumisiin liittyvä tieto on kerättävissä pelkästään organisaatioiden (IdP) RADIUS-palvelimen lokeista ja tiedoista.

Juuripalvelimelta ei siis pystytä selvittämään sitä, miksi joku autentikointi epäonnistuu ellei sitä pystytä päättelemään ulomman kuoren reititysongelmaksi (väärä realm) tai organisaation RADIUS-palvelimen vastaamattomuudeksi. Sisällä liikkuvaan tietoon ei välityspisteissä päästä käsiksi. Edes kaikki epäonnistumisetkaan eivät juuripalvelussa näy vaan jos esim. varmenneongelman takia TLS-tunnelin muodostus keskeytyy, tätä ei nähdä epäonnistuneena tai onnistuneena autentikaationa juuripalvelimella ollenkaan. Vain selvät IdP:n päätökseen johtaneet verkkovierailut näkyvät lokeissa onnistuneina tai epäonnistuneina autentikaatiopyyntöinä, eikä näistä useinkaan nähdä varsinaista syytä onnistumiseen tai epäonnistumiseen vaan nämä tiedot on organisaation tarkistettava omilta autentikaatiopalvelimiensa lokeista.

Tästä syystä tunnistamisongelmien syyt sekä niihin liittyvä vianselvitys tai yleisempien vikojen tilastointi pitää tehdä organisaatioiden RADIUS-palvelimilta. Juuripalvelimilta tuota tietoa ei pystytä keräämään.

Arch Redissä me olemme kuitenkin avustaneet monia yliopistoja liittymään eduroamiin. Joillekin olemme toimittaneet avaimet käteen integrointeja ja auttaneet tukisopimusten puitteissa selvittämään RADIUS-palvelimeen liittyviä autentikaatiovirheitä. Tälläiset autentikaatiovirheet ovat olleet juuri niitä, joita juuripalvelusta ei pääse näkemään vaan jotka kokemuksen kautta tulevat vastaan useimmin organisaatioiden omissa verkoissa. Seuraavassa osassa käydäänkin läpi yleisimmät eduroam-organisaatioissa autentikaatiovirheitä aiheuttavat tekijät.

eduroam ennen, nyt ja tulevaisuudessa esitys

Pidin viime perjantaina 16.9.2011 esityksen CSC40v -juhlaseminaarista eduroamista ennen, nyt ja tulevaisuudessa. Esityksen kalvot löytyvät jälleen Slidesharesta:

eduroam ennen, nyt ja tulevaisuudessa

View more presentations from Karri Huhtanen

eduroamin historiaa TTY:n Rajapinta-verkkolehdessä

Tampereen teknillisen yliopiston Rajapinta-verkkolehden artikkeli "Vierasverkkoon nopeasti ja helposti" kertaa Funetin WLAN-verkkovierailun ja eduroamin taustaa ja kehitystä Suomessa.

Arch Red Oy on vuodesta 2004 huolehtinut Funetin WLAN-verkkovierailun ja eduroamin Suomen osuuden toteuttavien juuripalvelinten käytännön toteutuksesta ja ylläpidosta CSC:n huolehtiessa verkkovierailufederaatioiden koordinoinnista.

Arch Red Guest Server 3.0 - uusi versio vierailijapalvelimesta

Arch Red Guest Server 3.0 eli vierailijapalvelimen versio 3.0 on julkaistu. Tärkeimät muutokset ja uudet ominaisuudet ovat:

• Uusittu ja parannettu käyttöliittymä
  
• Helpompi ja joustavampi mukautus
  
• Active Directory- ja LDAP-tuki
• Aikavyöhykeet: vierastunnusten ajat ovat aina paikallista aikaa
  
• Laajempi tuki kansainvälisille merkistöille
• Vierastunnusten hallinta web-pohjaisella rajapinnalla
  
• Täydellinen IPv6-tuki

Versiossa 3.0 keskityttiin parantamaan käyttöliittymää, mukautettavuutta oman organisaation tarpeisiin ja tukea etenkin suurille organisaatioille.

Käyttöliittymän ulkoasua kohennettiin, näkymiä yhdenmukaistettiin ja esimerkiksi vierastunnusten ja niiden salasanojen kirjasimet on valittu selkeiksi ja yksikäsitteisiksi tulostusta ja käyttöä varten. Muutokset käyttöliittymään tehtiin testausammattilaisen palautteen perusteella.

Mukautettavuus tarjoaa paremman mahdollisuuden omien tulostuspohjien, ohjeiden tai esimerkiksi SMS-lähetysten käyttöön. Mukautus voi olla yksinkertaisimmillaan tulostuspohjan logon vaihto ja esimerkiksi oman tarrapohjan teko on täysin mahdollista.

Etenkin suurille ja myös pienille organisaatioille versio 3.0 tarjoaa mahdollisuuden käyttää LDAP- ja AD-käyttäjätietokantoja vierastunnusten luojien eli käyttäjien tunnistamiseen ja valtuuttamiseen. Mikäli toimipisteitä on eri aikavyöhykkeillä, tunnukset voidaan aina luoda paikallisen ajan mukaan. Aikavyöhykkeiden lisäksi paikallisia käyttäjiä varten voidaan tulostuspohjat tehdä esimerkiksi kyrillisillä kirjaimilla.

Vierastunnusten luonti web-pohjaisella rajapinnalla on uusi tapa luoda vierastunnuksia. Vierastunnuksia voidaan nyt luoda sekä web-käyttöliittymällä että suoraan toisista sovelluksista. Uusi rajapinta antaa mahdollisuuden liittää vierailijapalvelin ja vieraiden tunnistaminen esimerkiksi intranet-sovellukseen, jolla jo nyt hoidetaan vieraiden vastaanotto. Liitoksella saadaan nopeasti lisättyä vierashallinnan intranet-sovellukseen WLAN-tunnusten luonti. Rajapinta eli Arch Red Guest Server Extension API sopii mihin tahansa automatisoituun tunnusten luontiin.

Vieralijapalvelimen tuki IPv6:lle on tarkistettu, ja esimerkiksi demopalvelinta voi käyttää yhtälailla sekä IPv4:n että IPv6:n kautta.

Uusin version löytyy demopalvelimelta. Kommentit ja muut yhteydenotot ovat aina tervetulleita!

Konferenssiverkot, osa 1: MindTrek 2010 WLAN-verkon tilastoja ja kokemuksia

Nyt MindTrek 2010 -konferenssin loputtua voi vihdoin todeta, että tällä kertaa konferenssin verkko oli sellainen, jonka konferenssin verkon meidän mielestämme pitää olla. Iso merkitys oli sillä, että verkon suhteen oltiin hyvissä ajoin liikkeellä, lainattiin hyvät yritystason WLAN-laitteet Ciscolta sekä sovittiin Tampereen Puhelimen kanssa riittävän kaistan toimittamisesta. Arch Redin rooli verkonrakentamisessa oli huolehtia laitteiden saamisesta lainaan Ciscolta, verkonsuunnittelusta sekä laitteiden konfiguroinnista ja asentamisesta. Hyviä vihjeitä laitteiden konfiguraatioon saimme Ciscolta Tomi Järventieltä ja lisäksi koko konferenssin verkon rakentamisessa oli sellainen hieno säätäjädraivi mm. Ilkka Lehtisen ja Heikki Ilvespakan "johto"töiden muodossa.

Kun kerran palautekin konferenssin verkosta oli poikkeuksetta positiivista, päätimme kerätä kasaan tilastot ja kokemukset verkon käytöstä, konfiguraatioasetuksista ja parhaista käytännöistä eli käytännössä siitä, miten konferenssi- ja muita korkean käyttöasteen verkkoja meidän mielestämme kannattaa tehdä. Yhdessä blogipostauksessa ei kaikkia asioita kannata käydä läpi, joten julkaisemme konferenssiverkkojen rakentamisesta juttusarjan täällä Arch Redin blogissa aloittaen MindTrek 2010 WLAN-verkon käyttötilastoista.

MindTrek 2010 -konferenssia varten saimme tänä vuonna ensimmäistä kertaa kuituyhteyden ja ethernettiä edellisten vuosien SHDSL-yhteyksien sijaan. Mittausten mukaan yhteys oli n. 100Mbps Internetistä MindTrek-verkkoon päin ja 10Mbps MindTrek-verkosta Internettiin. Konferenssin aikana ei kuitenkaan päästy edes testaamaan yhteyden rajoja liikennöinnin pysyessä lähinnä 10Mbps tasolla. Tosin 10Mbps nimellisnopeudella varustetulla linkillä verkko olisikin ollut jo oikeasti jumissa, kuten MRTG:llä piirretystä kuvaajasta alhaalla näkee.

Liikennettä mitattiin 5 minuutin välein, joka tarkoittaa, että esim. graafissa oleva huippuarvo tarkoittaa, että ko. hetkenä liikennettä on siirretty 5 minuutin keskiarvonakin jo 10Mbps:n yhteyden teoreettisen maksimin verran jatkuvasti. Liikennekäyrän leikkautumiseen (suora viiva) muutamassa kohdassa ei ole varmistettua selitystä. Eräs selitys voisi olla koneen kellon edistäminen/jäljestäminen ja sen siirtäminen takaisin aikaansa. Muita selityksiä taas esim. se, että jotkut palvelut tai palveluntarjoajat, kuten YouTube saattavat rajoittaa tiettyyn IP-osoitteeseen tilatun liikenteen määrää ja koska kaikki MindTrek-verkon koneet olivat yhden IP:n takana, annettiin liikennettä YouTuvesta putkeen vain tietyn rajoituksen mukaan.

Käyttäjien määrää verkossa tilastoitiin varsinaisen konferenssin alusta loppuun. Alla olevasta kuvasta voidaan nähdä, että vaikka suurin osa käyttäjistä käytti avointa ja salaamatonta WLAN-verkkoa, myös salattuihin ja käyttäjätunnistettuihin verkkoihin riitti sekä Langattoman Tampereen että eduroamin verkkovierailijoita. Käyttäjämäärän huippu mittauskaudella oli 165 yhtäaikaista käyttäjää.

Keskellä oleva laakso tarkoittaa yöaikaa, jolloin silloinkin verkkoon oli liittyneinä muutamia päätelaitteita. Kuopat päivien keskellä taas sijoittuvat konferenssin lounasaikoihin.

Ciscon suosituksesta kokeilimme myös konfiguroida tukiasemat tarjoamaan kahta WLAN-taajuusaluetta (2.4GHz ja 5GHz) tukeville päätelaitteille ensisijaisesti 5GHz aluetta. Yllätykseksemme näitä olikin päätelaitteista selvä enemmistö 2.4GHz:n päätelaitteiden jäädessä huomattavasti pienempään osaan, kuten kuvasta voi nähdä.

Kuvassa dot11a ja dot11n5 tarkoittavat WLANin 5GHz:in alueella toimivia IEEE 802.11a ja IEEE 802.11n päätelaitteita. 2.4GHz:n alueelta löytyi sitten 802.11g ja myös 802.11n standardi mukaisia päätelaitteita tunnisteilla dot11g ja dot11n24. Pelkkä IEEE 802.11g standardi näytti olevan selkeässä vähemmistössä käyttäjien päätelaitteissa. Useampaa taajuusaluetta käyttävät päätelaitteet kun valitsivat tukiasemien ohjeistamina mieluummin jonkun 5GHz:n taajuusalueen standardeista.

WLAN-verkoissa käytettävä taajuusalue vaikuttaa huomattavasti verkon toimivuuteen. 5GHz:n verkoissa on pienempi kantama, mutta enemmän toisiaan häiritsemättömiä kanavia (8 kpl) tukiasemille. Yleisemmällä 2.4GHz alueella puolestaan sitten on vain 3 täysin toisiaan häiritsemätöntä kanavaa (1, 5/6 ja 11) ja kyseinen taajuusalue onkin usein hyvin ruuhkainen jo pelkästään eri WLAN-verkkojen ansiosta. Usein myös konferensseissa on myös langattomia mikkejä yms. häiriölähteitä samoilla taajuusalueilla, joten 5GHz:n suosiminen ja tiheä tukiasemaverkko näyttää oikealta ratkaisulta varmistaa, että radioverkkokapasiteettia riittää kaikille käyttäjille.

Tämän pohjalta voimmekin antaa suosituksen, että päätelaitteissa ja tukiasemissa kannattaa suosia laitteita, jotka tukevat molempia radiotaajuusalueita ja tukiasemissa vieläpä yhtäaikaista taajuusalueiden käyttöä. Uusi 802.11n standardi tuo myös enemmän nopeutta ja kantavuutta verkkoon, mutta sitäkin ostaessa kannattaa huomata, että standardilla markkinoidaan myös laitteita, jotka osaavat toimia vain 2.4GHz:n alueella molempien alueiden (dual band, simultaneous dual band 802.11n) sijaan.

PÄIVITYS 2010-10-26: Ciscon Tomi Järventieltä tuli muutama lisäkommentti liittyen noihin jo esitettyihin suosituksiin. Kommentit ovat tässä alla:

Suositusten osalta haluaisin tuoda vielä esiin pari huomionarvoista asiaa:

1. Tukeeko WLAN-ratkaisu 802.11n-speksiä molemmilla taajuusalueilla, vai ainoastaan 5 GHz alueella. On useampia valmistajia, jotka myyvät 802.11n-ratkaisuja, mutta tukevat sitä vain 5 GHz alueella. 2,4 GHz alueella tuetaan vain b/g-speksejä, jolloin n-tukareihin investointi ei tuo kaikkea tarjolla olevaa hyötyä.

2. Kuinka suurta kanavajoukkoa ratkaisu tukee 5 GHz alueella. Osassa 5 GHz taajuusaluetta on _pakollista_ toteuttaa ns. DFS-ominaisuus (tutkanväistely), ja jotkut valmistajat oikovat jopa yritystason ratkaisuissa sen osalta aika tavalla. Oikominen johtaa siihen, että likimainkaan kaikkia olemassa olevia kanavia ei voida käyttää, ja pahimmillaan yli puolet mahdollisesta kapasiteetista joudutaan "heittämään hukkaan".

eduroam-esittely suomeksi

Arch Red Guest Server v3.0 tulossa

Arch Redin vierailijanhallintaohjelmisto Arch Red Guest Server lähestyy v3.0 julkaisemista. Kokeile mitä uutta on tulossa demopalvelimellemme asennetulla esiversiolla (v2.9.13). Lisää tietoja ja demoon kirjautumiseen tarvittavat tunnukset löytyvät osoitteesta:

http://www.archred.fi/tuotteet/arch-red-guest-server/demo

Mobile Cloud Apps @ Demola 22.4.2010 klo 8.30-10.30

Arch Redin toimitusjohtaja Karri Huhtanen osallistuu torstaina 22.4.2010 Hermian järjestämään Cafe Combinat -tapahtumaan paneelikeskustelijana aiheesta Mobile Cloud Apps. Lisää Mobile Cloud Apps tapahtumasta löytyy myös Facebookista.

Karri Huhtanen TREX Workshop 2010:ssä

Karri Huhtanen esittelee tänään 19.2.2010 TREX Workshop 2010:ssä ICT SHOK Future Internet testialustaa sekä WLAN-verkkovierailua (roaming) Langattoman Tampereen ja Funetin kanssa.

Vierailijapalvelin 2.8.0 julkaistu

Arch Red Guest Server eli vierailijapalvelin on saavuttanut version 2.8.0. Versionumeron kasvaminen 2.6:sta antaa vinkkiä huomattavista muutoksista. Tärkeimpänä muutoksena on aikaleimojen tallettaminen UTC-aikana. UTC- eli Coordinated Universal Time helpottaa vierailijapalvelimen käyttöä organisaatioissa, jotka toimivat useilla aikavyöhykkeillä. Aikavyöhyke voidaan valita käyttäjäkohtaisesti, vaikka käyttäjä olisi Suomessa ja vierailijapalvelin organisaation pääkonttorissa Australian Adelaidessa *.

Tuki aikavyöhykkeille parantaa entisestään vierailijapalvelimen kansainvälistämistä ja kotoistamista (internationalization ja localization). Vierailijapalvelimen tarjoaminen palveluna on entistäkin helpompaa organisaation sisällä sekä kaupallisena palveluna.

Muut muutokset liittyvät eri kieliversioiden tukeen ja asennuksen yksinkertaistamiseen. Mukana on myös aikaisemmin mainittu tuki tunnusten keston määrittelylle.

* Suomen aikavyöhyke on UTC+2 ja Adelaiden UTC+9.30 normaaliaikana. Molemmat käyttävät myös kesäaikaa, ja eteläisellä pallonpuoliskolla kesäaika alkaa Suomesta katsoen syksyllä. Aikaeron miettiminen jää lukijalle harjoitukseksi ...

Avoimen asiakaslaitteen turvaaminen

Yritykset ja palveluntarjoajat hyödyntävät yhä enemmän avoimia alustoja (mm. open sourcea) asiakaslaite- ja palvelutarjonnassaan.

Täysin avoimessa alustassa asiakas pääsee käsiksi koko laitteeseen ja sen sisältämiin tietoihin. Kontrolloidussa, täysin tai osin suljetussa alustassa tätä pääsyä ja vaikuttamismahdollisuuksia rajoitetaan, mikä voi jopa kannustaa murtamaan järjestelmän suojauksia rajoituksien poistoa varten.

Kokonaisuutena asiakaslaitteen turvallisuus ei kuitenkaan koostu vain sisäisestä ja ulkoisesta turvallisuudesta sekä laitteen sisältämistä tiedoista vaan myös laitteen toiminnan turvaamisesta kaikissa tilanteissa.

Tampereen tietoturvapiirille 5.10.2009 pidetyssä esityksessä käsitellään näitä avoimen asiakaslaitteen (CPE = Customer Premises Equipment) turvaamisen haasteita ja ratkaisuja palveluntarjoajan ja laitevalmistajan näkökulmasta.

Esityksen kalvot löytyvät julkaisujemme joukosta täältä:

• Avoimen asiakaslaitteen turvaaminen
  

Julkaisut verkkoon

Uutena osiona Arch Redin webbisivuilla on nyt julkaisut. Ensimmäisenä sivuille tulivat IPv6-protokollaa ja NAT-tekniikkaa esittelevät opetusmateriaalit. Molempia on pyritty tekemään myös itseopiskeluun sopiviksi.

Hakusanalla IPv6 löytyi aikaisemminkin suomeksi tietoa, mutta tänään julkaistu paketti on tietääkseni laajin ja kattavin suomeksi tehty katsaus IPv6-protokollaan ja siihen liittyviin tekniikoihin. Pelkkään perusasiaan ei jäädä, vaan mukana on esimerkiksi siirtymävaiheen tekniikoita esimerkkien kera.

Myös NAT eli Network Address Translation eli osoitteenmuunnos on käsitelty kattavasti. Kaikki NAT-toteutukset eivät ole samanlaisia, ja tähän liittyen esimerkiksi NAT-toteutuksen toimintaa selvittävä STUN-protokolla on kuvattu yksityiskohtaisesti.

Julkaisuihin tulee tulevaisuudessa lisää sisältöä sekä suomeksi että englanniksi. Aiheet ja käsittelytapa vaihtelevat konferenssipapereista opetusmateriaaliin.

Toivottavasti tänään lisätyt asiat käyvät hyvästä aloituksesta :)

Tuotteita ja esimerkkejä - mitä Arch Red tekee

Yhteenveto tuotteista syntyi pitämiemme esitysten ja koulutusten perusteella. Molemmissa seuraa hetki jolloin asiat pyritään kokoamaan, joten miksi yhteenveto ei olisi osana tuotteiden esittelyäkin? Sivuillamme oli jo esitelty tuotteet yksitellen, ja yhteenveto kertoo nyt sen kuinka ne liittyvät toisiinsa, miten niistä rakennetaan kokonaisuuksia ja kuinka ne toimivat muiden valmistajien tuotteiden kanssa.

Tuotteiden lisäksi yhteenveto näyttää myös sen, että osaamme suunnitella kokonaisuuksia. Verkkojen ja käyttäjätunnistuksen arkkitehtuuriosaaminen on perusta sille, että tuotteemme ovat järkeviä ja sopivat tehtäväänsä. Tarpeesta riippuen rakennamme muiden järjestelmillä tai käytämme omia silloin kun ne ovat paras valinta. Kuten esimerkeistäkin näkyy, emme pyri tekemään itse kaikkea vaan otamme aina sen mikä on sopivin.

Reissussa Netti-Nyssen Internet-roudarina ja Langattoman Tampereen lämppärinä

Arch Red on pieni asiantuntijayritys, jolla on tietenkin omat tuotteensa, omat palvelunsa sekä niiden ympärillä pyörivä tutkimus- ja tuotekehitys, mutta ne eivät ole ainoita asioita, joita yrityksessä teemme. Meillä on myös omat harrastusprojektimme, joita tulee tehtyä joskus osittain firman ajalla ja joskus omalla vapaa-ajallakin. Ideana on, että ihan kaikkea ei tehdä pelkästään rahan vuoksi, vaan joskus on vain mukava tehdä asioita, jotka ovat hienoja, haastavia ja yksinkertaisesti hauskoja.

Netti-Nysse on meille yksi tälläinen projekti. Olemme tehneet yhteistyötä Netti-Nyssen tiimin kanssa jo pitkään ja kun minua kysyttiin mukaan huolehtimaan Nyssen keskuspalvelimesta ja Internetin järjestymisestä Netti-Nyssen Euroopan kiertueeella, ei tarvinnut niin hirveän paljon vastustella ennen kuin suostuin mukaan.

Täällä sitä sitten ollaan, jossain Venetsian lähellä, matkalla Milanosta Ljubljanaan ja kirjoitellaan bussin taka-auditoriossa etukäteen valmiiksi tätäkin blogipostausta.

Tehtävänä on sekä huolehtia bussin palvelimesta että Internet-yhteyksistä myös Langattoman Tampereen edustajana esitellä tamperelaisen avoimen ja yhteistoiminnallisen yhteisöverkon ideaa sekä yrittää löytää uusia ideoita, kontakteja ja yhteistyömahdollisuuksia kaupungeista matkan varrelta. Ehkäpä osassa noita kaupunkeja on jo omia yhteisöverkkoprojekteja suunnitelmissa, menossa tai jo valmiina ja voisimme parhaassa tapauksessa saada sovittua vaikka yhteisöverkkojen tunnusten toimimisesta ristiin täällä maailmallakin.

Karri Huhtanen (Arch Red Oy)
Internet-roudari

Vierailijapalvelin 2.6.1 julkaistu

Uudessa versiossa on yksi uusi ominaisuus sekä joukko pieniä parannuksia. Uutena ominaisuutena on vierailijatunnuksen keston määrittely.

Mitä keston määrittely tarkoittaa? Tunnus voidaan tehdä esimerkiksi siten, että se on voimassa joulukuun 31. päivään saakka, ja sen kestoksi määritellään 24 tuntia. Tunnus sulkeutuu päivän kuluttua siitä kun sitä ensimmäisen kerran käytetään. Ensimmäinen käyttö voi tapahtua milloin vain ennen joulukuun loppua.

Kesto voitiin määritellä jo aikaisemminkin nimettömille tunnuksille, mutta nyt se voidaan asettaa myös henkilökohtaisille tunnuksille.

Uusinta versiota voi testata webin kautta ja RADIUS-protokollalla suoraan verkossa.

VMware Server - hallinta ssh:n kautta

VMware Server 1.0.x ja 2.0.x ovat hallittavissa ssh-yhteyden kautta ssh:n port-forwarding -menetelmän avulla. Menetelmän etuna on se, että VMware-palvelimen palomuurisäännöissä tarvitsee sallia hallintaa varten ainoastaan ssh-liikenne. Tästä on hyötyä etenkin version 2.0.x kanssa, joka käyttää kahta TCP-porttia.


VMware Server 1.0.x
ssh -4 -v -L 1902:127.0.0.1:902 vmwareserver1.example.com
[-v option tulostamia viestejä poistettu]
debug1: Local connections to LOCALHOST:1902 forwarded to remote address 127.0.0.1:902
debug1: Local forwarding listening on 127.0.0.1 port 1902.

ssh:n -v option viesteistä näkyy, että yhteydet paikalliseen loopback-osoitteeseen 127.0.0.1 ja TCP-porttiin 902 kuljetetaan ssh-yhteyden yli kohdekoneen porttiin 902. ssh:n option -4 rajaa IPv6:n pois käytöstä.

Paikalliseksi portiksi otettiin 1902, koska portti 902:n kuuntelu ei ole sallittua kuin pääkäyttäjälle eli rootille.

VMware Server Consolen avulla yhteys mudostetaan valitsemalla "Remote host", ja "Host name"-kenttään annetaan arvoksi 127.0.0.1:902




VMware Server 2.0.x
ssh -L 1902:localhost:1902 -L 8333:localhost:8333 vmwareserver2.example.com

Erona versioon 1.0.x on:

• Portteja on nyt kaksi: myös portti 8333 kuljetetaan ssh:n kautta
• Paikallinen portti 1902 viedään palvelimelle porttiin 1902. Edellisessä palvelimen portti oli 902

Portti 1902 ei ole palvelimen oletusportti, vaan se on määritelty palvelimella ajetun vmware-config.pl-komennon kautta. Kysessä on VMwaren authd-prosessin portti.

VMwaren hallintayhteys koostuu kahdesta osasta:

1. Yhteys porttiin 8333 www-selaimella https:ää käyttäen
2. Yhteys kohdan yksi kautta opittuun porttiin, joka on nyt 1902

Koska palvelimen portti on vaihdettu arvoon 1902, ssh-komentoa ei tarvitse antaa root-käyttäjänä.

Mikäli VMware Server 2.0.x on jo konfiguroitu, portin 1902 tilalla voidaan käyttää porttia 902. Tässä tapauksessa ssh-komento ajetaan root-käyttäjänä esimerkiksi sudon avulla.

Kun sopiva ssh-komento on saatu annettua, VMware-hallintayhteys otetaan selaimella osoiteeseen https://127.0.0.1:8333/

Kiemuraista, eikös?

IPv6 ja Arch Red

Arch Red on nyt IPv6-käyttäjien saavutettavissa. WWW-sivut, sähköpostin vastaanotto, nimipalvelu ovat palveluista laajimmin käytettyjä, mutta myös rajoitetummat ja pelkästään omaan käyttöön tarkoitetut palvelut, kuten reititys, RADIUS, keskitetty autentikointi sekä sähköpostin luku toimivat IPv6:lla. Viimeisimpänä IPv6 tuli käyttöön WWW-palvelussa.

Onko nyt hyvä hetki ottaa IPv6 käyttöön? Tekniikka on jo pitkälti toimivaa, mutta esimerkiksi VPN-yhteyksien kanssa IPv6-tukea ei aina ole. Aikaa on vielä näidenkin ongelmien korjaukseen, mutta ennusteiden mukaan IPv4-osoitteiden jakaminen nykyisellä käytännöllä voi jatkua vain hyvin rajoitetun ajan. Arch Redin ihmisillä on IPv6:sta jo vuosien kokemus, ja meillä IPv6 kuuluu yhdeksi osaamisalueeksi. Tästä johtuen käyttöönotto julkisissakin palveluissa tapahtui nyt.

Omien kokemusten perusteella IPv6:n käyttöönotossa on tärkeintä tehdä ne palvelut ensin valmiiksi, joita haluaa muiden käyttävän. Vasta sitten ne julkistetaan esimerkiksi lisäämällä niille nimipalveluun IPv6-osoite. Tämä on lähes itsestäänselvyys, mutta usein käy niin, että IPv6 jää esimerkiksi valvomatta ja pääsee rapautumaan.

IPv6:n käyttöön liittyy monia muitakin asioita, mutta nyt ei enää pidä tuoda huonosti toimivaa IPv6-palvelua käyttöön. IPv6:lla on jo käyttäjiä, ja heidän määränsä ei tule vähenemään tulevaisuudessa.

Vierailijapalvelin 2.6 ja uusi demo julkaistu

Vierailijapalvelin, eli Arch Red Guest Server saavutti eilen version 2.6. Julkaisun yhteyteen tehtiin kattava verkosta käytettävä kokeiluversio. Pelkän www-käyttöliittymän esittelyn lisäksi demossa on mahdollista kokeilla myös oman RADIUS-palvelimen tai -asiakkaan yhdistämistä vierailijapalvelimeen.

Vierailijapalvelimen vahvuus on monipuolinen RADIUS-rajapinta, joka on käytettävissä demon RADIUS-osan kautta - tosin perusautentikointi ja WPA:n ja WPA2:n EAP ovat vasta pieni näkymä siihen mitä kaikkea Radiatorilla voi tehdä. Tällä hetkellä Radiator esimerkiksi ainoastaan palauttaa vierailijatunnukseen liitetyt tagit eli järjestelmämerkinnät, mutta mitkä tahansa temput ovat mahdollisia niiden perusteella.

Karrille kiitos RADIUS-demon ideasta!