Soneran IPv6 6rd & sen toteutus Ubuntussa


Hei,

 

Miten mahtaa pystyä sen tunnelin pystyttämään Ubuntussa, joka saa suoran IP osoitteen datakeskuksen verkosta, jossa backbonea operoi Sonera eli esim IP osoite on Soneran verkossa oleva?

 

Onko mitään tietoa mikä täsä mättää kun ei vaan yksinkertaisesti toimi?

 

Seuraavat tiedot ovat tiedossa:

 

  • Border Relay => 80.221.111.254
  • 6rd IPv6 Prefix => 2001:2003::/32
  • IPv6 DNS => 2001:4860:4860::8888 (Googlen)
  • Interface em1 => Internet

 

Testi confit seuraavaksi eli:

 

/etc/network/interfaces:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto em1
iface em1 inet static
address [My external IPv4 address]
netmask 255.255.255.248
gateway [My private gateway IP address]
post-up iptables-restore < /etc/iptables.up.rules
iface em1 inet6 static
address [Calculated IPv6 address from my IPv4]
netmask 32
gateway 2001:2003:50dd:6ffe::1

auto tun6rd
iface tun6rd inet6 v4tunnel
address 2001:2003::
netmask 32
local 80.221.111.254
endpoint any
ttl 64
up ip tunnel 6rd dev tun6rd 6rd-prefix 2001:2003::/32
up ip link set mtu 1280 dev tun6rd

ip6tables:

 

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

ip -6 route show:

 

::/96 via :: dev tun6rd  metric 256  mtu 1480 advmss 1420 hoplimit 0
2001:2003::/32 dev tun6rd proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
2001:2003::/32 dev em1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::1 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev tun6rd proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev em1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev venet0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
default via 2001:2003:50dd:6ffe::1 dev em1 metric 1024 mtu 1500 advmss 1440 hoplimit 0

 

Error:

 

root@localhost:~# ping6 ipv6.google.com
unknown host

 

 

Lähteet:

 


24 kommenttia

Kannattaa testata PING ensimmäiseksi IP:llä, eikä DNS:n kanssa, koska silloin jää epäselväksi kummassa vika on. Nyt PING tulos kertoo vain ja ainoastaan sen, että DNS resolve epäonnistui. Eikä sitä, että kulkeeko liikenne IPv6:lla ulos vai ei.

mm. Teredeoa (yuk) Windowssilla käytettäessä homma toimii juuri noin. Eli IPv6 AAAA recordien DNS ei ole käytössä vaikka se toimisikin nslookupilla, mutta jos käyttää IP-osoitetta, niin pingi kyllä kulkee.

Väärät menetelmtä ongelmatilanteen selvittelyssä johtavat usein sekaannukseen ja silloin on todella hankalaa tietää mikä on oikeasti se ongelman ydin.

Käyttäjätaso 4
Kunniamerkki +16

Itselläni on palvelin myös palvelinsalissa, mutta olen toteuttanut 6to4 tunnelilla ulos. Yhteys on myös Soneran.

 

Käytän bash scriptiä:

 

/sbin/ip tunnel add tun6to4 mode sit ttl 64 remote any local XX.XX.XX.XX
ip link set dev tun6to4 up
ip -6 addr add 2002:XXXX:XXXX::/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
ifconfig eth0 add 2002:XXXX:XXXX::1/64

ja tietenkin /etc/network/interfaces tiedostoon:

 

post-up sh [file.sh]

  

@olkituItse haluaisin välttää 6to4 käyttöä.

Käyttäjätaso 4
Kunniamerkki +16

Itse haluaisin välttää täysin IPv6 tunnelit, natiivina haluaisin kaiken...


@olkitu kirjoitti:

Itse haluaisin välttää täysin IPv6 tunnelit, natiivina haluaisin kaiken...


Toi on kyllä totta, mutta valitettavasti ei vielä mahdollista. :(

Käyttäjätaso 4
Kunniamerkki +16

Palvelintarjoajani ei ole vielä tilannut Soneralta natiivista IPv6, kun siinä on kytkemismaksu... IPv6 on ilmainen mutta kytkeminen maksaa ja kun sitä ei niin paljon kaivata vielä. 

 

Saitko pingattua Googlen IPv6 osoitteeseen. Kokeilitko traceroute6?


@olkitu kirjoitti:

Palvelintarjoajani ei ole vielä tilannut Soneralta natiivista IPv6, kun siinä on kytkemismaksu... IPv6 on ilmainen mutta kytkeminen maksaa ja kun sitä ei niin paljon kaivata vielä. 

 

Saitko pingattua Googlen IPv6 osoitteeseen. Kokeilitko traceroute6?


Olin eilen niin turhautunut niin sain sen hoidettua HE-Net:in tunnelilla.

 

sm@localhost:~$ traceroute6 google.fi
traceroute to google.fi (2a00:1450:400f:804::2003) from 2001:470:28:a37::1:1, 30 hops max, 24 byte packets
1 samip-2.tunnel.tserv24.sto1.ipv6.he.net (2001:470:27:a37::1) 14.421 ms 16.239 ms 14.672 ms
2 ge2-20.core1.sto1.he.net (2001:470:0:11e::1) 11.705 ms 15.245 ms 11.982 ms
3 2001:7f8:d:fe::115 (2001:7f8:d:fe::115) 11.744 ms 11.897 ms 13.893 ms
4 2001:4860::1:0:26ec (2001:4860::1:0:26ec) 30.563 ms 27.96 ms 33.682 ms
5 2001:4860:0:1::e5 (2001:4860:0:1::e5) 28.209 ms 28.187 ms 31.478 ms
6 arn09s05-in-x03.1e100.net (2a00:1450:400f:804::2003) 27.685 ms 28.028 ms 27.748 ms

(HE-NET tunnelilla)

Käyttäjätaso 4
Kunniamerkki +16

No hyvä että toimii jollakin tavalla jos IPv6 on välttämätön... Olisihan se hyvä että palvelimet vastaisi molemmilla IPv4 + IPv6... sitten vasta kuluttajalaitteet... 

Saas nähdä missä vaiheessa se tipping point tulee. Olen ihan varma että verkkojen ylläpitäjät on sitä mieltä että kuka nyt viitsii edes konfiguroida koko IPv4:sta, kun siitä on pelkkää haittaa. Mennään IPv6 only verkoilla niin kaikki on paljon selkeämpää. Puhumattakaan kaikeasta NAT hole punching roskasta ja CG-NAT:eista, joiden taakse vielä tupla nattina kuluttajien oman purkin NAT ja muista ongelmista käyttäjien ja rate-limittien kanssa, sekä jostain port forwardingeista. Ihan hirveetä ja turhaa säätämistä. Ihan sama kuvio on nähty uudelleen ja uudelleen, 64 bittisten käyttisten suhteen, Windows versioiden suhteen jne. Siis mitä, julkaisiko joku uuden pelin joka ei toimi täysin 32 bittisellä XP:llä, miksi joku tekee niin roskaa softaa.Eihän kukaan halua käyttää 64 bittisiä systeemeitä, kun niistä on kuulemma niin paljon ongelmia ja vaivaa.

 

Tämä on tietysti tulevaisuuden juttu joka jää nähtäväksi, jälkeenpäin katsoen kaikki näyttää niin ilmiselvältä ja siinä vaiheessa kun murros tapahtuu niin noista asioista puhuminen vaan jotenkin mystisesti loppuu ja katoaa. Kuten tämäkin keskustelu siirtyy historian arkistoihin.

 

Englanti on muuten aloittanut IPv4 osoitteiden myymisen: ne kun on kerran täysin arvottomia, jos et niitä ajoissa myy. Ihan kuten Bitcoinit.

 

Edit: Tässä hyvää IPv6 tilastoa RIPE:ltä Suomi valkoisella. Googlen IPv6 tilastot taas kuvaavat paremmin käytäntöä, eli kuinka hyvin loppukäyttäjät saavat IPv6 osoitteita.

Käyttäjätaso 4
Kunniamerkki +16

Tässä edes odotetaan että operaattoreidenkin omat verkkosivut toimisivat IPv6:lla... Tai muutenkin verkkosivut voisivat toimia IPv6:lla... Ennen kuluttajan ei kannata oikein siirtyä IPv6 käyttämään jos palvelimet eivät käytä IPv6. 

 

Ja ei IPv6 Only verkkoja varmaan voida laittaa kymmeniin vuosiin mutta edes rinnakkain ajettaisiin... Monet DSLAMit ei varmana tue IPv6:sta.

 

Konesali jossa palvelimeni on ei ole natiivia IPv6 koska avausmaksut niin korkeat siihen nähden mitä hyötyä siitä olisi. Operaattorin laite ei tue IPv6 joten sekin joutuisi vaihtoon... (Joku Juniperin 1Gbps runkokytkin). 

 

6to4 taas tuo pingiä lisää kun menee Ficixin kautta... joten vaikka on IPv6 osoite palvelimella niin menee aina IPv4:lla. 

Tälläisen conffiksen tein Debian-reitittimelleni:

https://sintonen.fi/debian-6rd/

 

Tuo siis toimii dynaamisesti eikä sisällä kiinteitä IP-osoitteita.

 

Täysin tyytyväinen en ole siihen että tuo tekee turhia radvd-conffiksen kirjoituksia joka RENEW-tilanteessa ym.

Tein "option-6rd" scriptiin pienen parannuksen:

- Nyt operaatioita ei suoriteta kuin tilanteessa jossa 6RD-configuraatio ja/tai IPv4 -osoite muuttuu

Hei

 

Tässä on minun versioni, tehty debianille mutta toiminee ubuntullakin:

#!/bin/sh
#
# hae ipv4 osoite eth0 kortilta
#
extipv4="$(/sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}')"

# laske 6rd ipv6 osoite ipv4 osoittesta
#
extipv6="$(ipv6calc -I ipv4 $extipv4 --action 6rd_local_prefix --6rd_prefix 2001:2003::/32 --6rd_relay_prefix 80.221.111.254/0 -O ipv6addr | cut -d/ -f1 | awk '{ print $1 1}')"

case "$1" in
start)

