Dne 21. dubna 2026 v 17:28 jsem zaznamenal výpadek mé hlavní konektivity. To znamenalo výpadek všech webů, emailového serveru, hlavního autoritativního DNS serveru i většiny dalších služeb. Ze začátku jsem očekával, že výpadek nebude trvat dlouho, ale po hodině mi bylo jasné, že to nejspíš potrvá déle.
Záložní konektivita
Jelikož jsem se s menšími výpadky konektivity již v minulosti setkal, tak jsem se před nějakou dobou rozhodl zařídit záložní konektivitu. V lokalitě, kde jsou servery provozovány, bohužel není příliš jiných možností, než současná hlavní optická konektivita.
Mobilní data jako záložní konektivita
Po zvážení různých možností z hlediska jednoduchosti instalace, ceny provozu i zřízení jsem se nakonec rozhodl pro záložní konektivitu ve formě předplacené SIM karty s kreditem od virtuálního operátora Kaktus.
Pro velmi malé datové přenosy, které jsou v době funkčnosti hlavní konektivity očekávané, je výhodné využívat kredit, kde 1 MB stojí 1 Kč. Pro výpadky se poté hodí předplacený tarif NEŘEŠTO za 350 Kč, který nabízí 10 GB přenosu plnou rychlostí poté neomezená data o rychlosti 2 Mb/s. Celkově tak tato záložní konektivita v případě jejího nevyužití vyjde na 100-200 Kč ročně a případně 350 Kč za měsíc, kdy bude aktivně využívána.
Hardware
Co se hardwaru týče, rozhodl jsem se zvolit USB LTE modem D-Link DWM-222W, který jsem v akci pořídil za 700 Kč. Tento modem se chová jako samostatný router s (velice pomalým, ale funčním) webovým rozhraním, který přes USB poskytuje síťové rozhraní.
Modem jsem se rozhodl připojit do Raspberry Pi 3B+, které již v infrastruktuře provozuji z jiných důvodů.
Připojení přes mobilní data?
Nejzásadnější však bylo vymyslet, jak se přes záložní konektivitu připojit na dané Raspberry Pi. Jednou ze zvažovaných možností bylo připojení na vzdálenou VPN, ale tuto možnost jsem zavrhnul, jelikož by záložní konektivita byla závislá na nějaké další službě, která nemusí být dostupná. Zvážil jsem proto raději využití IPv6 adres, které relativně nově Kaktus (resp. T-Mobile) na své síti nabízí a modem je podporuje.
Před tím ale bylo potřeba potvrdit, že operátor ani modem neblokují přímé připojení na adresy z přiděleného IPv6 rozsahu. Po krátkém testu po připojení do notebooku se mi povedlo pomocí SSH připojit přes přidělenou adresu, takže experiment byl úspěšný a IPv6 budu moci k připojení používat.
Dalším problémem, na který jsem však narazil, byl fakt, že přidělený IPv6 rozsah se po každém restartu modemu změní. To naštěstí nebyl problém, který by jednoduchý bash script odesílající IPv6 adresu notifikací přes službu ntfy.sh snadno nevyřešil. Praktičtější by možná bylo ukládání IPv6 adresy do DNS, na což nejspíš přejdu někdy v budoucnosti.
Jak to tedy funguje?
Na Raspberry se tedy můžu jednoduše připojit přes SSH s autentizací pomocí SSH klíče. Raspberry je tak připojené do dvou sítí, jak do lokální, tak do sítě USB modemu. Pomocí tunelování přes SSH se tak jednoduše můžu připojit ke službám, které v lokální síti běží, i když bude hlavní konektivita nefunkční.
Výpadek 21. dubna 2026
První příležitost k vyzkoušení záložního připojení se naskytla 21. dubna v 17:28, kdy mě na výpadek upozornil monitorovací systém. Poté, co výpadek již trval hodinu, jsem se rozhodl přejít na záložní konektivitu a poprvé ji otestovat v praxi. Aktivoval jsem tak tarif a dal se do přenastavování.
Nejdůležitější bylo zprovoznit přístup k Internetu z lokální sítě. To šlo snadno udělat pomocí statické routy na hlavním routeru, která přesměrovala rozsahy 0.0.0.0/0 a ::/0 na adresu Raspberry Pi, které jsem povolením IP forwardingu a nastavením NATu proměnil v novou bránu do Internetu.
Obnova provozovaných služeb
Díky funkčnímu připojení k Internetu bylo poté možné obnovit interní spojení se vzdálenými částmi sítě přes Wireguard. Poté bylo potřeba upravit konfiguraci nginx a dalších provozovaných služeb, a aktivovat listenery s PROXY protokolem. Nakonec bylo možné zprovoznit na serveru v ve vzdálené části sítě zprovoznit HAProxy a nechat data téct přes interní Wireguard spojení.
Problém jménem DNS
Provozuji své 4 na sobě nezávislé autoritativní DNS servery, které v průběhu celého výpadku odbavovaly veškeré požadavky a zajistili tím, že DNS překlady domén stále fungovaly bez problémů.
Větší problém ale nastal ihned, když bylo potřeba záznamy změnit, protože služby nově běžely na jiných IP adresách. Jelikož jediný master DNS server byl právě zasažený výpadkem, tak nebylo možné žádné záznamy aktualizovat, jelikož se změna kvůli nefunkční veřejné IP adrese masteru nebude propagována dál.
Každý z autoritativních serverů je poháněný projektem Knot DNS a master je naštěstí odlišný pouze konfigurací a tím, že má uložené klíče pro podpisy DNSSEC zón. Rozhodl jsem se proto učinit masterem jiný server, kterému tak stačilo jen nakopírovat zóny a klíče, a upravit adresy ve slave serverech.
Pak už bylo možné příslušné záznamy aktualizovat a zprovoznit tak nejen všechny webové stránky.
Emaily...
Posledním větším problémem byl emailový server, který provozuji. Mám sice záložní emailový server, který přijímá poštu v případě nedostupnosti toho prvního, ale počítá se vždy s tím, že výpadek bude krátký a hlavnímu serveru se emaily doručí, až bude opět dostupný na své veřejné IP adrese.
Výpadek ale může trvat libovolně dlouho, takže bylo nutné vymyslet nějaké lepší řešení, aby bylo možné alespoň přijímat nové emaily. Rozhodl jsem se proto za HAProxy dát také SMTP a IMAP porty, aby bylo možné doručit jak nové emaily, tak ty ze záložního serveru.
Odesílání emailů jsem se rozhodl oželet, jelikož by jeho zprovoznění zahrnovalo migraci emailového serveru na jiný stroj a jeho následnou rekonfiguraci, aby fungoval v novém prostředí. Do budoucna by proto bylo dobré připravit možnost odesílání emailů i ze záložního emailového serveru.
Závěr
Výpadek hlavní konektivity byl naštěstí vyřešen následující den ráno, takže poté bylo možné vrátit infrastrukturu zpět do původního stavu.
Potěšilo mě však, že se mé zamýšlené řešení v podobně záložní LTE konektivity osvědčilo a bylo do jisté míry použitelné. Překvapením pro mě bylo, že za celou dobu běhu záložní konektivity, tedy přibližně za 10 hodin, bylo vyčerpáno pouze 3,74 GB mobilního internetu. Odezva nebyla nejhorší ani nejlepší a pohybovala se v rozmezí 30-100 ms.
Díky tomuto výpadku a v rámci něj vzniklé dokumentace tak bude možné rychleji reagovat na případné budoucí výpadky. Byla také zjištěna slabá místa v infrastruktuře, na kterých bude do budoucna potřeba více zapracovat.