ylläpitäjän sivunootit

Muiden harrastuksien ohessa teen myös ylläpitoa verkkopalveluille. Kodin lähiverkon lisäksi on ollut vaihteleva määrä kodin ulkopuolisia verkkolaitteita, palvelimia ja virtuaalipalvelimia.

Ylläpitämilläni alustoilla on pyörinyt paitsi omia sovelluksia, myös ystävien ja tuttavien verkkopalveluita. Palvelimillani on ollut myös joitakin matalan budjetin webhosting-toteutuksia (aloitteleville yrittäjille ponnahduslautana näkyvyyteen verkossa), sekä muutama yhdistystoiminnan kautta tilattu projektialusta lyhytaikaiseen tarpeeseen. Yhdistävänä tekijänä on ollut usein pieni budjetti, mutta tarve saada silti erinomainen palvelun taso. Ja minullehan tämä on harrastus.

Yksi pidempiaikainenkin projekti löytyy. Olen toteuttanut tarvittavan palvelinympäristön ja sen ylläpidon jo vuosien ajan Kaaosradiolle.

Vuonna 2008 syntyi hetken mielijohteesta takaa.fi, jonka tarkoituksena oli siirtää ajatustasolla erilleen ulkopuolisille tuotetut palvelut ja omat projektit. Siitä tuli kuitenkin lähinnä infrastruktuurin domain-nimi, pois lukien ensisijainen nimipalvelin edelleen terae.fi-domainissa. Tämän viimeisteli olosuhteiden pakosta tapahtunut pikainen siirtymä takaisin kotiverkosta käsin jaeltavaan sisältöön, sillä budjetti oli hyvin rajallinen ja tarvittiin iso määrä tallennustilaa käytettäviin. Elettiin vuodenvaihdetta 2011-2012 ja muuton myötä kotona oli hieman yllättäen useampi 1GE-liityntärajapinta kuitukytkimeen, mikä toi uusia mahdollisuuksia toteuttaa itseään.

Kodin ulkopuolisen infran sydämenä toimii Hetznerin Tuusulan ("Helsinki") konesalista vuokrattu erillispalvelin.
Olen sen verran old school ylläpitäjä, että luotan yhä perinteiseen erillliseen palvelinrautaan enemmän kuin jaettuihin resursseihin. Erityisesti aikakriittisissä sovelluksissa.

Kotona on Mikrotikin CCR (Cloud Core Router), 1 GE liityntärajapinta Elisan kuitukytkimeen, QNAP TS-459 Pro+ levykehikko (4 levyn RAID6), pari Ubiquiti AmpliFi HD Wi-Fi Mesh-reititintä, jne...
Esimerkiksi varmuuskopiointi palvelimilta suoritetaan yhä perinteisin menoin omalle levytilalle, kotiin.

Hetznerin konesali käyttää Vantaan Energian myymää tuuli- ja vesivoimaa 50/50 suhteessa myytynä. Kotonamme käytetään 100% vesivoimalla tuotettua sähköä.

datakaapin hiljennys ja viilennys (osa 2: SSD m.2 ja tuuletinvaihto 40x40x20mm)

Kun kaksi vanhinta pyörivää kiintolevyäni NAS-kehikon RAID-pakassa olivat jo selvästi hidastuneet toiminnaltaan ja ikääkin kertynyt jo noin 7 vuotta, päätin toteuttaa kauan päässä muhineen suunnitelman vaihtaa kaikki levyt SSD-malliin. Aikaisemmasta WD Green-sarjasta oli vielä kaksi levyä pyörimässä ja kaksi oli jo korvattu WD Blue -sarjalla, kooltaan 1TB ja käytössä RAID-taso 6 (viime kesään asti RAID10).

Uudet levyt ovat Samsung 860 Evo-sarjaa, 1TB levyjä 2.5" koteloituna eli SATA600-väylään sovitettuja M.2-muisteja (Samsung V-NAND 3bit MLC).
Nämä SSD-levyt on varustettu sisäisellä 1GB DDR4 välimuistilla, joten järjestelmän omaa muistia ei tarvi tuhlata välimuistiksi ja myös levylle kirjoitus on erittäin nopeaa.

Koska olin jo vaihtanut aikaisemmin RAID-pakan tason RAID10:stä RAID6:ksi, saatoin ottaa pakasta irti kaksi levyä samalla kertaa ja asentaa tilalle uudet ilman tietojen katoamista. Vaikka levyjärjestelmä ottaakin käyttöön vain yhden levyn kerrallaan, oli kätevämpää laittaa kaksi samalla kertaa ja odotella valmistumista, sitten seuraavat kaksi.

Energian kulutuksessa ja lämmön tuotossa on suuri ero. Normaalissa päivittäisessä käytössäni lämmöt putosivat koko datalaitekaapissa 2-3°C jo ensimmäisen käyttövuorokauden (RAID rebuild jälkeen) aikana. Laitekaapin kattopelti tuntuu käsiin viileältä aikaisemman käteen tuntuvan lämpimän sijaan. APC Smart-UPS ilmoittaman mukaisesti sähkötehon käyttö laski 3% (kuorma putosi 16%:sta 13%:iin) eli 750VA maksimista se tekee noin 23W pienempää tehonkulutusta ja siten myös vastaavasti pienempää lämmöntuottoa. Se on likimain sama määrä tehoa ja hukkalämpöä kuin mitä nykyinen reititinlaitteeni kuluttaa ja tuottaa kohtuullisella rasituksella käyttäessä.

Asennustarvikkeiden kanssa meinasi mennä sormi suuhun. Olin kokonaan unohtanut, että vanhat 3.5" ja uudet 2.5" "levyt" vaativat keskenään eri kokoiset asennusruuvit. Vanhat kehikon mukana tulleet 2.5" ruuvit olivat kadonneet. Sopivat ruuvit löytyi eläköityneestä RB1200-reitittimestä, jonka alumiinikotelo oli kasattu saman mitan uppokantaisilla koneruuveilla. Kussakin kehikossa on 3kpl ruuvin paikat 2.5" levyille, mutta näille riittää varsin hyvin 2kpl per media, kun eivät pyöri ja tärise voimakkaasti ja ovat hyvin kevyitä.

