Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6 (diskuse)

[Jendа]

NAT v IPv6

Ffffuuuuuu

Lidé chtějí skrýt detaily topologie svých interních sítí, takže budeme mít NAT v ipv6 bez ohledu na to, co si myslíme nebo chceme.

To je ale škoda, že k tomuto NAT neslouží…

[Radek Hladik]

Už jsem se tu na to ptal jednou, pořádnou odpověď jsem nedostal. Takže to opět nadhodím jako argument

Řekněme, že mám malou síť (5PC), které jsou ovšem závislé na internetu (třeba eshop, co já vim). Tak si ten vlastník řekne, koupim si dvě linky k internetu, třeba ADSL+nějakou WiFi. Když nepůjde jedno, půjde snad druhé, každopádně si tím zvýší spolehlivost velmi výrazně. A vše co k tomu potřebuje je privátní rozsah a jeho NATování na zrovna používanou adresu.

Jak tohle udělám u IPv6? Samozřejmě nepředpokládám, že bych dostal svůj vlastní rozsah a dělal si BGP a spol. Takže dejme tomu, že od obou poskytovatelů dostanu /64. Jak jsem se dozvěděl minule, můžu použít site-specific adresy pro lokální provoz a počítače budou dostávat druhou adresu podle toho, která linka zrovna jede. Jedinej problém je, že všechny mechanismy, jak zjistit svojí IPv6 adresu jsou směrem klient->server, takže klient musí aktivně něco udělat, aby mu "internet zase začal chodit".

Přitom přímo ideální varianta je zjednodušený NAT, dokonce už jsem viděl takový experimentální modul do iptables*, který prostě udělá přepis prefixu. Při směru dovnitř jedním směrem, při směru ven druhým směrem. Není potřeba si držet stav (ikdyž by to možná mohlo k něčemu pomoct), prostě přepíšu prvních x bitů adresy podle zadaného mapování. Zvenku jsem pořád dostupný na všech adresách, ven lezu přes tu zrovna používanou, vše to funguje poměrně ideálně.

Prostě lidi musí pochopit, že NAT vzniknul jako hack, možná rozbil internet, ale má i svá pozitiva a ty se mu nedají upřít ani propagandistickými obrázky

*) xt_RAWNAT z http://xtables-addons.sourceforge.net/modules.php/

[Jendа]

Jak jsem se dozvěděl minule, můžu použít site-specific adresy pro lokální provoz a počítače budou dostávat druhou adresu podle toho, která linka zrovna jede.

Ano, přesně takhle se to dělá. Možná je lepší, aby počítače měly adresy od obou ISP trvale a přehazovala se jenom default route, respektive její priorita.

Jedinej problém je, že všechny mechanismy, jak zjistit svojí IPv6 adresu jsou směrem klient->server, takže klient musí aktivně něco udělat, aby mu "internet zase začal chodit".

Tohle jsem nějak nepochopil… Normálně pošleš do sítě router advertisement a klienti se podle toho aktualizují, ne? A failover zvenku se řeší na úrovni DNS.

Zvenku jsem pořád dostupný na všech adresách, ven lezu přes tu zrovna používanou, vše to funguje poměrně ideálně.

Dokud se někdo nepokusí na klientovu adresu zvenku připojit…

ale má i svá pozitiva

No…

a ty se mu nedají upřít ani propagandistickými obrázky

FFUUUU používám jako obecný výraz pro zděšení .

[Jiří J.]

Dokud se někdo nepokusí na klientovu adresu zvenku připojit

Pokud by se o to někdo pokusil, nevidím důvod, proč by tomu NAT měl bránit. Pokud jsem původní příspěvek pochopil dobře, jde o statický/bezstavový překlad JEN horních 64bitů podle současně použitého "venkovního" poskytovatele. Tedy o překlad adresy autorovy sítě. Samotné adresy jednotlivých počítačů v ní (spodních 64 bitů) zůstanou neměnné.

V podstatě jde o takovou zvláštní formu 1:1 NATu.

[Jendа]

Protože nevím svoji „vnější“ adresu, tak nemůžu říct protistraně, kam se má připojit.

[Jendа]

Neboli potřebují společníka, na kterého si pingnou, a on jim řekne jejich adresu. A pak se najednou udělá failover, klienti o něm ale *nevědí* (na rozdíl od řešení s RA, kde uvidí, že jim přišel nový RA, a můžou hned zareaovat), takže jim nečekaně přestanou protékat pakety, počkají na timeout, pingnou si na společníka znova, zjistí, že se jim „veřejná“ adresa změnila, a tak pořád dokola.

[David Jaša]

Neodpověděl sis už o pár příspěvků výš tímhle?

A failover zvenku se řeší na úrovni DNS.

[Jendа]

Stále se klienti nijak nedozví, že došlo k failoveru a musí si znova přeložit svá jména.

[frr]

Jojo... hodila by se podpora pro SRV záznamy u HTTP (tj. implementace v prohlížečích). Stará a smutná píseň...

[pavlix]

Ta by se hodila.

[Heron]

+1

[j]

No a kdyz jim DNS vrati IPcka obe, tak ani nic prekladat nemusi, jednoduse zkusi nejdriv tu druhou, navic to rozlozi zatez na obe linky.

[Atom321]

