Zamyšlení nad DNS a NATem

23.3.2010 11:28 | Přečteno: 1659× | Linux

V tomto zápisku chci rozebrat myšlenku ohledně NATu a DNS, kterou již delší dobu nosím v hlavě

Jde o to, proč když je k dispozici 1 veřejná IP adresa, tak, abych se dostal k více počítačům ve vnitřní síti, tak je nutné používat pomůcky typu přesměrování portů, třeba abych se dostal na svůj PC na webserver, tak musím na firewallu přesměrovávat port 80081 na 80 vnitřní sítě.

Absolutně nechápu proč to prostě nejde jednodušeji. Moje představa je taková. V internetu na DNS by bylo uvedeno, že třeba doména mojedomacidomena.cz odkazuje na IP adresu 90.178.50.128

*.mojedomacidomena.cz IN A 90.178.50.128

Když bych chtěl třeba pc.mojedomacidomena.cz, tak by můj router odpověděl, že se nachází na IP adrese 10.0.0.2 a dále by komunikace probíhala mezi těmito dvěma body. V případě, že bych zvenku zadal ntb.mojedomacidomena.cz, router by odpověděl 10.0.04 a zase by komunikace běžela mezi těmito dvěma body, bez směšné maškarády s porty.

Prostě klient z venku by věděl, že má požadavek hledat na IP adrese 90.178.50.128 a router by příchozí požadavky jej přesměrovával na 10.0.0.2, nebo cokoliv jiného. Proč vlastně něco takového nejde udělat?

       

Komentáře

[poky74]

Teď už ej to stejně zbytečné, nasaď ipv6 a jsi v suchu

[pasmen]

Protože ten router nemá možnost vědět, kam chce člověk venku lézt. Pokud pracuje jen na 3. (a případně nižší) vrstvě, jakože většina routerů ano, pak má k dispozici z packetů pouze IP adresy, čísla portů atd. Počítač venku si zjistí překlad IP adresy routeru z DNS a pak teprve začne spojení s routerem. Ale tohle asi víš...

[Cubic]

na 3. (a případně nižší) vrstvě

jako ze by routoval na druhe vrstve?

pak má k dispozici z packetů pouze IP adresy

jo? a jak potom delaj ten NAT?

[pasmen]

To jsem ale přece nikde neřekl. Jenom to, že zpravidla router používá pouze 3. (a případně nižší) vrstvu. Klasický router samozřejmě pracuje na 3. vrstvě, ale to všichni víme. Co se NATu týče, to je interní záležitost routeru a jeho conntrackových tabulek. Nic to nemění na tom, že ze samotných paketů může přečíst jen IP adresy, porty, atd.

[Cubic]

Pokud pracuje jen na 3. (a případně nižší) vrstvě

U toho jak je to napsane mam problem s vykladem, bud to chapu tak ze operuje automaticky i na nizsich vrstvach(bez toho by to nefungovalo) a nema to cenu zminovat nebo jak jsem si to vylozil ja: dela rozhodnuti na treti vrstve pripadne dela rozhodnuti na nizsi vrstve. Coz se mi samozrejme nezda.

Nemam v umyslu se hadat, jen naznacuju jak mi to puvodne vyznelo a proc jsem reagoval jak jsem reagoval.

[pc2005]

přesměrovávat port 80081

Tak to steží .

Jinak udělat by to jít mohlo, otázka je do jaké míry by bylo řešení kompatibilní se stávajícíma řešeníma. Jinak to protunelování NATu jde třeba pomocí http://en.wikipedia.org/wiki/Source_routing .

[Cubic]

třeba pc.mojedomacidomena.cz, tak by můj router odpověděl, že se nachází na IP adrese 10.0.0.2 a dále by komunikace probíhala mezi těmito dvěma body. V případě, že bych zvenku zadal ntb.mojedomacidomena.cz, router by odpověděl 10.0.04 a zase by komunikace běžela mezi těmito dvěma body