Aikaisemmin ostamani Noctua laitetuuletin alkoi pitämään hiljattain melua. 6 vuoden takuu ei auta akuuttiin ongelmaan.
Kyseisen mallin pitäisi olla enintän 4500rpm nopeudella pyörivä, mutta omani pyörii noin 5000rpm.
Teki sitä jo uutena, pyöri 4700-5000rpm koko käyttöaikansa, mutta nyt on tullut ylimääräinen sivuääni ikäväksi extra-ominaisuudeksi.

Kun enää ei ole kiire (on yhä hiljaisempi kuin alkuperäinen tuuletin ja tekee tehtävänsä), tilasin uusiksi CCR:n tuulettimiksi valmiiksi oikean kokoisia Noctua 40 x 40 x 20mm NF-A4x20 PWM malleja. Niitä 10mm paksuja oli valmiiksi hyllyssä mm. Jimm'sillä, mutta 20mm mallissa kestää muutaman päivän pidempään saada.

Tällä kertaa vaihdan sekä main että aux tuulettimen hiljaiseen malliin. Nähtäväksi jää, miten niitä käytän.
Suorituskykyarvoissa on 10mm ja 20mm paksun mallin välillä "pieniä" eroja, joten odotettavissa on myös hieman viileämpää toimintaa: 40x40x20mm mallille on ilmoitettu ilmavirraksi täydellä teholla 5.5 CFM (9.34 m3/h), kun taas 40x40x10mm mallista on ilmoitettu vastaavaksi luvuksi 8.2m3/h (4.8 CFM).
Alkuperäistä vastaavan kokoinen myöskin asettuu paikoilleen alkuperäisen suunnittelun mukaisesti eli ilmavirta kerätään lähempää jäähdytyssiiliä ja pusketaan ulos alkuperäistä vastaavalta alueelta. Pienemmän mallin lamellit puhaltavat laajemmalta alalta, mutta poistoaukkoja on vain paksumman mallin toimintaa vastaavasti kapeammin reunalla.
Ohuemman asennus oli kompromissi kiireen ja toimivuuden väliltä. Olisi pitänyt asentaa oikean kokoinen malli jo aikaisemmin.

Debianin CPU-scaling säädöt palvelinkäyttöön (powersave -> performance)

Tässä viher-orientoituneessa maailmassa näyttää tulevan asennukset vakiona suurimman tehon säästön asetuksin.
Myöskään Hetznerin palvelimen Debian 9-asennus, jonka hiljattain päivitin Debian 10-versioon, ei tehnyt tässä poikkeusta.

Koska käyttö on mm. radio-stream palvelua ja julkista NTP-palvelua, poistin cpufreq-utilsin ja sen sellaiset turhina.
Sen tehtyäni käskytin komennon
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done
laittaakseni kaikki Intel Core i7-7700 ytimet toimimaan parhaan suorituskyvyn asetuksella (muussa tapauksessa ne ovat powersave-asetuksin).


Ero suorituskyvyssä on hyvin selvästi nähtävissä esimerkiksi yksinkertaisen web-sivun haun Apache-palvelimelta reaktioajoissa.

Ytimien lämpötiloihin muutoksella on vähäinen vaikutus.

Lopuksi vielä sama rimpsu /etc/rc.local -tiedostoon, niin paras CPU-suorituskyky on taattu myös uudelleenkäynnistysten jälkeen.

IPv4-osoitteet ovat loppuneet (viimein)

Nyt viimein (näin voinee sanoa), noin 10 vuoden panikoinnin muututtua vuosien odotteluksi jälkeen, on tosi kyseessä.
Edes kierrätettyjä IPv4-blokkeja ei enää ole välittömästi jaeltavaksi eteenpäin, vaan kertyy jonoa.

Aiheesta voi lukea lisää RIPE NCC sivuilta, tässä linkki jonotuslistan tietoihin.

Nyt operaattorit viimeinkin niitä natiiveja IPv6-osoitteita päälle kaikille! Pls!

meilipalvelimen hienosäätöä kohden nykyaikaa (DMARC ja SPF)

Nykyisin sähköpostin siirto on muutakin kuin sisällön dumppaamista paikasta toiseen. Sähköpostia suodetaan monin keinoin haittaliikenteen vähentämiseksi.

Yksinkertaisimmillaan domainin (esimerkiksi takaa.fi) DNS-tietueet sähköpostin sujuvaan siirtämiseen ovat nykyisin seuraavan näköiset:

@ IN MX 10 ilolan.takaa.fi.
@ IN TXT "v=spf1 mx mx:takaa.fi -all"
polecats-enjoyment _dmarc IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@takaa.fi; sp=quarantine"

polecats-enjoyment

Nämä säännöt määrittelevät sähköpostipalvelimille tietoja, joiden perusteella sähköpostin sallitaan siirtyä tai se hylätään.
MX-tietue on vanhin kaikista, jo kauan käytössä ollut tietue, joka kertoo ensisijaisesti domainin vastaanottavan sähköpostipalvelimen nimen. Ilman tätä tietuetta olisi jokaisen domainin juuritietueen IP:ssä sähköpostipalvelin.

SPF-tietue on tekstikenttä juuritietueessa ja määrittelee RFC 4408/RCF 7208 mukaisesti säännön siitä, mitkä palvelimet ovat sallittuja lähettäjiä kyseiselle domainille. Esimerkkitapauksessa vastaanottavat palvelimet (MX-tietue tai tietueet) ovat myös sallittuja lähettäjiä. Joissakin tapauksissa sallittujen palvelimien lista kuitenkin eroaa lähetys- ja vastaanottosuuntiin ja säännöt tulee asettaa sen mukaan.

DMARC-tietue on tekstikenttä _dmarc (esimerkkitapauksessa _dmarc.takaa.fi) isäntänimen takana. Se määrittelee domain-tason tunnistusperusteet. Esimerkin tapauksessa se aktivoi raportoinnin ja sallii kaikkien juuritason domain-nimellä lähetettyjen viestien siirron, mutta hylkää alidomainit, joita omissa järjestelmissäni ei käytetä. Vaihtoehtoisia hylkäystapoja on reject (hylkäys tallentamatta) tai quarantine (riippuu palvelusta miten käsittelee, esimerkiksi siirtää spam-kansioon tai muuhun karanteeniin). Domainille ei ole kuitenkaan tässä tapauksessa asetettu muita ehtoja tunnistautumisen suhteen kuin nimipalvelu- ja IP-perusteella tunnettu lähettävä palvelin.

