Linux 3.7

Vyšel Linux 3.7. Mezi novinky patří NAT pro IPv6, významné změny v ovladačích pro grafiky Intel a nVidia a za pozornost stojí i vyřešení výkonnostního problému v Btrfs.

11.12.2012 11:49 | Luboš Doležel (Doli) | Nová verze

Komentáře

[Salamek]

Mezi novinky patří NAT pro IPv6
Bléééé smrt!!!

[Grunt]

Když už jsme u toho, jak se potom řeší vlastně multicast u IPv6 v případě NATu?

[pavlix]

To mi nezní jako otázka, na kterou by se dalo smysluplně odpovědět. Multicast je široký pojem, NAT je rovněž široký pojem a tyhle dvě věci spolu můžou bez problémů™ fungovat. Ale možná ses chtěl zeptat na IP maškarádu a globální multicast?

[Grunt]

Multicast je široký pojem, NAT je rovněž široký pojem a tyhle dvě věci spolu můžou bez problémů™ fungovat.

No, jasně. Jen musíš nastavit IGMP proxy (u Linuxu nevím jak). A schválně mi řekni, kdo to má? Většinou se nastaví routování, NAT, propingne se to a je hotovo, další…

globální multicast

No jasně. Teď si to definoval přesně. Ono je to stejně jedno, protože oni mezi sebou nedistribuují IGMP ani poskytovatelé, takže i když vyřešíš proxy, tak je to šumák.

[Ondrej 'SanTiago' Zajicek]

Jen musíš nastavit IGMP proxy ... Ono je to stejně jedno, protože oni mezi sebou nedistribuují IGMP ani poskytovatelé, takže i když vyřešíš proxy, tak je to šumák.

1) IGMP proxy rozhodne neni standardni reseni distribucie multicastu ale spis hack, prirovnal bych ho treba k proxy ARP.

2) 'IGMP informace' se nedistribuuji mezi poskytovateli, IGMP slouzi prevazne k domluve klient-router, mezi routery uz se nepouziva, tam je to rizeno multicastovymi routovacimi protokoly (napr. PIM-SM).

[Jendа]

No tak je tam třeba taky podpora pro protokol pro komunikaci s Marťany. Proč blésmrt? Prostě další věc, kterou asi nikdo nebude v dohledné době používat.

[Salamek]

Komunikace s martany mi prijde mnohem uzitecnejsi

[pavlix]

Měli bychom přidat ještě modul pro komunikaci s Paroubkem :D.

[otula]

Bléééé smrt!!!

No sice půjdu hlavou proti zdi (názorem proti většině), ale určitě bych to neodsuzoval. Jednak jsem si myslel, že právě uživatelé Linuxu povětšinou argumentují tím, že mít možnost je věc pozitivní (kdo nechce, ten si to v konfiguraci jádra vypne) a jednak nevěřím tomu, že by ISP začali v budoucnu po globálním přechodu na IPv6 hromadně rozdávat desítky IP adres pro každou domácnost.

[xm]

nevěřím tomu, že by ISP začali v budoucnu po globálním přechodu na IPv6 hromadně rozdávat desítky IP adres pro každou domácnost

Pletete se, jednoduše musí. Méně než /64 prefix dát prostě a jednoduše nemohou a to je sice málo (/64 prefix totiž nejde dělit na subnety, RFC doporučuje, aby ISP přidělovala malým domácnostem /56 prefix - tedy max. 256 subnetů), ale i tak to činí cca 1,8 x 10^19 adres, o mnoho řádů více než je vůbec všech IPv4 adres dohromady.

[kralyk z abclinuxu]

Už se tady někde objevila stížnost na poskytovatele, který přidělil prefix v rozporu s RFC, bylo to buď menší než 64 pro jednu síť, nebo jeden 64 na rozpodsíťování, už nevim, oboje je ale špatně...

Imho jediný způsob, jak se od ISP dočkat něčeho rozumnýho, je tlačit na ně neustále horem dolem, dokud to nebude lepší...

[Grunt]

I can clear this sky in 10 seconds flat!

Hmm…,

[Luboš Doležel (Doli)]

nebo jeden 64 na rozpodsíťování

O2

[otula]

Pletete se, jednoduše musí. Méně než /64 prefix dát prostě a jednoduše nemohou

Pokud je to tak, tak je to pro mne příjemná informace. Každopádně i tak bych se nad možností použít NAT nepohoršoval. Předpokládám, že to stejně budou distributoři mít v jádrech vypnuto a zapne si to jen ten, kdo bude mít potřebu NAT použít.

[pavlix]

Předpokládám, že to stejně budou distributoři mít v jádrech vypnuto

Z čeho ten předpoklad vychází?

[otula]

Přece z toho, že distributoři nejsou trubky, a pokud bude v jádru funkce, nad kterou odborná většina kroutí hlavou, tak ji nechají vypnutou. Ale samozřejmě to může být jinak.