Vaši vnější adresu protistrana zná, je to zdrojová adresa spojení mezi vámi.

[Jendа]

Ano, ale to znamená, že spojení musím navazovat já. A co když se chtějí spojit dva klienti, kteří jsou oba dva za tímhle?

[Atom321]

Úplně stejně, jako když za "tímhle" nejsou a mají dynamicky přidělené adresy, které vzájemně neznají.

[Jendа]

Skutečně? Já když mám dynamickou adresu, tak ji zjistím tak, že se zeptám jádra (IP stacku) svého OS. Při „tomhle“ si ale musím pingnout někam ven.

[trekker.dk]

To jo, jenže jádra už se nezeptáš, jako adresu má druhá strana, takže se nikam stejně nepřipojíš.

[pavlix]

Můžu ji publikovat.

[trekker.dk]

Takže jsi ve stejné situaci jako lidi za tím 1:1 NATem - potřebuješ externí službu, aby se k tobě mohl někdo připojit.

[pavlix]

Takže jsi ve stejné situaci jako lidi za tím 1:1 NATem

Nastesti nejsem.

[pavlix]

Při symetrické situaci žádné takové spojení není, protože ani nevznikne :).

[pavlix]

V podstatě jde o takovou zvláštní formu 1:1 NATu.

Spíše úplně obyčejnou. NAT má své problémy i svá použití.

[Ondrej 'SanTiago' Zajicek]

Možná je lepší, aby počítače měly adresy od obou ISP trvale a přehazovala se jenom default route, respektive její priorita.

Problem je ze volba zdrojove adresy nezavisi na route. Takze kdyz by jeden spoj nefungoval, pocitace by stale mohly volit prislusnou zdrojovou adresu, ktera by odpovedi vedla na nefunkcni spoj.

[Jendа]

Fakt? Já měl za to, že když mám adresy 2001::1/64 a 2002::1/64 a routu via 2002::2, tak se automaticky jako odchozí adresa zvolí ta, která je ve stejné podsíti jako gateway. Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal.

[Ondrej 'SanTiago' Zajicek]

Narozdil od IPv4, kde to bylo dost jednoduche, se u IPv6 voli zdrojova adresa na zaklade pomerne sloziteho algoritmu (popsaneho v RFC 3484), ktery bere v potaz napr. shodu se scope vuci destination adrese (takze pri komunikaci cilenou na ULA adresu se take pouzije ULA adresa, zatimco pri komunikaci na verejnou se pouzije verejna, nejsem si jist, ale myslim ze obdobne pri komunikaci na 6to4 cil se pouzije 6to4 zdrojova na zaklade nektereho pravidla). Vetsina techto pravidel ale bere v potaz cilovou adresu a nikoliv gateway.

Ono taky v obecnem pripade u dvou nezavislych uplinku a klientu to vypada tak, ze mam adresy z dvou normalnich prefixu 2001:X::/64 a 2001:Y::/64 a dve (potencialni) defaultni routy smerovane na fe80::/64 (RA routy se standardne smeruji na link-local adresu routeru). Ty jednotlive default routy maji s prislusnyma prefixama spolecne pouze to, ze prisly ze stejneho RA, ale pokud vim, tak tento vztah jadro nedrzi (nebo ho aspon neprezentuje) a minimalne to RFC 3484 nerika, ze by se podle toho mely routy volit.

[Ondrej 'SanTiago' Zajicek]

Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal. Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal.

Tuhle poznamku nechapu. ip_forward se (AFAIK) tyka pouze forwardovanych paketu, nikoliv lokalne generovanych paketu. Pokud mas pocitac se dvema rozhranima, na jednom 192.168.1.1/24 a na druhem 192.168.2.1/24 a k prvnimu je pripojeny soused s 192.168.1.2/24, ten ma routu 192.168.2.0/24 via 192.168.1.1, tvuj pocitac ma vypnuty ip_forward a nejaky program z nej komunikuje s 192.168.1.2 ale vynuti si zdrojovou IP 192.168.2.1, tak komunikace funguje.

[Sten]

Pokud máte více rout s různými prioritami a ke všem IP adresy, zvolí se ta IP adresa, která patří routě s nejvyšší prioritou (pokud si to teda aplikace nevynutí jinak). Proto se taky při komunikaci s 2001::/8 nikdy nevolí adresa fe80::/8, i když by dle vás měly mít obě stejnou šanci na zvolení.

[Ondrej 'SanTiago' Zajicek]

Viz ma vyse uvedena odpovet Jendovi. Volba zdrojove adresy podle typu cilove adresy (jak uvadis v prikladu) je neco uplne jineho nez volba zdrojove adresy podle routy.

AFAIK vazba 'adresa patri k route' tam prave neni. Pokud tvrdite ze ano, kde se ten vztah da vylistovat? Ktere RFC rika, ze by se tak klienti meli chovat (protoze kdyby to v Linuxu opravdu tak bylo jako linuxova specialita (ac myslim ze neni), tak by to celkem moc uzitecne nebylo, kdyz by se ostatni klienti chovali jinak)?

[Radek Hladik]

Normálně pošleš do sítě router advertisement a klienti se podle toho aktualizují, ne?

A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?

Dokud se někdo nepokusí na klientovu adresu zvenku připojit…

