Linuxový router PC – Software (2)


Konfigurace UEFI

Jak již bylo zmíněno v prvním díle, počítač nám po sestavení úspěšně nastartoval do UEFI setupu.

UEFI
UEFI nám ukazuje správné komponenty, což je dalším znakem toho, že bylo vše uděláno správně! :-)

První věc na řadě byla dost nebezpečná, a to sice aktualizace UEFI na nejnovější verzi. Počítač by měl běžet 24/7, a tak by na něm měl být co nejaktuálnější a nejstabilnější software, což platilo právě i pro UEFI. Desky od ASRock mají v sobě utilitu Instant Flash, která nás zachraňuje od šíleností typu flashování přes MS-DOS. Pokud by to ale někomu vyhovovalo více, výrobce takovouto možnost nabízí taky. Stačí nahrát stažený obraz firmwaru na flash disk naformátovaný na FAT32 a Instant Flash už se o všechno ostatní postará sám.

Tak jsem tedy učinil a dal se do aktualizace a doufal jsem, že nevypadne elektrika. To se nestalo, ale nával adrenalinu jsem v sobě pochopitelně měl a ten se umocnil ve chvíli, kdy se aktualizace zasekla na 100% a počítač byl totálně nečinný. Nechal jsem to tak asi 2 hodiny a bezvýsledně, tak jsem s tím, že jsem si desku rozbil, počítač násilně restartoval pomocí reset tlačítka. Naštěstí k rozbití nedošlo a ačkoliv jsem nebyl vyzván k restartu, jak bych měl, tak pouhé doběhnutí aktualizace na 100% očividně stačilo k tomu, aby byla aktualizace dokončena. Mohl jsem tedy začít s nastavením.

V UEFI jsem vypnul co nejvíce věcí, co bych stejně nepoužil – integrovaný zvukový čip, režim spánku, secure boot apod. Integrované GPU jsem přidělil co nejméně sdílené paměti, co mi deska umožňovala, a to sice 64MB. Desktopové prostředí na tento počítač totiž určitě nepřijde a konzole opravdu moc grafického výkonu nepotřebuje. Kdyby šlo nastavit méně (16MB), udělal bych to. Boot order bude mít na prvním místě SSD a CSM/Legacy boot jsem bohužel vypnout nemohl, byť bych ho nepotřeboval, protože v takovém případě deska odmítala bootovat bez připojeného monitoru. Nevím, proč se tak chová, ale je to v tomto způsobu použití zásadní problém a tak mi nic jiného nezbývalo.


Instalace OS

Jako OS jsem vybral Debian (webové stránky, Wikipedie), a to v aktuálně nejnovější verzi 10 (Buster).

Můžete namítat, že jsem mohl zvolit něco, co je na router přímo uzpůsobené, jako např. OpenWrt nebo na FreeBSD založený pfSense. Je to pravda; třeba bych měl méně práce s prvotní konfigurací, nicméně kdybych v budoucnu chtěl na PC navíc provozovat něco ne uplně routerovského, měl bych v takovém případě práce s nastavováním naopak více. Neberte mě špatně – OpenWrt provozuji na jednom routeru také a svůj účel plní velmi dobře. Debian však ve stabilitě oproti těmto distribucím rozhodně nezaostává a mé zkušenosti jsou s ním mezi linuxovými distribucemi asi nejvyšší (provozuji jej jak na PC, tak na notebooku, a to jako primární OS).

Samotná instalace proběhla bez jakýchkoliv problémů a byla zanedlouho hotová. Na disku jsem si vytvořil EFI System Partition a hlavní oddíl mountnutý do kořenové složky, naformátovaný na ext4. V taskselu jsem zvolil pouze skupinu „Standardní systémové nástroje“, protože nic víc zatím nepotřebuji a zbytek si doinstaluji ručně.