[pavlix]

Ale samozřejmě to může být jinak.

K tomu bych se docela přikláněl.

[Michal Kubeček]

Co přesně si představujete pod pojmem vypnutou? Pokud to, že by podpora v distribučních jádrech nebyla zakompilovaná, tak jsem si téměř jistý, že v tomto smyslu ve většině distribucí "vypnutá" nebude.

[otula]

No jo, jak bumerang se mi vrací mé rýpání do druhých kvůli nepřesnému vyjadřování :) Ano, myslel jsem to tak, že se to "vypne" při konfiguraci, takže ve výsledku to nebude zakompilováno v kernelu.

[Michal Kubeček]

Tady bych očekával, že zvítězí pragmatické uvažování - když to tam bude, uživatelé, kteří o NAT nestojí, si prostě příslušná pravidla nenastaví a ani nenatáhnou modul a nijak je to neomezí (nepočítám těch pár KB v /lib/modules, koho tohle trápí, tak stejně bude muset smazat tolik distribučních modulů, že jeden navíc už nehraje roli). Když to tam nebude, uživatelé, kteří budou NAT chtít nebo potřebovat, budou nuceni buildit vlastní jádro. Takže bych se opravdu hodně divil, kdyby v běžných "domácích" distribucích podpora zapnutá nebyla. U enterprise distribucí může hrát roli i (ne)ochota ten kód supportovat, ale případnou neochotu IMHO převáží tlak ze strany zákazníků.

[otula]

No jo, pravda je, že jako modul to nikomu překážet nebude a že v distribučních jádrech bývá často "nejlépe všechno". Stavěl jsem se k tomu tak, že pokud si mnoho lidí klepe na čelo "k čemu to bude dobré, radovali jsme se, že se NAT konečně zbavíme", tak možná stejný postoj zaujmou i distributoři.

[sigma]

Méně než /64 prefix dát prostě a jednoduše nemohou

A bude to tak třeba i na 3G mobilním připojením nad PPP? Tam je sice technicky možnost přidělení celého prefixu, ale mám dost pochybnost, jestli to v praxi bude běžná, navíc nezpoplatněná, věc.

[pavlix]

dost pochybnost, jestli to v praxi bude běžná, navíc nezpoplatněná, věc.

Podle mě je odpověď na obě otázky ano. Tedy běžná i zpoplatněná. Zpoplatněná dost možná ve smyslu tarif pro telefon a tarif pro tethering. Operátoři o tom už stejně dlouho snili, akorát dosud se snažili (aspoň tady Vodafon) o přesný opak, tedy dát připojení pro telefon dražší než připojení pro počítač, jestli se nepletu.

[Ondrej 'SanTiago' Zajicek]

Méně než /64 prefix dát prostě a jednoduše nemohou

Pouze za predpokladu, ze budou delegovat nejaky prefix. To ale vubec nemusi a mohou klidne pouze dat jednu IPv6 adresu na spojovacim rozhrani.

[pavlix]

a jednak nevěřím tomu, že by ISP začali v budoucnu po globálním přechodu na IPv6 hromadně rozdávat desítky IP adres pro každou domácnost.

Možná proto je proti implementaci NATu takový odpor, aby náhodou ISP nepřestali ty „desítky“ (2^64 = 18446744073709551616) dávat.

[Franta]

Večer vyzkouším

A vyšel i GNU Linux-libre bez binárních blobů.

[mrmlal]

Ad ipv6 a nat... Proc fuj? A co portforwarding? Ted to musim prznit za pomoci TPROXY :(.

[Luboš Doležel (Doli)]

Pokud se nic nezměnilo, tak je to jen triviální NAT, kdy se vymění prefix adres. Nic víc.

[Michal Ludvig]

Nikoliv. Je to plně funkční NAT, NPT a MASQUERADE se stejnými možnostmi jako v IPv4. Umí to jednak vyměňovat prefix celému subnetu, ale umí to i skrýt subnet za jedinou IPv6 adresu. Vyzkoušeno, od 3.7-rc6 to provozuju na laptopu. Jen je k tomu potřeba upgradovat i ip6tables a moduly.

Bohužel problém který jsem doufal že vyřeším IPv6-NATem (t.j. IPv6 pro VMs na VirtualBoxu) se jen posunul jinam - jakmile totiž zapnu IPv6 forwarding tak se mi přestane automaticky přiřazovat venkovní adresa pomocí Router Advertisement (a co víc dokonce se v ten okamžik zruší všechny existující routy z RA). Takže sice mám možnost NATovat VirtualBoxový provoz na vnější (wlan0) adresu, ale v tu chvíli se mi na wlan0 rozbije autokonfigurace, takže je to celkem na pikaču. Samozřejmě ty v6 adresy můžu nastavit ručně a pak to chodí, ale trochu to ztrácí ten "it just works" efekt.

[petr_p]

accept_ra - INTEGER
        Accept Router Advertisements; autoconfigure using them.

        It also determines whether or not to transmit Router
        Solicitations. If and only if the functional setting is to
        accept Router Advertisements, Router Solicitations will be
        transmitted.

        Possible values are:
                0 Do not accept Router Advertisements.
                1 Accept Router Advertisements if forwarding is disabled.
                2 Overrule forwarding behaviour. Accept Router Advertisements
                  even if forwarding is enabled.

        Functional default: enabled if local forwarding is disabled.
                            disabled if local forwarding is enabled.

[pavlix]

+1

[Michal Ludvig]

2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled.

Diky, tohle jsem nevedel. Zkousel jsem jen jednicku a s ni to nefungovalo.

[Michal Kubeček]

Ono to také funguje až od 2.6.37, což není zase tak dávno.

[victor8]

na co portforwarding? mame malo adries na poriadne routovanie?

[Franta]

Např. když chceš provozovat službu na neprivilegovaném portu, ale zpřístupnit ji zvenku na privilegovaném…

[SPM]

A kvůli tomu řešit v network stacku nějaký forward paketů a NAT? To mi přijde teda dost jako prasárna :)

