Zkušenosti s více IP na serveru

[czechsys]

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?

[Reklama]

[RDa]

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).

[Filip Jirsák]

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.

[czechsys]

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.

[Filip Jirsák]

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.

[Reklama]

[Jose D]

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?

[Filip Jirsák]

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.

[Jose D]

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.

[CZmok]

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.

[czechsys]

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?

[czechsys]

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...

[Filip Jirsák]

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, u nginx začněte třeba u Server names a spojíte to s tím, že u listen můžete uvést i IP adresu/adresy.

[czechsys]

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, u nginx začněte třeba u Server names a spojíte to s tím, že u listen můžete uvést i IP adresu/adresy.

Krucinal, ja neresim spojeni navazovane smerem na server. Ja resim spojeni navazovane ze serveru.

[snuff1987]

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.

[snuff1987]

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.