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

1. 8. 2011 | Jirka Bourek | Jaderné noviny | 4404×

Aktuiální verze jádra: 3.0 ještě nevyšlo. Citáty týdne: Paul McKenney, Thomas Gleixner. Garrett: Bootování s EFI. Návrat realtime stromu. NAT v IPv6. Jak Linusovi zkazit dovolenou. RLIMIT_NPROC and setuid().

Obsah

• Aktuální verze jádra: 3.0 ještě nevyšlo
• Citáty týdne: Paul McKenney, Thomas Gleixner
• Garrett: Bootování s EFI
• Návrat realtime stromu
• NAT v IPv6
• Jak Linusovi zkazit dovolenou
• RLIMIT_NPROC and setuid()

Aktuální verze jádra: 3.0 ještě nevyšlo

Jádro 3.0 ještě vydáno nebylo, alespoň ne v době psaní tohoto článku. Záludné chyby, první ve VFS (vizte níže), druhá v RCU zpozdily vydání, které je jinak již připraveno: historie naznačuje, že k vydání dojde okamžitě po zveřejnění článku.

Stabilní aktualizace: během minulého týdne žádné nevyšly a žádné se ani nerevidují.

Citáty týdne: Paul McKenney, Thomas Gleixner

Tato sada patchů obsahuje opravy pro průšvih týkající se RCU, plánovače a obsluhy přerušení ve vláknech. Průšvih spočíval v tom, že RCU špatně chránilo jedno ze svých bitových polí, používání RCU plánovačem v místech v irq_exit(), kde in_irq() vracelo false, RCU používalo plánovač tak, že to kolidovalo s plánovačem používajícím RCU, obsluhy přerušení ve vláknech způsobovaly problémy v irq_exit() mnohem častěji a tak dále.

-- Paul McKenney vysvětluje, proč (ještě) nemůžeme mít hezké 3.0

Jinak řečeno bavte se a ujistěte se, že budete mít po ruce hasičák, když tohle budete používat!

-- Thomas Gleixner

Garrett: Bootování s EFI

Matthew Garrett zkoumá záludnosti bootování Linuxu s EFI. Výrobci hardwaru se opět krátkozrace zaměřují na Windows. Jak jsme mnohokrát viděli v minulosti, jediná věc, kterou si výrobci hardwaru zkontrolují, je, jestli Windows bootují správně. Což znamená, že vůbec není překvapením, když zjistíte, že některé systémy podle všeho ignorují bootovací proměnné EFI a místo toho prostě hledají záložní zavaděč [fallback bootloader]. Záložní zavaděč nemá jmenné prostory, což garantuje kolize, pokud je na stejném stroji nainstalováno několik operačních systémů [...] Mohlo by to být horší. Pokud tam již zavaděč je, Windows ho nepřepíší, takže věci jsou o něco málo lepší než ve dnech MBR. Zavaděč Windows ale Linux nenabootuje, takže pokud tam jsou Windows první, stále máme problém.

Návrat realtime stromu

Ti, kteří sledují sadu patchů pro preempci v reálném čase, ví, že se na nějaký čas zasekla u 2.6.33. S vydáním nového patche založeném na 3.0-rc7 nám Thomas Gleixner řekl proč: celá sada patchů byla přepracována a pročištěna, bylo implementováno nové řešení problému proměnných specifických pro CPU a vydání založené na 2.6.38 pozdržela ošklivá chyba. Ta potvora trvala na tom, že bude ničit souborové systémy. Reprodukovat ji trvalo celé dny a naprosto odmítala odhalit alespoň malinkatý náznak toho, kde je příčina. Koukat několik měsíců do naprosto zbytečných výpisů není příliš zábavná činnost. Verze 3.0-rc7 naštěstí žádné takové chování nevykazuje.

NAT v IPv6

napsal Jonathan Corbet, 20. července 2011

Jedna z hezkých věcí, kterou měl protokol IPv6 zajistit, bylo odstranění potřeby překladu síťových adres (NAT). Adresový prostor je dost velký na to, aby motivace pro použití NATu (nedostatek adres, nutnost přečíslovat sítě při změně poskytovatele) zmizela. NAT se často považuje za hack, který rozbil architekturu Internetu, takže není málo lidí, kteří ho rádi uvidí zmizet. Přechod na IPv6 často vypadal jako příležitost to zajistit.