[Luboš Doležel (Doli)]

Když si aplikace neumí odebrat sama sobě práva roota po bind()...

[SPM]

Na druhou stranu naštěstí až tak moc takových aplikací není...

[Franta]

Ano, nejhezčí by bylo, kdyby šlo konkrétním (neprivilegovaným) uživatelům přidělit právo na naslouchání na určitých kombinacích ip/port. Jde to nějak?

[SPM]

Afaik nejde, teda alespoň jsem to nikdy neviděl... ještě by to asi šlo nějak oprasit přes inetd, ale to už je taky pěkná prasárna.

[Luboš Doležel (Doli)]

CAP_NET_BIND_SERVICE a příkaz setcap

[pavlix]

Každopádně jde opak. Selinux umí blokovat připojení aplikací k portů, které nejsou pro ně určené.

[pavlix]

Na to by měla bohatě stačit služba typu inetd, ne?

[Jendа]

A to jde i s démonem (abych nemusel při každém požadavku startovat nového workera)?

[Michal Kubeček]

Jestli jsem dobře pochopil zadání, tak by mělo stačit něco jako rinetd.

[pavlix]

Jako jde relativně cokoli, třeba můžeš z inetd volat službu, která tě propojí na socket té aplikace, třeba socat nebo netcat. Ten socat se dá použít i samostatně.

[mrmlal]

Treba kdyz potrebuji provozovat jednu sluzbu na ruznych portech a svetu ji nabizet pod jednim portem? S tim, ze za pomoci iptables prepinam instance te sluzby?

[SPM]

Tak každou tu službu namapuješ na jednu adresu a port můžou používat stejný.

[mrmlal]

Ech.. to opravdu neni schudne reseni. Zvlast, kdyz ty 2 instance maji uz rozdilna data, takze by servirovaly nesmysly.

[SPM]

Mám dvě instance nějakého daemona. Jaký je rozdíl jestli jsou nabindované na adresa1:portX a adresa2:portY nebo adresa1:portX a adresa2:portY?

[Petr Tomášek]

A co když třeba chceme adresy skrýt?

[Grunt]

Jenže to je ten problém. Furt do nekonečna se uvažuje o internetu jako o webu, tedy kdy klienti navazují spojení na nějaké hostingy (většinou na jednom místě v Praze) a tzv. brouzdají. Jenže se naprosto zapomíná, že v TCP/IP protokolu jsou takové lahůdky jako UDP nebo třeba právě multicasting (kvůli kterému musí s navázáním spojení začít strana serverová), které se tady tímto skrýváním odstřihávají od zbytku světa. A pak to vypadá jak to vypadá.

[Petr Tomášek]

UDP jako lahůdka? Ehm.

Jinak pochopitelně je vždy něco za něco...

[Grunt]

Standardně navazované a spojované UDP (podobně jako TCP) samozřejmě není problém. Cokoliv nestandardního už být začíná (třeba distribuované tabulky).

[pavlix]

UDP jako lahůdka? Ehm.

UDP je opravdu lahůdka a s IP maškarádou obecně nefunguje. Aplikace se musí chovat k UDP prakticky stejně jako k TCP, aby to vůbec fungovalo. Hodně věcí se muselo změnit.

[Ondrej 'SanTiago' Zajicek]

IMHO pro UDP a maskaradu plati v podstate to same co pro TCP a maskaradu:

1) nepredavat IP adresy a porty jako data

2) pouze strana iniciuici komunikaci muze byt za maskaradou

3) 'session' nesmi byt bez komunikace moc dlouho

[Michal Kubeček]

