Jak zprovoznit veřejnou IP adresu ve vnitřní síti (nebo DMZ)?

Především bychom se měli vždy zamyslet, zda má být počítač s veřejnou IP adresou opravdu ve vnitřní síti. Ve většině případů je totiž vhodnější jej umístit na samostatný segment, kterému obvykle říkáme demilitarizovaná zóna. Protože je ale z hlediska řešení problému víceméně jedno, zda je veřejná IP adresa ve vnitřní síti nebo v demilitarizované zóně, můžeme od toho odhlédnout. Řešení existuje několik, řazena jsou podle jejich vhodnosti (sestupně).

samostatný rozsah

Ideální situace nastává v případě, že máme od poskytovatele k dispozici kromě vnější IP adresy našeho routeru ještě rozsah IP adres, který použijeme pro DMZ (nebo vnitřní síť). Řekněme, že adresa našeho vnějšího rozhraní eth0 je 1.2.3.4, délka prefixu 26 (maska 255.255.255.192) a pro DMZ (rozhraní eth1) jsme dostali rozsah 1.2.4.128/28; default gateway má adresu 1.2.3.1. Pak není potřeba provádět vůbec žádná speciální opatření, pouze na routeru nastavíme adresy a rozsahy oběma rozhraním a default gateway podle poskytovatele:

  ip addr add 1.2.3.4/26 brd + dev eth0
  ip addr add 1.2.4.129/28 brd + dev eth1
  ip route add default via 1.2.3.1

Nesmíme samozřejmě zapomenout povolit potřebnou komunikaci v konfiguraci paketového filtru a povolit IP forwarding. Při použití veřejných IP adres přímo ve vnitřní síti funguje vše úplně stejně, není problém používat na stejném fyzickém segmentu současně dva různé rozsahy IP adres.

Jakkoli je toto řešení technicky ideální, v praxi obvykle nedostaneme k dispozici celý rozsah IP adres, který bychom mohli použít pro DMZ nebo lokální síť. Častěji dostaneme např. dvě IP adresy z téhož rozsahu. I v případě, že máme samostatný rozsah, musíme se často uchýlit k náhradním řešením, protože vnější adresu spotřebuje zařízení, které nemáme pod kontrolou nebo které můžeme konfigurovat pouze částečně (ADSL modem/router, jiný embedded router apod.). U ostatních variant budeme tedy předpokládat, že kromě vnější adresy 1.2.3.4 máme k dispozici pouze jednu další adresu 1.2.3.5 (máme-li jich více, bude postup podobný).

proxy ARP

Obecně je problém v tom, že sice můžeme na routeru napsat

  ip route add 1.2.3.5 dev eth1

a router bude pakety pro 1.2.3.5 směrovat správně do DMZ, ale tyto pakety se k nám ve skutečnosti nedostanou, protože gateway poskytovatele neví, že má tyto pakety směrovat na 1.2.3.4 a očekává 1.2.3.5 přímo ve vnějším segmentu. Proto pošle ARP dotaz pro zjištění odpovídající MAC adresy, ale na ten nikdo neodpoví. Řešením by mohlo být přidání položky pro 1.2.3.5 do směrovací položky gatewaye poskytovatele, ale jednak to obvykle domluvit nejde, jednak by to neřešilo provoz z ostatních počítačů ve stejném segmentu (např. další zákazníci poskytovatele).

Ihned vidíme, že pokud bychom router donutili, aby na ARP dotazy na adresu 1.2.3.5 odpovídal MAC adresou svého rozhraní eth0, byl by problém vyřešen. "svět" by potom doručoval pakety pro 1.2.3.5 na router a ten by je dále odsměroval do DMZ. To se skutečně dá zařídit, a to dvěma způsoby. Nejprve nastavme počítač v DMZ (budeme mu říkat server) na 1.2.3.5/26 a na routeru přidejme

  ip addr add 1.2.3.4 dev eth1
  ip route add 1.2.3.5 dev eth1

Ano, v rozporu se zvyklostmi lze skutečně nastavit stejnou IP adresu dvěma různým rozhraním. Příchozí pakety jsou tak jako tak akceptovány jako příchozí, jakmile jejich cílová adresa odpovídá některé z našich IP adres, a chování odchozích paketů není definováno přiřazenými adresami, ale směrovací tabulkou, kde má nově přidaná položka pro 1.2.3.5 (s prefixem 32) vyšší prioritu než automatická položka pro 1.2.3.0/26.