Näillä perustein esimerkiksi Gmail, jossa on DMARC ja SPF -perusteiset suodot käytössä, sallii ilolan.takaa.fi MX-palvelimen lähettää kokeilen@takaa.fi-osoitteella sähköpostia. Sen sijaan vaikkapa kokeilen@onnistuisiko.se.takaa.fi lähetetty viesti hylättäisiin ja MTA saattaisi lähettää vuorokausiraportin, että tällaistakin on yritetty.

Paluu ntp.org pooliin

Vuosia sitten, kun julkisia (S)NTP-palvelimia oli yllättävän vähän koko maailmassa, jakelin omalta stratum-3 aikapalvelimelta kotoa käsin aikaa NTP pool projectissa (pool.ntp.org).
Päädyin kuitenkin pian lopettamaan epävakaan xDSL-linkin vuoksi.

Nyt, kun minulla on vakaa ja vähän kuormitettu palvelin hyvän yhteyden päässä (1 Gbit/s taattua kaistaa), tein paluun julkiseen NTP-pooliin.
Oheisesta linkistä näet NTP pool project profiilini.

Liityttyäni fi.pool.ntp.org -pooliin oli siihen liittyneenä ja toiminnassa vain 50kpl IPv4 (koko maailmassa ~2800) ja 10kpl IPv6-liitettyjä (koko maailmassa ~1300) aikapalvelimia.
Suomalaisten julkisten NTP-palvelimien määrä on yhä hyvin vähäinen.

Miksi julkiset NTP-pool-palvelimet ovat niin tärkeitä?
Esimerkiksi moni Linux-jakelu käyttää edelleen pool.ntp.org ensisijaisena palveluna. Windows-työasemat eivät käytä DHCP-mainostettuja lähimpiä operaattorin aikapalvelimia, jne.
Monin paikoin julkinen NTP-pool on se helppo ja ensisijainen valinta ja tämä pool-projekti löytyy yleensä ensimmäisenä ja sitä mainostetaan lähes joka keskustelussa aiheesta.

Ison linkkinopeuden stratum-2 palvelimia on vähäinen määrä kotimaassa ja siten suuri osa (erityisesti IPv6-liikenteestä) päätyy omalle palvelimelleni.
Kotimaisten palveluun liittyneiden IPv6-osoitteita jaellaan ainakin toistaiseksi lähinnä 2.fi.pool.ntp.org kautta.

Aikatieto palvelimellani (Europe/Helsinki):


Sinun laitteeltasi saatu aikatieto:

Jos nämä ajat eroavat useita sekunteja (jopa minuutteja) keskenään, on syytä asettaa laitteeseen verkkoajan päivitys päälle. Esimerkiksi 2.fi.pool.ntp.org-osoitteella, ellei parempaa ole tiedossa.

Nykyisin useimmissa laitteissa onkin jo valmiiksi ajan päivitys verkosta päällä, mutta se saattaa käyttää kaukana olevia palvelimia kuten time.windows.com ja on aina parempi käyttää mahdollisimman lähellä olevia osoitteita. Monet operaattorit jakelevat myös DHCP-viesteissä kuluttaja-asiakkailleen lähimpien operaattorin omien aikapalvelimien osoitteita kuten ntp.elisa.fi, jolloin se on luonnollinen valinta myös käsin asetetuksi aikalähteeksi.

Tällaisena hc-nörttinä olen tietenkin varmistanut omassa verkossani, että NTP-kyselyt menevät tunnetulle aikapalvelimelle. Tämä on mahdollista palomuurin NAT-säännöllä, joka siirtää lähtevät kyselyt haluttuun osoitteeseen ja paluuviesti näyttää tulevan alkuperäisen kyselyviestin mukaiselta palvelimelta. Useimmat verkkolaitteet sisältävät asetuksissaan valmistajakohtaisia pooleja, jotka ovat hyvä kompromissi, mutta esimerkiksi Ubiquitin tahtotila käyttää DNA:n NTP-palvelimia Elisan verkossa ei ole se paras vaihtoehto.

datakaapin hiljennys ja viilennys (osa 1: CCR asennuksen jälkimainingit)

Asennettuani Mikrotik CCR:n hiljaisemmalla tuulettimella, huomasin lämpötilojen olevan hieman turhan paljon koholla. Aloitin pikaisen ratkaisun korjailulla.

Koska asennettu Noctua-tuuletin on 40x10 mm ja alkuperäinen tuuletin 40x20 mm, kävin hakemassa kotimatkalla yhden halvan 40x10mm tuulettimen. Siitä poistin tuulettimen, jolloin jäljelle jäi vain tukeva täytepala yhtenäisen tunnelin tekemiseksi. Näillä keinoin muodostuu jälleen 40x20mm tuulettimen paikan täyttävä yhdistelmä.

Yllätyksekseni sillä oli suuri vaikutus miten päin palikat asentaa.
Ensimmäisessä vaiheessa laitoin tuulettimen lähemmäs jäähdytysripoja ja tyhjän hylsyn lähemmäs ulostuloaukkoja. Tällä tavoin asennettuna ilmavirtaus oli hieman nopeampi ja jäähdytysteho parempi, mutta pienille tuulettimille tyypillinen ujellus palasi äänimaisemaan.

Vaihtoehtoinen asennustapa on asentaa tuuletin suoraan kiinni ulostuloaukon luokse peltiin ja jättää tyhjä hylsy imupuolen ohjaimeksi.
Tämä asennustapa on hieman heikompi jäähdytysteholtaan, mutta ujellus poistuu.
Lämpötiloissa (CPU) muutos on noin 1-2°C luokassa.

Tämä on varsin hyvä kompromissi kotikäyttöön, jossa CPU-rasitus harvemmin on edes puolta täydestä suorituskyvystä.

Lyhyen harkinnan jälkeen tämä jätetään käyttöön.

