Názory k článku 10 důvodů, proč mít NAT na IPv6

Jak uz bylo rozebrano prede mnou, NAT je nutne zlo, ktereho se musime zbavit....

Jen dalsi priklad - kdyz domacnost pouzije NAT kompletne se zabarikaduje a zadne jeji nodes nejsou pristupne, pokud se nenastavi "krabicka/router".

Koupil jsi si novou lednicku, ktera umi objednavat veci z internetu tak jak dohcazeji? Smula, misto zastrceni CAT5 a power zavolej ISP at ti to pijde rozchodit. Potrebujes regulovat teplotu, svetlo, dvere atd na dalku - smula, musis rozchodit ten webserver na jinem protu, protoze na 80 uz lezi ta lednicka a ty mas jenom jednu verejnou adresu.

nedej panbuh abych pak mohl pristupovat na svoje filmy, ulozene na DVR nebo homeserveru...

Tohle proste musi fungovat tak, aby i Franta z horni dolni koupil, zastrcil lbely co se nedaji zamenit a ono to fungovalo. A mimochodem to je nase prace, co tomu rozumime to zaridit. Franta at nam zaridi at mame co jist

NAT is dead, viva IPv6

cely clanek je pekna kravina, nema cenu se k tomu ani dale vyjadrovat

Nemohl by příště článek o NATu psát někdo, kdo si alespoň neplete NAT a firewall?

Není. Nenechte se mást tím, že třeba v Linuxu jsou firewall i NAT implementovány v jednom celku (NetFilter) a konfigurovány jednou utilitou (iptables).

NAT je překlad adres, můžete mít klidně nastaven NAT, který bude IP adresy a porty překládat 1:1, takže každé zařízení ve vnitřní síti a každý jeho port bude normálně dostupný z internetu. Ostatně některé příklady zmíněné v článku (třeba 1-4) by používaly právě takový NAT. Je snad jasné, že takovýhle NAT žádné zabezpečení odpovídající firewallu nepředstavuje.

Spíš 3 (slovy tři) - ICMP to umí taky.

Směrovací protokoly opravdu není nutné přes NAT dostávat, nedává to moc smysl. Tj. z toho seznamu odpadá např: igmp, eigrp, pim, ospf. ESP taky nekontroluje hlavičky, takže z IPSec tak maximálně to AH.

Možná je spíš lepší se bavit o jednotlivých aplikačních protokolech, tj. H.323, SIP, atd.

Ale jinak s tím lze celkem souhlasit.

Navic z clanku jsem pochopil, ze ani nevite jak NAT vlastne funguje?
To ze NAT vetsinou umi jen a pouze 2 (slovy dva) protokoly, ktere vsichni admini jiste znaji.
TCP a UDP zkrz NAT dostanete jednoduse.
Ale co ostatni protokoly:
esp, ah, igmp, gre, eigrp, ospf, ipip, pim, l2tp, ...

Ano jde to, ale vzdy nejakou obezlickou, nebo tunelovanim pres TCP, ci UDP.

Protlacit nekdy zkrz NAT takovy PPTP, nebo IPSec tunel je nekdy dost velka fuska.
A to nemluvim o standardnich problemech FTP a otevirani portu pro data.

Kdyby nebyl NAT bylo by na svete o polovinu mene administratoru, protze by nemuseli resit problemy zpusobene NATem. Fuj, doufam, ze ipv6 nikdy NAT jak je v IPv4 nebude.

preco nepisat "odborne" clanky na temy, o ktorych mam iba hmliste predstavy ...

něco ve smyslu: Tento článek nečtěte, pokud rozumíte tématu a zároveň máte problémy s krevním tlakem.

Autor bohužel vyrostl v době, kdy se NAT stalo nedílnou součástí síťové architektury a bohužel se nedokáže od tohoto paradigmatu odpoutat.

Snažím se pouze prosadit liberální pohled na věc, tedy kdo chce NAT ať ho má, kdo nechce ať ho nemá.

S tím ale myslím nikdo nepolemizuje. Problém je v tom, že spousta lidí si na internet pokřivený NATem už tak zvykla, že nemít NAT jim připadá jako omezení. Takže pak vymýšlejí různé krkolomnosti, které pak mohou krkolomně řešit NATem – a jsou spokojeni. Přitom by stačilo to udělat „normálně“, je to jednodušší, bezpečnější, spolehlivější, žádný NAT není potřeba.

Takže to vaše „chce“ se dá vykládat různě. Chce otrok okovy? Některý jistě, nedovede si představit, že by najednou žil bez nich, má je přece celý život… Ale ten, kdo se okovů dokázal zbavit, nebo je nikdy neměl, už je nikdy nebude chtít zpátky. Celé „tažení“ proti NATu s IPv6 není proto, aby NAT nepoužíval ten, kdo opravdu chce. Jde jen o to, aby si jen dotyčný uvědomil, zda to náhodou nejsou takové okovy, na které si už zvyknul.

Ano NAT zvysuje bezpecnost asi tak jako kdyz zavrete vchodove dvere od bytu a nechate je odemcene a jeste nechate zvenku klic v zamku ! :-)

NAT neni firewall a nikdy nebude je to jen falesny pocit bezpeci, BFU rozdil znat nemusi, ale admin ten by toto mel chapat, a jestli nevi tento zakladni fakt, nemel by nikdy na administraci jakehokoli stroje sahat.

tak zase na druhou stranu, málokdo má zájem o sousedovy broadcasty.

teda beru zpet slovo "idealni". ma neolik masarek...

O strukturu sítě v domácnosti se starat musím. Je potřeba rozlišovat tři situace:
- je připojen pouze jeden počítač - musím přidělit adresu /128,
- v domácnosti je jeden subnet - přidělit /64
- v domácnosti je více subnetů - přidělit /56 či /60.

V prvním případě mohu přidělovat přes DHCPv6. Tuto adresu mohu přidělovat v podstatě náhodně v rámci příslušného rozsahu.

Ve druhém případě musí přidělit přes DHCPv6 jednu externí adresu, při dalším DHCPv6 pro vnitřní rozhraní musím přidělit /64 subnet a do svého routeru doplnit směrovací údaj. Problémem je, kdy mám tento směrovací záznam zrušit - pokud by měl být natrvalo, tak musím domácímu routeru přiřazovat pořád stejnou externí IPv6 adresu a pořád stejný vnitřní /64 rozsah. Nebo musím monitorovat stav přidělování z DHCPv6 serveru a v okamžiku, kdy propadne pronájem, tak zrušit záznam ve směrovacích tabulkách.

Pokud si v domácnosti někdo zapojí druhý vnitřní router, tak ten požádá o adresu pro své externí rozhraní, dostane adresu od DHCPv6 serveru z hraničního routeru (popřípadě přes autokonfiguraci). A poté vnitřní router požádá o adresu pro své interní rozhraní. A hraniční router, protože dostal jen /64 subnet, tak požadavek nejspíš zamítne. Nebo ho může předat na DHCPv6 server poskytovatele a ten přidělí další /64 subnet, hraniční router bude muset upravit své směrovací tabulky a předá upravenou DHCPv6 odpověď vnitřnímu routeru.

Neznám specifikaci DHCPv6 protokolu tak, abych byl schopen říct, že mnou uvedená konstrukce je vůbec možná. Určitě ale nevím o žádné implementaci. Většina autorů však píše o tom, že jsem v tomto případě měl hraničnímu routeru přidělit větší rozsah (/56 či /60). Ale jak to poznám??? Jediná šance je vytvořit aplikaci, ve které budou jednotliví uživatelé žádat o velikost svého rozsahu. Mohl bych tuto možnost dodatečně zpoplatnit ....

on spis myslel unikátní lokální adresy
a ty resi dost bodu;)

> ad 5 - toto řeší v IPv6 ULA adresy ve spojení s proxy servery,

Pripojeni site s privatnima (ULA) adresama k Internetu pres proxy server je mnohem mene prakticke reseni nez pripojeni site s privatnima adresama k Internetu pres NAT.

Tohle řeší prefix delegation u DHCP (umi napriklad ISC DHCP od verze 4.1)

pro firmy co chtej smirovat zamestnance je to velmi prakticke:)

není to tím, že site-local adresy už neexistují (viz RFC 4291 2.5.7.)? :)

Tedy hlavne svymi reakcemi na vecne nazory? Ze by nize popsany typ cloveka?
http://www.dfens-cz.com/view.php?cisloclanku=2001011201

nene jen zamenujete todle
fec0::/10 — prefix místní stránky udává platnost adresy pouze uvnitř místní organizace. Použití bylo v září 2004 odmítnuto dle RFC 3879 a systémy nesmí podporovat tento speciální typ adres.
s timhle
fc00::/7 — unikátní lokální adresy (ULA) jsou směrovatelné pouze v množině spolupracujících stránek. Tyto byly definovány v RFC 4193 jako náhrada za adresy lokální stránky (viz níže). Adresy zahrnují 40 bitové pseudonáhodné číslo minimalizující nebezpečí konfiktu při sloučení stránek či úniku paketů.

Me by zajimalo, jak se v IPv6 bez nat bude resit zobrazeni default stranky.

