Už nějakou dobu je rok 2020 a všechno je čím dál digitálnější, jen asi frčí víc a víc psát věci pokudmožno basic. To samozřejmě napořád nevydrží, ale co rozhodně vydrží, bude neutuchající zájem o co nejsnáze proveditelná komplexní řešení custom situací, na které obyčejný čumáček asi jen tak nestačí. A že jich poslední dobou je — tedy alespoň u té nové generace.
Třeba teď hodně zájmu vzbuzuje využití VPN na tisíc způsobů a kdo si vzpomene, celé to šlo kdysi propojit tak, aby i telefony na cestách měly pohodový přístup jak do lokální sítě, tak automatickou podporu pro Tor bez žádných čárů a márů. Jak je tam vidět na ukázce konfigurace OpenVPN klienta, pořád tam platí jedna zajímavá poučka — pokud je to možné, všechno složité by se mělo konfigurovat na jednom místě (serveru) a všechno ostatní (klienti) by se měli tomuto nastavení pak dynamicky přizpůsobit. Tehdejší strategií pro přímou podporu Toru bylo podmíněné přesměrování provozu klienta při požadavku na .onion adresu do vnitřní proxy skrz DHCPkem podstrčený PAC soubor někde na lokální síti. Tuhle filosofii navíc není nutné nijak měnit, je to docela elegantní.
No a dneska se stalo něco zajímavého, co tu vzpomínku vyvolalo. Znáš to, si tak sedím a kutám kutám, když tu náhle se nedaří debugovat jeden darkweb s našimi USTAFáckými vzpomínkami. Stručně řečeno, protože jsem lenochod, dost podobně jako ve VPN mi to běží i na LANě, kdy nepotřebuji na ověřené a důvěryhodné sajty používat speciálně vycraftovaný Tor browser a stačí mi normální Firefox, který je podmíněně směrovaný na proxy běžící kdesi na lokálním serveru. Tor browser je velká věc, dneska je už hrozně elegantní, má jednu ikonu a všechno se děje bez vědomí uživatele. Dřív to běželo tak, že byl browser, k němu bundle Vidalia a celé to bylo takhle nakonfigurované. Vidalia integrovala Tor a k němu pak ještě proxy pro prohlížeč, kterou byla Polipo. A tohle bylo hrozně fér, protože to byla konečně hodně lehoučká proxy, u které přece nebylo potřeba žádné cachování, prostě jen spojení na odpovídající upstream a jelo to. No a proto jí nic nebránilo běžet i centrálně pro LAN.
Web je neustále ve vývinu a téměř všechno je dneska HTTP/2 a vlastně se na první pohled ani nedá poznat, v čem může být problém, když prohlížeč přes Polipo jen suše zahlásí 502 s tím, že vzdálený server asi shodil spojení a nic víc. Ono v nastavení Apache pro tu skrytou webovku bylo napůl zakomentované nějaké šašení s protokoly a na sílu prosazované HTTP/1.1, ale nějak to nejelo. No a až pak curl zahlásil, že vlastně z dálky nepřišla žádná data, kdežto při přímém požadavku na nějaký soubor přišla data všechna. Zvláštní, žejo. No a pak si tak googluji a najednou Jéžovy kule, vývoj Polipa byl ukončený v roce 2014, zatímco moje nasazení začínalo někdy o rok později a dnešní pohled do repozitáře vskutku nehlásil žádnou novou kandidátskou verzi. Takže kdyby byla chyba tady, už to žádný update neopraví, ale je rozhodně dobré vědět, že to tu dovedlo žít i šest let po smrti bez jakéhokoliv rušení.
Takže přišel čas na hledání náhrady. Základní vlastnost — že to musí být lehké a nemusí cachovat — v pohodě splňuje Privoxy, která je prosazovaná v mnoha jiných projektech, jen se v ní nepíše vyloženě o Toru, ale zase třeba hodně o blokování reklam. Plán nasazení počítal s jedinou myšlenkou — vymění se proxy a úplně všechna ostatní konfigurace zůstane úplně stejná, tedy použije se HTTP proxy na TCP 8123 a jako upstream izolovaný Tor v SOCKS5. Jenže hopla! Takhle přímočaré nastavení Privoxy není a hodně lidí na fórech bude tvrdit, že je potřeba přímo v torrc otevřít HTTP podporu, nejčastěji na čísle 9080. Opak je ale pravdou, propojení na SOCKS5 upstream je popsaný přímo v sebedokumentaci jako forward-socks5t / 127.0.0.1:9050 ., takže pak stačí už jen nastavit odpovídající interface pro činnost listen-address [LAN IP]:8123 a je vymalováno, vše by mělo jet jako dřív. Jako bonus pak Privoxy ukazuje klientům o něco podrobnější hlášení o stavu, než to jak to dělala Polipo.
Co se týče samotné chyby na tom darkwebu, z nějakého důvodu byl zkrátka jen poškozený handler pro PHP. Ten stroj je logicky starý a instaloval se na něm Debian někdy v létě 2011, takže si prošel všemi těmi divotvornými aktualizacemi a z nějakého důvodu, ač měl balíkově meta-nainstalované poslední PHP 7.3, pořád tam uvnitř drželo PHP 5, ba co víc, při odstranění PHP 5 nebylo provedeno automatické zkonfugurování Apache. Což tedy znamenalo ručně začarovat a2dismod php5, a2enmod php7.3, reload a jelo to zase všechno, jak mělo. Teď je teda otázka, co se stane po automatické aktualizaci s novým PHP 7 a vyššími, ale vzhledem k tomu, že to je metabalík, tak budeme doufat, že nic a vše pojede. Tak asi tolik pro dnešek ode mě na téma pacičkové výměny proxy, snad i ty dva řádky byly dost basic.