Koska datakaappi on ollut hieman turhan lämpöinen ympäristö tähän asti, parantelin myös kokonaisuudessaan sen painovoimaista tuulettumista.

Yläosan kaksi 120mm tuulettimen paikaa on ollut suljettuna peltilevyillä, joten avasin ne ja laitoin niihin pelkät tuulettimen esisuodattimet (mahdollisten päältä putoavien pienten roskien poissa pitämiseksi).

Tällä pienellä muutoksella saadaan lämpösimmästä kohden yläosasta ilma vaihtumaan ja vaikutus laitteiden lämpötilaan on 2-4°C.

CCR1009-7G-1C-1S+ lämpötilavahti

Koska järjestelmän oma automatiikka vain käynnistää laitteen uudelleen cpu-overtemp-threshold -arvon kohdalla (jää odottelemaan jäähtymistä cpu-overtemp-startup-delay ajaksi), päätin lisätä vähän skriptauksella parempaa ohjauslogiikkaa ja ennakoivaa viilennystä.
Tämä tarve muodostui päätuulettimen vaihdosta hiljaisempaan johtuen.

Loin skriptin cputemp-watch, jonka muokkasin Miktorik foorumilta (credits go to "theycallmetimmy"; who ever you are, thanks Timmy!) löytyneestä skriptistä:
/system script add dont-require-permissions=yes name=cputemp-watch policy=read,write,policy,test source="
:global "cputempstatus"
:global "cputemplaststatus"
:global "cputemp" [/system health get cpu-temperature]
:if (cputemp > "69") do={:set "cputempstatus" "ALERT: cpu temp is high - activating aux fan"}
:if (cputemp < "70") do={:set "cputempstatus" "NOTICE: cpu temp is ok - disabling aux fan"}
:if ($"cputempstatus" != $"cputemplaststatus") do {
:log info "$cputempstatus"
:if (cputemp > "69") do={:system health set use-fan=auxiliary}
:if (cputemp < "70") do={:system health set use-fan=main}
:set "cputemplaststatus" $"cputempstatus"
}"

Loin scheduleriin ehdon, että skripti ajetaan minuutin välein käynnistyksen jälkeen:
/system scheduler
add interval=1m name=cputemp-watch on-event=cputemp-watch policy=read,write,policy,test start-time=startup

Nyt voi olla huoletta, sillä mikäli lämpö nousee turhan korkealle, tehokas tuuletin korvaa hiljaisen noin minuutin ajaksi. Tai kuinka kauan tarve sitten kestääkään kovassa rasituksessa.

Kun mikään ei riitä (kotiverkon runkopäivitys Gigabit-luokkaan, osa 2)

flektikuva

Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router on nyt asennettuna.
Käyttöönotto vei pari tuntia. Ajankäytöstä suurin osa meni kaapeloinnin uusimiseen, räkin järjestelemiseen ja vastaaviin hienosäätöihin. Ohjelman perusasetukset (osan siirto vanhasta reitittimestä) ja uuden laitteen lisäsäädöt tein noin vartissa.

Kotikäyttöön tuollainen on tuulettimiltaan aivan liian meluisa, mikä tuli huomattua nopeasti. En ollut kuitenkaan osannut varautua melumäärään, joten käytin laitetta muutaman päivän ajan 400MHz core-nopeudella ennen kuin sain uuden hiljaisen tuulettimen käsiini.

Uudeksi tuulettimeksi valikoitui Noctua NF-A4 FLX.
Uusi tuuletin on sentin alkuperäistä ohuempi, joten varmistin ilmavirtauksen oikean suunnan teippaamalla sivut kiinni muoviseen ilmanohjainkoteloon. Lisäksi teippasin samaisen boksin päälle silikoniletkun pätkän varmistamaan sen tiiviyden emolevyyn peltikoteloinnin puristuksella. Samalla saavutettiin mahdollisimman hyvä värinänavaimennus, mistä on hyötyä sekä laitteiden ja liitosten mekaanisen kestävyyden, että meluntorjunnan suhteen

Näin datakeskuslaitteesta tuli kotikäyttöön soveltuva hiljainen tehopesä, jonka pelastaa ääritilanteissa alkuperäiseksi jätetty aux-fan eli varatuuletin. Se ei kuitenkaan todennäköisesti tule käynnistymään kertaakaan edes kesähelteillä. Jos flekti alkaa huutamaan kuin hinaaja, siitä tietää olevan aiheellista lisätä koko räkkikaapin tuuletusta.

Asennuksen jälkeen selvisi, että combo-portti (SFP/GE) jumittelee. Syyksi ilmeni Rx FCS error ja Rx Code error.
Samaa ongelmaa oli ollut jo aikaisemminkin mikäli verkkoyhteydessä käytti erillisportteja eikä kytkinporttia; esimerkiksi RB1200 portit 9 ja 10 eivät läpäisseet juuri lainkaan liikennettä ja jumittelivat, samoin RB450G portti 1 mikäli sen irrotti kytkinkäytöstä ja siirsi suoraan CPU-käyttöön konfiguraatioltaan.
CCR1009-7G portit ovat kaikki erillisportteja ja siten virheet aiheuttavat keskeytyksiä ja hidastavat siirtoa virheellisistä ethernet-frameista riippuvan määrän.

Muistin, että aikoinaan oli sama ongelma käyttäessäni kotona Nebulan reititystä samalla Elisan kuitukytkimellä. Samassa yhteydessä olimme testanneet ystäväni Timo Raidan kanssa Fluken testerillä, että kaapeloinnit kuitenkin täyttivät sisäverkossa Cat6 U/UTP vaatimukset ja ylittivät ne riittävästi, joten vika ei voinut olla runkonousussa.

Siinä yhteydessä porttia oli vaihdettu ja ongelmat poistui. Portti oli kuitenkin palautettu alkuperäiseen vaihtaessani liittymän Elisan liittymäksi (hetkelinen päällekkäisyys liittymäsopimuksissa ja runkonousua vaihdettiin valmiiksi kaapeloituun toiseen porttiin). Olin vaihtanut sisäverkon kokoonpanoa ja siinä yhteydessä portiksi oli vaihtunut sellainen, mikä ei näistä virheistä välittänyt ja siksi virhe näytti olevan poissa vuosia.