Klasicky pripad, sednete si nekam do restaurace pripojite se na hotspot a zobrazi se vam v prohlizeci stranka pro zadani hesla (a informace kde heslo ziskat). Na IPv4 resene jednoduchym DNATem vseho s dst portem 80 na pripravenou stranku.

V IPv6 me ted nenapada jak.

Něco takového je pouze pseudozabezpečení. Ve skutečnosti by totiž neměl být v současnosti žádný problém takovou překážku překonat. Správný postup je použití třeba 802.1X.

nebo třeba takový VoIP telefon. Ten by se měl přesměrovat na hlasovou bránu, která by mu řekla, že je v zabezpečené síti a že heslo dostane u obsluhy. Pak zavolá podruhé, řekne hlasové bráně heslo a už si bude moct zavolat. Kdo vymyslí něco lepšího? ;-)

V tomhle směru mě napadá - je u IPv6 nějaká možnost, jak vyřešit transparentní proxy?

Napiste, jak by jste to prekonaval, kdyz to neni problem, to by me zajimalo :-)

Kazdopadne jak vam psal uz Ondrej Zajicek, tyhle stranky jsou vetsinou informativni. Treba v hotelu je na ni cislo, na recepci, kde vam to na pozadani odblokuji, ale samozrejme nechteji, aby se jim na WiFinu pripojoval kdokoliv z venku, tak ty hesla pravidelne meni.

Internet rozhodne neni jen web, ale protoze vsichni vedi, ze hotspoty takhle funguji, tu stranku si nactou. Funguje to tak v podstate v jakekoliv verejne budove nebo hotelu. Klasicky to ma treba poskytovatel pripojeni k internetu, nalovite wifinu (zapojite komp do ethernetu v panelaku, kam jste se nastehovali) a vyskoci na vas informacni stranka kam mate zavolat, aby vas pripojil. Jak vam tady nekdo psal, dalsi pouziti je transparentni proxy.

> Jinak to samozřejmě můžete řešit přesměrováním HTTP komunikace, NAT je jen jeden ze způsobů, jak to přesměrování zařídit

Opravdu? Omlouvam se jestli to vyzni moc utocne, ale opravdu miluji v technicke diskusi kdyz nekdo odpovi takhle vseobecne. Proc nenapisete, jak konkretne by jste to resil?
Jedine dalsi zpusoby ktere me napadly, je za a) nasadite nejaky program, ktery bude prepisovat vsechny odchozi pakety (tedy delat to same co mohl delat DNAT ve FW) nebo b) zahazovat vsechny pakety na port 80 a vracet http redirect (coz mi prijde jako mnohem horsi varianta, protoze takovy program pobezi pod administratorem - bude nachylny na bezpecnost)

Na windows nejsem odbornik, ale zil jsem vzdycky v presvedceni ze ICS funguje jen kdyz vyberete u typu propojeni "Doma". Pri pripojovani v restauraci snad i BFU vybere "verejne misto".
V restauraci/hotelu by jste ale stejne musel cekat, dokud se nekdo s nezabezpecenymi win nepripoji. Coz by mohlo trvat docela dlouho.

Kazdopadne zajimavy tip, zkusim proverit :)

oprava: propojeni -> pripojeni

Pokud je připojen více než jeden počítač, tak je to IMHO celkem rozumné... Minimálně při použití IPv6. Ono je pak vlastně jedno, jestli je tam těch dalších počítačů 5, 10 nebo 2^27 :)

no, a ještě IPv6 oproti IPv4 neznamená o 50% delší adresu ("počet číslic"), ale o 300% delší adresu, tedy čtyřikrát delší

Mozna jsem pochopil jak jste to myslel s tim routovanim. Myslel jste to tak, že webový server bude odpovídat za všechny DST IP adresy.
Ale to stejne zajistite jenom tak, ze budete delat nejakou formu NATu. V tomto pripade prepisovat vsechny DST IP na adresu routeru. A po odblokování IP klienta tenhle nat vypnout.

Jinak by na tom routeru musela běžet nějaká speciálně upravená aplikace (web server), ktery prepne sitovku do promiscuit modu a zaroven by taaplikace musela mit nejakou konfiguraci, aby tohle chovani slo pro urcite SRC IP vypnout ... To je reseni na urovni baraku na muri nozce :-)

já bych se tím, že někdo něčemu nerozumí moc neoháněl. Je to jednoduché - pro dosud neautentizovaného uživatele posílám pakety na GW1 (tam sedí ten naslouchač man in the middle), pro autentizovaného uživatele posílám na GW2, což je skutečná brána do internetu (hlavičky paketů nepřepisuji, čili žádný NAT)

Praktickou realizaci ponechávám za domácí úkol, na linuxu to můžete nastavit pomocí ip rule.

Odpovím si sám: Squid má možnost dokompilovat příslušný modul pro Netfilter, takže minimálně na Linuxu to řešitelné je. Čímž se nechá odpovědět i na úvodní dotaz tohoto vlákna.

FW mělo znamenat firewall. Opravím tedy svou větu na: "tedy delat to same co mohl delat dst NAT standardne nainstalovany v systemu" Aby jste byl spokojen :)

V linuxu je webový server (apache) řešen tak, že pod rootem běží pouze naslouchající proces, který pak data předává ke zpracování dalším procesů, které běží pod normálním uživatelem. Tj. s příchozími daty se pracuje pod nonroot uživatelem. Asi by takto šel řešit i ten můj naslouchající proces a tím padá moje námitka na bezpečnost. Zatímco NAT je ale součástí skoro každého síťového zařízení, tak nějaká aplikace provádějící redirect určitě ne.

Vracení HTTP redirectu tak jak jsem ho popsal by pravděpodobně (pravděpodobně píši jen proto že jsem nezkoušel) fungovalo v pořádku. Naslouchající program by v odcházejících paketech jako src IP podstrčil DST IP z příchozího paketu. Klasický man in the middle. Po redirectu už by se spojení od klienta navazovalo na novou (podstrčenou) adresu.

ALE hlavně jsem nepochopil, jak chcete zařídit redirect webu pomocí routování bez NATu. To že na routeru bude na portu 80 webový server, který bude odpovídat na všechny adresy vám podle vás zajistí, aby se tahle stránka zobrazila jako default při zadání čehokoliv do prohlížeče? To se na mě nezlobte, ale jestli si tohle myslíte, tak principu fungování IP vůbec nerozumíte.

Ano, to jste ale jen popsal to co uz jsem psal uz drive viz. varianta b) :-)
Celou dobu mi jde o to, ze zatimco na IPv4 jste vsechno mohl resit prakticky jakymkoliv sitovym zarizenim v milionkrat vyzkousenem IPv4 stacku, tak nyni budete to same resit radoby hackerskou technikou, prepinamim sitovky do promiscuit modu, ... a na sitovych prvcich nahravat nejaky firmware treti strany, aby to umel.

No, s tím promiskuitním režimem jste trochu vedle. Ten je o vrstvu níž. Zachycení toho spojení není nutné provést v promiskuitním režimu, protože na GW1 bude ten paket poslán přímo.

Jde o to, že toto řešení je realizovatelné bez NAT jak v IPv4, tak v IPv6.

U TCP/IP si nepomůžete podvržením jednoho paketu, jenom pro navázání spojení potřebujete 3 pakety, kde potřebujete mít správně třeba sekvenční čísla.

Router by veškerou komunikaci na portu tcp/80 pro nové uživatele směroval na jeden web server, ostatní by směroval třeba na výchozí bránu. Ten web server by pak odpovídal na požadavky na jakoukoli IP adresu.

NAT není součástí skoro každého síťového zařízení, naopak směrování je součást každého zařízení schopného komunikovat IP protokolem, protože musí určit aspoň to, zda je paket pro toto zařízení nebo se má poslat jinam. Předpokládám ale, že jste myslel, že kdejaký hardwarový modem nebo router má v sobě podporu pro IPv4 NAT, ale routovat podle cílového portu neumí. To máte pravdu, ale pro podporu přihlašování to zařízení stejně musí umět rozlišit přihlášené a nepřihlášené uživatele, takže to stejně nezvládne každá krabička za tři stovky. Stejně pro to bude potřeba nějaká podpora v tom zařízení, v jednoduchém zařízení pak ten web server může být přímo jeho součástí, a pak je úplně jedno, zda si to to zařízení uvnitř řeší přepisem DST hlavičky, nebo jejím ignorováním.

Ano pokud bude nastaven jako GW, mate s promiskuitnim rezimem samozrejme pravdu, omlouvam se.
Ale stejně se podle me nezbavíte nejake speciální aplikace napsane pro tento ucel, ktera bude pracovat s RAW sockety a bud bude umet sama propoustet odblokovane klienty nebo se pouzije vase reseni s dvema GW.
Coz mi prijde zbytecne, protoze nat by to zvladl bezpecneji a jednoduseji.

Hledáte v tom zbytečně komplikace. Buď NATem změníte cílovou IP adresu na adresu, kterou web server očekává, nebo nastavíte web server, aby cílovou IP adresu ignoroval, a odpovídal na všechny. Rozdíl v bezpečnosti nebo jednoduchosti není žádný – druhé řešení je dokonce o něco výpočetně jednodušší, protože nemusíte v paketu nic měnit a přepočítávat kontrolní součty, na web serveru zase nemusíte testovat, zda se IP adresa shoduje.