Problém je, že u UDP, na rozdíl od TCP, obecně není moc jasné, co to ta "session" vlastně je. Na druhou stranu, třeba connection tracking netfilteru v tom AFAIK rozdíl nedělá a i pro TCP používá stejnou heuristiku jako pro UDP. A obávám se, že podobně to bude i u většiny ostatních.

[pavlix]

IMHO pro UDP a maskaradu plati v podstate to same co pro TCP a maskaradu:

UDP vůbec nezahrnuje předpoklad, že klient navazuje komunikaci, server odpovídá za výměny zdrojového a cílového portu a veškerá další komunikace má porty nastavené stejně jako komunikace předchozí.

UDP aplikace, které chtějí fungovat za IP maškarádou musejí toto dodržovat. V případě TCP je to dáno tak jako tak.

Plus samozřejmě to, co píšeš.

[Jendа]

A co když chci v ext4 vytvořit smyčku z hardlinků na adresáře?

IP bohužel nebyl navržen jako protokol pro zachování anonymity (to je například Tor) a v něm nelze IP adresy komunikujících stran skrývat.

[Petr Tomášek]

IP bohužel nebyl navržen jako protokol pro...

Jo, jasně, Supermoudré Absolutní Bytí navrhlo IPv6 a kdožkoliv by nejednal podle jeho příkazův, do pekla bude vhozen...

[Jendа]

U IPv4 to je úplně stejné. Proto jsem psal IP (bez specifikování verze).

[Petr Tomášek]

Jo, jasně, IP bylo navrženo jako protokol pro vojenské datové sítě tak, aby odolali atomové válce.

No a? To neznamená, že by lidé (tj. např. ISP) nemohli implementovat tento protokol k takovému účelu, k jakému se jim hodí. Například tak, že použijí NAT.

Opravdu nechápu tuhle fašounskou snahu vnutit ostatním „jedinou správnou cestu,“ jak IPv* implementovat...

[Jendа]

No a? To neznamená, že by lidé (tj. např. ISP) nemohli implementovat tento protokol k takovému účelu, k jakému se jim hodí. Například tak, že použijí NAT.

No tak to samozřejmě můžou, jen nějak nevidím důvod… IPv6 adres je dost, takže NAT (ve smyslu maškarády) není potřeba.

Opravdu nechápu tuhle fašounskou snahu vnutit ostatním „jedinou správnou cestu,“ jak IPv* implementovat...

To tady vnucuje kdo?

[kralyk z abclinuxu]

To neznamená, že by lidé (tj. např. ISP) nemohli implementovat tento protokol k takovému účelu, k jakému se jim hodí. Například tak, že použijí NAT.

A k čemu je něco takovýho proboha dobrý? To mě vždycky nejvíc štvalo na všech poskytovatelích internetu: Neposkytnou ti plnohodnotný připojení, pouze polo-připojení za NATem, což je největší zlo.

Opravdu nechápu tuhle fašounskou snahu vnutit ostatním „jedinou správnou cestu,“ jak IPv* implementovat...

Můžeš tomu říkat klidně "fašounská snaha" a přidávat kolik chceš dalších hanlivých výrazů, nicméně standard je od toho, aby se "fašounsky" používala právě jediná cesta. A ne, že si každej druhej Pepa doimplementuje featury X Y, jen proto, že se mu to tak zrovna líbí, a je mu jedno, že interkonektivita půjde do háje.

[frEon]

jestli si dobre vzpominam, i takovy tu byl. Jsem zvedav jestli uz ten typek pustil fsck...

[Peter Fodrek]

A co tak pripojenie starej IPv4 siete do IPv6 siete providera.. Riesit to cez NAT je celkom uzitocne.. Vnutri IPv4 zvonku IPv6 IPcky..?

Aspon si myslim,ze je to takto myslene..

[SPM]

To řeší takové ty NAT64 apod. - tohle je čistě jenom NAT v rámci IPv6

[Jendа]

Počkat, jak že by tohle mělo fungovat?

[pavlix]

A co portforwarding? Ted to musim prznit za pomoci TPROXY

Já zpravidla przním pomocí netcatu a inetd :).

[kralyk z abclinuxu]

Mezi novinky patří NAT pro IPv6

Ehh...

[psonek]

Uz me bezi v telefonu :)

[R]

Par otazok pre anti-NAT fasistov: Predstavme si firmu s 50 PC, ktora by chcela pouzivat IPv6. 1) Ako urobim bez NATu prechod celej firmy od jedneho internetoveho providera k inemu? 2) Ako urobim bez NATu redundantne internetove pripojenie cez dvoch nezavislych providerov?

[Jendа]

1) Annoucneš do sítě nový prefix a stanice si ho změní.

2) Stanice budou mít IP obou providerů současně a budou si měnit default routu.

[mrmlal]

Co kdyz ty stanice jsou widle a do netu by mely otevrene sluzby, ktere nechci? Ono je bohuzel nekdy jednodussi ty widle nekde zariznout v jednom bode, nez to resit na kazde stanici zvlast. (cimz nerikam, ze by se nemely vypinat sluzby, ktere nepotrebuji, na stanicich).

