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 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (13%)
 (2%)
 (0%)
 (2%)
 (73%)
 (11%)
Celkem 62 hlasů
 Komentářů: 4, poslední včera 21:50
    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: 11555×

    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.