Co si budem nalhávat, lidem jde většinou o to, aby se oni mohli připojit někam. Ale jinak je to samozřejmě problém, který je ovšem na současné úrovni neřešitelný. Pokud se připojí nějaká síť, která je (výrazně) menší než prefix vhodný pro účastnění se routování, pak pokud je 100% závislá na svém ISP.

ale má i svá pozitiva

No…

a ty se mu nedají upřít ani propagandistickými obrázky

FFUUUU používám jako obecný výraz pro zděšení .

Tohle je u mně 0 informační hodnota. Argumenty, protiargumenty, připomínky, že něco říkám špatně beru, ale tohle neobsahuje nic z toho...

[Ondrej 'SanTiago' Zajicek]

A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?

Defaultni routu prepnou (ta se neridi DHCPv6), adresy neprepnou (kdyz je prideluje DHCPv6). Stejne tak je neprepnou staticky konfigurovane servery.

A o adresy jde predevsim, prepinani defaultni routy je trivialita a casto ani neni potreba (pokud napr. obe linky k ISP jsou smerovane pres jeden router).

[Jendа]

A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?

No mně se aktualizují adresy i routy okamžitě po přijetí RA.

Co si budem nalhávat, lidem jde většinou o to, aby se oni mohli připojit někam. Ale jinak je to samozřejmě problém, který je ovšem na současné úrovni neřešitelný. Pokud se připojí nějaká síť, která je (výrazně) menší než prefix vhodný pro účastnění se routování, pak pokud je 100% závislá na svém ISP.

Takže si můžeme vybrat buď řešení NATem, které znemožní plnohodnotnou obousměrnou komunikaci, a řešení přepínáním adres/rout, které tímto problémem netrpí. Já bych si vybral to druhé(, kdybych měl dvě přípojky).

Tohle je u mně 0 informační hodnota. Argumenty, protiargumenty, připomínky, že něco říkám špatně beru, ale tohle neobsahuje nic z toho...

Tak ukaž nějaká pozitiva NATu…

[Heron]

Jak tohle udělám u IPv6? Samozřejmě nepředpokládám, že bych dostal svůj vlastní rozsah a dělal si BGP a spol. Takže dejme tomu, že od obou poskytovatelů dostanu /64.

Jednoduše. Počítačům přidělíte IP z obou rozsahů (pomocí RA se přidělí samo) a síť bude mít dva routery. Přes RA budou ohlašovat i svoje priority, takže pokud jedna z linek (všimně te si, že jich tam můžete mít neomezeně) vypadne, tak stačí zvýšit prioritu další preferované lince ven. Klientům se změní preferovaná default routa a jede se dál.

Toto řešení je (IHMO) daleko elegatnější, než nějaký NAT.

[trekker.dk]

Počítačům přidělíte IP z obou rozsahů (pomocí RA se přidělí samo) a síť bude mít dva routery.

IMO je lepší mít jeden připojený k oběma ISP, nicméně předpokládám, že to jde udělat taky.

[Ondrej 'SanTiago' Zajicek]

Jenze zmena default routy nezmeni pouzite zdrojove adresy.

[Sten]

Právě že změní. Zkuste si to

[Kvakor]

Změní se, jen pokud onen router dělá zároveň i NAT.

[Radek Hladik]

Přiznám se, že se RA jsem ještě neexperimentoval. Ale co jsem nastudoval, tak jsem měl pocit, že to funguje nějak ve stylu, že se klient zapne a zeptá se "hej hola, tak jak tady ta síť vypadá?", něco si podle toho nastaví nebo použije DHCPv6, pokud to v tom advertismentu je, ale dál, že je to na libovůli toho klienta, aby zjišťoval, že se něco změnilo a případně na to reagoval...

[Ondrej 'SanTiago' Zajicek]

RA obecne rozesila router a klienti na ne reaguji i kdyz jsou nevyzadane. Klient si pri pusteni muze vyzadat RA (posle RS), aby nemusel cekat na to, kdy router sam posle RA.

[Radek Hladik]

Díky, budu si s tím muset pohrát

[Radek Hladik]

Ješte filozoficko/rýpavá otázka I v článku je zmíněno, že NAT rozbil Internet. Ovšem k tomu, aby mi chodilo to přepínání, jak je tu naznačeno, tak potřebuju site-specific adresy pro přístup k lokálním strojům. A to je něco, co je dosažitelné jen z nějaké části sítě, to není "rozbití Internetu"?

[Ondrej 'SanTiago' Zajicek]

No, to asi neni otazka na mne. Ja si myslim, ze NAT a firewally sice rozbily Internet, ale ze IPv6 uz to nespravi, a je treba s 'rozbitym' Internetem pocitat.

[Radek Hladik]

Ne, to bylo tak nějak všeobecně do diskuze U toho NATu to jeětě chápu, i když nesouhlasím, ale ten firewall, ten mně překvapil Resp. jak firewall (počítejme bez NATu) rozbil Internet?

[Ondrej 'SanTiago' Zajicek]

Firewall (rekneme stavovy, propoustejici nova spojeni 'ven' ale ne 'dovnitr', jaky se casto navrhuje jako default pro koncove krabicky) rozbiji end to end konektivitu prakticky stejne jako NAT.

[trekker.dk]

rozbiji end to end konektivitu prakticky stejne jako NAT.