Síťové karty rozpoznány
Síťové karty nám Linux rozpoznal. Teď ještě vybrat tu správnou, kde je internet. :-D
Hostname automaticky zjištěno
Toto je jedna z pěkných i užitečných (např. při automatizované instalaci) featur instalátoru Debianu: z DNS si zjistí hostname a automaticky ho předvyplní. :-)
Rozložení oddílů
Rozložení oddlílů na SSD: 150MB pro ESP, zbytek pro systémový oddíl.
První boot se povedl
První boot se povedl a my se můžeme přihlásit! :-)

Vzhledem k tomu, že jsem instaloval netinst verzi Debianu, jsem musel být k síti připojený ještě předtím, než jsem PC nakonfiguroval jako router. PC byl po celou dobu připojen normálně do domácí sítě jako jakékoliv jiné zařízení. Toto jsem nezměnil ani těsně po instalaci, kdy jsem nainstaloval pár balíčků, a to jak z kategorie pomocných nástrojů, tak nepostradatelných síťových služeb typu DHCP a DNS server, abych je měl připravené na později.


Nastavení sítě

Balíčky by byly nachystané, takže jsem mohl počítač odpojit z domácí sítě zpoza NATu a přejít ke konfiguraci sítě tak, aby počítač fungoval jako router a právě zmiňovaný NAT prováděl sám. První na řadu přišel soubor /etc/sysctl.conf, kde jsem změnil pár možností:
net.ipv4.tcp_syncookies=1
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
První z nich povoluje tzv. TCP SYN cookies, které zmírňují účinky potencionálního DoS útoku typu SYN flood. Další dvě možnosti povolují IP forwarding, což je hlavní funkcionalita jádra systému, která umožňuje počítači fungovat jako router.
Dále na řadu přišel soubor /etc/network/interfaces, resp. soubory z /etc/network/interfaces.d/. V prvním zmiňovaném jsem zakomentoval výchozí konfiguraci a do souborů ve složce, jejíž cesta byla druhá zmíněná, jsem zapsal konfiguraci takovou, jakou potřebuji. Prvně jsem nakonfiguroval WAN rozhraní:
auto enp1s0
iface enp1s0 inet static
        address 213.XXX.XXX.XXX
        netmask 255.255.255.XXX
        gateway 213.XXX.XXX.XXX

auto he0
iface he0 inet6 v4tunnel
        autoconf 0
        address 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
        netmask 64
        endpoint 216.66.86.122
        local 213.XXX.XXX.XXX
        ttl 255
        gateway 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
Můj poskytovatel bohužel zatím ještě nezavedl IPv6, takže jsem pro její získání použil 6in4 tunel od Hurricane Electric, který je zdarma, nějakou dobu ho již používám a z vlastních zkušeností vím, že funguje velmi dobře. Brány rozbalující pakety IP protokolu 41 jsou všude po světě, z nichž je jedna v Praze, kterou jsem vzhledem k její síťové blízkosti použil. Nepěkné věci ale o svém poskytovateli za absenci IPv6 rozhodně říkat nebudu, protože mi na druhou stranu poskytuje veřejnou statickou IPv4 adresu přímo v ceně tarifu a navíc po plain Ethernetu, což mi o dost zjednodušší konfiguraci a odemkne další možnosti (vystavovat doma bežící služby do internetu). Nemusím se zároveň otravovat s konfigurací věcí typu PPP nebo DHCP. :-)

Další na řadu přišla konfigurace LAN rozhraní:
auto enp4s0
iface enp4s0 inet static
        address 192.168.144.1
        netmask 255.255.255.0

iface enp4s0 inet6 static
        autoconf 0
        address 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
        netmask 64
Zde to je vcelku přímočaré – statická IPv4 i IPv6; nic víc není potřeba. :-)

S nastavením sítě rovněž úzce souvisí nastavení firewallu. Použil jsem již vestavěný jaderný modul netfilter v kombinaci s userspace nástrojem iptables, respektive ip6tables, tudíž nic speciálního. Základní pravidla jsem napsal do firewallu před připojením k internetu, aby nedošlo k bezprostřednímu ohrožení sítě, ale ideální nastavení firewallu pro každou síť je dobré vyladit při používání. Tak jsem také učinil a po 14 dnech používání mám nadefinováno zhruba 270 pravidel, když sečteme jak pravidla pro IPv4, tak pro IPv6. Myslím si, že v takovémto stavu už tam mnoho děr nebude. :-)