Bude se to řešit úplně stejně, jako se to řeší teď. Prostě přesměruješ komunikaci na TCP portu 80.

K čemu je potřeba pamatovat si adresu?

Podle mě ale klasický web server (například toho apache) takto na linuxu nenastavíte, protože i když naslouchá "na všech IP" adresách, tak se k němu dostane jenom to, co ve firewallu projde INPUTem, tj jenom to co je určeno pro IP adresy nastavené na stroji, kde apache bezi.
Na neco jineho budete potrebovat upraveny webserver, pracujici s RAW sockety, ktery bude odposlouchavat opravdu vsechno co tece pres rozhrani.

Ano, ale musela by to byt specialne upravena aplikace, pracujici s RAW sockety, aby se k ni pakety pro libovolnou dst IP dostaly.

Proč? Aplikace by normálně naslouchala na :::80, takže by odpověděla na každý požadavek na portu tcp/80, který by přišel na daný počítač.

Bez natu bych musel psat/hledat nejakou specialni aplikaci ktera bude predavat prichozi pozadavky na jine stroje a u odchozich pozadavku zase falsovat src IP.
Ta „speciální aplikace“ se jmenuje router neboli směrovač a je součástí linuxového jádra.

> Router by veškerou komunikaci na portu tcp/80 pro nové uživatele směroval na jeden web server.

Ano, ale musela by to byt specialne upravena aplikace, pracujici s RAW sockety, aby se k ni pakety pro libovolnou dst IP dostaly.

Treba na AP ovislink (krabicka za par stovek) sel nahrat firmware APpro, kde jste pak mel klasicky linuxovy iptables a mohl delat redirecty cehokoliv kamkoliv.

Jeste me napadl jeden priklad, kdy se mi NAT hodil. Prebral jsem server, na kterem bezel web a maily. Z duvodu bezpecnosti a lepsi skalovatelnosti bylo rozhodnuto, ze se na serveru vytvori dva vitualni servery OpenVZ - jeden pro web a druhy pro maily. Problem ale byl, ze web aplikace i maily byly pristupne na spolecne domene (ja vim, chyba navrhu, ale co s tim nadelate) a priblizne stovka klientu mela tu domenu nastavenou ve svych lokalnich aplikacich.
Resilo se to jednoduse tak, ze HW stroji se nechala puvodni domena, kazdy virtual dostal novou a do FW na HW stroj se dalo pravidlo, ze cokoliv prislo na jeho IP port 80, tak se presmerovalo DNATem na web virtual a cokoliv prislo na imap/pop3 port, tak se smerovalo na mailserver virtual.
Novi klienti samozrejme dostali nove domeny, na ktere se pripojovali primo a stavajici klienti dostali navod a postupne na nove domeny take premigrovali.

Bez natu bych musel psat/hledat nejakou specialni aplikaci ktera bude predavat prichozi pozadavky na jine stroje a u odchozich pozadavku zase falsovat src IP.

Proc ale, kdyz mam obecny nastroj, ktery zvladne oba ukoly a mam to nastavene za 5 minut?

Takze jinymi slovy, ten problem, kterymu v soucasnosti celime, ze je treba flashnout (nebo vymenit) vsechny existujici zarizeni, aby podporovaly IPv6, vyresime elegantne tim, ze bude stacit vsechny existujici zarizeni flashnout nejakym IPv4+ (a nebo taky vymenit, pokud novej firmware z nejakyho duvodu pro dany zarizeni nebude). V cem presne je ta vyhoda? :)

Problem komunikace mezi staryma a novyma adresama spociva v tom, ze stary zarizeni si vubec nedokaze predstavit, ze by nejaky novy adresy mohly existovat. Kdyby na stary zarizeni dorazil paket se zdrojovou adresou 981.245.765.423 (pomineme technicky detaily, kvuli kterym se to vubec nemuze stat), tak to zarizeni by stejne reklo, ze je to pitomost a takova adresa neni platna. A komunikace by nefungovala. Stejne tak kdyby se stary zarizeni dozvedelo (coz opet realne nejde), ze server, na kterej se chce pripojit, ma novou adresu 562.645.234.234. Nemohlo by s tim delat vubec nic, protoze pro nej by ta adresa byla jasne neplatna.

> Proč? Aplikace by normálně naslouchala na :::80, takže by odpověděla na každý požadavek na portu tcp/80, který by přišel na daný počítač

Mate pravdu ze v tomto konkretnim pripade bych se obesel bez RAW socketu, ale potreboval bych pro kazdy typ spojeni specialni proxy. Na Hw stroji by tedy bezela http proxy, ktera by se zeptala webserveru a pop3/imap proxy ktere by se ptaly mailserveru.

> Ta „speciální aplikace“ se jmenuje router neboli směrovač a je součástí linuxového jádra.

:-) Dobra zkusim to na, prikladu.

HW stroj ma IP1 (domena hosting.xx), web virtual IP2 (domena web.xx), mailserver IP3 (domena mail.xx).
1) Pozadavek od klienta se starym nastavenim prijde na hosting.xx:80, pokud na HW stroji mam nat, tak prepisu dst IP na IP2 a vse vyrizuje webvirtual. Protoze ma linux ulozena spojeni v tabulce, tak automaticky u odchozich paketu z tohoto spojeni nastavi src IP na IP1. Takze pro klienta to vypada, jak kdyby odpovidal HW stroj.
2) Pokud na hwstroji nic nebezi, tak routing nicemu nepomuze, protoze uz se doroutovalo do cile. A klientovi vyprsi spojeni.
3) Pokud tam bezi http proxy, tak se zepta web virtualu a posle klientovy odpoved.

Nepotřebujete ani žádný speciální proxy. Na routeru nastavíte, že všechny pakety s cílovým portem tcp/80 mají být směrovány na web server, na web serveru nastavíte, že všechny pakety s cílovým portem tcp/80 patří lokálnímu počítači (tj. mají být routovány do aplikace), a aplikaci web server (třeba Apache) nastavíte, ať naslouchá na všech IP adresách.

Ve vašem příkladu nemusíte dělat NAT, prostě jenom nastavíte routování tak, že pakety s cílem IP:80 se mají routovat na virtuální stroj. Virtuálnímu stroji nastavíte routování tak, že pakety s cílem IP:80 mají být routovány do aplikace, a poběží tam třeba Apache, který bude naslouchat na adrese IP, nebo rovnou na všech. Není potřeba přepisovat adresy v paketech ani kontrolní součty, není potřeba ani udržovat tabulku spojení. Stačí tedy ve vašem bodě 2 změnit to, že hwstroj bude pro danou IP adresu a port 80 routovat komunikaci do lokální aplikace, a nahradit to routováním do síťového rozhraní virtuálního stroje.

Jen pro informaci: jak se nechá - třeba - v Linuxu nastavit, že všechny pakety s cílovým portem 80 patří lokálnímu počítači? Zatím mi tato funkce nějak unikala... :-(

Priznam se ze tohle jsem jeste nikdy nenastavoval. Uz studuji RPDB, jestli mi neco neuniklo :-)

Kadopadne i kdyby jste to takto nastavil, tak by to podle me nefungovalo, protoze klient se bude ptat adresy IP1:80; IP1 to preroutuje podle vas na IP2 a IP2 odpovi. Pokud HW stroj (IP1) neudela nat na paketu odchazejicim od IP2, tak ke klientovi dorazi odpoved od IP2. On ale ceka odpoved od IP1. Tj paket od IP2 zahodi.

Linux neumí routovat přímo podle portů, takže si pakety musíte nejprve firewallem označit, a pak už můžete routovat podle fwmark. Pak stačí pakety routovat na typ local – ostatně když si v Linuxu vypíšete routovací tabulku local: ip route show table local najdete tam normálně routy typu local pro IP adresy, které má ten počítač přiřazené.

Router nepřeroutuje IP1 na IP2. Směruje se podle IP adres, ale na rozhraní (na linkové vrstvě). Takže router IP1 „přeroutuje“ na nějaké rozhraní, IP adresa paketu ale zůstane nezměněná – je to úplně normální předání (forward) mezi rozhraními, když máte router se dvěma síťovkami, dělá přesně tohle router pořád. V případě s virtuálním strojem by jen jedna z těch síťovek byla virtuální.

Jj, "IP1 to preroutuje podle vas na IP2" melo znamenat, ze IP1 preda paket na adresu IP2 beze zmeny (neni tam nat). Tj v paketu zustanou puvodni IP adresy.

Nevedel jsem ale, ze pocitac s IP2 vygeneruje jako odpoved paket se zdrojovou adresou podle dst IP prichoziho paketu tedy s IP1. Myslel jsem, ze odpoved muze jit jen se zdrojovou IP adresou nastavenou na rozhrani. Pujdu to vyzkouset.

Dekuji za trpelive vysvetlovani vasi myslenky a preji hezky vikend.

Áha, routování podle fwmark jsem už používal pro nasměrování určitých portů do VPN tunelu, ale tenhle způsob použití jsem neznal. Díky.

oprava: ze IP1 preda paket na adresu IP2 beze -> ze stroj s IP1 preda paket na stroj s IP2 beze ...