echo "Asetan sonera-ipv6 tunnelin julkisesta osoitteesta " $extipv4 " kayttamaan " $extipv6

ip tunnel add sonera-ipv6 mode sit remote 80.221.111.254 local $extipv4 ttl 255
ip link set sonera-ipv6 up
ip addr add $extipv6/64 dev sonera-ipv6
ip route add ::/0 dev sonera-ipv6

exit 1
;;
stop)
echo "Poistan sonera-ipv6 tunnelin.."

ip -6 route del default
ip link set sonera-ipv6 down
ip tunnel del sonera-ipv6

exit 1
;;
*)
echo "Aja $0 parametrilla start tai stop"

exit 1
;;
esac

ja pastee samasta jos näyttää oudolta/puuttuu jotain: sonerav6.tunnel.sh

Skripti olettaa että ulkoverkkoon päin oleva kortti on eth0, asetetaan extipv4= alkuisella rivillä.

 

Tallenna siis tuo esim nimellä sonerav6.tunnel.sh

Anna sille ajo-oikeudet: chmod 700 sonerav6.tunnel.sh

Aja skripti roottina: sudo ./sonerav6.tunnel.sh start

 

Jos kaikki meni kuten strömsössä voit nyt testata yhteyden esim. traceroute6 ipv6nyt.fi:

$ traceroute6 ipv6nyt.fi
traceroute to ipv6nyt.fi (2a00:13f0:0:1005::11), 30 hops max, 80 byte packets
1 2001:2003:50dd:6ffe::2 (2001:2003:50dd:6ffe::2) 22.348 ms 22.520 ms 22.485 ms
2 * * *
3 2001:2000:600a:4ff:3:0:2016:1 (2001:2000:600a:4ff:3:0:2016:1) 23.544 ms 23.770 ms 23.973 ms
4 * * *
5 ipv6nyt.fi (2a00:13f0:0:1005::11) 24.025 ms 24.228 ms 24.194 ms
Käyttäjätaso 4
Kunniamerkki +16

Testasin scriptiäsi Debianissa ja hyvin toimii kunhan asentaa ipv6calc paketin pakettihallinnasta...

 

aptitude install ipv6calc
Käyttäjätaso 4
Kunniamerkki +16

Itselläni siis Debian reititin mutta en saanut 6rd reititetty. 6to4 onnistuin kyllä. Tämä 6rd on paljon vieraampi kun tuo 6to4... Tartteeko tämä jotakin muuta kuin 6to4?

 

Käyttäjätaso 4
Kunniamerkki +16

Huomasin lisäksi että 6to4 ei reitity esim omalle palvelimelle mutta www.google.com toimii ihan hyvin.

Käyttäjätaso 4
Kunniamerkki +16

Taisin ratkaista 6rd ongelman... 

6to4 yhteyksiä ei suositella käytettäväksi koska niissä ei ole SLA:ta. Sen kyllä välillä huomaa.
6rd on ihan sama kuin 6to4, ainoa ero 6rd:ssä on eri prefixi jolla voidaan käyttää "valittua gatewaytä", 6to4 random anycast periaatteen sijasta. Teknisesti noilla on tosi vähän eroa. Joskus itse ajattelin että jokainen operaattori ajaisi omaa 6to4 gatewaytä, no 6rd tekee juuri tämän.
Käyttäjätaso 4
Kunniamerkki +16

