A hagyományos IP címek elfogytak. Természetesen még van tartalékuk az internetszolgáltatóknak, de az átállás azért lassan-lassan megkezdődik IPv6-ra ami a föld lakosságánál is sok ezerszer több címet biztosít. Ha már az összes internetes eszköz átállt volna, akkor ugyanolyan észrevétlenül kapnánk a szolgáltatóktól az IPv6-os címeket mint a mostani IPv4-et, de sajnos itt még messze nem tart az átállás. Ennek ellenére bárki számára be lehet szerezni egy címet otthoni célra amivel kipróbálható és akár tartósan is használható az IPv6.
Áttekintés
Valószínűleg majdnem mindenki akinek otthoni internet előfizetése van, útválasztó (
router) segítségével osztja el azt a lakásában, ami pedig
NAT-ot használ a gépek címzéséhez. Ez azt jelenti, hogy a belső gépeknek ad egy 192.168.1.* (esetleg más) magánhálózati címet ami az internet felől nem érhető el, és csak egy közös valódi címet használnak ami az útválasztó eszközé. Ez a megoldás sok problémát felvet. Nem lehet a gépeket az internet felől közvetlenül megszólítani, megkülönböztetni bizonytalan és nehézkes, a routernek pedig erőforrás és memóriaigényes feladata van. A címek elfogyása mellett többek között ezeknek a kiküszöbölésére is ad lehetőséget az IPv6. Internetszolgáltatói támogatás nélkül természetesen ezek nem mind tökéletesen elérhetőek, de nagy részüket azért igénybe lehet venni.
Ami már működik
Az IPv6 alatt ugyan úgy működnek majd a szolgáltatások mint IPv4 alatt, nem lehet majd különbséget tapasztalni. A nagy oldalak, a Google, Wikipédia, Facebook már elérhetőek IPv6 alatt is, de nem nyújtanak extra funkcionalitást.
Az aktuális gép böngészésre használt kapcsolatának (IPv4/6) működése kipróbálható az
test-ipv6.hu oldalon. A Google külön is fenntart egy címet (
ipv6.google.com), amin
csak IPv6 alatt érhető el a kereső, de a normál címein is működik IPv6.
Amiben igazából érdekességeket lehet majd tapasztalni azok a hálózati eszközök (pl. ping6), illetve az hogy minden port "nyitott" tehát egy gép IPv6-on nem szorul be a router mögé.
IPv6 cím beszerzése
IPv6 címet ideálisan az internetszolgáltatótól, vagy ennek hiányában IPv6 csatornán (
tunnel) keresztül lehet szerezni. Az internetszolgáltatók közül Magyarországon néhány már ad ki lakossági kapcsolatokra IPv6 címeket (Externet, T-home DSL és Optika). Ha van rá lehetőség, komoly használatra mindenképpen a szolgáltatól érdemes címet igényelni.
(T-home IPv6 igénylés). Más esetben marad a tunnel használata.
IPv6 tunnelből rengeteg van, de érdemes magyarországit választani. Az egyetlen ismert ilyen a
SixXS rendszerében van, ezért innentől kezdve csak ezzel foglalkozom. A magyar hozzáférést itt a UPC biztosítja. A tunnel létesítéséhez először
regisztrálni kell a SixXS rendszerébe. Valódi adatokat kell megadni, mert emberi ellenőrzés történik. A regisztráció után szokás szerint megerősítő e-mailt küldenek. Ingyenes e-mail címekkel a tájokoztatás szerint
nem engednek beregisztrálni, ez alól valószínűleg a gmail és a hotmail kivételek.
Miután egy regisztrációt elfogadtak (erre várni kell) egy újabb értesítő e-mailt küldenek, amiben a felhasználónév és jelszó található. Ezzel lehet bejelentkezni az oldalra és új tunnelt igényelni. (
Home ->
Request tunnel) Itt a kapcsolat típusára érdemes kitérni:
ayiyaAutomatikusan felkonfigurált csatorna, ami működik dinamikus IP-cím NAT mögül is. (Folyamatosan nyitva tartott kapcsolattal működik)
heartbeatAutomatikusan felkonfigurált csatorna dinamikus IP-címekhez, de megköveteli a célgép elérhetőségét (NAT mögül csak beállított DMZ vagy átirányítás esetén működik)
staticStatikus IP címekhez, megköveteli a célgép elérhetőségét.
Otthoni használatra nagy valószínűséggel az
ayiya a legmegfelelőbb.
Az új csatorna elfogadására ismételten várni kell.
Az IPv6 cím beállítása
A SixXS rendszeréhez van egy kiváló segédprogram, az
aiccu. Windows bináris, és nyers forráskód is letölthető, de én
Ubuntu 12.04 LTS-t fogok használni. Ezen a rendszeren az
aiccu tárolókból is telepíthető:
sudo apt-get install aiccu
A telepítés alatt megkérdezi a felhasználónevet és a jelszót, ez megegyezik a SixXS weboldalon használttal. Később is módosítható.
Érdemes még a program beállítófájlába belenézni:
/etc/aiccu.confA telepítés után, itt is beállítható vagy módosítható a felhasználónév és jelszó. A fontosabb sorok kiemelve, kommentelve:
# Under control from debconf, please use 'dpkg-reconfigure aiccu' to reconfigure
# AICCU Configuration
# Login information (defaults: none)
username FEHLASZNALOHELYE # Felhasználónév
password JELSZOHELYE # Jelszó
# Protocol and server to use for setting up the tunnel (defaults: none)
protocol tic
server tic.sixxs.net
# Interface names to use (default: aiccu)
# ipv6_interface is the name of the interface that will be used as a tunnel interface.
# On *BSD the ipv6_interface should be set to gifX (eg gif0) for proto-41 tunnels
# or tunX (eg tun0) for AYIYA tunnels.
ipv6_interface sixxs
# The tunnel_id to use (default: none)
# (only required when there are multiple tunnels in the list)
#tunnel_id TUNNELNEVE
# Be verbose? (default: false)
#verbose true #Írja ki mibaja
# Daemonize? (default: true)
# Set to false if you want to see any output
# When true output goes to syslog
#
# WARNING: never run AICCU from DaemonTools or a similar automated
# 'restart' tool/script. When AICCU does not start, it has a reason
# not to start which it gives on either the stdout or in the (sys)log
# file. The TIC server *will* automatically disable accounts which
# are detected to run in this mode.
#
daemonize true #Futás háttérben
# Automatic Login and Tunnel activation?
automatic true #Automatikus indulás
# Require TLS?
# When set to true, if TLS is not supported on the server
# the TIC transaction will fail.
# When set to false, it will try a starttls, when that is
# not supported it will continue.
# In any case if AICCU is build with TLS support it will
# try to do a 'starttls' to the TIC server to see if that
# is supported.
requiretls false
# PID File
#pidfile /var/run/aiccu.pid
# Add a default route (default: true)
#defaultroute true
# Script to run after setting up the interfaces (default: none)
#setupscript /usr/local/etc/aiccu-subnets.sh
# Make heartbeats (default true)
# In general you don't want to turn this off
# Of course only applies to AYIYA and heartbeat tunnels not to static ones
#makebeats true
# Don't configure anything (default: false)
#noconfigure true
# Behind NAT (default: false)
# Notify the user that a NAT-kind network is detected
#behindnat true
# Local IPv4 Override (default: none)
# Overrides the IPv4 parameter received from TIC
# This allows one to configure a NAT into "DMZ" mode and then
# forwarding the proto-41 packets to an internal host.
#
# This is only needed for static proto-41 tunnels!
# AYIYA and heartbeat tunnels don't require this.
#local_ipv4_override
5-6: Az előbb említett belépési azonosító.
23: Írja ki részletesen mi történik. Ez nagyon hasznos lehet, nem kötelező.
35: Fusson a háttérben démonként. Ezt első kipróbáláskor érdemes hamisra állítani (false) hogy látható legyen mi történik. Automatikus működéshez vissza kell kapcsolni true értékre.
38: Rendszer indulással automatikusan betöltődhet-e az IPv6 is
69: Jelzi hogy a csatlakozás NAT mögül történik. Ennek automatikus érzékelésére is képes, nem kötelező.
A program a következő parancsokkal tesztelhető:
aiccu autotest
aiccu start
Az első parancs egy tesztet készít a kapcsolatról, a második pedig felépíti az IPv6 csatornát. Ha minden rendben történik akkor a
már említett tesztoldalra lépve látható a kapott az IPv6 cím és néhány információ a kapcsolat minőségéről is.
Egy ilyen módon beállított gépen újraindítás után már automatikusan fel fog épülni a kapcsolat, és használhatóak az IPv6-os szolgáltatások is.
Probléma esetén, a következő parancsok hasznosak lehetnek:
# Az aiccu újrabeállítása
sudo dpkg --reconfigure aiccu
# A hibaüzenetekhez szükséges program telepítése és futtatása
sudo apt-get install busybox-syslogd
sudo logread
Amennyiben a kliens gép WiFi-n csatlakozik, ismert hiba hogy felfüggesztés után visszatérve nem kap újra IPv6-os címet. A hiba oka hogy az aiccu hamarabb akar elindulni és IPv6-os csatornát kiépíteni mint a gép csatlakozni tudna a hálózatra, így természetesen nem fog felépüni a kapcsolat. Erre megoldást jelent egy szkript létrehozása ami az aiccut minden új internet-kapcsolat létrejötte után, (így a WiFi kapcsolódás után is) újraindítja. Ehhez a /etc/network/if-up.d mappába kell elhelyezni egy indítófájlt:
sudo echo '#!/bin/sh
echo "New interface is up, Restarting AICCU"
/etc/init.d/aiccu restart
' >> /etc/network/if-up.d/aiccu
sudo chmod +x /etc/network/if-up.d/aiccu
Biztonság IPv6 alatt
Nagyon fontosnak tartom megemlíteni hogy a tunnel beállítása után a
gép rendelkezik egy publikus címmel, tehát az internet felől (de legalábbis az IPv6 része felől) elérhető. Olyan mintha közvetlenül, router nélkül csatlakozna az internetre. Bár önmagában ez nem jelenti bárki számára hozzáférést, mindenképpen elővigyázatlan dolog!
A probléma legegyszerűbben egy tűzfal telepítésével és beállításával orvosolható:
sudo apt-get install gufw
Ezek után a
Tűzfalbeállítás programban (
<ALT>+F2 gufw) és kapcsolható be a tűzfal. Ehhez jobb alul az
Unlock vagy
Feloldás gomb használata, majd a jelszó megadása után a tűzfalat bekapcsolt állapotba (
Status: On) és a bejövő forgalmat tiltásra (
Incoming: Deny) kell állítani.
Tűzfalbeállítás után ha egy program nyitott portot igényel azt a helyes működéshez hozzá kell adni a kivételekhez. Ilyen program például az aktív állapotú torrent kliens.
Teljesítmény és statisztikák
Az IPv6 tunnelről a sebesség tekintetében: Ez egy kényes dolog, ugyanis az IPv6 csomagok tesznek egy tiszteletkört a csatorna végpontjáig pluszban (UPC) ami jelentősen megnövelheti a válaszidőt:
Ping:
$ ping -c 5 google.hu
PING google.hu (173.194.35.151) 56(84) bytes of data.
64 bytes from muc03s01-in-f23.1e100.net: icmp_req=1 ttl=56 time=42.7 ms
64 bytes from muc03s01-in-f23.1e100.net: icmp_req=2 ttl=56 time=39.6 ms
64 bytes from muc03s01-in-f23.1e100.net: icmp_req=3 ttl=56 time=56.5 ms
64 bytes from muc03s01-in-f23.1e100.net: icmp_req=4 ttl=56 time=42.5 ms
64 bytes from muc03s01-in-f23.1e100.net: icmp_req=5 ttl=56 time=40.7 ms
--- google.hu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 39.603/44.445/56.599/6.192 ms
$ ping6 -c 5 google.hu
PING google.hu(muc03s02-in-x18.1e100.net) 56 data bytes
64 bytes from muc03s02-in-x18.1e100.net: icmp_seq=1 ttl=55 time=113 ms
64 bytes from muc03s02-in-x18.1e100.net: icmp_seq=2 ttl=55 time=37.2 ms
64 bytes from muc03s02-in-x18.1e100.net: icmp_seq=3 ttl=55 time=44.9 ms
64 bytes from muc03s02-in-x18.1e100.net: icmp_seq=4 ttl=55 time=82.9 ms
64 bytes from muc03s02-in-x18.1e100.net: icmp_seq=5 ttl=55 time=74.3 ms
--- google.hu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 37.283/70.701/113.986/27.637 ms
Ezek az adatok egészen jók, bár a natív IPv4 kapcsolatnak azért láthatóan jobbak az adatai. Ez a hátrány természetesn natív IPv6 esetén nem jelentkezne.
Csatornázott IPv6-on 100 csomag átlagos pingje ~75ms lett, ez még mindig lényegesen jobb mint pl. egy mobilinternet esetén. Sebességet sajnos nem tudtam IPv6-on mérni, mert nem a csatorna hanem a szerver oldal volt a szűk keresztmetszet, a speedtest.net pedig nem támogatja még az IPv6-ot. Használat közben a tunnel nem okoz semmilyen érhezhető lassulást.