Davide, vážně by to chtělo "něco lepšího", protože tvé příklady jsou docela mimo. Přesměrování, které zmiňoval kolega, je používáno skutečně víceméně jen u hotspotů a provozovatel to chce využít jako malou propagaci typu "Internet pro tuto kavárnu poskytuje ten a ten". Zde se moc nepředpokládá, že by sis do kavárny přitáhl VoIP bránu. Pokud chceš odeslat mail nebo uskutečnit VoIP hovor, pravděpodobně to uděláš z mobilu nebo PC. A tam bych neviděl jako problém otevřít si nejdříve prohlížeč a zkouknout tu stránku.

spis by mel byt pripojen tak jak si krabicky reknou

to jo, ale od toho mají svého poskytovatele.

Ale vždyť jo. Ale považovat něco takového za zabezpečení je poněkud přitažené za vlasy. Ostatně i to hloupé 802.1x umožňuje umístění do guest VLAN, ve které se mu to okno prohlížeče s popisem může klidně otevřít.

Znáte nějakého poskytovatele tunelu IPv6 přes IPv4, jehož řešení by nevyžadovalo veřejnou IPv4 adresu? Jsem nejméně za pěti NATama.

Je vyřešen např. SIP přes IPv6? Žádné NATy, fajn, ale v praxi to funguje a existují alespoň někteří operátoři, kteří ho poskytují?

zeby trebas teredo ? Ve win 7 napr bezi defaultne, takze kazdy s win 7 ma "nativne" IPv6 pokud to nema blokle nekde cestou nebo si to sam nevypne.

Díky za tip.

Mezitím jsem rozjel gogoc: vyžaduje registraci na freenet6.net (alespoň mě se anonymně nikam nedostal), instalace v Ubuntu je "$ sudo aptitude install gogoc" a nastavit hodnoty v konfiguráku.

Ale teredo ($ sudo aptitude install miredo) působí sympaticky, žádná registrace, žádná nutná konfigurace. A jel i když jsem si změnil konfiguraci na Microsoftí server, ať nezatěžuju ten debianovskej :-D

Akorát zatím se mi ten gogoc zdá rychlejší, ještě otestuji.

Ještě jsem našel sixxs.org ($ sudo aptitude install aiccu), ale tam mají otravnou registraci, tak jsem to nevyzkoušel.

hodil by se nekdo v cechach:)

Tunnel6

to jo, ale uz je potreba verejna ip a hodne stesti aby adresa 192.88.99.1 u meho providera vedla skutecne k nim

zajimavy:)

Článek je podle mě minimálně z 90 % nesmyslný. Přesto mi pomohl se nad některými věcmi více zamyslet a ujasnit si na ně názor.
NAT pro IPv6 je technicky skutečně nesmyslný, to souhlas. Přesto o čekávám, že přijde jeho čas, horkým kandidátem je tzv. WiFi tethering na smartphonech.
Až se střetne rovina technická s rovinou obchodní, byrokratickou a marketingovou, bude mnoho lidí za IPv6 NAT rádo. Jestli si myslíte, že mobilní operátor vám přes PPP spojení pustí víc IPv6 adres nebo dokonce naroutuje jakkoliv velký (malý) segment, pak jste šťastní. Jestli se o něčem takovém bude s vámi bavit, tak jedině za další peníze navíc. Konkurence tady funguje - když jsou v daném místě a čase k dispozici 2 operátoři s rozumnou nabídkou, lze hovořit o štěstí.
Myslíte, že na univerzitním Eduroamu mi ten Cisco Wireless Manager pustí víc IPv6 adres nebo naroutuje prefix, abych se z virtuálního stroje co mám na notebooku mohl připojit někam na ssh nebo si stáhnout aktualizace? Zapomeňte. Můžu to řešit bez NATu přes HTTP nebo SOCKS proxy. Ale to je podle vás lepší řešení než NAT, když se oprostíte od pravdy, že "NAT je špatný"? Teď mi řešení s NATem pro virtuální stroje dostačuje - ať se připojím do jakékoliv sítě, můžu se z VM připojit ven, můžu tam mít dokonce statickou IP konfiguraci, čímž odpadne ladění na X dalších místech (DHCP/RA server a klient), ale to jsem ochotem s IPv6 opustit.

autor se opil? jak proboha souvisí obecná funkce NAT s jakoukoliv IP, je jedno jestli máme IPv6 nebo IPv4, funkce je stále o tom samém a její využití se nijak nemění... nemáte co psát že plácáte takové bludy?

Komentář je už sice trošku starší, ale stejně si neodpustím reakci ;-).

Argument je to sice celkem rozumný, jen bych teď rád věděl, jak dostanu packet s cílovou privátní IP adresou skrz síť poskytovatele. A vynechme nesmysly typu source routing, který je na většině ISP routerů blokován.

Článek přesně podle hesla
"potřebujeme nějakou hodně vášnivou diskusi... co takhle napsat blábol IPv6 vs. NAT na úrovni 'včera v hospodě jsem zaslechl co to je IPv6 a že tam NAT neni' ".

Když už cítí lupa okurkovou sezónu tak nabízím:
10 důvodů proč je IPv6 špatný když podporuje IPsec.
10 důvodů proč je špatný DHCPv6
10 důvodů proč je špatné mít 64 bitů pro síť
10 důvodů proč je špatný mobilní IPv6
10 důvodů proč je špatný ND
...

Ale dobrá... pokud to NEBYLO myšleno jako provokující článek, nebo článek, kdy autor opravdu nic neví a formou článku chce vzbudit diskusi, ze které se o IPv6 dozví, protože sám je líný odpovědi nalézt....
tak DOUFÁM že si autor před napsáním článku přečetl minimálně RFC 2993, 3027 a samozřejmě RFC 4864. Pak se ale v článku měly objevit argumenty, které ukazují na chyby v těch RFC.
Pokud je autor nečetl, tak se posouváme o několik let zpět, kdy vznikaly tyto dokumenty a byly provázené diskusemi.

PS: Chvilková opilost autora neopravňuje k ignoranci.

Požadavek jsem nevznesl, ta potřeba nebyla zatím tak silná. Spíš to byla taková ilustrace jedné z možných situací. Ale tohle podle mě musí fungovat out-of-the-box, resp. to musí být respektváno jako základní konfigurace. A to se obávám, že nebude. Budou sítě, kde přes DHCPv6 (nebo jiný protokol) budu moci požádat o delegaci prefixu. Budou jiné sítě, kde mi půjde udělat normálně bridge. Budou sítě, kde nepůjde ani jedno z toho, ani nic podobného, a nebude ani možnost nějakého požadavku na správce té sítě. Dnes prostě vždy funguje IPv4 NAT, až na skutečně obskurní situace s proxy a autentizací.

Sám se až příliš často střetávám se situacemi, kdy vůbec nezáleží na tom, jestli nějaká instalace nebo technologie něco umí/neumí/bude umět/teoreticky může umět. Záleží na tom, jak "blbě" ji někdo nastaví a omezí (ať už je důvod jakýkoliv), a jaká je šance s tím něco dělat. Bohužel často taková šance není, a je nutno se smířit se zkriplenou technologií, nebo nemít nic.

Jsem zvědav, jak dopadne implementace IPv6 u českých mobilních operátorů. Už to vůbec nějaký evropský mobilní operátor má nasazeno v provozu? Zajímaly by mě dataily jako způsob přidělování adres a právě možnost "tetheringu" - sdílení PPP spojení z mobilu na další zařízení.

Musim ve vetsine souhlasit s flasi, NAT sice neni temer zadna ochrana, ale presne jak to vysvetluje flasi je to dobre napsane.

NAT ma jeko vedlejsi funkci zvyseni bezpecnosti.

To nic nemeni na tom, ze kdyz nekdo chce zabezpecit pocitac, nebo sit, tak pouzije firewall, tim padem nat nepotrebuje.

Nicmene komu staci k nejakemu ucelu NAT, tak spolecne s tim si zvysi zabezpeceni sve site. Ale jak rikam na zacatku jeto vedlejsi produkt a velmi chatrne. A mozna to sedi presne s analogii tou kouli na dverich.

Kouli na dvere si muzu dat z toho duvodu, aby ty dvere byli jednosmerny. Veldejsi funkce je zvyseni bezpecnosti, protoze se tam nahodny kolemjdouci nedostane, ale kdo chce si samozrejme veme kartu a odevre si. Ano myslim, ze toto je lepsi prirovnani nez to moje na zacatku.

Existence NATu neni ani tak otazka technicka jako spis "politicka". Neni problem se obejit i bez neho, ale nemuzeme zpomenout i na pozitiva, kt. prinasi. NAT dokaze v hodne situacich ulehcit a urychlit reseni ruznych krkolomnych situaci pri migracich zarizeni, testovani novych tras, propojovani siti, zjednoduseni smerovani a podobne. At uz jsou tato reseni elegatni, ci nikoliv, jsou velice casto pozadovana byznysem, protoze jsou levna a rychla, jednoducha pro implementaci. Z tohoto duvodu si myslim, ze at uz se na technicky urovni budou lidi stavet pro NAT nebo proti nemu, tak ve vysledku bude zaviset jen na pozadavcich zakazniku. A kdyz si to vemu z pohledu dodavatelu sit. HW, tak me nenapada jedinej duvod, proc neudelat proprietarni reseni, kt. pak treba neprotlacit jako standard. Proto si dovolim tvrdidt, ze NAT v IPv6 driv nebo pozdejc urcite bude.

