ylläpitäjän sivunootit

Muiden harrastuksien ohessa teen myös ylläpitoa verkkopalveluille. Lähinnä sitä teknistä puolta.
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. 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ä usein pieni budjetti, mutta ajoittain astetta suurempi tarve.
Toisinaan oma roolini on ollut lähinnä konsultin tasoa.

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 ja palveluita verkossa. Alkukesästä 2019 alkaen tuo tarve meni kuitenkin ohi, kun hankin uutta vuokrapalvelinrautaa konesaliin riittävällä levytilalla.

Kodin ulkopuolisen infran sydämenä toimii Hetzner EX42 juuripalvelin (sijainti "Helsinki" eli Tuusulassa).
Lisäksi epäkaupalliseen käyttöön pieni FAR ry. jäsenvirtuaalipalvelin ja slave DNS.
Tarvittaessa kapasiteettia kasvatetaan lisäämällä tarpeeseen soveltuvia fyysisiä tai virtuaalisia laitteita verkkoon.
Kodin sisäpuolista infraa varten on RouterBOARD RB1200 & RB450G, Ubiquiti AmpliFi HD WiFi Mesh-reititin ja ProCurve 1800-8G.
Kotiverkossani on myös QNAP TS-459 Pro+ levypalvelin (2x 1GE NIC, 4 levyä, 1.8TB RAID 10), jota käytetään myös palvelinten varmuuskopiointiin.

Tämä kotisivujeni alaosasto käsittelee blogimaisesti ylläpitäjän roolissa kokemiani juttuja.

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
add action=drop arp-src-address=!192.168.1.1/32 chain=input in-interface=eth2-mobile mac-protocol=arp
add action=drop arp-src-address=!192.168.1.1/32 chain=forward in-interface=eth2-mobile mac-protocol=arp out-bridge=br-lan
(HUOM! Suodatus aina sillä perusteella, että !192.168.1.1/32 eli pudotus jos ei ole tämä osoite, joka on aina MR1100 oma LAN-osoite. Ja kaksi viimeistä eli in-interface=eth2-mobile perusteella suodatus ovat todennäköisesti tarpeettomia, mutta varmuuden vuoksi asetetaan suoto molempiin suuntiin; ARP-kyselyt sillasta, joissa vastaanottaja ei ole MR1100, sekä ARP-mainostukset MR1100:lta ellei se ole lähettäjän osoitteena.)

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 RouterBOARDeissa olleet väärät ND (Neighbor Discovery) asetukset. Toimivin setup on tässä tapauksessa yksinkertaisesti sammuttaa koko ND-ominaisuus turhana.

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

/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. ;)

[=]