To není pravda. U firewallu je to rozbíjení řízený proces a jde to vypnout, u NATu ne - to není stejně.

[Ondrej 'SanTiago' Zajicek]

To je vcelku jedno. Programator ptp aplikace (treba VOIP) urcene pro bezne uzivatele tezko muze pocitat s tim, ze si uzivatel bude schopen prenastavit firewall.

[trekker.dk]

Není. I u té routovací krabičky nakonec určitě bude nějaké zaškrtávátko typu "povolit telefonování po internetu". U NATu ho neuděláš.

[Ondrej 'SanTiago' Zajicek]

No, to mozna u znamych a vseobecne rozsirenych programu/protokolu. Pro programatora vyvijejiciho nove ptp programy/protokoly to nehraje roli.

[trekker.dk]

Ten zásadní rozdíl je, že to tlačítko udělat jde.

[l0gik]

UPnP?

[Jendа]

I v rámci sítě můžeš komunikovat po těch globálních adresách.

[Heron]

Spíše lokal. Globální adresy se mohou často měnit (zastánci NATu mění poskytovatele co hodinu a argumentují tím, že s NATem si mohou nechat stále stejné adresy, zatímco bez NATu by to museli neustále měnit). Uzel může mít globálních měnících se adres kolik chce a k tomu může mít kolik chce i lokálních adres. Nakonec, stejně jako ve světě IPv4. A úplně nakonec, je to jedno, máme DNS.

[Radek Hladik]

A úplně nakonec, je to jedno, máme DNS.

Ano máme DNS. jenže DNS má TTL a jiné věci a ještě jsem neviděl moc klientů, kteří bez problému přehodí aktivní spojení na nový pár IP adres ve chvíli, kdy to změnim v DNS

Vtip celého je v tom:

Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

Vy: "Jo, ale nemáte NAT!"

Zákazník: "Cože? Aničko, najděte mi číslo na někoho jiného..."

[Heron]

Já jsem reagoval na něco jiného

Ženeš to ad absurdum. To co popisuješ se umí a potřebuješ na to ospf (záložní linka) nebo lépe bgp (více nezávislých konektivit).

Navíc bych chtěl opravdu vidět, jak bys to, co popisuješ, dosahoval v prostředí za NATem. Spojení popadají tak jako tak. Pro všechna spojení z venku se ti změní adresa té tvé sítě (ip wan routeru). Budeš muset řešit totéž.

[Radek Hladik]

Ne já pořád popisuju to samé. Vnější konektivita popadat může, ale nesmí to ovlivnit funkce na vnitřní síti. A pořád se bavím o malých sítích, kde i kdyby šlo dělat BGP a OSPF, je to overkill*. Reaguju na příspěvek, že můžu použít globální adresy i v rámci vnitřní sítě, řikám ano, ale pak musí celá síť mít pořád všechny globální prefixy i v případě, kdy linka toho prefixu nefunguje.

Jinak, kdybych chtěl dosáhnout vyšší spolehlivosti s těmi vnějšími spojeními, pak použiju tunely někam na páteř. Prostě zdegraduju linky od poskytovetelů na obyč transportní vrstvu a problém s dostupností IP na páteři přenechám našemu páteřnímu ISP. Stačí jako popis, jak to udělat?

Opravdu mně zatím nikdo nepřesvědčil, co je tak špatného na použití site specific adres a jejich mapování na routeru, říkejme tomu třeba PRS (prefix remapping scheme) Žádné stavy, žádne maskování x adres za jednu, jen prostě pravidla if prefix=něco then prefix=něco jiného.

*) reálný příklad: Realitní kancelář, má asistentku, tři makléře, kteří jsou většinu času někde v terénu. Mají celkem 5 PC a jeden server, kde na sambě mají věci a tiskárny. Mají ADSL a většinu času je v kanceláři jen asistenka, která řeší emaily. Ale v 9 ráno si potřebujou natáhnout z nějakého relaitního serveru poptávky a když to nezvládnou, tak najednou mají půl dne volna, protože ostatní už ty lidi obvolali. Makléři mají mobílní internet, třeba Ufon či co já vim. A mají představu, že když jim v kanceláři nejde net, tak seberou jednomu makléři Ufona, připojí ho k routeru, někde něco kliknou a tradá.

[Jendа]

ale pak musí celá síť mít pořád všechny globální prefixy i v případě, kdy linka toho prefixu nefunguje

A to vadí?

[j]

Opravdu tu neustele melete z cesty aniz tusite jak snadno a krasne to funguje - jednoduse mate N routeru, kazdy posila do site svuj prefix, vnitrni komunikace neni NIJAK ovlivnena JAKYMKOLI vypadkem konektivity ven a pokud to mate dobre nastaveno (= DNS odpovida adresami ze vsech prefixu), tak si klient prelozi jednou a pouzije libovolnou z tech adres (maximalne nekde pocka na timeout). Kdyz vam padne linka, tak se spojeni rozpadne zcela v zavislosti na schopnostech protokolu a s IP vrstvou to nema nic spolecneho.

A ano, kazdy do ma vice nez 1 linek ven by mel provozovat nejaky routovaci protokol a kazdy kdo ho pripojuje by mu to mel umoznit.

Ad ten "realny" pripad - chci videt jak bude nekdo neco stahovat na 256kbit (realne) lince.

