Jatketaan ”Kotiverkko kuntoon” -sarjaa.
Tässä osassa otetaan Pfsense palomuuri ”tuotantokäyttöön”, eli tehdään siitä kodin varsinainen reititin/palomuuri.
Jotta homma pysyy jotenkin hanskassa, niin tehdään taas parissa osassa. Ensin kotiverkon siirto Pfsenen taakse ja käyttöön yksi WAN-linkki. Jos ja kun homma näyttää toimivan, niin otetaan käyttöön toinenkin WAN-linkki ja jatketaan Dual WAN-ominaisuuden testaamista.
Kotiverkko Pfsense palomuurin taakse
Kuten aiemmissakin testeissä, niin piirtelin taas suunnitelman, jotta ei tarvitse tekemisen tohelluksessa miettiä liikaa ja toisaalta ei pääse unohtumaan jotain tärkeää. Osoittautui ihan hyväksi ideaksi tälläkin kertaa, kun kaikki ei mennyt ihan putkeen.
Kuva: Suunnitelma
Pfsense henkiin
Koska käytössä oli päällekkäisiä ip-osoitteita, niin päädyin ajamaan Pfsensen alas, jotta verkko ei sekoaisi sieltä löytyvästä kahdesta reitittimestä samalla ip-osoitteella.
Jotta olisi helppo keino palata aiempaan Asus-reitittimiin perustuvaan reitittimeen/palomuuriin, päädyin laittamaan molemmat Asus ET12-laitteet kylmäksi ja sivuun. Niiden tilalle tuli käyttöön vanhemmat Asus AC5300 ja AC86U-laitteet, joiden rooliksi jäi pelkästää wifi-tukiasemana toimiminen, kun reititin/palomuuri-toiminnallisuus olisi Pfsense-laitteessa.
Kun palomuuri/reititin ja wifi-tukiasemat oli saatu alas, oli aika muuttaa kytkimen asetuksista Pfsensen LAN-portin VLAN testi VLANista 101 varsinaiseen kodin default VLANiin 1. Näin uusi reititin/palomuuri saisi yhteyden kodin ”langallisiin” laitteisiin. Kun wifi-tukiasemat ja reitittimen DHCP-palvelin olivat alhaalla, piti manuaalisesti muuttaa yhden piuhalla verkkoon kytketyn tietokoneen ip-osoite, jotta pääsi kiinni kytkimeen tekemään muutoksia.
Seuraavaksi Pfsense tulille ja ihmettelemään miksi mikään ei oikein tunnu toimivan. Laitteen portit näyttivät nousevan status-valojen perusteella ylös. Samoin kytkimen päästä näki, että porteista meni läpi liikennettä. Mutta Pfsensen käyttöliittymään ei päässyt kiinni ja mikään ei laite ei saanut uutta ip-osoitetta DHCP-palvelimelta
Kytkimen asetuksia ihmettelemään. Tohinassa oli päässyt unohtumaan painaa ”Apply”-nappia PVID kohdassa ja porttiin tuleva ei-tagatty liikenne ohjattiin vielä vanhaan testi VLANiin 101 ja näin ollen yhteys Pfsensen ja muun verkon välillä oli poikki. Homma korjaantui vaihtamalla PVID oikeaksi ja painamalla ”Apply”-nappia.
Sivuhuomatuksena: Pfsene ymmärtää myös VLANien päälle ja olisin voinut viedä VLAN tagattyinä myös perille asti, mutta yksinkertaisemman setupin vuoksi olen päätynyt terminoimaan VLANit kytkimessä ja vien kodin LANin ei-tagattynä Pfsenseen.
Jos tulevaisuudessa on tarve useammalle toisistaan eriytetylle verkolle, niin voi VLAnit ottaa käyttöön myös Pfsensen päässä. Ehkäpä erillinen guest wifi-verkko ? Tai oma verkko kodin erinäköisille IOT-laitteille, jotka näyttävät keskustelevan internetissä välillä vähän kummallisiin kohteisiin tai tekevät jotain muuta hassua kuten iSmartgate laitteet, jotka lähettävät säännöllisesti verkkoon ”turhia” broadcast paketteja.
Näiden päätösten tekemiseen saa helposti dataa Pfsensen edistyineistä analytiikka ominaisuuksista. Jo pelkästään logi-dataa lukemalla saa paljon paremman kuvan liikenteestä kuin Asuksen vehkeillä, mutta ottamalla käyttöön”ntopng”-paketin saa todella yksityiskohtaisen käsityksen oman verkon liikenteestä. Jopa kartalle näkyviin mihin kaikkialle kotoa otetaan yhteyksiä ottamalla käyttöön Geolite2 DB tietokannan.
Toisaalta liika informaatio voi olla myös vähän pelottavaa.
Miksiköhän joku meiltä liikennöi parhaillaan useampaan kohteeseen Wichitan alueelle jenkkilässä? Rouva ollut vaihtarina Kansasissa, onko sillä joku vanha heila siellä?
Kuva: Pfsense / NtopNG kartta Wichita, U.S
Tai Wiliiandra Lakes Region World Heritage Arealle Australiassa?
Kuva: Pfsense / NtopNG kartta Wiiliandra, Australia
Asus AiMesh wifi-tukiasemat käyttöön
Olin valmistellut wifi-verkon pystyttämistä aiemmin viikolla liittämällä testiverkkoon alkuperäisen AC5300-tukiaseman rinnalle myös toisen AC86U-tukiaseman. Nämä tukiasemat muodostavat Asus Aimesh-tyyppisen verkon, jossa AC5300 on ”primääri”-laite, jonka kautta hallinnoidaan wifi-verkon asetuksia, myös AC86 laitteen osalta, joka jatkossa toimii wifi-tukiasemana yläkerrassa.
Asuksen dokumentaatio on hieman epäselvä koskien ethernet-kaapelointia tällaisessa käyttöskenaariossa, jossa Asuksen vehkeitä käytetään pelkästään wifi-tukiasemina ja reititin/palomuuri on jossain muussa laitteessa. Voittavaksi yhdistelmäksi osoittautui:
- Primääri-laite (AC5300) kytketään verkkoon LAN-portin kautta
- Muut Aimesh-laitteet (AC86U) kytketään verkkoon WAN-portin kautta
Kun wifi-tukiasemat olivat saatu toimimaan Pfsensen kanssa, piti vielä muuttaa muutama wifiin liittyvä asetus:
- Aiemmin testikäytössä olevan 5Ghz taajuudella toimineen testi wifin SSID:n vaihto vanhaksi ”tuotanto” 5GHz SSID:ksi
- Aiemmin testiverkossa pois päältä olleet 2.4Ghz radiot päälle.
Tässä kohtaa tuli toinen unohdus. Muistin kääntää vain yläkerrassa olevan AC86U laitteen 2.4Ghz radion päälle. Aiheutti taas hieman ihmettelyä.
Positiivisena huomiona tuli, että nykyään aiemmin ongelmalliset ajoporttia ja autotallin ovia kontrolloivat iSmartgate-laitteet saivat myös yhteyden yläkerrassa olevaan wifi-tukiasemaan. Ennen iSmartgate-laitteiden sijoittamista erillisiin koteloihin ei tämä yhteys ollut toiminut ja olivat pudonneet pois pelistä, jos alakerran wifi-tukiaseman kanssa oli jotain haasteita.
No lopulta hiffasin mistä oli kyse ja laitoin myös alakerran (AC5300) tukiaseman 2.4Ghz radion päälle. Wifi ”roaming” näyttää toimivan ihan ok, suurin osa 2.4Ghz verkkoa käyttävistä laitteista vaihtoi itsekseen tukiasemaan, josta sai vahvimman signaalin.
Nykyään Asuksen ”Aimesh”-valikon kautta voi myös pakottaa wifi clientin kytkeytymään tiettyyn tukiasemaan käyttämällä ”binding”-ominaisuutta. Tämä on hyvä ominaisuus, jos verkosta löytyy itsepäisempiä wifi clientteja, jotka pitävät kiinni huonommasta wifi-yhteydestä vaikka maailman tappiin asti. Meillä ainut tällainen laite oli yläkerran Neato D6 robotti imuri, joka otti kiinni yläkerran wifi-tukiasemaan vasta ”binding”-ominaisuuden avulla.
Pfsense Dual WAN ominaisuuden käyttöönotto
Aiemmin viikolla olleen lumimyrskyn seurauksena meiltä meni pahimmillaan sähköt poikki neljä kertaa päivässä. Yleensä tietotekniset laitteet eivät kauheasti tykkää, jos sähköt menevät yllättäen poikki.
Pahimmaksi ”uhriutujaksi” meillä osoittautui Qnapin NAS purkki, joka alkoi jokaisen sähkökatkon jälkeen rakentamaan 2x16TB levyjen RAID-pakkaa uusiksi. Yleensä tämä operaatio otti vähintään 24 tuntia. Onneksi mitään ei mennyt rikki vaikka sähköt menivät poikki myös tilanteessa jossa RAIDin uudelleenrakennus oli kesken, homma vaan alkoi aina alusta. No tämä rupesi sen verran pelottamaan, että tilasin Qnapille varavirtalähteen eli UPSin, tästä lisää myöhemmin.
Toinen uhriutuja oli Elisan WAN-linkki, jos sähköt räpsyivät tarpeeksi paljon, niin talon katolla oleva Zyxelin 4G modeemi pahoitti mielensä ja jäi juntturaan. Homman sai kuntoon käyttämällä laite hieman pidemmäksi aikaa virrattomana. Yleensä on selvinnyt yksittäisistä sähkökatkoista ihan ok, mutta ilmeisesti useampi peräkkäinen räpsy oli sille liikaa.
Eli piti saada vikasietoinen internet-yhteys käyttöön ja oli aika ottaa Dual WAN käyttöön Pfsensen kanssa. Pääosin homma noudatti samoja askelmerkkejä kuin aiemmassa postauksessa, joten turha toistaa niitä tässä.
Olin kuitenkin jossain vaiheessa aiempien testin aikana vaihtanut nimipalvelimiksi Cloudflaren 1.1.1.1 ja 1.0.0.1 DNS-palvelimet ja laittanut nämä osoitteet myös WAN-linkkien dpinger testiosoitteiksi. Yhdellä WAN-linkillä testiosoite toimi ihan ok, mutta jostain syystä Dual WAN setupissa testiosoitteet lakkasivat toimimasta ja ”Gateway” status muuttui ”unknown” tilaan. Kokeilin käyttää WAN-linkkejä alhaalla ja bootata Pfsense purkin, mutta ei auttanut. Lopulta vaihdoin nimipalvelimet ja testiosoitteet Googlen DNS-palvemiliksi 8.8.8.8/8.8.4.4.
Homma lähti pelittämään ja kotiverkon vehkeet pääsivät taas internettiin.
Dual WAN ominaisuuteen liittyy haaste joidenkin HTTPS-protokollan yli käytettävien webbisaittien kanssa ja ne eivät välttämättä tykkää jos liikenne näyttää tulevan kahden Duan WAN-linkin eri ip-osoitteista. Lääkkeenä tähän olin ohjannut kaiken HTTPS-porttiin (443) menevän liikenteen käyttämään pelkästään toista WAN-linkkiä, jolloin webbisaitin näkövinkkelistä kaikki liikenne tulee samasta ip-osoitteesta.
Homma toimi ihan hienosti ja ei tullut ongelmia esim verkkopankin käytössä. Toisaalta näyttää siltä, että päivittäisessä käytössä suurin osa meidän ulospäin suuntautuvasta liikenteestä on juuri kyseistä HTTPS liikennettä. Näin ollen toinen WAN-linkki hyrräsi suurimman osan aikaa käyttämättömänä.
Ainut millä sai liikennettä menemään kahden linkin yli oli käyttää ”Speedtest”-sovellusta, joka defaulttina käyttää testien aikana useampaa yhteyttä ja ei käytä porttia 443.
Ehkäpä tämä ei ole se mitä haetaan?
On tietysti hienoa, että Speedtestillä saa aikaan kivan näköisiä numeroita ja saa teoriassa yhdeltä tietokoneelta käyttöön molempien WAN-linkkien yhdistetyn kaistan, mutta ehkä olisi parempi saada liikenne jakautumaan tasaisemmin WAN-linkkien välillä?
No onneksi tähänkin löytyy potentiaalinen lääke. Otetaan käyttöön ”sticky sessions” asetus. Tästä lisää seuraavassa postauksessa.
Älypippuri 