Serverové služby pro domácí síť

Router už routoval, ale to by nám úplně nestačilo, protože bychom například museli nastavovat každému zařízení v síti statickou IP adresu. Na řadu tedy přišly některé kritické i méně kritické síťové služby, které budou sloužit zařízením v domácí síti.

DHCP server

Pro automatické přidělování IPv4 adres souží dosti starý, ale bez problémů dostačující protokol DHCP. Na jeho obsluhu jsem použil celkem široce používaný program, co se týče Linuxových síťových prvků – ISC DHCP server (webové stránky). Ten dělá přesně to, co potřebuji a jeho konfigurace je velmi jednoduchá. Do souboru /etc/dhcp/dhcpd.conf byl mnou připsán následující kus textu:
# nastaveni DHCP pro domaci sit
subnet 192.168.144.0 netmask 255.255.255.0 {
  range 192.168.144.100 192.168.144.254;
  option routers 192.168.144.1;
  option domain-name "lan";
  option domain-name-servers 192.168.144.1;
  option ntp-servers 192.168.144.1;
  default-lease-time 2592000;
  max-lease-time 2592000;
}

# vlozime soubor s definicemi statickych paru MAC + IP adres
include "/etc/dhcp/dhcpd-static.hosts";

# jediny DHCP server na siti
authoritative;
Poté už jen stačilo do souboru /etc/default/isc-dhcp-server nadefinovat, aby server poskytoval služby na LAN rozhraní pro IPv4 (ISC DHCP totiž umí i DHCPv6, ale to nepotřebuji). Do souboru se statickými DHCP záznamy jsem přidal pár domácích zařízení, u kterých bych chtěl, aby měla stále stejnou IP adresu a měl jsem hotovo. Stačilo spustit příkaz systemctl restart isc-dhcp-server a vše běželo! :-)

RA server

IPv4 adresy už se nám přidělují, ale co s IPv6? V IPv6 funguje automatická konfigurace adres jinak. Nejvýraznější roli zde hrají tzv. Router Advertisement (RA) pakety zahrnuté v protokolu NDP (Neighbor Discovery Protocol), jenž zařízením říkají něco jako: „Já jsem v této síti router – vím jak do sítě dovnitř a ze sítě ven. V této síti platí tento prefix (rozsah) IPv6 adres a pokud chceš adresu taky, tak si ji buď vygeneruj sám, nebo si o ní požádej DHCPv6 server.“ (jaká přidělovací metoda bude použita závisí na nastavení RA serveru).

Pro přidělování jsem zvolil první metodu, tedy automatické vygenerování IPv6 adresy, kdy RA server ani nebude mít přehled o tom (a ani jej mít nepotřebuje), jaké zařízení má jakou adresu, kolik jich má či jak často si je mění. Této metodě se říká SLAAC (Stateless Address Autoconfiguration = bezstavová autokonfigurace). Metoda s použitím DHCPv6 serveru by se mi sice líbila víc, protože chci mít přehled o tom, kdo má jakou adresu, protože na některých zařízeních mi běží služby a já chci vědět, kam se mám připojovat, ale použít ji nemůžu, poněvadž ji nepodporuje Android. Pokud se ptáte proč, tak protože Google. U zařízení na které se budu chtít připojovat budu tedy muset používat statické adresy.

Pokud by vás tato problematika zaujala, můžu jedině doporučit přednášku Autokonfigurace IPv6 v lokální síti od Ondřeje Caletky, kde se dozvíte víc.