[Jendа]

Vtip celého je v tom:

Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

Vy: "Jo, ale nemáte NAT!"

Zákazník: "Cože? Aničko, najděte mi číslo na někoho jiného..."

Při přepínání konektivity ven ti nic nebrání si staré adresy ještě chvíli podržet, než se dokončí všechna spojení uvnitř sítě.

[Radek Hladik]

Při přepínání konektivity ven ti nic nebrání si staré adresy ještě chvíli podržet, než se dokončí všechna spojení uvnitř sítě.

Ne, nebrání. jenže jak dlouho si je mám podržet? Co já vím, jestli s nima jěště někdo někde komunikuje nebo nedej bože plánuje komunikovat? Alespoň nevím o mechanismu, kdy na celé sítí zjistím "hele, pánové, neplanujete ještě někdo ty starý adresy používat? Ne? Tak já je utnu..." Takže ideální řešení, podržet si je na vždy, tedy mít pořád všechny prefixy na všech strojích. A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční. A jak píšu výše, to už se mi víc líbí řešení, kdy každý klient má jednu (kromě link-specific) adresu a na rozhraních mnou spravované sítě to mapuju z/na funkční rozsah(y).

[Jendа]

Ne, nebrání. jenže jak dlouho si je mám podržet?

Každá stanice si je drží tak dlouho, dokud je po nich navázané nějaké TCP spojení. Úplně stejně, jako při používání Piracy Extensions.

Co já vím, jestli s nima jěště někdo někde komunikuje

Tobě jako adminovi je tohle totálně fuk. Ty prostě pošleš do sítě RA, které říká, že pro nová spojení se mají používat nové adresy/nový router. Stará spojení uvnitř sítě ještě doběhnou po starých adresách a klienti je pak zahodí.

A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční.

A já nevím, co se ti na tom nelíbí. Mně přijde normální, že má jeden počítač víc adres. Třeba můj domácí router jich má momentálně 7 a desktop 3.

[Radek Hladik]

Každá stanice si je drží tak dlouho, dokud je po nich navázané nějaké TCP spojení.

To samozřejmě nestačí, protože hodně protokolů si tu IP adresu někde uloží a otvírá nové spojení. Třeba takový poštovní klient, jednou za čas udělá resolv mail-internal.firma.cz a pak se na to IP do kolečka připojuje. Nebo se mu zadá server přímo pomocí IP.

Stará spojení uvnitř sítě ještě doběhnou po starých adresách a klienti je pak zahodí.

To opravdu ve všech OS funguje tak, že pokud se to IP, na které už nedostávám RA, samo po nějaké době nečiností zahodí?

A já nevím, co se ti na tom nelíbí. Mně přijde normální, že má jeden počítač víc adres. Třeba můj domácí router jich má momentálně 7 a desktop 3.

Třeba už jen myšlenka "keep it simple". Jeden klient, jedno IP. Žádné řešení, proč ten klient zase používá jinou IP, než by měl? A himbajs, pustí mně ten firewall z tohohle IP nebo z jiného?

Pokud se budem trumfovat, tak můj nejbližší router má adres 12 a kámošův kámoš má router, který má dokonce 15 Každopádně já mám rád v síti přehled a pořádek, takže preferuju mnou zmíněnou variantu. Čistě subjektivní preference...

[trekker.dk]

A himbajs, pustí mně ten firewall z tohohle IP nebo z jiného?

Tak nevím, tohle už mi přijde jako argument typu "jsem blbec a neumím si to nastavit"...

[Radek Hladik]

I tak je možné se na to dívat. A pro ty z nás, kteří nenosí (nebo nechtějí nosit) v hlavě hafo IP adres je vhodná varianta udržet to jednoduché "Pořádek je pro blbce, inteligent zvládne chaos". Já už jsem dávno zjistil, že to zvládnutí chaosu je leckdy zbytečně namáhavé a je lehčí použít tu první část...

[j]

Pro ty znas, kteri to maji v hlave vporadku, je tu DNS.

[pavlix]

To samozřejmě nestačí, protože hodně protokolů si tu IP adresu někde uloží a otvírá nové spojení. Třeba takový poštovní klient, jednou za čas udělá resolv mail-internal.firma.cz a pak se na to IP do kolečka připojuje. Nebo se mu zadá server přímo pomocí IP.

Takový poštovní klient poštu normálně odešle, i když je stará adresa už zrušená, v čem je tedy problém?

[Radek Hladik]

A jak to udělá? Zavolá fuknci na otevření socketu a předá jí "mail-internal.firma.cosi", protože resolvovací knihovna OS tento dotaz již před chvílí dělala, nemusí ho udělat znovu a vráti nějakou IP z cache, tedy tu starou. OS se dále na tuto adresu zkusí připojit a zjistí, že to nejde, protože server už tu adresu nemá. Ano bude to fungovat v případě, kdy serveru ta adresa zůstane a nebude mu vadit, že klient se nyní připojuje z jiné IP.

[pavlix]

Nedostatek invence.

[Radek Hladik]

Přebytek sebevědomí.

[trekker.dk]

Zbytečná "diskuze"...

[pavlix]

Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

Vy: "Jo, ale nemáte NAT!"

Jsem navážkách, jestli ještě píšeš z neznalosti nebo už trolluješ. Máš pocit, že přenatování na jiné vnější adresy spojení snad nepřeruší?