V soucasnosti prisel do domacnosti BFU technik nebo kamarad a zmenil jedno nastaveni na hloupe krabicce a vse fungovalo.
Ted pokud bude v siti jeden/dva stroje, co bude mit vyply autokonfig, tak je musite obejit vsechny. A kdyz je otevrene nezabezpecene AP a cela sit v autokonfigu, tak radsi ani nedomyslet.

site-local adresy nic neřeší. Ty jsou pro komunikaci uvnitř switchované sítě

Většina domácích routerů nejde konfigurovat po WAN portu. Změnit konfiguraci IP, znamená dojít k uživateli fyzicky.

Pokud chce někdo psát odborný článek, měl by o dané problematice alespoň něco vědět. Pokud tomu tak není, je lepší neuveřejňovat nic, jinak vaše představy budou nejen mlhavé, ale ještě k tomu nesprávné.

Tento článek bych chápal, pokud by byl uveřejněn na osobním blogu. Pokud ho zveřejní (dříve) odborná Lupa, je to přinejmenším důvod k zamyšlení...

což je jenom hloupá výmluva, protože toto je věc, která se dá velmi jednoduše nastavit přinejhorším změnou firmware. (ostatně stávající krabičky stejně IPv6 neumí, takže svým zákazníkům můžete poradit, co si mají koupit)

Mit IPv4 jako podskupinu IPv6 je *teoreticky* strasne jednoduchy, protoze vzhledem k rozsahu se do nej klidne schova. Staci treba pustit na drat mapovany adresy 0:0:0:0:0:ffff/96. Routery spojujici v4/6 site pak muzou fungovat podobne jako je u 6to4 univerzalni 192.88.99.1. Proste pokud to ISP neresi sam, tak to snad nekam doleze a bude to i nejak fungovat. A nebo pokud vyzaduje spolehlivost, tak si muze rozjet relay u sebe.
Zasadni rozdil je, ze u 6to4 je vsechno pekne staticky a jednoduchy. Tady by to ale znamenalo gigantickej NAT/PAT a ten neomezenej provoz neustoji. Z toho duvodu je NAT64, aby si to kazdej resil u sebe, kde to ma pod kontrolou. Dalsim duvodem pak pravdepodobne bude, ze pokud by se IPv4 namapovalo do IPv6, tak uz bysme se ho nikdy nezbavili, navzdy by se uz muselo pocitat s tim, ze ten rozsah je specialni a ne uplne plnohodnotny IPv6. Takze je lepsi mit to nekompatibilni, ale cistejsi a vsechny potrebny cunarny at radsi dela NAT64 nebo nejaka jeho budouci alternativa.

Prosim, ubezpecte me nekdo o tom, ze "privatni rozsah" v bodech 5 a 6 opravdu nejsou adresy podle RFC 1918 a autor tim mysli normalni verejny adresy, za ktery se treba stydi a nechce je nikomu ukazovat. :)

Mám v domácí síti 3 počítače, ale jeden účet (a IP) u ISP.
V IPv4 toto celkem elegantně řeší NAT.
Jaké je řešení v IPv6?

dostanete tri adresy a nebo krabicka (routrik) dostane jednu ip adresu a jednu podsit a z ni rozda adresy tem trem pocitacum

A co firmy, které mají desítky, či stovky poboček po celém světě (propojené přes VPN tunely) a chtějí mít všude jednotný rozsah IP? Jak zajistí, aby jim ISP přiřadil stejný prefix? My ve firmě máme desetitisíce počítačů po celém světě a IP adresy máme hierarchicky organizované podle fyzického umístění (10.číslo státu.číslo pobočky/podsíť­.podsíť/číslo pc)
Pro obyčejné lození na web není problém mít vnitřní síť úplně oddělenou od internetu s privátními adresami a jednotlivé pobočky propojené přes internet pomocí VPN tunelů a ven se leze přes proxy. Problém je v tom, že máme hromadu serverů, které jsou přístupné z venku a k tomu využíváme NAT (1:1) a taky máme dost stanic, které komunikují s "venkem" po protokolech, kterým se přes proxy moc chodit nechce.

Ale zapomel jste, ze NAT neni firewall, takze k propojeni privatnich adres pres NAT stejne potrebujete firewall, a jestli ne tak jste blazen.
A skutecny firewall je skoro stejne narocny jako nejaka proxy.

Ja nevidim zadny duvod pouzivat privatni adresy, misto nich se daji pouzivat "normalni" adresy oddelene firewallem od zbytku site.

A proc by mela mit standardni domacnost svuj subnen ? Neexistuje pro to zadny duvod.

Jenom pro info, IPv4 je soucasti IPv6 adresovani. Nepamatuju si z hlavy ten spravny prefix, ale da se to dohledat.

protože za chvíli bude mít svou IP adresu i záchod, který bude hlásit doktorovi, jak dobře jste se vys.al :-)

Jenze takova vec neni myslena primarne jako zabezpeceni, ale jako informovani uzivatele. To 802.1x nijak neresi.

no jo, a co teprve chudák klient, který nemá webový prohlížeč a jenom chce přes SMTP poslat jeden mail? Ten si dokonce ani nepřečte, že se má někde autentizovat na přihlašovací stránce.

Tohle se bude řešit jiným způsobem nebo protokolem – třeba jako součást DHCP odpovědi dostanete i adresu stránky, která se vám má zobrazit v prohlížeči. Internet totiž není jen web, takže se snadno může stát, že se v té restauraci budete chtít připojit přes IMAP k poště, přes SSH k serveru a přes SFTP si stáhnout z domova dokument, a nenapadne vás, že byste měl lézt na web, abyste se dozvěděl něco o nutnosti přihlášení.

Jinak to samozřejmě můžete řešit přesměrováním HTTP komunikace, NAT je jen jeden ze způsobů, jak to přesměrování zařídit.

Tak pokud se vám podaří nacpat číslo 9xx do 8 bitů, tak proč ne. Až to dokážete, tak se hlašte v Bradavicích na katedře matematických kouzel a zázraků :-)

Jinak IPv4 je opravdu dostačující v podstatě pro všechno až na ty adresy.

zkoušel jste se někdy připojit k bezdrátové síti, kde je alespoň jeden člověk s Windows? To máte pak routerů víc než by správce chtěl :-)

Hned se přiznám, že do problematiky IP protokolu nevidím do takové hloubky, abych znal jednotlivá RFC ustanovení.

Nicméně.. pokud byste to měli vysvětlit "po lopatě" laikovi, proč nelze vytvořit nějaký nový "firmware" (nastavení, no cokoliv), které by bralo v úvahu, že mohou existovat v rámci IP4 adresy typu 9xx.9xx.9xx.9xx .. zařízení, které by se tímto "flashlo", by je dokázalo správně routovat. Pokud by někdo na svém zařízení nezajistil flashnutí, byla by to pouze jeho chyba.

Z mého pohledu je IP4 naprosto dostačující protokol pro snad 98 procent subjektů? Jeho jediný problém je, že dochází adresy - takto by vznikl tak velký rozsah, který by stačil na velmi velmi dlouhou dobu.

ono totiž (stále z mého laického pohledu), je mnohem snazší si pamatovat 4 skupiny číslic než 6.

abych byl konkrétnější - spousta Windows má zapnuté nějaké ICS (internet connection sharing) a zapnuté IPv6, takže vám to nadeleguje nějaký prefix z 2002:xxx a vy pak lezete přes připojení toho uživatele.

když jsem se naposledy připojoval k nějaké veřejnější síti, tak tam bylo asi 5 takových.

Přepisování cílové adresy je NAT, bez ohledu na to, jakým způsobem se to konfiguruje – a to, že se NAT někde konfiguruje stejným způsobem, jako firewall, ještě neznamená, že NAT a firewall je totéž (pokud tedy FW mělo znamenat firewall).

Přesměrování paketů HTTP komunikace můžete řešit třeba jen routováním a cílový počítač (s „default stránkou“) nakonfigurovat tak, ať odpovídá na libovolnou IP adresu.

Řešení se „zahazováním paketů na port 80 a vracení HTTP redirectu“ by nefungovala, protože HTTP přesměrování se vrací v rámci navázaného HTTP spojení – takže nejde pakety zahazovat, ale je potřeba normálně navázat TCP/IP spojení a v něm udělat přesměrování. Pro naslouchání na portu 80 potřebujete na linuxu normálně vždy rootovská práva, takže řešit takhle „default stránku“ není nijak nebezpečnější, než provoz jakéhokoli jiného webu.

„Napiste, jak by jste to prekonaval, kdyz to neni problem, to by me zajimalo :-)“

Většinou stačí tunelování přes DNS. Ale pokud by si to náhodou chránili (což jsem ještě nikde neviděl), tak si nastavit MAC nějakého regulérního klienta, který se odpojil?

No, ja bych rek ze pro 99% uzivatelu je to tak maximalne sprosty slovo.

Pokud chcete přirovnávat NAT ke dveřím, tak NAT jsou zavřené, nezamknuté dveře bez kliky (s "koulí").
Čili dostane se tam (bez dodatečných bezpečnostních opatření) úplně každý, kdo se tam bude chtít dostat a současně je schopen vynaložit nějaké drobné úsilí a má nějaké drobné znalosti. Ale nedostane se přes ně malý kluk, nedostane se tam náhodný kolemjdoucí.
Veřejná IP adresa jsou odemknuté dveře s klikou - dostanou se tam (bez dodatečných bezpečnostních opatření) úplně všichni - i ten malý kluk i ten náhodný kolemjdoucí.

NAT celkově bezpečnost zvyšuje. Dokáže filtrovat roboty, kteří pročesávají adresu za adresou a subnet za subnetem a zkouší, jestli na portu X neběží proces Y ve verzi Z, ke kterému má ten robot připravený exploit. Pokud nemáte firewall, tak jste za NATem ohroženi méně, než bez NATu.
V případě domácích uživatelů, kteří se nechovají aktivně nebezpečně (tedy ti, kteří nenavštěvují rizikové stránky a nestahují a nepoužívající cracky apod.) je rozdíl být/nebýt za NATem silně korelující s rozdílem být/nebýt zavirován. V době, kdy aktualizace windowsů nebyly standardně nastaveny na automatické to bylo zcela markantní, dneska už to tak zjevné nebude, ale nějaká korelace tam bude pořád. Nemluvě o tom, že počítač za NATem je pro škodlivý software méně cenný než počítač přímo v internetu.
Já bych si svůj domácí počítač "chránit" pouze NATem rozhodně nedovolil. A nedoporučuji to ani svým známým. Ale riziko s NATem je prostě menší, než bez něj. A jelikož běžný domácí uživatel je obvykle vystaven pouze útokům anonymním, automatizovaným a hromadným, tak NAT supluje firewall velmi dobře. Čemu by zabránil firewall zabrání NAT většinou (a pro jistotu: většinou != vždy) taky a čemu by firewall (paketový filtr, stavový firewall, proxy) nezabránil, tomu NAT nezabrání taktéž.
Situace je pochopitelně zcela jiná v případě firemní sítě, která se s mnohem větší pravděpodobností může stát obětí cíleného útoku, proti kterému je NAT opravdou pouze formální překážkou.

Pokud si někdo myslí, že NAT nejde zvenku překonat, tak je hlupák a opravdu zažívá falešný pocit bezpečný. Ale stejně směšné mě připadá, když někdo popírá, že NAT chránil a chrání miliony domácích uživatelů před roboty automaticky hledající otevřené porty s běžící děravou službou.

Píšete obecně o NATu, a přitom nejspíš myslíte nějaký konkrétní typ NATu, při kterém z venku není možné normálně navázat spojení. Je otázka, jaké množství uživatelů je právě za takovýmhle NATem. Bez toho, aniž bych viděl konkrétní nastavení NATu, bych se neodvážil tvrdit nic o tom, jak brání či nebrání třeba automatizovaným útokům. Takže je rozumné předpokládat, že nechrání nijak – a pokud někdo má náhodou NAT nastaven tak, že přes něj roboti neprojdou, má prostě štěstí. Rozhodně bych nemátl neznalé uživatele tvrzením, že NAT velmi dobře supluje firewall – není k ničemu dobré něco takového předpokládat.

Zrovna pro roboty není nic jednoduššího, než pokoušet se automaticky projít i tím NATem – robota nic nestojí vyzkoušet pár možností.

Aaaa, dalsi co nedokaze pochopit, ze NAT s ochranou stroje za nim nema nic, tedy absolutne nic, spolecneho

A navic plka o necem, cemu naprosto evidetne ani zbla nerozumi.

1. Obávám se, že odmítáte přistoupit na to, že existuje i jiný pohled na věc. Vy to prostě berete individuálně - já jsem za nějakým NATem, tudíž musím předpokládat, že je nastaven tak, že je snadno prostupný a tudíž ho nesmím považovat za nějakou ochranu a tudíž si musím zabezpečit ochranu jinak. To je naprosto v pořádku a s tím souhlasím.
Jenže já jsem psal z globálního pohledu. Prostě ty NATy, které se používaly a používají dokázaly spoustu primitivních automatizovaných útoků odrazit. Tudíž procento zavirovaných za NATem bylo nižší, než procento zavirovaných bez NATu. Prostě vedlejším produktem NATu je statisticky se projevující ochrana. Statisticky, tudíž by bylo velmi nemoudré se na ni spoléhat. A to vaše "štěstí na ten spravný NAT" prostě tvoří část té statistiky. A "štěstí na hloupý útočící robot" je také její součástí.
Píšete, že pro roboty není nic jednoduššího, než se pokoušet automaticky projít NATem. To je otázka. Já vím, že před pár lety to drtivá většina robotů nezkoušela (a současnou situaci nesleduji). Zřejmě měli jejich tvůrci zato, že je snazší využít omezenou kapacitu linky k hledání na dalších veřejných IP adresách, než zkoušet hledat za každou IP adresou privátní rozsahy.

Napsal jsem "Já bych si svůj domácí počítač "chránit" pouze NATem rozhodně nedovolil. A nedoporučuji to ani svým známým." Pokud by z toho někdo nabyl dojmu, že je dobrý nápad spoléhat se na NAT, pak musím jenom opakovat, že je to velmi špatný nápad. Myslím, že moje přirovnání k nezamknutým dveřím s koulí hovoří za vše - tento způsob zabezpečení si normální člověk dovolí, pouze pokud je fyzicky přítomen v bytě - tedy je schopen kontroloval, kdo těmi dveřmi opravdu prochází - počítačovou řečí, ten kdo má navíc firewall.

Nejsou to moje přání - já si vůbec nic ohledně NATu nepřeji.
Jsou to moje dojmy. Jsou to moje dojmy podložené zkušenostmi s různými domácími uživateli. Jsou to moje dojmy podložené komunikací s lidmi, kteří se bezpečností domácích uživatelů zabývali profesně. Jsou to moje dojmy podložené zkušeností s jednou komunitní sítí čítající několik málo stovek členů (čili dost obyčejných uživatelů) poté, co se stalo s počtem zavirovaných windows v síti poté, co zavedli NAT a poté, co ho zase zrušili (když získali dost veřejných IP adres).
Nejsou to tvrdá data, ale je to dost, abych to mohl v tomto typu diskuze prezentovat.
Už si přesně nevybavuji, jestli to byl Sasser, Blaster, nebo jak se jmenoval vir, cto automaticky napadal děravou službu RPC na portu 135 ve Windows NT větve. Ale vím, že tam to bylo zcela markantní - kdo neměl zaplátované windows a měl veřejnou IP adresu (a neměl firewall), tak byl nakažen. Kdo byl za NATem, tak většinou nakažen nebyl. Anebo nebyl nakažen až do doby, kdy někdo za NAT donesl počítač nakažený odjinud.
Ale NAT (nebo jestli chcete, tak přesněji implementace NATu u drtivé většiny ISP, nebo domácích routerů) prostě statisticky znamenal rozdíl.

NAT v praxi prostě fungoval jako koule na nezamknutých dveřích - jakkoliv mohl fungovat i jinak (i jako klika, možná i jako dveře dokořán), ale část útočníků zastavoval a IMHO i zastavuje dál (píšu IMHO, protože zcela aktuální situaci neznám, ale současně nepředpokládám, že by došlo k zásadní změně).

Jak čtu debatu, zcela jasně vidím, že odpůrci NATu jako bezpečnostního prvku nepřišli na to o jaký případ se jedná. Sice se holedbají kolik druhů NATu znají, ale buď jsou to nezajímavé úchylnosti stvořené na jakýchsi obskurních linux bednách, nebo pracují ve firemní sféře, kde jsou firewally automaticky a NATováním se řeší obskurnosti které by při IPv6 nebyly. Ale o to vůbec nejde, jde o jíný případ a není to žádný ojedinělý případ.
Jedná se o miliony IPv4 NAT krabiček používaných v domácnostech na přípojkách ADSL a Kabelovky. Všude tam, kde mají pro připojení více kompů malý router s NAT n:1. Při standardním nastavení se všechny stroje maškarádují za 1 veřejnou IPv4 od ISP. Opačným směrem není žádné NAT pravidlo. Proto jsou všechny pakety z inetu zahozeny. Dá se říci, že zcela stejně jako pravidlo drop na firewallu. Takže uvnitř domácí sítě nemusí byt žádný firewall (který si bfu-admini stejně hned vypnou při prvním problému se spojením MSWin sdílení), sdílené složky mohou být bez hesel (a taky v drtivé většině jsou) .. nemluvě o rychle přibývajících různých multimediálních krabičkách, které jsou také zcela otevřené.
Při použití IPv6 bez nějaké chytré krabičky/firewallu - v tom místě kde teď je ten NAT routřík - máte všechno otevřené celému světu a musí se vše uzavírat přímo na každém zařízení a na některých to ani nepůjde.
Chci tím prostě říct, že současná nutnost IPv4 NAT N:1 rovnou vyřešila "zabezpečení" vnitřní sítě proti přistupu zvenku, je to automatická vlastnost. Milony kompů s děravými MSWin za těmito krabičkami byly chráněny proti wormům typu Blaster apod.
IPv6 bez NATu přinese jen větší složitost v nastavení bezpečnosti. Přímé připojení BFU kompů na inet bude cesta do pekel.
Nejsem zastánce nutně vracet NAT N:1 , ale myslím si, že nejjednodušší a efektivní pro domácnosti bude dát na přívod k ISP malý firewall, který nastaví zabezpečení domácí sítě globálně podobně jak to dělala IPv4 NAT krabička - ven všechno, dovnitř nic.
A stejně v to nemám moc velkou víru. Ten IPv4 NAT N:1 si BFU selfadmini v domácnosti vypnout nemohli a udělat "díru" zvenku je pro ně poměrně složité. Takže byli chráněni. Nemluvě o tom, že nemuseli nastavovat defakto nic, na WAN si to vzalo DHCP a na LAN to DHCP poskytovalo. Pokud nová IPv6 firewall krabička bude mít možnost jednoduše zlikvidovat ten zákaz paketů zvenku, BFU to udělá bude problém. Nemluvě o tom, že bude muset nastavovat přidělené rozsahy IPv6 adres.
Takže, zkuste se myslet nad tím, jaké nastanou problémy v oblasti největšího nasazení ISP přípojek - domácnosti. Opusťte svůj svět firemnich apod přípojek, kde to vůbec problém není. :-D

Pro existenci NAT zadne duvody nejsou.

O strukturu site domacnosti se starat nemusite, kazdy jejich zarizeni jednoduse dostane nejakou IP. Nevidim v tom zadny problem vzhledem k rozsahu adres. Pokud si domacnost pozada, jednoduse pridelite prefix, stejne jako dosud jednu IPv4. Navic nebude muset kazdy BFU vecne resit po netu, proc mu nefunguje tohle a tamhle ... jak ma co kde nastavit ve sve hloupe krabce aby mohl byt active ...

Prechod k jinemu ISP zakaznik vubec nepozna. Pokud poskytuje do site nejake sluzby, pak jiste pouziva DNS, pokud ne, je mu uplne sumafuk ze se mu zmeni adresy.

:-D
Ne. Neexistují důvody rozjíždět IPv6 za NATem. NAT je potřebný v určitých specifických situacích, které jsem popisoval.

Toho, že IPv6 s IPv4 nefunguje tak jak píšu jsem si vědom. A právě v tom spatřuji zásadní problém. IPv6 protokol není navržen jako kompatibilní, aby IPv4 v sobě zahrnul, ale jako druhý - paralelní protokol. Pokud chce člověk provozovat oboje, buď udělá tunely, dual-stacky, nebo má smůlu. Zkrátka se už v návrhu nepočítá s přechodem na IPv6, ale s dlouho trvajícím, až nekonečným souběhem. A to je dost nepraktické...

"Autor bohužel vyrostl v době, kdy se NAT stalo nedílnou součástí síťové architektury a bohužel se nedokáže od tohoto paradigmatu odpoutat."

Ano, to nepopírám...

A ono snad překlad adres bezpečnost nezvyšuje. Překonání NATu obvykle vyžaduje nějakou snahu a velikost této snahy je pro většinu lidí dostatečná.

Nesuďte autora, někdo si může myslet naopak o Vás že jste magor.
Třeba já si to myslím, ale netvrdím že magor opravdu jste :-D jen mi tak připadáte.

dostanete blok /64 nebo /48, pokud chcete. Co víc chtít?

http://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/

A jeste doplnim, ze jsou veci, za ktere by se melo trestat.

"NAT je soucast firewallu" je asi stejna pravda, jako "husite jsou hrdinove". Oboji je blbost, oboji nekdo neustale opakuje a oboji povazuji za trestuhodne. Tenhle pan at se venuje rizeni projektu ale ne proboha psani clanku o sitich a tim min o IPv6.

Vubec nechapu, proc je to soucasti jinak pomerne dobreho serialu.

Ale on tomu asi opravdu nerozumi, kdyz nevi zakladni vec ip admina o tom ze NAT neni firewall.

Pripomina mi to trochu rozdil mezi slovem hacker a cracker, taky to spousty IT radoby odborniku nevi.

Rad predvedu, tak snadny utok zvladnu i ja. Co myslite ze vas NAT udela s paketem s cilovou privatni IP ? No jako kazdy spravny router ji posle na rozhrani kde ten rozsah existuje. A voiala, spojeni je navazano.

Ani k jednomu uvedenému opravdu, ale opravdu nepotřebujete NAT.

Nejen že, k uvedenému NAT nepotřebujete, ale navíc NAT to celé spíš komplikuje. Takže tenhle argument je poněkud mimo.

NAT je zlo, které doufám časem vymizí a jeho zastánci v IPv6 se budou houpat za svoji chlubu v průvanu.....

Snažíte se sice psát z globálního pohledu, ale není to nic jiného, než vaše dojmy. To „NATy dokázaly“ a „vedlejším produktem je statisticky se projevující ochrana“ nemáte ničím podložené, jsou to jen vaše přání. To vaše přirovnání ke dveřím s koulí není přesné – ve skutečnosti nevíte, jestli jsou ty dveře většinou s koulí, s klikou nebo otevřené dokořán.

Fak nechapu jak nejaky "admin" muze obhajovat NAT?
Snadno protoze pro laickeho uzivatele je prave NAT jena z zakladnich ochran. Ano samozrejme ze lze podobne ochranit domaci sit i firewalem na klasickem routeru bez prekladu adres, ale je to zbytecne slozite a snadneji se udela chyba. Osobne si myslim ze pro naprostou vetsinu uzivatelu internetu nepredstavuje NAT resp. maskarada zadny problem.

Ahoj Petře, nevím zda máš v plánu provozovat v Jetnetu IPv6 za NATem, ale na tvém místě bych se tomu obloukem vyhnul.

U toho 6 paket prechodu na 4 rozhranni se nelze nez pousmat, jestli to autor mysli vazne. Ocividne jeden detail nedomyslel.

A k zaveru? IPv6 je idealni "zaklad", ktery je dobre vynutit jako minimum co zakaznik dostane a bude mit skutecny internet a ne jen peepshow net nad ktery se ruznymi berlickami v kazdem protokolu/aplikaci opravuje, aby se to internetu aspon z casti podobalo. Druha vec je stav, kdy ten peepshow net lidi vyzaduji, tak je potreba jim to nabidnout i nad IPv6 jako moznost volby.

Já samozřejmě nemůžu vědět jak to dotyčný myslel. Firewall je výraz používaný čistě ve smyslu zabezpečení a nebo jako název pro balík nástrojů (filter, mangle, nat...). Pravdu máme asi všichni :-)

viz.:
http://www.mikrotik.com/testdocs/ros/2.9/ip/flow.php

zkuste v google zadat "NAT punching"

"Jak už tu psal jeden uživatel - Když bude poptávka, bude i NAT."

Poptávka po čem? NAT není Chuck Norris, aby dokázal nemožné. Je to defekt, který vznikl kvůli nedostatkům v původním návrhu IPv4 a není nejmenší důvod jej zavádět někam, kde lze onu poptávku uspokojit uplně jinými mechanismy. Někdo tu zmínil přirovnání s kladivem - proč jej nepoužít na porcelánové nádobí, když to s plechovými hrnci přece fungovalo, že?!

Až na to, že NAT žádné zabezpečení nepřináší.

mám router s NATem a za ním PC s vnitřní adresou. Nechám si předvést jak se na něj dostanete...

"Internet funguje na základě NATu? Můžeš uvést nějaké příklady? Který peeringový uzel funguje na natu? Mám se zeptat na NIXu? Nebo snad hostingu?"

Pane Crhonek nedělejte ze mě blbce. Všichni víme, kolik uživatelů přistupuje k internetu přes NAT. Možná sem se nevyjádřil přesně, internety by sice fungoval ale neměl by uživatele, protože nejsou adresy, ale víte jak jsem to myslel, tak mě nemusíte hned chytat za slovo.

Snažím se pouze prosadit liberální pohled na věc, tedy kdo chce NAT ať ho má, kdo nechce ať ho nemá.

Prominte, ale blbce ze sebe delate sam, a to za prve timto clankem, a za druhe diskusi pod nim...

liberální pohled? spis krapet konzervativnejsi;)

NAT je výsledek evoluce. Bez něj by dnešní internet nefungoval. Trvám na tom, že chirurgické odstranění této užitečné pomůcky ze sítí je zhovadilost. Všichni se třesete na to, aby jste měli konečně plnohodnotný internet, ale žádný ISP nemá důvod svou IPv6 síť ven za běžného provozu natovat. Ale proč by ten NAT nemohl použít, když ho v konkrétním případě bude potřebovat? Protože někdo řekl, že je to špatné?

Speciálně v ČR jsou stovky sítí, které mají spoustu uživatelů a vlastní AS nemají. A speciálně tyto sítě s IPv6 "shoří jak svíce". Až totiž dojdou IPv4 adresy a ani si budou chtít kvůli IPv6 zařídit vlastní AS tak nedostanou žádné IPv4 adresy, na které by překlopili současný IPv4 provoz. Zjednodušeně řečeno se ocitnou v pasti. Já AS i vlastní IPv4 adresy mám, takže mě to netrápí, ale jiné to bude bolet víc.

Jak už tu psal jeden uživatel - Když bude poptávka, bude i NAT. A odpůrci ať se klidně stavějí na hlavu...

Obávám se, že jste můj příspěvek buď nepochopil, nebo úmyslně překroutil.
Pokud budou mít domácí IPv6 krabičky nastaveno takovéto filtrování, tak běžnému uživateli uberete trochu (málo) starostí s bezpečností a přidáte mu trochu (hodně) starostí s dostupností různých služeb.

Já v této diskuzi neobhajuji potřebu NATu na IPv6 ani na IPv4. Já jenom tvrdím, že NAT má v praxi statisticky ochranou funkci (v daném čase, při daném nastavení a jako vedlejší efekt).

ad 1 - ISP by měl mít vlastní AS s BGP, měl by mít připojení do více sítí. Pokud by se ale mluvilo o zákazníkovi, tak tomuto problému rozumím. Plánované přechody k jinému ISP v IPv6 usnadňuje možnost mít přiděleno více adres.

ad 2 - v rámci sítě ISP není potřeba a ani vhodné dodržovat hierarchickou strukturu IPv6 adres z důvodu úspor ve směrovacích tabulkách.

ad 3 - měnit najednou adresy všech nameserverů je zhovadilost i v IPv4. Pokud se to udělá postupně, tak není problém - pokud tedy nezpřístupňujete zákazníkům jen jeden nameserver.

ad 4 - mohu zákazníkovi přidělit dva IPv6 adresní rozsahy. Z představy, že bych měl v IPv4 pro zákazníky udržovat měsíce výjimky typu DST-NAT se potím hrůzou.

ad 5 - toto řeší v IPv6 ULA adresy ve spojení s proxy servery,

ad 6 - opět ULA adresy,

ad 7 - pravděpodobnost kolizí v IPv4 je o mnoho řádů vyšší,

ad 8 - prostudujte si http://anonymous-p2p.org/index.html a najděte si programy, které podporují IPv6 (popřípadě podpořte finančně naprogramování podpory pro IPv6 - např. pro I2N),

ad 9 - jak jste sám psal, řeší NAT64

ad 10 - tato oblast se příliš neřeší a ani se tomu nedivím. Tento problém nastane u různých specifických zařízení (kamery, printservery, sondy, ...), které ale stačí mít dostupné v rámci privátní IPv4 sítě. Pokud by potřebovali komunikovat přes IPv6, tak se využijí proxy servery.

Pro existenci NATu v IPv6 bych viděl dva důvody:
- připojování malých koncových zákazníků (hlavně domácnosti), neboť jich je mnoho a použití NATu znamená, že se nemusím starat o strukturu jejich sítě,
- usnadnění přechodu zákazníka od jednoho ISP k druhému,

To je zas článek, který mě po ránu nadzvedl ze židle. Takovou snůšku pseudoargumentu jsem už dlouho nečetl. Většina popisovaných problémů má elegantní řešení v IPv6 a zbytek je jen o lenosti něco někde nastavit.

To chce jen lupa rozvířit vody kontroverzními názory?

Kolik jste konfiguroval routerů na linuxu nebo mikrotiku?

Ok, tak tedy na linux-based zařízeních je NAT součástí firewallu. Že to je jinde jinak na věci nic nemění. Zabezpečení je vedlejším produktem NATu, cílem samozřejmě ne.

Otevrene priznavam, ze jsem magor. To nicmene nic nemeni na tom, ze kolegove v tomto threadu maji naprostou pravdu. Autor o IPv6 vi asi tolik co ja o vas.

Spokojenost?

A proč byste to tak nemohli mít dál? V případě IPv6 jsou pro tohle určeny unikátní lokální (unique-local) adresy, které vám mohou vyhovět naprosto stejně.
Jinak doporučuji ke studiu toto...

Neda se nic nez souhlasit.
Velice trefne napsano.

Nahradit privatni ip adresy normalnimi adresami je to nejjednodussi co muze byt. Prave proto je tolik IPv6 adres, kterou muze dostat kazdy milimetr vseho v byte a porad jich bude dost.

Zeptejte se hracu, ti potrebuji primy pristup do internetu a prave NAT je pro ne nejvetsi problem, ktery resi ruznymi servery v internetu. Des a hruza. Fak nechapu jak nejaky "admin" muze obhajovat NAT?

No predevsim bezna domacnost nepotrebuje router ani firewall v extra kabce, protoze BFU si to stejne neumi nakonfit a ted je tato konfigurace standardem predevsim proto, aby vubec bylo mozne pripojit vic nez jedno zarizeni.

Pokud by bylo i na IPv4 pridelovano bez kecu potrebne mnozstvi adres, tak to neni treba ani ted.

Firewall je firewall. S prvním jsem si hrál někdy v roce 1994, byl to TIS. Nebo když si člověk vzpomene třeba na socksifikované klienty, začíná těm mladým závidět, jak jim je všechno jasné ;-).

Detaily, nat je pruser pro cokoli. Resim dnes a denne dotazy proc, jak ... a dycky je to o nejake blbe krabce s natem. Ostatne jak se rozmahaji p2p site, tak spousta tech krabek prestava stihat, zkratka na natu nejsou schopny udrzet tisice konexi.

co treba RFC a vyhledy do budoucna?

Zaměňuješ nástroj a mechanismus. Nenech se zmást tím, že používáš shodný nástroj na zcela rozdílné mechanismy.

A on snad existuje nějaký důvod, aby ho neměla?

Rozumne to je, pokud to dotycny tak chce, ale pokud nema ani paru o nejakem routovani, nema smysl to resit. Proste bude na subnetu spolu s dalsi tisicovnou klientu.

Deset duvodu, proc necist Lupu?

NAT je součást firewallu

Obavam se, ze argumentace zde uvadena vychazi ze znacneho nepochopeni principu IPv6 protokolu. Takze jen nekolik komentaru k jednotlivym bodum:
1. ISP ktery nema BGP a vlastni AS jen tezko muze byt nazyvan ISP. Spise bych volil termin preprodavac internetove konektivity. Nicmene to samo o sobe samozrejmne neresi problem zmeny ISP. Ten resi budto moznost pouziti vetsi mnozstvi adres na jednom rozhrani, ci "Provider Independent Adress space"
2. opet lepe resitelne pomoci vetsiho mnozstvi adress pricemz mechanismy ND/RA (pripadne DHCPv6) resi dynamicky alokovane adresy a staticke je treba resit zvlast.
3. NAT nepracuje bohuzel pouze z hlavickami, u nekterych protokolu je nucen se divat do vnitrku paketu jako napriklad FTP, SIP a bohuzel i prave DNS (to nic nemeni ze pripadna proxy by to mela jeste slozitejsi)
4. zarizeni ktere neumoznuje zmenu adresy sakra neco takoveho existuje?
Pripoustim aplikaci jejiz licence je vazana na IP adresu ale to je opet potreba resit jinak!
5. privatni rozsahy v BGP tabulce :-)), pokud chci komunikovat v internetu je potreba mit Globalni adresu, pokud chci komunikovat lokalne je potreba mit Site Local adresu, opem v IPv6 tech adres mam vzdycky vic a kuprikladu link local adresa se pouziva pro ziskani jakekoliv dalsi adresy
6. Tradicni omyl- zamena funkce NATu s Firewallem, ano NAT cast te funkcionality take poskytuje, privatni rozsah proste neni dostupny z internetu!
7. Opet pro Site local adresy existuji 2 moznosti - nahodne generovana (nepamatuji si presne kolik bitu ma byt nahodne generovano, ale i pokud by to bylo pouze 32 tak pravdepodobnost bude 1:zhruba 4 miliardam. Pokud to neni dost je mozno si i site local adresu nechat priradit od IANA a pak mate svoji vlastni 10.x.x.x kterou nema nikdo jiny
8. Navrhuji zakazat vberejne osvetleni, protoze pokud lampy na ulici sviti krade se vyrazne snaze a pravdepodobnost odhaleni je minimalni!!
9 a 10 tohle je otazka protoze specifikace NAT 4to6 a 6to4 zatim neni hotova a predchozi snahy jsou zruseny, opet nejvetsi komplikace je ALG s tim ze pokud protokol pouziva adresu uvnitr paketu (nejen v hlavice) viz DNS, FTP, SIP..... tak je potreba pro nektere komunikace menit i vnitrek paketu, v takovem pripade se meni v paketu i delka a treba muze presahnout MTU a pak je potreba fragmentovat coz je velmi komplikovana operace a prilis neskaluje takze to nebude jednouduche ale v teto oblasti pravdepodobne jeste nejaky cas NAT zustane.
Zaverem: pokud se clovek nauci resit veskere problemy pomoci jednoho nastroje napr. kladiva tak proste cely zivot resi problemy pomoci kladiva- zatluce hrebik, opravi mosazne nadobi a dokonce s kladivem v ruce i manzelka rychle poslechne. A protoze tomu cloveku tak vsechn o funguje tak pak proste pouziva kladivo i na veci na ktere kladivo neni uplne nejvhodnejsi napriklad porcelanovem taliri kladivo nepomuze a s manzelkou je lepsi promluvit.
.

Slysel jste nekdy o site-local adresach?