Teď už tedy k tomu, jak to bude vypadat v mé síti. Použiji program RADVD (Router Advertisement Daemon, webové stránky), jenž je asi nejznámější implementací a pokud stavíte Linuxový router, většinou vám bude doporučován právě tento kus softwaru. Konfigurace není nijak složitá a nachází se v souboru /etc/radvd.conf. Přinejmenším na Debianu 10 ale tento soubor ve výchozím stavu neexistuje a je to příčina, proč služba při prvním (automatickém, ihned po instalaci) pokusu o spuštění vyhodí chybu!
interface enp4s0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 10;
        MaxRtrAdvInterval 90;
        prefix 2001:XXXX:XXXX:XXXX::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        };
        RDNSS 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX {};
        DNSSL lan {};
};
Programu říkáme, že má rozesílat do sítě RA v intervalech od 10 do 90 sekund. Určujeme prefix naší sítě, který je na lince (k zařízením v tomto prefixu je tedy možné se dostat přímo na druhé síťové vrstvě OSI modelu bez použití routeru [default gatewaye] mezi nimi; taková zařízení se budou vzájemně objevovat opět pomocí protokolu NDP, v tomto případě pomocí zpráv Neighbor Solicitation a Neighbor Advertisement) a že si adresy z tohoto prefixu mohou sami vygenerovat, což je právě požadavek pro fungování IPv6 na Androidu. Nakonec do RA paketu přidáme informaci o tom, že v této síti je možné ptát se tohoto routeru na DNS dotazy a o tom, že v této síti platí doména „lan“ prostřednictvím rozšíření RDNSS a DNSSL, uvedených v RFC 8106 či starším RFC 6106. Tyto rozšíření sice neumí Windows 7 a 8.1, ale zbytek autokonfigurace bude fungovat normálně, takže žádný problém. Na těchto OS se akorát bude ve výchozím stavu resolvovat pomocí DNS serveru přidělenému přes DHCP na IPv4.

Rekurzivní DNS server

Referenci na to, že služba DNS serveru bude v síti také existovat, už jste mohli vidět v článku několikrát. Na její poskytování použiji program Unbound (webové stránky), jenž je dobře fungující i prověřenou implementací. To dokazuje i fakt, že jej používá i řada ISP jako DNS rekurzor pro své zákazníky. U mě doma bude rovněž v režimu rekurzivním (tedy že si o DNS záznamy bude žádat přímo autoritativní servery, nikoliv další server v „řetězu“, jak by se dělo v případě forwarding módu). Hlavní konfigurační soubor tohoto programu je /etc/unbound/unbound.conf a mnou doplněná část je zde:
server:
  # spojeni s klientem
  interface: 0.0.0.0
  interface: ::
  access-control: 0.0.0.0/0 refuse
  access-control: 127.0.0.0/8 allow
  access-control: 192.168.144.0/24 allow
  access-control: 192.168.164.0/26 allow
  access-control: ::/0 refuse
  access-control: ::1/128 allow
  access-control: 2001:XXXX:XXXX:XXXX::/64 allow
  access-control: 2001:XXXX:XXXX:XXXX::/64 allow
  do-udp: yes
  do-tcp: yes

  # zlepseni DNSSEC
  harden-glue: yes
  harden-dnssec-stripped: yes
  harden-referral-path: yes
  use-caps-for-id: yes

  # zrychleni odpovedi
  prefetch: yes
  prefetch-key: yes

  # zvyseni soukromi
  hide-identity: yes
  hide-version: yes
  identity: "resolver"

  # vyber IP protokolu
  prefer-ip6: yes

# moznost "vzdalene" kontroly z localhostu
remote-control:
  control-enable: yes
  control-interface: 127.0.0.1