[kralyk z abclinuxu]

Tak snad když máš X workstationů s widlema, tak je nebudeš všechny instalovat a konfigurovat ručně jednu za druhou. Vytvoříš jednu nebo několik málo konfigurací a ty rozkopíruješ na příslušné stroje. Takže zakázat ty služby by neměl bejt problém. Ale i kdyby to jó problém byl, tak tohle snad řeší spíš firewall než NAT, nesnad?

[Jendа]

I na to existuje řešení, a překvapivě je úplně stejné jako v IPv4. Jmenuje se Firewall. Stavový Firewall.

[Václav "Darm" Novák]

Dá se jen doufat že neděláte admina, nebo alespoň admina v síti ve které se kdy budu nacházet :)

[Václav "Darm" Novák]

OK, omlouvám se, dočetl jsem vše a některé argumenty jsou relativně rozumné. Takže řešíme prasárny u klientů :/ njn, ale souhlasím že tady by se to mělo primárně zaříznout u zdroje a neobcházet problém.

[R]

Cele to ma jeden problem: ako budu tie stanice medzi sebou komunikovat? Napriklad cez aku IP adresu sa bude tlacit na print server?

[Jendа]

1) Updatneš to v DNS.

2) Pořád stejně, staré IP se nemažou, takže komunikace uvnitř sítě bude fungovat dál.

[pavlix]

Když se podíváš na moji reakci, tak v případě #1 (a #3) není potřeba řešit, v případě #2 se lokální služby řeší přes ULA.

[Ondrej 'SanTiago' Zajicek]

Stanice budou mít IP obou providerů současně a budou si měnit default routu.

Zmena default routy, BTW, sama o sobe nefunguje. Protoze vyber zdrojove IPv6 adresy na default route moc nezavisi a pro funkcni failover je treba zajistit, aby klienti vybirali spravnou zdrojovou IPv6 adresu z rozsahu zrovna funkcniho providera. Nehlede na to, ze v pripade jedne gateway s dvema uplinky bude default routa na klientech stejna. Asi by to slo vyresit odjimanim ci deprekovanim prislusnych prefixu, ale celkove je to abuse mechanismu k jinemu nez zamyslenemu ucelu.

[pavlix]

ale celkove je to abuse mechanismu k jinemu nez zamyslenemu ucelu.

Ono je trochu problém, když je standard navržen tak, že plně nepokrývá problém, pro který byl určený. A zrovna autokonfigurace tím trpí hodně.

[pavlix]

Par otazok pre anti-NAT fasistov:

Tady nějací jsou? :)

Predstavme si firmu s 50 PC, ktora by chcela pouzivat IPv6. 1) Ako urobim bez NATu prechod celej firmy od jedneho internetoveho providera k inemu? 2) Ako urobim bez NATu redundantne internetove pripojenie cez dvoch nezavislych providerov?

Tyhle otázky řeším na každém školení :). Vždy je několik možností. Některé jsou správné, některé jsou méně správné. V podstatě máš tři možnosti (pokud u jedné pro kompletnost ignoruju to „bez natu“).

1) Dělat to klasickým způsobem, jako se to dělalo vždycky u větších nasazení. Tedy pomocí BGP a AS. Nevýhodou jsou neúměrné náklady na danou velikost sítě.

2) Dělat to přečíslováním. To je nová možnost s IPv6. Řeší obě otázky. Ideální pro takto malé sítě.

3) Udělat backup pomocí 1:1 NATu nezaručuje funkčnost všech aplikací. Vhodné spíše pro garážové ISP s připojenou hromadou BFU a jedním fyzickým telefonem na support (podle vzoru jede web, lidi nevolaj).

Pomocí #3 se dá dosáhnout stejně špatného stavu jako s IPv4 :). Možnosti #1 a #2 nabízejí udržení plnohodnotné konektivity. Někdy je vhodné doplnit #2 o využití ULA adres pro lokální služby, aby se jim neměnila IP.

Všimni si, že v těchto případech neexistuje důvod použít IP maškarádu, pouze 1:1 NAT.

[Petr Ježek]

Hmm, a to řešení propadu výkonnosti btrfs je kde? Není žádné. V Phoronixu je uvedeno, že je pouze lepší fsync a podmínky komprese. Leč praxi nepotrvzeno.

[mrmlal]