Me prijde ze chces aby kazdy router fungoval jako DNS server a odpovidal na dotazy adresama z privatnich rozsahu. Kdyz klient dostane odpoved 10.0.0.2 a kdo to potom bude routovat a hlavne kam?

[Cubic]

Prostě klient z venku by věděl, že má požadavek hledat na IP adrese 90.178.50.128 a router by příchozí požadavky jej přesměrovával na 10.0.0.2, nebo cokoliv jiného. Proč vlastně něco takového nejde udělat?

sakra tohle jsem nejak prehledl, jaky by pak byl rozdil mezi tim co ty navrhujes a NATem? Jak by router poznal kam to presmerovat do vnitrni site na urcite IPcko kdyz v IP paketu je jen cilova addresa a v tct/udp zas jenom port? A ted si predstave ze je tech NATu za sebou vic...

[filbar]

Jakou router tady beru Alix s nainstalovaným CentOSem, ve kterém je bind.

Má představa je taková, že klient dostane odpověď od IP adresy 90.178.50.128(pc.mojedomacidomena.cz) a když se bude dotazovat, tak se dostane na 90.178.50.128 a ta ho odkáže na vnitřní IP adresu 10.0.0.2.

V mé úvaze se jedná o zamyšlení, proč není TCP/IPv4 navrženo tak, aby něco takového umělo, případně proč do něj někdo nějakou takovou funkcionalitu nenavrhnul.

[Cubic]

TCP/IP bylo navrzeno na zaklade urcitych predpokladu u ktery doba a vyvoj ukazali ze byly mylne, pokud by se to navrhovalo znova asi by vzniklo IPv6 rovnou a ty bys nemusil resit takovehle skopiciny

[CET]

No, nechapu, jak myslis "odkaze". Proste se zeptas na jmeno, dostanes IP. To je DNS. Pak se pripojis na IP a dostanes odpoved. Ano, tusim jsou nejaky ICMP redirecty a ten tvuj server by i odpovedet mohl 10.0.0.2, ale klient by pak sel bud uplne nejak jinak (pokud uz by to tam v te siti neco routovalo), nebo spis nikam, protoze privatni IP se neroutujou do internetu. Navic, kdyby to takhle delali i ostatni, zkus se zamyslet, jak by routery vedeli, ze 10.0.0.2 maji routovat k tobe a ne k nekomu jinemu, ktery take vraci 10.0.0.2 pro svoje privatni servery?

Proto je to privatni range, kterej se proste neroutuje. A kdyz bys to chtel zacit routovat, tak jsi tam, kde jsme ted, ze neni dostatek IPcek, protoze se pouzivaji Interni.

Mozna chces VPN - coz je zabaleni privatnich IP do public trafficu. Pak se tvuj klient spoji s VPN serverem na IP 90.178.50.128 a pak tvuj klient rekne, ze chce mluvit s pc.... a dostane privatni IP 10.0.0.2, kterou pak routuje tim VPN tunelem.

[Martin Mareš]

V mé úvaze se jedná o zamyšlení, proč není TCP/IPv4 navrženo tak, aby něco takového umělo, případně proč do něj někdo nějakou takovou funkcionalitu nenavrhnul.

No hlavně proto, že celý NAT je strašlivý bastl, který porušuje základní principy fungování TCP/IP a ačkoliv ve většině případů funguje, občas, když není zrovna správná fáze Jupiterových měsíců, se něco rozsype a rozhodně nelze ani trochu mluvit o tom, že by do chování protokolů zapadal.

[pht]

Worse is better :)

[pht]

a ta ho odkáže na vnitřní IP adresu 10.0.0.2

