Vlákno názorů k článku Router Turris Omnia se šroubovákem (a kleštěmi) v ruce od anonym - Dobrý den, na tvorbě dokumentace, návodů, celkovém zlepšení komunikace...

Dobrý den,
na tvorbě dokumentace, návodů, celkovém zlepšení komunikace a poskytování informací pracujeme. Stejně tak na zjednodušení či "laicizaci" zařízení tak, aby bylo lépe použitelné. Všechno chce čas a lidskou práci, velký úspěch kampaně bereme jako obrovský závazek a vše zlepšujeme co nejrychleji to jde.

Jak sám píšete, je to označené jako dokumentace k Turrisu. Turris Omnia je něco jiného – a mělo by to případně v té dokumentaci být napsané, že se týká i Turris Omnia. Navíc na stránce Turris Omnia na tuhle dokumentaci žádný odkaz není. Takže je docela pochopitelné, že to autor nenašel, není sám.

Na to bude nejlepší použít Query Policies modul v Knot Resolveru - http://knot-resolver.readthedocs.io/en/latest/modules.html#query-policies a možná v případě hodně adres udělat ten feed jako RPZ.

Případně DNS Application Firewall, který nad tím staví více uživatelsky přívětivou vrstvu - http://knot-resolver.readthedocs.io/en/latest/modules.html#dns-application-firewall

Tak s kresd momentalne valcim, resp. s implementaci v Omnii. Hadam ze je tam zatim pripraveny dost jednoucelove, protoze jeho konfigurace je natvrdo vyrabena init scriptem pri jeho startu s jedinou moznosti a sice jestli ma vsechny dotazy forwardovat nebo ne.
Mozna se na nej vykaslu a prehodim to na unbound, anzto je pro mne zatim fakt challenge presvedcit knot aby:
a) nevracel na privatni site akorat SOA "blocked.", coz bylo fakt prekvapko kdyz jsem si Omnii poprve zapl do LAN jako "klienta" kde moje PC bylo az za Omnii (a tedy otazka privatnich adres byla vice nez potrebna). Navic bych potreboval aby se na dotazy mnou jmenovanych zon ptal jineho serveru v LAN a ne providerovych resolveru (proste aby se neptal "ven", ale vnitrniho NS). Pri pohledu na dokumentaci konfigurace kresd jsem mel nejprve pocit ze autori museli hulit fakt matros (nebo je to treba jen tim ze nejsem Lua pozitivni a tak nevim co se jeste tyka Lua jako takove a co primo resolveru, co z toho nahodou nespada do "to prece kazdy vi"). Zatim jsem se dopracoval k tomu, ze pro moje zony tam budu nejspis potrebovat vlozit cosi jako: policy:add(po­licy.suffix(po­licy.FORWARD('192­.168.0.2'), {'\5intra'})), ale jak se zbavit "blocked." na to jsem jeste neprisel (stejne jako tam poslat "0.168.192.in-addr.arpa", protoze mi to nejak koliduje s tim "backslash-cislo" nesmyslem, ktery doted moc nechapu).

b) toto cele naroubovat aby to bylo Omnia/OpenWRT koser. Tady by ta dokumentace ale fakt bodla, nerad bych se ted ci v budoucnu dostal do konfliktu se predstavami autoru /etc/init.d/kresd ci /etc/config/re­solver.

OK, tak beru zpet, zase tak hrozny to neni.
Nestastny je snad akorat to, ze modul 'policy' vyplachuje pravidla a hned potom tam dava blokovani "private_zones". Tady by asi bodlo, kdyby ta vec s "private_zones" byla jako samostatny modul co by se natahl samostatne (t.j. az potom, co by si clovek vyjmenoval vlastni pravidla pro zony z RFC1918). Takhle musi mit clovek ten seznam, ktery je vetsi nez samotna konfigurace, kopirovat do konfiguraku.