Jeste by me od zarytych anti-NAT katoliku zajimala jedna vec. Predstavte si, ze mate firewall F a stroj X v jednom IP rozsahu. Nedejboze stane se, ze potrebujete stroj X odnest do jine serverovny a nemuzete si prenest IP rozsah. Sstroj X ma IP adresu (ipv6, ipv4 - cert to vem) a na nej navazan dns A zaznam s TTL treba 2 tydny. Spravny postup je, ze zmenite TTL u dns zaznamu a pak A zaznam zmenite. Dejme tomu, ze zakaznik je prasatko ci idiot, ma v domenach bordel (na jeden server mu "ukazuje" 1000 domen u ruznych registratoru, vy k tem zaznamum pristup nemate, ale stale potrebujete odstehovat ten stroj (se souhlasem zakaznika).

Takze v soucasne dobe se to resi tak, ze se na firewallu F nastavi DNAT pro starou IP stroje X a ten se odnese do nove serverovny s novou IP. Vse co jde na starou IP stroje X se naflaka na novou IP a posle dal do sveta. Jsem si vedom nedostatku a toho, ze to neni 2x ciste reseni (co je?), ale zatim to tak fungovalo celkem bez problemu.

Jak tohle resit na ipv6 bez NAT?

[Jendа]

Jak tohle resit na ipv6 bez NAT?

Nevím, co třeba nějaký tunel?

[mrmlal]

Ja se prave ptam a cekam odpoved... nejaky tunel pro me neni reseni. Uvedl jsem jasne reseni a: "nevim, nejaky tunel", mi jako efektivni reseni neprijde. Google na tento vyraz take mlci.

[Jendа]

Jsem na tohle lama, ale podle mě by mělo jít třeba IPIP nebo IPSEC tunelem protáhnout traffic pro danou IP. Nebo OpenVPNkou.

[Heron]

Obávám se, že podobných příběhů vymyslíte nesčetně mnoho proti jakékoliv technologii. Místo vytváření chaosu (dnat, tunel, cokoliv), by bylo nejjednodušší vyřešit problém tam, kde nastal. Naopak, obcházení problémů na jiných vrstvách se v budoucnu dost vymstí. V chaosu DNATů jen asi těžko udržíte pořádek ve firewallu, v přenesených datech a nakonec ani v těch DNS.

[mrmlal]

Podobnou reakci jsem take cekal. A ten problem bych mel resit kde? Kde je to nejjednodussi misto? Ano.. i na toto si sam odpovim.. neprenaset ten server mezi serverovnami :D.

Jen dodam, ze vypadek mel byt co nejmensi. Pokud tam zakaznik bezel eshopy ci jine veci, ktere vydelavaji, tak cekat (v nejhorsi variante) tyden na vyexpirovani TTL u DNS zaznamu...

Bratri, spojme se a budme na sebe hodni. Lide jsou mili a inteligentni, maji stale spoustu casu a chute resit kdejake veci...

Toto bylo prechodne reseni prave na dobu nezbytne nutnou, aby si zakaznik byl schopen premlatit DNS. Vse bylo zdokumentovano a brano v potaz. Nasledne se odnasel ze serverovny i firewall F.

Osobne jsem i za tyto oberlicky rad. Nemam rad, kdyz me omezuji fanatici...

[Salamek]

Myslim ze by se daly vymyslet obezlicky i bez DNATu ktere by byly dostatecne po dobu vyexpirovani TTL u DNS...

[mrmlal]

Dalo by se vymyslet cokoli...

Tak neco prosim nadhodte.

Zatim jsem si tu jiny navrh, nez ten svuj, neprecetl. Coz je skoda.

[trekker.dk]

Tak pokud jde o web a jenom pro klienty, kteří nedodržují TTL, stačí reverzní proxy...

[kralyk z abclinuxu]

Osobne jsem i za tyto oberlicky rad. Nemam rad, kdyz me omezuji fanatici...

Tak ono existují specielní případy, jako ten, cos poopsal, kdy se nějaká format NATu hodí (tady spíš jde o DMZ, imho) i v IPv6, proto to taky nakonec do teho kernelu bylo přijato. Co "fanatikům" vadí (imho, mluvim teď hlavně za sebe) je běžná praxe mnoha ISP, kdy oni nasadí NAT a mají dojem, že to je největší zabezpečení a je jim jedno, že omezují uživatele.

[mrmlal]

Tento argument o ISP beru. Je to marketing. Mame toho malo, tak Vam to nauctujeme. Na druhou stranu... mati ani nevi, co to verejna ip je a k cemu ji vlastne pouzit :).

PS: Nekdy az prilis ryju, za coz se omlouvam. Ale znat nekdy urcite prasarny z praxe a nebyt ortodoxni se mi osvedcilo.

PPS: Za NAT v kernelu jsem rad. Konecne nebudu muset prznit NSD, aby podporovalo TPROXY.

[frEon]

Jasne ze nevi k cemu ji pouzit. Ona nejspise nevi, stejne jako moje mama, ani k cemu pouzit neverejnou ip ani ze pocitac vubec nejakou ma. Problem je, ze se internet "prizpusobl" a problem natu obchazi nejakym resenim, ktere by ve svete bez natu bylo naprosto idiotske. Trena takovej multicast, coz je super vec. Ale protoze je spousta lidi za natem, tak treba takovej youtube, nebo velky videokonference, ho nevyuziva. A to je velka skoda.