6rd:llä ainakin yhteydet toimii paremmin... sehän on suoraan Soneran verkossa tämä Soneran oma... 6to4 ei reititä kaikkialle, esim omalle palvelimelle ei pääse 6to4:lla mutta 6rd:llä ja natiivisesti pääsee. 

Maltion sitten tunkata tuon 6rd tunneloinnin päälle Ubuntun kanssa ja tein tölkistä samalla reitittimen, joka hoitaa liikennöinnin reitityksen koko sisäverkkoon. Hienosti toimii, myös DDNS nimet päivittyvät automaattisesti ja tunnelin osoitepäivittyy täysin automaattisesti jne. Yhteysnopeudt on mainiot Telia:n 6rd:llä.

 

Kuitenkin jäi yksi ongelma, josta ehkä tietäjät tietää. En ymmärrä miksi WiFissä oleva puhelin on täysin jumissa IPv6:n osalta, vaikka muilla koneilla (Linux) verkossa IPv6 toimii aivan mahtavasti. Jos joku tietää mistä on kyse, niin saa antaa pro-tipsin.

 

Edit, kappalejako kuntoon. Ilman javascriptiä tämä näköjään hukkaa kappaleet.

Käyttäjätaso 4
Kunniamerkki +16

IPv6 DNS olisiko? Vai myös suorat IPv6-yhteyksissäkin ongelmia?

Testasin lisää tuota ja ei tuolla taida olla mitään tekemistä Linuxin, tai 6rd:n kanssa. Vaan jotain todella hämärää taitaa olla tuon reittittimen toiminnassa. Tuntuu että kaikki IPv6 liikenne on täysin jojossa WLAN:sta, kun kerran Ubuntu reititin on kiinni LAN:ssa.

 

Pitää debugata ja katsoa jos keksisin mistä johtuu. Mutta packet loss on järjetöntä, ja todellakin TCP:llä siirtonopeudet ovat enemmänkin kilotavuja sekunnissa, kuin megatavuja. Eikä edes ole vitsi. Just nyt siirtyy 680 bytes/second wgetillä. LANista tulee niin kovaa kun Telian kaistajarru antaa tulla tällä (rajoitetulla) liittymällä.

 

Eli omassa verkossa / reitittimessä (?) on jotain omituista vikaa (?). Vika ei ole Ubuntussa, koska sitä tuskin kiinnostaa onko WLANista vai LANsta tuo IPv6 liikenne peräsin, kun sen kannalta molemmat on samassa interfacessa. Reitittimen IPv6 mode on link local only, joten sen ei pitäisi tähän liikenteeseen sotkeutua. ip -6 route, on sama molemmissa koneissa, jne.

 

Tuleepahan yksi hyvä vianetsintä / debug harjoitus lisää. (Yay, ihan kun näitä ei muutenkin riittäisi tarpeeksi.)

 

Edit ja jatkot: Pienen säätämisen jälkeen vahvistettu. Sama läppäri, eetteri kaapelilla, IPv6 toimii täydelisesti. Vika siis ei ole läppärin IPv6 konfigissa, eikä myöskään Ubuntu reitittimen konfigeissa, eikä Telia:n 6rd:ssä. Vaan nyt liittyy vahvasti tuohon Telian toimittamaan ZyXELin reitittimeen, miten se voi sabotoida IPv6 liikennettä. Tuo jää selvitettäväksi. Mutta nyt on vikaa rajattu aikalailla.

 

Jatkot, koska on kind of off-topic, niin forkkasin tänne:

https://yhteiso.telia.fi/t5/Kiinteat-nettiyhteydet-ja/ZyXEL-NBG6515-IPv6-WLAN/m-p/177979#M10440

Lisädebuggauksen jälkeen lopputulos on tämä:

WLAN liikenne joka reitittyy eteenpäin Internettiin on se joka jumittaa.

 

Testasin myös, että WLAN IPv6 ei sinänsä ole ongelma, eli jos otan yhteyden paikallisen palvelimen link local tai public IPv6 osoitteeseen, toimii yhteys hyvin. Mutta vain kun liikenne reitittyy WLANsta (link localin / reitittimen kautta) eteenpäin, se alkaa katoamaan ja WLAN yhteyden kohdalla, koska paketit tulevat Internetistä kyllä reitittimelle asti ongelmitta.

 

Tämä on varmasti sellainen juttu, jonka tietäjät tietää ja osaa sanoa kuin apteekinhyllyltä mitä on sössitty. MTU on jo laitettu radvissa 1280 tavuun.

 

Tulee ihan mieleen klassikot kuten duplex issuet ethernetissä aikanaan. Toi on just niin paha, mutta miksi? Sitä tiedä en.

 

 

 

Vastaa