ipv6 6to4

Hálózatok általános

Hi!

Egy Cisco RVS4000-es mögött szeretnék ipv6-ot beállítani. Az eszközben van egy olyan lehetőség, hogy IP mode:dual stack IP, ami a doksi szerint 6to4-et jelent. Linux alatt az eth0-nak van is megfelelő ipv6-os címe, de a traceroute6 csak a router belső címéig megy el. Mi lehet a gond?
Az internet-szolglátatónknál kell lennie a másik 6to4 routernek, vagy az anycast-tal beszerzett router bárhol lehet a világon? A szolgáltatónk legjobb tudomásom szerint nem támogatja az ipv6-ot...
Esetleg a tűzfal akasztja meg a továbbjutást? Erre azért gondolok, mert csak ipv4-es tűzfalszabályokat lehet beállítani. Márpedig, ha bekapcsolom a 6to4-et, belül ipv6-os címek vannak, erre is kellenének szabályok.
Csak most kezdtem ismerkedni az ipv6-tal, úgyhogy bocs, ha butaságot írok/kérdezek.

  • 1634 megtekintés

( turdus | 2011. 01. 06., cs – 09:59 )

"traceroute6 csak a router belső címéig megy el"
"A szolgáltatónk legjobb tudomásom szerint nem támogatja az ipv6-ot..."
Mi nem érthető ezen?!?
Egyébként a tűzfal szempontjából mindegy, hogy milyen ipv6-os címek mennek 6to4-ben, mivel az számára sima payload. Inkább azzal lehet gond, hogy az encapsulation protokollt nem engedi át, szvsz (csak tipp).

Mint írtam, most kezdek ismerkedni az ipv6-tal. Mivel a szolgáltató nem támogatja az ipv6-ot, ellenben a 6to4 pont arra szolgál, hogy kifelé ipv4-gyel forgalmazzon a routerem (majd pedig egy másik router alakítsa vissza a csomagokat ipv6-ra, az ipv6-os hálózatba), továbbá a routerem eleve csak ezt a lehetőséget adja az ipv6-ra, ezért gondolom, hogy működnie kellene. Én eddig így értettem meg, de előfordulhat, hogy nem jól értem.

( sibike | 2011. 01. 06., cs – 09:57 )

Van globális címe a hostoknak? Ha nincs akkor be kellene az RA daemont is konfigurálni a routeren.

Annak a hostnak, amelyen a parancsot kiadtam, van. Van egy 2002 kezdetű, és egy fe80 kezdetű. A 2002 a global, ami a 6to4-es működéskor használatos. Nem akarom ide leírni, de a cím érvényes szerintem, mert a folytatása a router külső ipv4-es címének hex átirata, a többi pedig a MAC addr.-ből képzett.

interfaces:

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.7
gateway 192.168.0.253
netmask 255.255.255.0
broadcast 192.168.0.255

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3e:8f:c9:26
inet addr:192.168.0.7 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2002:102:304:0:216:3eff:fe8f:c926/64 Scope:Global
inet6 addr: fe80::216:3eff:fe8f:c926/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5325 errors:0 dropped:0 overruns:0 frame:0
TX packets:1916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:668222 (652.5 KiB) TX bytes:1983000 (1.8 MiB)
Interrupt:246

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1407 errors:0 dropped:0 overruns:0 frame:0
TX packets:1407 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1104979 (1.0 MiB) TX bytes:1104979 (1.0 MiB)

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.253 0.0.0.0 UG 0 0 0 eth0

# traceroute6 hup.hu
traceroute to hup.hu (2001:4c48:1:f800::6), 30 hops max, 80 byte packets
1 2002:102:304::1 (2002:102:304::1) 1.500 ms 1.663 ms 2.431 ms
2 2002:102:304::1 (2002:102:304::1) 2.801 ms !H 2.705 ms !H 3.226 ms !H

RVS4000-en:
ipv6:
2002:102:304::1/64
Az eszköz Gateway módban van, és természetesen be van kapcsolva a dual stack IP. A RIP nincs bekapcsolva, nem tudom, kellene-e.

MTU:1200! (voltak oldalak, melyek nem mentek enélkül. Az gáz, hogy az ipv6-nak 1280 a minimum, de ahhoz, hogy ilyen értékkel próbálkozzak, át kéne konfigolnom a squidet futtató szervert is, erre pedig alkalmat kell találnom).

Nem *-ot használtam, hanem 102:304 értéket mindenhol következetesen a router külső címének hexa alakja helyett.

Direktben nem szűröm. Más kérdés, hogy mit engedek. A szerverek (az a gép is szerver lesz, amin kipróbáltam az ipv6-ot) ki vannak engedve teljesen (allow all protocol), de ez megint nem jó, mert az ipv4-es címükre vonatkozik ez... A záró szabályba belefuthat, hiszen az mindent tilt, ami addig nem illeszkedett semelyikre. Most beállítottam 3 szabályt, amik icmp-re vonatkoznak: engedélyeztem a lan IF-ről bármerre a ping-et, az ICMP timestamp-ot, és az ICMP info-t. Ennyi lehetőség van, ami az ICMP-hez kapcsolódik, viszont ez nem segített. Felmerült bennem, hogy mennyivel vagyok ezzel előrébb, ha ezek esetleg csak a v4-re vonatkoznak...
Be van állítva még a block WAN request, ami minden kívülről kezdeményezett dolgot tilt, nem tudom kellene-e, hogy kívülről kezdeményezhessenek ilyent?
ipv6 kiengedése: erre nem láttam külön lehetőséget, csak tcp/udp szolgáltatásra állíthatok be szabályokat, úgyhogy erre ötlet? Kipróbáltam még egy olyan szabályt, hogy a lan-ról bárki bármit bármerre, de ez sem segített.

ICMP Fragmentation needed üzeneteket be kell engedni, az MTU problémáknak ez szokott az oka lenni.
Ettől függetlenül a 6to4 tunnelnek működnie kellene. Innentől nem marad más hátra, mint snifferelni a wan forgalmat és addig tekergetni a tűzfalat amíg meg nem látod az IP proto IPv6 csomagokat.

A block WAN request beállítás miatt nem. Sajnos nem látom át annyira ezt a kérdést, hogy tudjam, kell-e bármiféle külső kezdeményezést engednem? Eddig azt értettem meg a tűzfalakkal kapcsolatban, hogy alapból mindent tiltsak, és csak azt engedélyezzem, amiről tudom, hogy kell. Persze, ezzel nem mondok újat.

( PunishR v | 2011. 01. 06., cs – 11:22 )

192.88.99.1 anycast cím bárhol lehet, azon át kéne forgalmaznod.
Szolgáltató nem nagyon szokta ezt szűrni. Viszont nem nagyon preferálják a 6to4 címet a programok, tehát míg normál global címnél először v6on próbálkoznak utána v4en 6to4 esetében v4 preferált.

Arra figyelj hogy ne 6to4 relay ként konfigold.