Ondřej Caletka: Pokročilejší síťování v Linuxu
V Linuxu pro konfiguraci sítě existují zastaralé nástroje, které vycházejí z klasických unixů. Používají staré rozhraní a neumožňují využít nové funkce, které jádro má. Jsou zastaralé od roku 1999, kdy byly nahrazeny novými nástroji.
Stále je možné je pro některé činnosti používat, ale při složitějších konfiguracích už s nimi nevystačíme. Místo ifconfig, route, netstat a brctl bychom dnes měli používat nástroje z balíčku iproute2: ip, ip route, ss a ip link.
Všechna nastavení použitím těchto nástrojů jsou neperzistentní a nepřežijí restart operačního systému. Zajištění toho, aby se vše nastavilo i po restartu, si řeší každá distribuce po svém.
Samotné nástroje jsou ale napříč distribucemi stejné. Neexistuje také způsob, jak jednoduše resetovat celé nastavení sítě. Nejjednodušší je restartovat celý operační systém.
Hlavním nástrojem pro konfiguraci sítě je dnes ip, který umožňuje nastavit vše podstatné od IP adres na rozhraní až po routování. V nejjednodušší případě je potřeba zapnout rozhraní, přidělit mu adresu s maskou, nastavit výchozí bránu a do souboru /etc/resolv.conf nastavit DNS resolver. DNS stojí mimo jádro Linuxu, které o něm prakticky nic neví. Je to záležitost uživatelského prostoru, konkrétně knihovny glibc.
V moderních distribucích existuje démon systemd-resolved, který umožňuje směrovat požadavky na různé servery podle dotazovaného jména. To se hodí v případě, že používáte VPN a chcete být připojeni do více sítí zároveň. Pokud má každá jiný nameserver s různými IP rozsahy, je to jinak dost složitý problém.
Složitější situace nastává, pokud jsme připojeni do více sítí zároveň, například pomocí Ethernetu a Wi-Fi. Pokud potřebujeme komunikovat s různými sousedy, obvykle ještě problém nenastává. Horší je, když v obou sítích je router a obě se nám snaží vnutit svou výchozí bránu. Ta ovšem z definice může být jen jedna.
Můžeme ovšem nastavit, který provoz chceme odbavovat ze kterého rozhraní. V nejjednodušší konfiguraci rozlišujeme podle cílové IP adresy.
Složitější pravidla umožňuje definovat takzvaný policy routing, který dovoluje vytvořit víc směrovacích tabulek. Tato pravidla pak pokaždé vybírají, která tabulka bude použita.
Tabulky lze pojmenovat čísly nebo jmény v /etc/iproute2/rt_tables. Pravidla pak přidáváme pomocí ip rule, které říká, že když používáme konkrétní adresu, máme použít konkrétní routovací tabulku. Pokud je v ní výchozí brána, dojde rovnou k odbavení provozu.
V systému jsou základní směrovací tabulky local, main a default.
Linuxové jádro dovoluje používat Virtual Routing and Forwarding (VRF), které umožňuje vytvářet virtuální síťová rozhraní, do kterých se zavěsí jednotlivá sub-rozhraní a tím je možné mít část rozhraní s jednou směrovací tabulkou a ostatní s jinou. Pro IP provoz to pak vypadá jako dva nezávislé počítače. Hodí se to v situaci, kdy jste připojeni do více sítí se stejnými rozsahy.
Moderní jádra nabízejí také network namespaces, které jsou základními stavebními kameny pro linuxové kontejnery, ale lze je použít i samostatně. Kteroukoliv síťovou kartu je možné přestěhovat do vlastního namespace a ona zdánlivě zmizí ze systému. Do toho namespace je možné vlézt a tam to vypadá stejně jako ve zbytku systému, ale je tu dostupné jen to jedno síťové rozhraní.
Je tak možné postavit například oddělený router nebo třeba měřící systém, který sleduje kvalitu Wi-Fi, ale zároveň ji reportuje po Ethernetu. Nechcete mít úplně oddělené virtuály, ale potřebujete oddělit routovací tabulky.
Při konfigurace sítě se často zapomíná na to, že směrování je ve výchozím stavu vypnuto. Dokud to nezapnete, celá konfigurace může vypadat dobře, ale data neběhají.
Často se také setkáváme s privátními IP adresami, které unikají do internetu. Obvykle když vám vypadne VPN, tak se začne privátní provoz odbavovat výchozí branou.
Řešením je vložit do směrovací tabulky záznam unreachable, který se uplatní jako výchozí a provoz se zahodí už v původní síti.
WireGuard je nový protokol přenášející IP datagramy v UDP zprávách. Existuje velmi efektivní implementace v linuxovém jádře, ale také alternativy napsané v uživatelském prostoru například v Go. Autentizace je velmi podobná SSH, obě strany znají své veřejné klíče a vytvářejí jejich vazbu na IP adresy.
WireGuard umí velmi dobře spolupracovat s existujícími síťovými rozhraními a namespaces.
Radko Krkoš: CESNET PassiveDNS
PassiveDNS umožňuje ukládat historii DNS a pořízení „snímku“ stavu v nějakém čase v minulosti. Data můžeme sbírat před rekurzivním serverem u klientů nebo na druhé straně ve veřejném internetu. Výhodnější je druhá varianta, protože nám to neumožňuje identifikovat konkrétního uživatele.
Lze pak provádět analytiku nad takto pořízenými daty a to buď v reálném čase nebo zpětně ze záznamu.
CESNET si vyvinul řešení na míru s využitím nástrojů PostgreSQL, Python, Flask, Apache, dpkt a dnslib. Data využíváme pro bezpečnostní aplikace a projekty bezpečnostního výzkumu. Samozřejmě chceme data nabízet také komunitě.
Primární přístup je umožněn přes webové rozhraní, kde je možné vyhledávat v databázi a prohledávat stav DNS v minulosti.
Přístup je řečený přes federaci eduID.cz, kde jsou členové akademické sítě, nebo je možné využít přístup přes eduID.cz Hostel či přes MojeID. Takto tam můžete získat přístup, i když nejste členy akademické obce.
Pro přístup není nutné používat webové rozhraní, ale služba má také API, které se hodí pro hromadné zpracování.
Pro sběr dat se používají především rekurzivní DNS servery sdružení CESNET, ze kterých se už nasbíralo 7 miliard záznamů a denně přibývá 80 milionů dalších. V současné době jde asi o 900 GB dat. Připravujeme také sondy na perimetr sítě, které by mohly sbírat DNS provoz. Nevýhodou ale je, že data z rekurzorů mají větší váhu, protože u nich víme, že přišly jako legitimní odpověď na dotaz.
Data zachytávaná mimo rekurzory mohou být generovaná kýmkoliv.
Radek Zajíc: Linux a kontejnery a IPv6
Kontejnery umožňují aplikace uzavřít do vlastního prostoru, kde se virtualizují některé informace aplikaci dodávané. Je to způsob, jak aplikaci izolovat a dát jí k dispozici všechno potřebné, co bude potřebovat ke svému běhu.
Přednáška se zabývala především virtualizací síťových rozhraní v kontejnerech.
U tradičního serveru není potřeba obvykle řešit routování, protože server má jedno síťové rozhraní. Ve světě kontejnerů je potřeba řešit propojení virtuálních síťových karet jednotlivých kontejnerů. Tím se ze serveru stává router, se vším, co k tomu patří. Můžete routovat, nastavovat ACL nebo třeba dělat NAT.
K tomu je ale potřeba spousta podsítí, pokud chceme například jednotlivé kontejnery síťově oddělit. Na složitějším systému se tak můžeme rychle dostat k mnoha tisícům podsítí. IPv4 adresy nejsou a nebudou. Můžete dělat překlad adres a vymačkat z IPv4 světa, co půjde.
Můžeme se ale přesunout do světa, kde je adres dostatek. Na scénu přichází IPv6. Protokol IPv4 je smutný příběh o tom, jak se vyvinul internet.
V typické síti dnes dostaneme přístup do IPv4, ale vedle roste paralelní svět používající IPv6. Tam je adres obrovské množství, takže si můžeme svůj přidělený prefix rozdělit na libovolné další podsítě.
Většina uživatelů ovšem přístup do IPv6 stále nemá, takže musíme nějak řešit přístup z IPv4. Klasickým řešením je dual-stack, ale nechcete udržovat dvě sítě. Zvyšuje to riziko chyby.
Populárním řešením je nasazení dual-stacku jen na okraji sítě, přičemž uvnitř se pak používá jen IPv6. Tohle dnes dělá Facebook, blíží se tomu třeba i LinkedIn.
Pokud naše datacentra nemají IPv6 konektivitu a my se chceme mezi servery propojit, můžeme použít tunelování.
Michal Špaček: Minority Reports
Prohlížeče dříve v různých situacích narazily na problém, ale provozovatel webu se o nich nedozvěděl. Internet Explorer 6 někdy odmítl stránku zobrazit, ale nikomu o tom neřekl.
Dnes je možné použít reportování, kdy se prohlížeč ozve, pokud dojde k potížím. Existuje přibližně desítka různých reportů, které může prohlížeč odeslat na zvolený web.
Content Security Policy je komplikovaný standard, který dovoluje v hlavičkách stránek informovat prohlížeč o tom, odkud může stahovat do stránky obsah. Prohlížeč pak nebude načítat například injektovaný obsah, který by měl stáhnout a třeba spustit z jiné domény.
Součástí hlavičky může být i příkaz report-uri, který určuje, na jakou adresu má být posílán report, pokud se politika poruší. Report se pošle ve formátu JSON a jeho součástí může být i příklad kódu, který nebyl kvůli politice vykonán.
Druhou možností je použití ReportingAPI pomocí direktivy report-to , jejíž výhodou je, že reporty posílá asynchronně a dokáže jich poslat více najednou. V případě přehlcení reportovacího serveru tedy uživatel nic nepozná. Prohlížeč zprávu posílá v jiném procesu, někdy v budoucnu, až má čas.
Je možné posílat tři typy reportů: Crash při pádu prohlížeče, Deprecation při použití zastaralého API, Intervention v případě odmítnutí akce prohlížečem.
Existuje mnoho dalších reportovacích API týkajících se DNS, e-mailové komunikace a dalších. Největším tahounem je v tomto Chrome a další rozhraní přibývají. Další prohlížeče se budou přidávat a Chrome doženou.
Reportování si můžete vyzkoušet na canhas.report, kterou provozuje přímo Michal Špaček.
(Foto: Gabriel Seidl, LinuxDays)
ČLÁNKY DO MAILU