Není tedy překvapující, že když Terry Moës zaslal implementaci IPv6 NATu pro Linux, první odpovědi byly méně než příznivé. Každý, kdo chce vidět konec NATu, jenom těžko přivítá implementaci, která může sloužit jenom k jeho prodloužení po přechodu na IPv6. Smutný fakt ale je, že NAT tu podle všeho zůstane. David Miller to vyjádřil typicky přímo:

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.

Všichni to musí přestat popírat, teď.

Ať se nám to líbí nebo ne, s NATem se budeme potýkat navždy. Ti, které zajímá, jak by mohl fungovat v Linuxu, mohou najít Terryho implementaci na SourceForge společně s pojednáním o návrhu kódu. Podporován je bezestavový (RFC 6296) i stavový NAT.

Jak Linusovi zkazit dovolenou

napsal Jonathan Corbet, 19. července 2011

Za všecho může Hugh.

Linus už se chystal vydat finální verzi jádra 3.0, když se objevil Hugh Dickins s malým problémem: čas od času kompletní kopie stromu zdrojových kódu jádra selže, protože jeden ze souborů dočasně zmizí. Následovalo odhodlané cvičení v honu na chyby, které ukazuje, jak citlivý a záludný je základní kód. Problém byl nalezen a zlikvidován, ale mohou být i další.

K lepšímu porozumění toho, co se zde stalo, by mohlo pomoci nějaké pozadí. Vydání 2.6.38 obsahovalo patche škálovatelnosti dcache; kód používá spoustu triků k tomu, aby při vyhledávání jmen souborů nemusel zabírat zámky. Pro správnou zátěž metoda „procházky RCU“ [RCU walk] poskytuje významné zlepšení výkonu. To ale funguje jenom v případě, že veškeré relevantní struktury se záznamem o adresáři [directory entry, „dentry“] jsou v dentry cache jádra a při vyhledávání nedojde k souběhu s dalšími CPU, které se pokouší stejnou cestu změnit. Když se narazí na takovou situaci, vyhledávání se vrátí ke staršímu a pomalejšímu algoritmu, který vyžaduje zamknutí každé dentry.

Dentry cache (dcache) je velmi dynamická datová struktura, jednotlivé záznamy nepřetržitě přichází a mizí. Jedno CPU tedy může odstranit dentry ve stejnou chvíli, kdy se ho jiné pokouší použít k vyhledání jména. Chaosu se předchází používáním mechanismu čtení-kopírování-aktualizace [read-copy-update, RCU], který se stará o odstraňování dentry záznamu; záznam je možné odstranit z cache, ale pokud vlákno, které tuto dentry používá, získalo odkaz před jeho odstraněním, struktura samotná bude existovat do doby, dokud ji nějaké vlákno potřebuje. To samé by mělo platit pro strukturu inode spojenou s touto dentry.

Hugh vysledoval problém v kousku kódu v walk_component():

err = do_lookup(nd, name, path, &inode);
/* ... */
if (!inode) {
        path_to_nameidata(path, nd);
        terminate_walk(nd);
        return -ENOENT;
}

Pokud do_lookup() vrátí nulový ukazatel na inode, walk_component() předpokládá, že se narazilo na „negativní dentry“. Negativní dentry se v dentry cache ukládají a ukazují na fakt, že specifické jméno neexistuje; to je významná vlastnost linuxové vrstvy virtuálního souborového systému, která zvyšuje výkonnost. Jestli chcete vidět příklad, spusťte jakkoliv jednoduchý program pod strace a podívejte se, kolik systémových volání vrátí ENOENT; k vyhledávání neexistujících souborů dochází často. Hugh zjistil, že tento ukazatel na inode se občas vrací nulový i v případě, že soubor existuje, což kód vede k domněnce, že se narazilo na negativní dentry; to vedlo k „dočasnému zmizení souboru“.

Hugh se na tento kód musel dívat dlouho předtím, než došel k závěru, že jádro odstraňuje dentry z dcache ve špatný čas při vyhledávání. Jak bylo popsáno výše, dentry jako taková existuje i po odstranění z cache, ale to neznamená, že se nemůže změnit: odstranění nastaví ukazatel d_inode na NULL. (Stojí za to poznamenat, že toto chování jde proti obvykle praxi používání RCU, která říká, že by se struktura neměla měnit, dokud není jisté, že i poslední odkaz zmizel.) Hugh došel k závěru, že tento nulový ukazatel je později přečten při vyhledávání cesty, takže walk_component() si myslí, že soubor neexistuje, přičemž ve skutečnosti došlo pouze k odstranění dentry z cache. Hlášení o problému obsahovalo patch, který zajistil, že si kód vyhledávání lépe ověřil, že soubor skutečně neexistuje, když se mu vrátilo NULL.

Linus problém potvrdil, ale oprava se mu nelíbila, protože podle něj byla příliš specifická pro jednu konkrétní situaci. Navrhl alternativu: prostě nenastavit d_inode na NULL; ukazatel na inode by pak takovou hodnotou později nemohl nic zmást. Al Viro zaslal alternativní opravu, která měnila chování dcache méně záludněji, měl obavu ze zavedení dalších divných chyb:

Za prvé nejsem úplně přesvědčen o tom, že je dobrá optimalizace (pravděpodobně je, ale vážně mě děsí složitost, kterou tu již máme) a opravdu mě nelákají vyhlídky na řešení jakéhokoliv záludného svinstva, na které můžeme přijít s Linusovým patchem. Ještě jednou, dcache v současnosti není v příliš zdravém stavu; v tomto bodě je podle mě hloupé a přímočaré lepší než záludné věci, které by mohly šlápnout na nohu divnému kódu, který tu máme...

Jakmile uděláme audit kódu, fajn, nemám problém s tím, když se ->d_inode bude zachovávat, dokud se dentry neuvolní. Jakýkoliv kód, který závisí na tom, že ta věc bude vynulována, si koleduje o problémy a měl by být přepsán tak jako tak. Samozřejmě je háček v tom, že než ho přepíšeme, tak ho musíme najít...

Linusovi se Alova oprava nelíbila; hrozila tím, že zpomalí pomalé vyhledávání, když se bude jednat o negativní dentry. Diskuze o patchích trvala nějakou dobu; jak se snažili najít nejbezpečnější opravu chyby, oba účastníci diskuze pomalu přišli na to, že ve skutečnosti neví, co se děje. Když se na věc Linus podíval zblízka, mávnul rukama a přiznal, že je nechápe:

Takže jak vůbec může nastat Hughův NULLový inode? I u současných zdrojáků? Když se teď dívám na detaily, všechno podle mě vypadá dobře.

Jak se stává, Linusova interpretace byla dostatečná k tomu, aby Hugha nasměrovala na skutečný problém. Když je proces procházení specifickou dentry téměř hotov, do_lookup() volá __follow_mount_rcu(), která má proces vyhledávání přesměrovat, pokud se prochází přípojným bodem [mount point]. Ukazatel na inode je __follow_mount_rcu() předán samostatně; Hugh si všiml, že funkce dělá následující:

*inode = path->dentry->d_inode;

Jinými slovy se ukazatel na inode znovu načte ze struktury dentry; k tomuto přiřazení dojde bez ohledu na to, jestli dentry reprezentuje přípojný bod. To je skutečným zdrojem problému: jestliže byla dentry odstraněna z dcache poté, co proces vyhledávání získal odkaz, d_inode bude NULL. __follow_mount_rcu() vynuluje ukazatel, který ukazoval na platný inode, takže si následující kód myslí, že soubor vůbec neexistuje.

Linus zaslal opravu skutečného problému společně s nyní slavným příspěvkem na Google+, ve kterém píše, že pro jistotu zpozdí vydání 3.0 o jeden den.

Máme patch, chápeme problém a vypadá to JasněSprávně(tm), ale nemyslím si, že chci 3.0 vydat jenom pár hodin po jeho aplikaci.

Linus vydání zpozdil i přes nepříhodnou skutečnost, že to začleňovací okno 3.1 posune do jeho plánované dovolené. Z jeho strany to nicméně byla opatrnost na správném místě: JasněSprávný(tm) patch měl ZaseDalšíZáludnouChybu(tm). Opravená verze patche již existuje a tato konkrétní chyba by měla v tuto chvíli být historií.

Z této epizody je nicméně potřeba vzít si ponaučení nutící k zamyšlení. Chování dentry cache je v tomto okamžiku tak citlivé, že i kombinovaná síla mozků vývojářů, jako je Linus, Al a Hugh, jen tak tak stačila na to zjistit, co se dělo. Stejní vývojáři jsou zjevně nervózní ze změn v této části jádra. Naše přístupné a snadno programovatelné jádro postupem času zesložitělo a je stále těžší ho pochopit. Z velké části se tomu nedá vyhnout; prostředí, ve kterém jádro běží, je samo o sobě za posledních 20 let složitější a složitější. Jestliže se ale dostaneme do bodu, kde téměř nikdo nebude schopen pochopit, revidovat nebo opravit nějakou část základního kódu, budeme si zadělávat na dlouhodobé problémy.

Mezi tím bychom si měli být schopni užít vydání 3.0 (a aktualizaci 2.6.39) bez záhadně mizících souborů. Jeden potenciální krátkodobý problém nicméně zůstává: vzhledem k tomu, že další začleňovací okno se protáhne do Linusovy dovolené, je tu šance, že bude více než obvykle nabručený na správce, kteří zašlou své požadavky na přetažení [pull request] pozdě. Až se začleňovací okno otevře, moudří správci subsystému by měli být připraveni ke startu.

RLIMIT_NPROC and setuid()

napsal Jake Edge, 20. července 2011

Systémové volání setuid() v Linuxu (a dalších Unixových systémech) vždy představovalo bezpečnostní problém. Má podivné interakce s bezpečnostními a dalšími vlastnostmi jádra (např. nešťastně pojmenovaná chyba sendmailu a kvalifikací [capabilities]) a v programech se často používá chybně. Je to ale součásti unixového dědictví a bude s námi pravděpodobně přinejmenším do doby, než chyba roku 2038 ukončí trápení unixových systémů. Nedávný patch od Vasilije Kulikova pravděpodobně ukazuje tyto problémy v akci: podivné interakce omezení zdrojů a špatného používání systémového volání setuid().

Problém, který se Vasilij pokouší řešit, má poměrně historické pozadí. Roku 2003 se programy používající setuid() k přepnutí na jiného uživatele, než je root, mohly vyhnout limitu na počet procesů, které administrátor pro daného uživatele nastavil (tj. RLIMIT_PROC). To ale opravil patch Neila Browna, který způsobil, že volání setuid() selže, když je nový uživatel nad limitem.

Bohužel mnoho programů návratovou hodnotu setuid(), které má omezit jejich práva, nekontroluje. To je ve skutečnosti chyba, na kterou narazil sendmail, když byly zavedeny kvalifikace, protože nekontroloval, jestli přepnutí na nové UID opravdu uspělo. Chybné programy, které nekontrolují návratovou hodnotu, mohou způsobit poměrně závažné bezpečnostní problémy, protože předpokládají, že jejich činnost je omezena omezenými privilegii nového uživatele; ve skutečnosti přitom běží se zvýšenými privilegii (často pod rootem), se kterými byly spuštěny. Změna z roku 2003 tedy útočníkům přidala způsob, jak zajistit, aby setuid() selhalo, když se použilo RLIMIT_PROC.

Vasilij problém popsal v červnu a poznamenal, že to není chyba v Linuxu, ale umožňuje zachybovaným privilegovaným programům napáchat chaos:

Nemám za to, že kontrola RLIMIT_NPROC v setuid() je chyba (chybějící kontroly návratových hodnot systémových chování jsou skutečnou chybou), ale přilévá to olej do ohně programům, které mají špatně napsané zahození privilegií. Věřím, že situaci by bylo možné zlepšit relativně malými změnami ABI, které by neměly být viditelné pro běžné programy.

Ve svém příspěvku navrhl dvě možná řešení problému. Prvním je přesunout kontrolu RLIMIT_NPROC z set_user() (pomocná funkce setuid()) do execve(), protože většina programů návratovou hodnotu tohoto volání kontroluje (a když ne, nezpůsobí to problémy). Další návrh je ten, který roku 2006 přišel od Alexandera Peslyaka (též znám jako Solar Designer), aby selhání volání setuid() zaslalo procesu SIGSEGV, což by špatně se chovající programy ukončilo.

První řešení není kompletní, protože by to stále uživatelům umožnilo překročit limit na počet procesů tím, že by používali setuid(), které by nebylo následováno execve(), ale to je dostatečně vzácný případ na to, aby se to nepovažovalo za významný problém. Alexanderovo řešení bylo v době, kdy bylo navrženo, považováno za příliš velkou palici, obzvláště kvůli programům, které kontrolují návratovou hodnotu setuid() a takový případ mají ošetřený.

Na první pokus nedostal Vasilij žádné odpovědi, ale když s tímto tématem přišel znovu 6. července, byl příjemně překvapen kladným postojem Linuse Torvaldse:

Moje reakce je: „prostě tu bláznivou kontrolu z set_user() vyndejme úplně“. Pokud má někdo oprávnění změnit uživatele, rozhodně má také oprávnění ignorovat RLIMIT_NPROC; jak říkáš, selhání je větší bezpečnostní riziko než úspěch.

Důvodem pro RLIMIT_NPROC je snaha vyhnout se fork bombám. Pokud limit překročíme kvůli jinému důvodu, který je pod kontrolou superuživatele, koho to zajímá?

To vedlo k patchi, který mění do_execve_common(), aby vrátilo chybu (EAGAIN), pokud je proces přes limit, a kontrola v set_user() byla odstraněna. Patch byl přijat dobře, ale někteří komentátoři nebyli přesvědčeni, že by měl jít už do -rc 3.0, jak navrhl Linus. Když se Neil na patch podíval, viděl problém, který je možná potřeba řešit:

Všimněte si, že je tu prostor pro souběh, který by měl nezamýšlené důsledky.

Mezi 'setuid(běžný-uživatel)' a následujícím 'exit()' poté, co execve() selhalo, by v každém procesu vlastněném stejným uživatelem (a v danou chvíli víme, že jich je hodně), selhalo execve() tam, kde by nemělo.

Zjednodušeně je problém v tom, že přepnutí procesu pod jiného uživatele by mohl způsobit překročení limitu, ale tento limit by nebyl vynucen do volání execve() (jehož selhání by pravděpodobně způsobilo ukončení procesu). Mezitím by jakékoliv execve() v jiném z procesů daného uživatele selhalo. Není jasné, jak velký problém to je, ale rozhodně by to vedlo k neočekávanému chování. Neil navrhl patch, který by problém řešil přidáním příznaku procesu (PF_NPROC_EXCEEDED), který by se nastavil v setuid(), pokud by byl překročen limit, a následně by se kontroloval v do_execve_common() Tak by execve() selhalo jenom v procesu, který překročení limitu způsobil.

Vasilijovi i Alexanderovi se tento přístup líbil, i když Alexander není přesvědčen, že oproti Vasilijovu původnímu patchi má nějakou výhodu navíc. Také upozornil na to, že mezi setuid() a execve() může být předem neznámý interval, takže by se test na RLIMIT_NPROC měl opakovat, když se volá execve(): Bylo by trochu překvapení zjistit, že proces selhal na execve() kvůli RLIMIT_NPROC, když tento limit byl překročen před několika dny a v době volání execve() již překročen není.

Neil zatím novou verzi patche s přidaným testem nezaslal. Je tu také otázka, jestli problém, ze kterého má Neil obavu, je vůbec potřeba řešit a jestli to stojí za to přidat další bit pro příznak procesu (v současnosti zbývají pouze tři). Vzhledem k tomu, že Linus má zájem odzbrojit špatné programy, nějaká oprava se pravděpodobně dostane do 3.1. Není jasné, který přístup vyhraje, ale každopádně setuid() přestane selhávat kvůli překročení povoleného počtu procesů.

Jak poznamenal Vasilij a další, rozhodně to není chyba v jádře, co se tu opravuje. Je to ale dostatečně častá chyba v programech v uživatelském prostoru – často se závažnými důsledky – že stojí za to opravit ji v rámci proaktivního bezpečnostního opatření. Alexander vyjmenoval několik nedávných bezpečnostních problémů způsobených programy, které nekontrolují návratovou hodnotu setuid(). Také poznamenal, že problém není omezen na setuid-root programy, protože i jiné programy, které se pokouší přepnout na méně – jinak – privilegovaného uživatele, mohou také způsobit problémy, když se setuid() použije chybně.

Dopad změny je relativně malý a špatně napsaných programů v uživatelském prostoru – i těch, které mají běžet s nějakými oprávněními – je hojnost, takže je změna přijatelnější než jiné proaktivní opravy. Jak jsme viděli dříve, setuid() je zákeřná funkce a snadno se rozzlobí; může u ní docházet k překvapujícím interakcím s jinými zdánlivě přímočarými bezpečnostními opatřeními. Uzavřít díru v setuid(), i když problém žije v uživatelském prostoru, rozhodně vylepší celkovou bezpečnost Linuxu.

       

Komentáře

[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