První variantou, jak realizovat proxy ARP je přidání speciální proxy položky do ARP tabulky routeru:

  ip neigh add proxy 1.2.3.5 dev eth0

Ta způsobí, že přijde-li ARP dotaz na 1.2.3.5 na interface eth0, odpoví router MAC adresou tohoto svého rozhraní. V novějších verzích jádra lze ale tento proces zautomatizovat tak, aby nebylo nutné explicitně zadávat adresy, za které se má router vydávat. Zapneme-li proxy na obou rozhraních

  echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
  echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

bude se na každém z nich router vydávat za adresy, které jsou fakticky "na druhé straně". Vše pak bude fungovat symetricky, takže bychom dokonce serveru mohli default gateway nastavit na 1.2.3.1, z praktického hlediska je ale vhodnější použít 1.2.3.4.

bezstavový NAT 1:1

Další možností je použití bezstavového překladu adres pomocí routeru. Na rozdíl od obyklejšího překladu adres (realizovaného netfilterem) je bezstavový překlad výrazně méně náročný na zdroje routeru, protože není potřeba udržovat tabulky překládaných "spojení" (flows) a vyhledávat v nich jednotlivé pakety (proto se také někdy místo stateless NAT používá termín fast NAT). Za to ale samozřejmě platíme tím, že musíme explicitně definovat i pravidla, která by při stavovém překladu jádro provádělo automaticky. Dalším problémem je skutečnost, že v jádrech řady 2.6 stateless nat nefungoval a ve verzi 2.6.8 byl proto odstraněn. Alternativou by zde mohlo (? *FIXME*) být použití akce NETMAP netfilteru.

U řešení založených na překladu adres nemá server nastavenou veřejnou IP, pod kterou se na něj přistupuje z vnější sítě, ale nějakou náhradní. To je také největší slabinou tohoto řešení - potřebujeme-li komunikační protokoly, které kolidují s překladem adres, např. ESP/AH (IPsec), nelze toto řešení příliš snadno aplikovat. Pro DMZ v tomto případě musíme použít nějaký náhradní rozsah, předpokládejme, že to bude 10.20.30.0/24, router bude mít adresu 10.20.30.1, server 10.20.30.5.

Bezstavový NAT aktivujeme přidáním speciální položky typu nat do směrovací tabulky (tyto položky jsou defaultně přidávány do tabulky local, podobně jako položky typu local nebo broadcast):

  ip route add nat 1.2.3.5 via 10.20.30.5

Taková položka způsobí tři věci: za prvé bude na všech rozhraních kromě eth1 router odpovídat na ARP dotazy na 1.2.3.5 MAC adresou příslušného svého rozhraní (podobně jako u proxy ARP), za druhé u paketů s touto cílovou adresou přepíše cílovou adresu na 10.20.30.5 a za třetí pak tyto pakety odsměruje obvyklým způsobem (tedy na eth1). Tímto způsobem je možné překládat (mapovat) i celé rozsahy, pouze bychom místo 1.2.3.5 napsali např. 1.2.3.8/28 (jako cíl se píše pouze nejnižší adresa cílového rozsahu, prefix musí být stejný - mapujeme vždy 1:1).

Protože je ale tato forma překladu adres bezstavová, nemůžeme se (jako u DNAT v netfilteru) spoléhat na automatický překlad paketů v opačném směru. Stavové informace ovšem nepotřebujeme, protože u překladu 1:1 je i zpětný překlad možno realizovat pouze na základě paketu samotného. Zde ale potřebujeme překládané pakety rozlišit podle zdrojové adresy, místo položky proto definujeme pravidlo (rule), např:

  ip rule add priority 1235 from 10.20.30.5 nat 1.2.3.5

Ze stejného důvodu ale musíme navíc dávat pozor, abychom zdrojovou adresu překládali pouze u paketů, u kterých je to žádoucí. Pokud by totiž na rozhraní eth2 byl klient, který by přistupoval přímo na adresu 10.20.30.5, výše uvedené pravidlo by u odpovědi přeložilo zdrojovou adresu, což by byla chyba. Bylo by proto třeba buď i pro komunikaci z vnitřní sítě používat adresu 1.2.3.5, nebo upravit pravidla tak, aby se překlád vztahoval jen na pakety "do světa".

