ylläpitäjän sivunootit

HUOM! Sivustoni on muuttanut. Nämä ovat vanhat sivuni.

Tuoreimmat sivuni ovat muuttaneet tänne! <-- linkki

Poistan täältä sisältöä sitä mukaa kuin olen ehtinyt siirtää sen uusille sivuilleni.

IPv4-osoitteet ovat loppuneet (viimein)

Julkaisuaika: 26.11.2019 klo 09:20

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!

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

Julkaisuaika: 10.11.2019 klo 19:13

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.

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

Julkaisuaika: 26.06.2019 klo 14:26

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)

Julkaisuaika: 23.06.2019 klo 10:06

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.

Julkaisuaika: 17.06.2019 klo 20:03

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 (spam-suodon parantelua)

Julkaisuaika: 08.06.2019 klo 23:56

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!

Julkaisuaika: 04.06.2019 klo 01:53 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. ;)