Tein muutamia testejä reititysnopeudelle ja virheilylle. Testasin yhteyden molemmilla runkokaapeleilla omin laiteportein kodin ja jakamon välillä, eikä virhettä ilmennyt isoillakaan siirtonopeuksilla. Vein toisen oman laitteeni puolen metrin päähän ISP reitittimestä kytkinsillaksi ja kaikki toimi ok reitityksessä tällöin.
Tein vikailmoituksen ja porttia vaihdettiin. Samalla vaihtoivat käyttöön eri runkonousun ja patch-kaapelinsa.

Virheitä ei ole sittemmin ilmennyt ja täysi Gigabit-nopeus toimii myös ulkoverkon reiteille reititettynä. Nyt kotiverkkoni on päivitetty todennäköisesti noin 20 vuodeksi eteenpäin riittävälle tasolle ja laajennusavaraa riittää myös suoraan kuituyhteyteen, mitä tulevaisuuden tarvetta varten kotiin asti on jo rakennusvaihesssa vedetty myös kuidun pää valmiiksi. Tervetuloa 4K, 8K tai vaikka 32K striimit! :)

Kun mikään ei riitä (kotiverkon runkopäivitys Gigabit-luokkaan, osa 1)

Itselleni harvinaisen pitkän harkinnan jälkeen, palautettuani kuituliittymän nopeusluokaksi 1Gbit/s (tarjouksella seuraavan pari vuotta vain 10€ kalliimpi kuin 250M ohjelmarajoitettu), tilasin uuden runkoreitittimen kotiini.

Samalta istumalta tilasin (viimeinkin) räkkiini myös "kaapelinhallintapaneelin" ja muutaman uuden Cat6-piuhan korvaamaan vanhoja Cat5e-vetoja.
Toistaiseksi toinen NAS-järjestelmän portti on poissa käytöstä ja aikaisempi WAN-yhdyskaapeli alkoi myöskin pätkimään linkkiä toistaiseksi tuntemattomasta syystä (ehkä RF-häiriöt?). Samalla päivitän myös 4G-reitittimen kaapeloinnin S/FTP-tyyppiseksi suojatuksi. WAN-yhdyskaapeliksi tulee Cat6 F/UTP ja kaapin sisäistä kaapelointia uusiessa jatkan Cat6 UTP-linjalla. Jokainen kaapin sisälle tuleva kaapeli on jatkossa värikoodattu eli kullekin laitteelle on oma värinsä. Poikkeuksena 4G-linkin harmaa, jotta se ei erotu ihan niin paljon kulkiessaan avovetona vaaleaa seinäpintaa vasten.

Aikaisemman selvitystyön jälkeen oli helppo valita Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router, joka on nyt tätä kirjoittaessani tilattu. Siitä myöhemmin lisää.
Verkkokoonpanoni nykyiset Mikrotik RB450G ja RB1200 korvautuvat molemmat tällä uudella laitteella.

Vähän taustatietoja, jotka vaikuttivat valintoihin ja tekoihin:
Kuituoperaattorini kotiliittymissä on epäsymmetrinen nopeusluokka 10:1 jakosuhteen periaatteella eli 1Gbit/s down ja 100Mbit/s up on tämän hetken suurin sallittu reititysnopeus, vaikka fyysinen linkki on luonnollisesti 1G/1G full-duplex.
Epäsymmetrisestä nopeusluokasta seuraa tarve hallita erityisesti kotoa lähtevää liikennettä, jotta mikään yksittäinen laitteen pilvisynkronointi tai vastaaava toiminto ei tukkisi linkkiä ja aiheuttaisi edes lyhytaikaisia häiriöitä muulle käytölle.
Tavanomaisesti kotikäytössä siedetään pientä tahmaa hetkittäin, mutta minä en kuulu tavanomaisiin kotikäyttäjiin.

Tätä kirjoittaessani olen muokannut verkkokokoonpanoni olemassa olevilla laitteilla siihen suorituskykynsä huippuun, millä on mahdollista saavuttaa noin 700/100M jatkuva liikennöinti ilman isoa pakettikatoa ja esimerkiksi tunneliprotokollien liikennöinnin katkeilua ja tolkutonta uudelleenlähetystarvetta TCP-liikennöinnissä (esimerkiksi palvelimen tehdessä backupit kotiin).
Tämän toteuttamiseksi RB1200 hoitaa varsinaiset reititystyöt. Lähtevälle reititysliikenteelle on SFQ-queue, jonka käyttö aiheuttaa NAT-reitityksen ohessa sellaisen CPU-kuorman, ettei reititin jaksa enää tehdä täydellä teholla reititystyötään. Ilman queue-sääntöjen osuutta latausnopeudet ovat olleet suurimmillaan noin 920 Mbit/s, mutta jo kytkimen hallintaohjelman käyttö samanaikaisesti laskee suorituskyvyn noin 850 Mbit/s tasolle.
RB450G hoitaa WAN-puolen wire speed siltausta (RB1200 ja IPTV kesken, jotta IPTV saa suoran yhteyden runkoon). Koska se ei tee varsinaista reititystä ja kytkinpiiri hoitaa raskaimmat työt itsenäisesti, sille jää hyvin CPU-aikaa, jota on hyödynnetty mm. DNS resolver-käytössä lähiverkolle, työpaikalta tarpeen mukaan web-proxyliikenteen hoitamiseksi (omat jutut työkoneella) ja vastaaviin matalan prioriteetin toimiin.

Monien dataverkkonörttien tapaan en kuitenkaan halua tyytyä siihen, että laitteet ovat hieman alimitoitetut ja ajoittain täydellä käytöllään (hyötysuhde sinänsä parhaimmillaan). Sen sijaan haluan mielummin ylimoitoittaa laitteet tämän hetken tarpeeseen ja jättää valmiiksi option laajennuksiin tulevaisuudessa. Uuden kokoonpanon tulisi palvella vähintään vuoteen 2030 asti ja mahdollistaa molempien asunnon Ethernet-nousujen käyttö samanaikaisesti. Lisäksi optiona suora valokuituveto asuntoon tuodun kuidunpään avulla.