[Radek Hladik]

Jestli troluju, tak v míře povolené uměleckou licencí. A už jsem psal, že je jasné, že vnější spojení přenatování zruší (pokud se to nějak neobejde), stejně tak jako to, že vnitřní spojení budou fungovat. Co jsem ovšem psal je:

"Pokud použiju globální adresy od jednoho prefixu na vnitřní spojení" a zároveň "pokud tento prefix přestane fungovat, můžu tyto adresy po chvíli zmastit (a dokonce se to udělá samo)", tak to pravda není.

[pavlix]

Da se ledacos.

[Radek Hladik]

A ledaccos se nedá. Myslím, že tuto část debaty můžeme uzavřít, neboť už jsme u neplodných výkřiků...

[pavlix]

Myslím, že tuto část debaty můžeme uzavřít, neboť už jsme u neplodných

Čtu je se zájmem.

[Radek Hladik]

To můžu, ale budu závislý na tom, že v síti vůbec jsou. T.j. buď bude mít každý klient (a server) pořád všechny adresy ze všech rozsahů bez ohledu na to, jestli fungují, nebo budu mít problém. Při vší uctě mi připadá jednodušší, aby každý klient měl jednu IP adresu, která platí v rámci organizace a na hraničních routerech se s touto adresou něco dělo.

[pavlix]

Při vší úctě tvůj názor není pro ostatní zase tak důležitý. Zvlášť, když je typickou ukázkou „kdo chce, hledá řešení, kdo nechce, hledá výmluvy“.

[Radek Hladik]

To je samozřejmě pravda. Ani tvůj názor není pro ostatní zase tak důležitý. Ani když je typickou ukázkou toho "když já něco chci, tak je to jediné správné a možnosti, jak udělat něco jiného jsou špatně".

A proto si myslím, že takovéhle diskuze jsou, protože přispívají k většímu pochopení těch ostatních, což ve finále vede k lepšímu pochopení problematiky z více stran, což každý soudný člověk rád udělá.

[pavlix]

To je samozřejmě pravda. Ani tvůj názor není pro ostatní zase tak důležitý.

Muj nazor v teto oblasti zpravidla jini ocenuji, protoze jim umim rict, co udelat jde a jak to jde udelat.

Ani když je typickou ukázkou toho "když já něco chci, tak je to jediné správné a možnosti, jak udělat něco jiného jsou špatně".

Timto problemem nastesti narozdil od tebe netrpim, cos ale zrejme sam dobre vis, takze nema zadny smysl se o tom dohadovat.

[Radek Hladik]

Muj nazor v teto oblasti zpravidla jini ocenuji, protoze jim umim rict, co udelat jde a jak to jde udelat.

A tak to má být. Ja bohužel patřím k těm lidem, které ostatní neoceňují, protože jim neumím říct, zda něco jde a případně jak.

Timto problemem nastesti narozdil od tebe netrpim

Tady poprosim o link, kde tvrdím, že mnou prosazované řešení je jediné správné nebo že jiná jsou špatně. Vždy maximálně tvrdím, že se mi takové řešení nelíbí nebo líbí. Koneckonců o pár příspěvků výše tvrdím, že

A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční

[pavlix]

Tady poprosim o link, kde tvrdím, že mnou prosazované řešení je jediné správné nebo že jiná jsou špatně.

Předpokládal jsem, že mě hodnotíš metodou „podle sebe soudím tebe“, jinak si tvoji reakci neumím vysvětlit.

[Radek Hladik]

Zajímavý předpoklad, můžeš ho rozepsat? Sbírám myšlenkové pochody a tenhle ve sbírce ještě nemám

Ale bez ironie, tohle už jsou netechnické téměř invektivy založené na pár příspěvcích, zkusme to vrátit na technickou rovinu. Já tvrdím toto a poprosím o komentář, co je podle tebe špatně:

* Pokud budu správně rozesílat RA a klienti si zvládnou rozumně rychle přehodit priority a budou správně vybírat odchozí adresu a to i relativně hloupí klienti typu tiskáren, SIP krabiček/telefonů, Windows, mobilů s WiFi, tak si to dovedu představit jako funkční řešení

* Na vnitřní komunikaci budu potřebovat buď site specific adresy nebo budou muset mít všechny uzly v sítí všechny globální adresy a to ideálně pořád.

* jiná možnost, která také bude fungovat, je použít pouze site specific adresy a na hraničním routeru (routerech) dělat nějaký NAT 1:1, který nemusí být stavový

* Dala by se použít varianta stavového mapování n:m, kdy bych měl k dispozici třeba jen /64 od ISP, ale v síti bych používal několik rozsahů /64. Pořád by to bylo jedna vnitřní pro jednu vnější, jen bych využíval toho, že obsazenost těch /64 je cca 2^(-60)%. A při použit EUI64 je i dokonce poměrně nepravděpodobná kolize dvou adres bez prefixu.

[pavlix]

Já si nezačal. Technická rovina mě baví víc :). Takže to s tebou ještě jednou zkusím, ale dost možná naposledy.

Na ty body ani není třeba odpovídat jednotlivě. Všechny úvahy a možnosti už známe, všechny nějakým lepším či horším způsobem fungují.