Přístup k serveru povolíme z tohoto počítače, z domácí sítě a nakonec z VPN (o ní zmínka později), aby se serveru neptal nikdo, kdo nemá. Pro zvýšení bezpečnosti je pochopitelně TCP i UDP port 53 zakázán z venku i pomocí firewallu. Následně povolíme několik možností, které zlepší funkčnost DNSSEC validace z hlediska bezpečnostního a dále dvě direktivy, které budou často navštěvované domény automaticky resolvovat bez přímé žádosti nějakého zařízení uvnitř sítě, pokud vyprší platnost záznamu v lokální cachi, což může zmenšit dobu odpovídání. Poté zde máme možnosti, které znemožní zjišťování použitého DNS rekurzoru a jeho verzi zařízením, které se ho můžou jinak na vše ostatní ptát a to, že se při spojování s autoritativními DNS servery bude preferovat spojení po IPv6 (když už ho máme, tak proč ho nepoužívat, že?). Nakonec povolíme soket pro správu DNS serveru za běhu pomocí utility unbound-control z localhostu.

Jestliže jste se ztráceli v některých pojmech, které jsem zde užíval (autoritativní a rekurzivní DNS server apod.), opět existuje na toto téma mnoho přednášek, článků a jiných zdrojů (i v češtině). Můžu sem dát odkaz třeba na tuto přednášku, na tento článek spíše pro začátečníky nebo na tento článek spíše pro pokročilejší.

NTP server

Hiearchická struktura protokolu NTP přímo nabádá k tomu, aby si ten, kdo má tu možnost a znalosti, zprovoznil doma vlastní NTP server a synchronizoval z něho čas koncových stanic. Stejně jsem učinil i já, a to konkrétně pomocí programu OpenNTPd (webové stránky) z projektu OpenBSD, z kterého pocházejí i jiné známé serverové démony, jako například OpenSSH. Tyto programy mají nejméně jednu věc společnou – velmi jednoduchou konfiguraci a jinak tomu nebylo ani zde, což je také důvod, proč jsem si nezvolil třeba referenční implemetaci ntpd. Ta má mnoho možností, které nepotřebuji – porovnejte manuálové stránky obou programů a uvidíte sami. Navíc má mnou vybraná implementace ješte jednu „killer feature“ zvanou constraints, ale o té až později. Konfiguraci má tento program v /etc/openntpd/ntpd.conf a ta moje vypadá asi takto:
# bud dostupny i pro klienty zvenci
listen on 0.0.0.0
listen on ::

# synchonizuj se s timeservery googlu
server 2001:4860:4806::
server 2001:4860:4806:4::
server 2001:4860:4806:8::
server 2001:4860:4806:c::
server 216.239.35.0
server 216.239.35.4
server 216.239.35.8
server 216.239.35.12

# ochrana proti MITM
constraints from "https://www.google.com/"
constraints from "https://ethernetlord.eu/"
constraints from "https://github.com/"
Jako upstream servery budu využívat veřejné časové servery Googlu a nebudu je zadávat jako hostname, ale přímo jako IP adresy. Důvod je takový, že funkčnost DNSSEC závisí na správném čase a kdyby jsem do konfigurace zadal hostname (time.google.com), tak by to platilo i naopak a mohl bych se eventuelně dostat do nepěkného začarovaného kruhu. Použitím IP literálů je možné se tomuto problému vyhonout. Nakonec jsem nastavil tzv. constraints, což je funkce OpenNTPD, která má zajistit, aby potencionální Man-in-the-middle útok na nešifrovaný a neautentizovaný protokol NTP nezpůsobil rozladění hodin (což může mít bezpečností následky, např. při validaci TLS certifikátů). Funguje to tak, že se démon ptá přes zašifrovaný protokol HTTPS webových serverů, které v hlavičkách odpovědi obsahují údaj „Date:“, jenž obsahuje přesný čas a datum (s přesností na sekundy). Pokud se některý z údajů získaný z NTP serverů příliš odlišuje od takto získaného času, je ignorován.

HTTP proxy server

Tady byl trošku oříšek jenom se rozhodnout, jestli jej vůbec mám na síti zprovozňovat. Je přece rok 2020, téměř všechen webový obsah je dynamický a navíc běhá na HTTPS, do kterého se (díky bohu) nedá dívat a tím pádem ho ani cachovat. Nakonec jsem se rozhodl, že ho spustím, ale to jen proto, že po spuštění všech ostatních služeb jsem měl na serveru více jak 1,6GB RAM volné a říkal jsem si, že toto by bylo asi jediné pro mě v rámci možností užitečné využití. Mé konečné rozhodnutí bylo, že službu spustím a použiji k tomu software Squid (webové stránky).