[Ondrej 'SanTiago' Zajicek]

Trena takovej multicast, coz je super vec. Ale protoze je spousta lidi za natem, tak treba takovej youtube, nebo velky videokonference, ho nevyuziva.

Problemy multicastu s NATem vubec nesouvisi. Aby multicast fungoval, musi byt nastaveno routovani multicastu na jednotlivych routerech v siti, coz prakticky nikde neni.

Krom toho, na video-on-demand jako Youtube se multicast vubec nehodi. Hodi se spis na distribuci online TV/radio vysilani a k temto ucelum se (sice jen v ramci jednotlivych ISP) i obcas pouziva.

[Jendа]

Na druhou stranu... mati ani nevi, co to verejna ip je a k cemu ji vlastne pouzit :).

Možná neví, k čemu použít „veřejnou IP“, ale třeba ví, že by chtěla telefonovat, posílat soubory, sdílet plochu a SSH, abys jí mohl na dálku pomoci, a dívat se na video.

[Martin Mareš]

Kde je to nejjednodussi misto?

Nebýt lama a před přesunem stroje snížit TTL v DNS na minutu, takže IP adresu půjde snadno změnit.

[mrmlal]

Echm... nevim, jestli jste cetl to, co jsem psal predtim. Mozna 2x cist a jednou psat? Jo jsme lamy. Zbytek vesmiru jsou taky lamy. Na zachode v mise same lamy. To co pisu je lame. :)

Navic. Nekteri registratori nastaveni TTL na 1 minutu ani nepodporuji.

Pro priste. Jak by asi rekl Pohlreich. Mozna by to chtelo vytahnout hlavu z prdele :D.

[frEon]

vytahnout hlavu z prdele a pouzit mobilni adresu tak, jak je to popsano v tom linkovanym rfc, misto vymejsleni kravin s natem a pod.

[mrmlal]

Ok. A jak to resi dns? To tam mam ten AAAA zaznam pro mobilni adresu pridat a spolehat na to, ze klient je natolik inteligentni, ze pri selhani jedne ip se vrhne na druhou?

[mrmlal]

Aha.. navic musim mit podporu na strane routeru... hm.. no to je vazne reseni.

[Michal Kubeček]

A pro ten NAT snad ne? Je to dočasná obezlička obcházející problém, do kterého jste se dostal neprozíravou konfigurací (upřímně, kdo dnes ještě běžně používá TTL 14 dnů?), ale je to podstatně čistší, než ten problém obcházet NATem.

[frEon]

Aha.. navic musim mit podporu na strane routeru... hm.. no to je vazne reseni.

no rozhodne lepsi reseni nez nat - uz jenom proto ze usetris prenosovou kapacitu linky a nemusis kvuli zmene adres prekladat novej kernel a restartovat jak pako router...

Navic mobilni ip je jedna nejluxusnejsich vlastnosti ipv6, jelikoz muzes mit stejnou ipcku at jsi kdekoliv...

[mrmlal]

Moc nechapu, proc bych mel prekladat jadro a restartovat router jako pako? Co se tyce linky: tam to vyslo v pohode a tahle rezie navic se ztratila. To uz nas vic zatezuji kreteni s UDP floody z hacklych joomel.

[frEon]

uz mas na routeru kernel 3.7?

[Michal Ludvig]

Teorie je to hezká ale bohužel neobstojí při střetu s realitou. Funkčních implementací mobilního IPv6 je stále jako šafránu.

[frEon]

uznavam, to je taky pravda...

[Michal Kubeček]

Ne. Udělat (dočasně) mobilní adresu z té původní.

[frEon]

mezitim, co navazovani spojeni resi router a dalsi komunikace bezi na primo mas dost casu zmenit nastaveni svyho dns.

[Martin Mareš]

Četl jsem a trvám na svém

Problémům se má především předcházet (a překvapivě ve zbytku vesmíru se to tak obvykle dělá). A když jednou za čas předcházení nestačí, existuje spousta daleko čistších mechanismů než NAT, kterými lze problém obejít – namátkově tunelování nebo obecná TCP proxy.

[mrmlal]

Ve zbytku vesmiru se deje veci a vsichni na to stejne se*ou. Teorie je pekna... realita je, ze lidi jsou lemry :D. TCP proxy se mi zda jako takovy NAT na jine urovni ;).

[Jaromír Svoboda]

Tak hele, to, že zítra stěhuješ server s eshopem ses dozvěděl teprve včera? To je teda divná organizace postupu. O tom jsi snad musel vědět dostatečně dlouho tak jsi měl čas na změnu TTL na cokoli lepšího. Jako jo, může se stát, že se ze dne na den něco stěhuje ale je to pravidlo?

Navíc, jak už Heron napsal:

