Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: czechsys 18. 03. 2021, 14:17:09
-
Ahoj,
opakovane narazim na problem soubehu vice IP v ramci jednoho serveru (napr. IP per domena na nginx). Pro prichozi spojeni neni co resit. Ale pro vytvoreni odchoziho spojeni a jeste z hlediska firewallu...
Teoreticky priklad s ipv6 /64 dedikovanou na server - odchozi spojeni muze pouzit libovolnou ip z defaultni routy (pripadne vliv metriky na vice rout).
gateway ::a:1
server ::a:2/64
a.domain.tld ::a:3/64
b.domain.tld ::a:4/64
Pro odchozi se tedy pouzije :2 ci :3 ci :4 (firewall - kazda ip musi byt povolena vsemi potrebnymi smery, popr. cela /64). Pokud v default route nastavim zdrojovou ip :2, tak prichozi budou chodit na :3 ci :4, ale odchozi bude :2 (skoro ideal pro firewall - 1 ip). No jo, ale pak nekdo bude narazet na to, ze sluzba ve firewallu bude mit odchozim smerem :2, v prichozim smeru :3 (:4)...
Nejake zkusenosti z praxe?
-
Pokud je to TCP sluzba, tak odchozi IP bude vzdy ta sama jako prichozi automaticky, i kdyby ti sluzba bezela zaroven na ruznych IP.
Pro UDP je nutno explicitne nastavovat z jakeho rozhrani odeslanej paket vznikne a muze byt v ruznych smerech tedy jina IP.
Asi si ujasni, proc chces obsluhovat vicero IP na danem serveru (muj pripad byl, ze jsem chtel mit ruzne hostnamy pro vice IP - mail.neco.tld, vpn.neco.tld ... takze tam me sluzba nebezela na vsech IP, ale jen na konkretni).
-
U odchozích spojení se zdrojová IP adresa vybírá podle nejspecifičtější routy. Pokud to spadne až na výchozí bránu, vybírá se brána podle pořadí, v jakém jsou zadané – buď první nebo poslední (nejlepší je si to vyzkoušet). Takže při stejném nastavení se to bude odesílat stále stejnou cestou – jediný zmatek by v tom mohlo udělat to, pokud by se rozhraní (po bootu) nastavovala asynchronně a pořadí, v jakém jsou zaregistrované routy na bránu, by tak bylo náhodné.
Lepší je ale použít pravidla (ip rule) a pomocí nich přesně specifikovat, která routovací tabulka se má kdy použít. V každé routovací tabulce pak budete mít jenom jednu výchozí bránu. Pak to můžete mít pevně v rukou a chování bude deterministické. Ale samozřejmě jste omezen tím, co máte k dispozici v pravidlech, tj. IP adresa cíle a myslím že i značky firewallu. Tj. pokud byste si představoval, že klient zavolá PHP skript na webu v určité doméně, PHP skript bude navazovat TCP/IP spojení ven a zvolí se jedna odchozí IP adresa, a stejný skript volaný na jiné doméně zvolí jinou IP adresu, musel byste potřebnou informaci dostat až na úroveň TCP/IP spojení, což by bylo dost obtížné. Daleko jednodušší bude v takovém případě zvolit odchozí IP adresu přímo v PHP při vytváření spojení.
Příchozí spojení neřešíte, tam správnou adresu v odpovědi zvolí sám operační systém. Pozor na to, že pokud máte více rozhraní, paket odejde rozhraním, které je vybrané podle routovací tabulky. Nemusí to tedy být stejné rozhraní, kterým přišel paket navazující spojení. Což může být problém, pokud jste za NATem nebo pokud síť, ke které jste připojen, má implementovánu kontrolu zdrojových IP adres.
-
Teorii znam, spis me zajimaji poznatky z praxe (napr. Hetzner udajne dava /64 per VM).
Mam tu realny priklad - na webserveru jsou domeny verejne i interni. V pripade ipv4 to resi nastaveni listen na public ci rfc1918 ipv4. V pripade ipv6, kdy pouzivam zasadne GUA, uz mi obecny pristup na IP adresu ve firewallu nestaci - i kdyz v public dns interni preklad neni uveden, tak staci poslat request na ipv6 s nastavenou interni domenou a firewall by to pustil. Pred webserverem je momentalne proxy, takze to pokryvaji acl. Ale uvazoval jsem o zruseni te proxy a v tom okamziku se to riziko "spoofnuti" domeny objevi.
-
Teorii znam, spis me zajimaji poznatky z praxe (napr. Hetzner udajne dava /64 per VM).
Mam tu realny priklad - na webserveru jsou domeny verejne i interni. V pripade ipv4 to resi nastaveni listen na public ci rfc1918 ipv4. V pripade ipv6, kdy pouzivam zasadne GUA, uz mi obecny pristup na IP adresu ve firewallu nestaci - i kdyz v public dns interni preklad neni uveden, tak staci poslat request na ipv6 s nastavenou interni domenou a firewall by to pustil. Pred webserverem je momentalne proxy, takze to pokryvaji acl. Ale uvazoval jsem o zruseni te proxy a v tom okamziku se to riziko "spoofnuti" domeny objevi.
Nechápu, v čem je problém. S IPv6 máte všechny možnosti, jako s IPv4, a k tomu ještě spoustu nových možností.
V tomhle konkrétním případě – interní domény máte na jiné IPv6 adrese (stejně jako to máte u IPv4) a přístup k ní můžete zablokovat na firewallu.
-
Ja to asi chápu. Jde o replikaci legacy schématu server s veřejnou IP v DMZ a nějakou privátní adresou v nějaké sítí za firewallem, split-horizon DNS, atd.
A vlastně tady při konfiguraci s jen jedním interface je všechno jinak.
@czechsys: je to tak?
-
Ja to asi chápu. Jde o replikaci legacy schématu server s veřejnou IP v DMZ a nějakou privátní adresou v nějaké sítí za firewallem, split-horizon DNS, atd.
A vlastně tady při konfiguraci s jen jedním interface je všechno jinak.
V čem je to jiné? V obou případech máte dvě IP adresy na jednom rozhraní. Vidím v tom jediný rozdíl – v IPv4 je víc IP adres na jednom rozhraní trochu netypická věc, v IPv6 je to samozřejmost a úplný základ.
-
V obou případech máte dvě IP adresy na jednom rozhraní.
Takový to SMB IT infra v nultých letech - jedna-dvě sítě s privátními rozsahy za firewallem, DNS dělaný na doménovém řadiči implementující split-horizon DNS (ideálně zneužívající TLD .local), k tomu nějakej LAMP píchnutej do DMZ i LAN, je jednom interface obsluhuje intranet, na vnějším public služby.
Ten stereotyp, že mít privátní IP = být za firewallem. Na tom vyrostlo dost síťařů samouků, a teď to samý zkouší na IPv6 kde už jdou věci dělat správně. To jsem myslel.
-
Nevím, jestli jsem přesně pochopil problém, ale není řešením Policy Based Routing? Obsluhujeme servery se stovkami ipv4 adres ve více VLANách, tedy i rozsazích (myšleno na jedné instanci OS) a odchozí trafic řídíme takto.
-
Ne, zcela to nikdo nepochopil. Nejde o nejake legacy-based migrace (ano, castecne to vychazi z toho).
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Nyni dam na kazdou fqdn vlastni ipv6, server tedy bude sam o sobe vlastnit celou /64. Na firewallu muzu ridit pristup per fqdn (misto per server). Spojeni inicovane smerem na server netreba resit. Spojeni iniciovane serverem ale resi problem, co vlastne bude zdrojova ipv6. Bude to ipv6 serveru? Bude to ipv6 nektere nahodne z fqdn? Na tom jednom interface muzou byt desitky ipv6 ze stejne /64.
Zakaznikovi se rekne, ze ma na api pristupovat na a.domain.tld. Ale pokud budeme z toho sameho serveru pristupovat k zakaznikovi my (spusti se php cronem), tak v ramci jeho projektu to muze byt defacto kterakoli ipv6 z toho /64, nejen primo ta a.domain.tld.
Policy Based Routing tohle castecne resi, ale neresi zcela ten cron pristup. Jak to pozna, ze to do sveta ma jit prave tou specifickou fqdn adresou pro a.domain.tld?
-
Ja to asi chápu. Jde o replikaci legacy schématu server s veřejnou IP v DMZ a nějakou privátní adresou v nějaké sítí za firewallem, split-horizon DNS, atd.
A vlastně tady při konfiguraci s jen jedním interface je všechno jinak.
@czechsys: je to tak?
Vubec. Na tom serveru jsou vsechny ipv4 lokalni. Ale je to za proxy serverem. A kdyz se zbavim proxy serveru a nasadim na to jednu verejnou ipv6 (a presunu do dmz misto te proxy), tak vlastne vsechny aplikace budou pristupne pres tu verejnou ipv6, coz neni v pripade internich aplikaci zadouci. Jo, oddeleni internich do vlastniho serveru je sice reseni, ale taky tak trochu plytvani prostredky...
-
Ne, zcela to nikdo nepochopil. Nejde o nejake legacy-based migrace (ano, castecne to vychazi z toho).
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Ale pochopili. Naopak vy jste nepochopil, jak to funguje.
Máte různé IP adresy a různé domény. Buď máte webový server nastavený tak, že všechny domény jsou dostupné na všech IP adresách – pak se lze přes veřejnou IP adresu dostat i na privátní doménu. Nebo máte správně přiřazené interní domény jenom k interním IP adresám. Pak se přes veřejnou IP adresu k interní doméně nedostanete, protože server na veřejné IP adrese odpoví, že danou doménu nezná.
Jestli je to IPv4 nebo IPv6, na tom vůbec nezáleží. Jediný rozdíl je v tom, že v IPv4 je ta interní IPv4 adresa z interního rozsahu, takže to na ní vidíte na první pohled. Naproti tomu s IPv6 sit u „interní“ IPv6 vyrobíte tak, že k ní zakážete na firewallu přístup z internetu.
Až to budete hledat v dokumentaci webového serveru, hledejte IP based virtual host vs. name based virtual host. Dokumentace pro Apache: Apache Virtual Host documentation (http://httpd.apache.org/docs/2.4/vhosts/), u nginx začněte třeba u Server names (http://nginx.org/en/docs/http/server_names.html) a spojíte to s tím, že u listen (http://nginx.org/en/docs/http/ngx_http_core_module.html#listen) můžete uvést i IP adresu/adresy.
-
Ne, zcela to nikdo nepochopil. Nejde o nejake legacy-based migrace (ano, castecne to vychazi z toho).
Rekneme, ze mate webserver pro jeden typ aplikace. Ta aplikace je tam duplikovana mnohonasobne, s tim, ze kazda kopie ma vlastni fqdn. Nektere aplikace jsou pristupne na pres fqdn na interni ipv4, nektere jsou pristupne na verejne ipv4.
Ted na to nasadite ipv6. Vsechny aplikace nyni maji verejnou ipv6. Kdyz na firewallu povolim pristup na ipv6 serveru, tak tim umoznim pristup na vsechny aplikace (napr. curl https://b.internal.domain.tld --resolve-host="ipv6:443"), i kdyz interni domeny nejsou ve verejnem dns (ale muzou leaknout).
Ale pochopili. Naopak vy jste nepochopil, jak to funguje.
Máte různé IP adresy a různé domény. Buď máte webový server nastavený tak, že všechny domény jsou dostupné na všech IP adresách – pak se lze přes veřejnou IP adresu dostat i na privátní doménu. Nebo máte správně přiřazené interní domény jenom k interním IP adresám. Pak se přes veřejnou IP adresu k interní doméně nedostanete, protože server na veřejné IP adrese odpoví, že danou doménu nezná.
Jestli je to IPv4 nebo IPv6, na tom vůbec nezáleží. Jediný rozdíl je v tom, že v IPv4 je ta interní IPv4 adresa z interního rozsahu, takže to na ní vidíte na první pohled. Naproti tomu s IPv6 sit u „interní“ IPv6 vyrobíte tak, že k ní zakážete na firewallu přístup z internetu.
Až to budete hledat v dokumentaci webového serveru, hledejte IP based virtual host vs. name based virtual host. Dokumentace pro Apache: Apache Virtual Host documentation (http://httpd.apache.org/docs/2.4/vhosts/), u nginx začněte třeba u Server names (http://nginx.org/en/docs/http/server_names.html) a spojíte to s tím, že u listen (http://nginx.org/en/docs/http/ngx_http_core_module.html#listen) můžete uvést i IP adresu/adresy.
Krucinal, ja neresim spojeni navazovane smerem na server. Ja resim spojeni navazovane ze serveru.
-
Riesenie je pouzivat sedliacky rozum = ked vam to takto nevyhovuje, tak pouzit dizajn ako v IPv4 = 1 IP = x domen rozdelenych cez Virtual host.
Ved nikto vam nekaze teraz vsetky domeny rozhadzat do separatnych ipv6.
-
Verejnu ipv6 zavesim namiesto verejnej ipv4 a rozdelim cez virtual hosts , privatnu ipv6 zavesim na povodne privatnu ipv4 a rozdelim cez virtual hosts. Ak je mala kapacita, pouzijem bond.
Samozrejme, ze ked mate viacero verejnych ipv6 na kazdu domenu tak na odchadzajuci traffic sa bude pouzivat nie vzdy ten interface, ktory si predstavujete.
-
Krucinal, ja neresim spojeni navazovane smerem na server. Ja resim spojeni navazovane ze serveru.
Tak nepište tři odstavce o webovém serveru, když řešíte klienta.
Jak to funguje z pohledu klienta jsem psal v komentáři #2 (https://forum.root.cz/index.php?topic=24451.msg347096#msg347096).
Než budete psát další komentář, přečtěte si prosím všechny odpovědi. Už tu byly popsané všechny varianty, takže si stačí jen vybrat tu odpověď, která řeší váš problém.
-
Policy Based Routing tohle castecne resi, ale neresi zcela ten cron pristup. Jak to pozna, ze to do sveta ma jit prave tou specifickou fqdn adresou pro a.domain.tld?
no právě tou policy (rulou), třeba takhle. Jestli chápu problém:
rooot@superserver:~$ ip ru l
0: from all lookup local
32763: from 10.88.24.0/21 lookup VLANaaa
32764: from 10.88.8.0/21 lookup VLANbbb
32765: from 10.88.48.0/21 lookup VLANccc
32766: from all lookup main
32767: from all lookup default
root@superserver:~$
root@superserver:~$
root@superserver:~$ ip r l t VLANccc
default via 10.88.48.1 dev eth1
10.88.48.0/21 dev eth1 scope link src 10.88.53.24
root@superserver:~$
Nebo se to dá řešit přes iptables, manglovat. Ale to už si ani nepamatuju jak se dělá... :-)
-
Policy Based Routing tohle castecne resi, ale neresi zcela ten cron pristup. Jak to pozna, ze to do sveta ma jit prave tou specifickou fqdn adresou pro a.domain.tld?
no právě tou policy (rulou), třeba takhle. Jestli chápu problém:
rooot@superserver:~$ ip ru l
0: from all lookup local
32763: from 10.88.24.0/21 lookup VLANaaa
32764: from 10.88.8.0/21 lookup VLANbbb
32765: from 10.88.48.0/21 lookup VLANccc
32766: from all lookup main
32767: from all lookup default
root@superserver:~$
root@superserver:~$
root@superserver:~$ ip r l t VLANccc
default via 10.88.48.1 dev eth1
10.88.48.0/21 dev eth1 scope link src 10.88.53.24
root@superserver:~$
Nebo se to dá řešit přes iptables, manglovat. Ale to už si ani nepamatuju jak se dělá... :-)
To ale vybíráte tabulku na základě zdrojové IP adresy, czechsys ale potřebuje správně určit zdrojovou IP adresu. To se nejsnáz (jak už jsem psal v komentáři #2) udělá tak, že ji přímo aplikace určí (asi na základě konfigurace). Pokud aplikace neumí určit odchozí IP adresu a spoléhá na přidělení OS, nezbývá, než ten údaj dostat do jádra přes ruku někudy jinudy. Třeba pokud to závisí na uživatelském účtu, používat v iptables match -m owner, označkovat si je a pak v ip rule udělat pravidla na základě -fwmark.
-
To ale vybíráte tabulku na základě zdrojové IP adresy, czechsys ale potřebuje správně určit zdrojovou IP adresu.
Však jo. A v té tabulce říkám, která IP bude zdrojová: src 10.88.53.24
-
Však jo. A v té tabulce říkám, která IP bude zdrojová: src 10.88.53.24
Ale na základě čeho vyberete, která tabulka se použije?
-
Však jo. A v té tabulce říkám, která IP bude zdrojová: src 10.88.53.24
Ale na základě čeho vyberete, která tabulka se použije?
Jasný, šlo o příklad. Tak si pan kolega upraví rule. Jak se ostatně píše např. v #17.
-
Pokud to spadne až na výchozí bránu, vybírá se brána podle pořadí, v jakém jsou zadané – buď první nebo poslední (nejlepší je si to vyzkoušet).
On může mít routovací záznam(cíl) mít víc bran než jednu? RTNETLINK answers: File exists (< ip route add ... )
-
Pokud to spadne až na výchozí bránu, vybírá se brána podle pořadí, v jakém jsou zadané – buď první nebo poslední (nejlepší je si to vyzkoušet).
On může mít routovací záznam(cíl) mít víc bran než jednu? RTNETLINK answers: File exists (< ip route add ... )
Routovací záznam nemá žádnou bránu. Pokud routovací záznam jako cílovou síť obsahuje všechny možné adresy (celý internetú, říká se tomu záznamu (výchozí) brána. Nevím, jestli je teď možné mít v jedné routovací tabulce v linuxovém jádru více bran – ten původní dotaz je dva roky starý, chování se za tu dobu klidně mohlo změnit a mohla tam přibýt kontrola.
-
Pokud to spadne až na výchozí bránu, vybírá se brána podle pořadí, v jakém jsou zadané – buď první nebo poslední (nejlepší je si to vyzkoušet).
On může mít routovací záznam(cíl) mít víc bran než jednu? RTNETLINK answers: File exists (< ip route add ... )
Proč by to nemělo jít?
root@michacka:~# ip ro add table 100 default nexthop via 10.97.1.1 nexthop via 10.97.1.2 nexthop via 10.97.1.253 nexthop via 10.97.1.254
root@michacka:~# ip ro sh table 100
default
nexthop via 10.97.1.1 dev wlp2s0 weight 1
nexthop via 10.97.1.2 dev wlp2s0 weight 1
nexthop via 10.97.1.253 dev wlp2s0 weight 1
nexthop via 10.97.1.254 dev wlp2s0 weight 1
root@michacka:~#
-
Pokud mate na serveru vic IP z jednoho bloku a vite, ze pro odchozi provoz chcete pouzit prave jednu z nich, dejte ji do "ip route add/change default via ...", napr. takto:
ip -6 route change default via fe80::1 src 2001:db8:dead:beef::babe dev eth0
Spojeni odchazejici default routou pak budou navazovana z 2001:db8:dead:beef::babe.
Hetzner smeruje na server celou /64, ale je na vas, jak si ji rozdelite. Pokud skutecne budete mit na interface vic adres, pak system obvykle nekterou z nich vybere a pouzije.
Policy based routing (ip rule ...) jde taky pouzit, ale na tenhle use case mi prijde zbytecne slozity.
-
Původní dotaz ja skoro 2 roky starý, nemyslím si, že má smysl řešit původní problém…