stavový překlad netfilterem

Poslední (a z již uvedených důvodů nejméně žádoucí) variantou je klasický stavový překlad cílové adresy pomocí akce DNAT netfilteru. V konfiguraci z předchozí sekce by řešení vypadalo takto:

  ip addr add 1.2.3.5/26 brd + dev eth0
  iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.5 -j DNAT --to 10.20.30.5

Navíc je samozřejmě třeba povolit příslušné pakety v řetězci FORWARD tabulky filter - ale to je třeba i u předchozích řešení (jen je třeba dávat pozor na to, že u prvních dvou je cílová adresa 1.2.3.5, zatímco u druhých dvou 10.20.30.5). O překlad (a detekci) "zpětných" paketů se postará netfilter automaticky, ale to nás samozřejmě něco stojí. Proto je toto řešení nevýhodné zejména při větším počtu procházejících spojení a slabším hardware routeru. Kromě toho samozřejmě přebírá všechny nevýhody plynoucí z překladu adres.

NAT redirect "gotcha"

Nedbáme-li dobře míněných varování a umístíme server do vnitřní sítě, můžeme se u řešení založených na překladu adres dočkat nemilého překvapení, že klienti z vnitřní sítě se na server (použijí-li překládanou veřejnou adresu) nedostanou. Ve skutečnosti je ale problém trochu složitější, musíme si proto nejprve rozebrat, co se v takovém případě na síti vlastně děje.

Představme si paket odeslaný na vnější adresu 1.2.3.5 z lokální adresy 10.20.30.99: tento paket přijde na gateway, ta mu přepíše cílovou adresu na 10.20.30.5 a pošle ho do vnitřní sítě, kde je řádně doručen na server. Zdrojová adresa je ale pořád 10.20.30.99, což je kámen úrazu: jakmile totiž server pošle odpověď, ta je doručena klientovi přímo (ne přes gateway), protože server i klient jsou ve stejném segmentu. Proto klient odpověď sice dostane, ale ta má pořád zdrojovou adresu 10.20.30.5, takže ji klient nepovažuje za odpověď na svůj paket, který posílal na 1.2.3.5

Existují dvě možná řešení. Za prvé nenechat klienty z vnitřní sítě, aby používali "vnější" adresu 1.2.3.5 ale skutečnou adresu 10.20.30.5. Přistupují-li klienti k serveru přes jméno, lze to řešit tak, že klientům z vnitřní sítě příslušné jméno přeložíme na adresu 10.20.30.5; je-li náš nameserver zároveň nameserverem pro Internet (kde musí být toto jméno překládáno na 1.2.3.5, lze v případě BINDu použít mechanismus tzv. view.

Druhým řešením je nechat sice pakety putovat přes gateway, ale kromě cílové adresy jim přeložit i zdrojovou (na její vnitřní adresu, podobně jako u maškarády). Tím je zaručeno, že i odpověď půjde zpět přes gateway, kde budou obě adresy přeloženy zpět. Takové řešení sice funguje, ale je asi patrné, že tato varianta není příliš elegantní ani efektivní. Konfigurace, kdy spolu dva počítače na témže segmentu komunikují přes třetí, který paketům překládá zdrojovou i cílovou adresu, očividně není optimální. Navíc má ještě jednu podstatnou nevýhodu: server není schopen rozlišit jednotlivé klienty z vnitřní sítě, jako adresa klienta bude v logu vždy adresa gatewaye.

Neměli bychom ale zapomínat ještě na třetí, obecně nejvhodnější, řešení: respektovat pravidlo, že server přístupný z Internetu nepatří do vnitřní sítě, ale do samostatného segmentu, demilitarizované zóny. Často je totiž místo krkolomných konstrukcí s cílem vyhovět přesně zadání vhodnější analyzovat, zda jsou všechny požadavky zadání opravdu rozumné.

Dokument vytvořil: Michal Kubeček, 27.12.2005 15:39 | Poslední úprava: Chulda, 5.1.2010 10:37 | Další přispěvatelé: Michal Kubeček | Historie změn | Zobrazeno: 13910×