Jak by měl takový odkaz proběhnout? 10.0.0.2 má na domácí síti skoro každý, jak bude klient vědět s kterou 10.0.0.2 má komunikovat? Pokud chcete navrhnout, aby se adresa zapisovala stylem "10.0.0.2 poblíž 90.178.50.128", tak jste jen zvýšil délku adresy na dvojnásobek - což je přístup, který používá IPv6 (ale délka je čtyřnásobná).

PS. nevím jestli dostatečně chápete rozdíl mezi DNS a IP. Internet je víceméně schopen funkce i bez DNS, IP komunikace probíhá mezi dvěma body které mají jednoznačně dané IP adresy pevné délky. DNS je jen tabulka pro lidi, která ukazuje jménem na IP adresu. V IP paketech žádná jména nejsou.

Rozsah adres 10.0.0.0 - 10.255.255.255 (a další) je tzv. privátní a mají smysl vždy jen v rámci jedné organizace. Proto nemůžete na tyto adresy zvenčí nic poslat, protože každý může mít adresu 10.x a nebylo by jasné, ze které sítě to má být.

[rADOn]

Najdi si nekde schema jak vypada TCP resp. UDP paket a poradne si ho prohledni. DNS jmeno tam nikde nikde nenajdes. Vsechno co ma NATujici router k dispozici jsou zdrojova a cilova IP a port. To je vsechno co ma NAT k dispozici a s tim dela co umi.

[CET]

Je videt, ze nechapes, jak to vlastne funguje.

DNS preklada pouze jmena na IP nebo IP na jmena (plus minus neco navic funkcne i obsahove, ale v tomhle pripade to staci).

Kdyz se klient v internetu zepta na IP pro pc.mojedomena.cz, tak dostane 90.178.50.128. Kdyz se klient zepta na IP pro ntbk.mojedomena.cz, tak dostane opet 90.178.50.128. V obou pripadech pak vytvori spojeni na IP 90.178.50.128 a port 80. Cili, jak router pozna, ze jednou to byl dotaz na ntbk a jednou na pc?? Nikaj. Jde se proste na IP.

Teoreticky bys mohl mit DNS server na tom routeru a pak ho nejak ohackovat, aby dokazal podle DNS zadosti nastavovat routing, kdyz klient pozada o IP pro ntbk.mojedomena.cz, tak DNS vrati 90.178.50.128 a poznamena si, ze klient chtel tohle jmeno, takze pro klientovo IP bude smerovat pristup na ntbk (10.0.0.4). Jenze, klient mohl zadat zaroven i o adresu pro pc.mojedomena.cz a jak pak router pozna, ktere zrovna spojeni ma presmerovat na PC a ktere na NTBK, kdyz se klient ptal na obe adresy? Dal si pak budes muset pamatovat informace pro vsechny klienty, kteri o DNS pozadali, navic bys musel mit hodne nizke TTL, jinak by se totiz IP ukladaly do ruznych DNS cache, takze by se ti mohlo stat, ze by vic klientu s ruznymi IP sdilelo stejnou dns-cache (resolver u providera), takze prvniho klienta bys dokazala idetifikovat a dobre nasmerovat, ale druhej klient by IP pro PC nebo NTBK dostal z cache a tam uz bys nevedel, na co se ptal.

Co ty vlastne vymyslis se v apachi pro http nastavuje pomoci namevirtualhost. Je to o tom, ze apache bezi na jednom IPcku, ale nabizi stranky pro ruzne www adresy. Klient pak pristoupi na jednu IP adresu a v http hlavicce rozlisi, na kterej virtualni web (jmeno) chce jit. Neni to uz ale IP, ale HTTP.

Mohl bys teda na router nainstalovat apache, kterej by delal pouze reverse-proxy. Mel bys tam dva virtual hosty podle jmen, pokud by sel uzivatel na http://pc.mojedomena.cz, apache by udelal proxy na http://10.0.0.2, pokud by sel klient na http://ntbk.mojedomena.cz, router by proxoval na http://10.0.0.4. Jeste tusim proftpd umi virtualhosty a mozny i proxy, takze pro ftp bys to takhle taky mohl udelat, ale pokud vim, tak telnet, ssh a spousta dalsich sluzeb to nepodporuje. Proto se pouzivaji port redirect.

