Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
nc6 www.nic.cz 80tak mi to vypise html kod. Kdyz to ale udelam na stanici za routerem tak to nevypise nic. Dalsi zajimavosti je: ping6 www.nic.cz funguje jak na routeru tak na stanicich ale IP6 adresa je na kazdem jina (pritom oba pouzivaji stejny DNS server). router:
64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=15.1 msstanice:
64 bytes from 2001:1488:0:3::2: icmp_seq=1 ttl=63 time=16.4 msHledal bych chybu v radvd.conf, DNS nebo firewallu ale me zarazi to ze nefunguji pouze stranky od nic.cz jinak ostatni ipv6 stranky chodi bez nejmensiho problemu. Diky za pomoc
Řešení dotazu:
ip link set dev sit0 mtu 1280
.
Pak se to zlepšilo, dnssec.cz je ok, ale nic.cz se stále nedostanu...
20:30:56.281690 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56 20:31:01.427932 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56 20:31:02.711026 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxx:769.1041 > 2002:d91f:cd32::1.http: S 7522974:7522974(0) win 16384 <\mss 1440> 20:31:02.745220 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1:xxxx:769: ICMP6, neighbor solicitation, who has xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769, length 32 20:31:02.745698 IP6 xxxx:xxxx:xxxx:1:18c4:74c1:xxxx:769 > fe80::21d:60ff:fe74:xxxx: ICMP6, neighbor advertisement, tgt is xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769, length 32 20:31:02.745714 IP6 2002:d91f:cd32::1.http > xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041: S 2414926498:2414926498(0) ack 7522975 win 5680 <\mss 1420> 20:31:02.746235 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041 > 2002:d91f:cd32::1.http: . ack 1 win 17040 20:31:02.746294 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041 > 2002:d91f:cd32::1.http: P 1:455(454) ack 1 win 17040 20:31:02.789017 IP6 2002:d91f:cd32::1.http > xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041: . ack 455 win 6432 20:31:05.800936 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56
Co se tyka tcpdump tak na vnejsim rozhrani se neda IPv6 dumpovat kdyz to jde skrze IPv4 tunel.Já měl za to, že mi to tcpdump (nevím verzi) rozklíčoval až na IPv6.
1041 se mi zdá jako neuvěřitelně nízký port na klientskou stranu. Podle všeho má www.nic.cz dvě IPv6 adresy:20:31:02.711026 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxx:769.1041 > 2002:d91f:cd32::1.http: S 7522974:7522974(0) win 16384 <\mss 1440>
$ host www.nic.cz www.nic.cz has address 217.31.205.50 www.nic.cz has IPv6 address 2002:d91f:cd32::1 www.nic.cz has IPv6 address 2001:1488:0:3::2Z toho jedna je 6to4 odpovícající veřejné IPv4, že. Jestli správně chápu RFC 3484, tak by počítač se zdrojovou 6to4 adresou měl preferovat cílovou adresu 6to4, což aspoň na straně klienta preferuje.
Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB.Jinak s nativní adresou se připojuju bez problémů na obojí:
$ nc -6 -v 2001:1488:0:3::2 80 Connection to 2001:1488:0:3::2 80 port [tcp/http] succeeded! $ nc -6 -v 2002:d91f:cd32::1 80 Connection to 2002:d91f:cd32::1 80 port [tcp/http] succeeded!Takže pokud to nefunguje pouze lidem se 6to4, problém může být buď u CZ.NIC, nebo na straně lidí s 6to4. Doporučuju radši zkouknout IPv4 i IPv6 firewall, případně udělat test s oběma vypnutými. Ještě bych zkusil traceroute6. Pak stojí za zkoušku dávat volbu -s programu ping6 a zkusit jak velký paket projde. Případně dokonce zkusmo snížit MTU u nějakého klienta a otestovat s nižším. Ale určitě bych se nebál komunikovat i s CZ.NIC.
$ ping6 2002:d91f:cd32::1 PING 2002:d91f:cd32::1(2002:d91f:cd32::1) 56 data bytes 64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=5.04 ms 64 bytes from 2002:d91f:cd32::1: icmp_seq=2 ttl=64 time=5.24 ms 64 bytes from 2002:d91f:cd32::1: icmp_seq=3 ttl=64 time=3.38 ms
23:20:25.193391 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 1, length 64 23:20:25.198372 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 1, length 64 23:20:26.194743 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 2, length 64 23:20:26.199919 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 2, length 64 23:20:27.196190 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 3, length 64 23:20:27.199508 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 3, length 64Tzn, zafungovala preference 6to4 adresy. Pokud jde o HTTP...
# nc -6 -v 2002:d91f:cd32::1 80 nc: 2002:d91f:cd32::1 (2002:d91f:cd32::1) 80 [www] open
23:27:11.036775 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [S], seq 2763135321, win 5680, options [mss 1420,sackOK,TS val 180153199 ecr 0,nop,wscale 4], length 0 23:27:11.041637 IP6 2002:d91f:cd32::1.www > 2002:54f6:a172::1.44379: Flags [S.], seq 1393182434, ack 2763135322, win 5632, options [mss 1420,sackOK,TS val 1644033031 ecr 180153199,nop,wscale 7], length 0 23:27:11.041805 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [.], ack 1, win 355, options [nop,nop,TS val 180153201 ecr 1644033031], length 0 23:27:14.829449 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [F.], seq 1, ack 1, win 355, options [nop,nop,TS val 180154148 ecr 1644033031], length 0 23:27:14.833638 IP6 2002:d91f:cd32::1.www > 2002:54f6:a172::1.44379: Flags [F.], seq 1, ack 2, win 44, options [nop,nop,TS val 1644033411 ecr 180154148], length 0 23:27:14.833771 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [.], ack 2, win 355, options [nop,nop,TS val 180154149 ecr 1644033411], length 0Takže u mě žádný problém. Testuju s konfigurací:
# ip -6 address | grep 2002 inet6 2002:54f6:a172::1/16 scope global # ip -6 route | grep 2002 2002::/16 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0Je to nevyužitý počítač s Debianem squeeze (testing).
test:~# ping6 -c 1 www.nic.cz PING www.nic.cz(2002:d91f:cd32::1) 56 data bytes 64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=63 time=4.26 ms --- www.nic.cz ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.266/4.266/4.266/0.000 ms test:~# nc6 -v www.nic.cz 80 nc6: 2002:d91f:cd32::1 (2002:d91f:cd32::1) 80 [www] open ^C test:~# curl -v -I http://www.nic.cz/ * About to connect() to www.nic.cz port 80 (#0) * Trying 2002:d91f:cd32::1... connected * Connected to www.nic.cz (2002:d91f:cd32::1) port 80 (#0) > HEAD / HTTP/1.1 > User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18 > Host: www.nic.cz > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OKPro jistotu přidávám i dump:
10:27:23.585264 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 1, length 64 10:27:23.589410 IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 1, length 64 10:27:30.165737 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [S], seq 3032584461, win 5760, options [mss 1440,sackOK,TS val 190057990 ecr 0,nop,wscale 4], length 0 10:27:30.170167 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610: Flags [S.], seq 1676351567, ack 3032584462, win 5632, options [mss 1420,sackOK,TS val 1647994945 ecr 190057990,nop,wscale 7], length 0 10:27:30.170235 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [.], ack 1, win 360, options [nop,nop,TS val 190057991 ecr 1647994945], length 0 10:27:31.547976 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [F.], seq 1, ack 1, win 360, options [nop,nop,TS val 190058336 ecr 1647994945], length 0 10:27:31.552831 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610: Flags [F.], seq 1, ack 2, win 44, options [nop,nop,TS val 1647995083 ecr 190058336], length 0 10:27:31.552927 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [.], ack 2, win 360, options [nop,nop,TS val 190058337 ecr 1647995083], length 0 10:27:33.306395 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [S], seq 1878728742, win 5760, options [mss 1440,sackOK,TS val 190058775 ecr 0,nop,wscale 4], length 0 10:27:33.309709 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [S.], seq 514882641, ack 1878728743, win 5632, options [mss 1420,sackOK,TS val 1647995259 ecr 190058775,nop,wscale 7], length 0 10:27:33.309802 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 1, win 360, options [nop,nop,TS val 190058776 ecr 1647995259], length 0 10:27:33.310356 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [P.], seq 1:163, ack 1, win 360, options [nop,nop,TS val 190058776 ecr 1647995259], length 162 10:27:33.315637 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [.], ack 163, win 53, options [nop,nop,TS val 1647995259 ecr 190058776], length 0 10:27:33.815006 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [P.], seq 1:474, ack 163, win 53, options [nop,nop,TS val 1647995309 ecr 190058776], length 473 10:27:33.815118 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 474, win 427, options [nop,nop,TS val 190058902 ecr 1647995309], length 0 10:27:33.816673 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [F.], seq 163, ack 474, win 427, options [nop,nop,TS val 190058903 ecr 1647995309], length 0 10:27:33.820684 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [F.], seq 474, ack 164, win 53, options [nop,nop,TS val 1647995310 ecr 190058903], length 0 10:27:33.820787 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 475, win 427, options [nop,nop,TS val 190058904 ecr 1647995310], length 0Takže bych řekl, že to bude konfigurační problém na tvojí straně, CZ.NIC má zdá se vše v pořádku, tedy až na DNS. /etc/radvd.conf používám jednoduchý (br1 protože virtuální stroj na bridge):
interface br1 { AdvSendAdvert on; prefix 2002:54f6:a172:1::/64 { AdvOnLink on; AdvAutonomous on; }; };Důležité routy na routeru (na testování 6to4 netřeba default, stačí 2002::/16):
2002:54f6:a172:1::/64 dev br1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 2002::/16 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0Zkoušel jsi ten traceroute(6), jak jsem ti radil, nebo se namáhám zbytečně?
traceroute to www.nic.cz (2001:1488:0:3::2) from 2002:5892:cb9::1, 30 hops max, 24 byte packets 1 2002:c058:6301::1 (2002:c058:6301::1) 14.59 ms 14.942 ms 16.866 ms 2 2001:1488::1 (2001:1488::1) 14.852 ms 15.582 ms 14.712 ms 3 2001:1488::1 (2001:1488::1) 15.23 ms !S 17.289 ms !S 14.87 ms !Sze stanice (bohuzel ted nejsem na miste a bezi pouze XP):
Vypis trasy k www.nic.cz [2001:1488:0:3::2] 1 1ms < 1ms < 1ms 2002:58xx:xxxx::1 2 15ms 15ms 15ms 2002:c058:6301::1 3 17ms 16ms 16ms 2001:1488::1 4 * * * Vyprsel casovy limit zadosti
13:20:35.487988 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 10, length 64 13:20:35.492198 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 10, length 64 13:20:36.490012 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 11, length 64 13:20:36.496011 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 11, length 64 13:20:37.491306 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 12, length 64 13:20:37.496492 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 12, length 64Tedy samozřejmě mimo mé a tvé veřejné adresy, ta se lišit musí.
A, tak přecijen něco. Je tam špatná adresa. Při pingu ze stroje s 6to4 na jiný stroj, který má alespoň jednu 6to4 adresu, se má vybrat cíl 6to4, už jsem o tom výše psal. Doporučuju HTTP zkusit přímo na IP, například:traceroute to www.nic.cz (2001:1488:0:3::2) from 2002:5892:cb9::1, 30 hops max, 24 byte packets 1 2002:c058:6301::1 (2002:c058:6301::1) 14.59 ms 14.942 ms 16.866 ms 2 2001:1488::1 (2001:1488::1) 14.852 ms 15.582 ms 14.712 ms 3 2001:1488::1 (2001:1488::1) 15.23 ms !S 17.289 ms !S 14.87 ms !S
test:~# curl -g -I http://[2002:d91f:cd32::1]/ HTTP/1.1 302 Found Date: Sat, 29 Jan 2011 12:29:58 GMT Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g Location: http://www.nic.cz/ Content-Type: text/html; charset=iso-8859-1Jinak na skrývání IPv4 uvnitř IPv6 už se můžeš vykašlat, stejně jsi ji už jednou zapomněl. Spíš tam pak nahoď nějaký stavový firewall, na IPv4 i IPv6 a u toho, co otevřeš si hlídej klíče/hesla.
curl -g -I http://[2002:d91f:cd32::1]/ HTTP/1.1 302 Found Date: Sat, 29 Jan 2011 12:54:36 GMT Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g Location: http://www.nic.cz/ Content-Type: text/html; charset=iso-8859-1Curl na stanici
curl -g -I http://[2002:d91f:cd32::1]/ HTTP/1.1 302 Found Date: Sat, 29 Jan 2011 12:52:47 GMT Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g Location: http://www.nic.cz/ Content-Type: text/html; charset=iso-8859-1Takze to slape dobre. Me prijde jako kdyby se stranky NICu neustale smerovali sami do sebe (vlezu na nic.cz a tam se udelal redirect na nic.cz atd atd) protoze prohlizec chybu nehodi - pouze se porad snazi nacist stranku. Jeste me napadlo: nemuze byt problem v tom ze je to za dvojnasobnym NATem ? Ale me proste udivuje to ze ipv6 funguje vsude ok jenom u nic.cz pres ktery jsem vlastne tunelem pripojeny to nejde.
Takze to slape dobre. Me prijde jako kdyby se stranky NICu neustale smerovali sami do sebe (vlezu na nic.cz a tam se udelal redirect na nic.cz atd atd) protoze prohlizec chybu nehodi - pouze se porad snazi nacist stranku.To je jen redirect z IP adresy na pojmenovanou stránku, to je v pořádku. Zkus to samé, ale bez parametru -I, případně, pokud se nic zajímavého nedozvíš, přijdej -v. Já už mám teďka podezřejní, že se zařídne odpověď od CZ.NIC někde u Volného. Jak to funguje na IPv4? Vypisuje něco "iptables -L -t mangle"?
Jeste me napadlo: nemuze byt problem v tom ze je to za dvojnasobnym NATem ? Ale me proste udivuje to ze ipv6 funguje vsude ok jenom u nic.cz pres ktery jsem vlastne tunelem pripojeny to nejde.Takhle, 6to4 funguje na veřejné adrese. Takže záleží na typu NATu. Za dvojtou čistou maškarádou by to třeba nefungovalo, ale vůbec. Co je přesně v tomhle případě myšleno dvojtým NATem a proč se vůbec řeší souvislost NAT a 6to4? 6to4 jako takové totiž za NATem funguje/nefunguje, podle toho, jestli NAT doručuje protokol 41 (IPv6 in IPv4). IP maškaráda tradičně řeší pouze TCP, UDP, přidružené chybové zprávy a ICMP ECHO, ne zapouzdřené IPv6.
curl -g http://www.nic.cz ^C root@exchg:/opt# curl -g http://[2002:d91f:cd32::1]/ <\!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <\html><\head> <\title>302 Found<\/title> <\/head><\body> <\h1>Found<\/h1> <\p>The document has moved <\a href="http://www.nic.cz/">here<\/a>.<\/p> <\hr> <\address>Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g Server at 2002:d91f:cd32::1 Port 80<\/address> <\/body><\/html>Dvojnasobny natem myslim ze je ADSL modem na kterem je nastaveno aby vsechno prichozi smeroval na vnitrni IP kde je nas router, pres ktery je pripojena vnitrni sit (trosku takovy hybrid). Kdyby neslo 6to4 vubec tak to vubec neresim a prikladam tomuhle ale me zarazi ze vse funguje ok a je problem pouze s nic.cz
Dvojnasobny natem myslim ze je ADSL modem na kterem je nastaveno aby vsechno prichozi smeroval na vnitrni IP kde je nas router, pres ktery je pripojena vnitrni sit (trosku takovy hybrid).To by mělo jít přežít.
No jo, to je pořád o tom, že na těch holých IP není nic zajímavého. Ještě bych zkusil "curl -v http://www.nic.cz/". Měl by ukázat, že se spojilo a zůstat viset až při čekání na data. Pokud problém zůstane, až půjde ping6 na tvůj router (což mi nejde), nezbývá než kouknout na toto vlákno, začít prudit poskytovatele, a případně hledat workaround pro IPv6. Ale jestli je to tak, tak nejspíš ADSL modem ten workaround dělá aspoň pro IPv4, jinak bys měl problémy i s tím. Ale dokud nejde ani ten ping, není vůbec jasné v čem je problém. Ten ping by to chtělo napravit.curl -g http://www.nic.cz ^C root@exchg:/opt# curl -g http://[2002:d91f:cd32::1]/ <\!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
Kdyby neslo 6to4 vubec tak to vubec neresim a prikladam tomuhle ale me zarazi ze vse funguje ok a je problem pouze s nic.czTak vyzkoušej další, třeba i ipv6.google.com info.nix.cz, apod.
root@exchg:~# curl -v http://www.nic.cz/ * About to connect() to www.nic.cz port 80 (#0) * Trying 2002:d91f:cd32::1... connected * Connected to www.nic.cz (2002:d91f:cd32::1) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.5 > Host: www.nic.cz > Accept: */* >Jinak ping uz by ti mel jit. Nicmene nic.cz stale nefunguje. Je to fakt divny
Jinak ping uz by ti mel jit.Tož to mi už jde, z nativní adresy :). Ale z toho 6to4 mi to pořád nejde, nemáš to zakázané na firewallu?
19:13:26.875829 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 15, length 64 19:13:27.875768 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 16, length 64 19:13:28.875802 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 17, length 64 19:13:29.875822 IP 84.246.161.114 > 88.146.12.185: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 18, length 64 19Z mojí veřejné adresy chodí na tvojí veřejnou adresu IPv4 paket se zapouzřeným IPv6 paketem s ICMPv6 hlavičkou. A žádné odpovědi se mi nedostane. Ale není důvod, aby to k tobě nedošlo. Není tak, že blokuješ 6to4 pakety, které jdou z cizích IPv4 adres?
root@exchg:~# ping6 2002:54f6:a172::1 PING 2002:54f6:a172::1(2002:54f6:a172::1) 56 data bytes 64 bytes from 2002:54f6:a172::1: icmp_seq=1 ttl=63 time=27.3 ms 64 bytes from 2002:54f6:a172::1: icmp_seq=2 ttl=63 time=21.4 ms 64 bytes from 2002:54f6:a172::1: icmp_seq=3 ttl=63 time=23.6 ms 64 bytes from 2002:54f6:a172::1: icmp_seq=4 ttl=63 time=21.9 ms ^C --- 2002:54f6:a172::1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 21.449/23.590/27.392/2.344 ms root@exchg:~# curl -g -v 2002:54f6:a172::1 * getaddrinfo(3) failed for 2002:54f6:a172::1 * Couldn't resolve host '2002:54f6:a172:' * Closing connection #0 curl: (6) Couldn't resolve host '2002:54f6:a172:' root@exchg:~# curl -g -v http://[2002:54f6:a172::1] * About to connect() to 2002:54f6:a172::1 port 80 (#0) * Trying 2002:54f6:a172::1... connected * Connected to 2002:54f6:a172::1 (2002:54f6:a172::1) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.5 > Host: [2002:54f6:a172::1] > Accept: */* > < HTTP/1.1 200 OK < Date: Sat, 29 Jan 2011 19:12:05 GMT < Server: Apache/2.2.16 (Debian) < Last-Modified: Sat, 29 Jan 2011 19:07:50 GMT < ETag: "9c5-9b5-49b00e621c0af" < Accept-Ranges: bytes < Content-Length: 2485 < Vary: Accept-Encoding < Content-Type: text/html < X-Pad: avoid browser bug <aaaaaa222222SSSSSS2222222SSSS2a22222SSSSSSSS22aaaaaaaa222222SS222aaaZaaZZZZ 2222aaaaS2222222222222222SS2SS22222SSXXXSSXSSXSSSXXXXXSSXSXXXXXX7XSSSSSSS22 2222222aaaZZa222222a222222SS22a22SSX77rrr777X77XXXSSSSSXSSXSSSXXXSXSS22S222 22a2222aaaaaaa22222aaaZZa2aa2aa2222SSSSXXXSSSSXXXXXXSXSXXSSSSXSSSXX7X22SSS2 22222a222222222222aaaZZZZZaaZaaZZZaaaa2a2SSSSSSSXSXXXXXXXXSX7;..,;20X77XXXS 2SSSSSXSSSSSSSSSSSSSS2222aa2222aaaaaa222222SSX7X777XXXX7r: aMMMMBS7XX7XXX SSSSSSXXSXXSSX7:,::i:.:rXSSSSSS22222a2SSXX7XXX77rr;i, :WMMM@r.,;XSSSSS22 S22a222S2222XirWMMMMMM@a:;XSSXXXSSXXXX77;ii:,,,:...:rX0MMMMZ: ,;XSS2S222222 SSSS22aaa22X,2MMMWWW@@MMM2.:i:,,. ..i7ZB@MMMMMMMMMMMM07 :7SaaaZZaaaaa222 XSXSXXS2S7: rMMZWWWWWWW@MMMB0MMMMMMMMMMMMMMM@WMW@@W@@@@WMMZaZ8888ZZaa2222S2 rrr;77rriXMMMMMWWWWWWWWWWWMMMM@W@M@@@@@@WWWWWBWW@WW@8ZW@MXS0B00088ZZZZaaaa2 ;;iiiii:;ZX;,8MMWWW@@MMMMMMMM@W@WWWWB0@ 08a222SS22aZZZZ2BMir7r MMMMBBWWBBBBWWWWWWMMM0,:;rr7XXXXXX777rr77XX7X77X7X 0WWWBB088888ZZ8ZSZMMM8MMMMM@WWWWBBWW@WWWWWMM2,ir7r7r77XXX77rr;;;rr7XXSS2222 SSSaaaZZZaaa22222X;rWMMMMWWWWWWWWWWWWWWWWWMB;r77XXXXS2222SSX77rr;rr7XXX2aZa SSSSSSXXXXX7XXXX777;. XWMMM@WW@@@@WWWWWWMMM22a22222222222SSXX7rrrrrr7XXSSSS 2222SXXXX7XXX7XXXXXX7ri i0M@@MWMMMMM@MMMBZZ0B000000088ZZZZZZZZZaaa22SSSSXS 22aaZZ8Z888808888ZZZZaa2X:MZMMW ..78WMMZrXSSS2222aaaaaZZZZZZZZaZaaa222SS2SS 2SXXSS22aaZ880000BBBBB088S2BWMMXaX7 ;Mii7rr;;;i;;;;;;;rr777r7r7r7rrr7rr77XX 888ZZZZa2SSX77XXSSXSSSSS2SX7 8SrXMr;XX77r77rrrr;;;;;rrrr77r7r7rrrr;rr;i; Z8088ZZZZZZ22SSSSSXX7777rrrXai 7270Mr72aZZZZ888888888ZZZaSSXSXSSSX7r;i::;rS aaaSS2222aaaaaaZaZZZ888888Z88M; .MMrrSSXXXS2aaa2aaaa2S77rrrr777X77XXX2a888Z XXX7X77rrr7XXS222222aZZZ8ZZa7@2: 7M,;;;;iiii::,::,,...,:,.,::i;r;rr7X2ZZa22 XXr;ii::iiii;r777rrr7ri::iir,M,S MMZXS2Zaaa22SXX77777XS222222aaa2SXX777r7XX X77r;rr7XXXSSSSSXS22XrrXSa80Z080, 2Z8aaaZZ880BBWWWWWWWWWWWWWW@WWWWWB08ZZZZ i,:iirrrrr7rrrrr7a:;MMM@WBB0000WMW i8Z22aaa8Z888Z888000BBB88ZZZZ0BBW@MMMMB 822SXXaZa2XX77777Z rMM@8Z880BMM: :XBZaaa22222ZZZZZaa222XXXXXXXXXXXS2aZZ2 8WaSSr77XX2Z0@@@WMMX 7MM@0ZZZ:M2 ;0Z8aSX7r;7XaZaS77r;rXX2aa2SSXXXSSX7r; ;;7X;:ii.:..7SZ8BWZ; ;2S77 XB SiX;;rrr;ii;i::,::;r;7X;iii::,,.... , 282X, ..2a8W8Sr.,;a8WMMM@, 2BMW22@. 72a22S22a2aZZ8082;i;:,:iir7XSSXriii ,:SZ,7. i:i . ;.,.i7rSWMMMr ,2B0iM ,8SSSSXrr7777XXS22a2aZZ8880ZSXX280 . rZMZS8 r:.7 ri , ;08Z r8SBZ :;X7SaZ80Z227r:... .,. ,ir7X2 BBZZX7;2;.a8XSSr8000Z@MMMMW0082i ;8WX:70SMSSaa:iii;;rXX7X0MM@BB0Za2S77rr7rX* Connection #0 to host 2002:54f6:a172::1 left intact * Closing connection #0 root@exchg:~# curl -g -v 2002:54f6:a172::1 * getaddrinfo(3) failed for 2002:54f6:a172::1 * Couldn't resolve host '2002:54f6:a172:' * Closing connection #0 curl: (6) Couldn't resolve host '2002:54f6:a172:'
Nicmene nic.cz stale nefunguje. Je to fakt divnyAle vrací minimálně potvrzovací paket :). Takže to zas nahrává tom MTU. Totální bordel, protichůdné příznaky. Něco jako zácpa s průjmem zároveň :D.
ip -6 route show ::/96 via :: dev sit0 metric 256 mtu 1480 advmss 1420 hoplimit 0 2002:xxxx:xxxx:1::/64 dev br0 metric 1024 mtu 1500 advmss 1440 hoplimit 0 2002::/16 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0 2000::/3 via ::192.88.99.1 dev sit0 metric 1024 mtu 1480 advmss 1420 hoplimit 0 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0 default dev sit0 metric 1024 mtu 1480 advmss 1420 hoplimit 0
2002:xxxx:xxxx:1::/64 dev br0 metric 1024 mtu 1500 advmss 1440 hoplimit 0 2002::/16 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0Tady s tím rozdílem v MTU a MSS si musí ty stroje v pohodě poradit, ale je zajímavé vědět, jestli za tím není nějaké ADSL... což v tvém případě (pardon za využití nechtěně zveřejněného údaje) zřejmě je. Dost možná, že tvůj poskytovatel nereaguje správně na příliš velké pakety a zatímco režie 20B na IPv4 hlavičku tunelovaných paketů je OK (širší trasa je u tebe, tvůj router jistě chyby vrací), u té 8B režie bych se ani nedivil, kdyby to neprošlo. Zkusil bych testovat s natvrdo nastaveným MTU 1492 místo 1500 proti ADSL modemu. MTU sit0 by mělo automaticky vyjít o 20 bajtů nižší. Můžeš postnout default route pro IPv4? Vnitřní síť by teoreticky měla zůstat jaká je. Kdyby to nešlo, tak bych zkusil vnitřní síti nastavit MTU stejné jako má tunel, ale je potřeba vždy nastavovat na všech zařízeních stejného linku, jinak bude síť blbnout. Je to docela velká alchymie a bez vyzkoušení (nemám ADSL, nemám stejného poskytovatele, nemám tedy kde) se můžu lehce splést. Navíc osobně jsem tenhle problém řešil na IPv4-only síti a vyřešil zadáním TCPMSS pravidla do mangle tabulky.
Tohle je celkem ok, až na to, že 1480+20 přes ADSL (1492) neprojde a bohužel ne všude si to poradí samo. Ale podle aktuálního standardu se má dávat default route pro ::/0, stejně jako se to dělalo na IPv4. Do budoucna se počítá s možným vyhrazením dalšího rozsahu.2000::/3 via ::192.88.99.1 dev sit0 metric 1024 mtu 1480 advmss 1420 hoplimit 0
A... tady ta default (::/0) je, takže dohromady to dělá bordel. Myslím, že místo těchto dvou pravidel by mělo být pouze to, které doporučuje i CZ.NIC v návodu:default dev sit0 metric 1024 mtu 1480 advmss 1420 hoplimit 0
default via ::192.88.99.1 dev sit0Je to taková změť spousty drobných pro danou situaci neškodných konfiguračních nedostatků, plus ta chyba při vybírání správné adresy z DNS, plus tradiční problémy s poskytovateli ADSL připojení, že se nakonec můžou nějaké chyby zkombinovat a projevit se i jednoduchém příkladě s www.nic.cz, kde by to správně mělo fungovat už jen tím, že funguje 6to4, radvd a forwarding. A lehčeji se to přehlédne.
default via 192.168.254.1 dev eth1 eth1: <\BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc htb state UNKNOWN qlen 16 link/ether 00:00:1c:dc:45:7f brd ff:ff:ff:ff:ff:ff
Dalsi zajimavosti je: ping6 www.nic.cz funguje jak na routeru tak na stanicich ale IP6 adresa je na kazdem jina (pritom oba pouzivaji stejny DNS server). router:64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=15.1 msstanice:64 bytes from 2001:1488:0:3::2: icmp_seq=1 ttl=63 time=16.4 ms
xhire@fusinka ~ $ host www.nic.cz www.nic.cz has address 217.31.205.50 www.nic.cz has IPv6 address 2001:1488:0:3::2 www.nic.cz has IPv6 address 2002:d91f:cd32::1
ping6 2001:ad0::1
. A ten mi nikdy nešiel (hoci ping na ipv6.google.com prejde). Dnes som pátral po príčine a zistil som, že ICMP echo-request pakety odchádzajú, ale ako odpoveď na ne prichádzajú pakety z 192.88.99.1 a s protokolom 47. Čo je 47? GRE - Generic Routing Encapsulation. Nikdy predtým som na takú potvoru nenarazil. Tie pakety blokoval môj firewall a keď som ich povolil, tak ne môj systém odpovie ICMP paketom "destination port unreachable". Možno to bude súvisieť s tým, že moje jadro hovorí "# CONFIG_NET_IPGRE is not set". Zatiaľ som neskúšal tú voľbu povoliť.
Takže riešenie nemám, len tip pozrieť sa, či niečo podobné nenastáva aj u vás.
Mimochodom to čo tu zaznelo, že
Odchozí data půjdou nejspíš přes relay na CZ.NIC, ovšem příchozí se můžou vracet přes jinou mašinu.je pravda, ale myslím, že tomu pomohlo iptables pravidlo s
-m state --state ESTABLISHED,RELATED
IN=eth1 OUT= MAC=00:00:1c:dc:45:7f:00:1b:fc:03:f1:a0:08:00 SRC=192.88.99.1 DST=192.168.254.254 LEN=124 TOS=0x00 PREC=0x00 TTL=242 ID=12990 DF PROTO=47a dalsi zajimava vec kdyz je nastaveny firewall
iptables -A INPUT -i eth1 -p 41 -m state --state RELATED,ESTABLISHED -j ACCEPTtak na stanice za routerem neprojde ping6 www.nic.cz ale projde ping6 ipv6.google.com logovani firewalu pise
IN=eth1 OUT= MAC=00:00:1c:dc:45:7f:00:1b:fc:03:f1:a0:08:00 SRC=217.31.205.50 DST=192.168.254.254 LEN=124 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=41pokud nastavim
$IPTABLES -A INPUT -i eth1 -p 41 -j ACCEPTtak projde ping6 jak na www.nic.cz tak na ipv6.google.com Ale jak rikam - jiz jsem testoval s uplne vypnutym firewallem resp. vsechno povoleno a stejne bez uspechu
Rozdíly hledej tcpdumpem na vnějším rozhraní :).iptables -A INPUT -i eth1 -p 41 -m state --state RELATED,ESTABLISHED -j ACCEPTtak na stanice za routerem neprojde ping6 www.nic.cz ale projde ping6 ipv6.google.com
tak projde ping6 jak na www.nic.cz tak na ipv6.google.com Ale jak rikam - jiz jsem testoval s uplne vypnutym firewallem resp. vsechno povoleno a stejne bez uspechuTo mě právě fascinuje. Že ti v určitou chvíli jde ping na všecho, dokonce tobě posílám i přes tvé ADSL pakety velikosti 1500 (jestli správně počítám), a dostávám takové zpátky, což by mělo vyloučit problémy s MTU. Na tvym místě bych už kotaktoval CZ.NIC, protože mají více zkušeností... ale problém podle mě nebude ani přímo u nich, ale někde mezi váma.
ip tunnel add sit0 mode sit remote any ip link set dev sit0 mtu 1472 up ip -6 address add 2002:xxxx:xxxx::1/16 dev sit0 ip -6 route add default via ::192.88.99.1 dev sit0 ip -6 address add 2002:xxxx:xxxx:1::1/64 dev br0Nastaveni radvd.conf:
interface br0 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvLinkMTU 1472; prefix 2002:xxxx:xxxx:1::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; };Jeste jednou diky vsem za pomoc.
Tiskni
Sdílej: