Vlákno názorů k článku 10 důvodů, proč mít NAT na IPv6 od davro - Ale vždyť jo. Ale považovat něco takového za...

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.

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.

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

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

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.

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

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

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.

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... :-(

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.

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

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.

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.

> 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?

„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?

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

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.

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.

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.

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.

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.

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.

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.

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 :-)

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.

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.

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

oprava: propojeni -> pripojeni

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 :)

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.

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 :-)

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)

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

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.

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? ;-)

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.

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

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.

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.