Osa noista ip-tunnistussaiteista kertoo mun ipv4 osoitteen, osa näyttää ipv6 osoitteen. Jos ipv6 otetaan käyttöön koska ipv4 osoitteet loppuvat, miksi esim mulla on käytössä molemmat? Mikä logiikka tässä hommassa on? Onko ipv6 käytöstä mitään hyötyä tässä vaiheessa?
IPv6 siirtymävaiheessa eli nyt käytetään molempia IPv4 ja IPv6 osoitteita samaanaikaisesti. Tämä sen takia että IPv4 osoitteet vähissä ja IPv6 ei ole kaikkialla vielä saatavilla.
Esimerkiksi tämä klaani.sonera.fi ei tue IPv6 osoitteita vaikka luulisi nyt IT yritysten pistävän IPv6 käyttöön palvelimissa mahdollisimman pian. Soneralla on IPv6 osoitteita mutta omat palvelut eivät tue IPv6 verkkoa. Itse olen päivittänyt omani palvelimeni IPv6 osoitteille.
Erityisesti palveluntarjoajien pitäisi ottaa IPv6 käytöön verkkopalveluissaan. Muuten tavallisella kotikäyttäjällä hyöty ei ole kovinkaan hyvä. Silti jos mahdollista niin ottaa käyttöön IPv6. Siitä kuitenkaan ei ole haittaa. IPv6 osoite on aina julkinen joten NAT ei tuota ongelmia ja osoitteita on aina riittäästi. IPv6 mahdollistaa sisällepäin tulevat yhteydet helposti ilman porttiohjauksia.
IPv4 tulee olemaan vielä käytössä seuraavat 10 vuotta ainakin ennen kuin kaikki siirtyvät käyttämään IPv6 verkkoa. IPv4 voi tällöin käyttää suurempia kuluttaja verkoissa osoitemuutoksia (NAT) sillä internet käyttäjällä tulee olemaan paljon vähemmän käyttöä IPv4 osoitteille.
Ok, eli en ollut ihan sokea. Tölkissä oli niin vanha firmis, ettei tukea ollut. Soneran tyypit päivitti sen äsken. Mutta ei siinä vielä kaikki. Päästiin vasta toiseen erään.
DNS
Se on jotenkin solmussa, eli syystä tai toisesta tulee puutteelliset DNS infot. Kaikesta huolimatta DNS toimii, mutta todella hitaasti, eli oikea resolveri ei ole ensisijaisena. Koskee Windows, Linux ja Android laitteita kaikkia. Ehkä jotain jäi väärin? Ehkä ei? Musta heittivät factory resetin purkille firmiksen päivittämisen jälkeen. Jos asetan hans manual menetelmällä DNS serverin vaikka ns1.inet.fi niin homma pelaa buenosti.
Palomuuri
Miksei port forwarding, koske samalla myös IPv6:sta? Silloin olisi helppoa avata halutut portit sitä käyttäen. Koska palomuuri on lukittu tarkoittaa tämä käytännössä sitä, että palomuuri pitää ottaa kokonaan pois käytöstä. Mun tapauksessa se ei ole ongelma, mutta voi olla joillekin. En ole kokeillut alkaako tuon jälkeen IPv6 toimimaan sisään päin moitteettomasti. Todennäköisesti, no höh, eihän se montaa sekuntia ota. Tsekataan. Ok, eli IPv6 inbound toimii kun palomuurin kääntää kokonaan pois. Olisi tietysti kiva, että voisi valita portit, mutta hällä niin väilä. Mutta uskon vakaasti, että jotakuta tämä kyllä vielä häiritsee.
DNS pieni jatko: Tarkistin vielä että en ollut tunkannut mitään DNS:n kanssa. Eli parametrit #supersede .... on remmattuna dhclient.conf:issa. Tosin nyt enabloin sen tilapäisesti kunnes selviää miksi hommat mättää.
Port Forwarding tehdään vain NATille jos haluaa ohjata portteja.
Normaalisti käytetään vain INPUT, FORWARD ja OUTPUT sääntöjä.
Todellakin. Mutta kun ne on lukittu tässä Soneran ritsassa. Muualla mä käytän kyllä ns. kunnollisia palomuureja joissa näitä asioita voi säätää. Mutta ei nyt jaksa edes alkaa keskustelemaan kunnollisista palomuureista ja reitittimistä, kun ei niitä käytännössä koskaan kuluttajilla näe.
Juu tosiaan sellaisia ei ole kuluttajilla eikä oikein minullakaan. Itse reititän liikennetä Linux reitittimelläni ja pari Mikrotikkiä on käytössä. Näillä olen päässyt tekemään kaiken mitä tartteekin tehdä.
Jatketaan, eli voi kyllä toimittaa ihan paketti dumpit Soneran propellihatuille jos ne eivät tiedä mistä on kyse. Mutta uskon että ne tietää. Pistän tikettiä menemään. Turha tehdä turhaa analyysiä itse, jos ne tietää heti mistä on kyse...
No debuggasin mä sittenkin. Eli ongelma on se että 192.168.1.1 osoitteessa oleva DNS palvelin vastaa poskettoman hitaasti. Jos korvaan DNS:n esim 192.89.123.26:llä niin homma toimii varsin vauhdikkaasti. Miksi DNS relay menee rikki? Eikä sillä oikeastaan niin väliä, voisihan sitä tarjota DHCP:n kautta suoraan oikeat DNS serverin osoitteet eikä relay ole sinänsä mitenkään välttämätön.
Fix fix?
Btw. koska tcpdump tekee defaulttina reverse lookupin IP:lle jumittavan DNS serverin käyttäminen on sen kanssa tosi kliffaa, ellei featurea disabloi.
Eivät näköjään vielä tänään korjannut tuota. Vaikka tein siitä eilen tiketin. Ei pitäs olla paha juttu. Jos pääsisin itse tunkkaamaan noita asetuksia tossa tölkissä niin olisi jo fiksattu eilen ennen puoli kahdeksaa.
Eli siis sekä IPv4 ja IPv6 osoitteet ja DNS palvelut toimivat maniosti, kunhan vain ohittaa sen mitä toi tölkki tuuppaa clienteille defaulttina.
Jos olet laittanut kuluttajana niin eikö asiakaspalvelija vastausaika ole 7 työpäivää?
Olkitu, voi hyvinkin olla. Evt, evvk. Anyway, eilen illalla myöhään los problemos poistui.
Eli ehkä siellä joku näki viestin ja totesi, että ton asian korjaamiseen menee 5 sekuntia ja teki tarvittavan muutoksen Nyt toimii kaikilla laitteilla aivan mainiosti. Mietin vielä että olisiko toi voinut liittyä DHCP leasien expiroitumiseen, mutta sekä linux että windows koneella kyllä vapautin leasen ja hommasin uuden, että ei pitäisi.
Jossain vaiheessa kun laitoin mm. toimiston IPv6 yhteydet kuntoon, niin huomasin että jotkut asetukset säilyvät clienteissä tosi pitkään. Eli teki testaamisesta hankalaa kun asetusmuutokset eivät välittömästi vaikuttaneetkaan ympäristöön. Pitää odottaa että RA pakettien ajat expiroituu ennen kuin uudet asetukset astuvat voimaan vaikka reititin uusia RA paketteja päälle tunkisikin. Monesti oli parasta tehdä illalla viimeiseksi 'give your best shot' konfiguraatio ja sitten aamulla katsoa mikä on tilanne. Btw. En todellakaan ole ainoa joka on noiden kanssa saanut tunkata. Meinasin tuon kanssa vaipua epätoivoon, ennen kuin asian syvin olemus alkoi pikkuhiljaa selkenemään. Sekä miten linuxuit, windowssit ja kyseinen reititin pitää konfiguroida kyseisen operaattorin verkossa.
Eräällä konesalitarjoajalla on nyt ihan samoja ongelmia, DHCPv6 ei vaan toimi niillä millään. Sekä toisella palveluntarjoajalla eivät ole saaneet RA paketteja toimimaan oikein. Siksi molemmat em. tahot ovat lähteneet siitä, että IPv6 konfiguroidaan aina käsityönä. 8 eri operaattorin kanssa olen nyt vääntänyt IPv6:n kuntoon. On prefix delegaatiota ja kiinteitä subnettejä /48 jne, sekä erilaisia haasteita on riittänyt. Eniten haastetta on tuonut se, että monesti toisellakaan puolella ei täsmäleen tiedetä mitä pitäisi tehdä ja sitten se menee yrirä ja epäonnistu menetelmän kautta siihen, että tulee random ohjeita, joita koitetaan soveltaa ja jossain vaiheessa (jos on onnea) kaikki lähtee toimimaan. Samalla operaattorilla vielä eri tuotteiden kanssa konfiguraatiot saattaa olla ihan täysin erilaiset. Sekä osaa niistä ei ole ollenkaan dokumentoitu jos ovat ns. harvinaisempia konfiggeja. No tää on tätä, haastetta riittä. Onko se kivaa, riippuu päivästä ja fiiliksestä.
Mitä tuli muuten tunnelointiin, niin jokainen joka käyttää 'siltaavaa yhteyttä' käyttää jo ethernet framejen tunnelointia, eikä natiivia Internettiä aka IP protokollaa suoraan linjalla. Muita layereita on kasa, mutta en lähde nolaamaan niiden arvailulla kun asian edellisestä käsittelykerrasta on varmaan kymmenen vuotta. Silloin kun ADSL yhteydet tuli markkinoille noihinkin piti tutustua. Onhan meillä myös PPTP jota joskus käytetiin kovasti.
Itse luovutin Dhcpv6 siitä lähtien kun en saa Linux reitittimelle radvd:llä /65 prefixin advertise. Ilmoittaa että haluaa /64 mutta ei se käy minulle.
Sitten minulla on IPv4 Dhcp eri verkossa kuin IPv6 verkko, eikä vielä ole hajua miten konffailla Dhcpv6 relay Linuxilla.
Sinulla näyttää olevan enemmän kokemusta näistä. Staattiset osoitteet meneee vielä mutta jos on dynaamiset niin ainakin minulle alkaa tulla ongelmia. Omassa palvelimessa ja verkkolaitteissa on tietenkin staattiset osoitteet niin ei se ole ollut ongelmana. Kotin olisi kiva se Dhcpv6 kun ei sielä joka laitteelle jaksa sitä laittaa käsin.
Oho... no tietenkin jos lukisi vähän enemmän niin tiedän jo miksi ei voi tehdä... Mutta ei silti oo järkeen ettei voisi tehdä pienempiä verkkoja...
Eikö tuola Soneran 6rd:stä tuu vaan /64 verkko?
Vielä sen Sonera voisi fiksata, että heittäisi noille reverse DNS nimen, kaikille IP osoitteille kun suositellaan reversen käyttöä.
#sonera #ipv6 #rdns
Nimenomaan /64. 6rd:n juju on siinä että ensimmäiset 64 bittiä tulee operaattorin 6rd prefixistä ja asiakkaan IPv4-osoitteesta, ja loput 64 bittiä on sitten asiakkaan käytettävissä lähiverkossa normaaliin tapaan.
Sonera kävi uuden kuitubitin kytkemässä tuossa pari päivää sitten ja laitoin tuon 6rd:n ajoon samalla. En huomannut reitittimessäni (EdgeRouter Lite) tukea OPTION_6RD:lle niin laitoin asetukset käsin, näyttäisi toimivan varsin kivasti ja pääsi vihdoinkin eroon "ruotsalaisuudesta". Nuo sijaintitietoa käyttävät weppisivut kun alkoi häiritä hiljalleen HE:n IPv6-tunnelin kanssa.
Kokeilin hiukan FUNET:in suuntaan 6rd-palvelun nopeutta.
Siinä missä normaali ftp-siirto sujuu n. 550-600 Mbit/s nopeudella, 6rd:n kautta nopeus jää n. 55 Mbit/s luokkaan. Speedtestillä Nebulan suuntaan pääsee kyllä 950 Mbit/s nopeuteen saakka ja EdgeRouterin CPU on 5% luokkaa eli 6rd ei kuormita sitä mitenkään.
Ranskan suuntaan ipv6 nopeustestillä sai hiukan n. 70 Mbit/s luokkaa olevia nopeuksia eli kenties tuo Soneran 6rd kaipaisi hiukan lisävauhtia -- natiivi IPv6 olisi tietysti toivottu vaihtoehto..
Onko kellään hajua saako Asuksen DSL-N66U -reitittimeen IPv6:sta toimimaan? Tämän kummempia asiaan liittyviä asetuksia vehkeestä ei löydy ja näihin en oikeen osaa soveltaa aiempia tiedonmurusia..
Sinulla on nyt asetukset hieman pielessä...
Mutta hyvä että tulit tänne Klaaniin...
6rd IPv6 Prefix: 2002:2003::
IPv4 address: sAsuksen julkinen IPv4 - osoite]
IPv4 Mask length: 0
6rd Border Relay IPv4 Addr: 80.221.111.254
Tästä voisi toki tehdä erillisen oppaan kun varmaan tuota nativiia ei lähiakoina näytä tulevan eikä tule edes saatavilla kaikille. Noilla asetuksilla pitäisi saada toimimaan, mutta tulee päivittää tuo IPv4-osoite jos sinulla muuttuu osoite Soneran DHCP:ltä.
Nuo on Asuksen oletusasetukset (pöljä juttu sinänsä että siellä on jotkut oikeat valmiina). Kokeilin noilla antamillasi, mutta ei lähde siltikään toimimaan. Sen verran jaksoin kaivella että reitittimessä on skripti ipv6rd_start.sh jonka sisältö:
#!/bin/sh
#To build 6rd tunnel
#Usage:./ipv6rd_start.sh
if $# != 5 ] ; then
echo "usage: $0 CE_address 6rd_prefix prefix_length 6rd_PD BR_address"
exit 0
fi
CE_ADDR=$1
PREFIX=$2
PREFIX_LEN=$3
PD=$4
BR_ADDR=$5
TUNNEL_NAME="6rd"
ip -6 route flush dev $TUNNEL_NAME
ip link set dev $TUNNEL_NAME down
ip -6 tunnel del $TUNNEL_NAME
ip tunnel add $TUNNEL_NAME mode sit local $CE_ADDR ttl 255
ip tunnel 6rd dev $TUNNEL_NAME 6rd_prefix $PREFIX/$PREFIX_LEN
ip link set $TUNNEL_NAME up
ip -6 addr add $PD/$PREFIX_LEN dev $TUNNEL_NAME
ip -6 route add ::/0 via ::$BR_ADDR dev $TUNNEL_NAME
exit 0
Ilmeisesti kyseinen skripti siis ajetaan noilla tiedoilla mitä tuonne asetussivulle syötetään. Asetusten määrittämisen jälkeen ilmestyy kyllä interface 6rd:
6rd Link encap:UNSPEC HWaddr 54-F8-7C-AB-0F-41-00-49-00-00-00-00-00-00-00-00
inet6 addr: 2002:2003:xxxx:xxxx::1/32 Scope:Global
inet6 addr: ::84.248.xxx.xxx/128 Scope:Compat
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 TX bytes:1860 (1.8 KiB)
Vaan ping6 ei kulje mihinkään (DNS toimii, olen laittanut Googlen DNS:t reitittimeen). Pitäisikö Link encap olla jotain muuta kuin UNSPEC?
ip -6 route kertoo tämmöistä:
::/96 via :: dev 6rd metric 256 expires -551sec mtu 1480 advmss 1420 hoplimit 4294967295
2002:2003::/32 dev 6rd metric 256 expires -552sec mtu 1480 advmss 1420 hoplimit 4294967295
fe80::/64 dev eth0 metric 256 expires -17746sec mtu 1500 advmss 1432 hoplimit 4294967295
fe80::/64 dev eth0.1 metric 256 expires -17740sec mtu 1500 advmss 1432 hoplimit 4294967295
fe80::/64 dev br1 metric 256 expires -17739sec mtu 1500 advmss 1432 hoplimit 4294967295
fe80::/64 dev br0 metric 256 expires -17734sec mtu 1500 advmss 1432 hoplimit 4294967295
fe80::/64 dev nas10 metric 256 expires -17724sec mtu 1500 advmss 1432 hoplimit 4294967295
fe80::/64 dev ra00_0 metric 256 expires -4184sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev ra01_0 metric 256 expires -4184sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev nas8 metric 256 expires -4182sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev nas8_0 metric 256 expires -4181sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev 6rd metric 256 expires -551sec mtu 1480 advmss 1420 hoplimit 4294967295
ff00::/8 dev eth0 metric 256 expires -17746sec mtu 1500 advmss 1432 hoplimit 4294967295
ff00::/8 dev eth0.1 metric 256 expires -17740sec mtu 1500 advmss 1432 hoplimit 4294967295
ff00::/8 dev br1 metric 256 expires -17739sec mtu 1500 advmss 1432 hoplimit 4294967295
ff00::/8 dev br0 metric 256 expires -17734sec mtu 1500 advmss 1432 hoplimit 4294967295
ff00::/8 dev nas10 metric 256 expires -17724sec mtu 1500 advmss 1432 hoplimit 4294967295
ff00::/8 dev ra00_0 metric 256 expires -4184sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev ra01_0 metric 256 expires -4184sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev nas8 metric 256 expires -4182sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev nas8_0 metric 256 expires -4181sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev 6rd metric 256 expires -551sec mtu 1480 advmss 1420 hoplimit 4294967295
default via ::80.221.111.254 dev 6rd metric 1024 expires -551sec mtu 1480 advmss 1420 hoplimit 4294967295
Voi kyllä olla että jätän asian sikseen, ei tuosta vielä niin hirveästi hyötyä ole että jaksaisi päiväkausia tuon kanssa tapella :)
Nyt en tajua miksi ei toimi tuo...
Tässä yleinen 6rd scripti joka ainakin toimii... tuo laskin sitten tarttee ipv6calc paketin...
#!/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
Niin se oikea prefix on 2001:2003::/32 ei 2002:2003::
@tlauttia kirjoitti:
Niin se oikea prefix on 2001:2003::/32 ei 2002:2003::
Oho... Olinpas typottanut...
@olkitu kirjoitti:
Oho... Olinpas typottanut...
Ei välttämättä ollenkaan typo, voi olla varsin hyvin Freudilainen lipsahdus, koska jos olet käyttänyt aikaisemmin mm. 6to4 yhteyksiä, niin tuo 2002 prefiksi tulee niin selkärangasta. Aivot tunnetusti rakastaa muistiin perustuvia oikopolkuja ja lintsaamista, joten jos tiedät jotain, niin et viitsi sitä enää uudelleen lukea.
Eikös tämä ole syy siihen, miksi monet liikenne onnettomuudet tapahtuu mm. tutuissa paikoissa joissa liikennejärjestelyt on muuttunut. Hei, eihän tuossa ennen mitään kolmiota ole ollut, voit sitten todeta kun on kaara ihan lytyssä.
Ihan samaan itsepetoksen harhaan menee ne jotka kuvittelee esim. 192. tai 172. alkuisten IPv4 osoitteiden olevan LAN osoitteita tai non-routable osoitteita, tämähän ei muuten pidä paikkaansa. Niin lukemattomia kertoja nähnyt ihmisten 'vahtelevan' tuosta.
Aivan.. siis mitä olinkaan kirjoittanut...
Juu aikaisemmin olen käyttänyt paljon 6to4 pääasiassa. Tosiaan 2002::/16 on noita 6to4 ja 2001:2003::/32 on Soneran omaa verkkoa.
Onneksi kyllä privaatti ipv4 osoitteet melkein muistan, 192.168.0.0/24, 10.0.0.0/8 ja sitten tuo 172.16.0.0/12 (tämä viimeinen pitikin varmistaa tuo maski)
Itselläni oli jossain vaiheessa virtuaalipalvelin 192.89 verkon alla, jotkut toisaan luulivat privaattiverkoksi. Yhdessä projektissa käytettiin 172.24.0.0/24 verkkoa, niin oli pakko kysyä "onks noi privaattiosoitteita"? Ei kaikkea vaan muista...
Asiallahan nyt ei varsinaistä väliä minulle ole, tuleeko ip vielä 4 vai 6 versioa. Mutta, kun sonera kerran sanoo palveluiden olevan valmiita ipv6:lle haluasin sen käyttööni. Thomsonin hallintasivulta ei kuitenkaan löydy tuota vaihtoehtoa napsauttaa se päälle. Pitääkö tämä siis pyytää erikseen jostain, vai kuinka ? Aikasemmin tässä ketjussa joku muukin etsi tuota valintaa, mutta ei selvinnyt löytyikö se sieltä.
@vahtmestar kirjoitti:
Asiallahan nyt ei varsinaistä väliä minulle ole, tuleeko ip vielä 4 vai 6 versioa. Mutta, kun sonera kerran sanoo palveluiden olevan valmiita ipv6:lle haluasin sen käyttööni. Thomsonin hallintasivulta ei kuitenkaan löydy tuota vaihtoehtoa napsauttaa se päälle. Pitääkö tämä siis pyytää erikseen jostain, vai kuinka ? Aikasemmin tässä ketjussa joku muukin etsi tuota valintaa, mutta ei selvinnyt löytyikö se sieltä.
Mikä käyttöjärjestelmä versio sinulla on Thompsoinista? Itselläni ei ole kokemusta Thompsonista mutta Intenossa tämä on. 6RD tämä vielä on mutta tuo Soneran ilmoitus että palvelut olisi IPv6 valmiita on minusta hiukan huijaus kun ei ole kyseessä natiivi IPv6. Toki ei sillä paljon merkitystä, hyvinhän tämä 6RD ainakin on toiminut.