IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Zdravim
Tak pár hodin jsem hledal a nenašel, tak prosím o radu. :) Podle návodu http://www.root.cz/clanky/navod-jak-jednoduse-a-rychle-na-ipv6/ jsem si získal účel u tunnerbroker a nastavil ipv6 v systému dle návodu. Necham asi za sebe mluvit terminal.
root@petrpc:~# ifconfig
eth0 Link encap:Ethernet HWadr 00:0f:ea:43:2d:4e
inet adr:10.0.0.1 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::20f:eaff:fe43:2d4e/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:79072 errors:0 dropped:0 overruns:0 frame:0
TX packets:86589 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 58716637 (58.7 MB) Odesláno bajtů: 14306669 (14.3 MB)
Přerušení:23 Vstupně/Výstupní port:0x6000
lo Link encap:Místní smyčka
inet adr:127.0.0.1 Maska:255.0.0.0
inet6-adr: ::1/128 Rozsah:Počítač
AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1
RX packets:36 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 2536 (2.5 KB) Odesláno bajtů: 2536 (2.5 KB)
sit0 Link encap:IPv6-in-IPv4
inet6-adr: ::127.0.0.1/96 Rozsah:Neznám.
inet6-adr: ::10.0.0.1/96 Rozsah:Kompatibilita
AKTIVOVÁNO BĚŽÍ NEARP MTU:1480 Metrika:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 0 (0.0 B) Odesláno bajtů: 0 (0.0 B)
sit1 Link encap:IPv6-in-IPv4
inet6-adr: 2001:470:1f14:310::2/64 Rozsah:Globál
inet6-adr: fe80::a00:1/64 Rozsah:Linka
AKTIVOVÁNO POINTOPOINT BĚŽÍ NEARP MTU:1480 Metrika:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 0 (0.0 B) Odesláno bajtů: 0 (0.0 B)
root@petrpc:~# ping6 -c4 www.ipv6.uni-muenster.de
PING www.ipv6.uni-muenster.de(tolot.ipv6.uni-muenster.de) 56 data bytes
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
^C
--- www.ipv6.uni-muenster.de ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3024ms
root@petrpc:~# ping6 -c4 2001:0470:1f0a:cc0::1
PING 2001:0470:1f0a:cc0::1(2001:470:1f0a:cc0::1) 56 data bytes
ping: sendmsg: Operation not permitted
Podle ifconfigu se to tváří, že to funguje, ale ping (ani zápis pomocí ip, ani domény) nefunguje, ani jakýkoliv jiný pokus o spojení s nějakym ipv6 strojem. Jinak běžim za adsl routerem Zyxel, kde je nat, ale nejak se mi podařilo dopracovat k tomu, že mam přidat do nat forwardu port 3653 a ani to nepomohlo.
Ubuntu 9.04
Linux 2.6.28-11-generic
Vaše chybová hláška není o tom, že by vám nefungovala síť, ale o tom, že nemáte právo odesílat takový packet. A zakazuje vám to vaše jádro (chybí SUID bit, kvalifikace, zasahuje SELinux).
Asi bych začal rozchozením ping6 ::1 a pak ping6 -n -I sit1 ff02::1, kde byste měl vidět odpovědi ze dvou strojů – ze svého konce a od druhého konce u tuneláře.
Nicméně i samotné nastavení rozhraní, co jste podal, mi přijde divné. Linkové adresy na sit0 jsou dost divné.
Ostatně celý ten návod na rootu je pochybný. Za prvé přestaňte používat net-tools (ifconfig a route) a přejděte na iproute2. Za druhý není třeba konfigurovat dvě síťová rozhraní. Vše se udělá na jednom. Přesný postup příkazů je možné vymáčknout z konfiguračního formuláře Hurricane Electric. Za třetí nějaké natování transportních portů je na nic, protože tenhle tunel je IPv6 v IPv4. Nikoliv IPv6 v UDP v IPv4. Jste si vůbec jistý, že vám váš router umí natovat takový provoz?
Pokud za natem máte stejně vlastní router (nebo jediný stroj), tak doporučuji udělat z modemu čistý bridge a PPPoE zakončit na něm. Dostanete tak na svůj stroj veřejnou IPv4 adresu a budete mít o jeden NAT méně.
Tak jsem zkusil variantu vygenerovanou tim formulářem pomocí iproute2: modprobe ipv6 ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 85.71.173.59 ttl 255 ip link set he-ipv6 up ip addr add 2001:470:1f14:310::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6 ip -f inet6 addr
Zjistil jsem teda ještě zajímavější věc, že modul ipv6 se nepodařilo najít, což se mi zdá jako nesmysl, když:
root@petrpc:~# ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.030 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.041 ms
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
root@petrpc:~# ip -f inet6 addr
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qlen 1000
inet6 fe80::20f:eaff:fe43:2d4e/64 scope link
valid_lft forever preferred_lft forever
A navíc ve všech diskusních forech si uživatele stěžují na problém se zapnutou podporou ipv6 v Ubuntu 9.04, takže myslim, že ta podpora tam bude. A kdyby ne, tak přeci by vůbec neuměl zacházet s ipv6 packety, ani nastavením, nebo ne? Přiznam se, že v Linuxu jsem docela nováček, ale rád bych si s tim pohrál nějak dokonce. Jinak ten router by měl mít podporu ipv6, jestli umí natovat timhle způsobem, to netušim, ale bridge z něj udělat nemůžu, potřebuji ho jako router. v baráku jsou ještě dva počítače. Takže mi tam běží nat a na muj počítač jsou natovány porty pro ftp a jabber server. Ale pokud by neuměl natovat ipv6 packety, tak to by znamenalo, že mam opravdu smůlu, nebo jen bych nemohl mít příchozí spojení na ipv6?
root@petrpc:~# modprobe ipv6 FATAL: Module ipv6 not found. root@petrpc:~# ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 85.71.173.59 ttl 255 root@petrpc:~# ip link set he-ipv6 up Cannot find device "he-ipv6"
Co je to "he-ipv6"?
Vyzkoušel jsem i variantu:
ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 10.0.0.1 ttl 255
10.0.0.1 je lokální ip za nat...
root@petrpc:~# ip -f inet6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::20f:eaff:fe43:2d4e/64 scope link
valid_lft forever preferred_lft forever
7: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480
inet6 2001:470:1f14:310::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:1/128 scope link
valid_lft forever preferred_lft forever
Už se mi podařilo rozběhat to "he-ipv6", ale komunikace stále nejde.
DMZ tu nemam,ale přepnul jsem natování ze SUA only na Full feature a napamoval globální ip na lokální bez ohledu na port, ale stále to nechce běžet... asi to vzdam. :)
Napadlo mě teda ještě to přepnout ten router na bridge a do mého počítače dát wi-fi kartu a udělat z něj acces point a router (tuhle funkci teď plní router) pro zbylé dva počítače. Já jsem připojenej kabelem. Ale podle mě, když jsem to takhle namapoval, tak prostě ten router musí všechny packety příchozí posílat na muj počítač, ne? Jestli to neni zbytečný, jestli neni chyba jinde.
root@petrpc:~# ping6 -n -I he-ipv6 ff02::1
PING ff02::1(ff02::1) from fe80::a00:1 he-ipv6: 56 data bytes
ping: sendmsg: Operation not permitted
A pokud teda jak tady kolega píše jádro zakazuje tu komunikaci, jak tedy to povolim? SElinux je pro mě španělská vesnice. :)
root@petrpc:~# telnet telnet open 2001:7b8:3e2::1 25 Trying 2001:7b8:3e2::1...
A tim konec... ale neni mi jasný, proč se pokoušim připojit na port smtp?
Ta hláška Operation not permitted je fakt divná, když ping na na localhost funguje. Co ping z rozhraní eth0? Měl byste obdržet hlášení od všech strojů na dané lince, které umí IPv6. Tedy asi jen od vašeho.
Hláška je textový přepis chyby EPERM, která se používá, když „operace není povolena“. Nemáte zavedený nějaký nestandardní bezpečnostní modul? Tahle chyba se ve spojení s ping6 normálně objevuje, jen když zkusí pingat ne-root (protože ICMP packety si ping6 sestavuje sám a odesílá je je jako syrové packety, což je privilegovaná operace).
Kdyby vám „jen“ nefungovalo směrování IPv6, tak maximálně dostane chybu no route to host, network unreachable či něco obdobného.
Mimochodem Launchpad: default ipv6 policy is block se na vaše Ubuntu nevztahuje (zakázaný odchozí IPv6 provoz pomocí packetového filtru)? ip6tables -vnL vám tvrdí co?
9.9.2009 16:00
root@petrpc:~# ip6tables -vnL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 588 ACCEPT all lo * ::/0 ::/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 73 packets, 6228 bytes)
pkts bytes target prot opt in out source destination
8 588 ACCEPT all * lo ::/0 ::/0
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/188934
to již zabralo, ping už mi funguje.
root@petrpc:~# ping6 -n -I he-ipv6 ff02::1
PING ff02::1(ff02::1) from fe80::a00:1 he-ipv6: 56 data bytes
64 bytes from fe80::a00:1: icmp_seq=1 ttl=64 time=0.133 ms
64 bytes from fe80::a00:1: icmp_seq=2 ttl=64 time=0.108 ms
^C
--- ff02::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.108/0.120/0.133/0.016 ms
To opravdu děkuju, to mě nenapadlo.
Takže teď mi ještě asi zbývá vyřešit dns, protože např. ipv6.google.com nefunguje... zřejmně asi potřebuju nějaký veřejný dns server co podporuje ipv6 záznamy?
No, stačí – ten ping byl na multicastovou linkovou adresu, ale ozval se jen váš stroj. Měl by se ozvat i druhý stroj. Taky by měl fungovat unicastový ping na druhý konec tunelu (ping6 -n 2001:470:1f14:310::1). Dokud nepojede i tohle, tak nemá smysl řešit další věci.
Takže problém hledat buď ve směrování a nebo teda v nat routeru, které teda prostě spolupracovat nebude, ikdyž jsem nastavil natování veškerého provozu na 10.0.0.1. Tak zkusim nejdřív předpokládat, že prostě to bude směrovací tabulkou na téhle stanici.
Když se podivam na ipv4 routovaci tabulku:
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
169.254.0.0/16 dev eth0 scope link metric 1000
default via 10.0.0.138 dev eth0 metric 100
Tak to docela chápu, ale při pohledu na:
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
Nechápu nic. :) Logicky by tam asi mělo být, že se vše má směrovat přes tunel na druhé straně, jestli to dobře chápu něco jako ipv4 směruju na router, ale jelikož nemam nastudované ani zkracování adres ipv6, tak asi opravdu zjišťuju, že nedjřív bych si měl tu knížečku o ipv6 vážně nastudovat. :)
ip route add ::/0 dev he-ipv6 jsem provedl...
A ping na 2001:470:1f14:310::1 vypadá takto:
root@petrpc:~# ping6 -n 2001:470:1f14:310::1
PING 2001:470:1f14:310::1(2001:470:1f14:310::1) 56 data bytes
A neskončí žádnou hláškou...
Při nenastavení směrování, aspon skončil hláškou: Network is unreachable, ale ted z něj nevypadne nic. :) Takže buď to směrování nastavuju blbě, nebo ta černá krabička opravdu nechápe co je to natovat veškeré packety na muj stroj a musel bych udělat router z tohoto počítače.
Tak teda jestli to směrování jsem nastavil dobře, a určitě je problém na cestě ( jediný nat je na na mém routeru) , tak odložim to na jindy. A udělam tedy router a wi-fi AP z tohoto stroje a krabičkový router přepnu do bridge mode, stejne mi tenhle pocitac bezi nonstop. Ale to udelam az pri jine probdele noci, protoze to je otazka i vyreseni signalu wi-fi pro dva pocitace, co krabicovy router pouzivali jako AP. :) A to jsem si myslel, jak jsou tyhle krabicky chytry, router co jsem mel predtim se umel pripojit i na vpn tunel atd. Aspon si do tý doby něco nastuduju o ipv6.
Tak díky moc za rady.
Btw. Z pohledu ipv6 je cesta packetu od mého stroje k tunelu brána jako jeden skok, že? Takže trasovat to, abych zjistil, jestli skutecne je problem na tom Zyxelu nema smysl, ze?
Pokud ten zyxel je modem, co dává Telecom k ADSL, tak vězte, že s ním mám nějaké zkušenosti. Hardwarově je namakaný, na co mají ve webovém rozhraní, je taky dobře udělané, ale spoustu věcí nelze v něm nastavit (ani z webu, ani po telnetu). Například není možné anténu přepnout z režimu AP do jiného. A podobných nedodělků tam je spousta, protože si manažeři mysleli, že běžný uživatel takové věci nepotřebuje.
Teoreticky byste se měl obejít bez nového rádia:
Ten modem má několik rozhraní síťových, v podstatě jedno je ADSL (na linkové vrstvě jede taky Ethernet), druhé (LAN) je klasický Ethernet do vnitřní sítě a třetí je bezdrátové (WIFI).
Když dáte ADSL a LAN do bridge (BR), tak dostanete PPPoE po kabelu do vašeho stoje. Tam získáte veřejnou IPv4 (rozhraní PPP) i IPv6 adresu (rozhraní he-ipv6). Když v modemu nastavíte BR místní IP adresu a ze stejného rozsahu nastavíte adresu svému stroji, tak můžete komunikovat ze svého stroje s modemem, když on bude v režimu bridge (tohle je ostatně standardní nastavení, které ten modem určitě umí).
Když WIFI nastavíte místní adresu a povolíte přeposílání packetů mezi WIFI a BR, tak budete mít ostatní bezdtrátově připojené stoje dosažitelné ze svého stroje.
Když na svém stroji nastavíte NAT (maškarádu na PPP rozhraní) a povolíte přeposílání packetů a na všech strojích správně nastavíte výchozí brány, tak všechny stroje budou moci posílat packety do Internetu.
Otázka je, jestli je možné k tomu dokopat ten zyxel. Jestli si opět chytří páni neřekli, že něco takového běžný uživatel nepotřebuje.
Nad tim jsem taky přemýšlel, že bych využil wifinu toho routeru alespoň. Přepnul dsl a lan do bridge, po utp kabelu bych tedy dostával PPPoE, jako bych tam měl normální modem. A doufal, že to wi-fi bude umět samostatně se nastavit. Na web rozhranní i na telnetu je možnost nastavit směrování (lze nastavit přeposílání packetů mezi bezdrátem a utp). ale jestli bude umět zpětně převést PPPoE na klasický Ethernet, z utp na wi-fi (to co teď dělá z adsl na utp i wi-fi), to už bude možná horší. :( Ale jelikož se jedná o rodinnej domek, kde já jsem v podstatě v pronájmu v půdnim bytě a další dva počítače jsou v jiném patře, blíž routeru, takže by to možná ze signálem bylo horší, kdybych si udělal z tohoto stroje wi-fi ap, proto bych radeji vyuzil antenu toho Zyxelu. Jinak ano, jedná se o Zyxel co dodává kyslík ke svému připojení. Mě ten router vadí i v jinejch směrech (např. ve firewallu umí dropovat packety, ale reject bere jako permit atd), ale neni možné ho vyměnit kvůli O2 TV :). Takže rozhodně bych si radějii rozběhal vlastní router, nat, dns cache atd.
Jinak při vyslání pingu na konec tunelu, když jsem začal sledovat provoz pomocí tcpdump, tak to vypadá následovně:
root@petrpc:~# tcpdump -np -i he-ipv6
tcpdump: WARNING: he-ipv6: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on he-ipv6, link-type RAW (Raw IP), capture size 96 bytes
16:02:54.024513 IP6 fe80::a00:1 > 2001:470:1f14:310::1: ICMP6, echo request, seq 1, length 64
16:02:55.024673 IP6 fe80::a00:1 > 2001:470:1f14:310::1: ICMP6, echo request, seq 2, length 64
16:02:56.024666 IP6 fe80::a00:1 > 2001:470:1f14:310::1: ICMP6, echo request, seq 3, length 64
Vidim tedy pouze odeslané packety.
Jinak, když se dívám kudy se jádro chystá směrovat, tak vidim, tak jestli dobře interpretuju následující výpis, tak by vše mělo chodit přes adresu tunelu, což je dobře, ne?
root@petrpc:~# ip route get 2a02:38::1001
2a02:38::1001 via ::216.66.84.46 dev he-ipv6 src 2001:470:1f14:310::2 metric 1 mtu 1472 advmss 1412 hoplimit 4294967295
NAT funguje i na IP vrstvě. Jen to není stavový překlad adres a není možné jej demultiplexovat. Že natující router bude packety přicházející z Internetu překládat a směrovat na jediný stroj, který takové packety před tím vypustil, se jaksi spoléhají všechny návody (i ten z Rootu). Teoreticky to fungovat může, ale praxe je různá. A obávám se, že tohle je ten horší případ.
Když se žádná hláška neobjevila, tak to znamená, že žádná odpověď nepřišla. Po ukončení pingu jste jistě dostal statistiku, že tolik a tolik packetů se ztratilo.
Jestli máte směrování nastaveno dobře, se lze přesvědčit dvěma způsoby:
Příkazem ip route get CÍLOVÁ_ADRESA se zeptáte jádra, kudy hodlá takové packety posílat. To je pro ulehčení, aby správce nemusel studovat všechny směrovací tabulky.
Druhý způsob je poněkud přízemnější, ale za to údernější – prohlídnete si provoz na podezřelém rozhraní pomocí tcpdump -np -i ROZHRANí. Případně může být dobré dodat parametry -s0 -v, pokud chcete znát celé packety nebo podrobnosti.
Když se podíváte na rozrhaní he-ipv6, tak uvidíte jen IPv6 packety, které chodí tunelem. Když se podíváte na eth0, tak kromě běžného IPv4 provozu uvidíte i váš IPv6 provoz z he-ipv6 zabalný do IPv4 packetů a směřující na jeden z konců tunelu.
Ještě dodám, že jádro z výkonnostních důvodů si udržuje cache směrovacích pravidel. Pokud častěji měníte směrovací pravidla, může se stát, že údaje v cache budou neaktuální. Jádro ale při skutečném směrování dává vždy přednost údajům v cache. Cache lze preventivně vyprázdnit příkazem ip route flush cache. (Nejsem si jist, jestli je nutné parametrem -6 vybrat jen IPv6 záznamy.)
Studium bude dobrý nápad. Především pochopit co to jsou rozsahy (host, link, global scope), druhy adresování (unicast, multicast) a na co všechno se používá ICMPv6.
Citovaná tabulka obsahuje pouze směrovací záznamy pro linkové adresy. Máte dvě rozhraní vedoucí ze stroje, tak máte dva záznamy. Proto se u pingu na linkovou adresu musí uvádět parametrem -I název odchozího rozhraní.
Pokud modprobe ipv6 selže, ale ip addr show ukazuje IPv6 adresy, tak máte podporu pro IPv6 zakompilovanou přímo v jádře a tento krok nemá smysl.
Co je to "he-ipv6"?
To je název zařízení (tunelu), který jste vytvořil příkazem ip tunnel add. Název si můžete zvolit „jakýkoliv“.
root@petrpc:~# ip link set he-ipv6 up Cannot find device "he-ipv6"
To je divné. Příkaz ip tunnel add žádnou chybu nevypsal? ip tunnel show a ip link show ukazují nově vytvořený tunel a zařízení? Nemáte nějaké chybové hlášení v jaderném logu (dmesg)?
Takže mi tam běží nat a na muj počítač jsou natovány porty pro ftp a jabber server.
Vy potřebujete natovat protokol č. 41 (IPv6).
Ale pokud by neuměl natovat ipv6 packety, tak to by znamenalo, že mam opravdu smůlu, nebo jen bych nemohl mít příchozí spojení na ipv6?
Záleží, jak to je v zyxelu udělané.
Obecně problém je, že IPv6 není možné demultiplexovat, jako TCP. Proto pokud vám takové packety budou dovnitř procházet, tak jedině pokud předchozí IPv6 provoz bude pocházet jen z jednoho stroje. Jinak by zyxel nemohl vědět, na kterou IPv4 adresu jej překládat.
tunel he-ipv6 už jsem vytvořil, když jsem zadal lokální ipv4 adresu (za nat) příkazem
ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 10.0.0.1 ttl 255
Předtím jsem tam zadával globální ipv4 adresu routeru, vygenerovanou tim scriptem na tunnelbroker.net, takže tohle už se mi povedlo. Můj momentální výpis ip tunnel show vypadá takto
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc he-ipv6: ipv6/ip remote 216.66.84.46 local 10.0.0.1 ttl 255
A ip link show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0f:ea:43:2d:4e brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
4: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
link/sit 10.0.0.1 peer 216.66.84.46
V logu dmesg je jediná zmínka o ipv6 tato: eth0: no IPv6 routers present
Jak vypadá routovací tabulka? (co řekne ip -6 route?)
Na tom ADSL modemu bude potřeba v konfiguraci NATu říct, aby všechen provoz na protokolu 41 z internetu směroval na 10.0.0.1, to jste udělal?
root@petrpc:~# ip -6 route
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
Router je nastaven, že veškerý provoz natuje na 10.0.0.1
Myslím, že jste si to vším tím testováním jen rozházel :)
Vámi naposledy zmíněný výstup příkazu ip link show ukazuje, že na rozhraní he-ipv6 nemáte vůbec nastavenou IPv6 adresu. Zkuste tedy:
ip -6 a a 2001:470:1f14:310::2/64 dev he-ipv6
A následně vypsat routovací tabulku pomocí ip -6 route. Tentokrát by měl přibýt záznam pro síť 2001:470:1f14:310::/64.
Pak nastavte správně MTU (pro ADSL je vhodné použít 1472), přidejte do routovací tabulky záznam pro síť ::/96 a nakonec nastavte směrování pro všechen IPv6 provoz.
ip link set dev he-ipv6 mtu 1472 up
ip -6 route add ::/96 dev he-ipv6 metric 1
ip -6 route add ::/0 via ::216.66.84.46 dev he-ipv6 metric 1
Pak vyzkoušejte ping6 a traceroute6 na (např.) 2a02:38::1001 (nix.cz)
Některé verze jader nemají rády IPv6 směrování přes ::/0, pomůže přidat směrování pro síť 2000::/3:
ip -6 route add 2000::/3 via ::216.66.84.46 dev he-ipv6 metric 1
Teď se dívám, že ip link show nikdy nezobrazuje v6 adresy... pro diagnostiku bude asi lepší výstup příkazu ip a, příp. ip a s dev he-ipv6. Výstupem by mělo být něco podobného (tohle je konkrétně konfigurace 6to4 tunelu, ale formát výpisu bude podobný)
# ip a s dev tun6to4
14: tun6to4@NONE: <NOARP,UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN
link/sit 77.75.72.3 brd 0.0.0.0
inet6 2002:4d4b:4803::1/16 scope global
valid_lft forever preferred_lft forever
inet6 ::77.75.72.3/128 scope global
valid_lft forever preferred_lft forever
Tiskni
Sdílej:
