IPv6 - tunnellel megvalósítva (Linuxot futtató számítógéppel)

A 2012. karácsonyi IPv6-fórumtéma ( http://hup.hu/node/120634 ) motivált arra, hogy nyissak itthon is az IPv6 kísérletek felé. Sajnos a Digi kábel felénk nem ad natív IPv6 elérést, így megoldottam tunnellel.

Ha valaki kedvet érez hozzá, segítségképp leírom, hogyan induljon el.

Tehát (ADSL és egyéb PPPoE bejelentkezéses esetben):

/etc/ppp/ip-up szkriptbe beleírni:

IPv4_ADDR=$IP
IP_numbers=`echo $IPv4_ADDR | tr "." " "`
IPv6_ADDR=`printf "2002:%02x%02x:%02x%02x::0922:4915:5204/128" $IP_numbers`

/sbin/ip tunnel del tun6to4
/sbin/ip tunnel add tun6to4 mode sit remote any local $IPv4_ADDR ttl 64
/sbin/ip link set dev tun6to4 up
/sbin/ip -6 addr add $IPv6_ADDR dev tun6to4
/sbin/ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

És még egy fontos: beengedni a külső interfészről a 41-es protokollt (IPv6 tunnel):
iptables -t filter -A INPUT -i ppp0 -p 41 -s 192.88.99.1 -j ACCEPT

A PPPoE újraindításával meg is kapja a publikus IPv6 címét a számítógép.

Teszt: ping6 -n time.kfki.hu

------ Vége az egygépes beállításnak, alább komplett otthoni LAN beállításáról írok -----------

De itt nem álltam meg, azt mondtam, hogy a teljes LAN-omban elérhető legyen az IPv6. Ehhez kellett egy olyan Linuxot futtató, tipikusan ATOM (D2500CC) vagy egyéb kisfogyasztású alaplap, amelyben 2 független ethernet kártya van. Netán bátrak USB-Ethernet átalakítóval is próbálkozhatnak.

eth0: internet felöli interfész
eth1: LAN felöli interfész
ppp0: PPPoE-s bejelentkezés során jön létre.
tun6to4: IPv6 over IPv4 tunnel létrehozása során jön létre.

Továbbá néhány szoftverből friss verzió kell. Tehát az alábbiak kellenek:

--> Linux kernelből legalább a 3.7-es (2012. december). Ebben jelent meg az IPv6-ra a NAT. Lefordítottam (3.7.1).
--> iptables: friss, legalább 1.4.17-es verzió (2012. december). Ebben jelent meg az ip6tables MASQUERADE kezelője. Le kell fordítani.
--> radvd (http://www.litech.org/radvd/) - Slackware alatt nem volt, így fordítottam egyet.

LAN konfigurálása IPv6-ra

Előre bocsátom, a a LAN-on levő laptopokhoz nem kell hozzányúlni, csak a routerként használt Linuxot kell az alábbiak szerint bekonfigurálni.

Az RFC szerint fd00::/8 helyi címzésre (lásd ipv4: 10.0/8, 192.168/16, 172.16/20) használatos. Tehát a routernek is használt szerverben az alábbi kell:

Szerver: ip -6 addr add fd00:1111:2222:3333::1/64 dev eth1 # ipv6 címe a szerver belső interfészének

/usr/local/etc/radvd.conf

interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix fd00:1111:2222:3333::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Majd el kell indítani a radvd-t. A -c (kis c) opcióval ajánlott előbb ellenőrizni az elgépeléseket.

/usr/local/sbin/radvd -C /usr/local/etc/radvd.conf

A fentiek alapján már a laptopok kaptak is IPv6 global címet. Az ifconfig parancs kimenete:


wlan0 Link encap:Ethernet HWaddr e0:2a:82:dc:3a:c5
inet addr:192.168.73.24 Bcast:192.168.73.255 Mask:255.255.255.0
inet6 addr: fd00:1111:2222:3333:e22a:82ff:fedc:3ac5/64 Scope:Global
inet6 addr: fe80::e22a:82ff:fedc:3ac5/64 Scope:Link
inet6 addr: fd00:1111:2222:3333:c1c:7ea8:83db:48c2/64 Scope:Global

Következhet a router IPv6 címfordításának beállítása és a routing engedélyezése

Ehhez kell a legalább 1.4.17-es iptables csomag.


echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
ip6tables -t nat -A POSTROUTING -o tun6to4 -j MASQUERADE

Teszt a helyi hálózaton lógó Linuxot futtató laptopról: ping6 -n time.kfki.hu

PING time.kfki.hu(2001:738:5001::1) 56 data bytes
64 bytes from 2001:738:5001::1: icmp_seq=1 ttl=57 time=24.1 ms
64 bytes from 2001:738:5001::1: icmp_seq=2 ttl=57 time=24.4 ms
64 bytes from 2001:738:5001::1: icmp_seq=3 ttl=57 time=24.5 ms

Fontos: ip6tables szoftverrel az IPv6-os tűzfalszabályokat is állítsuk be, mert az iptables csak IPv4-re korlátozta a portokat.

Jó szórakozást!

Update#1: az építő jellegű hozzászólások hatására tovább kísérleteztem a dinamikus IPv6 lehetőségeivel. Persze a statikus IPv6 szerencsésebb, de most szándékosan az egyszerűbben (regisztráció nélkül) lefogható dinamikus érdekelt.

Az eredetileg írt NAT-olás a legegyszerűbb megoldással létrehozható IPv6-os hálózatot biztosít a klienseknek. Hátránya, hogy ugyanúgy 1 IP címre NAT-ol, mint ahogy IPv4 esetén rákényszerültünk.

Hogyan hozható létre olyan kapcsolat, ahol a végberendezések önálló IP címmel rendelkeznek?

Ennek több módját is kipróbáltam. A tunnel szolgáltatónál nagyobb IPv6 tartomány is lefoglalható. Például egy /56-os tartomány is lefogható.

Egyik megoldás: simán routoljuk be a /64-es tartományt. Ez statikus IPv6 szolgáltatónál ( http://www.sixxs.net/ ) jó megoldást ad, hiszen fix IPv6 címek lesznek belül és fix a routing szabály is. Dinamikus IPv6 esetén ez több kellemetlenséget is magában hordoz. Például nincs fix IPv6 címmel rendelkező belső hálózat. Az ip-up -ban régi IPv6 route-ot kell felszámolni és az új belső tartományt átroutolni. A dinamikusan a ppp0 IPv4-es címét bemásoló radvd konfig:

interface eth1
{
IgnoreIfMissing on;
AdvSendAdvert on;
# Advertise at least every 30 seconds
MaxRtrAdvInterval 30;
prefix 0:0:0:2170::/64
{
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface ppp0;
# Very short lifetimes for dynamic addresses
AdvValidLifetime 300;
AdvPreferredLifetime 120;
};
};

Ezen a problémán dinamikus IPv6 esetén máshogy segítettem: kipróbáltam az SNAT-ot. Ekkor visszatértem az eredetileg írt helyi hálózatos (fd00::/8) radvd.conf-ra

/etc/ppp/ip-up fájlba további sort írtam bele, miközben a firewall fájlból kivettem az IPv6 MASQUERADE sort:

IPv6_TOstart=`printf "2002:%02x%02x:%02x%02x:2170:4321:8432:" $IP_numbers`
/usr/sbin/ip6tables -t nat -A POSTROUTING -s fd00:1111:2222:3333::/64 -j SNAT --to $IPv6_TOstart:10-$IPv6_TOstart:01fa

És még egy apróságot elkövettem: a firewall fájlba az ip6tables -t nat -F után egy "/usr/local/sbin/conntrack -F" sort raktam be ( http://conntrack-tools.netfilter.org/ ).
Erre azért volt szükség, mert miközben ping6 -n time.kfki.hu ment a laptopon és a PPPoE új IP címet kapott, sajnos beragadt a conntrack alapján a régi SNAT-ba a futó ping és egyéb aktív kapcsolat. Ezzel ezt az apró hibát is orvosolni tudtam.

Ennek eredményeképp a LAN-on felcsatlakozó kliens LAN-beli IP címmel fog rendelkezni. Internet felé azonban az imént írt ip6tables sor értelmében kap egy IP címet a közel 500-ból.

Ezzel megtaláltam azt a minimálisan jól használható megoldást, amit dinamikus IPv6 tunnel szolgáltató esetén jól lehet használni. Ennél - mint már említettem - már csak a fix IPv6 címtartománnyal lehet jobbat alkotni.

Végezetül: köszönet az építő szándékú hozzászólóknak. Jó kísérletezgetést!

Hozzászólások

Tök jó látni élő embert, aki kipróbálta az IPv6 NAT-ot, de szerintem itt a remek pillanat arra, hogy a működés okozta mámorban felejtsd is el rögtön, lehetőleg egy életre :)

A tunnel brokered nyilván nem csak 1 tunnel végponti IP címet ad, hanem teljes /48-as, vagy /56-os subnetet. (prefix)

Javaslom, hogy ezek közül egy rendes, /64-es publikus tartományt hirdess a "belső" gépeid irányába.

Egyébként, gratulálok, hogy eltervezted, kipróbáltad, és dokumentáltad az akciót!

Eredetileg én is NAT nélkülit akartam csinálni. Azonban egy problémám van, amit nem sikerült leküzdeni - hátha valaki tud megoldást rá.

Dinamikus az IP címem és az IPv6-os cím(tartományt) is ez szerint kell használnom.

1. vagy a radvd-nek az aktuális IPv6 tunnelbeli tartományt kellene LAN-ra hirdetnie.
2. vagy IPtartomány --> IPtartomány mappingot kellene csinálnom.

Bármi segítségnek örülök.

> 1. vagy a radvd-nek az aktuális IPv6 tunnelbeli tartományt kellene LAN-ra hirdetnie.

A radvd.conf-ban találsz erre példát:

For 6to4 support, include the Base6to4Interface option in each prefix section. When using a dynamic IPv4 address, set small prefix lifetimes to prevent hosts from retaining unreachable prefixes after a new IPv4 address has been assigned. When advertising to on a dynamic interface (e.g., Bluetooth), skip the interface if it is not active yet.

interface bnep0
{
IgnoreIfMissing on;
AdvSendAdvert on;
# Advertise at least every 30 seconds
MaxRtrAdvInterval 30;
prefix 0:0:0:5678::/64
{
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface ppp0;
# Very short lifetimes for dynamic addresses
AdvValidLifetime 300;
AdvPreferredLifetime 120;
};
};

Egyébként, én elfelejteném a 6to4-et, és keresnék egy olyan tunnel brokert, amelyik fix, dedikált prefixet ad.

Lassan, de haladok. Köszi a segítséget.
A fenti beállítás oké. A "prefix 0:0:0:"-ba szépen behelyettesíti a ppp0 interfész IP-jét. Oké.
Ahol még hibázik a dolog - és fixen kellett beírnom:

- tun6to4-re fogtam egy /63-as subnetet. Oké.
- eth1: a radvd-től nem kér IP címet. Hogyan lehet rávenni erre? Hiszen ez alapján állna be a (dinamikus IP-s) local route a LAN felé.

> - tun6to4-re fogtam egy /63-as subnetet. Oké.

/63? /48-at, vag /56-ot szokás allokálni végfelhasználónak.

> - eth1: a radvd-től nem kér IP címet. Hogyan lehet rávenni erre? Hiszen ez alapján állna be a (dinamikus IP-s) local route a LAN felé.

Ha bekapcsoltad a gépeden az ipv6 csomagok forwardolását - merthogy te vagy a router a helyi háló számára - akkor automatikusan kikapcsol a stateless autoconfig, tehát nem fog az eth1 IP címet kapni. Ez így rendben is van, tedd csak fel kézzel a kívánatos fix címet rá.

Az a baj, hogy nem fix, hanem dinamikus a tartomány, így a fenti tunnel szolgáltató által adott IPv6 is a 2002::/16 utántól dinamikus.
Tudom, fix szolgáltatóval egyszerűbb lenne, de én most már erre is kíváncsi vagyok.

Tehát mégegyszer:

- szolgáltatóm PPPoE-n dinamikus IPv4-et ad.
- a blogbejegyzésben írt szolgáltató 2002::akármit/MASK ad, ezzel elkerülve a dupla allokációt és így regisztrációmentesen tudja adni. A 63 nem probléma. Nem kell egész oktetnek lennie - működik.
- szóval dinamikus IPv6 tartománynál tartunk.

- dinamikus prefixű radvd megy, klienst meg is kapja a megfelelő prefixel az IPv6/64 -es tartománybeli címet (ppp0 ipv4-éből és MAC-ból generálva).
- router (Linux) azonban szintén ezt a dinamikus 2002::akármi::/64-et kellene hogy routolja az eth1 felé. Ugyanakkor ha változik az IPv4 címtartományom, akkor a régi IPv6 tartomány route szabálya meg kell hogy szűnjön.

"- a blogbejegyzésben írt szolgáltató 2002::akármit/MASK ad, ezzel elkerülve a dupla allokációt és így regisztrációmentesen tudja adni."

Ennél azért egyszerűbb a helyzeted, azért nincs "dupla allokáció", mert a "kapott" 2002:AABB:CCDD::/48 tartományod az aktuális IPv4 címed A.B.C.D hexadecimális formában.

Ebből kifolyólag, ahogyan már jelenleg is használod ezt a logikát az alap tunnel felhúzásánál csak ki kell egészítened a scriptedet, hogy eth1 felé felhúzzon egy ipt /64-es maszkkal.

Tudom, tudom, thread nekromanta meg minden, de akkor is! :-) A leírás jó, olyannyira, hogy én is ennek alapján kalapáltam össze az IPv6 tunelt. Ami a dolgot árnyaltabbá teszi, hogy a nagy T "home gateway" néven tisztelt eszköze mögött vagyok, azaz a tűzfalam már eleve NAT-olt IPv4 címet kap. Innen kezdve a leírásban szereplő beállításokon kell egy keveset csavarni ahhoz, hogy a dolog így is működő képes maradjon.

A legelső lépés, hogy a "home gateway" webes felületén fel kell vennünk mint DMZ host a tűzfalunk WAN lábának IP címét. Bár a "home gateway" MAC address alapján tudna fix IP-t adni, ezzel én nem foglalkoztam, hanem a tűzfalon is fix IP-t állítottam be a WAN lábra (192.168.1.254), meg ugyanazt a fix IP-t adtam meg DMZ hostként is és slussz! :-)

A második lépés, hogy a saját tűzfalunkon elvégezzük az IPv6 tunel kialakítását. Lássuk a scriptet:


#! /bin/bash -x


# IPv4 cim a valos IP cim frissiteni kell!
IPv4_ADDR=46.139.63.19

# Szamok elovetele IP cimbol
IP_numbers=`echo $IPv4_ADDR | tr "." " "`

# Az IP cim szamaibol kepezzuk az IPv6 cimet
IPv6_ADDR_WAN=`printf "2002:%02x%02x:%02x%02x::0922:49a8:3704/56" $IP_numbers`

# Az IPv6 tunel interface letrehozasa. Fontos, hogy itt a helyi NAT-olt IPv4 cimet adjuk meg!
ip tunnel add tun6to4 mode sit remote any local 192.168.0.254 ttl 64

# IPv6 tunel interface UP-ba kerul
ip link set dev tun6to4 up

# IPv6 tunel interface megkapja az IPv6 cimet
ip -6 addr add $IPv6_ADDR_WAN dev tun6to4
                                                                         
# Route-olas beallitasa. Fontos, hogy az IPv4 cimnel a tunel fogado oldalat kell megadni!
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
                                                                         
# Az IPv4 ala bujtatott IPv6 forgalom mukodesehez kell, hogy a fogado fele az IPv6 tunel be legyen engedve
iptables -A INPUT -i eth1 -p ipv6 -s 192.88.99.1 -j ACCEPT

A scriptet megnézve két dolog lehet szembe tűnő:
- a valós IP. Mivel az ezen a gépen nem ismert és az érdekelt volna, hogy működik-e így a dolog, ezért első körben bevasaltam, utána meg persze így maradt. (Még szerencse, hogy nem túl sűrűn változik az IP-m, noha nem fix IP-s a szolgáltatás. Tudom, több módja is van annak, hogy hogy szerezzük meg a valós IPv4 címet - most nem foglalkoztam vele.)
- az IPv6 címet a *valós* IPv4 cím alapján kell képezni, a tunel interface felhúzásakor viszont IPv4 címként a WAN láb NAT-olt, belső hálózatokba való IPv4 címét kell megadni.

Igazából ennyi - remélem, aki hasonló eszköz mögött ül, az hasznát veszi az itt leírtaknak.