Obávám se, že podobných příběhů vymyslíte nesčetně mnoho proti jakékoliv technologii.

[mrmlal]

Opravdu mi prijde, ze tu nikdo necte to, co pisu. Pisu, ze domeny jsou zakaznika. Ma je u ruznych registratoru. A protoze zakaznik ci registrator naznaji, ze TTL je vhodne nastavit na 14 dni, tak to tak udelaji. 14 dni jsem mozna prehnal, ale on i dvoudenni vypadek nepotesi. Jak jsem take psal, zakaznik v tom muze mit pekny bordel. Zakaznik to muze vedet klidne mesic dopredu, ale nic s tim neudela. Napriklad je to reseller, co preprodava domeny dal atd. Navic vetsina rozhrani registratoru zrovna neholduje hromadne zmene TTL u vsech zaznamu najednou... takze proklikavat 1000 domen s 2 zaznamy se protahne. Ja fyzicky nemam pristup k jeho majetku (domenam) a nemohu je tudiz spravovat. Chapu, ze si tu vsichni solichaji na svem pisecku, ale ja musim resit i tuto rezii navic.

Jinak ta mobilni adresa je pekna vec, jen by me zajimalo, jak se k tomu postavi ISP.

Co se tyce routeru a jeho konfigurace. Ja tu neresim homemade router s linuxem. Resim tu router/firewall naseho ISP (cisco povetsinou). Ono zadat ISP o rozchozeni mobility jen proto, ze potrebujeme prenest jeden server...

[mrmlal]

PS: Jeste jedna vec. Obcas se stane, ze si zakaznik nekam natvrdo hodi rovnou IP adresu. Coz je pak jeste vetsi opruz. Nejlepe, kdyz si tu ip hodi do zarizeni, ke kterym nema vzdaleny pristup a soucasne jsou po cele republice. A museji fungovat, protoze mu z nich tecou penize ;).

[Martin Mareš]

Opravdu mi prijde, ze tu nikdo necte to, co pisu. Pisu, ze domeny jsou zakaznika. [...]

Čte. Jenže on tu také ledaskdo ví, že slušní poskytovatelé síťových služeb se svými zákazníky obvykle sepíší smlouvu, v níž je na takové věci pamatováno, takže zákazník ví, že má na výběr buďto součinnost při změnách adres nebo výpadek služby.

[mrmlal]

Ano, to sice ma. Na druhou stranu.. hodlas nasrat zakaznika, co ti plati celkem slusne penize mesicne? Jen proto, ze nestihl objet republiku a nastavit si sva zarizeni? Takze ho proste odstrihnes a reknes.. sorry vole, mels to ve smlouve. Fuck yeah! Geek rules! Ordnung muss sein! To, ze on si to nastavil spatne, ja neovlivnim. V realite je to sice ve smluve, ale vetsinou se pristupuje k potrebam zakaznika.

[Martin Mareš]

Jistě. Ale s většinou zákazníků se raději předem domluvím, že se jim budu starat i o doménu, takže změny IP adres a TTL za ně zařídím a vše se stěhováním serveru zkoordinuji.

Někdy se samozřejmě může stát, že něco selže a je potřeba nějakou dobu spojení forwardovat z jednoho stroje na druhý, ale jednak jsem přesvědčen, že ve slušné společnosti je to výjimečné, druhak že na to vůbec není potřeba NAT a je lepší problém řešit o několik vrstev výše.

[mrmlal]

Tak pokud jsi mala firma, tak ok. Pokud jsi vetsi a mas tech zakazniku hromadu, navic jsou to reselleri/partneri, kteri se staraji o domeny jinym lidem... tak to proste nejde. O nekolik vrstev vys? I kdyz je tam nabusena rovnou ip? Ano, tento NAT byl vyjimka. A nebyl na dlouho. Poslouzil dobre. Proto jsem rad, ze lze delat i takoveto prasarny. Nemit moznost NATovat u ipv6 mi bere svobodu delat si prasecinky, ktere ja chci ;). Navic... s NAT v ipv6 konecne nemusim prznit NSD na podporu TPROXY :).

[pavlix]

Vrať se do reality :).

[mrmlal]

Opravdu vserikajici odpoved. Proc? Uz tu koncim s diskusi. To je jak hrach na stenu hazet.

[Martin Mareš]

O nekolik vrstev vys? I kdyz je tam nabusena rovnou ip?

Jistě.

[pavlix]

Ano, to sice ma. Na druhou stranu.. hodlas nasrat zakaznika, co ti plati celkem slusne penize mesicne?

Pokud zákazník platí hodně peněz měsíčně, tak mu to klidně přijedu osobně nastavit :D.

[Salamek]

+1

[frEon]

Vymysli si lepsi priklad, tohle resi rfc 6275.

[Michal Kubeček]

Nestačilo by (dočasně) použít mechanismus mobilní adresy?