V podstatě se dají rozumná řešení rozložit mezi tři kategorie:

1) bez překladů a elegantní, jejichž jedinou nevýhodou je nutnost spolupráce ISP, tedy dynamický routing

2) bez překladů a méně elegantní, bez podpory ISP, tedy dynamické přepínání a použití několika záznamů na jedno jméno v DNS (ať už dynamicky pomocí výměny adres nebo staticky, kdy je nastaveno několik adres zároveň)

3) S 1:1 překladem adres či rozsahů

Vtip je v tom, že každé řešení má své nevýhody, což znamená, že se na žádném neshodneme jako na nejlepším bez pečlivého zvážení situace.

Ve všech případech lze zařídit, aby nová spojení naběhla po výpadku téměř okamžitě. Pokud vím, tak jen v prvním případě lze pokračovat bez ztráty spojení.

Třetí možnost nevyžaduje ty několikanásobné adresy, ale je velké riziko, že bude ve světě IPv6 používaná v zanedbatelné míře, což znamená, že s tím aplikace nebudou počítat a nebudou fungovat. NAT věci rozbíjí, aplikace je musejí napravovat. Pokud je napravovat nebudou, tak nebudou s NATem fungovat.

[Ondrej 'SanTiago' Zajicek]

1) bez překladů a elegantní, jejichž jedinou nevýhodou je nutnost spolupráce ISP, tedy dynamický routing

No, nejde jenom o spolupraci s ISP, ale take je treba ziskat PI adresy, nebo se sam stat LIRem (tady clenstvi v RIPE). Obe varianty jsou spojene s nemalymi rocnimi poplatky.

[SPM]

Nebo si obě linky obstarat od jednoho providera (tedy samozřejmě s tím, že obě linky budou nezávislé)... což samozřejmě je také dražší, než internet od ufouna. na druhou stranu, pokud nefunkční internet způsobuje finančí ztráty za miliony a konektivita je přivedena ADSLkem za 3 stovky, tak si snad ani nic jiného nezaslouží...

[Ondrej 'SanTiago' Zajicek]

No, mit dve linky od stejneho poskytovatele je z hlediska zajisteni spolehlivosti dost zbytecne, nebot ve vetsine pripadu je vypadek nekde v siti poskytovatele, ne pouze na lince k nemu.

[SPM]

Samozřejmě nezávislostí byl myšlen případ, kdy obě trasy jsou nezávislé (resp. nikde se nesbíhají do stejného místa)...

[Filip Jirsák]

To bude dokonce jednodušší zajistit u jednoho ISP, kde se to dá ošetřit smluvně. U dvou ISP taky hrozí, že budou mít oba pronajatá vlákna v jednom kabelu, a ošetřit to smluvně by bylo dost náročné (ISP by si museli říct, jaké mají trasy a konzultovat každou změnu).

[pavlix]

Tak složité to není.

[Kvakor]

Problém je v tom, že IP adresa (ať v4 nebo "běžná" v6) není identifikací samotného počítače, ale spíš cesty, jak se k počítači skrz síť dostat. Takže pokud chceme, aby se dal k jednomu stroj směřovat provoz z více míst, musí mít onen stroj buďto více adres, nebo sice může mít jedinou adresu, ale musí existovat mechanismus, který nějak zařídí směrování z těch ostatních. U IPv4 se používá v rámci protokolu NAT a mimo něj rozličné IP tunely typu VPN.

IPv6 má ale i Mobilní IPv6, který alespoň na první pohled tento problém řeší. Na druhý pohled, ono to vlasně je "jakoby" NAT 1:1 (v jednom směru) a IP tunel, jen s tím rozdílem, že do dělá přímo protokol (tudíž nikdo nemusí nikoho balamutit ohledně skutečných adres) a že umí roaming bez zráty otevřených spojení. Talže je otázka, jak to nakonec dopadne, protože to, že má něco několik let existující hotovou specifikaci a RFCčka, bohužel neznamená, že se to bude i používat.

[pavlix]

Dodej odkaz, kde ses ptal. Matně si pamatuju, že jsem ti ochotně a pečlivě na vše odpovídal, takže bych se rád podíval, jestli jsi tak nevděčný, jak to vypadá :). Dodej odkaz :).

[Radek Hladik]

Odkaz se dodává špatně. A to proto, že poslední bylo, bude to někdy v článku - konkrétně to přepínání adres. A zatím jsem to v článku neviděl a to jsem ty o IPv6 od tebe přečetl všechny...

[pavlix]

Bohuzel jsem se k pokracovani zatim nedostal, zabere mi to dost casu. Ale jakmile mi bude zbyvat cas, venuju tomu, co muzu.

[geebranz]

really needs improvement

Recognize

[Luboš Doležel (Doli)]

Součástí tohoto NATu není maškaráda (jestli mi něco neuniklo), tak to není až takový průšvih. Aspoň, že tak.

[Filip Jirsák]

Zdá se, že po dešti nerostou jen houby, ale i překlepy: týdné, ujistite se, ingorují, zjistíe, implmentaci, methoda, struktry, smaotná, svinsvta, stuečnosti, v této části jára, kvlůi.

[trekker.dk]

Hm, že bych zapomněl na spellchecker?

[Luboš Doležel (Doli)]

Bylo jich tam dost, ale všechno jsem neodchytil