Haluan samalla jättää itselleni joustavan mahdollisuuden laajentaa harrastuskäyttöäni jälleen kotipalvelimiin ja luoda VPN-yhteyksiä tarpeiden mukaan nopeista dataliittymistä kodin kautta kierrätettynä. Ja ne eivät saa häiritä kotona esimerkiksi IPTV-käyttöä ja WiFi-puheluita tai muita VoIP-toteutuksia, tai mitä tahansa muuta reaaliaikaisuutta vaativaa tulevaisuuden käyttötarvetta. Pienen pakettikoon reaaliakainen liikennöinti vaatii tavanomaista suurempaa reitityskapasiteettia.
Kaikki VoIP ym. toteutukset eivät välttämättä siedä täysin ongelmitta esimerkiksi nykyistä 0.7ms ja 14ms välillä vaihtelevaa kuormituksesta riippuvaa latenssia ja satunnaisia enemmän viivästyviä tai kokonaan putoavia paketteja.

IPv6 Elisan kotiverkkoon vaikka väkisin (siitä piti tulla vain 4G-varayhteys ja kuormantasaus)

Aloitin tilaamalla hetken mielijohteesta Netgear MR1100 4G-reitittimen ja siihen Elisan 4G-liittymän. Ajatuksena oli, että tekisin kuormantasausta ruuhkahuippuihin ja varayhteyden kotiverkkoon.

Ensimmäinen setup oli seuraavanlainen:
MR1100 oli yhdistettynä RB450G porttiin, joka otti haltuunsa siltaavassa tilassa ulkoisen IPv4-osoitteen DHCP:llä ja teki siitä ensisijaisen reitin kyseiselle reitittimelle. RB1200 on kodin ensisijainen reititin ja sieltä oli siirretty valikoidut liikenteet toissijaiselle reitille ja lisäksi vikatiloja varten oli toissijaiset reitit odottamassa. Kaikki toimi ihan ok, mitä nyt oli vaikeuksia keksiä mikä liikenne olisi hyvä reititellä mobiiliverkkoon ja millä kriteerein.

Nälkä kasvaa syödessä. Huomasin, että yhteyteen on helppo lisätä IPv6-toimivuus, joka Elisan kuituyhteyksistä yhä vuonna 2019 puuttuu (miksi?!). Kyseinen laite toimii IPv6-proxynä ISP:n ja asiakkaan omien laitteiden välillä. Koska tämä ei kuitenkaan mahdollista reititystä yhtä laitetta pidemmälle (operaattorin tarjoamaa /64 IPv6-blokkia ei voi jakaa eteenpäin reititettynä sisäverkkoon), eikä pelkästä reitittimen IPv6-toimivuudesta ole juurikaan hyötyä, lähdin kokeilemaan vaihtoehtoisia setupeja.
Huomasin RB450G tavoittavan 4G-yhteyden kautta IPv6-osoitteita myös MR1100 ollessa reitittävässä tilassa. Tämä mahdollistaisi tuoda sen IPv4-varayhteys ja IPv6-toimivuus LAN-puolelle kaikkiin laitteisiin, kunhan laitteen oma DHCP on suljettuna. Tuumasta toimeen.

Hyvin pian sain huomata, että verkkolaite toisensa perään putosi irti verkosta. Hieman myöhemmin ongelma rajoittui lähinnä RG450G puolelle, kun siirsin prioriteettimuutoksella RSTP-protokollassa RB1200 takaisin root-sillaksi. Raavin päätäni hetken ja siirsin MR1100 tämän ensisijaisen RB1200-reitittimen LAN-siltaan. Sama ongelma jatkui, mutta taas pääsi eri suunnasta käsiksi suorin yhteyksin. Poistin RB450G omat sisäiset siltaukset turhina ja liitin sen suorina yksittäisportteina takaisin RB1200, mutta ongelma jatkui vaikka enää ei ollut taistelua root-bridge roolista. IPv6 tuntui toimivan, mutta IPv4 ei. Eihän tämän näin pitänyt mennä.

Tässä vaiheessa huomasin, että ARP-tiedot täsmäävät kyllä RB1200 ja RB450G omissa ARP-tauluissa, mutta muut laitteet saavat kaikki MR1100 mainostamana sen omaa MAC-osoitetta.

Ongelman laadun selvittyä se oli helppo korjata. Laitoin RouterOS sillasta tarpeettomat ARP-huutelut suodatukseen, niin MR1100 ei enää vastaile niihin omiaan. Samalla, kun tutustuin näihin siltauksen asetuksiin, päädyin laittamaan koko siltaa koskevan dhcp-snooping=yes asetuksen, jolloin MR1100 oman DHCP-palvelimen tilalla ei ole merkitystä ja sitä voi käyttää myös normaalina langattomana reitittimenä tarpeen mukaan ilman mitään konfiguraatiomuutoksia. Samalla kannattaa varmuuden vuoksi laittaa fastpath/fasttrack pois päältä.
Hardware offload tulee asettaa pois päältä, jotta bridge filter toimii kaikkeen liikenteeseen.
HUOM! Jos sillassa on muissa porteissa käytössä haluttuja DHCP-palvelimia, näihin portteihin tulee asettaa trusted=yes päälle.

Sillan yleisasetukset:
/interface bridge
add add-dhcp-option82=yes dhcp-snooping=yes fast-forward=no name=br-lan
/interface bridge port
add bridge=br-lan hw=no interface=eth2-mobile restricted-role=yes
add bridge=br-lan hw=no interface=eth1-lan
(Palautin 4G-reitittimen takaisin RB450G:n 5-porttiin ja portista 3 on yhteys isomman reitittimen siltaan, joka on root-bridge.)

Ja lisäksi bridge filter asetukset turhien ARP-kyselyiden pysäyttämiseksi kyseiseen porttiin:
/interface bridge filter
add action=drop arp-dst-address=!192.168.1.1/32 chain=output mac-protocol=arp out-interface=eth2-mobile
add action=drop arp-dst-address=!192.168.1.1/32 chain=forward in-bridge=br-lan mac-protocol=arp out-interface=eth2-mobile
(HUOM! Suodatus sillä perusteella, että !192.168.1.1/32 eli jos ei ole tämä Netgear MR1100 oma LAN-osoite, jolle kysellään fyysistä osoitetta. Tällöin selvitään yhdellä säännöllä per chain, koska ei tarvi erikseen hyväksyä haluttua osoitetta ja suotaa muita.)

