Jsem pripojen pres poskytovatele internetu centrio a pravidelne mu pisu jak to u nej vypada s nasazenim ipv6. Bohuzel musim konstatovat ze tento operator ma k tomuto problemu velice laksni pristup. Odbyva me argumenty ze zakaznici ipv6 nechcou (ani nevedi co to je), ze tam jsou bezpecnosti problemy, ze stejne veskery obsah je pristupny pres ipv4 (ano posilal jsem mu odkaz na nebezi.cz, a na tu zelvicku ktera na ipv 4 netancuje, ale odbyl mne s tim ze to jsou jen takove sranda stranky). No a navic je pry prechod na ipv6 drahy:(. bydlim na hajich a zadna alternativa (symetricka opticka linka) zde bohuzel neni. V tomhle je praha dost pozadu, na morave odkuz pochazim maji operatora valachnet, ktery poskytuje symetricke opticke linky s ipv6 uz peknych par let, ale pry mensi operatori maj prechod jednodussi...
Tak toho retarda odkaz treba na stranky ministerstev. Na IPv6 by mely byt vsechny, a zeptej se ho, jestli to sou jen takovy sranda stranky.
Ovsem vubec nejlip udelas, kdyz mu posles vypoved smlouvy, kde mu presne popises, ze na nej seres z duvodu jeho neschopnosti. Nasadit Ipv6 je otazka par minut - i pro providera. A konfigurovat to je radove jednodussi a predevsim levnejsi nez se vysravat s NATem.
Zakaznici vubec netusej, co je to IP a kcemu je to dobry ... chteji fungujici internet. Coz nemaji. Bez se podivat na nejaky torrent, 150 zoufalcu za NATem ceka, az se pripoji nekdo s verejnou adresou ... nebo aspon s fowardem.
>Nasadit Ipv6 je otazka par minut - i pro providera
- upravit DB aby umoznila k IPv4 jeste pracovat s IPv6
- upravit vnitrofiremni informacni a dohledove systemy, aby s IPv6 pocitaly
- accounting, shaping a dalsi pripravit na IPv6
- rozebehat IPv6 na pateri, povymenovat/upgradnout zarizeni, ktera to nezvladnou
- navrhnout a otestovat zpusob jakym se k zakaznikovi ta IPv6 dostane
- rozhodnout/otestovat, zda bude zakaznik mi IPv4 i IPv6 najednou nebo se to bude z jedne na druhou snad (fuj) prekladat
pochybuji, ze tohle nekdo zvladne za 5 minut :-)
> Zakaznici vubec netusej, co je to IP a kcemu je to dobry ... chteji fungujici internet
>
presne. Takze jsou naprosto spokojeni na verejne ipv4 :-) Za posledni roky se ,pokud vim, na IPv6 ptal u nas jeden clovek...
"sit, se stovkama zarizeni, kde se to confi rucne, i jen na 4ce"
Snad v jakekoliv fabrice na vyrobnich linkach. Kdyz tedy je nekdo natolik pokrokovy, ze by si automaty mohli mezi sebou povidat po ethernetu a ne po necem prumyslovejsim. Nikdo si nelajsne nejake komplikace pri vyrobe jenom proto, ze nekde nejaky DHCP server na druhem konci fabriky ma slabsi chvilku. Stejne tak pri vymene nejakeho HW pouze prenastavis ip adresu a jede se dal. Chran buh, aby v takovych situacich bylo nutne kontaktovat IT, aby milostive vzali na vedomi, ze nejake zarizeni ma novou MAC adresu.
A tech masin v ty fabrice po ty siti komunikuje nekolik set? Vazne? Takovou fabriku bych rek jeste nikdo nepostavil. Nemluve o tom, ze tyhle veci vetsinou stejne behaj po seriaku a maximalne je to pak pripojeny nekde vsechno k jednomu PC. Uz jen proto, ze na ethernetu se da tezko cokoli garantovat, coz tyhle stroje dost casto vyzadujou.
Mam tu asi tak 20 veci, ktery maji fixni IPcko. Nejaky ty zavory, pichacky ... veci ktery defakto ani sitovat neumej, jen se po siti daj nastavit a da se z nich neco precist. A navic sou to krabice prevazne 10+let stary a dokud neumrou, nikdo je vymenovat nebude.
Vsechno ostatni je dhcp/ra a vsude se dava DNS. Nehodlam totiz resit, ze nekdo nekde neco prepoji, presune, ... zmeni se tomu IPcko ... a vsechno v riti. Pokud mi nekdo za poslednich 10let prisel s tim, ze jeho appka potrebuje napevno IP, tak sem ho rovnou vyhodil.
A krasna vec cece, probihala postupna migrace na novy verze softu, zaroven se to samo presunovalo na novy verze OS, a voiala, jak to bylo easy, kdyz stacilo zmenit jedinej zaznam v DNS a namirit to na novej stroj. Jen proto, ze trvam striktne na tom, ze se do zadny konfigurace zadny IPcka davat nebudou, ani 4kovy ani 6tkovy.
Ha, ha, ještě vyspávám poslední akci, kdy se síťovaly mašinky real time řízené po ethernetu přes IP protokol. Jen ten kruh má 140 kusů ethernet switchů a kruhy jsou dva, každá mašínka připojneá současně do obou kruhů. Takže jen cca 300 IP adres pro síťvé prvky v jedné hale. Ano, je to hromad malých průmyslových switchů, které mají typicky 4 ks optických portů a 6 ks metalických, cca z poloviny vždy zaplněno. Kruh používá turboring technoligii od Moxy, takže výpadek v řádů max 2 milisekundy při přerušen spojení někde nebo selhání switche. Komunikuje se přes UDP, kde jsou použity v tom IP stacky, co mají podporu pro real time komunikaci přes Ethernet Samozřejmě se po tom nemotá nic jiného, než ta průmyslová řídící komunikace, protože by cokoliv jiného to rozbilo. Takže ano, takových hal je dneska v Česku už řada.
Dneska se už na průmylsový Ethernet cpe všechno možné, co ještě před pár lety bylo doménou sériových linek RB485 a podobných, dost často každé čidlo je samostatné minikrabička napájené přes PoE a komunikující samostatně s dalšíma krámama.
Ale jinak i ty malé Moxy switche už IPv6 umí. :-) jenom ta pdopra pro PTPv2 je softwarová a ne lně hardwarová v těch miniswitchích, takže mizerná přesnost. :-(
Znam sit na severu moravy s cca 10k uzivateli konfigurovanou (z dobrych duvodu) staticky.
Lidi maji tech svych 5 udaju na papirku a v pripade vymeny routeru se v panelaku/ulici najde vzdy alespon jeden typek ktery to za tri minuty do zarizeni natuka, navic dnes uz to nezanedbatelne mnozstvi lidi zvladne samo. Na brane jen povolujete IP adresy a ani nemusite drzet databazi MAC adres. V zacatcich spouta freenetu nemela zarizeni schopne DHCP snoopingu a tak jeden router po rozpojeni omylem zapojeny LANovou stranou do domovni site dokazal behem noci znefunkcnit pripojeni vetsine lidi v panelaku.
DHCP snooping, je dobra vec. Kdysi jsem napsal maly patch(cca 80 radek) od ISC DHCPd deamona. IP adresa se pak prideluje na zaklade informaci z Option82. IP adresa je asociovana s konktretnim portem na switchi a je jedno jake zarizeni se do nej pripoji (samozrejme to nesmi byt hub anebo jiny switch).
VLAN neni zase tak moc (alespon na starsich boxech). Nektere switche umi ulozit template access-listu do ktereho lze vlozit IP adresu z dhcp snooping. Dokud klient nedostane odpoved od DHCP tak nemuze nic, a az ji dostane, tak muze pouzivat pouze to IP, ktere dostal pres DHCP. Na svoje "sousedy" muze samozrejme porad utocit, ale IP adresu nikomu ukrast nemuze.
Inu, ne kazdy stavi site na zelene louce.
Mas treba sit na ros od verze 3.x po 6.x. Pak musis zapocitat take upgrade na neco homogenniho (vse alespon na 5.x, kde ta rozsahlejsi jednolita ospfv3 area jakz takz beha). U kazdeho 3tiho boxu pak laborovani s konfiguraci jenom aby po update +- fungoval puvodni ip4 config (to uz je holt dan za pozivani mtk).
Dalsi vec je provisioning na last mile, QOS, DHCP6, RADIUS, nektery lidi do mtk lejou ruzny conntrack bastly - na ktery muzes u sestky zapomenout. Skoda slov.
Zatim nejschudnejsi reseni na rozsahlych, letitych mtk sitich stylu "vrabci hnizdo" se zda byt hodit vsechny AP interfacy do bridge s eoip tunelem, na druhe strane tunelu, za ipv4 ospf meshem pak linux megabox koncentrator jen pro 6ku (a udelas si tam i provisioning). Neuveritelna prasarna, ale funguje to bez radikalnich zasahu do stavajici konfigurace site.
kat@lua.cz
https://github.com/katlogic/eoip
V případě nemožnosti změny providera doporučuji použít Hurrican Electric IPv6 tunel
https://tunnelbroker.net/
Taktez mam Centrio a *zcela uprimne* krome *free siti zatim v Praze asi nejlepsi provider, IPv6 resim pres https://tunnelbroker.net/ jede to tech mych 250/250 a mam klid.
Holt v Praze je ta fakt velka konkurence, takze se clovek musi spokojit s tim ze ma vubec nejakou verejnou IP, nedej boze zazrak symetrickou linku a pritom rychlost vyssi, nez klasickych 60Mbit/s. Protoze provideri se muzou jinak pretrhnout kdo nabidne srackoidnejsi sluzby za vic ;)
No jo, je to tragédie. UPC se před pár roky dušovalo jak IPv6 bude za chvíli, když se to aktivně řešilo a po pár letech kde nic, tu nic - běžný zákazník má smůlu. Stejně kabelovka Elsat - píši jim pravidelně jednou za rok asi už 4 roky a nic. Na poslední e-mail mi raději už ani neodepsali.
Ještě že jsou snadno dostupné routery s OpenWRT[1], kde jde jednoduše rozběhat tunel a tunel brokeři jsou i v ČR (díky hoši).
[1] tím mám na mysli třeba TP-Linky, ať už nové, nebo bazarové, které jdou sehnat za příznivou cenu, kam jde flashnout OpenWRT i po slepu
https://www.katalogrouteru.cz – ale aktuálně asi offline :(
Jinak co se týče xDSL, moc dobře to s modemy třetích stran nefunguje, to si ostatně CZ.NIC hořce vyzkoušel na projektu SMRT. Stabilitě ale obvykle pomůže přepnutí do bridge módu a terminace PPPoE spojení na jiném routeru.
Z high-end mohu doporučit:
- Turris (pokud ho už nemáte, tak se k němu nedostanete),
- do budoucna Turris Omnia (předpokládám, že bude ještě lepší než Turris, i když to chvíli potrvá než ho vyrobí a není vůbec levný)
- Ubnt RouterStation Pro (ten bohužel dnes již také nejde sehnat a dnes už není tolik high-end)
Dostupnější zařízení:
- TP-Link TL-WDR4300 (je škoda, že má jen 8 MB flash, ale malá stará USB flashka mi to jistí)
- slyšel jsem slávu na TL-WR1043ND
- chystám se testovat TL-WR741ND - bohužel se také již neprodává, ale jde sehnat bazarový za 200 - 300,- Kč (původní cena 400-500); je sice jen stovkový, má 32 MB RAM, 4 MB flash a pomalý procesor, ale tohle je ideální věc, kterou dávat domů BFU - nahodíte OpenWRT, aby to bylo bezpečné, případně si tam dáte nějaký vzdálený přístup pro správu a máte vystaráno a lidé nebudou protestovat, že nechtějí dávat tolik peněz za takovou malou krabičku, když nějaká Tenda stojí 300,- Kč
- obecně TP-Linky jsou fajn volba, pokud na tom nechcete provozovat centrum chytré domácnosti, NASy a jiné podobné náročné věci a zároveň nechcete dávat tolik peněz
Dobré místo s informacemi je pro toto HW databáze OpenWRT a ještě ji korelovat s googlem.
Pokud ty routery pronajímáte \prodáváte svým klientům jako malý ISP tak jako příklad možná .
Neřeší to samo modemy ADSL \ VDSL \ DocSIS a hlavně to, že koncový uživatelé si tam instalovat něcoWRT nebudou . A ani Vám za to platit v globálu nebudou.
Takže stejně majorita spotřebitelů skočí u out-off-the-box řešení teré je z odborného pohledu iPv6 nebo "etalonu" Turris nedostatečný.
K drancovani IPv4 - nejmenovany ISP si par let pred tim, nez IPv4 adresy dosly, nechal pridelit od RIPE ke svym stavajicim adresam jeste rovnou prefix /16, a aby vykazal vyuziti, tak je do whois zadal jako assigned jeho stavajicim zakaznikum, kteri o tom nemeli ani tuseni (pouzivali stavajici adresy). Doted traceroute na adresy z tohoto rozsahu konci na hranici onoho ISP.
Konkrétně, prosím. V čem je to takový hnus? Já mám IPv6 v několika sítích, moje servery ho umí a nemám s tím žádnou práci navíc ani žádné strašlivé starosti.
Není to spíš tak, že to admini neznají a nechtějí se nic nového učit? Navíc jim to po té čtyřce funguje, tak proč by se snažili. Je to netrápní, oni mají velký NAT. Ovšem adresy dochází na druhé straně.
Někdy je ten odpor proti IPv6 až absurdně směšný. Dneska ji maji zavedenou prakticky všichni rozumní poskytovatelé VPS a uživatel pro to nemusí udělat nic. Stejně jsou lidi, kteří to chtějí vypnout.
To že držet ipv4 only krabičky a software, nejen v koncovém segmentu, se spoustě subjektu vyplatí, to ovšem nevyvrací.
Až bude pro ně nasadit a provozovat ipv6 levnější tak to zajisté udělají. Podnikatelé jsou především motivováni snižováním nákladů. Proto třeba používají v některých případech Linux , protože je to vyjde levněji nikoliv že tím dokazují nějaký aktivizmus.
Hlavně nemůžete vyměnit všechny krabičky v koncernu, jedna kamera na rozpoznávání objektu stojí 3000Euro a IPv6 nemuí, šest linek po dvou kamerách a je to 12*3000Euro... životnost kamer je spočítána na 8 let. Možná tam IPv6 přibude, ale spíš jen do nové verze, protože výrobci zásadně do starých zařízení přidávají jen velmi neradi, páč z toho netečou šušně...
To je tak hrozný nesmysl :-D
V korporátní sféře je životnost krabičky počítána na 10+ let.
Bavíme se o docházkových systémech, požárním systému, zabezpečovačce a kamerovém systému no a hromadou nejrůznějších technologických hračiček a strojů, jako jsou třeba vodoměry pořízené v roce 2014, které samozřejmě IPv6 neumí.
Ano, je možnost používat zároveň IPv4 i IPv, ale taky je možnost dát pěstí každému, kdo bude IPv6 chválit, mě osobně přijdou zhruba srovnatelné.
Třetí možnost je použít socialistickou metodu, prachy sebrat občanům (proč by měli mít děti) a pořídit nová zařízení za dotace.
Tyhle jednoúčelové krabky většinou nepotřebují přístup na internet, takže můžou běžet na privátních IP adresách, kterých je dost. I kdžy asi taky dost velké množství může vyžadovat ze vzdálené lokality přístup k centrále via intenret. V tom případě ale zase, může být provider grade NAT.
Petre, co tak udelat Root.cz na par dni jako IPv6 only site ve stylu nebezi.cz? Ten tyden mezi Vanoceni a Silvestrem by to asi nemuselo ani znamenat propad vynosu z reklamy (nota bene porad muzete mit nejakou stranku, kde se zobrazi i reklamy a odkaz ve stylu "Mate-li IPv6, tudy muzete pokracovat na Root.cz. Nemate-li, kontaktujte sveho ISP"...
Ano, můžu i jmenovitě.
NAT NENÍ FIREWALL, ale poměrně úspěšně zařízení vnitřní sítě schovává a proti dobré implementaci NAT jsou techniky na prostřelení NAT neúčinné (mluvím o zařízeních, které nekomunikují ven).
No a třeba teď jedu do koncernu, kde je 64 sítí spojených v MPLS, jsou hlavní sítě na site(sajtě) a pak podsítě na každé site (cca 8), většina zařízení je interních a nemají mít bránu natož možnost se pokoušet prostřelit ven, přesto komunikace musí fungovat 100%, pozor, některá zařízení z podsítí spolu musí komunikovat a jiná ne. Zápis adres a vůbec manipulace s IPv6kama na firewallu je jako mytí podlahy mistrem Caletkou, zní to jako dobrý nápad, ve skutečnosti se Caletka brání.
Pro koncernové IT je IPv6 snad největší zlo.
Atd, atd, atd...
Přesně tak. Jedna věc je rozchodit si IPv6 v testovací síti v labu a úplně jiná je implementovat ho v reálné provozní struktuře, kde si není možné dovolit dlouhodobější výpadek, je potřeba řešit věci jako multihoming, atp. Ne, že by to nebylo vůbec možné, ale je to velmi nákladné a přínosy jsou vesměs minimální => žádný manažer co nechce být na hodinu vyhozený do toho nepůjde.
Tohle jsou dobre kecy :)
Problem u ipv6 implementace v korporatu je v tom, ze to spousta lidi bere jako "nutne" zlo a neco, co neni potreba okamzite resit, takze az pristi rok, jo?
Ted to vypada, ze integrace s cloudem, respective nemoznost plne integrace bude nova motivace proc to zacit resit.
Btw jedna z obrovskych vyhod pro korporat je skutecnost, ze interni aplikacni development nebude moci "hardcodovat" ip adresy do aplikaci a budou muset zacit pouzivat fqdn.
> a proti dobré implementaci NAT jsou techniky na prostřelení NAT neúčinné
Proti dobré implementaci firewallu jsou techniky na prostřelení firewallu neúčinné.
> Zápis adres a vůbec manipulace s IPv6kama na firewallu je jako mytí podlahy mistrem Caletkou, zní to jako dobrý nápad, ve skutečnosti se Caletka brání.
Jak přesně se to liší od pravidel pro maškarádu + pravidel, které zabraňují prostřelení maškarády zvenku?
NAT NENÍ FIREWALL, ale poměrně úspěšně zařízení vnitřní sítě schovává a proti dobré implementaci NAT jsou techniky na prostřelení NAT neúčinné (mluvím o zařízeních, které nekomunikují ven).
Dejme tomu, že za tím NATem je síť 10.0.0.0/8. Co udělá taková dobrá implementace NATu bez firewallu, když na vnější rozhraní dostane paket s cílovou adresou 10.0.0.1? Pošle ho do vnitřní sítě. K tomu „poměrně úspěšně schovává“ bych doplnil upřesnění – pokud se zrovna nikdo nedívá.
Firemni sit, nekolik stovek zarizeni, nektery 6tku neumi. Ipv6 v provozu uz nejakych 8 let, z toho cca 4 nativne, predtim tunel.
Problemy ...
Mno, problemy sem tam sou, treba s tim, ze ministerstvo financi propaguje v DNS IPv6 adresu svych serveru, ale sit je nedostupna, pripadne nekolik mesicu po upozorneni mailem (a bez jakekoli odpovedi) dostupna, ale porty za firewallem ... mno a nektere browsery proste takovej stav nepoberou a web nezobrazej (ani pres tu 4ku).
Jinak naprosta pohoda. Co se tyce pomeru provozu, zacina atakovat 50%. Interne to je pres 80%.
A konfigurace? Mno ... asi tak 5 minut radvd. A dalsich 10 minut firewall, ktery ma zhruba 1/4 pravidel proti NATu. Tudiz je daleko prehlednejsi.
Google kupodivu takovy kroky dela zcela bezne, treba proto, ze na 4ce vidi milion IPcek, ale za nima je 100M zarizeni. A ver tomu, ze goole neprijde ani o cent, protoze jakmile neco takovyho jen zmini ze hodla udelat, tak se provideri pretrhnou aby 6tku nasadili.
Ostatne, to vis, ze google umi (trebas) nabodenicka v mailovy adrese? To pred @ ...
Nevim jake mate od T-Mobilu v praci pripojeni, ale vsechny jejich ADSLky maji automaticky dualstack od pulky roku 2014. Predpokladam, ze T-Systems nabizi i optiku a podobne, kde to muze byt uplne jinak. Kazdopadne mi doma uplne bez problemu funguje dualstack uz rok. Je k tomu potreba modem nebo router s podporou DHCPv6-PD a to je vsechno.
Praxe si to myslí také. IPv6 je tu přes 20 let, a pořád jaksi ne a ne se pořádně rozšířit.
Kdyby si návrháři IPv6 nechtěli dokazovat svou moc, a záměrně nešli proti IPv4, ale snažili se o co nejhladší koexistenci a rychlý přechod, mohli jsme tu IPv6 mít všude už desetiletí.
Praxe má vždycky pravdu. Realita je nad všechny výkřiky „to že ty to nechápeě, neznamená, že nejde o príma věc“. Hnusná šedá realita zničila už tolik príma věcí, až to hezké není.
jj, pise hlava dubova ... realita je takova, ze tu porad vykrikujou ti sami uz 10let o tom jako to nejde, a vsem ostatnim to vpohode funguje.
Firemni pripojka ipv6/4 ... 52%/48%
Domaci pripojka ... 28%/72%
... vazne to nefunguje. Teda jak je videt na ty domaci, jedinej problem jsou prave soho ISP, protoze znacnou cast provozu delaji p2p site.
Ale lidi to vazne nechteji pouzivat, oni nevedi co je to IP, a to ze jim spouta veci nefunguje, to jim vazne nevadi. Kcemu taky takovy nesmysly jako SIP, Jabber, ...
Přesně tak. Děláme službu, která potřebuje přesměrování portu u zákazníka dovnitř jeho sítě a tohle je největší problém, který je schopno vyřešit je pár lidí (10%, max 20%). Dokonce i když je zákazník technik, u Carrier Grade NAT nebo u netu poskytovaného třeba majitelem budovy, kde jsou kanceláře, je to prakticky neřešitelné. Došlo to dokonce tak daleko, že lidi jsou ochotní koupit si za pár tisíc korun krabičku, která jim udělá tunel na náš server než aby vyřešili dostupnost portu z internetu.
To se taky pravděpodobně stane. V některých zemích (USA, díky Comcastu) už je penetrace tak vysoká, že se začnou objevovat lokální služby, které budou IPv6-only. Ono nakonec těm firmám nic nezbude, protože čtyřkové adresy na novou službu nedostanou. A když budou jejich služby zajímavé, vznikne tlak na poskytovatele připojení po celém světě.
... a pak nastane čas na přechod. Chce to se občas rozhlédnout po světě aby člověk pochopil, za co je pádný argument a co jen kecy podporované nadšením pro technické novinky.
Uživatele totiž zajímá jediné - "Co z toho budu mít za viditelný užitek" a na nějaké kecy o technické dokonalosti a změnách infrastruktury na pozadí se zvysoka vykašlou. Teprve ve chvíli, kdy přestane fungovat facebook a seznam nastane chvíle pro změnu.
To je pravda, proto kazdymu kdyz se pta, proc mu nefunguje torrent, nebo proc se nemuze podivat domu na svy fotky jako ja, peclive vysvetliju, ze proto, ze zadnej internet nema a at zmeni providera. Nekolik desitek lidi uz to udelalo a jsou spokojeni.
Az prestane fungovat FB nebo google, tak tvoje firma do druhyho dne krachne, protoze to uz bude pozde.
Včera mi volal nějaký pán, že ačkoliv si nastavil správně port forwarding na svém domácím ADSL modemu na své Arduino, tak se na něj přesto zvenku nemůže připojit a jestli bych mu neporadil, co dělá na Arduinu špatně. Tak jsem mu musel prozradit tu hořkou pravdu, že doma vůbec není připojen přes ADSL k Internetu, ale jen do nějaké sítě O2, a proto není z Internetu jeho Arduino dostupné. Byl velmi překvapen.
Napsal jsem do ČTÚ, že se domnívám, že by tito poskytovatelé připojení ke svým WAN měli mít zákaz deklarovat prodej přípojek k Internetu. Že by to prostě v ceníku museli napsat pravdu: přípojka do naší sítě, kde vám možná poběží proNATovaný Seznam - 399 Kč. Přípojka k Internetu - nemáme, došly adresy (případně za 519 Kč, protože někteří vykukové si za IPv4 účtují 120 Kč měsíčně). Pak by konečně zákazník mohl vybírat mezi ISP toho, který prodává skutečné připojení k Internetu, tedy s veřejnou IP adresou (ať už 4 nebo 6).
K věci doplním informaci z mých pokusů.
O2 k VDSL i ADSL přípojkám přiděluje veřejný IPv6 rozsah (bohužel dále nedělitelný, pokud se nepletu :( ) a privátní IPv4 za CG NATem. Ovšem když sem tento víkend k přípojce připojil modem bez podpory IPv6 (nějaký starší Draytek), dostal sem přidělenou veřejnou IPv4 přímo na modem jako dříve...
Zjevně tedy závisí co připojíte za zařízení. Takže z tohoto pohledu je to podle mě OK.
To s přechodem mezi privátní a veřejnou IPv4 podle typu modemu je velmi zvláštní. Pokud se nepletu, situace byla taková, že nejdříve začali od 1. 7. 2012 rozdávat jen novým zákazníkům privátní IPv4 spolu s IPv6, pak ale začali postupně od roku 2014 zavádět IPv6 všem, tedy i původním uživatelům, kterým zůstala veřejná IPv4 adresa.
V každém případě přidělení pouze jednoho rozsahu /64 je velký fail. Každému proto doporučuji přechod na T-Mobile ADSL, kde dostane /56 plus veřejnou IPv4 adresu.
Jednak ti v tom brani RFC, druhak ti ta rozdelena IPv6 nebude fungovat. Nebudou ti fungovat mechanismy automaticky konfigurace, a to je jen jedna z mnoha veci.
K cemu ti je 48 bitu MAC adres? K cemu ti je ze tvuj switch za kilo si jich umi pamatovat tisice?
Cela IPv6 je mimo jiny navrhovana tak, aby BFU nikde nemusel nic nastavovat. Aby proste pichnul zarizeni do site a vse fungovalo. A pokud chces (napriklad) provozovat wifi pro navstevy a nechces je poustet do svy domaci site, tak ses bez routovani v riti, a bez /56 taky, protoze 90% vsemoznych mobilnich krabek stejne nic jinyho nez RA neumi.
To ohromné množství adres je tam mimo jiné proto, aby si každé zařízení mohlo adresu náhodně zvolit a bylo téměř jisté, že se netrefí do už používané adresy. Další důvod je ten, že to činí plošné skenování všech adres poněkud nepraktické.
Ale nic vám nebrání si /64 dále dělit kdekoli, jen musíte počítat s tím, že všechny funkce IPv6, které předpokládají délku identifikátoru rozhraní 64 bitů, zejména tedy bezestavová autokonfigurace, přestanou fungovat.
V případě O2 na xDSL je to jejich obchodní politika, u jiných ISP nutnost, protože nemají ani IPv6 na rozdávání...
A u O2 jsem se i v létě nasmál, když jsme řešili IPv6 pro jednu firmu (100 Mbps napojení optikou symetricky), tak obchodníci se na požadavek, že chceme /48 vytasili s tím, že není problm, ale dle jejich ceníku to bude trošku drahé, že budou chtít 180 Kč za každý blok /64. :-)
Mám zkušenost jinou, konektivita 100 Mbps v pohodě. V klidu dokopali optiku asi 300 metrů, záloha rádio 17 GHz na střeše mířící na druhou stranu na BTSku.
Navc pár vláken přenecháno pro propojení poboček. Cena takovou, kterou alternativci nebyli schopni ani ve svých představách. Kraj Vysočina a Plzeň....
Ono to bude dost asi o místě a lidech.
Ano, ten blok /64 si můžete rozdělit na menší a udělat si tam několik sítí ručně. Ale problém nastane s konfigurací koncových zařízení. U IPv6 obecně se můžete spolehnout, že zařízení budou umět bezestavovou autokonciguraci na základě SLAAC - ale toto funguje jen pokud LAN segment je /64. Takže když to nadělíte na menší sítě, tak SLAAC nemůžete použít, pak už zbývá pouze ruční konfigurace a nebo stavové DHCPv6. A zde nastává problém, že řada zařízení ani při ruční konfiguraci nevezme masku sítě jinou, než /64. A hodně zařízení vůbec stavové DHCPv6 neumí, podporují jen SLAAC...
Takže proto vreálu s jednou /64 na obecné domácí síti si moc segmentů nenaděláte, pokud si nechcete zadělat jen na problémy - proto se volí xDSL služby od T-mobile, který dává IPv6 blok /56 a i IPv4 veřejku místo O2. :-)
Citace z článku:
"Ani poskytovatel připojení však často nedokáže zavést IPv6 bez spolupráce se zákazníkem, zvlášť v případě, kdy se zákazník IPv6 aktivně brání. Jak jinak si vysvětlit..."
A hned další odstavec:
"...je krásně vidět znatelný nárůst až o dvě procenta každý víkend, kdy lidé začnou používat Internet z domova, kam jim bylo IPv6 zavedeno pravděpodobně bez jejich vědomí."
Tak jak to je ? Většina lidí nic o nějakých IP protokolech neví, oni prostě jenom chtějí Internet. A já to naprosto chápu - sám mám doma neveřejnou IP adresu, nic neřeším, rychlost je pro moje potřeby dostatečná. Pokud by poskytovatel připojení zavedl IPv6, tak by mi to bylo vcelku jedno - pokud mi Internet (jako spotřebiteli) bude fungovat alespoň tak dobře jako teď, proč ne. A takhle k tomu přistupuje asi většina lidí.
Takže klíčová otázka ještě jednou - kdo že se to "IPv6 aktivně brání" ???
Ti zákazníci, kteří by pro zavedení IPv6 museli něco udělat na své straně. Dokonce se najde i část rezidentních zákazníků, kterým bylo IPv6 zavedeno bez jejich vědomí a oni jej přesto vypnou, třeba jen proto, že tomu nerozumí, nebo proto, že si myslí, že to nepotřebují. Nebo uživatelé webhostingů, či VPS hostingů, kteří dostanou IPv6 naservírovanou až pod nos a přesto nejsou ochotni ani přidat AAAA záznamy, v některých případech dokonce žádají provozovatele služby, aby pro ně IPv6 vypnul.
Třeba proto, že jejich super webová aplikace kterou napsal Franta Pepa před X lety za mraky peněz má pro IPčko char(15) a ono se jim opravdu nechce podruhé platit, aby jim někdo tu prasárnu předělal jen proto aby měli nějakou šestku. Firmám jde obvykle o zisk a ne o evangelizaci, a pro běžného malého zákoše jde jen o zbytečné náklady.
Z druhého konce mě napadá zajímavý pokus - schválně si na hoďku dvě vypnu na PC ipv4 a zkusím proklikat hry, co pojede a co ne.
P.S. koukám, pornhub, redtube i freevideo jsou také pořád na čtyřce only, fakt netuším jak přesvědčit užovky že šestka je budoucnost ;-)
Tak ja se hlasim, ze jsem ten zpatecnik, ktery na vsech pocitacich pro jistotu IPv6 vypina. Proc? Protoze nevim. Nevim, jak to funguje. Z toho, co tady pisete, si to tak nejak samo zije svym zivotem a z toho mam strach. (Pripomina mi to Microsofti NetBIOS, to taky tak nejak "fungovalo samo".) U IPv4 mam ctyrbajtovou adresu, masku, branu a to je v podstate nezbytne minimum.
Az nekde v nejake fabrice bude mistni IT vyzadovat, aby moje zarizeni umelo IPv6, tak to budeme resit. Zatim mi to prijde, ze ve fabrikach pouzivaji nejaky neverejny rozsah rozdeleny podle potreby na podsite, nejak si to routuji/firewalluji/natuji a rozhodne nemaji zajem na tom, aby vsichni videli vsechno. A pokud chcete od sebe z domu/prace/kancelare/zvenku k zakaznikovi do fabriky, tak rozhodne neni nejvetsi problem v nejakem IPv4 nebo NATu, ale v byrokracii.
> Z toho, co tady pisete, si to tak nejak samo zije svym zivotem a z toho mam strach.
To já mám v IPv4 taky.
> U IPv4 mam ctyrbajtovou adresu, masku, branu a to je v podstate nezbytne minimum.
U IPv6 máš šestnáctibajtovou adresu, masku, branu a to je v podstate nezbytne minimum.
> a rozhodne nemaji zajem na tom, aby vsichni videli vsechno
To chápu, ale u IPv4 je často problém udělat i aby lidi viděli to, co vidět mají.
Nejdříve musí být veškerý obsah dostupný na IPv4 i IPV6. To musí zařídit google tím, že zavede penalizaci. Podobně jako to je s bubu ohledně EU cookie. Všichni se více méně podřídily.
Pokud nebudete mít za 2 měsíce web dostupný jako dual, pagerank dolů.
Poté musí přijít na řadu stát, který řekne všem ISP, že za rok musíte mít vše duální.
Jak snadné.
Mít web jako duál dnes není problém, obvykle stačí do DNS přidat AAAA záznam, poskytovatelé služeb (datacentra, VPS, web hostingy) mají všechno na šestce už léta.
Problém je na druhé straně, u koncových uživatelů. Kvůli nim musí datacentra pracně shánět IPv4 adresy, kterých je šílený nedostatek. Dnes není možné si spustit nového poskytovatele VPS nebo datacentrum. Prostě na to nedostanete rozsah. Přitom byste klidně mohli vystačit s IPv6. Kdyby nebyla doba ledová u uživatelů.
No co, řekne, že od upstream poskytovatele dostal jenom /48, takže má jenom 256 /56, takže kdo ji chce, musí pořádně zaplatit.
(toho se osobně docela bojím, jako teď ISP dávají většinou jednu IPv4 a další za příplatek, tak že potom budou dávat /64 a kdo chce mít síť, bude si muset připlatit za /56)
Zamenujes pojmy ISP a LIR. Organizace muze mit vlastni AS, vic linek ven a provozovat BGP, aniz by byla LIRem. ASN muze ziskat od RIPE pres nejakeho LIRa (v rezimu sponsoring LIR) a /48 muze dostat assignute od nejakeho LIRa jako nezavisle routovatelny prefix, ktery muze propagovat pres BGP.
Ne nezamenuju. ISP ti MUSI poskytnou /56. Kdyz si svymu providerovi reknu, ze potrebuju /48, tak mi ji da. Obratem. A kdyz mu reknu, ze chci /32, tak mi rekne ze at pockam, nez si ji vyzada. A da mi ji taky. Maximalne po me bude chtit, abych vypsal nacionale do whois.
/48 neni rozsah pro ISP, to je rozsah pro koncovyho uzivatele. Ostatne neni to tak dlouho co byl v RFC jako minimalni pridelitelny rozsah.
Mimochodem, nekolik /48 mam.
> Ne nezamenuju.
Pokud beru IPS dle tebou vyse uvedene definice, tak zamenujes.
> ISP ti MUSI poskytnou /56.
Nemusi. viz RIPE-552 (IPv6 Address Allocation and Assignment Policy):
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
> Kdyz si svymu providerovi reknu, ze potrebuju /48, tak mi ji da. ... /48 neni rozsah pro ISP, to je rozsah pro koncovyho uzivatele.
Co ISP nabizi svym zakaznikum, je vicemene otazka jeho obchodni politiky. Bud muze byt rovnou LIR (obvykle u vetsich ISP), nebo muze vetsi pozadavky od zakazniku delegovat na sveho LIRa, nebo proste muze rict zakaznikum, ze maji s vetsima pozadavkama smulu. Opet viz RIPE-552:
5.3. LIR-to-ISP allocation
There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR.
Ehm ...rfc6177 ... napr
Jinak RIPE:
When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. ...
https://www.ripe.net/publications/docs/ripe-655
A to je rec o koncovy siti samo.Tudiz defakto i pridel /56 porusuje pravidla. Ale rekneme ze na nem panuje shoda jako na pro drtivou vetsinu siti dostatecnym.
Aha, takže jde o to že to chápete úplně špatně, protože shorter = kratší prefix = víc adres, je to jasně zdokumentované například tady: https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments
Několik /48 máte prto, že využíváte služeb rozumných subjektů, které jsou LIRy a mají svůj blok /32 z kterého dávají. Ale když se podívám, tak většina malých ISP v Česku, pokud má IPv6, tak má od svého uplinku přidělen jeden, někdy dva, bloky /48 a to si porcují dál koncákům.... A řada i těch, co má vlasntí AS, tak má koupen jeden blok IPv6 PI adres, takže jsou na tom podobně Tihle vám na požádání /48 nedají, u nich budu rád, pokud mi dají /60 jao koncáku a firmě možná /56. Taková je realita spolupráce s řadou menších ISP...
V tomhle paradoxně pomůže aktuální hlad po IPv4 adresách, který donutí i menší ISP zařídit si LIRa a získat tak mimochodem správné množství IPv6 adres pro své podnikání. Pokud někdo vystupuje v roli koncového objektu (má v RIPE databázi assignment na svou osobu), neměl by dané adresy používat pro svoje zákazníky, to není v souladu s pravidly. Výjimku tvoří point-to-point spojovačky a broadband pooly (ty však musí být vyznačeny speciálním stavem AGGREGATED-BY-LIR).
PI adresy jsou vždy určeny pouze pro potřeby jejich držitele a jejich přidělování dalším subjektům povoleno není. Proto také PI příděly existují pouze ve velikosti /48.
Kde není žalobce, tam ani není soudce. A finanční hledisko hodoří u těchto subjektů ve prospěch PI, dle jejich názoru, co jsem vyrozumněl.
Ale ano, souhlasím, že zoufalá snaha sehnat posledích pár IPv4 bloků, co ISP nažene do role LIRa,tak mu dá i tu IPv6 /32, takže prostor pak má.
Nocméně toto uvědomění se moc nepozoruji v okolí a i když se někdo probudí, tak často usne po zjištění, že to není zadarmo. :-)
Pokud je doba ledová u uživatelů, pak proto, že byl špatně vymyšleno celé IPv6 včetně plánu na co nejhladší přechod.
Stačí číst články zde na rootu či jinde, a síťaři i odborníci naopak trucovali tak, že dělali všehcno proto, aby přechod z IPv4 byl nemožný, aby se šlo zcela odznovu. Teprve později se trochu ustoupilo, protože když síťaři viděli spálenou zemi, kde namísto IPv6 co nejrychleji a zničené IPv4 viděli o to víc pevněji se držící IPv4 a vzdalující se přechod na IPv6 – pochopili, že musejí pár kroků vstříc udělat. Jenže to jsou nalepováky a je pozdě.
IPv6 se neujalo za 20 let. A minimálně dalších 10 let se neujme, přes všechny problémy s IPv4 adresami. Pro hloupost těch, kdo chtěli prosadit IPv6 revolucí namísto evolucí. Ti to spískali, ne uživatelé.
Ostatně už to, že došlo přes 4 miliardy IPv4 adres ukazuje, že jejich rozdělování bylo děláno špatně.
Zkrátka neustále čtu o nutnosti IPv6 a o zlých těch a oněch co tomu brání, a kdybych si všechny výslyky slov IPv6 nahradil třeba slovem „!imigranti“ nebo pod. – mám krásné sluníčkové projevy Sobotky či neziskovek.
Ne, uživatelé za nic nemohou. To pouze realita se brání vůči namyšlenosti těch, kdo výmýšleli přechod na IPv6. To to zbodali, a nechtějí si to přiznat. A teď už s tím stejně nic nenadělají. Když bůh dá, za 20–30 let se přechod na IPV6 podaří. Možná. To je celé.
> pak proto, že byl špatně vymyšleno celé IPv6 včetně plánu na co nejhladší přechod
To už jsem slyšel mnohokrát, ale když jsem se toho člověka zeptal, co konkrétně by si představoval lépe, nebo nedej bože jak, tak jsem se odpovědi nikdy nedočkal. Doufám, že tentokrát budu úspěšnější.
> Stačí číst články zde na rootu či jinde, a síťaři i odborníci naopak trucovali tak, že dělali všehcno proto, aby přechod z IPv4 byl nemožný, aby se šlo zcela odznovu.
Ničeho takového jsem si nevšiml.
> Pro hloupost těch, kdo chtěli prosadit IPv6 revolucí namísto evolucí.
Jak udělat „evoluci“, když v té hlavičce prostě místo na další bity není?
> Ostatně už to, že došlo přes 4 miliardy IPv4 adres ukazuje, že jejich rozdělování bylo děláno špatně.
Tomu nevěřím. Podle mě můžou mít tak dvě miliardy lidí na světě počítač, přičemž miliarda „zápaďáků“ má kromě počítače ještě počítač v práci, notebook, mobil, APčko, ledničku, televici a já nevím co ještě. K tomu nějaká infrastruktura a čtyři miliardy jsou pryč, i kdyby byly rozděleny teoreticky ideálním způsobem (což vzhledem k subnettingu spíš nejde).
"Jak udělat „evoluci“, když v té hlavičce prostě místo na další bity není?"
To je jednoduchy, vyuzijeme nevyuzivanej priznak ... a dame to do dat.
Ze z toho routerum jebne a jejich vykon padne naprdel? No a co, hlavne ze se to bude libit Ponkracovi.
Jo a taky budem muset nejdriv vsechny Ipcka providerum sebrat a znova je prerozdelit. A protoze defakto i jedina adresa bude znamenat celou obrovskou sit ... tak BGPcku jebne taky, protoze v nem bude asi tak 10 milliard rout.
Hlavne nedej boze, aby neco fungovalo samo, je treba zachovat vsechny dhcpka, arp, ... a predevsim, nejdulezitejsi soucast sitovani vubec ... !NAT! ... aby ponkrac neprisel o kseft, kdyz uz se to tak pracne naucil.
Patrně jsi nezažil přechod z IPX, Novell a NetBIOS na IPv4 :-) Proti tomu je IPv6 sranda.
Uživatelé opravdu za nic nemohou, jejich Windows podporuje IPv6 nejpozději od Vista, Linux ještě dříve, problémy jsou jen a pouze na straně ISP.
V Číně jsou tyto diskuze pro smích, tam jedou na IPv6 již mnoho let.
Jako nejvetsi problem IPv6 vidim nestalost prostredi. IPv6 jsem si nejdrive jako tunnel, pozdeji lokalne (tedy jakysi dualstack lab) zprovoznil jiz pred lety. Pokazde po nejake dobe ovsem zjistim, ze to zase nefunguje. At uz je chyba v nastaveni site, v operacnich systemech po aktualizaci nebo v ceste dal, proste se chovani meni, na zaklade toho jak se IPv6 vyviji. Nakonfigurovat IPv6 na serveru, kam ji doroutuje poskytovatel je jednoduche. Ovsem v siti stovek rozdilnych zarizeni, ktera se chovaji ponekud odlisne a kde rozmotat VLANy a IPv4 rozsahy je samo o sobe orisek a ted si to jeste zamotat IPv6, to uz chce opravdu hodne casu a evidentne i nasledna udrzba ma vetsi rezii. Navic nikdo stale nerekl, jak to spravne udelat - existuje nekolik variant a zadna neni idealni.
Naopak, ten standard je naprosto stabilní už přes deset let. Přibylo pár přechodových mechanismů, ale samotný protokol se nezměnil.
Když mám na routeru rozsah, rozdělím ho (nebo to udělá router dokonce sám) mezi sítě a v nich si klienti podle oznámení (RA) přidělí adresu. To je celé, magie v tom není.
Lol ... tak jelikoz je tu IPv6 jen 20let, tak je proste jeste stale v prudkym rozvoji ...
Viz predchozi, router si rekne o adresu, od ISP dostane celej prefix, z nej prideli po /64 na jednotlivy rozhrani a pusti na nich RA. Pokud od toho admin nic vic nechce, tak nemusi na konfiguraci ani sahat.
IPv6 adresa sa skladá z dvoch logických častí: 64-bitového prefixu siete a 64-bitovej adresy stroja v sieti, ktorá sa často generuje automaticky z adresy rozhrania (MAC adresa). MAC adresa je jedinečná.
nehovoriac o tomto
2001:0db8:85a3:08d3:1319:8a2e:0370:7334 vs 121.202.85.102
Ja si natoto vôbec nezvyknem.
Nehovoriac o tomto:
2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab
áno je to z wikipedie, ale vôbec sa mi to nepáči.
Potom je tu článok na root.cz
http://www.root.cz/clanky/edward-snowden-na-prazskem-ietf-navrhnete-bezpecnejsi-internet/
Dotkl se i nebezpečí spjatých s dlouhotrvajícími hardwarovými adresami. To se primárně týká bezdrátových spojení, kde MAC adresa funguje jako vlajka s identitou definující pozici.
Snowdenova řeč sklidila bouřlivé ovace. Mezi důvody, proč se tak stalo, může mimo jiné patřit fakt, že se NSA podařilo rozlousknout několik klíčových internetových protokolů vyvinutých IETF a dokonce i rozvracet některé jeho pracovní skupiny, ve snaze vyvinout nové standardy podle NSA.
Takže IPv6 NE!!!!!!
Opat mam pocit, ze sa nechapete. Podla mna predrecnik tvrdi nieco taketo: Mam hromadu IPv4 hostov za NAPT na jednu externu IPv4. Niekto teda vonku nie je schopny spolahlivo rozoznat od seba jednotlive hosty a preto nie je ani schopny efektivne sledovat ich cinnost.
Pri IPv6 ma jeden host vzdy konkretnu IPv6 adresu viditelnu pre kazdeho a je jedno, ze sa kazdych par minut zmeni host cast adresy, kedze to sa da odsledovat.
Problemom je teda podla neho fakt, ze sa traffic z jednej masiny da vzdy spolahlivo rozoznat od trafficu z inych masin a ked si niekto zmeni adresu, tak sa to da statistickymi metodami velmi lahko zistit.
Hezká ukázka jednoho z nevýhod NATu. :-)
Podobně řvou třeba hráči na konzolích. Jeden třeba zaprasí na PS4 něco a Sony blokne IPčko a půlka okresu má smůlu, nezahraje si, dokud ISPík je nedá na jiné...
Další podobný 'debil' je třeba Google. Pokud z jedné IPv4 adresy chodí moc požadavků, protože na ni NATuji pár set přípojek, tak začne neustále vkládat na každý dotaz captchu a uživatelé pak zuří. Sice teoreticky u Google může registrovat, že tyo IP bloky slouží pro CGN, ale zapár týdnů se to opakuje. Jako doporučení dostnau, že máte zákošům nasadit IPv6....
Ano, pokud vezmu shrnutí jedné z příloh zprávy ohledně problémů sledování uživatelů za NATem, tak úspěšnosí a přesnost sledování lidí za dvojitým ž trojitým NATem byla hodně vysoká. A to ten dokument původně vznikal s představou, že podpoří názor, že je těžké spolehlivě rozeznat počet storjů za NATem, přiřdit k sobě jendotlivé toky, že pochází z jednoho počítače atd. Snad vyjma externího sledování přenosů prošlých přes 4G sítě, které przní/rekonstruují IP hlavičky, takže toky dosti unifikují. Ukázalo se, že dneska to většina nástrojů používsaých Policií v rámci zemí EU umí velmi spolehlivě, s úspěšnosít nad 95% za časové okno 144 hodin (při sledování toků na uplinku od ISP používající CGN, kdy nedochází k jeho spolupráci s Policií a anii o sledování neví). Takže na ochrannou roli NATu bych moc nevěřil, pokud ten NAT není konstruován tak, aby cíleně modifikoval komunikaci za účelem ztížení identifikace, což větěina nedělá.
Opet dalsi, co o tom zvani a netusi o cem.
IPv6 se generuje bud z MAC nebo z GUID (by default, a da se to zmenit). To je IPcko urceny pro servery, aby se na ne dalo pripojit zvenku. Ovsem privacy extension ti zjevne nic nerikaji. To sou nahodne (klidne kazdych par minut) generovany adresy, ktery slouzej k odchozi komunikaci. A mimo jiny k tomu, aby stroj, kterej se pohybuje vice sitema (treba mobil) neslo sledovat. Widle to maj by default zapnuty.
Adresu na nic vedet nepotrebujes, je to technickej identifikator, presne stejne jako ta MAC adresa, ta se ti libi? Aha, tu nanic nepotrebujes, presne stejne jako IP, potrebujes jmeno, a tam si muzes dat co chces. Trebas pepek.vyskoc.cz.
Nerad sa vam miesam do plodnej diskusie, ale mne sa vsade osvedcilo toto miesto fail2ban:
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshblacklist --set
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshblacklist --update --seconds 120 --hitcount 4 -j DROP
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Pre IPv6 sa to da jednoducho upravit, aby to bralo napriklad len /64 prefix pri matchovani pravidiel.
Roboty to vacsinou vzdaju ihned, resp. uz velmi davno som nenasiel v logu zaznam o tom, ze by to nejaky robot skusal opat po tom, ako vyprsi DROP. Taktiez som sa bal, ze to bude robit problemy aj klasickym pouzivatelom, ale uz si ani nespominam na pripad, aby niekto potreboval otvorit viac ako 4 spojenia za 120 sekund. Vacsinou si ludia otvoria ssh, mozno nejake scp, ale stale je tam rezerva.
Nedávno som prešiel s VPS od v-netu do forpsi. Skoro mi oči vypadli keď som zistil, že už nemám IPv6... Zatiaľ mi to je jedno, uvidím časom.
Doma mám dsl router od t-comu s úzkou telefónnou koncovkou. Skúste zohnať poriadny router. Ani nemám ako vyskúšať, či by náhodou nefungovala IPv6. Som rád, keď mi tá kraksňa funguje aspoň týždeň v kuse.
hm, diskusi jsem si precetl, konec koncu neni prvni na toto tema, ale porad neznam odpoved na nasledujici:
K cemu je mi IPv6, kdyz nechci byt soucasti IoT a vsech tech legracek kolem (resit, jestli mi nekdo zvenku hackuje lednicku, zkousi nahrat sledovaci software do televize nebo co ja vim co vsechno).
Dokud jsem na IPv4, tak zvenku neni videt nic, pristupy zvenku skonci na routeru a dokud nenecham forwardovat konkretni port na nejake zarizeni v LAN, tak si na nej zvenku nikdo ani nepingne.
Jakmile ziskaji vsechna zarizeni nejakou IP6, tak budu muset zacit resit prinejmensim firewall a kam zkousi volat ven a kdo je zkousi volat zvenku.
Tak k cemu by mi IPv6 byla, krome pripadnych problemu?
> K cemu je mi IPv6, kdyz nechci byt soucasti IoT a vsech tech legracek kolem
K tomu, aby sis mohl s ostatními vyměňovat soubory. K tomu, aby sis s nimi mohl telefonovat. K tomu, aby sis mohl pro svůj web pořídit VPS za 20 Kč, když IPv4 adresa stojí 40.
K tomu, aby ses dostal na služby, které nebudou mít IPv4 adresu (zatím hudba budoucnosti).
> Dokud jsem na IPv4, tak zvenku neni videt nic
To jednak není pravda a jednak to souvisí s firewallem, nikoli s IPv4/IPv6 nebo NATem.
> Jakmile ziskaji vsechna zarizeni nejakou IP6, tak budu muset zacit resit prinejmensim firewall a kam zkousi volat ven a kdo je zkousi volat zvenku.
To musíš už teď. Co asi udělá tvůj router (vlastně ani nezáleží na tom, že v něm je NAT), když na jeho venkovní rozhraní dorazí paket s destination IP 192.168.0.66? To, co se od routeru tak nějak očekává - šoupne ho dovnitř.
No ... jak si budu vyměňovat soubory, když všichni budou za routerem (protože to jinak skoro ani dělat nejde) a všichni budou mít naprosto stejný stavový firewall, jako na IPv4?
Mimochodem - zkus si takový paket odněkud někam poslat. Jak budeš mít v cestě jeden jediný router, co nebude tvůj, tak si nepošleš. Případně pošleš, ale to bude taková výjimka, že se jí nehodlám moc zabývat.
Nu, DUID koncept se dosti zvrhl u DHCP. Ono to vychází z toho, že se DHCPv6 používá na všech typech linkách, včetně PPP, takže to nějak museli pořešit.
Je fakt, že řada DHCP serverů to umí ignorovat a jet dle MAC. A pokud je zařízení rozumné, jede s DUID-LL, takže je v tom zase jen ta MAC adresa.
Jimka k DUID-LL mám doboru historku, například TMobile to ve své ADSL síti hlídá, takže dát na Jižní Moravě router na ADSL, který si vezme IPv6 prefix přes DHCPv6-PD, zduplikuji konfiguraci tak blbě do jiného routeru, že do druhého se přenese i DUID-LL a zapnu ho v Libereckém kraji na síť TMO, tak už IPv6 prefix nezíská, dokud ten první router v Brně nevypnu. Tak pozor při klonování konfigurací. :-)
> No ... jak si budu vyměňovat soubory, když všichni budou za routerem (protože to jinak skoro ani dělat nejde) a všichni budou mít naprosto stejný stavový firewall, jako na IPv4?
Doufám, že nebudou.
> Mimochodem - zkus si takový paket odněkud někam poslat. Jak budeš mít v cestě jeden jediný router, co nebude tvůj, tak si nepošleš.
Já vím, ale to, že útoky fungují jenom ze stejného baráku/ISP/… snad neznamená, že je to v pořádku.
Fungujou klidne i z netu ... co myslis, pres kolik % routeru projde source routing? Vyzkousej si to. A spousta provideru naprosto vpohode pusti i privatni IPcka. Naprosto bezne se mi vraci treba odpoved na ping, ktera ma v src 192.168 ... pres celou republiku pripadne i zahranici.
Proto jak rikam, naivni trotli co si myslej, ze NAT je jejich spasa.
>K tomu, aby sis mohl s ostatními vyměňovat soubory. K tomu, aby sis s nimi mohl telefonovat. K tomu, aby sis mohl pro svůj web pořídit VPS za 20 Kč, když IPv4 adresa stojí 40.
Ako sa bude lisit vymena suborov a telefonovanie s IPv4 za NATom (ktore teraz funguje, bez problemov si vymienam subory a telefonujem s inymi ludmi nech som kdekolvek) a IPv6?
Ked budem chciet vymienat subory s vyuzitim plneho potencialu IPv6, tak si najskor spusitm nejaky file server, potom sa prihlasim do firewallu a povolim tam pristup, vymenim si nejake subory a potom to zase zrusim? Alebo ako mi v tomto ma pomoct IPv6?
"Ked budem chciet vymienat subory s vyuzitim plneho potencialu IPv6, tak si najskor spusitm nejaky file server, potom sa prihlasim do firewallu a povolim tam pristup, vymenim si nejake subory a potom to zase zrusim? Alebo ako mi v tomto ma pomoct IPv6?"
Tohle řeší to, pokud daný fileserver bude podporovat UPnP, pokud ano, tak po dobu svého běhu požádá domácí router, aby otevřel pro forward potřebné IP:porty. V podstatě stejně, jak to dneska dělá i pro IPv4, akorát nenastavuje jen otevření IP:port, ale zároveň konfiguruje i destination NAT.
Záleží, jak chytrejmáte routřík, na některých jde nastavovat, co může UPnP vše doprznit a zda jej vůbe cmá podporovat.
Nicmén ě je to běžně používaný způsob, jak mít defualt stavový firewall blokující vše dovnitř s možnotí si dynamicky něco otevřít.
UPnP je ale míněno hlavně pro dočasné otevření (např hry) a ne trvale běžící služby, kde ořčekávám nastavne natvrdo člověkem.
Jen jsme ukayoval, že řešneí pro IPv4 iIPv6 je podobné.
Pokud ty IP má a neumí ji dostat až k zákazníkovi, tak je to jeho neschopnost a lennost. :-)
Nicméně jsem popisoval, jak to může fungovat. V případě IPv6 žádný CGN nebude u operátora, takže stačí aplikaci ovládat koncový home router. V případě IPv4, kdy je tam ještě CGN, tak toto nelze a musí se používat opičárny jiné a mnohem komplikovanější. Takže tady je vidět situace, kdy to IPv6 zjednodušší.
Apropo, začíná to smrdět, že nebude ani CGN pro IPv4, evidentně začíná být v EU myšlenkový tlak na zákaz operátorských CGN dříve, než s ezačnou rozmáhat.Když nebude mít operátor dostatek IPv4 adres pro každého zákazníka, tak bude dávat IPv6 only přípojky a žádný NAT v dual stacku k tomu. A jako bonus bude operátor provozvat online databázi pro státní úředníky, kde si kdykoliv bude moci Policie a spol najít, jaké IP má jaký uživatel k používání (proto ten zákaz CGN, aby stačila pro identifikaci IP). Tím se odstrasní nutnost ukládání dat u operátorů a stát si přijde na své informace i bez aktivní spolupráce s ISP a nějakými soudníma povoleníma na zjištění identity majitele přípojky. :-)
> Ako sa bude lisit vymena suborov a telefonovanie s IPv4 za NATom (ktore teraz funguje, bez problemov si vymienam subory a telefonujem s inymi ludmi nech som kdekolvek)
Tak to jsi hustý, já k telefonování potřebuju SIP server, který se pokusí prorazit UDP díru, a když se to nepovede, tak tuneluje všechna média, a přenosy souborů mi nefungují vůbec. Jak to děláš?
>> K cemu je mi IPv6, kdyz nechci byt soucasti IoT a vsech tech legracek kolem
> K tomu, aby sis mohl s ostatními vyměňovat soubory.
nepoužívánm
> K tomu, aby sis s nimi mohl telefonovat.
to už provozuju na IP4
> K tomu, aby sis mohl pro svůj web pořídit VPS za 20 Kč, když IPv4 adresa stojí 40.
nepotřebuju
> K tomu, aby ses dostal na služby, které nebudou mít IPv4 adresu (zatím hudba budoucnosti).
tady už teprve postrádám konkrétní smysl
>> Jakmile ziskaji vsechna zarizeni nejakou IP6, tak budu muset zacit resit prinejmensim firewall a kam zkousi volat ven a kdo je zkousi volat zvenku.
> To musíš už teď. Co asi udělá tvůj router (vlastně ani nezáleží na tom, že v něm je NAT), když na jeho venkovní rozhraní dorazí paket s destination IP 192.168.0.66? To, co se od routeru tak nějak očekává - šoupne ho dovnitř
a tam to skončí, protože síť mám číslovanou jinak
sorry, ale pořád neznám důvod, k čemu je mi IPv6
Vy tu řešíte protokoly a na ministerstvu je žádost o schválení návrhu sdružení, které chce vybírat povinný výpalný z 3D tiskáren rozdělených do třech skupin podle schopností kolik cm3 hmoty jsou schopné vytisknout a jakým materiálem se tiskne. Argumentují tím, že jsou to „kopírovačky" všeho možnýho. Jinými slovy zákonem se stanou z dětí a jejich hraček výrobci, podnikatelé, kopírovači, tak se musí danit. Stát prý přichází o peníze, které by jinak formou daní získal od podnikatelů s papírem. Výrobci je snad převezou a budou prodávat půlstavebnice, ze kterých se pak kombinací složí 3D tiskárna.
Podle mě předně i IPv6 není nějak zájem. Jaký je vlastně důvod, proč by ISP měli investovat do něčeho, co BFU (99 % jejich zákazníků) stejně nijak neocení? Těm i několikrát natované připojení na Facebook a spol. stačí. Navíc realita je dnes taková, že nikoho ani nenapadne že by se data dala posílat přímo z počítače do počítače. Všechny služby jsou dnes založené na klient-server modelu. Koupíte si domů nějaký chytrý bazmeg, ale z telefonu se k němu nepřipojíte přímo, ale pouze přes servery výrobce. Jiná možnost není implementována. Nebo když chce Pepa poslat Frantovi fotky, tak je prostě nahraje na ulož.to a Franta si je stáhne. A zatelefonují si přes Skype. Ani jednoho z nich nenapadne, že by to měli dělat jinak, protože tohle je blbě a proti principům internetu. To je (bohužel) realita dneška
Predstavme si ze prejdem na to super IPv6 a budem chciet robit bezne veci:
Doma:
Kupim si novy router alebo inu sietovu krabicku, pripojim ho do siete a chcem ho nakonfigurovat, tak do prehliadaca zadam 32 pismeniek a 7 dvojbodiek a nezabudnem to zavriet do hranatych zatvoriek... toto spravim vzdy ked budem chciet do toho routeru ist.
Vlastne nie! Kvoli tomu budem prevadzkovat DNS.
firma:
legacy software podporuje len ipv4 (napr. dochadzkovy system)
20 IP telefonov na stoloch a 5 v sklade vyhodim, lebo nepodporuju IPv6
maly ISP:
zakaznik chce ipv4 takze musim mat dual-stack vsade, takze vsetko musim konfigurovat dvojmo. O prehladnosti IPv6 adries nehovoriac. Nad chybajucimi bezpecnostnymi funkciami pod ipv6 na switchoch a routeroch sa ani nepozastavim (problemy s rogue RA, problematicka analyza dlhych hlaviciek, ..., viz clanky Bezpecne ipv6 tu na roote)
> Vlastne nie! Kvoli tomu budem prevadzkovat DNS.
To jsi fakt nikdy neslyšel o mDNS, nebo to hraješ?
> legacy software podporuje len ipv4 (napr. dochadzkovy system) 20 IP telefonov na stoloch a 5 v sklade vyhodim, lebo nepodporuju IPv6
To je velmi smutný svět, ve kterém neexistují přechodové mechanismy. (btw. pokud je to starý síťový software, stejně by si zasloužil vlastní síť, protože to bude cedník)
> zakaznik chce ipv4 takze musim mat dual-stack vsade, takze vsetko musim konfigurovat dvojmo
NAT64 anyone?!
> O prehladnosti IPv6 adries nehovoriac.
jj, hrůza!
> Nad chybajucimi bezpecnostnymi funkciami pod ipv6 na switchoch a routeroch sa ani nepozastavim (problemy s rogue RA
Nad chybajucimi bezpecnostnymi funkciami pod ipv4 na switchoch a routeroch sa ani nepozastavim (problemy s rogue DHCP
> problematicka analyza dlhych hlaviciek
Tak, tohle je asi jediný dobrý argument. (nesledoval jsem poslední vývoj, nejde to, co chceš typicky filtrovat, tj. RA a multicast, identifikovat podle první hlavičky?)
> To jsi fakt nikdy neslyšel o mDNS, nebo to hraješ?
Ale iste, ale kolko z dnes predavanych krabiciek s IPv6 to ma?
> To je velmi smutný svět, ve kterém neexistují přechodové mechanismy.
Takze prevadzkovat dalsi system ktory vyzaduje konfiguraciu.
>NAT64 anyone?!
Asi som to zle napisal, ale ked zakaznik bude chciet verejnu ipv4 tak mu nat64 nepomoze a ked hej (inverzne mapovanie), tak zase budem mat ipv6 siet s jednymi pravidlami a ipv4 s druhymi a este budem udrzovat preklady
> jj, hrůza!
a nie? :)
> nejde to, co chceš typicky filtrovat, tj. RA a multicast, identifikovat podle první hlavičky?
IMHO nejde, ide to identifikovat podla zaciatku payloadu.. a preden si mozes hlaviciek postrkat kolko chces, takze nejaky switch nema sancu ich vsetky analyzovat a zahodit to co tam nema byt (port security). Ale mozno na to nieco vymysleli, necham sa poucit.
Asi som to zle napisal, ale ked zakaznik bude chciet verejnu ipv4 tak mu nat64 nepomoze…
Když bude zákazních chtít veřejnou IPv4 adresu, nepomůže mu za chvíli ani svěcená voda. Všichni chtějí veřejnou adresu, to je ostatně důvod, proč došly.
Jinak kromě NAT64 existují i přístupy, které mnohem méně kazí funkčnost IPv4 a přitom umožňují provozovat single stack přístupovou síť. Například MAP-E: http://www.root.cz/clanky/ipv4-jako-sluzba-aneb-jak-sit-zbavit-dual-stacku/
IMHO nejde, ide to identifikovat podla zaciatku payloadu.. a preden si mozes hlaviciek postrkat kolko chces, takze nejaky switch nema sancu ich vsetky analyzovat a zahodit to co tam nema byt (port security). Ale mozno na to nieco vymysleli, necham sa poucit.
Správný návrh sítě vůbec nepřipustí, aby se na jednom L2 segmentu potkali lidé, kteří by mohli mít zájem si vzájemně škodit. IPv6 k tomu dává krásné prostředky (jako off-link prefixy), které se však nedají dobře použít, pokud musí být na stejné infrastruktuře provozováno i IPv4. Věci jako DHCP snooping, ARP inspection a RA guard jsou jenom obezličky, které mají vždy nějaké problémy.
Jinak co se týče problému s fragmentovanými RA, tak tuším že je standard, podle kterého má koncový systém fragmentované zprávy objevování sousedů, včetně RA, ignorovat, protože se nepoužívají pro nic jiného než pro útok. Otázka samozřejmě je, jak dobré jsou koncové systémy v implementaci.
Predstavme si IPv6 tak jak je navrzeno. BFU si domu prinese router, pripoji ho do site, a on si SAM rekne o adresu a ISP mu AUTOMATICKY prideli prefix, ktery router SAM rozdeli na jednotlivy rozhrani (treba ethernet a wifi). BFU na to nemusi ani sahnout a funguje to.
BFU si totiz v zadnym pripade neumi nastavit ani tech !minimalne 6x4 cisel, ktere nezbytne potrebuje aby mu jeho sit fungovala na Ipv4. Natoz resit nejaky NAT. BFU totiz vubec netusi, kde se v jeho windows nejaka sit nastavuje.
Zakaznik zadnou IPv4 nechce, zakaznik chce fungujici internet a ten na IPv4 vetsinou nedostane.
Jestli mas ve firme 25 10let starych IP telefonu, tak si je mel vyhodit uz pred 5ti lety minimalne. Minimalne 10let totiz vsechny IPv6 umi.
>Zakaznik zadnou IPv4 nechce, zakaznik chce fungujici internet a ten na IPv4 vetsinou nedostane.
Zakaznik ma server a chce ho na verejnej ipv4, mozem ho presviedcat ze nech si to da na ipv6 aby sa na to nedostal z polovice beznych pripojeni, ale to je tak vsetko co stym mozem urobit
až na to, že většina bfu ani netuší, že by takové problémy měla mít. Poskytovatelé služeb se naučili s natem žít, takže bfu hrajou hry na nějakém serveru provozovatele a protože chtěj, aby se jim na VoIP dovolali i lidi "zvenčí", tak stejně jedou přes server operátora a ani netuší, že by se to mohlo řešit jinak(btw sám jsem přímý přístup z internetu k VoIP telefonu zařízl, protože mě nebavilo to prozvánění z internetu). BFU určitě ocení, když místo nějakého nicku na nějaké službě začnou dávat ipv6 adresy, aby si aplikace povídaly bez prostředníka. Přínos natu ohledně bezpečnosti je v tom, že když nefunguje přímá komunikace s koncovými stanicemi, tak naučil lidi nebo je to tak nastavený defaultně, zaříznout veškerý přístup zvenčí.Až (jestli) se rozmůže přímá komunikace na koncové kompy, tak to bude bezpečnostní peklo, protože se BFU naučí, že když chtějí aby jim něco fungovalo, tak musí komunikaci povolit. A budou odklepávat všechno. Firewally u bfu přestanou mít smysl, jako by nebyly.
> až na to, že většina bfu ani netuší, že by takové problémy měla mít
Mí BFU takové problémy občas opravdu mají.
> Až (jestli) se rozmůže přímá komunikace na koncové kompy, tak to bude bezpečnostní peklo
Kdy byla naposledy v nějakém populárním operačním systému vzdáleně zneužitelná bezpečnostní chyba? V Debianu v 2008, ve Windows taky tak nějak, ne?
- co konkrétně třeba? Tohle ale neni nic co by většinu bfu trápilo, většina bfu hraje onlinovky na nějakém veřejném serveru, telefonujou přes skype a pod a soubory si popsílaj mejlem nebo přes sdílecí servery a nic jim nechybí. To spíš tak bfu co si myslí že nejsou bfu a vrtaj do toho. A ty by si to rozvrtali i bez natu.
- poznámku nechápu, jako že firewall je vlastně stejně zbytečný, když v populárním OS nebyla od roku 2008 žádná pořádná díra nebo co?
> - co konkrétně třeba?
Tak třeba jsem teď zřizoval FTP účet, protože si nedokázali poslat 500MB soubor. Nebo po mně chtějí vzdálenou podporu (kdo tam má furt jezdit), což jsem musel vyřešit tím, že jim pošlu binárku, která se připojí přes dva tunely (jejich NAT - můj server - můj NAT) ke mně. A sledování kamery řeší cracknutým TeamViewerem.
> - poznámku nechápu, jako že firewall je vlastně stejně zbytečný, když v populárním OS nebyla od roku 2008 žádná pořádná díra nebo co?
Ano.
ale ako tomu pomoze IPv6?
naozaj bude end to end konektivita vsade? bez obmedzeni, firewallov po ceste?
Alebo tu budu stale tie iste problemy, len ich nikto nebude riesit na urovni aplikacii (prekopavanie natov, superuzly v p2p, tunelovanie cez treti server), lebo ved kto ma poriadny internet tak nema po ceste ziaden firewall a ostatni sa mozu strcit.
Muzu se zeptat na jediny duvod, proc by nekdo ve firme mel vyhodit zarizeni, ktera evidentne funguji a plni svuj ucel (jinak by je ofc vyhodil uz davno).
Spis bych se nedivil tomu, kdyby vyhodili toho kdo by bez jineho duvodu vyhodil funkci zarizeni.
ad IPV6 tak jak je navrzeno - pak tam pichne Androida, provider mu pres radvd hodi AdvManagedFlag, nasledne mu da pred DHCP6 adresu, wait, jak to vlastne dopadne? Par poslednich mesicu jsem nesledoval, ale obavam se ze to zrovna dobre nedopadne.
> ad IPV6 tak jak je navrzeno - pak tam pichne Androida, provider mu pres radvd hodi AdvManagedFlag, nasledne mu da pred DHCP6 adresu, wait, jak to vlastne dopadne?
Asi stejně jako když si omylem zapneš DHCP server? (viděl jsem jak na Windows, tak na Debianu ještě s původním initem, kde se při apt-get upgrade udělalo /etc/init.d/dnsmasq restart, což ho nahodilo, i když byl zakázaný)
Ať se teda pohnem, poraďte, doma IPv6 přes HE na veřejné IP, vcelku to chodí.
V práci wifi přípojka na 5ce, neválna kvalita, neveřejná IP v síti lokální ISP za dvojitým NATem, "nativní" IPv6 zatím v nedohlednu, je možnost dostat přes tunnel IPv6 i bez veřejné IP?
Na serverech s IPv6 prakticky není problém v datacentrech, nahodit v debianu opravdu otázka minuty, zapamatovat si ip6tables a netstatem v rychlosti zkontrolovat, že provozované služby poslouchají i na "šestce", tím, že servery budou i na 6ce je asi v první řadě nutný předpoklad. F
Bezestavový překlad funguje samozřejmě jen s veřejnou IPv4. Pokud je má síť NAT, pak je potřeba použít službu SixXS a jejich AICCU. Ta si automaticky vytvoří UDP tunel (protokol AYIYA) k nim na server a přes ten tahá konektivitu. Existuje to i pro OpenWRT, mám to nasazené v několika sítích a je to bez problémů. Jen nainstalujete balíček, dodáte mu uživatelské jméno a heslo a konektivita pro celou síť je na světě.
Jeste doplnim, ze se SixXS a AICCU jsou problemy s mobilitou. V takovem pripade nezbyde nic jineho nez pouziti Teredo protokolu (utilita miredo nasmerovana napr. na rychle teredo.nic.cz) spolu s "dynamickou" domenou napr. pres http://freedns.afraid.org . Toto reseni pouzivam na notebooku, se kterym casto cestuji a sem tam se na neho potrebuji pripojit vzdalene pres ssh.
P.S. Muze se to tez hodit, kdyz vam nekdo notebook slohne - viz. vlakno ve vedlejsim clanku http://www.root.cz/zpravicky/jak-lokalizovat-ukradeny-laptop/ .
Teredo ani 6to4 nepoužívejte. Míra rozbitosti je v desítkách procent, nedá se na to spolehnout. Navíc některé Teredo brány se chovají velmi zvláštně a například implementují stavový firewall, který na Teredo adresu nepustí nic, co na ní nezačalo, fakt dobré, když chcete Teredo použít pro vzdálený přístup.
Jinak kromě aiccu - AYIYA tunelu je možné také zavést IPv6 pomocí obyčejné OpenVPN, za předpokladu, že máte někde v IPv4 internetu server s dostatkem IPv6 adres.
Teredo ani 6to4 nepoužívejte. Míra rozbitosti je v desítkách procent, nedá se na to spolehnout.
S Teredo ve spojeni s teredo.nic.cz mam presne opacnou zkusenost - pri cestach po Evrope zatim ani jednou nezklamal (krome ssh sem tam prenasim i soubory se stovkami MB) a byl stabilni. Mohl byste prosim upresnit v cem ta rozbitost spociva? Nebo se poznamka o rozbitosti tykala 6to4 (coz bych chapal - routovani je v tomto pripade casto spatne nastaveno a nespolehlive/nefunkcni)?
Navíc některé Teredo brány se chovají velmi zvláštně a například implementují stavový firewall, který na Teredo adresu nepustí nic, co na ní nezačalo, fakt dobré, když chcete Teredo použít pro vzdálený přístup.
S teredo.nic.cz jsem takovy problem jeste nikdy nemel. Kdysi jsem zkosel i jine servery, ale ceskemu CZ.NICu verim asi nejvice (znam se s nekterymi osobne).
Ano, zkoušel jsem teredo.nic.cz, bylo to Raspberry Pi kdesi v ČR za devatero NATy a primárním cílem použití Tereda bylo dostat se na něj z nativního IPv6 internetu za účelem dálkové zprávy. Spojení zahájené z Raspberry prošlo, spojení zahájené z IPv6 internetu nikoli. Takže pro původní účel nepoužitelné.
Routování Tereda probíhá stejným principem jako routování 6to4. Servery Teredo se ho neúčastní, ty slouží jen jako rendez-vous bod. V každém směru se může použít jiná brána a ty brány mohou být rozbité, čímž se celé spojení rozbije. Jako uživatel to nastavením svého klienta nejste schopen ovlivnit, jde jen o to, na čí bránu zrovna narazíte.
Ano, tohle je obecny problem technologii 6to4. Pokud se pro ni uzivatel rozhodne, vi, ze cim dale je od patere, tim vetsi pravdepodobnost chybneho routovani - prijde mi ta pravdepodobnost ale naprosto srovnatelna s jakymkoliv jinym routovacim problemem, tedy urcite bych toto podezreni nevazal na 6to4 technologie, nybrz napr. na tu vzdalenost od patere.
Pokud Vase Raspberry Pi bylo staticky umistene daleko od patere, pak Teredo neni optimalni reseni. To, co jsem navrhoval se hodi pro mobilni zarizeni jak jsem uvedl hned v uvodni reakci.
Tedy uznáváte, že váš argument „CZ.NICu věřím asi nejvíce“ není vůbec relevantní ke spolehlivosti protokolu Teredo jako celku.
Jinak použití Tereda pro osamocený stroj za NATy mi připadalo právě jako ideální. Nechtěl jsem kvůli tomu zřizovat někde konfigurovaný tunel, myšlenka byla, že použiju jen službu DynDNS pro udržování aktuální Teredo adresy. Bohužel, když vám brána blokuje příchozí provoz, celé to nedává vůbec žádný smysl. Je to vlastně taková IPv6 adresa, která se chová, jako by byla za NATem :)
Muzes pouzit jinej typ tunelu - trebas nic https://www.nic.cz/ipv6/
Již před několika lety se mi v souvislosti s IPv6 do ruky dostaly nástroje z thc.org/thc-ipv6 a od té doby nepozoruji ve standardu IPv6 žádnou změnu. Ano, IPv6 má silné bezpečnosti nedostatky přímo na úrovni protokolu, tedy ve standardu - viz. např. útoky z repozitáře níže (postarší ideologičtí pánové ze standardizační komise nebyli za posledních 7 let či více let schopni se dohodnout na změnách, protože na nejvyšší úrovni nestačí v hlasování nadpoloviční většina, nýbrž všichni do jednoho musí být za jedno; netuším, zdali se tento princip za posledních pár let nezměnili, ale před pár lety to bylo takhle).
Máte zde někdo aktuální informace kolik vektorů útoku např. z těch 26 dostupných v repozitáři https://github.com/vanhauser-thc/thc-ipv6 se již na většině existujících a nově nasazovaných IPv6 sítích NEdá realizovat?
Dle mně dostupných informací se stále dají realizovat na drtivé většině IPv6 sítích všechny (a pozor, jsou tam i útoky, které jako vedlejší efekt totálně položí i IPv4 v případě dual-stack, což je dnes nejčastější zapojení). Zbrusu nové útoky v tomto repozitáři dokonce za poslední měsíce přibývají.
Budu moc rád, když mě vyvedete z omylu a předáte přesnější informace o tom, že se drtivá většina zmíněných útoků téměř nikde již využít nedá.
Dokud však byť jenom 5% těchto vektorů útoku bude na více než 5% IPv6 sítích použitelných (a to se bavím jak o lokálních, tak o WAN aj.), zcela odmítám jakékoliv nasazování IPv6 do seriózního provozu. Času na vyřešení bezpečnostních připomínek a problémů (včetně kvalitních navrhovaných řešení) měla standardizační komise více než dostatek, a tak nehodlám být nyní bitý za jejich neschopnost a ideologické přemýšlení.
Požívám zcela běžně z řady platforem, kde se komunikuje mezi ULA a globálníma adresami a nebyl s tím problém.
Přesněji je to tak, že Pv6 má inteligenci a jako zdrojovou adresu volí tu blíže k cílové, takže když má klient ULA a globální, tak spojení na globální jde z globální a na ULA z ULA, ale pokud má jen ULA a má se spojit na globální, tak to normálně zkusí. Je až věcí hraničního firemního routeru, že nepusít ULA adresy ven.
Máme firmu interně na ULA adresách a servery nv DMZ zónách na a globálních (interní klienti nesmí většinou přímo do Interneut, takže mají jen ULA adresy) a vše šlape jak má už pár let.
Zase jeden debilní propagandistický článek.
Kdyby IPv6 nebyla překombinovaná sračka, už dávno IPv4 nahradila. Jenomže bohužel se vývoj IPv6 raději řídil dementní ideologií („NAT je zlo, musíme udělat všechno proti tomu, aby v IPv6 byl NAT možný“, atd., atd.), takže ve svém důsledku vznikl paskvil...
NAT vznikl a existuje jen proto, že není dostatek adres pro všechna zařízení. IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít? Jen by mi komplikoval život a dělal úzké hrdlo.
A v čem je IPv6 překomplikovaný? Já mám pocit, že tyhle věci opakují jako mantru lidé, kteří si na šestku nikdy nesáhli. Někde to zahlédli na nějakém fóru, tak to musí být pravda.
> NAT vznikl a existuje jen proto, že není dostatek adres pro všechna zařízení.
Jo, tak Vám ten mozek pěkně vymyli. Samozřejmě, že s takovýmto _straw_man_ je jednoduché všem vnucovat, jak že je to IPv6 nenahraditelné.
Skutečnost je ale totálně odlišná. NAT (lépe řečeno maškaráda) vznikl(a) a existuje proto, aby se stroje v určité síti tvářili jako jeden stroj. A to může mít 1000+1 důvodů. Tak se probuďte a přestaňte být tak ideologicky zabedněný!
Třeba když chci mít pod jedním DNS názvem víc služeb, které dělá obecně víc backendů, jak to udělám bez NATu?
(však load ballancing není nic jiného než generalizace NATu)
Protože obecně to, že servery které nejsou internet facing nejsou routovatelné z internetu přináší další ochranu (možná se budeme lišit v hodnocení jak velkou)? (když se někdo někde uklikne a povolí omylem Any-Any, tak se v případě maškarádované sítě nic neděje, sice "NAT není firewall", ale on ten paket skončí v reálnějším scénáři na CE routeru, kterej ho stejně pošle defaultou zase ven, zatímco u plně routované sítě je malér okamžitě)
Díte pod jeden DNS název víc IP adres. Na rozdíl od řešení s NATem tam pak nebudete mít single point of failure. Je pozoruhodné, že NAT obhajují lidé, kteří neznají ani základní věci.
To, že nějaký server není routovatelný z internetu není vlastnost NATu, naopak NAT se používá pro řešení tohohle problému. A to, že to zařízení není routovatelné z internetu je často jen ničím neopodstatněná domněnka.
když se někdo někde uklikne a povolí omylem Any-Any, tak se v případě maškarádované sítě nic neděje
Ale děje. Navíc pokud se někdo takhle uklikává, nezachrání ho ani fyzické odpojení počítače od sítě…
on ten paket skončí v reálnějším scénáři na CE routeru
A nebo skončí na cílovém počítači, protože útočník předem z kompromitovaného počítače ve vnitřní síti udělal tu správnou díru do NATu.
Vždyť jsem vám to psal. Chcete víc backendů – máte třeba 10 Apache serverů, na kterých běží nějaká aplikace. Když máte backend, budete chtít asi nějaký frontend, nejspíš na rozvažování zátěže. Z pohledu uživatele je to jeden frontend s jedním DNS názvem, vy chcete, aby to bylo více služeb, asi na různých zařízeních s různou IP adresou. Tak do DNS pod ten název dáte několik A a AAAA záznamů. Pokud by se jednalo o e-mail, dáte tam několik MX záznamů, pokud třeba o Jabber, bude tam několik SRV záznamů…
Ja som to pochopil tak, ze sa snazi dosiahnut nieco taketo: http://www.ideaz.sk/~bwpow/47/scr/loadbalancer.png
Ma proste nejaku mnozinu serverov, pricom na tych serveroch bezia rozne sluzby. Ma pred nimi router, ktory je dostupny pod domenovym nazvom a konkretnou IPv4/IPv6 a mal by robit load balancing tym sposobom, ze by na zaklade protokolu a portu presmeroval packet na jeden zo serverov, ktory tu konkretnu sluzbu (protokol a port) je schopny spracovat. Na presmerovavanie by mohol pouzit napriklad iptables s modulom statistics. Vdaka tomu vie dynamicky reagovat na zmeny v poskytovanych sluzbach a beziacich serveroch prakticky okamzite. Samozrejme aj tych "prednych" serverov moze byt vela a ich IP by boli prave ako multi zaznamy v DNS.
Ach so. Pak je samozřejmě otázka, zda je dobrý nápad všechno to schovávat pod jeden doménový název. Řešit se to dá aplikačním proxy serverem, routováním i NATem, nejlepší je podle mne ale použít různé DNS názvy. Třeba proto, že když někdo bude DDoSem útočit na web server, není nutné, aby tím rovnou sejmul i všechny ostatní služby.
Ja som to pochopil tak, ze sa snazi dosiahnut nieco taketo: http://www.ideaz.sk/~bwpow/47/scr/loadbalancer.png
Ano, druhý nejpitomější návrh, co se dá vymyslet... hned po tom, kde se se místo somehost.somedomain použije pouze somedomain.
LOL - útočník z kompromitovaného stroje ve vnitřní síti udělá díru do NATu... a proto je ochrana perimetru na nic. Další komentář netřeba.
Dám do DNS víc adres - aha, a z těch 10 IPček bude 9 vracet rst na portu 22, jiných 8 bude házet reset na 25, pět z nich na 80+443. Opět, radši bez komentáře.
IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Tak v korporátních sítích se jich najde dost. Třeba ten, že mají více poboček připojených přes lokální ISP a propojených VPN tunely a chtějí mít vlastní systém rozsahů IP podle poboček/měst/států a ne podle toho jakou IP jim v daném míste přidělí ISP. Tam se potom bez NATu (klidně statického 1 k 1) neobejdete.
Boze ... a nejaky duvod? Aspon JEDEN? Aha, naprosto zadny.
Pokud budu mit 158 pobocek tak to porad nemeni nic na tom, ze budu uvnitr mit verejny IPcka, a pokud je mi zatezko mit 158 rozsahu, ... ahhh stejne MUSIM mit 158 rozsahu. Ale pak uz je mi uprdele, jestli budou vsechny zacinat 1111:1111:1111 nebo kazdej jinak, zejo?
A i pokud vyznavam boztvo jednoho prefixu, tak to nemeni naprosto nic na tom, ze zadnej NAT proste nepotrebuju. Poridim si proste bud PI nebo vlastni AS, adresy si pridelim jak se mi bude chtit ... a providerum pres BGP poslu vzdy tu cast, ktera je v dany siti dostupna ...
...zazrak...
Mno a pokud sem velka korporace, tak mam stejne i vlastni kabely, a stejne se z tech pobocek nikdo nedostane na net jinak nez pres 1-2 uzly po svete, takze zase mam uvnitr zcela normalni verejny IPv6 adresy a na tech uzlech firewall, kerej resi co se smi a co ne.
... nemozny ... nikde zadnej ani jeden jedinej NAT.
IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Tak v korporátních sítích se jich najde dost. Třeba ten, že mají více poboček připojených přes lokální ISP a propojených VPN tunely a chtějí mít vlastní systém rozsahů IP podle poboček/měst/států a ne podle toho jakou IP jim v daném míste přidělí ISP. Tam se potom bez NATu (klidně statického 1 k 1) neobejdete.
On vůbec multihoming (resp. backup konektivita) menších sítí (tedy bez možnosti AS/BGP) se lépe řeší tím NATem. Představa, že při přepnutí linky mi celou sítí probublává SLAAC a mění adresy mě docela děsí. Ale existují lidi, co je to neděsí ...
NAT 1:1 je tedy podle mě v určitých situacích dobré řešení. A jelikož je statický, tak dopady na výkon nejsou v podstatě žádné.
Mně teda NAT nepřipadá jako řešení záložní konektivity, spíš je to taková berlička, která umožní záložní konektivitu využít alespoň nějak. Vždyť s NATem tam máte single point of failure, při výpadku konektivity se nikdo nedostane po záložní lince dovnitř, rozpadnou se všechna navázaná spojení… Když nepoužijete NAT, ale zařízení budou mít normálně IP adresy od obou ISP, při použití SCTP výpadek jedné linky ani nezaznamenáte, pro TCP bude stačit znovu navázat spojení (z venku i zevnitř).
Je zajímavé, jak často dělají s NATem lidé z nouze ctnost a neumí si řešení bez NATu ani představit.
Kazda diskuse o IPv6 zrejme drive nebo pozdeji skonci u reseni multihomingu pomoci adres od obou ISP. To je postup, ktery spolehlive nefunguje, nebot:
1) Kdyz vypadne jedna linka a prislusny router prestane announcovat RA do site, tak ho sice klienti prestanou povazovat za default gateway, ale to neovlivni platnost pridelenych adres.
2) Autokonfigurovane adresy jen tak nevyprsi, protoze minimalni lifetime je 2 hodiny.
3) V algoritmu vyberu zdrojove adresy hraje default gateway (a dostupnost jednotlivych bran) jen malou roli, takze klient, maje adresy z obou prefixu, i pri dostupnosti obou linek muze vybrat zdrojovou adresu od 'zalozniho' ISP a pri vypadku primarni linky adresu 'primarniho' ISP.
4) pouzita adresa a pouzita gateway jsou obecne nezavisle, takze klient muze pouzit zdrojovou adresu od ISP A a poslat to na gateway smerem k ISP B. Aby to fungovalo, tak brany o sobe musi vedet a predavat si vzajemne odchozi traffic podle zdrojove adresy.
5) I kdyby se body 1-4 vyresily, tak by to cele fungovalo jen na ploche siti, kde jsou klienti a brany na jedne linkove siti. Pokud ma sit vnitrni strukturu a vnitrni routery, tak by byl treba jeste nejaky dalsi protokol, rozsireni ci mechanismus, ktery by propagoval informaci o vypadku prislusne brany a ovlivnoval to, jake RA budou propagovat routery ve vnitrni siti. Existuje treba wg homenet, ktera by takove veci chtela resit pomoci rozsireni do routovacich protokolu, ale to je zatim spis experimentalni zalezitost.
To, že algoritmus výběru zdrojové adresy jde navrhnout tak, aby klidně vybral adresu od nedostupného operátora, neznamená, že se to tak musí dělat. A i když to tak někdo implementuje, neznamená to, že je to dobrá implementace.
To, že použitá zdrojová adresa a použitá brána jsou obecně nezávislé neznamená, že nejde zařídit, aby byly závislé. Ostatně běžně se to řeší i v multihome IPv4 sítích. Navíc to, že pakety se zdrojovou adresou od ISP A pošlu přes síť ISP by nemělo ničemu vadit, naopak, internet byl navržen tak, aby tohle bylo možné dělat. Pokud nějaký ISP místo zajištění bezpečnosti dělá hlouposti, může s tím mít problém, ale to je problém toho ISP, ne problém koncepce.
Multihoming se na internetu řešil odjakživa, to není žádná specialita IPv6.
IPv6 přináší spoustu nových možností, takže s postupným rozšiřováním budou vznikat i nové standardy, třeba pro snazší řešení multihomingu, aby si to každý nemusel dělat na koleně.
> To, že algoritmus výběru zdrojové adresy jde navrhnout tak, aby klidně vybral adresu od nedostupného operátora, neznamená, že se to tak musí dělat. A i když to tak někdo implementuje, neznamená to, že je to dobrá implementace.
Navrhnout a implementovat lze ledacos. Pokud ale mam heterogenni sit a nechci soustavne resit, proc to nekterym klientum dobre nefunguje, tak musim vychazet z toho, jake klientske chovani je predepsano standardem a take jak se chovaji bezne implementace. A tam plati to, co jsem psal vyse.
> Navíc to, že pakety se zdrojovou adresou od ISP A pošlu přes síť ISP by nemělo ničemu vadit, naopak, internet byl navržen tak, aby tohle bylo možné dělat. Pokud nějaký ISP místo zajištění bezpečnosti dělá hlouposti, může s tím mít problém, ale to je problém toho ISP, ne problém koncepce.
Naopak, ingress filtering zdrojovych adres podle routovacich informaci je AFAIK povazovano za best current practice (viz RFC 3704). Ze to spousta siti nedela, je jina vec.
> Multihoming se na internetu řešil odjakživa, to není žádná specialita IPv6.
Bezny multihoming propaguje adresy pomoci BGP, takze site po ceste vedi, ze provoz z danymi zdrojovymi adresami muze prijit z daneho smeru a je tedy povazovan za legitimni (feasible path RPF).
Krom toho, kdyby napr. behem vypadku linky od ISP A pakety se 'spatnou' zdrojovou adresou (tedy tou od ISP A) dosly nakrasne pres ISP B az k cili aniz by je nejaka sit po ceste odfiltrovala, tak cil odpovi na tyto 'spatne' adresy a odpoved tedy pujde cestou k ISP A, ktery je kvuli rozbite lince nemuze dorucit do multihomingove site.
Pokud ale mam heterogenni sit a nechci soustavne resit, proc to nekterym klientum dobre nefunguje, tak musim vychazet z toho, jake klientske chovani je predepsano standardem a take jak se chovaji bezne implementace.
Který standard definuje, že klient musí počítat s tím, že někdo bude modifikovat IP adresy v jeho paketech?
Naopak, ingress filtering zdrojovych adres podle routovacich informaci je AFAIK povazovano za best current practice (viz RFC 3704).
To, že je něco považováno za best current practice, neznamená, že je to správně.
Krom toho, kdyby napr. behem vypadku linky od ISP A pakety se 'spatnou' zdrojovou adresou (tedy tou od ISP A) dosly nakrasne pres ISP B az k cili aniz by je nejaka sit po ceste odfiltrovala, tak cil odpovi na tyto 'spatne' adresy a odpoved tedy pujde cestou k ISP A, ktery je kvuli rozbite lince nemuze dorucit do multihomingove site.
Což není vůbec žádný problém, protože při výpadku ISP A by se odesílatel měl snažit nepoužívat jeho zdrojové IP adresy. Podstatné je, aby to fungovalo, když je linka ISP A aktivní.
Ad 1/2) Při výpadku jendé konektivity se udělá to, že se pošle preferred time 0, klientiu přestanou dané IP okmažitě používat.
Ad 3) Na totoje dneska již specifikace, aby se upřednstňovala zdrojová IPv6 adres adle brány s vyšší prioritou, ale asi to nic moc neumí.
Ad 4) Ano, klientui obvkyle jen použijí bránu s vyšíš prioritoua přeposlání mezi branami není problém, pokud to umí routery (linux dneska už policy routring pro IPv6 zvládá), aby to odešlo správnou linkou
Ad 5) Ano, ICMP/mechanismus pro rychlé přešíslování existuje, ale jak moc je podporován, to netuším.
Na síti, kde už ke hormada routerů, tak půjde už o velkou záíležitost, která to asi může řešit již metoudou vlastního AS, PI bloku adres a nepřečíslovává. Kde si vystačím s menší sítí, tak přečíslování funguje. Máme nasazeno a bez problémů na routerech od Mikrotiku přes několik poboček a v několika firmách, a tam je ta IPv6 ještě dost ochuzena o možnosti, ale i tam to jde udělat a funguje to. Interně se jede na ULA adresách a k tomu má klient globální adresu dle prioritní linky. Při výpadku se přečísluje na záložní (ULA zůstává) a jede se dál.
> Ad 1/2) Při výpadku jendé konektivity se udělá to, že se pošle preferred time 0, klientiu přestanou dané IP okmažitě používat.
Ano, explicitni odebrani prefixu ma vetsi sanci fungovat, nicmene i tam jsou pripady, kdy se to muze rozbit (napr. kdyz se router restartuje a po restartu nenabehne linka, vi, ze ma propagovat nejaky prefix s preferred time 0?) a je to IMHO daleko krehci reseni, nez pouziti NPT.
> Na síti, kde už ke hormada routerů, tak půjde už o velkou záíležitost, která to asi může řešit již metoudou vlastního AS, PI bloku adres a nepřečíslovává.
No, to muze byt i jen par wifi AP, ktere jsou nastavene v router rezimu. Zda je sit plocha nebo kosata a zda je velka nebo mala jsou IMHO vicemene nesouvisejici parametry.
Od toho jsou checking objekty, router si testuje pingem/BFD/... uplink a jeho funkčnost, ví jaký prefixy k tomu patří a dle toho případně i hned při startu začne na preffered time 0. Udělat explicitn odebrání (valid time 0) je ještě brutálnější. Ale co tuto techniku používáme v provozu tak 3 roky, tak s ní problém není. Rozhodně si nepamatuji, že by o duživatelů šla stížnost/report, že jim nefunguje síť, kde by byla chyba v tom, že měli IPv6 globální adresu od mrtvé linky.
Pokud s ohledme na IPv6 někdy je problém, tak je to Windwos 7+ a jména DNS serverů. Pokud je Win7 klient v síti, která mu přidějí i IPv6 adresy DNS serverů (přes bezestavové DHCPv6) a pak se přesune do jiné sítě, kde běží IPv6, ale nedojde k předání IPv6 adres serverů, tak mají snahu používat stále tu starou sadu z předchozí sítě, ale tohle je chyba Win7.
Dobře, máme velkou síť (centrálu firmy), která jede metodou PI IPv6 bloku a ASka, což je cca 3 kKč/rok plus jendorázově více na start více (zd eje větší problém sehnat v místě dvě nezávisl konektivity přes ISPíky ochotné k BGP). Druhý koenc je SOHO, kde je to nesmysl, tak má dvě linky a použítá třeba ten hot renumbering.
Pokud chceš třetí střední velikost, která má už kaskádu pár routerů a nemá přiotom vlastní AS, tak i zde je řešení, pokud se síť konfiguruje pomocí DHCPv6-PD. Zkrátka pokud dojde k přečíslování u hlavního routeru, dojde k propagaci nových segmentů dolů přes DHCPv6-PD servery na jednotlivé routery. Nezapomínejme, že u DHCPv6 je už na rozdíl od DHCPv4 metoda, kdy server může dle potřeby kontaktovat klienta a sdělit mu novinky ohledně jeho dynamického přídělu, tak mu ho sebere a pošle nový. Nicméně přiznávám, že jsem neviděl takové řešení živé v praxi. Obvkyle z důvodů, že většina současných DHCPv6 implementací nemá impmentován kanál pro dodatečné "obtěžování" klientů. Ale je to asi otázka času, až to někdo do krabic namlátí. Dneska i na SOHO krabičkách od Mikrotiku tohle udělám, že hlávní router přes DHCPv6-PD od uplinku vezme blok, zapropaguje k podřízeným krabičkám a DHCPv6-PD servery/klienti to postupně se naučí a vyberou segmenty z přídělu a nasadí je a funuje to, ale není tam ta podpora pro změnu, obnovují příděl jen na restart/vypršení platnosti.
1) delat backup pres mutihome je hovadina, coz neznamena, ze to nejak nebude fungovat
2) adresy lze vpohode stahnout, protoze router posle info a klienti je zahodej
3) ..
4) src z jinyho rozsahu zcela bez potizi odejde (i na IPv4), specielne kdyz o tom ISP vi.
=> zadny problem 1-4 neexistuje, protoze zalozni konektivita se resi za pomoci PI nebo vlastniho AS a plnotucnyho routovani s BGP. Coz zaroven znamena, ze netreba mit v siti vic rozsahu.
Dělat backup přes multihoming není blbost, ale i původní představa autorů IPv6. Pokud je to koncová síť, která se spojuje ven, tak multihoming s přečíslováním je původní představa autorů IPv6.
Později to Cisco doplnilo o představu použití NPT (což už je ten fuj bezestavový NAT), aby v síti nemuselo být víc prefixů.
Tohle je pro ty situace, kdy dneska je tam skoro SOHO router krabička s dvěma WAN porty, kdy to dle potřeby na IPv4 NATne na linku vlevo-vpravo.
Metoda PI IPv6 blok a AS je až pro větší subjekt, už jen proto, že to něco stojí na poplatcích RIPE, provozu BGP atd. Takže ot je řekněme pro subjekt, co má být trvale dostupný ze světa.
A k tomu "src z jinyho rozsahu zcela bez potizi odejde (i na IPv4), specielne kdyz o tom ISP vi.", tak na to bych obecně se nespoléhal ani v případě, že o tom mů ISP víc, pokud daný ISP není i tranzitní pro další sítě, tak jeho uplinku dneska zcela reálně to mohou blokovat opět, že pustí jen IP z přídělu a nic jiného. Aneb dodržování BCP38 může být v tomto případě prevít. Takže je dobré se pak u takové multihomed sítě držet BCP84. :-)
> On vůbec multihoming (resp. backup konektivita) menších sítí (tedy bez možnosti AS/BGP) se lépe řeší tím NATem
Pokud mam ve vnitrni siti verejne adresy a nemusim mit NAT uz kvuli privatnim adresam, tak je reseni pomoci vlastniho AS a BGP jednoduche a relativne levne - poplatky RIPE jsou celkem 100 EUR rocne za ASN a PI prefix (+ to, co si prihodi LIR/ISP).
Nicmene souhlasim, ze pouzit NAT 1:1 je rozhodne lepsi reseni nez resit zalohu 'preadresovanim'.
Mne tu minule v diskusii k IPv6 tvrdili, ze "gud praktis" je mat viac IP adries na rozhrani. Jednu na vnutorne adresovanie po VPNke a druhu od lokalneho providera. Ak bude providerov viac, tak mat proste tych adries viac a ono sa to uz tymi IPv6 mechanizmami poriesi, ked nejaka cesta vypadne. Pride mi to ale absolutne zvratene.
> IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Jděte už s těma vašema pseudoargumentama. Proč bych chtěl NAT mít? Protože např. ztěžuje špehování uživatelů, znemožňuje jednoduše spočítat, kolik strojů je za NATem, zvyšuje bezpečnost, atd., atd... Důvodů je spousta, počet IP adres je ten nejmenší...
>jak bys to udělal ty.
napriklad:
a) rozsirit dlzku adresy IPv4, tak, ze 173.194.112.7 by bolo ekvivalentne s 0.0.0.0.173.194.112.7 a prefixov by bolo na rozdavanie
b) ked moze byt Q-in-Q tak preco nemoze byt IPv4-in-IPv4 ? zariadenia po ceste to ani nemusia podporovat, len tie na hraniciach
a) v tom ze je to stale IPv4 len ma dlhsiu adresu, takze implementacia podpory je omnoho jednoduchsia, netreba vymyslat nejake prechodne mechanizmy, lebo je to spatne kompatibilne a podobne
b) pretoze na hraniciach sa prechaza mezi IPv4 a IPv6 sietou ktore su nekompatibilne, tu by sa len vybalil paket z vonkajsej obalky a dalej by isiel zase IPv4
1) nie, pripojovali by sa stale na tie povodne sluzby pomocou povodneho ipv4 bez nutnosti dualstacku
.. boli to prve dve veci co ma napadli, nerozoberam to do detailov, ale moznych rieseni problemu nedostatku IPv4 je vela, niektore lepsie, niektore horsie a co je fakt tak IPv6 ktore bolo vybrane ako riesenie sa nasadzuje pomaly a nasadzovaci akurat fnukaju ze ostatni nenasadzuju a ti co nenasadzuju tak problem nemaju
> 1) nie, pripojovali by sa stale na tie povodne sluzby pomocou povodneho ipv4 bez nutnosti dualstacku
A jak se připojím ze sítě IPv4+ na IPv4 službu, když jí pošlu paket, který má jako SRC adresu „nějakou dlouhou“ a ona mi odpoví na první čtyři bajty? Někde cestou nejspíš bude muset sedět krabice, která to spojení bude sledovat, a odpověď zpátky rozšíří o ty další čtyři bajty. Právě jsem popsal NAT64.
> .. boli to prve dve veci co ma napadli, nerozoberam to do detailov, ale moznych rieseni problemu nedostatku IPv4 je vela
Ne, to, co jsi navrhl, prostě není jednodušší než IPv6. Stejně jako IPv6 to prostě vyžaduje podporu u koncových poskytovatelů a klientů. Nevyžaduje to podporu na páteři, ale s tou právě problém není.
Dalsi placal co zvani o vecech o kterych nema paru. Ta prekombinovana IPv6 redukuje pocer pravidel firewallu (klidne o rad), redukuje pocet zaznamu v bgb (mozna o 2 rady) a umoznuje veci, o kterych si IPv4 muze nechat leda zdat.
A jak bylo receno, existence NATu ma jede jedinej duvod a tim je prave nedostatek adres. Velmi brzo bude ovsem i nedostatek portu, a na ten uz jaksi lek nemame.
Narozdil od tebe nemam uvnitr zadny privatni adresy, ale verejny. A tudiz se neuplatnuje zadny NAT a nemusim resit, z ktery strany paket prijde. Divny co?
Nevsim sem si, ze by se na IPv6 menila adresa paketu cestou pres router, takze je vazne nepotrebuju markovat. Narozdil od jebleho NATu, protoze tam se samozrejme zmeni. Opravdu by me zajimalo, jak by si tvoje malickost predstavovala shapovani 100 lidi ... na jedny IP ...
Chmm ...
wc -l firewall_ipv6
136 firewall_ipv6
wc -l firewall_ipv4
373 firewall_ipv4
Jeden router, obe dela presne totez. Pomerne jednoduchy nastaveni, zadny slozitosti.
ipsec nic? muticast nic? mobility nic?
Ale jo, on je urcite kazdej provider stestim bez sebe, kdyz dou vsici sledovat nejakej fotbal/hokej/... a tech rekneme 5Mbit mu do site leze bambilionkrat. A stejne tak je nadsenej z toho, kdyz misto aby si to porno vymenili mezi sebou, tak ho nejdriv tlacej na ulozto, a pak sosaj zpet.
> redukuje pocet zaznamu v bgb (mozna o 2 rady)
Na globalni urovni tak maximalne o jeden rad. V globalnich BGP tabulkach je ~580k IPv4 prefixu a ~50k ASNs. Takze i kdyby si kazdy AS vystacil jen s jednim prefixem (coz nemusi napr. kvuli traffic engineeringu), tak bychom pri plnem nasazeni IPv6 (a soucasnem mnozstvi AS) meli ~50k IPv6 prefixu.
Vidím to trochu jinak. Drobení je jedna věc, ale to asi pod /24 v BGP nepůjde.
Vidím dneska ale masovku už jinou, a to je tunelování IPv4 křížem krážem. A to hlavně z pohledu poskytovatelů server hostingu a spol.
Nemají IPv4 adresy, tak nakupují klidně malé bloky ud od /28 a tunelují je, takže když pronajmu takto část svých IPček, tak se nepublikuji v BGP, ani si hosting nedá servery do mé sítě, ale zkrátka je ze své sítě pošlu přes GRE tunel k hostingu a občas je sranda vidět, kudy a jak se ten paket ve skutečnosti motá v celkové trase.
Takže pomalu začíná IPv4 svět postihovat takto to, čím trpěl IPv6 v době tunelovaní z místa na místo, než zaačo nativní transport stoupat.
Zkrátka se cesta prodlužuje, jak je neoptimální routing, často prochází přes celkem "tenké" linky u koncových ISP tam a zpět, kteří takto poskytli své nadbytečné IP, občas stále do toho pak zasáhne problém zkráceného MTU, pokud je použit holý IPIP/GRE, ..
Jak už jsem psal výše, těch důvodů je více než jen nedostatek IP. Hlavně v korporátních sítích, kde jsou pobočky v různých lokalitách připojené přes různé ISP a propojené VPN tunely a chtějí mít vlastní management IP adres podle třeba pobočky/města/státu bez ohledu na IP které přidělí ISP. Další věc je redundance přípojek od různých ISP do jedné pobočky (= různé prefiy IP) tak, aby nezáleželo na tom, přes kterého ISP se komunikuje
Korporáty, které mají více poboček a chtějí mít adresování ve vlastní režii, jsou ideálními kandidáty na získání vlastního bloku adres a vlastního AS.
V jednotlivých pobočkách pak skrze lokálního ISP anoncují tu část svého bloku adres, která patří té které pobočce, mezi pobočkami jim může běhat třeba Site-To-Site IPSEC. Takže se jim to chová přesně jako ta stávající privátní síť, včetně VPN tunelů, přitom ale mají jen jednu sadu adres na všechno…
Ostatně, tohle přesně řeší třeba Kaufland, jehož člověk stojí za návrhen uvolnění pravidel RIPE pro podmínky alokace IPv6 adres. Ty totiž dříve reflektovaly jen „očekávaný počet zákazníků“, což je sice dobré měřítko pro ISP, ale na velké korporáty, které chtějí adresy hlavně pro sebe, se to vůbec nehodí.
Len k tej podpore hardveru: Cisco doteraz nepodporuje v6 na svojej vlajkovej lodi Catalyst 6500, konkretnejsie na firewall module, ktory je zapojeny vo failover mode. Poziadavku eviduju niekolko rokov, medzi tym uz modul prestali predavat, ale je masivne nasadeny a pouzivany.
Přiznávám, že diskuze šumí kolem mé hlavy, a ne vše pronikne dovnitř. Nicméně jsem chtěl vstoupit do vod IPV6 - na domácím VDLS routeru Comtrend (O2) je aktivní i ipv6 adresa. Takže jsem na počítači ipv6 povolil a naopak ipv4 zakázal. Výsledek?
a) vše fungovalo jako dřív
b) část serverů nebyla dostupná
c) nefungovalo nic
C) je správně!
Je otazka, proc nefungovalo nic, dneska je uz pomerne velke mnozstvi webserveru IPv6-ready. Hadal bych problemy IPv4-only DNS v pocitaci, routeru ci O2.
Nicmene obvykly scenar prechodu na IPv6 nepocita s vypinanim IPv4 na koncovych strojich, ale s dual stackem. Proste se jen zapne IPv6, zatimco IPv4 zustane stale nastavene.
Evidentně nejste to správné IPv6 sluníčko, protože jinak byste takové věci nemohl tvrdit.
Krása IPv6 je v tom, že má řešit nedostatek IPv4 adres, které ovšem ovšem potřebujete i když máte IPv6.
To je asi jako kdybyste nastoupil do nové práce abyste měl víc peněz, ale výsledek by byl, že musíte chodit do obou a plat máte stejný jak v té původní. Jo abych nezapomněl - budou vám tvrdit, že do té původní třeba možná někdy budete moci přestat chodit.
Alternativa k tomu je jaka? Za desatero NATy s IPv4 na vecne casy a nikdy jinak? A co s tema nestastnikama, kteri by fakt potrebovali verejnou adresu? Udelame nejakej dalsi genialni plan na odebirani adres velkym firmam, univerzitam a podobnym, kteri maji z minulosti nasysleno? A planovana udrzitelnost takovyho systemu bude na deset, dvacet, sto let? A pak co? Jednou ten moment, kdy ctyri miliardy adres prestanou stacit, urcite prijde. Ze by se potom uz konecne podarilo vymyslet, jak rozsirit adresni prostor pridanim patyho cisla k soucasnym ctyrem tak sikovne, aby s tim dokazaly pracovat i IPv4-only zarizeni, ktery nic jinyho nez ctyrbajtovou adresu neuznavaj? Zatim se nam takovou pokrocilou technologii vymyslet nepodarilo, ale za tech sto let, kdo vi... ;)
Bezesvy zpusob je prave dual-stack. Tedy pouziti IPv4 a IPv6 zaroven. Pro BFU to znamena, ze kdyz zapoji router a pocitac, tak bez jakekoliv konfigurace (pokud je u obou IPv6 defaultne aktivovano, coz u pocitacu je, jaka je situace u soucasnych routeru nevim, ale v principu by v tom nemel byt problem) mu IPv6 zacne fungovat, jakmile to ISP nasadi a zacne delegovat pres DHCP.
Přiznávám, že diskuze šumí kolem mé hlavy, a ne vše pronikne dovnitř. Nicméně jsem chtěl vstoupit do vod IPV4 - na domácím ethernetovém routeru TP-Link (UPC) je aktivní i ipv4 adresa. Takže jsem na počítači ipv4 povolil a naopak ipv6 zakázal. Výsledek?
a) vše fungovalo jako dřív
b) část serverů nebyla dostupná
c) nefungovalo nic
C) je správně!
Podobný pokus z testovacích důvodů občas dělám i na pár lidech, že jsou v IPv6 síti pouze. A mám-li říci pravdu, tak dneska už řada lidí by na IPv6 only síti ani nepostřehla, že nemá IPv4, k dokonalosti chybí snad jen ty porno servery a nějaký český bulvár (ihned.cz a novinky.cz zatím většinu neuspokojí).
Jsme sdruzeni, sdruzujeme asi 2000 lidí a na vetsine pripojek jiz IPv6 bezi.
Drobny problem je s pripojkami ktere konci na zarizenich nekterych clenu , typicky starsi TPlinky. U tech pocitam budeme muset pockat az bude na IPv6 nejaky obsah na ktery se nedostanou jinak, to je primeje stare zarizeni vyhodit a poridit nove ktere v6 podporuje.
Naklady byly cca 2 tydny jednoho cloveka .
TJ zadna hruza ...
Hypotetická otázka - který poskytovatel obsahu si může dovolit jet pouze na ipv6? Ti zavedení už (zřejmě) mají zavedené obojí, ti noví potřebují prorazit, a tedy nemohou ignorovat většinové zákazníky. Prostě pro přechod na ipv6 stále chybí impulsy. Bzw, taky mám starý (nooo) TP-Link WR1043ND, ve verzi V1, pro kterou výrobce podporu V6 neplánuje - prý až od verze V3.
Amazon AWS
Microsoft AZURE
Google Cloud
to jsou vsechno pekne ukazky, ze postavit server s IPv6 v cloudu je dnes snadne. Nebo ne?? Dokonce velky propagator IPv6, fy Microsoft stale IPv6 v AZURE nepodporuje! A uz narazil na nedostatek IPv4 adres, stale vsak IPv6 neni podporovano. Ale pry na podpore IPv6 intenzivne pracuje...
http://stackoverflow.com/questions/31581816/ipv6-support-for-azure
Nasledujci clanek napsal clovek z McAfee. Bezpocnosti moc nerozumim, takze predpokladam, ze jen chce vydesit zakazniky aby jim pak mohl prodat sve produkty. Takze by jsem ty informace nebral prilis vazne...
http://www.computerweekly.com/feature/IPv6-The-security-risks-to-business
Tak tech bezpecnostnich problemu tam neni zrovna malo, viz. nedavna serie clanku na rootu: http://www.root.cz/serialy/bezpecne-ipv6/
> Bohužel se ukazuje, že IPv6 tyhle problémy nejen že neřeší
a) Tyto problémy podle mě řešit nejde a vyplývají z toho, že se to provozuje na L1/L2 bez jakékoli bezpečnosti. Ale rád si poslechnu nějaký nápad, jak by to řešit šlo.
b) IPv6 ve skutečnosti dělá dost pro to, aby to řešit šlo, ale konfigurace je pak složitější. Například SeND (kryptograficky podepsaný „ARP“) nebo IPSEC.
IPv4 je sračka. Tečka.