[fík]

smaotná, svinsvta, stuečnosti

[donny]

zrojáků ;)

[kip]

A ještě "používáním mechanismus".

[Petr Tomášek]

Jediná dobrá zpráva za poslední dobu

Třeba to IPv6 bude jednou i použitelné

[SPM]

jo a internet je už navždy v prdeli :)

[Petr Tomášek]

To zůstane i bez NATu, možná ještě víc, anžto pod diktátem fanatiků... :)

[SPM]

jojo, pod diktátem fanatiků, kteří bez NATu nedokážou ani žít a byli by snad schopni obětovat každý týden jednu pannu jenom proto, aby jim ten NAT na IPv6 fungoval :)

[Kvakor]

Tolik panen by určitě nesehnali

[SPM]

No jo, oni vlastně kvůli tomu i draci vychcípali hlady :)

[Grunt]

Ať se nám to líbí nebo ne, s NATem se budeme potýkat navždy.

Super. A multipathu na jedno spojení se nedočkáme už nikdy. Na to stačí říct už jen jediné: FAKT DÍKY!.

[Ondrej 'SanTiago' Zajicek]

Standardni multipath 'odjakziva' rozdeluje pakety podle toku (tedy pakety z jednoho spojeni a tedy i z jednoho toku pujdou na multipath route stejnym smerem) a to zcela nezavisle na NATu, dela se to AFAIK zejmena kvuli flow control.

[Grunt]

Jo, to jo, ale někde není psané že je to pravidlo (doufám). Teoreticky je možné napsat více rout jedním směrem a pakety přepínat na jeden a druhý podle toho jak jdou ( Nejlépe ještě s nějakým komunikačním řídícím protokolem a nebo vnitřním mechanismem, který by zátěž rozkládal podle kapacity linky – v koutku duše jsem doufal, že když už vznikla taková spousta nových mechanismů v případě IPv6, tak tohle bude jeden z nich). TCP a UDP je na to připraveno a původní návrh vojenské sítě s tím také počítal. Bohužel v případě použití NATu tato volba automaticky odpadá, protože pokud započne někdo na nějakém portu komunikaci s cílovým serverem, těžko se bude server bavit pokud bude pokračovat úplně tu samou komunikaci (i když bude sedět ACK sekvence) z jiné zdrojové adresy (teda teoreticky by to šlo, al…).

[Ondrej 'SanTiago' Zajicek]

Jo, to jo, ale někde není psané že je to pravidlo (doufám). Teoreticky je možné napsat více rout jedním směrem a pakety přepínat na jeden a druhý podle toho jak jdou

Volit smer per-packet by sice slo, ale moc by to nepomohlo, protoze bys takhle vyuzival dohromady pouze odchozi smer. V opacnem smeru (download) by to vzdy slo jen jednou z tech linek, podle toho, jakou jsi zvolil zdrojovou adresu.

[Grunt]

Spíš jde o to, že tohle už je v routerech a pro cíl (pro zdroj skoro také, ale tomu to může být jedno) je to plně transparentní. Router u kterého se to slévá, to zas pro změnu může rozdělovat podle toho jak to šlo opačným směrem (podobně jako multicast) a nebo by se musel ještě dodělat nějaký mechanismus (např mnohem lepší tahat čtyři adresy routerů navíc v případě multipath než čtyři adresy navíc v případě source-routingu). Osobně bych byl teda pro nějaký promakanější mechanismu (třeba jako směrovací protokoly (RIPv6?), které by si předávaly také informaci o vytíženosti linek a podle toho by také pakety rozdělovaly – nebo něco podobně promakaného).

[Grunt]

dodělat nějaký mechanismus

A když si to tak vezmu, tak vlastně ani ne. I druhým směrem by na některém z hopů muselo dojít k rozhodnutí kudy pakety cpát v případě dvou a více cest (v dnešní podobě Internetu pravděpodobně někde poblíž NIXu), tak se holt nevezme jedna routa, ale dvě a dělit se bude podle toho jak do které linky se budou cpát. Teda samozřejmě v případě existence opravdu jedné celosvětově unikátní adresy. Dnešní internet je spíš více podobný spojovaným okruhům než opravdu přepínané službě, což ale nikdy nebylo cílem.

[Bedňa]

Hehe je tu dosť živo, tak myslím že na mojej prednáške NAT RULEZ! bude plno

[pavlix]

<joke>To přeju hodně štěstí, aspoň se budou mít lamy kde sejít ;).</joke>

[Bedňa]

Ale to si len robím prdel, prečítaj si diskusiu a napíš niečo rozumné, to sa nedá

[pavlix]

Tobě psát něco rozumného je jak házet perly sviním :).

[Bedňa]

Dík že si sa ma zastal náčelníku

[SPM]

Posledně si sliboval transparent a pak prd :)

[Bedňa]

Nemal som čas

[Chandigarh Escorts]

Every person has a desire to make love with someone but some people do not get the chance such people can contact Chandigarh Escort Service to make your dreams come true. Very sweet and hot girls are available to entertain you and to fulfill your desires of lovemaking. Call Girls In Chandigarh | Chandigarh Escorts | Chd Escorts | Chandigarh Escort Service | Escort Service Chandigarh | Chandigarh Call Girls | Chandigarh Escort