Eli nyt tarvittaessa MR1100 voi vain poimia mukaansa ja se toimii normaalina WiFi-4G reitittimenä. Konfiguraation muutosten ja tilan tarkistamisen tarpeita varten tarvii vain yksinkertaisen NAT-Masquerade säännön RouterOS palomuuriin sen LAN-asetuksia vastaavasti, jolloin riittää RB1200 tuntea tuo kyseinen laite oikealta osoitteeltaan IPv4-puolella.

Ajoittaisen IPv6-katkeilun syyksi osoittautui molemmissa RB-reitittimissä olleet väärät ND (Neighbor Discovery) asetukset.

Referrer-spam-botnetit kuriin (Nginx)

Nykyaikana kaiken sortin spammaaminen on yleistä. Siten on kasvavana ongelmana myös www-sivutilojen kautta tapahtuva liikenteen kaiutus ja pyrkimys nostaa pisteitään mainosverkostoissa, hakukoneissa, jne...

Jotkin mainosverkostot näkyvät toistuvasti referer-tiedoissa web-statistiikassa. Heidän kaiuttamansa liikenne tulee usein kolmansien osapuolien kautta ja saatat haluta poikkasta useiden referer-kohteiden liikenteet heti alkuunsa.

Useita nettilähteitä selattuani päädyin lisäämään Nginx-pohjaisen proxyni site/server-konfiguraation alle seuraavan rivin:
if ($http_referer ~* (semalt\.com|\.ru) ) { return 403; }
Tämä antaa HTTP-virhekoodin 403 ja estää liikenteen kaikilta semalt.com ja *.ru kautta tulevilta yhteyksiltä web-palvelimelleni.
HUOM! Tuo \.ru saattaa estää joitakin muita ".ru"-osuuden nimessään sisältäviä sivustoja, käytä varovaisesti. Omalle palvelimelleni ei ole erityistä syytä päästä sisään suorilla linkeillä minkään vastaavan web-sivun kautta.

Edellisen lisäksi olen päätynyt estämään IP-pohjaisesti häiritsevän paljon liikennöimään yrittäneet IP:t eli samassa server-osuudessa on rivi
if ($bannattu) { return 403; }
ja tätä edeltävässä osuudessa yleisellä tasolla kongifuraatiossa (voi laittaa saman tiedoston alkuun ennen "server {" osuutta) rivit
geo $bannattu {
default 0; #normaalisti kaikki pääsee läpi
93.221.199.91/32 1; #numero 1 tarkoittaa bannin olevan voimassa
112.168.56.131/32 1;
85.25.43.94/32 1;
141.212.121.0/24 1;
141.212.122.0/24 1;
}

Täten haitalliseksi havaittu liikenne on näiden osalta pysäytetty virhekoodilla 403.

Voiko olla liian nopea netti? Joskus voi, kun hinta ja käyttöaste (järki) ratkaisee.

Palvelinympäristöjen uudelleenjärjestelyn myötä Saunalahti Kotikuitu 1000M jäi käytännössä turhan nopeaksi, sillä enää ei tarvita kodin ja ulkopuolella olevan palvelimen välisiä NFS-levykytköksiä muuhun kuin kotiin päin tapahtuvaan varmuuskopiointiliikenteeseen. Muun ajan levykytkennät voi olla irrotettuina, jolloin kodin ja palvelimen välinen liikenteen hidastuminen ei vaikuta palvelinten toimintaan.

Johtuen mainituista varmuuskopiointitarpeista ja yleisesti lapsiperheen nykypäivän WiFi-käyttöasteesta (nämä jakautuvat eri vuorokaudenaikoihin), valikoitui Saunalahti Kotikuitu 250M tämän hetken tarpeisiin sopivimmaksi. Se on tämän hetken hinnoilla aikaisempaa sopimusta 30€ halvempi ja siten tällä erotuksella voi maksaa suuren osan uuden palvelimen tuomista kuluista.

Nopeusluokan laskua lähdin harkitsemaan, paitsi edellä mainituista kustannusrakenteen jakautumisen syistä, myös teknisistä järkisyistä.
Näitä mainitakseni:
Osoittautui, että edes uusin hankintani WiFi-käyttöön (Ubiquiti AmpliFi HD, hinta 170€) ei kyennyt tarjoamaan kuin noin 300Mbit/s siirtokapasiteettia langattomana kotiverkossa. Suurimmat nopeudet olivat noin 500Mbit/s oman MiMo-puhelimeni kanssa käyttäessä, mutta tämä toteutui todella harvoin. Siten isommasta kapasiteetista ei ollut juurikaan hyötyä normaalissa kotikäytössä. Parantaakseni WiFi-toimivuutta olisi pitänyt hommata ainakin yksi tällainen laite lisää ja mahdollisesti muutama mesh-toistin niille.
Kotiverkkoni sydämenä toimiva reititin osoittautui sekin alimitoitetuksi Gigabit-luokan käyttöön, sillä usean käyttäjän pikkupaketit saavat sen liian varhain tukkoon. Kokeiluni ylikellotettuna antoivat kyllä täyden nopeuden reitityskapasiteetin, mutta ennemmin vakaus kuin riskillä lisätehoa. Eli tämä laite olisi vaihdettava uuteen. Uusi omaan määritelmääni riittävä laite olisi ollut Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router (kuola valuu tätä kirjoittaessa), mutta hinta hieman hirvitti - se kustantaa noin 500€.

Uudet laitteet jäivät tilaamatta, sillä nopeusluokan lasku ratkaisi kapasiteettiongelman tältä erää.
Ja samalla harrastusbudjetin hintalappu laski 30€/kk.

Dovecot-optimointia (pari sanaa mobiilikäytöstä)

Tehdessäni aikaisemman kirjoitukseni muutoksia Dovecot-asennukseen huomasin muutamia pikkuseikkoja, jotka on hyvä huomata muuttaa. Muussa tapauksessa palvelimen vakioasennus on omiaan tuhlaamaan langattomista laitteista akkua aivan turhaan.