A co že tam hodlám cachovat, když jsem zde před chvílí psal o tom, že dnes téměř nic cachovat nejde? Je zde ještě několik služeb, které běhají po nešifrovaném protokolu HTTP a autenticitu dat zajišťují jinak (elektronickým podepisováním stahovaného obsahu) a zmíním zde tři – Windows Update, správci balíčků v Linuxu (apt, yum, pacman apod.) a Steam. Tyto služby se doma používají a stahuje se takto relativně slušné množství dat a proč nebýt slušný a nesnížit zatížení serverů, ze kterých stahujeme, když můžeme? :-)
Je i dost možné, že jsou nešifrované právě proto, že to otevírá možnost takovéhoto cachování.

Zrychlit prohlížení webu může v dnešní době ve většině případů proxy leda tak, že by se nacahoval požadavek na CRL (Certificate Revocation List) nebo OCSP (Online Certificate Status Protocol) a jiné zařízení/prohlížeč na stejném zařížení si o ten stejný požádal v relativně krátkém časovém intervalu znovu. I to se může stávat. :-)
Teď už k samotné konfiguraci, která je v souboru /etc/squid/squid.conf. Ten má ve výchozím stavu hodně (a to opravdu, asi 7000 řádek celkem) zakomentovaných možností, a tak jsem obsah souboru (po záloze) vymazal a napsal si konfiguraci vlastní, která vypadá asi takto (font dávám malý schválně, aby zápis netáhl až kamsi dolů):
# nastaveni seznamu ACL
acl manager proto cache_object
acl localhost src 127.0.0.0/8

acl localnet src 192.168.144.0/24
acl localnet src 192.168.164.0/26
acl localnet src 2001:XXXX:XXXX:XXXX::/64
acl localnet src 2001:XXXX:XXXX:XXXX::/64

acl localdst dst 213.XXX.XXX.XXX/30
acl localdst dst 0.0.0.0/8
acl localdst dst 10.0.0.0/8
acl localdst dst 100.64.0.0/10
acl localdst dst 127.0.0.0/8
acl localdst dst 169.254.0.0/16
acl localdst dst 172.16.0.0/12
acl localdst dst 192.0.0.0/24
acl localdst dst 192.0.2.0/24
acl localdst dst 192.168.0.0/16
acl localdst dst 198.18.0.0/15
acl localdst dst 198.51.100.0/24
acl localdst dst 203.0.113.0/24
acl localdst dst 224.0.0.0/4
acl localdst dst 240.0.0.0/4
acl localdst dst 255.255.255.255/32
acl localdst dst ::/128
acl localdst dst ::1/128
acl localdst dst ::ffff:0.0.0.0/96
acl localdst dst ::ffff:0:0:0/96
acl localdst dst 64:ff9b::/96
acl localdst dst 100::/64
acl localdst dst 2001:20::/28
acl localdst dst 2001:db8::/32
acl localdst dst fc00::/7
acl localdst dst fe80::/10
acl localdst dst ff00::/8

acl Safe_methods method GET
acl Safe_methods method HEAD
acl Safe_methods method POST

acl Safe_ports port 80
acl Safe_ports port 3128

# aplikace seznamu ACL
http_access deny !Safe_ports
http_access deny !Safe_methods
http_access deny localdst

http_access allow localhost manager
http_access deny manager

http_access allow localhost
http_access allow localnet
http_access deny all

# port bude klasicky squidovsky
http_port 3128

# nektere typy obsahu budeme cachovat vice a naopak mene
refresh_pattern (\.deb|\.rpm)$  1800  50%  43200
refresh_pattern -i (/cgi-bin/|\?) 0  0%  0
refresh_pattern .  0  20%  5400

