Portál AbcLinuxu, 19. dubna 2024 01:46
Obávám se že pro člověka který o IPv6 nic neví, což je nejspíš cílová skupina článku, je to povídání jen seznamem povětšinou nevysvětlených termínů pod kterými si nedokáže nic moc představit...
Nedá mi to abych si zde nepřihřál svou polívčičku, byť již pár let uleželou: IPv6 krok za krokem
Plus se sem přidává celá řada bezpečnostních problémů, které s IPv4 nebývaly.Povídej, zatím jsem žádný nový bezpečnostní problém neobjevil.
Ostatně od toho má IPv6 i Privacy Extensions..Takže žádný problém :).
DoS útok při dotazování se, jestli už mnou vylosovanou adresu někdo nepoužívá.Hmm, dos útoky po lokální síti :). To už se mi někde stalo :). Měl jsem nastavený logy z firewallu do konzole a zapojil jsem počítač do rozsáhlé windowsovské sítě... konzole mě nepustila ke slovu :). Jen vtipná historka.... myslím, že dos útokům po lokální síti IPv6 ani nepomůže ani neuškodí.
Potom jsou tu problémy s implementací IPv6 stacku, které se dají očekávat.Problémy s implementací jsou všude a u všeho.
Windows Vista umí tunelovat IPv6 i dost agresivní metodou.Kdekdo umí argesivně tunelovat kdeco... ať už je to skype, hamachi, na provrtávání NATů jsou tu i nějaká ta RFC. Tunelování má často bezpečnostní úskalí, malá zmínka je i v příštím díle (aspoň myslím). Nepočítal bych ho ani tak do bezpečnostních rizik IPv6 jako takového.
I pro IPv6 existuje varianta ARP spoofingu, byť se tedy nejedná o nový bezpečnostní problém, jen o variaci na staré téma.Spoofovat po lokále se dá ledacos, i když ARP spoofing bych to u IPv6 úplně nenazýval... ale různému falšování identity strojů na lokálním segmentu se nezabraňuje úplně jednoduše a zadarmo.
Dokud to i tady bude ve stavu ,jo, chtěli bychom, ale nemáme na to čas a nechce se nám shánět peníze na nové krabice`, tak to bude špatný
Buďte na univerzity hodní..
DoS útok při dotazování se, jestli už mnou vylosovanou adresu někdo nepoužívá.DoS útok? Síly asi takové, jako jeden ARP request u IPv4, ne?
IPv4 tenhle povinný mechanismus nemá.Lokální ethernetový segment ti dokážu zbořit kdekoliv. A je úplně jedno, jestli na něm je IPv4, IPv6, nebo cokoliv jiného. Pokud ho chceš chránit, musíš počítače od sebe dostatečně oddělit, na všech vrstvách, nejen IPv6, a odfiltrovat všecko nežádoucí... pak by ti podle mě nezbývalo nic jiného, než přiřadit adresy staticky nebo pomocí DHCP. Tahle možnost by na IPv4 a IPv6 probíhala stejným způsobem. Stateless je v takové síti nepoužitelná. Tím jsme vlastně odpověděli i na otázku, proč existuje DHCPv6. Speciální případy vyžadují speciální řešení.
14.1.2022 15:28
Jendа | skóre: 78
| blog: Jenda
| JO70FB
From 2001:1508:1000::8 icmp_seq=1 Destination unreachable: No route
Ale jinak me propagace IPv6 tesi.
inet6num: 2001:0DB8::/32 netname: IPV6-DOC-AP descr: IPv6 prefix for documentation purpose
8 16 24 32 20 01 0D B8 20 01 15 08alebo
7.3.2008 11:13
7.3.2008 17:01
8.3.2008 00:19
7.3.2008 01:05
8 16 24 32
00100000 00000001 00001101 10111000
00100000 00000001 00010101 00001000
ja som asi blby...
Ale jinak me propagace IPv6 tesi.A bude líp :). Kdyžtak můžeš napsat... pavlix(at)pavlix.net (jabber,mail).
Drobné opravy a upřesnění, na co jsem narazil při prvním čtení:
fe80::/10, fec0::/10NAT není totéž co maškaráda, maškaráda je jednou z aplikací NATJen jsem v článku upozorňoval, že se obecnější slovo NAT často (a nepřesně) používá ve významu maškarády. Díky
fragmentace nezmizela, jen je realizována jako (povinně podporované) rozšířeníZ IPv6 hlavičky zmizela.
chybějící dvojtečky u rozsahů: fe80::/10, fec0::/10Díky.
multicast není novinka, rozdíl je spíš v tom, že u IPv6 není broadcast samostatný typ, ale považuje se za speciální případ multicastuTak to přesně bylo myšleno.
fragmentace nezmizela, jen je realizována jako (povinně podporované) rozšířeníEnd-to-end fragmentace zůstává (byť není pevnou součástí hlavičky), po cestě se už narozdíl od IPv4 nefragmentuje.
Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.
IMHO v tom není záměr, spíš řada správců z neznalosti nakonfiguruje firewall tak, že propustí jen první fragment. Tj. podobný problém, jako popisujete v dalším odstavci.
Já jsem to pochopil tak, že se dohodne na začátku... a potom už se v hlavičce neřeší (ad e2e fragmentace).Ne tak úplně, jen všichni musí dělat Path MTU discovery.
Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.Kdepak, dokonce vzhledem k tomu, že některé protokoly (třeba NFS) MTU discovery nedělají, je fragmentace po cestě nutnost. (Tím určitě nechci říci, že neexistují implementace, kde je rozbitá. Ehm.)
Takže v hlavičce nic, jen se může stát, že přijde ICMPJá jsem to pochopil tak, že se dohodne na začátku... a potom už se v hlavičce neřeší (ad e2e fragmentace).Ne tak úplně, jen všichni musí dělat Path MTU discovery.
Packet Too Big, nebo ne?
Nojo, ale aspoň TCP už se to snad obvykle řeší přes MTU discovery, ne? (aneb, když trochu upřesním předpoklady... tak se snad časem povede).Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.Kdepak, dokonce vzhledem k tomu, že některé protokoly (třeba NFS) MTU discovery nedělají, je fragmentace po cestě nutnost. (Tím určitě nechci říci, že neexistují implementace, kde je rozbitá. Ehm.)
Takže v hlavičce nic, jen se může stát, že přijde ICMPAno, a v takovém případě buďto odesílatel pošle menší packet (což udělá TCP), nebo packet sám fragmentuje na menší a jednotlivé kousky pak mají navíc Fragment Header.Packet Too Big, nebo ne?
Jsem v tuhle chvíli naDěkuji za doporučení. Já vím moc dobře jaká je situace v místě, o které se jedná.
Paní/slečna na druhé straně linky, když jsem se konečně dovolal na technickou podporu....To musíte použít formulář na jejich webu a pak vám odepíše mailem člověk, co dokonce umí přečíst RFC a vysvětlí vám, že je jenom informational, a tedy není pro ně závazazné odesílat ICMP Packet too Big, když se jejich PPP server pokusí zabalit paket větší než 1492 B. Na druhou stranu je musím pochválit, že když jsem si stěžoval, že nesměrují 192.88.99.1, tak to dokázali opravit a ještě pohanit Španěly, kteří prý byli toho příčinou.
Jinak jedno iptables pravidlo v mangle tabulce problém vyřešilo.Vím a taky mám, jenže to řeší jen TCP. Co ostatní transportní protokoly?
Priste s reakci vyckam do rana bileho, kdy ze mne vyprcha to drobne rozcarovani a zacnu se na to koukat strizlivejsim okem :)Doporučuju. A až strávíš noc prolézáním RFC... :D.
Pokud je komentář extrémně vulgární, navádí k porušování platných zákonů (warez) nebo je přímo porušuje, mohou administrátoři označit komentář jako závadný. Pak obsah komentáře bude skryt, místo něj bude zobrazeno zdůvodnění administrátora.extremna vulgarita, ROTFLMAO xD
ujo, nebud precitliveny, ved vo vasich diskusiach sa casto vyskytuju aj "horsie" slovaBuď to není pod články, nebo o tom nevíme.
viem, ze som ta minule asi nastvalTo nebyl důvod pro cenzuru. Ostatně si na tebe nepamatuji, sorry. Každou chvíli mě někdo naštve :-).
Pro většinu domácích i firemních uživatelů je internet a web to samý. Znamená to tedy, že internet je web?Nemyslím že jsem něco podobného říkal. Ale když už jsme u toho... drtivá většina uživatelů má na stole počítač který se chová jako klient a ten když má dělat něco rozumného připojí se k serveru. Takhle to funguje s webem, s mailem, umí tak fungovat většina IM i herních protokolů, fungují tak fileservery, printservery a všechnyostatníservery. Komunikace klient-klient naproti tomu není zdaleka tak obvyklá jako klient-server a až na několik výjimek se bez ní dá obejít. Ty výjimky jsou buď pitomě navržené protokoly, které v případě že nefunguje klient-klient komunikace nemají fallback na klient-server (jakkoliv uznávám že v některých případech by tento fallback mohl mít vliv na efektivitu komunikace). Druhý případ výjimek jsou situace kdy jedna strana ve skutečnosti vystupuje jako server a nikoliv jako klient, což může být třeba v případě že se někdo chce na můj desktop připojit přes SSH nebo přes některý z remote desktop protokolů. Naštěstí ve většině případů (bavme se o reálném světě, nikoliv o vašem zbožném přání) tahle situace nastává jen v rámci interní NATované sítě kde každý vidí každého. Takže v rámci mé sítě se můj desktop může chovat jako server i klient zároveň a směrem do Internetu jen jako klient. A až na VoIP mi nejspíš bude všechno fungovat jak má. Jistě by bylo pěkné, v případě že chci třeba provozovat doma veřejně přístupný server, mít možnost dostat pro něj od providera vyhrazenou fixní adresu. Že tohle často není možné ale není ani chyba IPv4 ani chyba NATu ale chyba těch providerů.
Vybral sis na komentování špatnej portál.Ale jdi ty chytrolíne
umí tak fungovat většina IM i herních protokolů
Ale za jakou cenu?
fungují tak fileservery, printservery a všechnyostatníservery
Máte velmi omezenou představu o tom, co všechno Internet nabízí a hlavně co by mohl nabízet. Tomu se ale bohužel nelze divit, právě dnešní neutěšená situace zamaškarádovaných "klientů" k takovému deformovanému vnímání Internetu vede.
Že tohle často není možné ale není ani chyba IPv4 ani chyba NATu ale chyba těch providerů.
Je to chyba IPv4; adresní prostor IPv4 je nedostatečný a ví se to už nejméně 15 let. Nelze to vyčítat jeho původním architektům, protože těžko mohli předpokládat, že jejich projekt někdy nabyde dnešních rozměrů, a kdyby hned na začátku navrhli např. 64-bitové adresy, bylo by to při tehdejších hardwarových prostředcích příliš nepraktické. Chybou je pouze to, že se ještě dnes IPv4 používá pro téměř veškerou komunikaci.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j REJECTJenže to strašně degraduje původní myšlenku. Nat slouží akorát k anonymizaci, zabezpečení je vedlejší produkt (IPv6 má pro anonymizaci privacy extensions). Nebo snad někdo chce tvrdit, že zombie počítače jsou jen za na veřejných IP? Sám jsem zažil několikrát situaci, kdy 2-3 kousky těhle strojů (za natem) málem sundaly routery. Po praktických zkušenostech vím, že nat nestačí. Je třeba udělat ještě pár pravidel na filtrování portů. Nehledě nato, že nat je hrozná brzda.
Jinak NAT jako security feature je nesmysl. Je to to samý, jako když dám do iptables 2 pravidla:
Naopak, maškaráda ochrání síť podstatně méně než tato dvě pravidla. Tato pravidla zabrání navázat spojení zvenku. Maškaráda sama o sobě ne.
/dev/hell.
Vybral sis na komentování špatnej portál.Je tohle nutné? Doporučuji trochu více tolerance nebo aspoň diplomatičnosti.
Nechcete celemu svetu zdelovat ze pouzivate zarizeni konkretniho vyrobce jednoduse pomoci IP adresy (MAC je soucasti autoconf IPv6)Doporučuju pročíst i privacy extensions. Pokud je zapneš, netýká se tě ani počet počítačů, ani MAC adresy.
To co předvádíte je degradace InternetuNikoliv, to co předvádím je popis reality.
Jinak NAT není firewall a ani jím nemá být. Ta "bezpečnost", kterou podle vás NAT poskytuje, je jen a pouze iluze.Tohle je oblíbené tvrzení které mi zatím nikdo uspokojivě nevysvětlil. Můžete být můj první
Řekněme že chcete zabránit útoku z venku na počítač v interní síti. Pokud máte NAT není ta interní IP přímo adresovatelná z venku takže útočník musí nejdřív získat kontrolu nad NATovadlem a odtamtud se teprve dostat na váš interní stroj. Čili hlavní obrana bude ležet na přístupu na NATovadlo (v případě linuxu to bude v iptables INPUT chain plus patřičné aplikace jako ssh).
Pokud na druhou stranu má interní stroj veřejnou IP tak se útočník z venku může rovnou pokusit o přístup. Jistě že máte firewall, ale na jeho ochranu musíte vynaložit úplně stejné úsilí jako v případě NATovadla, protože jakmile se útočník dostane na FW bude mít přístup do vnitřní sítě. Ovšem navíc se musíte zabývat forwardovacími pravidly firewallu. I když zakážete veškerý provoz ve směru do vnitřní sítě, stále může dojít k situaci kdy v implementaci iptables FORWARD chainu bude chyba která umožní tohle blokování nějakým způsobem prolomit bez toho aby útočník musel přímo získat kontrolu nad firewallem.
Takže NAT opravdu z principu své funkce funguje jako efektivní (nikoliv jediná) vrstva v ochraně sítě.
Pokud stále trváte na svém výše uvedeném tvrzení že bezpečnost kterou NAT poskytuje je jen iluze tak prosím předložte nějaké argumenty.
Nat jde prostrelit pres pakety smerovane zdrojem
Pokud je útočník ve stejném segmentu jako brána (což v mnoha případech nelze vyloučit), nepotřebuje ani ten source routing.
Že před několika desetiletími předpokládali "otcové" internetu že každé dva uzly spolu budou moci přímo komunikovat je sice pěkné, ale v dnešní době to prostě neplatí.
Jenže je to zdrojem četných problémů a důvodem k vymýšlení neuvěřitelně krkolomných a místy až absurdních řešení, kdy spolu nezřídka dva počítače v jednom ethernetovém segmentu komunikují přes server na druhém konci světa. Maškarády mají sice zásluhu na zpomalení vyčerpávání adresního prostoru IPv4, ale to je vykoupeno tím, že významnou měrou přispěly k oddalování skutečného řešení problému.
V dnešní době ten rozdíl je - server má veřejnou, fixní IP, klient zhusta nemá veřejnou a málokdy má fixní IP a s tímhle rozdělením se dá docela dobře fungovat.
Jistě. Třeba pro VoIP komunikaci je to velice praktické uspořádání…
BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu
Na to nelze zapomínat, protože to především vůbec není pravda. Maškaráda (ani jiná aplikace překladu adres) nebrání přístupu do vnitřní sítě, to je jen hojně rozšířený omyl. Přístupu do té sítě brání filtr a bude mu bránit i bez maškarády.
věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích
Stále věřím, že tomu tak nebude. IMHO lze např. označní site-local adres jako deprecated chápat jako signál, že v tomto ohledu nejspíš výjimečně zvítězí zdravý rozum nad hloupými návyky.
A to je jen kvuli takovym lidem jako ses tyFííííha, lidi už mi připisovali lecjaké zásluhy, ale nedostatek IPv4 adres zatím nikdo! Jsem oslněn a poctěn
Jdu spát...
Potřeba end-to-end konektivity přišla až s voip, IM a p2p sítěmi, které se začaly rozmáhat až po nástupu NATů.Treba tradicni talk (jehoz historie saha nekam do pulky osmesatych let) vyzaduje take end-to-end konektivitu.
Nedostatek IP adres se nás tedy netýkal, přesto ta vaše idea "přímé" komunikace nefungovala. Podle network policy byl na celém subnetu stavový FW, a příchozí spojení bylo filtrováno.
Je zatraceně velký rozdíl mezi tím, zda je jen věcí vaší volby, jaké komunikační kanály, odkud a kam povolíte, nebo zda tomu brání obezlička, ke které jste donucen nedostatkem adres, a na vybranou nemáte.
NAT řeší reálný problém (nedostatek adres)
Maškaráda (protože tu máte na mysli, ne NAT obecně) problém nedostatečné velikosti adresního prostoru IPv4. Naopak, dalo by se říct, že bujení maškarád řešení tohoto problému naopak oddálilo.
protože nastal mnohem dříve, než se nedostatek adres vůbec začal projevovat.
Určitě? Na podzim 1992, kdy jsem se poprvé setkal s Internetem, už se o tomto problému vědělo a už tehdy dávala extrapolace dosavadního vývoje odhad, že nezmění-li se něco, adresy do dvou let dojdou. Přesto ještě o pět let později byla naše katedrální tiskárna dostupná z celého světa…
ta vaše idea "přímé" komunikace nefungovala.Já spíš mám z toho, co píšeš pocit, že fungovala dobře, jen byla omezená bezpečnostní politikou, kterou si firma sama schválila. Povolení přístupu z venku na počítač je bezpečnostní riziko :), nicméně servery dostupné z internetu existují (a bezpečnost se u nich obvykle řeší jiným způsobem než odfiltrováním nebo vytažením kabelu).
NAT řeší reálný problém (nedostatek adres), výměnou za featuru, která byla už stejně dávno mrtvá.No comment.
BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu a věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích.Ta bezpečností vrstva se v prostředích, kde není NAT obvykle nazývá Firewall.
NAT je připojení do internetu pro drtivou většinu domácích i firemních uživatelů.
Mate pravdu, ze pro "konzumni ucely" to "vetsinou staci". Je to ale velmi omezeny pohled. Kvuli nedostatku IP adres a NATu privatnich adres mame miliony siti ktere maji kazde tu samou adresu 10.x, mame miliony zbytecnych port redirectoru na routerech, mame slozite a packety prepisujici algoritmy pro podporu protokolu jako FTP.
Uz jste se nekdy setkal s problemem, ze Vas uzivatel se nemohl pres VPN pripojit na firemni mail, a to jen proto ze lokalni natovana sit mela stejny "privatni" rozsah jako Vase firemni? Uz jste si nekdy zkousel s kamaradem udelat VPN pripojeni a zjistil jste ze kamarad ma tu samou "privatni" IP adresu jako Vy?
Uz jste nekdy zkousel mit na natovane siti verejne dostupne sluzby? Je to pokazde o tom zavest nejaky uchylny port forwarding. Uchylne dualni konfigurace name serveru, NAT vyjimky pro lokalni uzivatele, a takto by se dalo pokracovat.
BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu a věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích.
Nebudu tady naznacovat, ze NAT sam o sobe neochrani ani ň, ale zamysleme se nad tim co internet znamena pro bezna "konzumni" PC. Davame vsechny svoje PC s internet-nedospelym OS za NAT a nebo extra firewall, jelikoz na "zivem" internet pripojeni by neobstaly. Jak muzeme ocekavat rozsahlou adopci IPv6 s "zivymi" adresami kdyz uroven bezneho uzivatelskeho PC je 10 let pozadu za soucasnosti?
V čem krabička s linuxem vevnitř a takovýmto nastavením iptables:Nebudu tady naznacovat, ze NAT sam o sobe neochrani ani ň, ale zamysleme se nad tim co internet znamena pro bezna "konzumni" PC. Davame vsechny svoje PC s internet-nedospelym OS za NAT a nebo extra firewall, jelikoz na "zivem" internet pripojeni by neobstaly. Jak muzeme ocekavat rozsahlou adopci IPv6 s "zivymi" adresami kdyz uroven bezneho uzivatelskeho PC je 10 let pozadu za soucasnosti?
7.3.2008 17:07
iptables -P FORWARD DROP
iptables -A FORWARD -i ${vnitrni_rozhrani} -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -a POSTROUTING -o ${venkovni_rozhrani} -j MASQUERADE
bezpečnější oproti krabičce s:
ip6tables -P FORWARD DROP
ip6tables -A FORWARD -i ${vnitrni_rozhrani} -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
?
dále zmíněné řešení bude bezpečnější.IMHO nebude. Privacy extensions ti vyřeší počet strojů, mac adresy apod. Firewall ti vyřeší nevyžádané přístupy zvenku.
tak ta konfigurace musí být o dost složitější.O dost složitější... to jako jedno zaškrtávací pole typu "povolit připojení k počítači zvenku" či "nechránit počítač firewallem"? Co bys chtěl... do teď to zaškrtávací pole nebylo, protože to nešlo vůbec... nadávat na možnost povolit připojení k počítači zvenčí... to jsme se dočkali věcí. I obyčejný "firewall" ve windows tuším ve výchozím nastavení přístup zakazuje, tak proč by stejné nastavení nemohlo platit i pro forward na domácích routerech?
Co se týče toho firewallu u IPv6, tak rozhodně firewall, který bude fungovat tak, že dovnitř nepustí žádné nové spojení, ale jen co navazuje na existující bude mít ten efekt, že se pro vást nemalá část IPv6 světa stane nedostupnou. Bohužel v IPv6 se předpokládá pár věcí, které takto nastaveným firewallem zrušíte a máte smůlu (třeba jen blbým nepovolením ICMPv6 ECHO odříznete ty, kteří používají Teredo tunely, protože oni si prvně přes ping očmuchávají protistranu a pomocí echo reply dojde k sestavení dynamického tunelu).
Podívejte se na pár RFC, které se zabývají doporučením, jak řešit ochlanu lokální sítě na IPv6. Třeba RFC 4890 řeší jen otázku ICMP protokolu, jeho součástí je i demo konfigurace, jak by takový firewall pomocí iptables měl ideálně vypadat, aby to chránilo vnitřní síť a zároveň udrželo IPv6 v maximální možné míře funkční. Ten výpis je na 7 stránek, a to je trošku dost víc, než ty tři řádky uvedené o pár příspěvků výše.
Pokud jsme si vědom, tak jsem snad psal, že mámli IPv4 síť jen za NATem, tak je to míň bezpečnější, než IPv6 síť za firewallem.Tak toho jsem si úplně vědom nebyl.
Podívejte se na pár RFC, které se zabývají doporučením, jak řešit ochlanu lokální sítě na IPv6.Určitě to ještě projdu :).
Ten výpis je na 7 stránek, a to je trošku dost víc, než ty tři řádky uvedené o pár příspěvků výše.Dobrý firewall byl vždycky trošku delší než tři řádky. Zakázat vše zvenčí není horší než NAT, o to mi šlo, detaily nastavení firewallu, aby fungovaly věci, které IPv6 přináší navíc, to už je jiná věc. IPv6 věci komplikuje pouze tím, že umožňuje pracovat bez NAT. Kvůli bezpečnosti se dá velmi jednoduchý firewall, který má ale vedlejší efekt, že pohřbí výhody, které jsme získali. Novou věcí je to, že ten vedlejší efekt pro konkrétní chtěné přístupy zvenčí chceme napravit. Nebo ne?
Dále ta konfigurace firewallu pro IPv6 (jak ji máte uvedenou) vám zajistí, že budete pro značnou část IPv6 světa nedostupný, pokud bude takto konfigurovaný, aby vám fungoval korektně provoz pro IPv6, tak ta konfigurace musí být o dost složitější.Coby člověku provozujícímu VoIP zařízení je mi to docela jasné. Účelem ale bylo ukázat nesmyslnost tvrzení o vylepšování bezpečnosti pomocí NATů.
To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu...Bezpečnostní problémy lze řešit jinak, než schováváním se. A pokud někdo provozuje k zavirování náchylnou parodii na OS, je to jeho problém a nevidím důvod, proč kvůli tomu omezovat nás ostatní.
Bezpečnostní problémy lze řešit jinak, než schováváním se.Jiste. Ale i schovavani je docela ucinou metodou. Stejne tak lze mozna nedostatek IPv4 adres resit jinak, nez prechodem na IPv6. Uvidime jak se to vyvine; o IPv6 se se mluvi uz dlouho a stale se prakticky nic nedeje; nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)
A pokud někdo provozuje k zavirování náchylnou parodii na OS, je to jeho problém a nevidím důvod, proč kvůli tomu omezovat nás ostatní.1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatu 2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win) 3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd) 4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi. 5) skutecne si myslite, ze vase lednicka a varna konvice musi byt dostupne z internetu? Verite ze OS ve vasi lednice a varne konvici bude dostatecne zabezpecen a bude se pravidelne updatovat?
Je vlaste i ve vasem zajmu, aby bylo nakazenych pocitacu co nejmene, nema to s OS moc spolecneho, protoze jediny pocitac ktery je 100% bezpecny je jen ten, ktery neni pripojen do site... Muzete rikat "parodie na OS", ale ve vetsine pripadu nemate zatim rozumnou alternativu (vetsina uzivatelu si porizuje nejlepsi dostupne reseni, ktere si mohou dovolit, kdyby si mysleli ze Linux je nejlepsi, meli by jej; k cemu nejlepsi OS, kdyz k nemu nejsou aplikace??
nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)To si snad děláte jen blbou srandu??? Lidem s tak stupidními názory bych nejraději přístup na Internet zakázal (dřív než bude pozdě a než ho zničí) :-P Ale naštěstí takových exotů jako jste vy je mezi technicky vzdělanými lidmi naprosté minimum, to mě hřeje u srdce
nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)Budu dělat, že tohle jsem nečetl, protože jinak bych musel použít slova jako blbec a podobná...
1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatuVšechny, které byly v distribuci. Tzn. minimálně opravu toho lokálního získání roota.
2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win)To je jeho blbost. A kvůli blbosti jiných se přece já nenechám omezovat.
3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd)Od toho je tu ISP, aby takové PC odstřihl od sítě a řekl majiteli, ať si to nechá spravit.
4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi.Viz předchozí mojí větu.
5) skutecne si myslite, ze vase lednicka a varna konvice musi byt dostupne z internetu? Verite ze OS ve vasi lednice a varne konvici bude dostatecne zabezpecen a bude se pravidelne updatovat?Mě by stačil počítač.
Stejne tak lze mozna nedostatek IPv4 adres resit jinak, nez prechodem na IPv6.Jistě, třeba IPv9 žejo :D.
Uvidime jak se to vyvine; o IPv6 se se mluvi uz dlouho a stale se prakticky nic nedeje;Jen dění okolo IPv6 možná dostatečně nesleduješ.
treba rozdeleni internetu na nekolik separatnich oblastiInternet je od slova internetworking, neboli propojování sítí, ne jejich rozdělování.
Muzete rikat "parodie na OS"Offtopic (už od toho, na koho reaguješ), no comment.
Offtopic (už od toho, na koho reaguješ), no comment.OS, který na počítači běží, je offtopic vzhledem k To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu.... ??? Zdá se, že politická korektnost začíná pronikat i do IT.
Někde se trefuješ do reality, někde ne.Bez konkrétního ukázání, kde se netrefuju do reality a kde jo, je vypovídací hodnota tvého příspěvku nula.
1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatu 2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win) 3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd) 4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi.
A v čem konkrétně podle vás v tomto ohledu pomůže další oddalování přechodu na IPv6? Uvědomte si, že dnes je jen velmi malá část počítačů, o nichž tady mluvíte, napadena klasickým útokem zvenčí. Mnohem častější je to, že si uživatel pustí do počítače škodlivý kód sám (ať už pomocí webového prohlížeče nebo mailového klienta).
. Pokud se IPv6 nakonec prosadi, bude to mnohem pozdeji, dnes si dnes myslime... Nebo ze by zmenu prineslo uvolneni nekolika zhavych filmu na IPv6 zadarmo? To by byla dost pikantni historie prosazeni IPv6...
Silni hraci sve IPv4 rozsahy maji, nedostatek IP address trapi prezne jen nove subjekty
Nedostatek adres trápí i ty "zavedené" (jen si to někteří neuvědomují). Nebo snad myslíte, že když někdo se skřípěním zubů funguje nad IPv4 s maškarádami, znamená to automaticky, že IPv6 nepotřebuje nebo nechce?
Domacim uzivatelum staci ve vetsine pripadu jen pristup pres NAT (vyjimkou jsou "piratske" p2p a domaci servery, mozna i VoIP).
No vidíte, že i vy sám víte o službách, které s vaším oblíbeným dělením na klienty a servery nevystačí.
proc si myslim, ze IPv6 muze skoncit ve slepe ulicce jako se to stalo i jinym skvelym technolgiim (OSI sitovy model
Mohl byste tu myšlenku s OSI modelem blíže upřesnit?
BTW, moc toho o IPv6 nevim
Všiml jsem si…
Chapu to tak, ze nejvetsi motivaci pro IPv6 je aby kazdy pocitac mohl byt dostupny na internetu. Nekteri rikaji, ze IPv4 adresy jiz dosly, podle jinych se tak melo stat nejpozdeji v roce 2010. Pote co byly uvolneny nejake IPv4 site, je mozno s IPv4 dozit do 2012. Jsou tato fakta spravna?Z toho, že dnes každý protokol musí řešit, jak se dostat přes NAT (a tedy z toho, že NAT dnes není nějaká podivná výjimka, ale věc, se kterou se musí počítat), lze snadno dovodit, že IPv4 adresy už (dávno) došly.
Přesně tak. Ten argument je asi tak přesvědčivý jako tvrdit, že monopol Českého Telecomu byl vlastně strašně skvělý, protože tím podpořili rozvoj bezdrátového připojení k Internetu.
Vemte si, kolik by se ušetřilo výpočetního výkonu, kdyby servery ICQ nedělali nic jiného, než login+client routing (maximálně offline zprávy). To by byl luxus. 90% věcí by šlo posílat někde extra mimo servery.
No jo, ale to přece nejde, to by se pak mnohem hůř odposlouchávalo… :-)
Diky za NAT a maskarady! Dovedete si predstavit tu hruzu, kdyby kazdy koncovy pocitac byl pristupny z interentu? To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu....Už se tu o existenci firewallu psalo.
Osobne v IPv6 moc neverim, kdyby bylo potreba, uz by bylo nasazeno. Zatim je to jen experiment a u toho asi i zustane (viz prispevek vyse, ze jej ani v roce 2008 univerzity neuzivaji; university nemaji vlastne ani moc motivaci, vetsinou maji vlastni IPv4 rozsah...).Univerzity motivaci k pokroku mají, jinak by nevzniklo ani IPv4. IPv6 není jen experiment, je to upgrade staršího protokolu. Otázky víry jsou jedna věc, jak se věci vyvinou věc druhá, já věřím, že IPv4 je z důvodu nedostatku adres dlouhodobě neudržitelné. Ostatní věci beru jako příjemný bonus.
Diky za NAT a maskarady! Dovedete si predstavit tu hruzu, kdyby kazdy koncovy pocitac byl pristupny z interentu?Tomu ale NAT nijak principiálně nebrání. Je to jenom vedlejší účinek některých implementací NATů, a jakožto vedlejší účinek to samozřejmě není testováno, zda tou skutečně brání, či nebrání (ostatně různé tunely skrze NAT jsou důkazem toho, že nebrání, jen komplikuje). Ostatně NAT může být klidně udělán tak, že každý koncový počítač za ním bude z internetu dostupný…
8.3.2008 21:28
x portů z jedné IP adresy na x různých kombinací IP adresa : port z vnitřní sítě je také NAT. NAT, který bude všechny porty z jedné IP adresy směrovat na odpovídající porty počítače ve vnitřní síti po dobu jedné hodiny, a po hodině se přepne na další počítač atd., je také NAT. A tak dále. To, o čem píšete vy, k tomu (mimo jiné) slouží firewall.
Ale ochrani treba pocitace, ...Slyšel jsi někdy o firewallu?
7.3.2008 15:05
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Firewall tu není od toho, aby cokoliv kam přeposílal. A portů je dost tak akorát pro jeden počítač.
Máme to ve firmě, jedna adres ven a podle portu se pak dostanu ne určenej počítač.
Takže se připojuješ na jednu IP, jen na různé porty. Nebylo by praktičtější se připojovat na konkrétní adresy (těch různých strojů) a standardní port dané služby?
BTW: Těch 67 milionů vrácených IP adres mi z pohledu IPv6 připadá jako plivnout do oceánu.
ip.
9.3.2008 12:20
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Já používám Mikrotik RouterOS, který je ale spíš cílený na zkušenější uživatele :D.Prosím?
O co prosíš?Já používám Mikrotik RouterOS, který je ale spíš cílený na zkušenější uživatele :D.Prosím?
9.3.2008 19:45
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Samozřejmě oproti domácím routerům s dodávaným firmware, nesrovával jsem s OpenWRT, pokud ti jde o tohle. Ale vzhledem k tomu, že se vyjadřuješ dost podivným způsobem, můžu jenom zkoušet hádat a číst myšlenky, třeba jsem se vůbec netrefil. Příště zkus napsat i o co ti jde :).Mně jde jen o to že RoS je spíše klikací frontend k Linuxovému jádru pro Windowsáky, který se snaží zjednodušovat než-li zařízení pro pokročilejší. Což je i jedna z příčin stavu síti s tahačema.
9.3.2008 21:06
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Systému s příkazovým řádkem říkáš klikací frontend?Máte na mysli tu parodii BASHe? Ale ne, zase tak moc hanit ho nemůžu a bohu dík alespoň za něj(Což už se u jiných věcí na RoS říct nedá). Není CLI jako CLI. A myslím si, že RoS se nekupuje kvůli hlavně tomu CLI.
9.3.2008 21:51
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Parodii na BASH? Vždyť to s BASHem není téměř v ničem podobné.Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).
Mě jejich příkazové rozhraní vyhovuje.Mně až na malé drobnosti také, bohužel oficiálně nedovoluje všechny vymoženosti z GNU systémů, což mě nehorázně štve.
Jsem si vědom toho, že není tak flexibilní jako ručně poskládané řešení na bázi Linuxu nebo BSD, ale na hraní tu mam jiný mašiny.Oficiálně není tak flexibilní, trošku větší otevřenost by jim určitě neuškodila.
Ale ve skutečnosti jediné, co nabízí navíc jsou grafy, které jinak se do textu blbě kreslí.O čem je řeč?
Doporučuju používat nebo nepoužívat, ale neurážet, podle mě je to moc hezká práce,Z různých distribucí a OS bych si dovolil tvrdit, že i jedna z nejpovedenějších , ale nenabízí vše.
jak hardwareMyslíte RouterBoardy?
Jak už jsem řekl, vyhovuje mi.Parodii na BASH? Vždyť to s BASHem není téměř v ničem podobné.Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).
Já jsem s tím smířený, jak už jsem řekl, na hraní mám jiné stroje.Mě jejich příkazové rozhraní vyhovuje.Mně až na malé drobnosti také, bohužel oficiálně nedovoluje všechny vymoženosti z GNU systémů, což mě nehorázně štve.
Možná.Jsem si vědom toho, že není tak flexibilní jako ručně poskládané řešení na bázi Linuxu nebo BSD, ale na hraní tu mam jiný mašiny.Oficiálně není tak flexibilní, trošku větší otevřenost by jim určitě neuškodila.
Traffic, převážně.Ale ve skutečnosti jediné, co nabízí navíc jsou grafy, které jinak se do textu blbě kreslí.O čem je řeč?
Zato nabízí to, co potřebuju, v trošku lépe (pro mě) použitelné podobě. Šetří mi čas, ve kterém si pak můžu hrát s jinými věcmi.Doporučuju používat nebo nepoužívat, ale neurážet, podle mě je to moc hezká práce,Z různých distribucí a OS bych si dovolil tvrdit, že i jedna z nejpovedenějších , ale nenabízí vše.
Jj, co jiného.jak hardwareMyslíte RouterBoardy?
Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).
Řekl bych, že důvod, proč tam není bash, je obsažen v první větě sekce Bugs manuálové stránky:
It's too big and too slow.
9.3.2008 22:44
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Ale no ták:Řekl bych, že důvod, proč tam není bash, je obsažen v první větě sekce Bugs manuálové stránky:
It's too big and too slow.
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 [ -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 ash -> busybox
-rwxr-xr-x 1 root root 3232 2008-01-25 09:41 ask
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 basename -> busybox
lrwxrwxrwx 1 root root 3 2008-02-22 13:21 bash -> ash
-rwxr-xr-x 1 root root 421 2008-01-24 15:37 bash_login
-rwxr-xr-x 1 root root 540 2008-02-15 09:43 burnK6
-rwxr-xr-x 1 root root 604 2008-02-15 09:43 burnK7
-rwxr-xr-x 1 root root 532 2008-02-15 09:43 burnP5
-rwxr-xr-x 1 root root 540 2008-02-15 09:43 burnP6
-rwxr-xr-x 1 root root 154516 2008-02-15 09:42 busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 cat -> busybox
-rwxr-xr-x 1 root root 8092 2008-01-25 11:32 catlog
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 cp -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 date -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 echo -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 expr -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 find -> busybox
lrwxrwxrwx 1 root root 15 2008-02-22 13:21 gosh -> /nova/bin/login
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 hostname -> busybox
-rwxr-xr-x 1 root root 332903 2008-02-24 22:04 htop
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 chmod -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 chown -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 ln -> busybox
lrwxrwxrwx 1 root root 15 2008-02-22 13:21 login -> /nova/bin/login
lrwxrwxrwx 1 root root 12 2008-02-24 22:08 ls -> /bin/busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 mkdir -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 mknod -> busybox
-rwxr-xr-x 1 root root 43 2008-01-24 15:37 mlogin
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 mount -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 mv -> busybox
-rwxr-xr-x 1 root root 7084 2008-01-25 11:32 pacd
-rwxr-xr-x 1 root root 5508 2008-01-25 11:32 pakp
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 rm -> busybox
lrwxrwxrwx 1 root root 4 2008-02-22 13:21 sh -> bash
lrwxrwxrwx 1 root root 17 2008-02-22 13:21 shell -> /nova/bin/console
-rwxr-xr-x 1 root root 72008 2008-02-15 09:42 telnet
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 test -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 touch -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 umount -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 uname -> busybox
lrwxrwxrwx 1 root root 7 2008-02-22 13:21 usleep -> busybox
Mikrotik krabicku (RB133) mam na stole, zrovna tu jsem nemyslel, neni to typicke SOHO zarizeni, spise stavebnice...Všechno je to na jedno brdo. Nějaké ořezané embedded zařízení s Linoxovým jádrem(+ OSS nástrojema) a nějaký klikací frontend. Kdyby se chtělo tak jde narvat IPv6 všude, ale z lenosti nebo z ekonomického hlediska se to nedělá.
Kdyz jsem si v roce cca 2005 napsal do TODO listu pripojeni pres 6in4 (ale nakonec zustalo jen u studie) a pak se o nej pokousel znovu behem vanoc 2007, tak jsme zjistil, ze se moc nezmenilo, jen UBYLO poskytovatelu "free" tunelu.
Mimochodem, dival jsem se na Mikrotik a nezda se mi, ze by umel IPv6, mozna jen na "bridge" interface. Verze RouterOS 2.9. Mozna ze IPv6 neni jen zdokumentovane, nebo to taktne zamlcuji aby nematli nezkuseneho ctenare; vse se toci jen kolem IPv4.
9.3.2008 21:20
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Mimochodem, dival jsem se na Mikrotik a nezda se mi, ze by umel IPv6, mozna jen na "bridge" interface. Verze RouterOS 2.9. Mozna ze IPv6 neni jen zdokumentovane, nebo to taktne zamlcuji aby nematli nezkuseneho ctenare; vse se toci jen kolem IPv4.Od verze 3.0 má plnou podporu. A proto jsem také mluvil o ekonomickém hledisku.
9.3.2008 22:52
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Verze 2.9 je dlouhodobe proverena, stabilni. Verze 3.0 je novinka. Nejvetsi potiz je ale s licenci, nejde snadno upgradovat z 2.9 na 3.0, viz licencni politika Mikrotiku;Přesně to jsem měl na mysli tím ekonomickým hlediskem. Ono se trochu licenční politika změnila, ale kdyby chtěli rýžovat…
snad je verze 3.0 i narocnejsi na hw, ze?To bude způsobeno přechodem z verze jádra 2.4 na 2.6 a možná také tím, že doposud tam nebyl CFS(I když tomu jak jádro pracuje s procesorem moc nerozumím, takže to spíše berte jak blábol). Většinu problémů s 100% vytížením CPU, ale způsobuje zacyklování některých procesů(Už si na ně chystám debugovací armádu).
7.3.2008 10:15
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
Porno zdarma za IPv6 připojení Vzhledem k tomu, že porno vládne Internetu, mohlo by to mít úspěch
7.3.2008 11:04
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
proc to? cekali jsme kdy to ipv6porn.com poradne roztoci a furt nic...Pěkný
Ale zase si nejsem jistý tou rychlostí u onion-routingu 
). Dokonce je mozne, ze se bude prodavat nejaky udelator, ktery bude delat preklad protokolu a adres z IPv6 do IPv4 a zpet (NAPT-PT) a bojovnici proti NATu a vyznavaci "opravdovemu pripojeni k Internetu" budou zurit ...
z IPv6 do IPv4 a zpet (NAPT-PT)Tyhle tunelovací technologie přece už dávno jsou.
Vetsi sranda bude se spoustou zarizeni typu ADSL modemy, routery, HW firewally, WiFi AP podobne. V idealnim svete by vsechny tyhle potvurky IPv6 uz meli.Modemy IPv6 nepotřebují, lepší routery ho mají... co s těmi ostatními... no bude to zajímavé :). To bude nových instalací OpenWRT a podobných :D. Poslední možnost je docela děsivá ale reálná :(.
7.3.2008 19:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
V idealnim svete by vsechny tyhle potvurky IPv6 uz meli. V temer idealnim svete by vyrobci poskytli upgrade firmwaru, i za cenu napr. omezeni nekterych neprilis potrebnych featur (typu obrazek na pozadi ve webovem rozhrani).Abych pravdu řekl, nepřekvapilo by mě, kdyby na takové řešení začala tlačit unie. Když už nic jiného, představuje to zbytečnou ekologickou zátěž, protože hodně IPv4-only výrobků poletí oknem.
Je pravda, že když koncový uživatel dostane /128 "rozsah", tak má docela smůlu. Když dostane aspoň /64, tak se s tím dá nějak naložit. Počítat, že každý dostane /48 by asi bylo naivní.Tohle zrovna řešitelné je. Provideři se při přidělování adres zákazníků musí řídit regulemi toho, kdo jim přidělil jejich blok. V našich končinách tedy obvykle RIPE a ten by mohl mít dost odhodlání na to, aby providery od takových nápadů odradil.
Ale cosi budeme povídat v naší zemi je taky spousta "providerů" jejichž síťová infrastruktura čítá 5 wifi spojů mizerné kvality a jejich jediný spoj do internetu je ADSL od kyslíků...&&
Provideři se při přidělování adres zákazníků musí řídit regulemi toho, kdo jim přidělil jejich blok.=> pokud kyslíci žádné regule nemají, tak ti "provideři" nemají ani co dodržovat.
Nejhorší na nedostatku IPv4 adres je to, že poskytovatel nemůže dát slušný rozsah ani když chce.Co je slušný rozsah?
Pro mne je to takový, abych mohl ve své domácí nebo firemní síti jednotlivým segmentům přidělovat rozsahy dostatečné velikosti a abych se obešel bez veškerých maškarád.
Nemám to podloženo žádným seriózním průzkumem, ale jsem docela pevně přesvědčen, že kdyby všichni, kdo si myslí, že mají připojení k Internetu, ho opravdu měli mít, zjistili bychom, že IPv4 adresy už dávno došly…
8.3.2008 20:14
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
S NATem plati toto - mam pripojeni pro jeden pocitac -> automaticky (bez jakekoliv lidske komunikace s poskytovatelem) mam pripojeni (sice neplnohodnotne) pro prakticky libovolne mnozstvi pocitacu. To s IPv6 bez NATu obecne nemusi platit.IPv6 adres je opravdu hodně, takže pro poskytovatele připojení pravděpodobně nebude problém přidělovat zákazníkům rovnou rozsahy. Spíš bych se obával jiné věci a sice toho, že poskytovatelé budou NATem chránit jisté zavaděče pro PC hry a budou si nechat platit za to, že NAT vypnou. Ostatně vzhledem k existenci link-local adres je ještě pravděpodobnější, že ti "lepší" poskytovatelé nebudou jiné než link-local adresy přidělovat vůbec, aby si ušetřili práci a mohli si nechat zaplatit za extra služby.
Ale toho bych se snad ani tolik nebál... naprostá většina poskytovatelů dává veřejnou IPv4, proč by nedali IPv6.Ne zadarmo. To je to, o čem mluvím - že se někdo bude s IPv6 pokoušet napakovat inkasováním za něco, co sám dostal téměř zdarma
Funguje tady nějaká konkurece, teda aspoň občas :).To jo, můžu si vybrat mezi kabelovou televizí, která má výpadky v četnosti jednou za čtrnáct dní až jednou za den, wifi, která má konektivitu od té kabelové televize a ADSL od Kyslíků...
Takže sám se spíš přikláním k tomu, že IPv6 téhle situaci více či méně pomůže k lepšímu.Doufám. Už aby to bylo.
diky za kazde info
8.3.2008 03:13
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Nevím, jak přesně rozeznávají freemaily.Kontrolují to ručně, takže snadno. Je důležité mít v cajku DNS, mít sekundární MX server a tím sekundárním MX nesmí být Rollernet.us. Je jedno, že Rollernet je i placená služba, prostě ne a basta.
Ale zase mám dostatek IPv4 adres.
většina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými paketyZdá se ti, že je tady málo nesmyslných blábolů, že přihazuješ další? To co říkáš, je jako kdybys řekl, že wget/seamonkey/cokoliv jiného se snaží bezostyšně zablokovat linku svými pakety.
9.3.2008 17:11
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Zdá se ti, že je tady málo nesmyslných blábolů, že přihazuješ další?Nesmyslný blábol to není určitě.
To co říkáš, je jako kdybys řekl, že wget/seamonkey/cokoliv jiného se snaží bezostyšně zablokovat linku svými pakety.Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.
Nesmyslný blábol to není určitě.Děkuji ti náčelníku, že jsi se mě zastal. Njn, někteří lidé holt reagují bez rozmyslu, budiž mu odpuštěno.
Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.Jak je to s BT, ten používá nějakou nesmyslně malou velikost? A tím pádem megabajt přes bittorrent je oproti megabajtu přes http obrovská zátěž?
9.3.2008 18:11
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Jak je to s BT, ten používá nějakou nesmyslně malou velikost?Nesmyslně malou určitě ne, ale&hellip
DHT se používá na vyměňování Hashů mezi všemi peery(možná kecám, moc jsem to nestudoval). No když je dostatek peerů, už to dovede vyprodukovat docela slušnou rate. A omezování a UDP, o tom asi netřeba mluvit. Velikost paketů tak mezi 80-500B.
No a pak TCP část. Pokud stahujete řekněme album a to obsahuje 20 skladeb o velikosti řekněme 2-3MB, tak ta je ještě rozkouskována na menší části (na Wikipedii je psáno, že většinou 250kB, ale já se setkal jenom s ještě menšími), které se stahují zároveň od všech peerů(nevím jestli se vždy jedna část musí stahovat právě od jednoho klienta nebo jestli se může stahovat jedna část i od více klientů) a na každou část se vytvoří samostatné TCP spojení. A než se vůbec TCP dostane z pomalého startu, tak je po spojení. No a pak jsou tu ještě komunikační pakety, které jsou malé(já jsem naměřil celkovou velikost tak kolem 50-150B, takže i hlavičky od linkové po transportní vrstvy jsou větší), že se pro blbých 50B dat musí odeslat tak 6paketů než se vůbec naváže a zase ukončí spojení. Nedejbože pokud je některý paket zahozen. To se potom musí 5x znova odesílat než vůbec projde.
Kdybych měl po ruce kus papíru, určitě bych to nastínil lépe. Celé je to spíše shoda různých náhod.
A tím pádem megabajt přes bittorrent je oproti megabajtu přes http obrovská zátěž?Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň. Zvláště pokud je na cestě k tomu všemu ještě pomalí HW. On vůbec celé určování propustnosti zařízení MB/s mi přijde trochu přitažené za vlasy.
9.3.2008 18:17
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
DHT se používá na vyměňování Hashů mezi všemi peery(možná kecám, moc jsem to nestudoval).DHT slouží pro hledání nových peerů a k získání metainformací (přes DHT je možné stáhnout i samotný torrent). Hashe jsou v .torrent souboru.
a na každou část se vytvoří samostatné TCP spojení.Vážně? A proč by se to dělalo?
A než se vůbec TCP dostane z pomalého startu, tak je po spojení.Co?
že se pro blbých 50B dat musí odeslat tak 6paketů než se vůbec naváže a zase ukončí spojeníTo je jen na začátku spojení. Omezte počet spojení a je to.
Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň.To můžu udělat klidně a problém to nebude. Hádám, že se o něco sníží efektivita, ale to je spíš můj problém.
9.3.2008 19:03
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Vážně? A proč by se to dělalo?Protože každou část stahuje z jiné IP.
TCP - od Techniky okna až dolů.A než se vůbec TCP dostane z pomalého startu, tak je po spojení.Co?
To je jen na začátku spojení. Omezte počet spojení a je to.A na konci. A technika zpoždění odpovědi byla asi také tvůrcům neznámá jelikož půlka z toho jednoho spojení jsou jen potvrzení(Na druhou stranu, ale nevím co je to za data).
BTW. jakékoliv omezování jinde než na AP klientů to potom ještě zhoršuje, protože se ty pakety musí odesílat znovu.
To můžu udělat klidně a problém to nebude. Hádám, že se o něco sníží efektivita, ale to je spíš můj problém.A problém tvého ISP, zvláště pokud má pomalí HW a neefektivní návrh sítě.
9.3.2008 19:09
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
A technika zpoždění odpovědi byla asi také tvůrcům neznámá jelikož půlka z toho jednoho spojení jsou jen potvrzeníNení posílání ACKů spíš úkolem jádra než nějakého programu?
A problém tvého ISP, zvláště pokud má pomalý HW a neefektivní návrh sítě.Tak to je v podstatě jeho problém a pokud by se problém opravdu objevil, jdu jinam.
Tak to je v podstatě jeho problém a pokud by se problém opravdu objevil, jdu jinam.Tak kvůli bittorrentu bych asi providera neměnil.
... tak ta je ještě rozkouskována na menší části (na Wikipedii je psáno, že většinou 250kB, ale já se setkal jenom s ještě menšími), které se stahují zároveň od všech peerů(nevím jestli se vždy jedna část musí stahovat právě od jednoho klienta nebo jestli se může stahovat jedna část i od více klientů) a na každou část se vytvoří samostatné TCP spojení.To není žádná pravda. Zaprvý ty kousky jsou většinou o dost větší než 250kB. Nevim odkud jste stahoval torrenty, já sem se sekal s nejmenšími o velikosti 1MB, obvykle pak 4 a více MB. Zadruhý stahuje se dycky od jednoho peeru jeden kousek a pak se sčekuje hash toho kousku. Najednou se sice stahuje víc kousků, ale každej je jinej a (imho) od jinýho peeru.
Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň. Zvláště pokud je na cestě k tomu všemu ještě pomalí HW. On vůbec celé určování propustnosti zařízení MB/s mi přijde trochu přitažené za vlasy.BT není na tahání 1MB souborů, ale stokrát až tisíckrát větších. A říct že 1MB soubor se rozkouskuje na 20 čaástí je holej nesmysl, žádný rozumný tvořič torrentů by to neudělal...
A než se vůbec TCP dostane z pomalého startu, tak je po spojení.Coz by byla z hlediska zahlceni linky vyhoda - v takovem pripade by to stahovalo pomaleji, nez je mozne.
Děkuji ti náčelníku, že jsi se mě zastal. Njn, někteří lidé holt reagují bez rozmyslu, budiž mu odpuštěno.Kecy sem, kecy tam, ale informační hodnota je nula.
Nechtěl jsem tě urazit.vs.
Sám seš blábol.Schíza je mrška, pozor na ní...
a případně dávat své pochybnosti najevo trochu diplomaticky.To většinou dělám. Jenže když se neustále opakují ty samé nesmysly (jak o torrentu, tak o IPv6), tak už se s diplomacií nezatěžuju.
Zvlášť, když už ses tady jednou netrefil.Připouštím, že je to možné... nicméně pokud slovem tady nemáš na mysli celé abclinuxu, ale tuhle konkrétní diskuzi, tak bych rád věděl, kde to
Torrent se u spousty lidí projevuje dost nepříjemným způsobem, přečti si třeba příspěvek od the.maxe. To je fakt, na tom nic nezměníš.To je fakt, který nehodlám popírat. Tvrdím ale to, že to není chyba torrentu, ale sítě, která nezvládá to, co by měla (například sdružování paketů do jednoho rámce, což by té síti značně odlehčilo) Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.
To je fakt, který nehodlám popírat.A o tom přesně byl můj příspěvek, který jsi označil za blábol.
Tvrdím ale to, že to není chyba torrentu, ale sítě, která nezvládá to, co by měla (například sdružování paketů do jednoho rámce, což by té síti značně odlehčilo)Fajn, začínáme mluvit k věci :) (ať už je to tak jak píšeš nebo ne). +1 Zajímalo mě, nakolik je na vině samotná specifikace, na kolik jsou to konkrétní implementace... a nakolik jiné důvody.
Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.LOL
A o tom přesně byl můj příspěvek, který jsi označil za blábol.Aha, v takovém případě jsi tom v tom příspěvku měl napsat. Větu
většina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými paketysi málokdo vyloží jako "Torrent se u spousty lidí projevuje dost nepříjemným způsobem"; to první jsi napsal na začátku, to druhé až teď.
Zajímalo mě, nakolik je na vině samotná specifikace, na kolik jsou to konkrétní implementacePokud mluvíš o wifi, tak specifikace to umožňuje, jenže je to náročnější na výpočetní výkon (pakety se musí porovnávat, jestli míří na stejný bod v síti), paměť (pokud chci čekat, musím neodeslaná data někde schovat), samozřejmě i na programování... zjednodušeně řečeno se to prodraží, tj. levné šmejdy to neumí a nedělají.
Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.Nejde o to, aby to šlo. Jde o to, aby měl ISP chuť to vůbec dělat... když to může vypnout nebo omezit počet spojení na IP adresu (což má pro většinu uživatelů torrentu podobný efekt).
9.3.2008 21:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Kecy sem, kecy tam, ale informační hodnota je nula.Vždyť fórum je od toho aby se na něm kecalo, nebo se zase mýlím?
9.3.2008 21:18
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.Slyšel jsi někdy o segmentovém stahování, tedy že si soubor rozdělím na několik souborů a každý kousek stáhnu zvlášť? Když najdu víc zrcadel, mám HTTP torrent. Vzhledem k tomu, že servery jsou zpravidla rychlejší, než ti dá linka od poskytovatele, se tohle nedělá. Kdyby jo, budou wifi rádobyISP brečet nad segmentovým HTTP stejně jako teď brečí nad torrentem.
Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.Jak se HTTP může snažit používat maximální velikost paketu, to teda nechápu. Webserver, který posílá data, je ze svého pohledu cpe do socketu; z principu může ovlivnit, velikost okna tak, že tu a tam pošle malý kousek dat a jinak nic, to se ale bude snažit použít minimální velikost paketu. Obráceně (tedy server pere do spojení, co se do něj vejde) to závisí na jádře, jak velké pakety udělá. Mýlím se? Nechám se klidně poučit.
9.3.2008 19:34
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Jeste stesi,ze s 2.4kou jsme zkonciliNa něčem jiném je situace lepší?
9.3.2008 19:42
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
9.3.2008 19:43
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Že by na licencovaných frekvencích?5Ghz je mám pocit bezlicenční pásmo(pokud se tedy bavíme o 802.11a) a nebo se mýlím?
Na něčem jiném je situace lepší?
9.3.2008 19:51
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
A aby ten program byl stejne rychly jako ten, ktery posila packety o velikosti okolo 1400b, musi jich poslat temer 30x tolik.No a to je právě blábol - bittorrent ani jeho klienti neposílají data v žádných 100B paketech. Klienti posílají data do socketu a jak bude packet velký, to si určí jádro jako takové. Ty malé pakety jsou z největší části dodatečné - režijní - informace.
Ostatní se většinou snaží psát trochu na úrovni.Někteří by se radši měli snažit pořádně si přečíst to, na co reagují.
No... buď v tom, že se neposílají 100B pakety...Já jsem nepsal, že se neposílají. Já jsem psal, že klienti neposílají 100B pakety. To totiž nemůžou. Uznávám, že jsem softwaru, kterej komunikuje po síti, nenapsal moc, ale pamatuju si na nějaký věci jako socket, send() a podobné... na druhou stranu si nepamatuju nic jako send_packet; dokonce silně pochybuju, že by něco takového mohl udělat někdo jiný, než root. Klienti neposílají pakety. Klienti posílají data a pakety z nich vyrábí jádro.
...nebo v tom, že v těch 100B paketech jsou režijní informace.Jasně - torrent funguje bez režie, všichni klienti jsou slinkovaní s libvěštec a potřebné informace jako kdo má jaká data k dispozici si domyslí...
Problem nastava tehdy, pokud si clovek zvoli "prasackeho" klienta, ktery neni schopen normalne komunikovat (tim myslim posilat packety o rozumne velikosti) a misto toho posila packety o velikosti 100b.Protože to je prostě nesmysl. Ano, systém posílá paket, protože to po něm aplikace chce. To důležité ale je, že klient nemůže posílat pakety o "rozumné velikosti", když prostě ta data nemá (když chce třeba druhé straně říct jenom něco jako "Ahoj, pošleš mi chunk 259?)" Na to nepotřebuje plných 1500B a proto pošle malý paket. Tvrzení, že torrent je špatný, protože posílá malé pakety na přenášení dat, je principiálně nesmyslné, takže máš pravdu, řeším kraviny, ale napsal je někdo jiný.
Jasně, TCP se k aplikaci chová jako datový proud, UDP zase ne.Z hlediska programátora se víceméně oba chovají jako datový proud, akorát u UDP nemáš jistotu, že ti přišlo všechno a pokud chceš nějaké potvrzování, musíš si ho naprogramovat sám. Při programování můžeš používat ty samé funkce (send/recv) A v kontextu toho, o čem se bavíme, je to úplně fuk.
9.3.2008 23:06
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
jsem si 100%ne jisty, ze ten klient neodeslal packet dlesi nez 122b!!!A sdílel jsi? Respektive stáhl si od tebe někdo kus toho CD?
stahoval jsem cca 600mb CD, ale abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb...Velikost odesílaných paketů tvůj stahující inkriminovaný klient neovlivní...
10.3.2008 00:11
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Dal jsem si tu praci,z e jsem si nainstaloval zavadec na hry, inkriminovaneho klienta jsem nainstaloval a zacal jsem stahovat. jsem si 100%ne jisty, ze ten klient neodeslal packet dlesi nez 122b!!!Aby se přes BT posílala data o tak malých blocích, to nemůže žádný normální klient dělat. To musela být nějaká závažná porucha.
ale abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mbTakže 233% overhead? Ale kdeže... maximálně nějaké procento.
abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb...Tak to je hooodně přitažené zavlasy. Je sice možné, že v jedné konkrétní situaci s nějakým hoodně bugozním klientem se to stalo, ale rozhodně to nejde zobecňovat. Nadruhou stranu je pravda, že dost klientů se chová přinejmenším podivně.
Uznávám, že jsem softwaru, kterej komunikuje po síti, nenapsal moc, ale pamatuju si na nějaký věci jako socket, send() a podobné... na druhou stranu si nepamatuju nic jako send_packet;Pokud klient komunikuje pres UDP, pak je rozcleneni dat do jednotivych paketu na nem. Viz sendmsg().
Nicmene tohle je uz dost offtopic...
10.3.2008 00:10
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
10.3.2008 20:35
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
videl jsi nekdy jak 40 lidi s bittorrent klientem dokaze srazit do kolen router s 2GHz opteronem a serverovou deskou, serverovyma sitovkama (zadnej raltek) ,2Gb pameti...? Asi ne.. ja v prvnich chvilich myslel, ze mi na siti strasi.Nechci být rýpavý, ale to je možná přesně ten problém ISP. Po vesnicích rozdají RB1XX-ky(vždyť je tam pár klientů - to musí přece stačit) a všechno to slejí do jednoho centrálního routeru kde nasadí nějaké Core2Dup s queues, ovšem to mi přijde jako chyba. Omezovat(alespoň odesílací směr) by se měl už na APčkách klientů, protože takt o torrenty zaserou celou cestu až k centrálnímu shaperu. A také nevím proč všichni omezujete počty spojení, které tak max. žerou paměť na routerech se zapnutým conntrackem.(I do jednoho spojení můžu narvat 1000p/s)
A také nevím proč všichni omezujete počty spojení,Nejspíš proto, že mají vyzkoušeno, že pak ten problém nenastane.
11.3.2008 21:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Omezovat(alespoň odesílací směr) by se měl už na APčkách klientů, protože takt o torrenty zaserou celou cestu až k centrálnímu shaperu.Teď se nezasvěceně ptám ostatních, zda je to opravdu možné? Tohle by se dalo samozřejmě čekat u UDP, ale u TCP? Shaper ty pakety zahodí nebo zbrzdí a klient zpomalí okamžitě sám.
Napr. maji zjisteno, ze na ADSL vetsinou probiha shaping tak, ze kdo ma vice TCP spojeni, urve relativne vice pasma. A tak pouzivaji tolik TCP spojeni, kolik ma masina portu.Jestli to spíš nebude z toho důvodu, že každé to spojení vede k někomu jinému... u P2P bych to docela očekával.
9.3.2008 17:06
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
sice nevím, jak to souvisí s 2.4kou... ale zkušenosti mých známýchSpíše je to neznalostí těch co ty spoje dělají. Většinou omezují až na centrálním routeru kdy je ke klientovi cesta přes 3 další routery spojené také Wi-Finou a jelikož BitTorrent(resp. rozšíření pro BT DHT bez kterého BT nefunguje) používá UDP a to stylem "perem do linky co se vleze", tak se zaplní buffery na routerech po cestě a celá linka jde do kopru. Nemluvě o tom, že když už i omezují u klientů odesílací směr, tak tam většinou dají pouze omezení na zakoupenou klientovu rychlost a pak to pozabíjí počty paketů.
t(resp. rozšíření pro BT DHT bez kterého BT nefunguje)Ale notak. Takhle lhát, že se nestydíš...
9.3.2008 17:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Dobře, upřesním:Funguje ale nestahuje, protože ostatní peerové odmítají bez zaplého DHT komunikovat. A na co někomu bude BitTorrent klient, který nestahuje?t(resp. rozšíření pro BT DHT bez kterého BT nefunguje)Ale notak. Takhle lhát, že se nestydíš...
9.3.2008 17:24
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Minimálně já lidi bez DHT neodmítám... Takže asi tak.
, tak jo. Řeknu všem ať tahají od Stopky. Bohužel jsi výjimka.
9.3.2008 17:22
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
9.3.2008 17:29
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
1) Takového klienta jsem ještě nevidělSkus si zapnout nějakého BT klienta a vypnout DHT. Mě v Azureusovi vždy naskákalo ve Swampu asi 15 IP adres a hned zmizli. A takto pořád dokola. Netvrdím, že odmítají všichni, ale při mém testu většina.
2) Těch UDP paketů je minimumTo bych tedy netvrdil(zvláště když se stahuje více souborů najednou). A s TCP částí to také není nijak slavné(vysvětleno trošku výše).
9.3.2008 17:41
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Skus si zapnout nějakého BT klienta a vypnout DHT. Mě v Azureusovi vždy naskákalo ve Swampu asi 15 IP adres a hned zmizli. A takto pořád dokola. Netvrdím, že odmítají všichni, ale při mém testu většina.Tak se neomezujte na vaše mizerné odhady a podívejte se do dokumentace. DHT slouží k vyhledání dodatečných peerů oproti tomu, co je k dispozici z trackeru. Jediné, co se dělo u vás, bylo to, že dané peery nebyly dostupné. A proč by proboha nějaký BT klient odmítal nové spojení když druhá strana nenabízí DHT? Jaký důvod by pro to měl?!
To bych tedy netvrdil(zvláště když se stahuje více souborů najednou). A s TCP částí to také není nijak slavné(vysvětleno trošku výše).To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.
9.3.2008 18:43
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
DHT slouží k vyhledání dodatečných peerů oproti tomu, co je k dispozici z trackeru. Jediné, co se dělo u vás, bylo to, že dané peery nebyly dostupné.Asi to tak opravdu bude, protože jsem zkusil jiný Torrent a "stahovalo to". Sice tak rychle, že blikání síťovky bych mohl i počítat(někdy i půl minuty tma), ale to mohlo být i tím, že už nebylo potřeba odesílat UDP pakety a nebo že je nějaký špatný torrent. Než něco vyvodím tak se radši půjdu zeptat nějakého tahače, jelikož jsem BT zapl po páté v životě. A nebo začnu u lidí DHT filtrovat a uvidím co na to budou říkat.
To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.Viz příloha.
9.3.2008 18:47
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Viz příloha.A to byl jeden torrent. Opravdu někdy doporučuji přesměrovat na svůj počítač stream od tahče který má obrazovku plnou torrentů od shora dolů a pak si do toho pustit Wireshark. Můj to neustál.
9.3.2008 19:05
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Viz příloha.A to je jako hodně?
9.3.2008 19:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
A to je jako hodně?Vzhledem k TCP?
9.3.2008 20:13
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
9.3.2008 21:31
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Jo. Tohle je jen nějakých 10p/s.
, a to jsi vypočetl z toho obrázku jak?
Na TCP to při zátěži lítá mnohem víc.Opak netvrdím, ale: a)Dá se to mnohem lépe řídit. b)Vždyť se také u BT neodvolávám jen na malé UDP, ale jako na jeden z faktorů.(Nicméně díky tobě již eliminovaných faktorů, za což jsem samozřejmě náležitě vděčný.
9.3.2008 21:35
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
a to jsi vypočetl z toho obrázku jak?Já ti ani nevím, na matiku jsem nikdy moc nebyl, ale když ten capture běží 75 sekund a za tu dobu projde 825 UDP paketů, tak 825/75 = 11.
Opak netvrdím, ale: a)Dá se to mnohem lépe řídit. b)Vždyť se také u BT neodvolávám jen na malé UDP, ale jako na jeden z faktorů.(Nicméně díky tobě již eliminovaných faktorů, za což jsem samozřejmě náležitě vděčný.Řekl bych, že ten protokol funguje docela dobře. Vždycky je co vylepšovat, ale není to zle udělané.
9.3.2008 22:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Já ti ani nevím, na matiku jsem nikdy moc nebyl, ale když ten capture běží 75 sekund a za tu dobu projde 825 UDP paketů, tak 825/75 = 11.To by platilo ,kdybych se sniffováním jsem začal v ten moment kdy jsem zapl Azureus. A navíc já nejsem určitě reprezentativní vzorek, skusím sehnat dump z nějakého hraničního routeru sítě s běžnými BT uživateli ať můžeme rozvinou tlachání i o nějaká fakta.
Protokol - příchozích paketů - příchozích bytů - odchozích paketů - odchozích bytů TCP/IP 2189 2877526 1745 191219 UDP/IP 19 4854 17 2124Pro doplnění - hodnoty příchozích paketů za sekundu a odchozích za sekundu byly přibližně 50. Jestli teda v torrentu UDP převažuje, tak se asi musí nějak maskovat, jinak to nechápu. Podle velikosti paketu:
1-75B: 9687 76-150B: 1017 151-225B: 203 226-300B: 184 301-375B: 230 1426-1500+: 10026Ostatní velikosti neuvádím, bylo to pod sto. Četnost malých a maximálně velkých paketů je přibližně stejná (že by potvrzovací pakety, keepalive* a režijní informace?) Otevřených TCP spojení je 36. Podle mě tohle všechno v žádném případě není nezvládnutelný provoz. * Keepalive pakety jsou další důkaz o tom, že NAT způsobuje problémy. Kdyby všechny stroje byly přístupné z netu, nebylo by nic takového nutné - spojení mělo timeout? Nevadí, obě strany mají možnost ho založit znovu, pokud budou chtít.
To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.Zajímavé, že mi ty UDP pakety vytvořily asi třikrát tolik záznamů v conntracku než TCP.
9.3.2008 17:42
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Alespoň vetšinou.
9.3.2008 17:22
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Potom mi vysvětli, proč na 5GHz obvykle stejný problém neřeší.Řeší ale méně, jelikož 5GHz má větší paketovou propustnost a stíhá odesílat a tím se mu tak moc nezaplňují buffery. A navíc pokud má last-mile řešenou skrze 802.11b, tak to ty béčka pochytají(A tak to nejede jen na daném segmentu). Na médiu nezáleží. U 802.11b je to spíš souhra náhod(malá max. packetrate, mnoho lidí na jednu anténu, špatně nasměrované antény, zarušení to všechno zkombinované z neznalostí a leností a o zábavu je postaráno)
Řeší ale méně, jelikož 5GHz má větší paketovou propustnostPresneji receno 802.11a (5 GHz) ma lepsi propustnost nez 802.11b (tradicni 2.4GHz). Propustnost 802.11a a 802.11g (novejsi 2.4 GHz) je za idealnich podminek vicemene stejna. Akorat na 2.4 GHz je toho ruseni mnohem vic. Ale na vesnicich v kopcovitem terenu funguje 802.11g celkem dobre.
tšina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými pakety, nejdejbože, když je to na 2.4GHz wifiIMHO nejpravdepodobnejsi pricina podobnych zvesti o blokovani linky torrentem je kvuli tomu, ze linuxovy firmware mnoha wifi krabicek ma casto napevno zakompilovanou podporu conntrack a casto nastavenou na dost malou hodnotu (treba i 512). Pokud takovou krabicku nekdo pouzije jako wifi AP, tak pri nekolika torrentech snadno hrozi preplneni conntrack tabulky a linuxovy router se pri preplnene conntrack tabulce chova dost divne.
linuxovy router se pri preplnene conntrack tabulce chova dost divne.To mi povídej.
Tohle vidím z pohledu protipirátských unií jako velké plus pro jejich činnost. Bohužel musím viděl i mínus. IPv6 specifikuje jako povinnou součást IPsec, sice v reálu to některé implementace nemají, ale je otázka času. A také se nám začíná i šířit i DNS SIG, dokonce i CZNIC začíná něco v tom duchu experimentovat. Pokud by došlo na to, že se mohutněji rozšíří IPsec komunikace na prakticky jakékoliv spojení na základě klíčů z DNS, tak jejich sledování bude horší, taktéž ISPéčkům se bude huře filtrovat provoz. Samozřejmě můžou IPsec potlačovat, ale používá se hodně i pro zcela legiimní věci a narazí. Pokud by na něj došlo masivněji, tak se nám opět trochu narovná pošramocená síťová neutralita upřednostňování na základě protokolů, což je hlavně plus pro uživatle a ke zlosti unií.
Pohled ISP na IPv6 má také svá specifika. Přeci jen NATovat pár tisíc klientů něco stojí, zdržuje to, jsou s tím komplikace, každou chvíli někdo otravuje, že chce přesměrovat port nebo něco nastavit, aby nějaký obskurní protokol fungoval (VPN klienti dokáží pěkně vydusit, pokud ISP má segmenty kolidující s koncovými body VPNka). Provozování NATu u ISP nese i právní úskalí. Dle naší legislativy ISP nenese odpovědnost za obsah přenášených dat, ale jen do okamžiku, dokud obsah komunikace nepozmění. A v případě NATu do toho občas šahá až na aplikační úroveň, aby některé věci fungovaly. Nerad bych narazil na magora, který by chtěl zkusit na základě toho mi hodit na hlavu spoluodpovědnsot za piráta. Další problém je, pokud jsem ISP se statusem veřejné služby, musím o klientech držet data, abych na žádost soudu k informaci o čase, IP adrese a cíle spojení určil o koho jde, pokud mají klienti veřejné IPčka, tak je to pohoda, jen si držím seznam kdo je kdo, jakou má IP a pro úlitbu vyhlášky ještě schovávám sumárně kolik dat apaketů nasosali za den (co den, to jedne řádek v DB na kleinta). V případ NATu musím schovávat informace o všech spojeních, která přes NAT prošla, abych pak poldy uspokojil a neriskoval, že mi pošlou na krk ČTU s jejim pokutovým sazebníkem. A je to opět práce navíc a dost dat (a to jen skladujeme 6 měsíců, až nám EU v rámci boje proti teroristům vnutí 3 roky, bude hůře).
Samozřejmě jsou i negativa, ne všechno v infrastruktuře umí dobře IPv6, ani takový mikrotik není bez šmouhy, zatím komplikovanější shaping provozu, pokud se rozmůže IPsec, bude zase o trošku horší "spravedlivé" omezování klientů atd.
Ale i tak se toho do budoucna nebojím.
Pohled uživatele má také své specifika, hlavně v ČR, kde smysluplného obsahu (a celkově i v EU) pro běžného spotřebitele moc není, takže je to zatím spíše pro early adopters, na kterých se to musí odladit. Nicmén pár přínosů by se našlo a doufám, že seriálek je nezapomene pořešit.
..., takže kdyby měl každý svůj veřejný blok, tak se stačí pomalu jen mrknout do RIPE.Většina podle mě bude používat blok od ISP stejně jako dnes.
napr. ICQ musi mit nejaky server, ktery jenom kopiruje soubor pokud si ho uzivatele chteji poslat (pac se nevidi)
Jenže důvod, proč ICQ (a nejen ICQ) vypadá tak, jak vypadá, je z velké části právě v těch maškarádách. Kdyby nebyly maškarády, mohlo by to fungovat podobně jako třeba SIP, tj. server jen pro navázání kontaktu a vlastní komunikace přímo.
Tak mě napadají dvě otázky.
1. Co když i tento rozsah bude brzy malý? Mobil, PC, tiskárna a bůhvíco ještě si každý v budoucnu připojí k internetu. ;)
2. Celkem mě z bezpečnostního hlediska zaujala věc, že paket má podle článku „Také samozřejmě odpadá délka hlavičky a místo pole Protocol se používá Next Header, které navíc umožňuje vkládat rozšiřující hlavičky (náhrada za options).“ Next Header. Nebude se dát náhoudou tato hlavička snadněji podvrhnout?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
