Portál AbcLinuxu, 1. května 2025 22:27
Evangelizátoři IPv6 se nám opakovaně snaží vtlouci do hlavy, že maškaráda (source NAT) je zlo a že s příchodem IPv6 nic takového není potřeba. Jakkoliv chápu, že je maškaráda v současnosti dost nadužívána a občas i zneužívána (především poskytovali internetového připojení) a že ji proto dost lidí nemá rádo, jsem přesto přesvědčen, že může být i užitečná (pokud člověk ví, co dělá). Přesto zaráží, že se tvůrci IPv6 tak sveřepě (a dogmaticky) tomuto konceptu brání a nenabízejí jeho adekvátní náhradu. Zde bych chtěl ukázat příklad použití maškarády, který je dle mého mínění naprosto legitmní a k němuž jsem adekvátní náhradu u IPv6 nenašel.
Jelikož je možné, že jsem něco přehléhl, vyzývám všechny propagátory IPv6, aby mi dokázali, že „to jde“ a není to řádově složitější, než běžná maškaráda pod IPv4. Co požaduji:
Všechny tyto požadavky maškaráda na IPv4 elegantně řeší tím, že zamaskuje vnitřní zařízení pro pozorovatele zvenčí pod jednu IP adresu.
Samozřejmě, je mi jasné, že má maškaráda dost neblahých účinků (zejména znemožňuje přímou adresaci daného zařízení zvenčí) a že tedy otázka, zda-li v určitém případě zvolit maškarádu, nebo „oteřenou“ síť s přímým adresováním strojů ve vnitřní síti by měla záležet na vlastních prioritách (paranoia versus snadné používání obskurdních protokolů) a každý by měl mít právo volby.
Osobně mi přijde, že kromě reálných P2P protokolů (které např. osobně nemám momentálně důvod využívat), je už dnešní internetový svět na maškarádu velmi dobře vybaven (viz např. ICE pro obcházení NATu pro internetovou telefonii a podobné protokoly) a lze s ním žít poměrně beproblémově.
Proto jsem přesvědčen o tom, že je zlo, když se tvůrci IPv6 snaží násilím (resp. z využitím paniky s nedostatkem IPv4 adres) prosadit jeden přístup a potlačit přístup druhý. IMHO je tento dogmatismus taky základní brzdou toho, proč je IPv6 tak „zašmodrchané“ a jeho nasazení se tak dlouho táhne. Ale to by asi bylo na jiný zápisek.
Tiskni
Sdílej:
tak tam strčte proxy server
+1
Můžete mi vysvětlit, proč by měl někdo zapotřebí takhle maskovat zařízení ve vnitřní síti? Protože v souvislosti s tím mě napadají jen slova: zbytečnost, nesmysl, security through obscurity a demence.Díky za reakci, pro mě je tenhle jen další potvrzení mého názoru na fanatičnost propagátorů IPv6. K otázce proč by měl někdo zapotřebí tohle maskovat: a proč by nemohl? Stejné, jako bych se zeptal, proč by měl mít někdo zapotřebí adresovat každý stroj ve vnitřní síti jednoznačnou adresou (když už dnes lze NAT přecházet bez problémově). Jenže já nemám potřebu vnucovat někomu, jak má dělat to, či ono, takže se takovýchto výroků zdržím
A když už máte opravdu potřebu dělat takové skopičiny, tak tam strčte proxy server.A proč by se měly věci dělat složitě, když jdou jednoduše ()? To je podobné, jako bych se ptal, proč potřebuješ mít IPv6 konektivitu od providera, když dnes existuje 100+1 různých způsobů, jak to protunelovat...
Stejné, jako bych se zeptal, proč by měl mít někdo zapotřebí adresovat každý stroj ve vnitřní síti jednoznačnou adresou (když už dnes lze NAT přecházet bez problémově)To v žádném případě není pravda. Pokud chceš tvrdit, že je, tak mi ukaž nastavení NATu, které mi port 80 přesměruje do vnitřní sítě na správný ze sta strojů. Web server běží na všech a v každém okamžiku je potřeba, aby bylo možné připojit se na všechny naráz.
Díky za reakci, pro mě je tenhle jen další potvrzení mého názoru na fanatičnost propagátorů IPv6.Zloděj křičí „chyťte zloděje“. Já osobně si myslím, že jediným fanatikem jsi v tomto případě ty. Definici fanatismu naplňuješ beze zbytku. Jsi neinformovaný a přitom svůj nepodložený názor hystericky hájíš. Dokonce se snižuješ až k takovým věcem, že argumentuješ proti Lubošově názoru v domění, že tím vyhráváš svou svatou válku proti IPv6 :). Přitom Lubošovi je tenhle „problém“, jak je vidět úplně jedno.
to neni fanaticnost ... i pres NAT de celkem v poho zjistit cse co se snazite tim maskovat ... protunelovat nat neni takovy problemmm,
a proxy s fw je jednodussi reseni nez nat a k tomu to ulevi provozu ...
Znáhodní adresy zařízení pro komunikaci navenek, takže je pak těžké odhadovat, kolik jich tam jePřečti si ještě jednou blog:
aby nebylo dokonce možné určit, zda dva streamy patří jednomu zařízení, ani v rámci krátkého časového úseku (třeba 5 minut).A RFC4941:
New temporary addresses are generated periodically to replace temporary addresses that expire, with the exact time between address generation a matter of local policy.
Je skutečně maškaráda (NAT) tak zbytečná a špatná?Jo.
Jen se těším se, jak nadšeně budete souhlasit, až bude do blbů nadávat vám nebo někomu vám sympatickému…Tak opětuju palbu a nebudu kňourat, ne? Nebo prostě mávnu rukou, vstanu od počítače a půjdu si udělat čaj a nebudu kňourat. Nebo vymyslím ďábelský plán jak dotyčnému shodit komplet síť/portál/počítač a … a nebo je ještě možnost, že to budu řešit jako Kubeček.
Jen si myslím, že není vhodné, aby šéfredaktor v diskusích nadával diskutujícím.Jo, jo. To by měl být
vzdělaný, eugenicky vypěstovaný člen z vyšších kruhů s bravurní rétorickou schopností, čistý jako lilie nebo tak něco, že? Nevím jak kdo, ale já teda chodím na portály kde je šéfredaktor člověk, který se nebojí prezentovat svůj názor (i takovou formou) než nějaké pokrytecké pako, které má nos v zadnici diskutujících tak hluboko, že kdyby ho měl jen o kousek větší, tak je z něj Pinocchio, mnohem radši. Ale proti gustu…
Nevzpomínám si, že by Robert Krátký něco takového udělal - nebo přinejmenším, že by to udělal, aniž by dotyčný nejdřív urážel jeho.Tak to je hodně závislé na úhlu pohledu. Protože to já si zas pamatuju. Za sebe bych totiž v podobné situaci asi napsal Ponkrácovi ještě něco horšího.
funkci na tomto portáluNejvyšší čistmistr – kazatel všeho dobra? Mi zas asi nějak uniklo.
nezbyde mi než se s tím smířitNo, asi tak…
nevyslovuje. Ďolík je pako, o tom žádná. Furt 1000× lepší než co tady dlouhodobě předvádí p. Astronaut (aspoň teda z mého pohledu).
Ja súhlasím s Michalom. Do autora blogu ste sa pustili hlava nehlava a urážky začali lietať priskoro a len preto, že s ním nesúhlasíte. Podľa mňa sa kultivovane spýtal a zaslúži si kultivovanú odpoveď. To, že niekto v IPv6 NAT nevidí zmysel, alebo ho dokonca považuje za škodlivé je legitímny postoj. Rovnako legitímne ale je, chcieť NAT napriek tomu.
Odbočka: Prevádzkovať sendmail SMTP server na počítači, ktorý má dynamickú IP a ktorý používam prakticky sám je blbosť. Je to zbytočnosť. Je to overkill. Je to komplikovanejšie konfigurovať ako napr. postfix, atď. Napriek tomu ho prevádzkujem. Čo je koho do toho, aké sú moje dôvody? Poďme sa baviť o tom, či problémy načrtnuté v blogu ešte niekoho trápia a ak áno ako ich riešiť.
Vlastne by bolo primerané prihodiť do blogu anketu:
anonymita strojov v LAN je niečo čo
( ) chcem riešiť
( ) je mi fuk
Ak je vám fuk fajn. Ak je to fuk 95% čitateľov, tak by sa Peter mal zamyslieť či náhodou nerieši blbosť. Ak to chcete riešiť, raďte ako na to.
Ja súhlasím s Michalom.Já taky v něčem souhlasím s Michalem. A v mnohém ne, protože 1) I (svatý) Robert už někomu v diskuzi řekl, že je to blbec. 2) Pokud mi Luboš napíše, že jsem blbec, budu to brát jako námět k zamyšlení a budu přemýšlet nad tím, čím jsem to způsobil. Úplně stejně jako kdyby mi to napsal Robert.
Do autora blogu ste sa pustili hlava nehlava a urážky začali lietať priskoro a len preto, že s ním nesúhlasíte.Mám za to, že sis to trošku popletl. Autor blogu urážkami nešetří, a k němu se všichni chovají ještě relativně slušně. Že navrhoval podat žalobu na lidi z CZ NIC za to, že mluví o vyčerpání IPv4, mi taky nepřijde v kontextu jeho dalších příspěvků nijak vtipné, spíš naopak.
To, že niekto v IPv6 NAT nevidí zmysel, alebo ho dokonca považuje za škodlivé je legitímny postoj. Rovnako legitímne ale je, chcieť NAT napriek tomu.Že by měl (obecný) NAT úplně zmizel je pokud vím menšinový názor, obhajovaný hlavně Lubošem a možná se někdo přidá. Ostatní více či méně připouštějí užitečnost překladu adres v některých případech. Ale Lubošovy argumenty nejsou nijak špatné ani arogantní. Prostě vyjadřuje pocit, že NAT nepotřebuje, a zajímá se o důvody, proč by ho vůbec měl kdo potřebovat. Roztržku s panem astrologem vůbec neřeším. Myslím si o něm to samé, co Luboš (a s NATem to nemá nic společného), jenom jsem neměl potřebu to vyjádřit v diskuzi.
Odbočka: Prevádzkovať sendmail SMTP server na počítači, ktorý má dynamickú IP a ktorý používam prakticky sám je blbosť. Je to zbytočnosť. Je to overkill. Je to komplikovanejšie konfigurovať ako napr. postfix, atď. Napriek tomu ho prevádzkujem. Čo je koho do toho, aké sú moje dôvody? Poďme sa baviť o tom, či problémy načrtnuté v blogu ešte niekoho trápia a ak áno ako ich riešiť.To se tu přesně děje. Stačí ignorovat astrologa a některé výstřelky pana Tomáška. Mimochodem, ač pan Tomášek očividně vůbec nerozumí IPv6 a pravděpodobně nesnáší ateisty, pořád mi subjektivně připadá mnohem chytřejší než pan astrolog.
Vlastne by bolo primerané prihodiť do blogu anketu: anonymita strojov v LAN je niečo čo ( ) chcem riešiť ( ) je mi fukTo je v tomto kontextu zbytečné, protože „anonymita“ strojů v LAN je v IPv6/PE vyřešená lépe než v IPv4/NAT. Ani tak to z globálního hlediska nemá žádný význam, protože protokoly vyšších vrstev stejně vše vykecají.
Ak je vám fuk fajn. Ak je to fuk 95% čitateľov, tak by sa Peter mal zamyslieť či náhodou nerieši blbosť. Ak to chcete riešiť, raďte ako na to.On by se mě zamyslet každopádně, protože ať už otázka má nebo nemá smysl, on obhajuje to slabší řešení, a to buď protože IPv6 nezná, nebo protože ho znát nechce. Což je ovšem jen a jen jeho problém. My ostatní si nad tím rádi podiskutujeme i tak.
urážky začali lietať priskoro a len preto, že s ním nesúhlasíte[citation needed]
NAT v IPv6 prostě bude.Jsi si tím jistý, pane astrologu? Aby to nebylo jako posledně, když se ti na čočku vysrala moucha.
Je totiž dost možné, že někteří správci nastaví svoje sítě tak stupidně/fašisticky, že tuto potřebu vyvolají -- např. tak, že nebudu moci připojit mobil k počítači (nebo obráceně), udělat mezi nimi obyčejný most a získat pro každé zařízení IP adresu -Tohle je trochu nesmysl - bridgovani neni obecne reseni a nikdy nebylo - internetove protokoly mame mimo jine od toho, abychom mohli propojit sitove technologie, ktere jsou vyrazne odlisne na linkove vrstve (a tedy je prirozene nejde zbridgovat). To, ze nejde zbridgovat napr. mobilni pripojeni (tedy typicky varianta PPP) a ethernet, je proste prirozena vlastnost tech technologii, zadne stupidni/fasisticke nastaveni. Tvrzeni, ze bychom problemy na sitove vrstve (pridelovani IP adres) meli resit upravou vsech moznych linkovych vrstev do kompatibilni podoby, je nesmysl.
Jenže když je síť nastavená tak, že se ke mně přes ten drát (myšleno obrazně -- přidělená přípojka) dostane jen jedna IP adresa, tak mi nezbývá než udělat ten NAT nebo proxy a všechna svá zařízení za tu jednu IP adresu schovat.
Sice si myslím, že špatná pravidla je lepší zrušit než je obcházet, ale někdy to třeba jinak nepůjde, navíc pro řadu lidí je obcházení hloupých pravidel přímo výzva. Jedním řešením je proxy, ale ještě pohodlnější bude ten NAT, protože si můžu udělat vlastní soukromou síť a v ní mít autokonfiguraci, takže nebudu muset nastavovat na každém zařízení adresu proxy.
Tohle je spíš filosofická debata (jestli pravidla obcházet, nebo se jim podřídit, i když jsou špatná) než technická.
Jak je vidět, tohle je věc, která trápí koncové uživatele. Je tedy absurdní to prezentovat jako důvod, proč IPv6 odmítají správci sítí, zaměstnavatelé nebo velké firmy. Naopak těm poskytovatelům by se nepřítomnost NATu v IPv6 mohla hodit -- u IPv4 si zákazník snadno schová víc počítačů (třeba i sousedů) za jednu IP, kdežto u IPv6 mu může hodně zlý poskytovatel účtovat za každou IP adresu (za každé zařízení) zvláštní poplatek (alespoň do doby než bude IPv6 NAT nebo si uživatel nenainstaluje proxy). Je tedy zřejmé, že nepřítomnost NATu není brzdou zavádění IPv6.
Můžu si připojit k ethernetu WiFi AP a udělat most, nebo můžu udělat most s bezdrátovou kartou v počítači, nebo propojit mobilní připojení přes wifi s počítačem... prostě to funguje a je to užitečné. Že to někomu nepřijde dostatečně košer a dal by tam raději router, neřeším.No, to ale ignoruje pointu meho prizpevku. Nejde o to, ze by bridge nebyl dostatecne 'koser', ale proste ty technologie jsou natolik odlisne, ze je bridgovat nejde. Zrovna wifi a ethernet jsou vcelku podobne na linkove vrstve (napr. pouzivaji stejne MAC adresy a stejny typ navazani na sitovou vrstvu - ARP), takze i pres drobne problemy je bridgovat jde. Ale Internet neni jen ethernet a wifi. Treba to PPP se s ethernetem (AFAIK) nezbridguje. Nepisu o zadnych pravidlech ci jejich obchazeni, ale proste o reseni technickeho problemu.
BTW, tusite nekdo, jakou linkovou vrstvu (z pohledu prenaseneho IP protokolu) pouziva UMTS?Tipl bych, že to bude pořád PPP...
# Můžu si připojit k ethernetu WiFi AP a udělat most, nebo můžu udělat most s bezdrátovou kartou v počítači, nebo propojit mobilní připojení přes wifi s počítačem... prostě to funguje a je to užitečné. Že to někomu nepřijde dostatečně košer a dal by tam raději router, neřeším.Jenže právě WiFi je postaveno pořád na Ethernetu, tj. udělat bridge není obvykle takový problém, a ta technologie s tím tak nějak počítá. I v tomto případě ale někdy problém je - je-li více počítačů za WiFi interfacem v režimu Client, dělá to velké problémy řešené obezličkami typu arpnat (vida, NAT už na linkové vrstvě). A nejen Ethernet existuje na světě. Pokud nějaký linkový protokol (může to být něco ve stylu PPP) nepodporuje z principu bridgování, není to fašistické ani hloupé. Závěr je, že je třeba počítat s tím, že reálný ekonomický svět je nesmírně hloupý, nesmyslný, fašistický, či pragmatický. Peníze, resp. užitek a všudypřítomný cost/benefit, nám vládnou. Buď se síťové technologie budou snažit teto svět změnit, nebo mu nakonec podlehnou, jako se stalo u IPv4.
Pokud nějaký linkový protokol (může to být něco ve stylu PPP) nepodporuje z principu bridgování, není to fašistické ani hloupé.Jenže když bude správce sítě resp. provozovatel chtít, tak přes tu jednu linku nasměruje víc IP adres (resp. připojí víc koncových zařízení) a nebude potřebovat NAT. Nejde tedy o technické omezení, které vyvolává potřebu NATu, ale o neochotu správce poskytnout konektivitu pro víc zařízení.
například SOCKS proxy, která toho vždy uměla víc než NATAle byla vyrazne narocnejsi na pouziti (zejm. proto, ze clovek musel presvedcit vsechny aplikace na vsech pocitacich, aby to pouzivaly, oproti jednomu pravidlu na brane v pripade NATu).
Ale byla vyrazne narocnejsi na pouziti (zejm. proto, ze clovek musel presvedcit vsechny aplikace na vsech pocitacich, aby to pouzivaly, oproti jednomu pravidlu na brane v pripade NATu).Což by teoreticky neměl být problém. Obvykle to bude tak jeden-dva počítače (firemní síť si nejspíš bude moct dovolit koupit místo toho připojení k internetu), a pokud vím, tak není zase takový problém aplikacím podstčit alternativní implementaci socketů, a teoreticky by to šlo napojit přímo na TCP/IP stack OS, ne?
NAT je překlad adres, to je trochu širší řešení, než jen řešení dostatku či nedostatku IP adres.Spletl jste si blog, pan Tomášek psal o IP maškarádě.
Prosím, vysvětlete mi potřebu NATu v IPv61. Rychle a okamzite pripojeni vice zarizeni na misto jedineho zarizeni. Samozrejme existuje mnoho dalsich zpusobu jak to udelat, ale ty obecne nejsou univerzalni (v mnoha pripadech nemusi fungovat, napr. bridging), nebo nejsou rychle a okamzite (napr. domluva s adminem, at na mne naroutuje prefix), nebo maji nejake netrivialni predpoklady a dalsi negativni dusledky (napr. zprovozneni IPv6 in IPv6 tunelu na misto, kde mi uz nekdo nekdo jiny ten prefix poskytl). 2. Multihoming pro male organizace. A ne, reseni zalozene na precislovani prefixu vsech hostu v siti (napr. pomoci RA) nepripada v netrivialni siti v uvahu. 3. Transparentni proxy (smerovana na jiny stroj). Uz tu bylo rozebirano.
Samozrejme existuje mnoho dalsich zpusobu jak to udelat, ale ty obecne nejsou univerzalni (v mnoha pripadech nemusi fungovatCož je vlastnost, kterou na IPv6 aplikacích budou velmi pravděpodobně s IP maškarádou sdílet.
2. Multihoming pro male organizace. A ne, reseni zalozene na precislovani prefixu vsech hostu v siti (napr. pomoci RA) nepripada v netrivialni siti v uvahu.Teď jde o to, jestli měl namysli obecný NAT nebo maškarádu.
3. Transparentni proxy (smerovana na jiny stroj). Uz tu bylo rozebirano.Viz výše.
Což je vlastnost, kterou na IPv6 aplikacích budou velmi pravděpodobně s IP maškarádou sdílet.Nijak vic nez na IPv4.
Teď jde o to, jestli měl namysli obecný NAT nebo maškarádu.Mluvim obecne o NATu, tedy jak o statickem NATu 1:1 (v nekterych pripadech), tak o maskarade (v jinych).
Nijak vic nez na IPv4.A to si právě nemyslím (z důvodů v diskuzi i jinými již několikrát uvedených).
napr. domluva s adminem, at na mne naroutuje prefixV případě IPv6 to tak ale ve většině případů už bude, takže je to problém dost abstraktní.
A ne, reseni zalozene na precislovani prefixu vsech hostu v siti (napr. pomoci RA) nepripada v netrivialni siti v uvahu.Smím se zeptat proč? Protože místní adresy ("unikátní lokální adresy") se nemění, takže kvůli místním službám (SAPy atd.) se nic měnit nebude muset. Složitější je to jen v případě, že je tam routerů pod sebou více, pak je jen třeba to udělat ještě tam. SIGHUP a klienti rázem mají adresy nové. Neměl by být problém to zautomatizovat.
V případě IPv6 to tak ale ve většině případů už budeNemyslim. Mozna u domaciho ADSL, ale pochybuji ze to bude bezne treba u wifi v hotelu nebo UMTS telefonu.
Smím se zeptat proč?Je s tim spousta problemu, napr. staticke adresy (na vsech routerech a serverech). V pripade vice routeru to vyzaduje netrivialni infrastrukturu (napr. router pri bootu by nejdriv musel zjistit, ktere adresy si ma vubec nastavit), nevim o tom, ze by existovaly nejake standardni protokoly, ktere by to resily, a bastlit si to na kolene asi moc adminu nebude.
U UMTS bych se toho do budoucna nebál, protože lidi si chtějí svůj telefon připojit k PC a tak dále.To já bych se bál. Technicky to půjde. Ale obchodně. Pochybuji, že mobilní (a někteří jiní) operátoři si nechají ujít příležitost tohle extra zpoplatnit jako "službu navíc".
Ona to není prognóza, ale běžná praxe v USA (25 vs. 45 USD).Já jsem to chápal tak, že tím chceš ukázat, že to bude i u nás.
Když bude v Linuxu podpora pro NAT, která ušetří zákazníkům peníze, tak to bude konkurenční výhoda pro Linux (alespoň dočasná) a pomůže mu to zvýšit náskok před ostatními systémy.To je jeden pohled na věc.
Otázka je, jestli samotná existence téhle funkce napáchá nějaké zlo -- jestli třeba bude svádět správce k nějakým šíleným konfiguracím sítí. Ale vzhledem k tomu, že IPv6 adres bude všude dostatek, tak doufám, že si nikdo nebude nějakým NATem přidělávat práci a jednoduše přidělí každému zařízení jinou IP adresu.Druhý pohled je, že když ta funkce nebude úplně běžně dostupná, a nebude ze začátku třeba ani na Linuxu, tak se neuchytí jako běžná praxe. A pro řešení speciálních případů obvykle stačí IP NAT bez maškarády. Ten by se do Linuxu měl přidat asi co nejdřív. Maškarádu bych do kernelu vůbec nedával a kdo chce, ať použije službu v userspace (navázanou na kernel, instalovanou zvláštním balíkem). Ale to je jen můj názor.
U hotelové WiFi taky, protože tam vám přece musí lítat router advertisements. Prostě si místo jedné adresy vezmete adres víc a neřešíte to.Ono není WiFi jako WiFi. Takový Cisco Wireless Manager dělá často na všech vrstvách různou těžkou magii. A možná to někomu přijde jako kravina / fašistické omezení, ale zákazníci za to platí a rádi to používají - a to s IPv6 nezmizí. Takže ta technologie vůbec nemusí povolit prostě si místo jedné adresy vzít víc a neřešit to. To je obecně i na Ethernetu, kde není v určitých prostředích výjimkou limit 1 MAC adresa na port switche. A tam pak nějaký bridge nepomůže.
Je s tim spousta problemu, napr. staticke adresy (na vsech routerech a serverech). V pripade vice routeru to vyzaduje netrivialni infrastrukturu (napr. router pri bootu by nejdriv musel zjistit, ktere adresy si ma vubec nastavit), nevim o tom, ze by existovaly nejake standardni protokoly, ktere by to resily, a bastlit si to na kolene asi moc adminu nebude.Radvd si už teď umí dopočítat prefix podle jiného rozhraní. Je to jen pro 6to4, ale jestli vyvstane potřeba, určitě to rozšíří...
Je s tim spousta problemu, napr. staticke adresy (na vsech routerech a serverech). V pripade vice routeru to vyzaduje netrivialni infrastrukturu (napr. router pri bootu by nejdriv musel zjistit, ktere adresy si ma vubec nastavit), nevim o tom, ze by existovaly nejake standardni protokoly, ktere by to resily, a bastlit si to na kolene asi moc adminu nebude.Nejsem si jistý, jestli jsem tě správě pochopil, ale mám za to, že tohle přesně dělá DHCPv6. Router dostane kromě vnější adresy přidělen i vnitřní prefix.
To je ale urceno pro trochu jinou aplikaci (prideleni prefixu pro domaci sit), nikoliv k tomu, aby nekdo konfiguroval vnitrni routery v siti pres DPCP (coz je samo o sobe hruzostrasna predstava).Nemám pocit, že by přidělování prefixů přes DHCP bylo takto omezené. Já osobně dávám v infrastruktuře teda přednost ručně nastaveným adresám, ale v principu na to podle mě jde DHCP použít.
Prosím, vysvětlete mi potřebu NATu v IPv6, děkuji.Lidi si budou stavět svoje sítě jak jim bude libo, ať si neblbové i blbové budou říkat co budou chtít.
Lidi si budou stavět svoje sítě jak jim bude libo, ať si neblbové i blbové budou říkat co budou chtít.Problém vidím v tom, že jim na tom část aplikací nebude fungovat a programátoři jim k tomu „zapomenou“ dodělat berličky typu ICE-UDP.
IPv6 je nový protokol daný shůry. Kdo se pokusí byť jen poukázat na jakýkoliv drobný nedostatek, bude prohlášen za zpátečníka, lenocha co se nechce nic učit, nechápajícího dementa, rouhače a antikrista. Následně bude ukamenován nezpochybnitelných dogmaty a po smrti přijde do pekla.Zajímavé, blog pod který píšeš vyznívá přesně naopak :).
ip6tables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 8080nebo kde tu proxy máte.
# ip6tables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY ip6tables v1.4.10: Couldn't load target `TPROXY':/lib64/xtables/libip6t_TPROXY.so: cannot open shared object file: No such file or directory1) TPROXY v ip6tables není (Fedora 15) 2) TPROXY neumí udělat redirect na jiný stroj podle dokumentace k iptables.
1) TPROXY v ip6tables není (Fedora 15)Viz #76
2) TPROXY neumí udělat redirect na jiný stroj podle dokumentace k iptables.
Na odkláněcím routeru se v směrovacích tabulkách nastaví cesta na stroj, na kterém běží transparentní proxy. Překlad v tomto případě není potřeba.
Překlad adres má zase své nevýhodySamozřejmě.
taková proxy už není zcela transparentní (server dostane jinou zdrojovou adresu) a v případě protokolů, které nemají explicitní lokátor (například FTP), ani fungovat nebude, neb proxy nebude vědět, kam se klient chtěl připojit.Mně osobně se koncept transparentní proxy nelíbí vůbec. Podle mě by bohatě stačilo, kdyby stroje dostávaly informaci o proxy (možná i SOCKS, která umí navazovat spojení libovolně a otevírat porty). Překlad by se zablokoval. Operační systém (či služba) by znal proxy, kterou by obratem poskytoval aplikacím přes socketové rozhraní, a pokročilejší aplikace by mohly stejnou proxy použít pro otevření portů či navázání spojení přímo.
iptables -t nat -A PREROUTING -p TCP --dport 80 -j REDIRECT --to-port 3128
Port-forwarding může směrovat i na jiný stroj, pokud cache běží jinde než na routeru. Proč to na IPv6 nefunguje, to taky nechápu.Ono to bude fungovat i na IPv6, jen na to ještě nejsou připravené pohodlné moduly.
Navic port-forwarding je ciste lokalni zalezitost firewallu, takze nevim duvod proc by to pro IPv6 nemelo fungovat.Jednak to nefunguje, protože to není implementované (zatím). Druhá věc je, že port-forward není čistě lokální záležitost a používá se právě k přesměrování trafficu na jiný stroj, kde TPROXY nestačí.
Kurna zjisti si co to vubec NAT je nez tady zacnes vykladat takove blbosti. CO ma proboha NAT spolecneho s transparentni WWW cache?Přesměrování IP a portů je jedna z funkcí NATu. Transparentní proxy funguje právě na principu přesměrování (přepsání/přeložení IP a portu).
Ono totiž jsou prostředí, kde potřebujete propojit systémy spravované různými subjekty, a dosáhnout dohody na změně nastavení "cizího" je někdy extrémně těžké nebo nesmyslně drahé. A pak přichází na řadu ty "prasárny", za které vás odmění, protože to jakž-takž funguje za 10 % ceny.V takovém případě bych asi volil standardní (tedy dražší) řešení a zdůraznil bych, že je dražší jen proto, že se těch (i kdyby jen de facto) standardů nedrželi jiní :). Ano, i ajťáci umějí být svině :).
Ale zkus někdy pracovat s lidma, kteří jsou zvyklí, že se třeba při pádu serveru přihlásí na hlavní router a nechají nějakou IP překládat na server záložní.Ano, je veliký problém říct nějakému stroji, že si má převzít IP adresu toho spadlého serveru.
Ano, je veliký problém říct nějakému stroji, že si má převzít IP adresu toho spadlého serveru.Přesně tak, je to velký problém.
prasení něčeho, aby to nějak fungovalo, než to udělat pořádněVelmi často je problém v tom, že "udělat pořádně" je násobně nebo dokonce řádově dražší než "zprasit. Jistě, že zprasené řešení má rizika, ale ta pořád mohou být hluboko pod cenou "pořádného řešení". Tady je podle mě jediné řešení čas, a osvěta ohledně "čistých", a "historií nezatížených" sítích.
Velmi často je problém v tom, že "udělat pořádně" je násobně nebo dokonce řádově dražší než "zprasit. Jistě, že zprasené řešení má rizika, ale ta pořád mohou být hluboko pod cenou "pořádného řešení". Tady je podle mě jediné řešení čas, a osvěta ohledně "čistých", a "historií nezatížených" sítích.Řada lidí by ti mohla povědět o svých zkušenostech s tím, jak dopadly příliš zprasené sítě. Na jednoduchá zprasená řešení musí člověk/firma mít.
NAT se používá i na jiné věci, než řešení nedostatku IP adres.V nadpisu zápisku byla Maškaráda.
Ano, NAT je levější řešení, protože není potřeba kupovat IPv6-compatible zařízení a protože "se to prostě nahodí a vono to nějak pojede". Technologicky nevyspělá řešení bývají levnější.Tohle řešení ale naštěstí taky umře :), i když je z krátkodobého hlediska nejvýhodnější.
IMHO se blizi doba, kdy dalsi rust vykonu CPU uz mnoha lidem neprinese viditelne zlepseni
To možná u toho ARMu, u klasických Intel/AMD ta doba IMHO trvá už asi tak pět let.
Namísto keců, že to nebude se to prostě má udělat – a pokud máte pravdu zašlo by to ne úbytě pro nezájem.A není dostatečným důkazem nepotřebnosti to, že to ani nevznikne? (místo aby to muselo nejdřív vzniknout a pak zajít) I když podle mého NAT pro IPv6 vznikne -- ale z jiných důvodů, než tu hlásají jeho příznivci.
I když podle mého NAT pro IPv6 vznikne -- ale z jiných důvodů, než tu hlásají jeho příznivci.Přesně tak, NAT pro IPv6 vznikne spíš z důvodů, kteřé hlásáme my „odpůrci“, co ho používáme jen v případech, které nejdou/nechceme řešit lépe.
tak lidi se rozhodli, že IPv6 budou víceméně co nejdéle ignorovat.
Navíc nemám pocit, že psaní síťových věcí by byl vrchol obtížnosti v programování. Patří to spíše k těm jednodušším programátorským úlohám.
A teď buď můžu předem nastavit IP adresy v klídku, ještě než zařízení dovezu na nové místo a nebo vznikne situace, že zařízení se musí na místo odvést honem rychle a není čas nastavit IP adresy.IPv6 má link-local adresy, pomocí kterých se k zařízení připojíš třeba i přímo kabelem, spustíš konfigurační rozhraní a nastavíš to na místě. Dřív se to dělalo pomocí speciálních služeb jako Mikrotik MAC Telnet, ale IPv6 už to má zabudováno v sobě.
A pomiňme, že zařízení má přidělovanou adresu z DHCP, ne vždy tam běží DHCP server, ne vždy zařízení umí DHCP klienta.DHCP je mi úplně jedno, k tomuhle slouží LL adresy.
Všechny tyto požadavky maškaráda na IPv4 elegantně řeší tím, že zamaskuje vnitřní zařízení pro pozorovatele zvenčí pod jednu IP adresu.Neřeší.
Hele, takovýto debílky fakt miluju, kteří reagují na něco, co člověk vůbec nepsalA fakt si jsi jistý, že se nejmenuješ ve skutečnosti Petr Tomeš?. Kde se v blogu píše od "dostání se na ten počítač z internetu", ha?
Hele, mám pocit, že jsi automat, kterej když narazí v blogu na výraz IPv6, tak začne automaticky trollitA já mám pocit, že teď zrovna trpíš samomluvou :).
A fakt si jsi jistý, že se nejmenuješ ve skutečnosti Petr Tomeš?Přesně na tohle už jsem se ho jednou ptal :D prej ne :)
Hele, mám pocit, že jsi automat, kterej když narazí v blogu na výraz IPv6, tak začne automaticky trollitTím mě úplně zničil, docela bych to navrhnul do XKCD! Dokonce ho kromě Tomešismu teď podezřívám už i z Hulánství.
Chci mít náskok před ostatními a učím se používat IPv6 takové, jaké je. Nářky nad neexistencí NATu v IPv6 jsou jen koulí na noze, která by mě brzdila a můj náskok před ostatními zkracovala.Tak on se vždycky najde někdo, kdo než aby šel dopředu a zvyšoval si kvalifikaci, tak radši nadává těm, kteří to dělají... a trochu oprávněně, protože pak mezi nima bude vypadat, že je pozadu.
Kdybych neviditelnost vnitřních strojů řešit chtěl, nasadil bych v síti privacy extensions. Každý stroj by prostě dostal IP adresu náhodně, a to ještě jen na chvíli. A bylo by mi úplně jedno, jestli tu náhodnou adresu někdo vidí nebo ne, protože příště už by byla adresa jiná, zcela nevystopovatelná.Víš o tom, že PE vznikly právě jako odpověď na stížnosti na degradaci soukromí v IPv6? Pravda, nebýt IPv4, nikdo by to neřešil, ale když už je, tak se nový protokol vypiplává do všech možných vlastností toho původního.
Na druhou stranu netuším, jak zamaskovat vnitřní adresu v IPv4 a to ani s pomocí NATu. Jak už jsem říkal - vyšší protokoly vnitřní adresu prásknou na hříšníka velmi ochotně. NAT v IPv4 dokáže zakrýt jen velmi málo z té spousty informací, které z vnitřní sítě prosakují jinak. Když to nejde na IPv4, neřeším to ani na IPv6.To samozřejmě jako argument neobstojí, protože „co kdyby náhodou“. Ne vždy stačí použít racionální argumenty.
Nasazení IPv6 na mých sítích byla velká úleva - nikdy před tím pro mě nebyly ty sítě tak přehledné a jednoduché. Teď se ještě zbavit IPv4 a jsem pan admin spokojený. S IPv6 mám pochopitelně spoustu starostí navíc, ale vždy to souvisí buď s mou neznalostí a nezkušeností, nebo s nefungujícím tunelem (problém ISP).Souhlasím, tedy až na délku adresy (nutné zlo).
Evangelizátoři IPv6 se nám opakovaně snaží vtlouci do hlavy, že maškaráda (source NAT) je zlo a že s příchodem IPv6 nic takového není potřeba. Jakkoliv chápu, že je maškaráda v současnosti dost nadužívána a občas i zneužívána (především poskytovali internetového připojení) a že ji proto dost lidí nemá rádo, jsem přesto přesvědčen, že může být i užitečná (pokud člověk ví, co dělá). Přesto zaráží, že se tvůrci IPv6 tak sveřepě (a dogmaticky) tomuto konceptu brání a nenabízejí jeho adekvátní náhradu.Píšeš velice zatvrzele, až bych řekl možná i fanaticky, na to, že nemáš o tématu zjištěná základní informace. IPv6 poskytuje plnohodnotnou náhradu za IP maškarádu, která se skládá z dvojice technologijí. Té první se říká stavový firewall a provádí filtrování komunikace podle směru, odkud je navazovaná (konfigurace triviální). Druhé se říká privacy extensions a zajišťuje to, že jeden počítač nemá vždy stejnou adresu a tedy je schovaný za místní prefix. Srovnej.... IPv4 + Port: Zde zvenčí identifikuješ jen vnější stroj, tedy máš 32 bitů informace z celkových 48 bitů, tedy pouhých cca 65 tisíc možností. IPv6 prefix + IPv6 náhodný ID + Port: Zde zvenčí identifikuješ prefix (odpovídá IPv4 veřejné adrese) a port (který také nic neříká), máš tedy 80 bitů informace, které ti jsou úplně stejně k ničemu, protože ti pořád chybí 64 bitů, kde je pouhý náhodný identifikátor. Tedy počet možností, do kterých se musíš strefit je cca 1.8 * 10^17.
Nejak jsem nepochopil, jak tohle zprovoznit v IPv6. (Ty sluzby zustavaji z vnejsiho pohledu stejne, ty pocitace se meni, recykluji, prohazuji, vyrazuji dost chaoticky)Řešení je několik. 1) Jedním z nich je samozřejmě i ten překlad IP adres a portů (a pokud vyhovuje a je implementován, nevidím důvod ho nepoužít, proto mu dávám taky číslo). Ale je to NAT 1:1, který bych rád viděl v Linuxovém IPv6 alespoň implementovaný. Na tento typ dynamických služeb mě napadají dvě podle mě hezčí řešení: 2) Změna v DNS IPv6 se nakonfigurují normálně, tedy buď ručně, autoconfigurací nebo pomocí DHCP (všechny tři možnosti umějí dát statickou adresu). Při změně služby se změní IP v DNS a Firewallu a jede se dál. Tahle možnost je podle mě nejlepší způsob jak situaci řešit na IPv4 i IPv6 (pokud není nějaká technická překážka). 3) Změna IP Každé takové migrující službě se přidělí jedna IPv6 adresa (je jich dost) a ta IP adresa se přidá počítači, který má službu obstarávat. Ve chvíli, kdy je potřeba přehodit službu jinam, udělá se přesně to. Odebere se IP adresa původnímu počítači a přidá se novému. Šlo by to do jisté míry zautomatizovat i pomocí DHCPv6. -- Každopádně, jako první bych řešil to, aby se to nedělalo tak chaoticky, to je chyba samo o sobě. Všude, kde jsem něco takového potkal to celé vzniklo nějakým ne moc dobrým nápadem. Pak bych zkoušel to DNS, protože to je nejjednodušší a nejhladčí řešení. A nakonec bych váhal mezi NATem a IPv6 adresou pro každou službu (nebo neváhal, pokud bych neměl IPv6 NAT implementovaný).
...migrující službě se přidělí jedna IPv6 adresa...Řešení s DNS mě samozřejmě napadlo, tohle je ale někdy ještě jednodušší a hlavně to funguje okamžitě, DNS mívá prodlevy. Že mne nenapadla taková očividnost mě jenom utvrzuje, že přepnout hlavu na verzi 6 bude ještě dlouho trvat a bude to bolet. Přehazovat pravidla NATu v IPv4 je pro mě velmi nepříjemná záležitost, je to složité. Ono to není jen jedno pravidlo, co se musí při migraci služby upravit či přidat. Ta pravidla jsou čtyři při dvou sítích - venkovní/vnitřní. Když k tomu připojíme další kombinaci - vnitřní/vnitřní, pravidel přibývá. A to se v původním příspěvku mluvilo o několika podsítích... to by se z pouhé nepříjemné záležitosti stala noční můra. Pro změnu adresy mluví ještě jiný argument - pokud stroj A poskytuje službu A, nebudeme to přeci nastavovat v bodě X. Navíc je to asi první věc, která by napadla naprostého laika nebo NATem nezkažené dítě: "Když má ten nový stroj dělat totéž, tak ho asi pojmenujeme stejně, ne?"
Jen mě samotného nenapadlo, že v IPv6 mohu totéž rozšířit i na IP adresy.Tak mě k tomu úplně svádějí, vzhledem k tomu, že se přidělují v de facto neomezených balících (myslím z hlediska počtu strojů, ne z hlediska členění).
Schválně, jak se dneska řeší HTTPS virtuály, používají se ještě často samostatné IP?Vzhledem k potřebě nějaké zpětné kompatibility AFAIK nemáš jinou možnost.
Řešení s DNS mě samozřejmě napadlo, tohle je ale někdy ještě jednodušší a hlavně to funguje okamžitě, DNS mívá prodlevy.Ty prodlevy jdou velmi přesně nastavit.
Že mne nenapadla taková očividnost mě jenom utvrzuje, že přepnout hlavu na verzi 6 bude ještě dlouho trvat a bude to bolet.Nebude to tak zlé. Jestli ti to šlo dobře s IPv4, nebudeš na tom s IPv6 kromě pamatování adres hůře.
Pro změnu adresy mluví ještě jiný argument - pokud stroj A poskytuje službu A, nebudeme to přeci nastavovat v bodě X. Navíc je to asi první věc, která by napadla naprostého laika nebo NATem nezkažené dítě: "Když má ten nový stroj dělat totéž, tak ho asi pojmenujeme stejně, ne?"Zvlášť pokud víš, že ten stroj má opravdu plně nahradit jiný stroj :). Nejlíp se to dělá v (třeba kontejnerových) virtuálech. Těch totiž můžeš mít hromadu, kdy každý bude provádět jenom tu jednu službu. Když postavíš náhradu za nějaký, prostě ho necháš nahradit. Mezi fyzickými stroji pak pustíš OSPF a dynamický routing ti zajistí automatické přesměrování cest na nový virtuál, jakoby se nechumelilo.
Mit spoustu migrujicich adres me nenapadlo - neni pak problem, kdyz pocitac s tou adresou nekdo odnese jinam a tam ho zapne?Je to úplně stejný problém jako když si někdo danou IP prohlásí za svou a začne ji používat. Nebo pokud by to přenesení bylo legitimní, tak je potřeba zavést dynamický routing, aby se vše dobře spojilo. Nejvíc je to vidět u těch virtuálů, které jdou přenášet, aniž by člověk zvedl zadek ze židle.
Za timto pocitacem je trochu slozitejsi sit s nejakou tou wifinou, switchema a tak, ve ktere jsou pocitace, z nichz nektere poskytuji ty sluzby A-Z, vetsinou tak jeden pocitac jednu sluzbu, ale nekdy i vic.Spravne reseni pro tenhle problem je vyuziti dynamickeho routovani (treba OSPF) - krome routeru by se do nich zapojili i 'dynamicke' servery, takovy server by propagoval jednu pevnou IP spojenou s danou sluzbou a na routerech by se podle toho automaticky vytvarely routy. Sekundarni vyhoda je moznost redundance a automatickeho a rychleho prepnuti. Pokud uz se tak jako tak v siti pouziva dynamicky routing (nebo je tam jen par routeru), tak je to k nasazeni jednoduche, pokud ne (a sit ma mnoho routeru), tak to asi je zbytecne slozite. Reseni s NATem ma problem v tom, ze komplikuje situaci pri pristupu k dane sluzbe zevnitr site.
Ty pocitace se tam ruzne meni, takze sluzbu A poskytuje dnes pocitac pA1 v podsiti S1, vcera to byl treba pA2 v podsiti S1, zitra bude treba pA3 v podsiti S2. Sluzbu B poskytuje dnes pocitac pB1, ale vcera to delal pA1 a kdovi na ktery to bude potreba dat zitra.
Nejak jsem nepochopil, jak tohle zprovoznit v IPv6. (Ty sluzby zustavaji z vnejsiho pohledu stejne, ty pocitace se meni, recykluji, prohazuji, vyrazuji dost chaoticky)Load balancing proxy, nebo migrace IP adresy se službou.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.