IPv6 je sraččkka. Kdyby IPv6 bylo slušně navržené (ne dogmaticky, ale pragmaticky), už dávno žádné IPv4 neexistuje.
Takto je to jen snaha vnutit uživatelům překombinovaný bastl, který ve svém důsledku zhoršuje bezpečnost a nefunguje o nic líp než IPv4. Je pochopitelné, že o moc velký zájem není.
(NESOUHLASÍM se zpracováním osobních údajů pod ZÁMINKOU přidání názoru do diskuze)
Pokud si dobře pamatuji jak ty "bludy" minule vypadaly, tak prostě jenom jedna hlasitá skupinka nebyla schopná pochopit, že dát domácímu routeru nějakého dědečka veřejnou ip (a tím umožnit jeho přímé adresování) ničemu neprospěje ... No a jak už to tak bývá, tak místo aby takovou adresu dostal každý kdo bude chtít zdarma, když jich má být tolik, tak se to zas musí narvat povinně všem ...
A jak se resi v IPv6 backup pres jineho providera? Mala firma a domacnost dostanou od ISP blok jeho adres (prefix). Ale jiny ISP Vam da zase jiny IPv6 prefix. To znamena, ze bez NAT muste lokalni sit precislovat... Pokud jste hodne velka firma tak muzete pozadat o vlastni, nezavisly, blok IPv6 adres, tam problem neni. Ale co my ostatni, mali a bezvyznamni?? V IPv4 je to snadne, na routeru s NAT se udela drobna zmena konfigurace, pripadne se prehodi ethernetovy kabel a jede se dal, v lokalni siti neni treba nic menit, jen je treba obnovit prerusena spojeni, treba restartovat prehravani videa, atd...
IPv6 počítá s tím, že zařízení má více IP adres. Takže nemusíte nic přečíslovávat, ta zařízení budou mít ty IPv6 adresy od začátku. Nemusíte mít ani jeden router, který může selhat – můžete mít pro každého ISP jeden router, a když jeden spoj vypadne, akorát daný router přestane do sítě oznamovat, že je přes něj dostupný internet.
Takže v IPv4 je to snadné, pro odchozí spojení změníte konfiguraci NATu, pro příchozí máte smůlu. Zatímco pro IPv6 je to komplikované – nemusíte tam udělat nic.
Ono je to velmi jednoduche, kazdy interface moze mat viacero ip adries. Takze najjednoduchsi stav je, ze zariadenia budu mat jednoducho minimalne jednu ip od kazdeho prefixu. Minimalne jednu preto, ze dnes si uz aj tak pytaju viac (jednu cez RA, druhu cez DHCPv6 ak je v sieti, apod). No a okrem toho urcite budu mat este aj link-local adresy.
Link-local adresy jsou nepouzitene, jak jsem byl poucen. U link-local adres je treba take uvadet fyzicky interface aby OS vedel kam ma pakety posilat (protoze vsechny adaptery maji stejny IPv6 prefix, fe80::). Takze adresovani pres link-local IPv6 adresy je slozite, je to nouzovka.
Linkové adresy jsou jednou z nejlepších věcí u 6, škoda, že nefungovaly pořádně i u 4, ušetřilo by to dost sraní typu „donesl jsem si nové zařízení a nemůžu se na něj připojit“, případně se tím dalo dělat propojování zákazníkova routeru s poskytovatelem bez vyplácávání veřejných IPv4 (má to tak IPv6).
A ten test je celkem snadny. Vemte treba Android telefon, pripojte jej do lokalni WiFi a poznamenejte si, jakou ma LL IPv6 adresu, tedy fe80::.....
Pridejte zaznam do /etc/hosts
fe80::c211:73ff:fe3f:632b android1
fe80::c211:73ff:fe3f:632b%2 android2
No, a ted zkuste komunikovat, treba ping6, curl nebo zkuste pouzit WWW prohlizec. A potom muzete zacit uvazovat, zda jsou ty IPv6 LL adresy skutecne tak super...
$ ping6 android1
connect: Invalid argument
$ ping6 android2
unknown host
$ curl http://android1/
curl: (7) Couldn't connect to server
$ curl http://android2/
curl: (6) Could not resolve host: android2
Tenhle váš test je hlavně blbost. DNS resolver nemůže ve své odpovědi vracet identifikátor síťového rozhraní. Ten musíte vy doplnit.
IPv6 LL adresy nejsou všespásnou náhradou adres na "lokální síti". IPv6 LL adresy jsou unikátní právě díky tomu, že tam ten identifikátor rozhraní musí být. Já si např. IPv6 LL aliasy dávám do ~/.ssh/config (tam ten identifikátor už napevno mít můžete) a snadno se tak připojím k jednomu kusu HW, co občas nosím s sebou a připojuju ho do různých sítí.
Jestli vám tahle vlastnost IPv6 LL vadí, tak vám nic nebrání na síti začít propagovat nový přefix, například fd00:1234::/64 (IPv6 ULA), a ten používat místo nějakého 192.168.X.X, jak jste byl zvyklý
A to je prave ten problem. Je to nekonzistentni, nedotazene, blbe navrzeno... Jednim z marketingovych trhaku IPv6 je, ze se sit sama nakonfiguruje, ale jak si s tim zacnete trosku hrat, zjistite, ze musite mit DHCP server, nebo aspon sirit prefix, snazit se dokonce mit unikatni lokalni adresy, atd, atd a myslenka snadne autokonfigurace se stava utopii. LL adresy jsou problem v Linuxu, ve Windows to funguje dobre, tam si muzete nakonfigurovat "embeded device" s WWW rozhranim i kdyz ma jen LL adresu, v Linuxu je to ale velky problem, snad funguje textovy prohlizec Lynx (ten ale neumi Javascript a dalsi rozsireni).
Sice to chodí "tunelem přes čmoud", ale s větší latencí , ale zato s výpadkem, pokud se stane něco v datacentru.
Ale budiž. Další příklad je, že mu děcka dají do baráku kameru, aby se mohli podívat, jestli nemá nějaký problém. A připojit se za CGNAT a NAT z jejich komplu za jiným CGNATem a NATem bez nezabezpečenýho čmoudu v tramtárii je problém.
A bez čmoudu mu nemůžou ani soukromě nasdílet fotky na své síti, zase musí někam na čmoud nebo to zveřejnit.
Takže jste si odpověděl sám. Laikovi je IPv6 naprosto k ničemu, protože na žádné zpřístupňování kamer / fotek na síti / vzdálené správy nemá skill, vesměs dokonce ani netuší, že to vůbec jde a kdyby to náhodou tušil a zkusil to sám, tak by nejspíš vyrobil bezpečnostní díru.
IPv6 je k něčemu pouze pár procentům lidí s dostatečným IT vzděláním. Proto (skoro) nikdo na ISP netlačí, že chce IPv6 a proto postupuje tak pomalu. Dokud tohle nepochopíte, budete nad tím pořád nevěřícně kroutit hlavou.
On to nemusí umět, stačí mít kamaráda nebo v někoho v rodině, kdo to nastaví. A je lepší stav, kdy v případě potřeby jde něco udělat, než řešit rovnáky na ohybák.
Ono je to jako s místem na zaparkování na vlastním pozemku před barákem. Když nemám auto, neublíží. Když mám auto, hodí se to víc, než placený parkoviště za rohem.
Stejně jako s netem. Když je jeho síť vidět zvenku (minimálně router), ušetří to v případě potřeby hodně práce a peněz - obvolávání ISPíka, jestli dá veřejnou IP adresu (= leckdy a příplatek - proč by měl děda najednou platit víc?)
- zřizování VPSky, její nastavování (čas) a placení (proč by měl děda ještě platit za něco, bez čeho se na Seznam dostane?)
Přitom by to šlo často udělat hned, bez dohadování a práce navíc.
Tahle argumentace plave na vodě, stačí jedna veřejná IP ne pro každé zařízení, tj nemusí to být žádný čmoud přes kterej to teče.
Osobně IPv6 podporujeme 100% v produkci ale když občas vidím jaké brikule to bežným BFU přináší tak bych raději IPv5 tj roztaženou o pár byte, kdy by pro BGP byl prostě větší prefix BGP prefixem a bylo by po ptákách. každý ISP z těch IPv4(2) by měl současný celý rozsah stávající IPv4 pro sebe.
Stačí porovnat velikost kumulativní BGP tabulky a vynásobit 10 a jedeme na IPv4v2, počet záznamů by v ní naopak klesl na akceptovatelné miliony.
Třeba matce díky veřejné IP adrese můžu spravovat počítač i bez blbostí typu teamviewer. Až bude starší, nejspíš se tenhle stav nezmění.
Hlavně nechápu že po tom co jsme se dostali do naprosto šíleného stavu kdy NAT je považovaný za default a veřejná IP „luxus“ je najednou možnost že by se z veřejné adresy stala opět norma považována za nějak špatnou. Asi Stockholmský syndrom, jinak si to vysvětlit nedovedu.
"Stanice vystavená přímo do netu má i své nevýhody. Např. když jednou zjistím její IP adresu, tak na ni budu moct cílit už vždy bez nějakého "hledání". To není přímo security ani žádný syndrom, jenom jeden z důsledků ..."
To je pravda, ale pokud bude krabička udělaná dobře, odolá. Dneska se hřeší na to, že tam bude NAT a těžko se útočí cíleně, takže se na bezpečnost tak trochu kašle. Tohle aspoň donutí výrobce dělat to pořádně.
A kdyby po pár průšvihách s únikem dat, DDoSy a šířením malware přišly tvrdý postihy pro dovozce/výrobce (s pokutou ve výší pokut za GDPR), vůbec bych se nezlobil.
No ale v domácí síti je jednodušší nahodit IPv6 než IPv4.
Když instalujueš IPv4 router, první, co po tobě chce, je nějaká "IP adresa rozhraní WAN". Jak má chudák vědět, jestli vybrat PPoE, DHCP nebo fixní? A co tam vyplnit? Pak to chce cosi s NATem, nejakou IP adresu. Ok, hodíme to z WAN a.. nechodí to. Jo, a co je to ten DHCP pool a ta síťová maska? Jaká velikost poolu a začátek? Pak už lítají sprostý slova, když velikost poolu sežere pětku podle návodu na webu a náhodou se tam sejdou dva noťasy, tři mobily, telka a tiskárna.
Když instaluješ IPv6 router, prostě ho zapojíš. Spojí se s ISPíkem, sosne si svou IP adresu a prefix. No a pomocí RA oznámí zařízením v síti, jaký je prefix a kontakt na sebe jako gateway. Zařízení samotný si zvolí nějakou IP adresu v rámci prefixu, kterou jiný nemá a nazdar. Z pohledu uživatele stačí zapojit kabely.
Pokročilejší věci musíš u obou standardů nastudovat.
Co je na 6ce hodně blbý, tak vytvoření lokálního DNSka, kam se sypou v reálným čase adresy strojů v síti, třeba z DHCPv6. Z toho nesmyslnýho identifikátoru nedostaneš do DNSka jméno stroje, kdyby ses po... :(
"No jako ISPák nejsem, ale to připojení bude otázka toho, co bude chtít ISP a pochybuju, že se jenom tak vzdá dohledem nad sítí a nějakou bránou ..."
Ale on se jí zavedením IPv6 přece nevzdá.
IPv4 - jeden zákazník, jedna IP adresa. Když zákazník neplatí, zařízne ji.
IPv6 - jeden zákazník, jeden blok /56. Když zákazník neplatí, zařízne ho.
Jenom je potřeba se naučit, že adresa přípojky má místo 32 bitů 56 (resp. 48) bitů a jsou za ní bity, do kterých nemá co sahat.
@Petr M
No to sice jo, ale má poznámka směřovala k té složitosti pro klienta co všechno musí nastavit a kam se připojit - přece ISP se snaží tlačit vlastní DNSka většinou, vlastní firewally, má často několik vstupních a výstupních bodů (speciálně pokud poskytuje někde něco přes wifi nebo microvlnu) a z toho různé okruhy a podsítě - takže je předpoklad, že stějně klient bude muset zase dopňovat nějaké další nastavení, minimálně třeba znát adresu brány lokální sítě v rámci ISP kam je připojen. Nevím, je právě otázka, jak to budou nakonec řešit - na jednu lokální (zeměpisně) síť jednoho poskytovatele je subnet s ipv4 taky dost velký (tolik klientů určitě ani nemají) a přesto to mají dělené na různé části a podčásti ...
A proč by to nešlo?
- Na centrálu dostane /32
- Na města/městskou část to rozstřelí na až 255 oblastí, tj. například vesnice bude mít svůj prefix /40. Co jde z toho prefixu, je z té vesnice a odnikud jinak (a router je za to rád, že dává provoz mezi místníma bez uplinku). Jednu /40 si nechá na režii, management a vlastní administrativu.
- Stejně v té oblasti vyřeší ulice/paneláky, dá jich až 256 a je s prefixem na /48. To pak naseká na byty a domy, a hele - může jich mít v jednom bloku 256 a je na /65 pro koncáka. A v prefixu koncáka vidí trénovaný technik i městskou část, ulici a barák.
Řešit tohle kaskádou NATu je přece zbytečná komplikace.
@Petr M
Opakuji. Vyjadruji se k tomu, že s ipv6 toho bude každá domácnost nastavovat na routeru (v zákl. min. konfig.) méně tak, že si myslím že bude nastavovat úplně stejně - adresu brány/přidělené ip či co ..., DNS server (to budou tlačit ISP vlastní stejně jako nyní) a pak věci přímo co se týká routeru samotného - firewall ... takže tam moc rozdíl nebude ....
Opakuji, neobhajuji NAT, jenom to pro velké sítě občas bývá složitější než nastavit širší prefix ...
Nemyslím si.
Když jsem posledně instaloval router, tak na IPv6 chtěl pro každou síť jenom hint (číslo podsítě mezi prefixem /56 a /64). Svou IP adresu, gateway a prefix dostal z DHCPv6 ISPíka (na základě DUID). Sítě za routerem jsou /64, takže volba soukromýho rozsahu IP (10.x.x.x / 192.168.x.x), počtu zařízení a začátku DHCP poolu tím padá. A stroje v síti dostanou adresu routeru a prefix přes RA nebo DHCPv6. Hotovo.
No a v případě IPv6 to bylo tak, že sice byla veřejná IPv4, ale přes WiFi a na "krabičce" ISPíka tam byl NAT 1:1, takže default nastavení nešlo použít. Adresa na WAN šla přes DHCP z "modemu" a kolidovala s tím, co měl výrobce routeru na WAN, takže změna konfigurace - adresní prostor za NATem, DHCP pool jiné velikosti (protože to měli default na 10 zařízení - zoufale málo) , takže celkem nastavování třech parametrů per podsíť, aby DHCP začalo fungovat. SAmo s restartem a novým přihlašováním.
Pak co je u čtyřky navíc a nemusíš řešit u šestky, je prostřelení NATu. A s tím související pravidla na firewallu. Takže konfiguraci jednoho zařízení, který má být dostupný zvenku, máš ve čtyřce na několika místech:
- potřebuješ fixní adresu v rámci sítě - buďto na zařízení, nebo v DHCP
- potřebuješ pravidla firewallu na tom dostupným zařízení
- potřebuješ nastavit maškarádu
- potřebuješ si udělat díru ve firewallu na routeru
- potřebuješ protistraně sdělit, na kterým portu se na zařízení dostane
- a pokud nemáš veřejnou IPv6, tak ještě VPN na VPS a všechno to rozchodit (tunel, VPN, ...)
V 6ce prostě nastavíš na zařízení firewall a koncovku IP adresy (nebo ji tam kopneš přes DHCPv6) a firewall. Protistraně sdělíš IP adresu a chodí to. Zázrak.
Kate:
O tom jsem zrovna nedávno přemýšlel: Kamarád si pořídil Ubuntu, je s tím velmi spokojený, protože se mu to každou chvilu nesloží, ale je prostým uživatelem, takže jsem se mu nabídnul, že jak se mu bude něco srát, opravím mu to. Pak mi tak nějak došlo, že napojit se k němu nebude pr-del. Má-li veřejku (o 6ce jsem ani neuvažoval, když si představím ty místní mistry síťování), tak stejně bude muset nastavit NAT (to nezvládne). Jestli ji nemá, bude muset iniciovat spojení - napadl mě tunel přes SSH -R ke mně, kde já budu muset mít extra účet na serveru, na který se bude napojovat (heslem, i to je komplikace). Teprve pak tím tunelem polezu já k němu. S 6 by nastavil nanejvýš díru ve fireválu. Ještě mě napadlo n2n, ale to mu zas musím nějak vysvětlit a naistalovat... Prostě na hovno.
Místo n2n můžu doporučit Tinc, funguje podobně, ale stále se vyvíjí a je ze zkušenosti mnohem stabilnější na desktopu (třeba sám restartuje spojení po suspend/resume) a má lepší zabezpečení (klíče místo PSK). Ale i s Tinc může být opruz, pokud to nedokáže udělat díru do NATu (symetrický NAT), i s takovou VPN je lepší mít veřejné adresy.
NAT má skutečně několik výhod, zvláště pokud jde o možnost skrýt počet zařízení v určité síti. S IPv6 (i se slavnými privacy extensions) nejde, protože v jeden okamžik má zařízení jdnu IPv6 adresu.
S IPv6 se např. může stát, že poskytovatel bude chtít, abyste mu platili podle počtu připojených zařízení. S NATem má smůlu.
"NAT má skutečně několik výhod, zvláště pokud jde o možnost skrýt počet zařízení v určité síti. S IPv6 (i se slavnými privacy extensions) nejde, protože v jeden okamžik má zařízení jdnu IPv6 adresu."
Tak to je kec, už jenom proto, že s IPv6 má zařízení v jednom okamžiku několik IP adres a nemusí je všechny použít. Ve výsledku je zvenčí vidět jenom počet používaných sítí (prefixů /64).
Jaký jsou ostatní zdánlivý výhody?
"S IPv6 se např. může stát, že poskytovatel bude chtít, abyste mu platili podle počtu připojených zařízení. S NATem má smůlu."
Stejně tak může chtít platbu za počet otevřených spojení a v tom ti NAT nepomůže ani náhodou.
Co chce ISP ale není až tak důležitý. Kasírují tě na základě smlouvy a k jejímu uzavření je přece potřeba, aby s ní souhlasili oba dva. Když ho s tím nápadem pošleš do ..., nenadělá nic. U nás taky ISP odmítal IPv6 úplně, kyslíkář myslel, že /64 je dost a že za veřejku IPv4 budu připlácet, tak holt mám od růžovýho Tčka /56 a veřejnou IPv4 zdarma.
Jenom nepodepisovat každou kravinu a nebát se jim od plic říct, že není rozdíl mezi obsahem septiku a lebky jejich markeťáka.
IPV4 je jednduche na pochopeni.
IPV6 je slozite na pohopeni.
1,Cim slozitejsi vec, tim vice chyb clovek udela pri nastaveni.
2,Kazdy je schopny po telefonu sdelit technicke podpore IPv4, je to par cisel oddelenych teckama. Zkuste si zavolat na indicky helpdesk a diktovat jim tam IPV6 adresu a chtit reseni.Pro koncoveho uzivatele, ktery neni Ajtak to neni,
3,IPV6 neni rozsirene, protoze se s tim mega predymenzovanym silenym balastem nechce nikomu stvat a otravovat, jen "aby si routery pokecaly". To zadna firma platit nebude.
Co je na IPv6 složitého?
Psal jsem embedded implementace jak IPv4 tak IPv6, a IPv6 je v mnoha věcech spíš jednodušší, více věcí se dá řešit bezstavově.
V podstatě všechny Vaše na všechny Vaše body se dá odpovědět, že pokud člověk není debil, tak nemá problém....
V mnoha ohledech je IPv6 v důsledku jednodušší, právě díky možnosti přímé komunikace.
Pro urcite typy koncovych uzivatelu je to mozna do jiste miry "jednodussi", pokud zvladnou aspon spravne nakladani s icmp6.
Ovsem pro podnikove nasazeni a pro ISP nastavaji seriozni provozni problemy, napr. bezpecnostni orisek (leaky) v prostych dual-stack konfiguracich, nedejboze riznutych VPN. Do toho se vam zacne michat mcast, tunelovani nekterych O/S, moznost pasivniho zjistovani citlivych bodu infrastruktury, atp. Nejde o neresitelne veci, ale ve velke siti a za provozu do tehle dzungle nikdo dobrovolne nepujde. S ipv4 udelate daleko mene chyb z neznalosti anebo prehlednuti.
Tak treba, co je ::ffff:c0a8:c0a8? Je to prelozena adresa 192.168.192.168. Prestoze mam v domaci siti podobne IPv4 adresy, tedy "neverejne" adresy a prestoze pocitac si vygeneroval nejakou nahodnou IPv6 adresu (fe80::..), tak se na adresu ::ffff:c0a8:c0a8 nedopingam (ping: sendmsg: Network is unreachable). Asi by jsem to musel nejak implicitne konfigurovat, pripadne uplne zmenit architekturu IP adres...
Protoze DNS muzete omezit nikoliv pomoci nejakeho username/password, ale podle zdrojove adresy dotazu, cimz se to po prustrelu daneho segmentu stava automaticky public. Sice to jde prikryt certifikaty nebo xauth za pomoci IPsec, ovsem to je pro vetsinu zdejsi populace sci-fi, takze zustanme u zjednoduseneho tvrzeni, ze je to proste public-by-design.
Nevidim v tom zadny problem...
darkstar:[~]$ ping6 fe80::208:e3ff:feff:fc08%eth0
PING fe80::208:e3ff:feff:fc08%eth0(fe80::208:e3ff:feff:fc08%eth0) 56 data bytes
64 bytes from fe80::208:e3ff:feff:fc08%eth0: icmp_seq=1 ttl=64 time=0.867 ms
64 bytes from fe80::208:e3ff:feff:fc08%eth0: icmp_seq=2 ttl=64 time=0.734 ms
64 bytes from fe80::208:e3ff:feff:fc08%eth0: icmp_seq=3 ttl=64 time=0.771 ms
64 bytes from fe80::208:e3ff:feff:fc08%eth0: icmp_seq=4 ttl=64 time=1.10 ms
^C
--- fe80::208:e3ff:feff:fc08%eth0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.734/0.869/1.106/0.147 ms
Fajn, cast problemu vyresena, ping6 se pripoji. A jak to mam udelal v WWW prohlizeci? Asi takto, https://[fe80::207:e9ff:fe11:98b7]/, ale to mi nefunguje, zrejme WWW server posloucha jen na IPv4 (a tam funguje).
Pak je tady dalsi komplikace, treba ssh
$ ssh fe80::207:e9ff:fe11:98b7
ssh: connect to host fe80::207:e9ff:fe11:98b7 port 22: Invalid argument
SSH server urcite na portu 22 posloucha...
Proste IPv6 je luxus, na ktery nemem cas. Pokud by jsem investoval nekolik tydnu do sebevzdelani, mohl by jsem se vzdat nekolka verejnych IPv4 adres a mohl by jsem usetrit 1EUR, mozna i 3 EUR mesicne...
Co jsi presne nepochopil na tom, ze na konec te adresy musis specifikovat odchozi rozhrani?
Zkus ssh fe80::207:e9ff:fe11:98b7%eth0 nebo jak se jmenuje to tvoje rozhrani... a v browersu https://[fe80::207:e9ff:fe11:98b7%eth0]
Btw...
propeler:[~]$ ssh -6 ::ffff:c0a8:5801
The authenticity of host '::ffff:c0a8:5801 (::ffff:192.168.88.1)' can't be established.
RSA key fingerprint is SHA256:LkOCk8U4CWB7FBHSLBddLgsRrzY+GRzgoeEsSTO8SnY.
Are you sure you want to continue connecting (yes/no)?
S tím browserem to je trochu těžší: https://bugzilla.mozilla.org/show_bug.cgi?id=700999
Zdá se, že linkové adresy se vývojářům Firefoxu kvůli znaku % nějak nezdají.
Ty vole.... hele, nez se tady ztrapnovat, klikni na tenhle link: https://knihy.nic.cz/files/edice/ipv6_2012.pdf
a trochu si neco nastuduj. To co jsi napsal je obycejna IPv6 mapped IPv4 adresa a za ni se odchozi rozhrani neuvadi. Ale pokud si chces hrat s link-local adresami, tam odchozi rozhrani specifikovat musis.
Problem bude i v tom, ze prechod z IPv4 na IPv6 neni "win-win" reseni. Cast problemu se vyresi, nove vzniknou.
Kdyz jsem zacal studovat, nemely pocitace jeste sitove karty. Pak byla na kolejich sit s Novel, na PC byl DOS. Hrali jsme sitove hry, treba WarCraft a Descent, taky se pouzival lokalni fileserver, i ve skole byl Novel, ten byl skoro vsude. Male firmy mely Lantastic anebo jinou exotiku. A pak prislo IPv4. Nastavovani IPv4 nebylo snadne, ani Windows jej neumely (instaloval se Trumpet Winsock). Chvili bezely oba protokoly soucasne. Ale protoze IPv4 nabizelo vice vyhod, a hlavne obsahu v internetu (prvni WWW servery), relativne rychle zacalo dominovat. Kdyz MS pridal IPv4 do Windows, bylo rozhodnuto. Problem IPv6 je ze, zakaznikum s IPv4 moc noveho neprinasi, pokud ma zakaznik verejenou IPv4 adresu, name motivaci k prechodu na IPv6. A spousta beznych uzivatelu ani tu verejnou IP adresu nepotrebuje...
Spousta běžných uživatelů neví, že by měla chtít veřejnou adresu (na zařízení, ne jen na krabici). Dostat se z mobilu na data doma v počítači? Jsme ve stavu, kdy je nejjednodušší použít TOR. Celkem směšné, ne? Vzdálený tisk - zapomeň. Stream muziky třeba do auta - zapomeň. Knížky do ebooku - leda doma, ke knihovně calibre se z venku nedostaneš. Chceš si něco zahrát s kamarády? Potřebuješ další server - herní nebo vpn. Kecáky, torrenty atd. by mohly běžet přímo = rychleji.
Ale bez veřejného adresování nemáš ani možnost volby a MUSÍŠ jet tak, jak ti nadiktují ti, kteří veřejné adresy mají.
Pamatuji dobu IPv4, pred nastupem NATu. A nevzpominam si, ze by se takove blbiny delali...;-) Streamvani hudby do auta z domaciho PC? Neni to blbost?? Neni jednossi si vypalit CD? Normalni clovek si ty pisnicky ulozi na USB flash disk... A pak, sice mame NAT, ale take mame verejne cloud servery, kde si muzete za par korun mesicne delat vse co vymyslite, takze tam muzete mit i tu knihovnu hudby pro streamovani do auta... Jak nad tim premyslim, vlastne ani verejnou IPv4 adresu na domacim pripojeni nepotrebuji.
Super, přidáme další mezivrstvu, protože proč ne. Jen ať se toho může rozbít co nejvíc. Nikdy jsem neřekl, že z domácího PC. Jasně, budu se starat, abych měl vždycky aktuální muziku na CD/flash. Proč? Navíc je to dost kanón pro soubory na jeden poslech (podcasty). Jsou lidi, co veřený adresy potřebují, jsou lidi, kteří ne. Myslím si, že by veřejný (a stabilní) adresy měly být samozřejmostí. V IPv4 na vyžádání, v IPv6 se počítá s tím, že každý zařízení bude mít veřejnou adresu. Nám to prospěje a vám to neublíží.
Pár příkladů toho, na co jsem osobně narazil.
* Hráli jsme s kamarádem dooma. Ani jeden bez veřejné adresy, na to, abysme se vůbec viděli, jsme museli použít hamachi. Naštěstí kamarád není technický antitalent, takže jsme se dobrali spojení. Spustil jsem tam zandronum-server, druhý problém byl s wadama těch map, co jsem měl v plánu. Nakonec jsem to hodil někam na užnevímkam hosting, aby to jeho doomseeker normálně našel. To samé s veřejnou adresou: pošlu adresu+port, wady si stáhne doomseeker automaticky z příslušného webserveru, co mi stejně jede na localhostu (jel by na localhostu+stabilní veřejné adrese). On by se navíc mohl připojit přes doménu místo IP adresy. Dtto s pokerem (pokerTH)
* Podcasty. Mám uděláno, že se mi podcast stahuje do složky s hudbou, která podléhá MPD. Když sedím u počítače, poslouchám z něj. Když jdu do kuchyně třeba mýt nádobí nebo škrabat brambory, připojím se z mobilu. Ale když jdu do krámu, proběhnout se... tak jakmile se dostanu z dosahu místní wifi sítě, mám utrum. To samé s veřejnou adresou: mpd poslouchá na veřejné adrese, doma se mi mobil chytí na wifi, venku to poteče třebas i přes data - ale uvidím server, připojím se.
* Domácí automatizace. Tedy domácí od slova doma. Toho nápadu jsem se vzdal, prostě proto, že si domů nevidím.
* V zimě máme na okně krmítko pro ptáky. Taky starou webkameru. Normálně bych se mohl kouknout přes den, jestli tam je dost, kdo nám tam lítá. No, nemůžu, neuvidím si domů.
Dobře, 3 a 4 jsou spíš pro radost mého srdce. Primární důvody jsou 1 a 2. Pro těch pár ad hoc případů se mi nevyplatí vydržovat si VPS kdovíkde. Kdybych už ale všechno veřejně adresovaný měl, tak proč ne?
Ano, je to řešitelný i v současném stavu, ale podstatně složitějším způsobem, nejspíš za vyšší náklady, s omezeními a závislostí na dalších subjektech. Děkuju pěkně.
A aby to nevypadalo že jde v případě 1 jen o staromilce pařící dooma, už jsem takhle pomáhala docela dost lidem s rozchozením Minecraft multiplayeru. Nakonec scénář kdy by prostě stačilo spustit si doma server na PC a ostatním poslat přes messenger IP adresu skončil tunelováním přes Hamachi, nebo nákupem výkonné VPS. Boží.
"Dovolil jsem si předpokládat, že nejsou úplná prasata a mají tam i firewall."
Já myslel, že prasata mají router s firewallem v jedné krabičce (v IPv4 s NATem) a jinak nic.
Homo sapiens totiž ví, že se může nakazit i stroj lokální síti (třeba stažením přílohy nějakýno mailu) a nebere LAN za routerem jako na 100% bezpečný prostředí. Takže správná je konfigurace, kde na routeru je firewall, který zastaví věci, co se buďto v síti nepoužívají (Telnet,...), nebo se používají jenom lokálně a nesmí odejít ze sítě ani přijít zvenčí (NFS, CUPS, RDP, DHCP,...). A pak má firewall v zařízení, který zařízne přístup z LAN k tomu, co zařízení nepoužívá/neposkytuje.
A když má FW i na zařízeních, uplink třeba 20Mbps a LAN 1Gbps (50x rychlejší), takže ji zvenku nezahltíš, tak proč rovnou nepovolit na FW routeru, co můžou lidi používat zvenčí? Pokud je nutná autorizace, vynutíš IPSec, nebo je tam autorizace pro službu (SSH). Easy.
Počkej, Minecraft je protokol? Aplikace se blokují a APLIKAČNÍM firewallu na zařízení, firewall na routeru blokuje konkrétní porty, protokoly nebo IP adresy.
A pokud se dostaneš na web, znamená to, že z pohledu klienta
1) kontaktuješ web server (port 80) z libovolnýho volnýho portu na tvé mašině
2) přijde ti odpověď s číslem portu, na kterým tě web server očekává a se kterým budeš komunikovat.
Takže nutným předpokladem je, aby sada portů s vysokýma číslama, používaná pro TCP, prošla firewallem obousměrně. Všechno, co potřebuješ, je mít na stroji port, na kterým požádáš o sestavení spojení. A když to bude poslouchat třeba na 56565, který není kvůli tomuto blokovaný (je to jeden z tisíců portů, který se jinak používají pro data na TCP), tak se spojíš. Stejně tak pokud máš dohodnuto UDP na některým z těch vyšších portů.
Původně jsem myslel, že IPv6 fanatici jsou jen lehce blázni, ale teď koukám, že je to mnohem, mnohem vážnější. Kde píšu o nějakém "Minecraft protokolu"? Nikde.
Prostě fakt je, že v trochu rozumně spravované síti nebude stačit "spustit si server a ostatním poslat IP adresu", jak tvrdí Kate, ale bude potřeba to spojení ještě povolit na firewallu.
Dovolil jsem si předpokládat, že nejsou úplná prasata a mají tam i firewall.
Asi nevíte, co to firewall je. Firewall nelze mít, můžete akorát firewall nějak nakonfigurovat – vzhledem k provozu v síti dobře či špatně. Běžná domácí síť nemá nikoho, kdo by uměl správně nakonfigurovat firewall, a hlavně taková síť firewall nepotřebuje a byl by jí k ničemu. Firewall je něco navíc, buď pro případ, kdy uvnitř sítě musíte provozovat nějakou službu, kterou není možné zabezpečit samu o sobě (a taková služba nemá v domácí síti co dělat), a nebo pro případ, kdy chcete přidat druhou vrstvu zabezpečení (např. pro případ chyby v síťovém stacku OS).
@Filip Jirsák
" Běžná domácí síť ... a hlavně taková síť firewall nepotřebuje a byl by jí k ničemu."
Čtu dobře, že právě pro domácí síť (tedy většinou mix všeho možného, od různých verzí androidů, nyní pomalu i nějaké to IoT blbosti, až po různé verze desktopy *nix/win), pro běžné uživatele doporučujete nemít na routeru žádný firewall (s default zakázaným přístupem dovnitř)? To myslíte vážně? Chcete si dělat botnet či co nebo jste fakt úplně odtržený od reality?
Nesouhlasím se zpracováním osobních údajů v rozsahu v odkazovaném textu u vynuceného checkboxu, které jde nad rámec údajů nezbytných pro nutné technické zpracován.
@xxxxx: Ano, to myslím vážně. K čemu by tam ten firewall byl? To všechna ta zařízení, která jste jmenoval, považujete za natolik bezpečná, že se přes ně nikdo do „vnitřní“ sítě nedostane? Od reality odtržený nejsem, naopak jsem – na rozdíl od vás – zaznamenal existenci virů a malware, které se šíří vnitřní sítí, jakmile se jim podaří napadnout jedno jediné zařízení v síti.
Mohl byste ten váš objev popsat konkrétněji? Mám zařízení A a B v jednom segmentu sítě, tento segment sítě je k internetu připojen přes router a firewall R/F. Zařízení A je napadené a ovládá ho útočník. Jak přesně firewall R/F mezi A a internetem ovlivní přímou komunikaci mezi A a B?
O multi-layer security jsem v komentáři psal, ale ta má smysl někde ve firemní síti, kde někdo rozumí tomu, jak ten firewall nastavit. Když si někdo přinese z Penny wifi router za 300 Kč a zapojí ho do zásuvky, rozhodně to není multi-layer security.
Firewall na routeru neslouží pro případy, kdy už je útočník vevnitř sítě, ale když se snaží teprve dovnitř sítě dostat (tohle vážně nevíte?). Třeba když plošným skenováním internetu napadá počítače se 0-day dírou v Intel ME. Hodně štěstí, až se budete bez firewallu na routeru bránit takovým útokům, firewall na počítači vám určitě hodně pomůže.
Tak znova – jak u běžné domácí sítě zajistíte, aby útočník nebyl uvnitř té sítě? To si myslíte, že vám pomůže firewall, když si uživatel spustí nějakou úžasnou flashovou hru nebo nainstaluje aplikaci do mobilu?
A kolik asi tak domácích uživatelů si dokáže firewall nakonfigurovat tak, aby bránil proti útoku na 0-day v Intel ME?
Nevím tedy, jak vypadají sítě, které spravujete vy, ale já měl útok zevnitř (= když IDS na firewallu stroje uvnitř sítě zachytí podezřelý provoz) maximálně tak jednou za měsíc, zatímco útok zvenku přinejmenším každou minutu (pokud to hodně podcením). Ale samozřejmě pro Jirsáka nehraje rozdíl 5 až 6 řádů žádnou roli, takže útočníky zvenku ignoruje a rovnou předpokládá, že je uvnitř. Nechtěl byste rovnou předpokládat, že útočník má roota ve vašem počítači? Pak nemusíte řešit ani lokální firewall ani uživatelská hesla.
Domácí uživatel ten firewall nastaví velmi jednoduše: nijak. Všechny tyhle routery (včetně té krabičky za 300 z Penny) mají firewall ve výchozím stavu nastavený na blokování příchozího provozu. U mnoha to ani nejde vypnout. (Spravujete vůbec nějaké sítě, že tohle nevíte?)
Jak bude podle vás nastavovat takový uživatel firewall třeba na tiskárně, která typicky přijímá úlohy z libovolné adresy, když přístupy z adres mimo síť nemá blokovat firewall na routeru?
Sten: Klidně si dál žijte v bludu, že typické domácí sítě mají nějakého správce. V případě útoků je úplně jedno, kolik je těch neúspěšných, podstatné jsou úspěšné útoky. Přesněji řečeno, podstatné je, zda nebyl žádný úspěšný útok, nebo zda byl alespoň jeden. Protože v reálném světě, kde domácí sítě nemají žádné správce (ač si myslíte opak), nebude nikdo, kdo by ten útok na domácí počítač zaznamenal a něco s ním dělal. Tiskárna přijímající úkoly z libovolné adresy je v pořádku, nikdo nechce řešit, jestli je zrovna na té správné wifi nebo jestli je dokonce mobilem připojený přes mobilní data. Ta tiskárna ale samozřejmě musí uživatele autorizovat. A rozhodně dává smysl posílat data na tiskárnu rovnou z počítače nejkratší cestou, a ne je posílat přes servery Googlu nebo jiného cloudu.
„Ulehčit útočníkům“ je nesmyslný obrat. Asi jako kdybyste u bytu „zabezpečeného“ běžnou FABkou řešil, že klika z venku místo koule „ulehčí zlodějům“. nevím, jakou autorizaci na tiskárně by uživatel nastavoval – zadání přístupových údajů je součástí instalace.
Firewall se nezapíná firewall se konfiguruje, a jeho konfigurace závisí na tom, co je v síti firewallem chráněné. Pokud tohle nevíte, nechápu, o čem tu chcete diskutovat.
Vy byste ale radil, že tu FABku nepotřebuje, přeci stačí zamknout skříň, kde má peníze.
Připojoval jste vůbec někdy síťovou tiskárnu? Celá ta instalace je, že do tiskárny připojíte síťový kabel. Žádná hesla se při tom nenastavují. Sice je můžete nastavit později (tedy u jak které tiskárny), ale není to nutné. A domácí uživatel to opravdu dělat nebude, ten nemívá heslo ani na svém počítači.
Takže jste fakt nikdy neviděl nastavení levného routeru? Tam je akorát jedno zaškrtávací políčko „zapnout firewall“. Tak to pak opravdu nemá smysl pokračovat, když ani nevíte, o čem je řeč.
Neradil.
Domácí tiskárny jsem do sítě připojoval a vždy tam byla nějaká autorizace. Pokud nějaká tiskárna umožňuje tisknout komukoli bez autorizace, je to chyba té tiskárny, ničeho jiného.
Zaškrtnutí políčka v nějakém webovém rozhraní levného routeru neřeší nic, nebyla by moc velká změna, kdyby to políčko bylo namalované na krabici a zaškrtli vám ho fixem už v obchodě.
Problem je taky na strane implementace IPv6, jeste to neni usazene a vyladene. To rozsireni IPv6 adresy za % se nazyva zone-id a je popsano v RFC7346 a RFC4007.
Je jeste docela dost klientu, kteri zone-id neumi, testovano v Ubuntu 18.04. Treba wget, aria2, Firefox, Google Chrome/Chromium. Jako priklad klientu kteri toto rozireni IPv6 adresy zvladnou je ssh a curl. Konkretne, curl v Ubuntu 16.04.4 uz toto rozsireni umi, curl v Ubuntu 14.04.5 jeste ne. ssh uz toto zvlada i v Ubuntu 14.04.5
Zajimave se chova httpie, ten se sice na web server pripoji, ale zrejme spatne formuluje pozadavek, protoze dostane odpoved 400. A to muze indikovat drobny problem v liburl3 (Python)...
BTW, overeni teto skutecnosti neni o mnoho tezsi nez kliknuti na tlacitko "nesouhlasim"...
$ curl http://[::1%1]/test.html
$ wget http://[::1%1]/test.html
$ http http://[::1%1]/test.html
No vážně, to by mě nenapadlo, že tohle zone-id nebude fungovat ani v Chrome, ani ve Firefoxu. Ve Firefoxu na to je mnoho let otevřený bug s velmi zajímavou diskuzí. Méně výživná je pak diskuze v projektu Chromium. Obě se ale táhnou už leta a zdá se, že výrobci prohlížečů to nevidí jako velkou nutnost. A svým způsobem je to pochopitelné, zvlášť když URL slouží k přenosu mezi počítači, zatímco zone-id je záležitost zcela lokální pro konkrétní počítač.
Dik za odkazy, zone-id je plechovka plna cervu... Ten problem je mnohem komplexnejsi nez jsem si myslel.
Tak treba, podle poslednich specifikaci se URL ma spravne zapsat jako http://[::1%251]/test.html (pripadne http://[::1%25lo]/test.html), protoze znak % se v URL pouziva pro escape a je treba jej tak i zadat.
Dale jsem si myslel, ze zone-id musim uvadet jen na pocitacich, kde mam vice NIC (treba ETH a WiFi), a ze OS musim naznacit kam paket poslat. Ale neni to pravda, i na pocitaci kde je jen jeden ETH a loopback musim %interface pouzit, protoze OS "nevi", kam ma LL pakety (fe80::/10) poslat.
Na Windows toto problem neni, protoze Windows pouziji magicky trik a odhadnou interface, kam pakety poslat. To je zrejeme i jeden z duvodu, proc Firefox a Chrome zone-id odmitaji, protoze na Windows to problem neni, zone-id se nemusi uvadet. Jen na Linuxu, MacOS a Chromebooku, mozna i na Andoridu, to je problem. Pokud konfigurujete HW pres LL IPv6 adresy, poridte si Windows!
Je pravda, ze tento problem je svym zpusobem jen okrajovy a na vetsinu uzivatelu nema zadny dopad...
Jeste pro zajimavost uvadim stejnou adresu v base85 formatu: 0000000000008&RB1GBe
Jeste jsem to v praxi nevidel, ale existuje navrh na zjednduseni IPv6 adres, prekodovanim do base85.
RFC 1924 bylo vydano 1 Aprila, takze je to mozna jen april, ale ipv6calc tento format IP adres podporuje.
K čemu takovou volovinu potřebuješ? 192.168.x.y znamená, že je to lokální adresa za NATem (x je podsíť, y je adresa zařízení). Navíc potřebuješ vědět ještě komplet IP adresu před NATem, někdy před CGNATem, takže si ve výsledku ty adresy pamatuješ minimálně dvě.
V IPv6 máš prefix:x::y. Prefix dostaneš od operátora (ten si musíš pamatovat/poznamenat, ale je to IP adresa tvé přípojky zvenčí a díky němu se dostaneš na zařízení uvnitř). X je podsíť (pro /60 jich máš k dispozici 16, pro /56 je jich 256, pro /48 je jich 65536) a tu si vybereš sám, stejně jako v IPv4. Y si vygeneruje zařízení, ale pokud chceš u zařízení pevný y, tak si je nastavíš dle libosti a neighbor discovery zajistí, že tohle y nebude mít nikdo s dynamickou adresou.
A jeden trik - nemusíš pro x a y používat hexa číslice, pokud dáváš adresy ručně. Můžeš použít klidně i BCD nebo trojkovou sosutavu, síť to přežije. Ono se totiž nečísluje kontinuálně (ale tahle featura, že po 192.168.2.5 bylo třeba až 192.168.2.105 fungovala odjakživa)... Jenom myslet out of the box.
Co je na tom složitějšího?
Proc to potrebuji? Mam funkcni IPv4 infrastrukturu, lety preverenou, znamou. A potrebuji nejak zacit s IPv6. Vlastne nepotrebuji, ale kdyby jsem chtel zacit s IPv6, tak se potrebuji nekde odrazit a postupovat pomalu krok za krokem. Jednou z moznosti je postavit si treba ESXi server a tam si vybudovat IPv6 svet na zelene louce, izolovane virtualni prostredi pro experimenty. Anebo zkusit postupne zapojit IPv6 do soucasne lokalni site, zacit experimentovat ale nerozbit soucasny funkcni stav. A to neni uloha snadna. S IPv6 koketuji uz vice nez 20 let, obcasne pokusy, ale skutecne v tom pro sebe zatim zadnou pridanou hodnotu nevidim, takze jsem konzervativni a zustavam na IPv4. Nejsem profesionalni sitar, IP konektivita me nezivi....
Jsem za NATem, mam ten luxus, ze mam verejnou IP4 adresu. Nemam potrebu mit verejnou IPv6 (spise prefix, ze?), v tuto chvili urcite ne a pokud by jsem ji mel, stejne by jsem chtel NAT pro IPv6. Mam i nejake servery v cloudu, tam muzu mit plnohodnotnou IPv6, ale nepotrebuji to, priplatek za IPv4 si mohu dovolit.
Tento clanek jsem dneska nasel, zda se mi zajimavy; je jiz 3 roky stary.
https://www.jumpingbean.co.za/blogs/mark/set-up-ipv6-lan-with-linux
Začít IPv6? Tak přejdi k ISP, který 6ku dává, minimálně /56 a povol to na routeru. Komply už se s tím popasujou samy. A pak si můžeš vesele hrát v domácí síti. A pokud jde o nerozbití sučasnýho stavu, slušný router nabízí několik sítí, takže si přepneš na switchi pár zařízení na experimentální síť a pak je můžeš vrátit...
Pokusy na izolované síti s fe80:: moc dobře nedopadají, mj. proto, že tam nemáš danou gateway ven, nějak to potom pro zařízení nedává smysl a bude se k tomu chovat jak Drákula ke svazku česneku na poledním slunci.
Uplne jednoduse, zacit se 6to4. Pokud je verejna IPv4 adresa, tak z ni lze ziskat taktez verejny a plne funkcni IPv6 prefix /48. Pravda, pro seriozni pouziti uz je to dneska trosku slepa cesta, ale na experimenty idealni. S poskytovatelem ani nikym jinym neni treba nic domlouvat, z nekoho neco loudit, nekde se registrovat, vubec nic. Je to tam, staci to jen zapnout. A ve standardnim nastaveni se IPv6 pres 6to4 nepreferuje, je az za IPv4, coz muze byt v tomhle pripade vyhoda, ze to jen tak snadno neco nerozbije.
Tak jsem prisel na to, jak priradit vlastni IPv6 adresu. Rekneme, ze PC ma IPv4 adresu 192.168.168.209 a ja chci, aby mel i "rozumnou" IPv6 adresu, treba ::ffff:192.168.168.9.
ifconfig enp4s0 inet6 add ::ffff:192.168.168.9/64
OK, a ted vypisi stav.
$ ifconfig enp4s0
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.168.9 netmask 255.255.255.0 broadcast 192.168.168.255
inet6 192.168.168.9 prefixlen 64 scopeid 0x0<global>
inet6 fe80::87f4:81fa:b481:d781 prefixlen 64 scopeid 0x20<link>
ether 00:1a:4d:50:41:95 txqueuelen 1000 (Ethernet)
RX packets 587973 bytes 356584138 (356.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 161055 bytes 63533139 (63.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Proc se ta IPv6 adresa zobrazuje jako 192.168.168.9?? Kdyz zadam "ping6 192.168.168.9", tak dostanu chybu. Kdyz zadam "ping6 ::ffff:192.168.168.9", tak to funguje. A ip prikaz take vypise spravnou konfiguraci, takze to vypada, ze stary ifconfig ma drobnou chybu...
$ ip addr show dev enp4s0
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1a:4d:50:41:95 brd ff:ff:ff:ff:ff:ff
inet 192.168.168.9/24 brd 192.168.168.255 scope global dynamic noprefixroute enp4s0
valid_lft 3488sec preferred_lft 3488sec
inet6 ::ffff:192.168.168.9/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::87f4:81fa:b481:d781/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Zajimava je i situace s HTTP protokolem. Curl funguje dle ocekavani.
$ curl http://[::ffff.192.168.168.9]/test.html
Kdyz vsak stejne URL zadam do browseru Chromium, dostanu vysledky nalezene Googlem; Chromium tedy tomuto URL nerozumi... :-( Takze jeste jednou
$ curl http://[::ffff:c0a8:a809]/test.html
Tomuto URL uz Chromium rozumi a zobrazi testovaci stranku.
Zajimavejsi je situace s WGET. Ten dela neco hodne spatne, at delam co delam, dostavam toto:
$ wget http://[::ffff:c0a8:a809]/test.html
HTTP request sent, awaiting response... 200 OK
Length: 31 [text/html]
test.html: No such file or directory
Cannot write to ‘test.html’ (Success).
$ traceroute6 ::ffff:c0a8:a809
traceroute: bind icmp6 socket: Cannot assign requested address
$ curl http://[::ffff:c0a8:a809]/test.html
<html><body>TEST</body></html>
Z meho pohledu je treba ten IPv6 jeste dost poladit... :-(
Z meho pohledu, je rozsah ::ffff:/96 pro tento ucel, nebot je urcen pro mapovani IPv4 adres. Jake mam dalsi moznosti? fc00::/7 ?
Funguji oba rozsahy, rozdil je, jak "ip" a "ipconfig" zobrazuji adresy. Adresa z rozsahu ::ffff:/96 se zobrazuje jinak a to se mi libi. Kdyby jsem netrval na peknem mapovani ipv6 na ipv4, pak rozsah fc00::/7 by mohl mit pekne adresy jako fc00::1234, tim by se taky dobre pracovalo. Pro testovani by mi stacily i linkove IPv6 adresy, fe80:/10, ale jednak jsou moc dlouhe, pak v Linuxu funguji spatne, teda jejich pouzivani je komplikovane (adresa%interface).
$ ip addr show dev enp4s0
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1a:4d:50:41:95 brd ff:ff:ff:ff:ff:ff
inet 192.168.168.9/24 brd 192.168.168.255 scope global dynamic noprefixroute enp4s0
valid_lft 2866sec preferred_lft 2866sec
inet6 fc00::c0a8:a809/64 scope global
valid_lft forever preferred_lft forever
inet6 ::ffff:192.168.168.9/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::87f4:81fa:b481:d781/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Jasně. Místo toho, že si zapamatuješ prefix, číslo podsítě a IP adresu (max. 64 bitů, ale nic ti nebrání použít jenom nejnižší čtyři v BCD a zbytek nechat nulu, tj. 80 bitů), tak
- si pamatuješ IP adresu zařízení (32 bitů)
- si pamatuješ adresu routeru na WLAN (dalších 32 bitů)
- si pamatuješ adresu na VPNce, přes kterou se tuneluješ do domácí sítě (dalších 32 bitů - celkem 96 bitů)
- když se něco dodrbe, tak navíc musíš kontrolovat NAT, VPN server a VPN klienta
- musíš se nastavovat s VPNkou, DNSkem, NATem,...
To je komplikace jak noha.