# velikost cache omezime na 1GB, maximum pro jeden "soubor" na 256MB
cache_mem 1024 MB
maximum_object_size_in_memory 256 MB

# pro jistotu
icon_directory /usr/share/squid/icons
global_internal_static off
short_icon_urls on

# spise pro bezpecnost aneb co nemusi bezet, at nebezi a o cem nikdo nemusi vedet, at nevi
visible_hostname RouterPC
pinger_enable off
udp_incoming_address 127.0.0.2

# nikdo venku nepotrebuje vedet, ze pouzivame proxy
via off
forwarded_for off
follow_x_forwarded_for deny all
request_header_access X-Forwarded-For deny all
request_header_access Via deny all

# pristupy logovat necheme, to by byl hned plny disk
access_log none

# ostatni (vychozi) konfiguraky zde
include /etc/squid/conf.d/*
Dalším oříškem byla distribuce proxy mezi uživatele – buď statické nastavení (je náročné a nevhodné, protože při přenesení do jiné sítě v podstatě přestane fungovat internet, minimálně v případě Windows, kde jsem nepřišel na možnost nastavit proxy pouze pro určitou síť), nebo WPAD (Web Proxy Auto-Discovery Protocol). Třetí, avšak poměrně neetickou možností by bylo zapnutí proxy v transparentním režimu a následné nasměrování provozu na ní pomocí NAT interception v iptables. To je sice nejednodušší na nastavení, ale uživatel si v případě problémů nemá jak proxy sám vypnout v případě problémů a musí si o to říct administrátorovi, který mu udělá výjimku v iptables, plus zde můžou být aplikace, které přes port 80 tahají i jiná data, než HTTP a takové přestanou fungovat (v praxi to dělá ale málokterá, protože jejich návrháři počítají s tím, že se můžou ocitnout v takto „rozbitých“ sítích). Zkusil jsem druhou možnost a funguje to dobře, až na zařízení s Androidem, kde je WPAD ve výchozím stavu vypnutý (tam to ale popravdě nevadí, protože tam není úplně co cachovat).

V každém případě mám připravený skript pro vypnutí celé proxy, kdyby došlo k problémům. S proxy servery byly problémy vždycky a jestliže na nějaký přijdu, okamžitě „letí pryč“. Pro funkčnost sítě tato proxy v žádném případě nutná není a dělám to vše jen proto, že mám tu možnost. :-)


„Veřejné“ serverové služby

Tímto titulkem nechcí říct, že jsou to služby, které by mohl používat každý – míním tím pouze to, že budou dostupné z internetu přes veřejnou IP adresu s otevřeným přístupem na firewallu tak, abych se k nim mohl připojit i z venčí a nebudou sloužit pouze ve vniřní síti, což byl případ předchozích zmiňovaných.

SSH server

Asi nikoho nepřekvapí, že nechci mít stále k routeru připojený monitor a klávesnici, ale budu se pro změnu nastavení přes terminál, přenos souborů apod. připojovat vzdáleně a to nejen z vnitřní sítě, ale i z internetu. Řešení možných problémů či údržba díky tomu nebude omezená na mojí přítomnost doma. Bezpečnou a velmi známou volbou je zde protokol SSH (Secure Shell). Použitou implementaci byste v tomto případě byste asi uhádli – OpenSSH (webové stránky). Konfiguraci zde nebudu rozpitvávat úplně do podrobna (mnoho věcí jsem tam popravdě ani neměnil – výchozí nastavení je dobré) a dám sem jen malý kousek, u kterého si myslím, že za to stojí. V tomto útržku, nacházejícím se v souboru /etc/ssh/sshd_config, povoluji pouze nejsilnější aspekty šifrování:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
CASignatureAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
HostbasedAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

VPN server

Terminál není jediná věc, kterou chcí mít pro případ potřeby zpřístupněnou zvenčí. Někdy třeba budu potřebovat něco vzdáleně vytisknout, připojit se na FTP, co mi běží na hlavním počítači nebo něco úplně jiného. Na to není lepší lék než si zprovoznit síťové tunelování na třetí síťové vrstvě (šlo by to i na L2, pokud bych chtěl :-)). Nejlepší softwarovou volbou pro mě byla OpenVPN (Wikipedie) – je bezpečný co se týče úrovně šifrování, relativně jednoduchý na nastavení, a to jak na serveru, tak na klientovi a funguje (nikoliv ale nativně) i třeba z Windows, kdyby bylo potřeba. Další volbou, kdyby se mi OpenVPN nezamlouvala, by byl relativně nový projekt WireGuard, nedávno zahrnutý do mainlinu Linuxového jádra (verze 5.6). Konfigurace je v mém případě v souboru /etc/openvpn/server.conf (název souboru si můžete libovolně vybrat, poté ho akorát specifikujete za zavináč do názvu systemd služby) a u mě vypadá asi takto:
multihome
port 1194
proto udp6
dev tun
ca /etc/ssl/ovpn/ca.crt
cert /etc/ssl/ovpn/srv.crt
key /etc/ssl/ovpn/srv.key
dh /etc/ssl/ovpn/dh.pem
topology subnet
server 192.168.164.0 255.255.255.192
server-ipv6 2001:XXXX:XXXX:XXXX::/64
ifconfig-pool-persist /etc/openvpn/temp/ipp.txt
push "dhcp-option DNS 2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX"
push "dhcp-option DNS 192.168.164.1"
push "dhcp-option NTP 192.168.164.1"
client-to-client
keepalive 1 30
tls-auth /etc/ssl/ovpn/ta.key 0
key-direction 0
cipher AES-256-GCM
auth SHA512
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/temp/status.log
log-append /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1

Webový server

WWW je dnes nejpoužívanější službou internetu, a tak na routeru bude taky. Koneckonců se dá dobře používat jak z telefonu, tak z počítače a tudíž může být užitečná nejen pro domácí síť, ale i pro vnější použití, například přes mobilní data. Jako software zde zvolím dobře známý a stále asi nejpoužívanější Apache HTTPd (webové stránky).

Na webovém serveru ale nebudou hostovány klasické webové stránky, jaké vidíte zde, ale spíše takové „informační centrum“ a osobní cloud, jenž jsem si naprogramoval již před nějakou dobou sám a celkem aktivně jej stále vylepšuji. Celý obsah serveru bude chráněn heslem a bude tedy určen jen těm, kterým to bude povoleno. :-)

Konfiguraci sem dávat nebudu – je totiž poměrně dlouhá a rozdělená do několika souborů, takže by to tu zabíralo dost místa a navíc se dle mého názoru nejedná o nic revolučního. Jen napovím, že se skládá z několika VirtualHostů a jako programovací jazyk pro webové aplikace používám PHP, spojený s Apachem pomocí protokolu FastCGI, ve kterém je napsaný mimo jiné i ten můj dříve zmiňovaný osobní cloud. Přemýšlím i o vyzkoušení Pythonu, protože jsem už mnohokrát slyšel, že se v něm webové aplikace píší dobře, avšak PHP mi zatím stačí, funguje dobře a na věci, které fungují, se nemá sahat, že? :-)


Závěr

Ta nejnáročnější část se mi podařila a veškeré síťové služby, které mají doma i zvenčí být přístupné, běží a slouží svému účelu. :-)

V plánu byla poslední věc – umožnit i ostatním zařízením v domácí síťi přístup. Jak jsem již zmiňoval, tento počítač má pouze jeden Ethernetový port a jen jedno zařízení doma opravdu nemáme. K rozvedení sítě do daších zákoutí mého obydlí použijeme můj dosud domácí router s Wi-Fi od Mikrotiku, který nastavíme tak, aby se choval jako takový lepší switch s Wi-Fi APčkem. Podrobněji o tom ale až v dalším a rovněž posledním díle tohoto seriálu. :-)