abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 16:11 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 4. a 5. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu.

Ladislav Hagara | Komentářů: 0
včera 14:11 | Komunita

Některým uživatelům Firefoxu se tento týden do Firefoxu nainstalovalo neznámé rozšíření Looking Glass 1.0.3 (png). Ve fórů Mozilly se řešilo, zda se nejedná o malware. Mozilla později informovala, že se jednalo o reklamu na seriál Mr. Robot. Řadě uživatelů Firefoxu se jednání Mozilly vůbec nelíbilo. Mozilla proto automatickou instalaci doplňku ukončila [Hacker News, reddit].

Ladislav Hagara | Komentářů: 15
16.12. 12:00 | Nová verze

Po cca 3 týdnech od vydání Linux Mintu 18.3 s kódovým jménem Sylvia a prostředími MATE a Cinnamon byla oznámena také vydání s prostředími KDE a Xfce. Podrobnosti v poznámkách k vydání (KDE, Xfce) a v přehledech novinek s náhledy (KDE, Xfce). Linux Mint 18.3 je podporován do roku 2021.

Ladislav Hagara | Komentářů: 6
15.12. 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 54
15.12. 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
15.12. 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 10
15.12. 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 10
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (0%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 1012 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník
    Nástroje

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

    Související dokumenty

    LARTC Howto (externí dokument)
    dokumentace iproute2 (externí dokument)
    proxy ARP - ručně (externí dokument)
    proxy ARP - automaticky (externí dokument)
    stateless NAT (externí dokument)
    Netfilter NAT HowTo (externí dokument)

    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: 11628×

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.