Tiedostossa 20-imap.conf:
imap_idle_notify_interval = 20 mins
Ei ole syytä ilmoitella kovin tiuhaan olevansa paikalla ja aktivoida mobiilikäyttäjän radiota turhalla viestillä.

Tiedostossa 10-mail.conf:
mailbox_list_index = yes
Ilman tätä IMAP NOTIFY ei voi toimia ja tällöin asiakasohjelma tekee tarpeetonta toistuvaa viestien hakua.

Dovecot-optimointia (spam-suodon parantelua)

Käytän sähköpostipalveluissani Dovecot-palvelinta (dovecot-imapd, Debian).

Tänään asensin lisäpaketin dovecot-antispam.
Kyseinen plugin mahdollistaa tunnistetulle spam-kansion (yleensä nimellä Junk) sähköpostien käsittelyn sa-learn (SpamAssassin Bayes-opetus) avulla heti viestin kansioon siirtäessä. Ja myös sisällön palauttamista tunnetuksi hyötysisällöksi ("ham") mikäli kansioon vahingossa päätynyt sähköposti palautetaan pois sieltä (muualle kuin roskakoriin).

Ohjeet ja skriptin pätkä löytyivät raimue.blog (2016/08/21) "setting up dovecot antispam with spamassassin"

Dovecot-antispam asennus meni lyhykäisyydessään seuraavasti:

apt-get install dovecot-antispam
joe /etc/dovecot/conf.d/90-plugin.conf
joe /usr/local/sbin/sa-learn-pipe
chmod +x /usr/local/sbin/sa-learn-pipe joe /etc/dovecot/conf.d/20-imap.conf
service dovecot restart

/etc/dovecot/conf.d/90-plugin.conf: (lisää rivit)
plugin {
# dovecot-antispam
antispam_backend = pipe
antispam_trash = trash;Trash;Deleted Items;Deleted Messages;Roskakori;roskakori
antispam_spam = Junk;SPAM;spam;junk
antispam_pipe_program = /usr/local/sbin/sa-learn-pipe
antispam_pipe_program_spam_arg = --spam
antispam_pipe_program_notspam_arg = --ham
antispam_pipe_tmpdir = /tmp
}

/usr/local/sbin/sa-learn-pipe: (uusi tiedosto)
#!/bin/bash
out=$(sa-learn "$@" - 2>&1)
ret=$?
if [ $ret -gt 0 ]; then
logger -p mail.err -i -t "${0##*/}" "${1//[^a-z]/}: $out"
fi
exit $ret

(Tähän on monta vaihtoehtoista lähestymistapaa, myöhemmin vaihdoin hieman erilaiseen toteutukseen.)

/etc/dovecot/conf.d/20-imap.conf: (uusi rivi)
protocol imap {
mail_plugins = antispam
}

liima, purkka, sinitarra...teippi!

System health

Kun olin aikani ihmetellyt melko korkeita reitittimen lämpöjä, tuli mieleeni kirjoitella siitä, miten asiat tehdään pieleen ihan huomaamatta. Tätä tapahtuu niin amatöörien kuin ammattilaistenkin keskuudessa.
Onneksi yhä vähemmän ammattilaisten keskuudessa. Sitä varten on niitä laatustandardeja.
Toki korjasin ennen kirjoittelua sen pieleen menneen osuuden; lisäsin parempaa teippiä ja mekaanisen varmistuksen, josta et halua tietää sen enempää.

Olen hommannut runkoreitittimeni aikoinaan "asiakkaan omaksi palomuuriksi" viileään konesaliin, jossa asiakaskohtainen uplink oli 100M. Kuitenkin sillä idealla, että se aikanaan siirtyy kotiin "eläkkeelle".
100M nopeusluokalle se on ylijäreä tuulettimeton malli, jonka voi alikellottaa sopivasti ja saavuttaa siten hyvän tasapainon.

Aikaa kului ja lopulta laite pääsi "eläkkeelle" kotikäyttöön. Sitä ostaessa en osannut kuin unelmoida tästä nykyisestä kodin verkkoympäristöstä. Unelmat kävivät kuitenkin toteen ja WAN on Gigabit Ethernet, jossa myöskin 1G down/100M up nopeusluokan internet-liittymä. Tulevaisuuden optiona myös isommat nopeusluokat, mutta todetusti RB1200 ei jaksa tarvittavilla verkkokonfiguraatioilla yli 1Gbit/s reititystä.

Pitkän alustuksen jälkeen itse asiaan eli siihen viritelmään, joka petti.
Tuulettimeton verkkolaite kaipasi ulkoista viilennystä. Kotiympäristössä se ei kuitenkaan ole tasalämpöisessä viileässä tilassa, vaan räkkiasennettu eteisen nurkassa olevaan kaappiin. Niinpä asensin sen välittömään läheisyyteen pienen tuulettimen, jonka virtalähteeksi valikoitui sopivasti jännitettä madaltava kiinalainen perusvirtalähde (jostain ZyXELin verkkolaitteesta ylijäämää). Tällaisen teholähteen ja tuulettimen liittimet eivät tietenkään ole samasta maailmasta, joten tuulettimen johdot tulivat kiinnitetyiksi teippiavusteisesti.

Useimmille teipeille on ominaista, että niiden liima menettää adheesionsa noin 60°C lämpötiloissa. Tuossa laitekaapissa lämpötilat saattavat nousta hetkellisesti yli 50°C. Ja vähemmän yllättäen teippiliitos oli rakoillut irti.

Onneksi nuo laitteet on tehty toimimaan myös korkeissa ympäristön lämpötiloissa. Suorituskyky kuitenkin kärsii lämpöjen noustessa.
Ulkoisella tuulettimella lämmöt pysyvät alle 50°C normaalin rasituksen alaisena.
Ilman tuuletinta CPU-lämpö nousee 70°C tuntumaan jo käynnistäessä laitteen.

Seuraavaksi hankintalistalle voisi päätyä tuoreempi runkoreititin, jossa kapasiteetti riittää moninkertaiseen määrään liikennettä ja palomuurisääntöjä. Niin voisi sitten taas asettaa sen vajaateholle käyttöön ja lämmötkään ei pääsisi muodostumaan ongelmaksi.
Mutta mañana, mañana. Uusi teippi pitänee tuon kasassa toistaiseksi. ;)