Jeste mne napadlo, ze by to presmerovani slo mozna vyresit podobne jako port knocking. Mel bys nejakou sekvenci portu, kdyz bys na router pomoci ni "zaklepal", tak by te presmeroval na jeden cilovy server, kdyz bys "zaklepal" jinou sekvenci, tak by otevrel pristup na druhy server. Ale bylo by to vzdy jenom jeden server/port soucasne.

[filbar]

jj, něco takového jako proxy, nebo nějaký takový tunel jsem měl na mysli, že nikdo něco takového ještě nevymyslel, aby šlo tak jednoduše tunelovat provoz mezi koncovými body i když by byl jeden, nebo oba v privátním rozsahu.

K ustavení spojení by se použilo DNSko v Internetu a na kraji vnitřní sítě a pak by provoz probíhal už v tomto "tunelu" mezi 10.0.0.2 a druhou adresou.

[CET]

Ale jo, ono to existuje. Jmenuje se to IP in IP Encapsulation nebo IP tunnel (http://www.ietf.org/rfc/rfc2003.txt a http://www.networksorcery.com/enp/protocol/ip-ip.htm a http://en.wikipedia.org/wiki/IP_tunnel).

To funguje ale trosku jinak, nez si predstavujes. Dns totiz nemuze vracet dve IP adresy s tim, ze jedna je "jako" primarni a druha je ta za NATem. Takze bys musel nejak vyresit DNSka. Mohl bys to napr. resit tak, ze v DNS by byl na A zaznamu verejna adresa a na TXT nebo SRV zaznamu ta privatni. Tvuj klient (a klient vsech ostatnich) by pak musel na kazdou adresu delat dva dotazy, jeden na A record (public IP) a druhy na TXT/SRV record, pri pripadne privatni IP (pokud by neexistovalo, slo by se primo).

Pokud by klient dostal privatni a public IP, tak by spojeni na privatni IP zabalil do packetu s public IP a poslal. Router by to pak rozbalil a preposlal na cil.

Jenze to bys pak musel donutit vsechny lidi, aby tohle pouzivali v DNS, na routerech a aby programatori prepsali klientske programy.

No a bylo by to spousta namahy pro nic, protoze kdyz uz chce nekdo provozovat vice serveru v nejake siti, tak si ty verejny IPcka poridi. Navic se zacina prechazet na IPv6. A kdyz ma nekdo v siti jeden ftp, jeden www a jeden smtp server, tak to proste vyresi port redirectem pro jednotlive sluzby. A kdyz chce nejakej jedinec na svym routeru doma pristupovat pres jednu public Ip na svoje 2 nebo 3 ssh servery, tak si ten port redirect udelat na portu 22, 23 a 24 a je vysmatej tak jako tak.

VPN je pak specialni pripad, kdyz se to navic jeste sifruje, overuje identita klienta a tuneluje se pristup pro vsechny sluzby.

Takze ano, kdyby to bylo hned od zacatku internetu, tak by se na tohle asi preslo, ale kdyby se vedelo dopredu, ze bude problem s IP, tak by se rovnou navrhnul IPv6 nebo neco podobneho.

[Heron]

Stále mi uniká smysl proč tohle řešit, když lze přidělit IP a normálně to routovat.

[petr_p]

Přehlížíte příčinu problému – že chybí veřejné adresy. A řešení samozřejmě existuje – IPv6.

Pokud mermomocí chcete řešit IPv4, tak můžete použít source routing. Nicméně z rozumných důvodů jej směrovače ignorují.

Jinak ještě existuje jeden potrhlý vědec, který se snaží nahradit agregované IP směrování vyšší vrstvou, kde se směruje podle obsahu (názvů vlastností a jejich hodnot konkrétních nebo abstraktních objektů). Něco jako byl přechod od spojované telefonní sítě k přepojované IP, akorát o úroveň výše. (Google uspořádal na toto téma jeho přednášku, video se dá stáhnout, ale zapomněl jsem odkud.) Nicméně sám přiznává, že spousta problémů není dořešena, případně jejich složitost je značně nepraktická.

[Josef Kufner]

Vpodstatě to není až tak úplňe blbá myšlenka. Řešení by ale bylo v použití SRV záznamů a nastaveného přeposílání portů, tak jak je obvyklé.

Tedy na počítači v LAN by běžela služba na standardním portu a v DNS by byl pro vnější svět SRV záznam ukazující na router a jeho nestandardní port přeposílaný do LAN.

Otázkou je, nakolik různé služby (tedy spíš jejich klientské části) podporují SRV záznamy.

[petr_p]

Ano, to je dobrý postřeh.

Rozdíl ale je ten, že aplikace se pak nepřipojuje na transportní adresu (transportní protokol, sítová adresa a číslo portu), ale na službu v doméně.

Pak by ale bylo třeba, aby takové adresování uměly všechny klienty, všechny servery (jakési UPnP s registrací DNS záznamů), aby bezpečnostní mechanismy pracovaly s těmito identifikátory (například porovnávání jmen v certifikátech, firewally) a tak dále.

Takže vzkaz tazateli: Je to skoro tak složité, jako třeba nasadit IPsec nebo IPv6.

[Josef Kufner]

Ne, je to jen o DNS a podpoře SRV. Nic jiného není potřeba. To přeposílání portů se nastaví spolu s DNS (jednou, ručně a staticky).

[Mrkva]

No, tohle by šlo vyřešit použitím routeru jako HTTP proxy.

[Michal Kubeček]

Měl bych jedno doporučení: než začnete vymýšlet nějaká další originální řešení problémů dnešního Internetu, nastudujte si aspoň základy toho, jak Internet, TCP/IP a síťová komunikace fungují. Sice se občas stane, že mysl nezatížená starými stereotypy přijde na něco, co ostatním, zvyklým na zajeté koleje, unikalo, ale mnohem častěji prostě jen netušíte, proč je ten váš nápad vlastně nesmyslný.

[12345]

Jo, tak nějak

[Cubic]

čerstvý setřih?

[Grunt]

Proč vlastně něco takového nejde udělat?

Protože před otevřením WinBoxu by bylo vhodné si o tom vůbec něco přečíst.

[xkucf03]

Tohle bohužel nefunguje, protože klient si nejdřív pomocí DNS přeloží tu doménu na IP adresu a pak se připojuje na IP – tyhle dvě činnosti jsou na sobě dost nezávislé a ten router hlavně nemá jak poznat, na jakou doménu se chce klient dostat (na jaký počítač za NATem ho má poslat).

Nejblíž tomu, co chceš je Jabber – tam se totiž používají DNS záznamy, ve kterých lze uvést i číslo portu – takže bys měl jednotlivé Jabber servery na různých portech, ale nemusel bys složitě konfigurovat klienty – prostě si z DNS zjistí jak IP, tak i port. Pro HTTP ale pokud vím nic takového neexistuje.

Pořádným řešením je IPv6. Sám jsem ho použil (kromě jiného) k vyřešení problému, že IPv4 adresa serveru je jiná podle toho, zda jsem v lokální síti nebo venku. Díky IPv6 mám vždy dostupný server na stejné adrese ať jsem kdekoli. (Dřív jsem si musel měnit /etc/hosts podle toho, zda jsem byl doma nebo jinde)

[Josef Kufner]

Pro HTTP ale pokud vím nic takového neexistuje.

Use of SRV records in conjuction with HTTP and URIs.

[Limoto]

Rozjeď si na routeru reverzní HTTP proxy....