routování (odvozené)podle domény

říká se tomu policy based routing a v podstatě si to vyřešíš buď čistě pomocí iproute (násobné routovací tabulky), nebo využiješ ještě markování paketů firewallem pro granulárnější rozlišení kudy se má packet směrovat.

https://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-policy-routing/

... tedy si vytvoříš jednotlivé routovací tabulky a do nich pak budeš prát spojení podle ip rule from/to, které si nadefinuješ podle potřeby.

https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html

No já myslím , že policy routing na to není potřeba, ten se využívá při "source" routingu ("from") a ani více tabulek. V čem myslíš, že mi policy routing pomůže nebo dostanu nějak informaci
Doméně do source routingu?

Source routing mi ani nepřeloží ty ip adresy z originálních na změněný rozsah a zpět

Policy routing samozřejmě potřeba je a přemýšlíš o tom dosti chaoticky (PR se používá nejen "from" ale i "to")
Doménu přece můžeš promrskat nějakým skriptem (dig -> grep -> adresy) do ipsetu, a ten zase omarkovat.

A poslední větu jsem už nepochopil vůbec.

Napadá vás ještě jiné řešení? Ta transparence tam nutně být nemusí: Šlo by SOCKS proxy pro Https bez rozbití certifikátu? (První krok CONNECT vyextrahuje doménu)

Zeptej se odborníka na všechno tupoleva.

Já se ptám všech generálně i kdyby a nemám seznam odborníků a i kdyby to mám Každého obesílkovat zvlášť?

Ne, nemusíš nikoho obesílkovat. Já jen, že máš stejnou IP a styl "dotazu" taky přesně sedí....

řešení máš výše. Mám to takto doma a funguje to dobře a správně.

A ty provozuješ jen policy routing a nebo i to odlišené routování podle domén, jak jsem poptával v dotazu? Tak jsem si tu tvojí odpověď nechal projít hlavou, neděla moudřejší pátke a rozumím tvému řešení (i přes to, že odkazované materiály slovo domain/doména nezmiňují). Vytvoříš statický seznam IP adres (dig ) a , provede se fwmark a následně se ip rule add fwmark 123 table dnsbasedroutingtabulka; , ve které bude default dev vpn1;

Jen kontrolní otázka, šlo rovnou přes naládování těch adres rovnou do ip rule a nebylo by potřeba iptables ? (Akorát by to nebylo přehledné, ip rule neumí ipset )

Mě na tomhle řešení se nelíbí ta "fragilnost" - závislot na čersvtých DNS datech - pokud se změní DNS záznam, rozbije se to, je třeba to udržovat aktuální (což nějakým cronem by šlo) a nutnost ty adresy ládovat

Proto jsem spíš prahl po řešení, kde se překlad provádí "on-the fly" , když se počítač v za routerem právě chce připojit, dostane falešnou adresu z známého rozsahu a ta se následně DNATem vrátí zpět, ale už se ví, že to má jít přes jiné rozhraní. Jen nevím, jak zajistit tu programatickou změnu z přeložené adresy na původní z DNS. . Něco jako DNS64 , jestli se nemýlím

Každopádně díky za radu, fwmark a ipset mě nenapadl. (Ipset je logické zjednodušení a zpřehlednění, ale ne klíčová věc).
Tohle řešení mě právě nenapadlo. Proto jsem tvrdil, že policy routing není třeba

Odpověd hosta obsahovala nula bitů užitečné informace.

Routuju podle domén, ale nepotřebuji to mít takto dynamické jak to chceš ty.
Naládovat do ip rules to můžeš samozřejmě rovnou, jen si tím vytvoříš spoustu problémů, jako to, že podmínky policy routingu budou sáhodlouhé a nečitelné a zároveň budeš muset při jakékoli změně všechno shodit a zase nahodit (z pohledu podmínek policy routingu).
Právě proto jsem ti navrhnul použít iptables a jejich pomocný tool ipset, který byl napsán právě pro tyto případy - máš desítky/stovky/tisíce adres, ale jen jeden řádek v iptables a jeden v ip rules. Navíc flushnout a naplnit ipset je otázka velmi primitivního skriptu a nemusíš vůbec nic měnit v pravidlech iptables nebo iproute.

Celé to navíc můžeš pěkně automatizovat. Pomocí dig si vytvoříš aktuální seznam IP adres, seřadíš si ho, následně ho naimportuješ do ipset. Následně už stačí proces opakovat s tím, že si pomocí iterace nad oběma seznamy budeš kontrolovat, že nově zjištěné IP adresy z dig-u jsou v ipsetu (a když ne, tak se přidá) a opačně, že v ipsetu jsou pouze adresy vypadlé nově z dig-u - tedy dva poměrně jednoduché cykly. Nebo můžeš ten ipset sprostě smáznout a nahradit seznamem novým. Je to bleskurychlé, takže fungovat bude obojí.

Jo,chtěl jsem se ujistit. Skvělé.

Tvoje hloupé vymyšlené otázky taky obsahují 0 bitů....

A ještě jak se naivně dětinsky snažíš měnit přezdívky. Kandidát na LOCK, později BAN.

Klud.

jinak k těm tvým písmenkům ohledně DNS, tam to zase vypadá, že používáš špatný DNS server a řešíš ex-post dopad toho, že namísto interního serveru, který ti dá správnou IP rovnou, řešíš spojení kamsik ven.

Teď nerozumím. K čemu se váže ta poznámka. K tomu mému návrhu řešení a nebo nějak celkově? Který DNS server by byl správný . A interní v čemu nebo vůči čemu interní? J

tak psal jsi o "cinklých" doménách/IP adresách. To implikuje použití nesprávného DNS serveru.

Jo už jsem v obraze. To byla klíčová myšlenka mého (prvního) nápadu a myslel jsem to tak, že nějakým způsobem router musí se dozvědět, pro které domény (což nejde) - IP adresy (to jde) má odklánět provoz, takže ty domény "označí"(=cinkne) tím, že je přeloží na nějaký modifikovaný rozsah (10.253.0.0/16) a následně je na základě toho odroutuje na to zvolené rozhraní a na závěr adresy přes DNAT přeloží na originální

"...by překládal na cinknuté " tak tady došlo ke zmatení

Ale jaké nástroje/utility k tomu na linuxu zvolit?

Pripadne mi to takove zbytecne komplikovane, utility pod linux me napada a IMHO nevidim duvod proc to nenastavit klasicky treba pres [nmcli], nebo to udelat klasicky jako EIGRP, popripade misto FHRP pouzit PBR.