Ondřej Caletka: IPv6 tunely pomocí OpenVPN
Ondřej Caletka začal svou přednášku klasickou otázkou: Potřebujeme vůbec IPv6? V 90. letech jsme si mysleli, že nepochybně ano a problém nedostatku adres není možné vyřešit jinak než novým protokolem. Dnes už si nejsme tak jistí, protože jsme sice pět let bez IPv4 adres, ale všechno nám funguje.
Úspěšné služby se přizpůsobily a veškerý globální obsah využívá CDN sítě. Ty výrazně snižují atraktivitu globálního tranzitu a bez potřeby globální komunikace není třeba globální adresace.
Přesto stále existuje dost důvodů, proč IPv6 nasadit.
Připojená zařízení komunikují přímo, cloudová služba je pak možnost a nikoliv povinnost. Uživatelé se probouzejí a zjišťují, že si společně se zařízením musí pořídit i službu. Například ‚chytrý‘ otevírač garážových vrat potřebuje mobilní aplikaci a běžící službu. Jak dlouho to ale bude fungovat?
Navíc se často jedná o službu, za kterou uživatel neplatí a nemá jistotu, že ji výrobce brzy nevypne.
Situace s IPv6 u českých poskytovatelů je velmi tristní. V datacentrech s tím není vůbec žádný problém, firemní zákazníci se taky obvykle k IPv6 dostanou, ale rezidentní zákazníci mají obvykle smůlu. Dobře to má nasazené T-Mobile, špatně O2 a u ostatních xDSL poskytovatelů není nasazeno vůbec.
UPC spustilo pilotní provoz, ale dělá to velmi špatně, odebírá veřejné IPv4 adresy a neumožňuje vypnout router v modemu.
Nejhorší situace je ovšem u mobilních operátorů, kdy ani jeden ze tří českých hráčů nemá se zavedením žádné plány. Ondřej parafrázoval absurdní větu náměstka pro telekomunikaci ministerstva průmyslu a obchodu, který původně mluvil o mobilních datech: Chcete-li IPv6 jako v Polsku, odstěhujte se do Polska a kupte si SIM kartu od Orange. Bude vám to fungovat i v roamingu u nás.
V USA jsou už desítky milionů iPhone zcela bez IPv4, ke čtyřkovému internetu se uživatelé dostanou jen pomocí překladu. Je vidět, že když se chce, tak to jde.
Pokud tedy nemáme k dispozici IPv6 konektivitu nativní, zbývá nám možnost pořídit si tunel. Automatizované tunely jsou letitým řešením, které se ovšem postupně opouští. Protokol 6to4 je jednoduchý a bezestavový, ale vyžaduje veřejnou IPv4 adresu a má velmi špatnou implementaci ve Windows. Druhou variantou je protokol Teredo, který je extrémně komplikovaný a většinou nespolehlivý. Moje zkušenost je, že to spíš nefunguje a když už náhodou ano, tak pomalu a nespolehlivě.
Ručně konfigurované tunely jsou stabilnějším řešením a mají pevně definované konce. Spolehlivost je určená jen koncovými body a existují velké množství různých technologií, které je možné použít.
Technicky vzato takové tunely existovaly ještě před IPv6 a říká se jim VPN. Je tedy možné k sestavení tunelu využít například: IPSec, Wireguard, L2TP, PPP-over-X nebo OpenVPN. Já jsem použil právě OpenVPN jako první pokus při vytváření vlastního tunelu.
Pro sestavování tunelů bez veřejné IPv4 adresy existovalo donedávna jediné řešení v podobě služby SixXS, která ale byla 6. června letošního roku ukončena. Protože serverová část byla uzavřená, byla společně se službou pohřbena řada technologií jako TIC, AYIYA a další. Klient Aiccu je sice otevřený, ale bez té zajímavé serverové strany je to stejně k ničemu a oni nemají vůbec zájem kód zveřejnit.
Proto se Ondřej Caletka rozhodl vytvořit vlastní tunelovací službu.
K tomu je potřeba dostatek IPv6 adres, tedy minimálně jeden /64 prefix na uživatele. Zároveň je potřeba jedna IPv4 adresa kvůli spojení s klienty. Běžná situace u VPS je, že vám nabídnou jeden /64 prefix, navíc bez možnosti naroutovat podrozsah. Delegování adres navíc podléhá pravidlům registrace.
Každý držitel příslušné adresy musí být registrován v RIPE Whois databázi a jednou přidělené adresy není už možné znovu pod-přiřadit. Je to logické, když už ty adresy někdo používá, nemůže je používat nikdo další.
Adresy se nakonec našly u vpsFree.cz, které poskytlo také hardware pro server. Máme zatím přiděleno /39 a umíme obsloužit zatím 512 tunelů s rozsahem /48. Můžeme ale kdykoliv přidat další, adres je dost.
OpenVPN má velkou řadu možností a nastavení, protože jde o univerzální nástroj. Snažil jsem se to nastavit tak, aby to bylo jednoduché a nenáročné, vzhledem k tomu, že na druhé straně budou pravděpodobně nějaké jednoduché domácí routery.
Používá se protokol TUN point-to-multipoint s vypnutým šifrováním. K autentizaci se používají certifikáty s platností jeden rok. Motivací je, že by se měl uživatel o svůj tunel starat a alespoň jednou kontaktovat svého poskytovatele a zeptat se ho na nativní IPv6.
Výsledkem je jeden konfigurační soubor, ve kterém má uživatel všechny potřebné údaje. Stačí zapnout OpenVPN na routeru a tunel se rozběhne. Je ještě potřeba si nastavit IPv6 adresy, protože OpenVPN neumí nastavit všechny potřebné adresy.
Podle prvních zkušeností to funguje velmi dobře, zejména s OpenWRT/LEDE nebo Turrisem. Problém je ale u zařízení s velmi malou pamětí, protože OpenVPN potřebuje v routeru dost místa.
Zatím je výkon omezen zhruba na 150 Mbit/s, což je podle Ondřeje Caletky potřeba ještě prozkoumat. Je to zatím jen první pokus, pokud to chcete používat, musíte být ochotni řešit problémy.
Služba je otevřená všem, stačí napsat požadavek na ipv6tun@vpsfree.cz.
Věroš Kaplan: Icinga 2 na steroidech
Icinga 1.x je fork monitorovacího nástroje Nagios, má lepší a pohodlnější webové rozhraní a opravené některé chyby, ale uvnitř je to pořád stejný nástroj. Z hlediska konfiguračních souborů i nástrojů je to pořád stejné.
Přednáška se ale týkala Icinga 2, což je přepsaná verze obsahující spoustu zajímavých novinek. Autoři přepsali například systém šablon (templates), nově je možné například používat vlastní poznámky (proměnné) o vlastnostech jednotlivých serverů či jiných objektů. Můžu pak třeba říct, že na všechny stroje s poznámkou ‚Linux‘ chci aplikovat nějakou službu. Icinga zavrčí a udělá to. Je to velmi rychlé a pohodlné.
Snaha je, aby konfigurace byla co nejmenší a nejčitelnější.
Konfigurace Icingy se postupně přesouvá k deklarativnímu stylu. Popíšu si stroje, co na nich má běžet a Icinga se postará o to, aby všechno správně hlídala.
Proti první verzi Icingy se podle Věroše Kaplana konfigurace výrazně zkracuje. Migrovali jsme síť se 400 stroji a konfigurace se nám zkrátila na čtvrtinu.
Icinga 2 má vlastní API, kterým je možné přistupovat ke konfiguraci celého systému. Můžete zjišťovat stav jednotlivých služeb, sledovat změny nebo spouštět akce. Pomocí REST API se můžete zeptat na stav služby a vytvořit si třeba dashboard nebo rozsvěcet semafor podle toho, v jaké kondici jsou vaše služby.
V cloudovém prostředí je výhodou možnost přes API přidávat nové stroje nebo plánovat testy. Všechno se pak dá automatizovat, pokud se vám často spouštějí a vypínají servery, můžete si je pohodlně přidávat do monitoringu.
Do webového rozhraní nové Icingy je možné nainstalovat rozšíření Icinga Director, které umí API využít a umožňuje nastavit všechno podstatné. Existují nasazení, kdy správce nainstaluje Icingu a zákazník si pak vše sám nakliká přes webové rozhraní.
Velmi užitečná je možnost distribuovaného monitoringu, kdy se konfigurace umístí do jedné hlavní instalace a ostatní se k ní připojí a stáhne si konfiguraci pro sebe. Můžete pak nainstalovat Icingu přímo na koncové stroje, které pak kontrolují samy sebe a výsledky posílají zpět.
Řeší se tím problémy s NRPE a ušetří se mnoho výkonu, protože není potřeba se kvůli každému testu připojovat po síti. Když změním konfiguraci, nemusím pak obcházet všechny stroje a měnit ji tam.
David Karban: MySQL sežere vaše data
David Karban se začal v poslední době hodně zabývat MySQL, což podle svých slov neměl dělat, protože ztratil veškeré iluze o dobře fungující databázi. Získal jsem dojem, že MySQL a PHP patří dobře k sobě. PHP se při každé verzi inspiruje jiným jazykem a je nekonzistentní a MySQL se svým syndromem…
Podle Karbana mají vývojáři dojem, že pokud je něco zdokumentované, je to vždy v pořádku. Existují případy, kdy se chyba nedá opravit a jen se přidá do dokumentace. To můžete udělat, ale neměli byste to dělat tak často jako MySQL.
Příkladem je řazení nově vytvořených indexů. Když specifikujete, že má být index řazen sestupně, MySQL vám vytvoří vzestupný index. Ale je to v pořádku, protože to je přeci v dokumentaci. Co na tom, že je to kravina?
MySQL obsahuje několik databázových engines, například MyISAM a InnoDB. Problém je, že když některý engine neumí funkci, kterou požadujete, tak se jednoduše její použití ignoruje. MyISAM nechcete používat, neumí třeba cizí klíče. Ale při vytváření se tváří, že je vytváří. Ovšem je to správně dokumentováno.
MySQL ale může i velmi jednoduše ztratit data. Pokud například do tabulky vkládáme špatný datový typ, databáze to nepovažuje za chybu a zobrazí jen varování. Pokusí se zkonvertovat data na správný datový typ a uložit. Obvykle to dopadne špatně a data tam nedoputují. Ale databáze se tváří, že všechno proběhlo správně.
Existuje možnost přepnout režim na tradiční, což vlastně znamená, že se místo varování zobrazí chyba. Od MySQL 5.7 je to výchozí stav, což ale také znamená, že při aktualizaci vám můžou přestat některé věci fungovat.
MariaDB jde podle Karbana vlastním směrem, takže je potřeba sledovat změny zvlášť. Zkoušel jsem to ve verzi 10, kde to funguje také tímto způsobem. Předpokládám ale, že také nebudou mít zájem, aby neničili lidem data.
Radek Zajíc: Uživatelsky přívětivé šifrování disku
Šifrování je dnes naprosto běžné, na webu dnes vlastně automaticky šifruje každý. Šifrování disku už ale tak rozšířené není. Podporují to všechny platformy, ve firmách je to například velmi časté.
Běžné je, že uživatel musí při startu počítače zadat heslo k rozšifrování disku. Nešlo by to jinak, aby u toho uživatel nemusel sedět?
V macOS nabootuje minimalistická přihlašovací obrazovka a uživatel se musí přihlásit, čímž se mu otevře dešifrovaný disk. Na Windows je od verze Vista k dispozici jiné řešení, které používá čip TPM. Systém si sám zjistí, jestli je TPM přítomný a když ano, umí ho využít.
Výhodou je, že vše samo funguje jen v tom případě, že nikdo nic na systémovém disku nezměnil. Pokud někdo udělá nějakou úpravu, BitLocker nastartuje v nouzovém režimu a požaduje recovery key.
V Linuxu se pro dešifrování využívá initramfs, do kterého se zadá heslo a pomocí něj se odemkne rootfs a spustí se init. Z toho plyne, že není možné udělat podobné řešení jako na macOS, protože bychom museli mít obrovský ramdisk.
Je možné ovšem jít jinými cestami: přidat položku keyscript do /etc/crypttab, je možné provést odemknutí po síti pomocí SSH nebo je možné mít obfuskovaný klíč například na USB disku. Problém je, že když si někdo dekompiluje initramfs, zjistí, jak klíč používáme a může nám ho ukrást. To nechcete.
Nejlepší variantou je využít TPM podobně jako to dělají Windows. Je to pasivní šifrovací komponenta, které můžete nechat počítat haše a ukládat informace do paměti. On to poslušně udělá.
Používá se tak, že od startu počítače dostává haše veškerého software, který startuje. Ty se řetězí a pokud celý start s neporušeným software, je výsledkem dešifrovací klíč. Zajímavé je, že GNU mělo dlouho odpor k TPM, který padl až v roce 2015.
Existují dvě různé verze, které jsou nekompatibilní. Verze 1.2 se objevila v roce 2006, verze 2.0 je tu od roku 2016. Pro počítače s certifikací Windows 10 je povinný od 28. července 2016.
V Linuxu je z pochopitelných důvodů podporovaná výrazně lépe starší verze, využití nové verze vyžaduje úplně jiné nástroje. Radek Zajíc se dále věnoval staršímu standardu TPM. Najdete je zejména ve starších enterprise noteboocích, typicky třeba v ThinkPadech.
V Linuxu nás zajímá především balík trousers, který obsahuje ovládací utility pro ovládání TPM čipu. Spousta informací se dá vyčíst také přímo z adresáře /sys/class/tpm/tpm0. TPM pak dostává postupně haše všech kroků nutných pro start počítače: kód BIOSu, jeho data, kód MBR, všechny fáze GRUBu, jádra, příkazový řádek jádra a initramdisk. Řetězením toho haše vznikají další haše, pokud je všechno po startu ve správném stavu, umí TPM čip proti heslu vydat dešifrovací klíč.
Před prvním použitím se musí čip vymazat v BIOSu, převzít jeho správu vložením hesla a poté provést inicializační boot systému, při kterém se naměří údaje pro naplnění TPM registrů. Poté už stačí jen mít nainstalované správné nástroje, vygenerovat nový initramfs a upravit konfiguraci GRUBu.
Poté je potřeba rebootovat, aktivovat TPM čip a uložit do něj heslo pro LUKS s využitím uloženého stavu. Bohužel neexistuje příliš funkčních nástrojů pro uložení LUKS hesla v TPM.
Radek Zajíc proto vytvořil vlastní nástroj, kterými je možné pohodlně toto řešení nasadit v Ubuntu.
Pavel Dostál: The Onion Router
Pavel Dostál začal svou přednášku popisem základního principu anonymizační sítě TOR. Kromě běžných veřejných relays serverů existují také neveřejné, kterým se říká bridges. Problém je, že ty veřejné jsou často blokované, takže bridges vám umožní se k TORu dostat.
Je také možné použít takzvané pluggable transports, které dovolují použít další služby pro přístup k síti. Je tak možné provoz dále zamaskovat a připojovat se například z Číny.
TOR má v běžných médiích velmi špatný obraz, protože je zmiňován především v souvislosti s kriminální činností. Nedávno běžela kampaň, ve které byly představovány různé osobnosti, které TOR používají.
Například byl citován Edward Snowden, který říká, že svobodný přístup k internetu je důležitý také pro studium a svobodnou práci.
Velmi užitečnou vlastností TORu jsou takzvané Onion Services, které umožňují provozovat anonymizované služby přímo uvnitř sítě. To dovoluje end-to-end šifrování, whitelisting konkrétních uživatelů a v neposlední řadě je to rychlejší než klasické použití sítě. Provoz neprochází exit nody, kterých je výrazně méně než běžných relay nodů.
Služby je možné využít například pro vlastní SSH, VPN nebo různé veřejné služby. Výhoda je, že můžete mít přes TOR otevřenou cestu do domácí sítě, kde nemáte veřejnou IP adresu.
Řada běžných služeb provozuje také přístup přes TOR, protože jejich uživatelé preferují anonymitu: Facebook, Blockchain, DuckDuckGo a podobně.
ČLÁNKY DO MAILU