Route48.org - Ilmainen IPv6 tunnelipalvelu suomalaisella PoP:lla

[ztec]

Route48 :: IPv6 Tunnel Broker :: 100% Free IPv6 BGP Transit, 100% Free IPv6 Tunnel Broker

Tämä toimii myös NAT:n läpi, eli on aivan kaikkien halukkaiden käytettävissä, sekä tukevat myös Wireguard VPN:ää ja sitä myöten myös liikenteen salausta. Vaikuttaa teknisesti katsottuna ainakin selvästi parhaalta IPv6 tunnelilta mitä Suomessa on saatavissa. Tarjoaa myös kiiteät IP-osoitteet ja avoimet portit, jotka valitettavasti puuttuu monen normaalin palveluntarjoajan valikoimista. Helpottaa huomattavasti palomuuraamista ja palvelujen tarjoamista, kun osoitteet ei muutu jatkuvasti.

WireGuardin lisäksi muita tuettuja protokollia ovat mm. GRE/SIT, ZeroTier, sekä tosi hakkereille BGP. rDNS ja PTR recordit ovat myös itse konfiguroitavissa.

Esim. palvelimen pitäminen Telian mobiililiittymäsä on ollut hyvin hankalaa ilman tämän kaltaista palvelua, joka avaa (melkein) kaikki portit ja antaa kiiteän IP-osoitteen. 1208925819614629174706176 osoitteen pitäs myös riittää niille hikisimmillekin kotiverkkolabran pyörittäjille.

Suomen tunnelipalvelimen IPv4 osoite on: 185.218.193.178 ja IPv6 osoite on: 2a06:a003:b000::1

Edit: Lisätty palvelimen IPv6 osoite näkyville.

 

[user9999]

Sivu on nurin vai onko jotain kesken.

 

[ztec]

Sivu on nurin vai onko jotain kesken.

Just sen takia mä kirjoitin niin kuin tuossa avausviestin viimeisessä kappaleessa mainitaan, että päivitän postauksen sisältöä kun pääsen verifioimaan sen sivustolta. Just juteltiin pitkästi @samip537 kanssa tuosta aiheesta. Toi sivusto toimii jos ensin käytät VPN:ää, vaikka Frankfurttiin. Mut jooh, mutta toimii kun toimii. Cloudflarelle on myös ilmoitettu, mutta mitä ilmeisimmin route48:n reititys-ongelmista on kyse. Cloudflare tekee vaan tilanteen analysoimisen erittäin hankalaksi normi tilanteeseen verrattuna.

 

[user9999]

Just sen takia mä kirjoitin niin kuin tuossa avausviestin viimeisessä kappaleessa mainitaan, että päivitän postauksen sisältöä kun pääsen verifioimaan sen sivustolta. Just uteltiin pitkästi @samip537:n kanssa tuosta aiheesta. Toi sivusto toimii jos ensin käytät VPN:ää, vaikka Frankfurttiin. Mut jooh, mutta toimii kun toimii. Cloudflarelle on myös ilmoitettu, mutta mitä ilmeisimmin route48:n reititys-ongelmista on kyse. Cloudflare tekee vaan tilanteen analysoimisen erittäin hankalaksi normi tilanteeseen verrattuna.

OK. VPN yhteys Saksaan niin pääsin tuolle sivulle.

 

[mRkukov]

Yksi sivu mitä en tuolta löydä: "Who are we"

Eli onko tämä vain joku random porukan virittelemä "ilmainen" palvelu vai joku ihan oikeasti "luotettava" taho joka tuollaista rakentanut? En lähtisi reitittämään yhtään mitään liikennettä ilman että tiedän kenen saataville kaikki data menee.

 

[mikajh]

Yksi sivu mitä en tuolta löydä: "Who are we"

Kun sinne rekisteröityy, niin näkee vähän tietoa Finland-palveluntarjoajista

 

[mRkukov]

Kun sinne rekisteröityy, niin näkee vähän tietoa Finland-palveluntarjoajista

Eli siitä kuka hostaa suomessa. Mutta kuka on taho tuon palvelun takana?

 

[Inffi]

Eli siitä kuka hostaa suomessa. Mutta kuka on taho tuon palvelun takana?

Suomi palveluntarjoajan (Web1) näkökulmasta tuo on meille vain virtuaalikone + BGP peer.

Route48 sivujen mukaisesti
"© Route48.org :: A Joint Partnership between ZappieHost, LLC. and Cloudie Networks, LLC."

Molemmista organisaatioista oli tuossa käyttöönottoprosessissa kavereita mukana. Ipv6 alueista voi sitten halutessaan Ripestä kaivella enemmän tietoja (Webupdates), mutta eipä tuolta nyt ainakaan mitään megakorporaatiota taustalta lävähdä silmille.

Sinänsä toki kaikki aina omalla vastuulla, mutta ainakin meidän seulasta oltiin valmiita päästämään tämä läpi

 

[mRkukov]

Route48 sivujen mukaisesti
"© Route48.org :: A Joint Partnership between ZappieHost, LLC. and Cloudie Networks, LLC."

Toinen tarjoaa hostausta bitcoin/paypal ja toinen sivu on hello world. Jes, näihin luotan.

Ripestä kaivella enemmän tietoja (Webupdates)

created: 2022-05-12T23:25:38Z

Jes. Luotettava taho.

Spoileri

Sori, ei mene minun seulasta läpi näillä tiedoilla.

Lisäksi se että tietoa pitää itse etsimällä etsiä eikä sitä ole mitenkään järkevästi kerrottu on jo aika huono merkki. Menee lähinnä kastiin random vpn josta ei tiedä kuka vetää välistä ja mihin tiedot siirretään.

 

[Inffi]

Toinen tarjoaa hostausta bitcoin/paypal ja toinen sivu on hello world. Jes, näihin luotan.



created: 2022-05-12T23:25:38Z

Jes. Luotettava taho.

Spoileri

Sori, ei mene minun seulasta läpi näillä tiedoilla.

Lisäksi se että tietoa pitää itse etsimällä etsiä eikä sitä ole mitenkään järkevästi kerrottu on jo aika huono merkki. Menee lähinnä kastiin random vpn josta ei tiedä kuka vetää välistä ja mihin tiedot siirretään.

Onko sitä olemassa edes muita kuin Random VPN jos sitä ei itse toteuta

 

[mikajh]

Pienoinen puute tuossa GRE/SIT -tunnelissa, että RemoteAddress ei hyväksy FQDN:ää vaan pelkän IPv4:n, eli jos mitään päivitysmekanismia ei ilmaannu, niin dynaamisen IP:n kanssa tulee jossakin kohtaa ongelma

 

[ztec]

Pienoinen puute tuossa GRE/SIT -tunnelissa, että RemoteAddress ei hyväksy FQDN:ää vaan pelkän IPv4:n, eli jos mitään päivitysmekanismia ei ilmaannu, niin dynaamisen IP:n kanssa tulee jossakin kohtaa ongelma

Onhan tuossa sairaan helppokäyttöinen päivitysrajapinta, jonka kautta tunnelin end-pointin osoitteen voi päivittää. Se on tunnelin editin alla ihan valmiina. Eli jos ja kun menet joskus IP:tä vaihtamaan, niin samalla näet miten sen voi automatisoida heittämällä.

Oli muuten mainio kokemus, koko asennukseen ja käyttöönottoon kaikkine juttuineen meni noin 5 minsaa, mukaan lukien GRE/SIT dynaamisella IPv4:lla. Riittää kun pistää yhdelle koneelle tai mieluiten reitittimeen ja jakaa siitä sitten verkon kaikille. Oikein sujuva ja mukava kokemus verrattuna moneen muuhun tunnelin tarjoajaan.

Klassinen vaihtoehto jos ei miellytä on käyttää esim. palvelua, mutta sen kanssa on ollut merkittävästi erilaisia haasteita, kuten varmaan kaikki jotka sitä käyttää niin tietävät. Mulla oli ennestään sekä Kuusitunneli, että Tunnel Broker (lähin pop Tukholmassa) molemmat käytössä.

Onko sitä olemassa edes muita kuin Random VPN jos sitä ei itse toteuta

Lisäksi jos kaikki liikenne on putken läpi on joka tapauksessa salattua ja autentikoitua, niin... No nää on näitä kysymyksiä joiden kanssa voi painia ja keksiä vaikka millaisia tarinoita ja selityksiä. Kenen ratkaisua sitten on kukakin myymässä.

Tietysti onhan tässä sellainen kaukainen haave, että nämä meidän rakkaat niin avuttomat operaattorit Suomessa osaisivat pistää edes perusasiat kuntoon, mutta ehei.

Edit ja jatkot: Yleinen IPv6 Suomessa keskustelu jossa mm NAT:sta ja IPv6:sta noin laajemmin tässä langassa.

 

[jase]

Koetin tuota wireguard tunnelia pystyttää pfsenseen, ei ihan 5 minuutissa onnistunu

Pitää varmaan joskus paremmalla ajalla kaivaa kunnon ohjeet ja miettiä miten tuo pitäisi konffata.

EDIT: Noh, käytin vielä toisen 5 minuuttia ja sain pingin kulkeen IPv6:n yli, sitten vielä pitäis saada jaettua IPv6 osotteet lähiverkkoon. Ei tää vieläkään ole sen helpompaa ole kuin 15v sitten

 

[ztec]

Koetin tuota wireguard tunnelia pystyttää pfsenseen, ei ihan 5 minuutissa onnistunu

Jooh, Wireguardiin ei tarvii heittää kuin avaimet, verkot ja gatewayt. Niin toimii.

Noh, käytin vielä toisen 5 minuuttia ja sain pingin kulkeen IPv6:n yli, sitten vielä pitäis saada jaettua IPv6 osotteet lähiverkkoon. Ei tää vieläkään ole sen helpompaa ole kuin 15v sitten

Riippuu ympäristöstä mitä käytät. Linuxissa voi vaatia sen että heität reitityksen päälle, sitten voi vaatia palomuurissa reitityssääntöjen konfiguroimisen, sekä vielä sen jälkeen radvd:n laittamisen kondikseen. Noi menee tosi nopeasti jos on homma rutiinina, jos tunkaa ekaa kertaa, niin voipi siinä hetki vierähtää. Tietysti parasta, jos reitittimessä on suora tuki tuolle. Mulla toimii nyt kaikki tosiaan vimpan päälle reverse dns:t mukaan luettuna. Just pistin nmap:n pyörimään, että kartoitan mitkä portit on auki tunnelin puolesta ja mitkä ei. Windowssissa on myös ruksi jaa tää yhteys lähiverkkoon, joka tarvii pistää päälle, jos on luonut tunnelin ensin. voipi tulla sysctl, netplan:n konfigit, radvd.conf, mahdolliset ufw:n rules6.before jne fileet tutuksi, jos ei ennestään ole. Tai sitten vaan rullailet ihan raakaa ip komentoa sen Linux mallin mukaan. Sen verran voisin sanoa että toi gateway ominaisuus on uusimmassa netplan:ssa deprekoitu, että pitää korvata route:lla ::/0 on-link:true jotta toimii.

Noihan toisaan tarjoaa minimissään /48, eli saat sitten rakennella 65535 omaa muutakin /64 aliverkkoa tuon yhden tunnelin kautta, eli ei pitäs loppua tosissaan hikisellä nörtilläkään noi osoitteet kesken. Mulle olisi hyvin riittänyt /64 tai /63, mutta ei valiteta. Viimeiseksi piti vielä tehdä palomuuri ja reitityssääntöjen positiivinen ja negatiivinen testi, että kaikki minkä pitää toimia toimii ja kaikki minkä ei pidä toimia, ei toimi. Sekin oli oma pieni urakkansa.

Konfiguroin vielä varareitit reitittimen kautta proxyjump:ia käyttäen ssh:lla, eli jos IPv6 pettää, niin pääsee SSH:lla läpi silti, kun tunnelin sijasta mennään reitittimeen IPv4:lla ja sitten paikallisest reititetyssä verekossa lopulliseen kohteeseen IPv6:lla.

Perussetit sanos.

Niin joo niin, se suorituskyky / round-trip latenssi (sijainti hki - hki)
he.net ~ 92ms
route48.org ~10 ms
IPv4 ilman tunnelointia < 2 ms.

 

[mikajh]

Tämä toimii myös NAT:n läpi, eli on aivan kaikkien halukkaiden käytettävissä

Tuohon kuuluu tietysti disclaimer, että esim. CGNATin takaa, jos (ja vain jos) käyttää joko Wireguardia tai ZeroTier:ia, ei GRE/SIT:llä

 

[ztec]

Tuohon kuuluu tietysti disclaimer, että esim. CGNATin takaa, jos (ja vain jos) käyttää joko Wireguardia tai ZeroTier:ia, ei GRE/SIT:llä

Tottakai, no sehän on aika selvä, että protokollat 41, 47 tms (ei siis porttinumerot!) ei kulje läpi. Eikä tunnelia saa edes konfiguroitua todnäk., koska CGNAT tuskin vastaa ICMPv4 echo-request aka ping:n, joka on edelltyksenä tunnelin konfiguroinnille.

Sen muuten voisi mainita, että tuo tunnelin testi pingi tulee jostain muusta osoitteesta kuin suoraan gateway:ltä. En tosin jaksanut kaivaa logeista mistä se täsmälleen tuli. Siitä voi muuten paljastua myös route48:n tausta-systeemeiden IPv4 osoite, kun puhutaan "cloudflaren antamasta suojasta". he.net:llä taas testi-pingi tulee gateway:ltä, joten riittää jos rajaa vain gateway:n IPv4:n vastaamaan ICMPv4 echo-requestiin.

 

[mikajh]

Pienoinen puute tuossa GRE/SIT -tunnelissa, että RemoteAddress ei hyväksy FQDN:ää vaan pelkän IPv4:n, eli jos mitään päivitysmekanismia ei ilmaannu, niin dynaamisen IP:n kanssa tulee jossakin kohtaa ongelma

Tämä puoli lienee kunnossa, sillä Edit tunnelissa seisoo:

If you wish to programmatically change your tunnel IPv4 endpoint you can use either of these GET API urls:
Update tunnel to current IPv4 of requestee (Remote Address)
Update tunnel with a specified IPv4 address

 

[mikajh]

Wireguard toimii Samsung S21:ssä (Android 12), mutta S9:ssä (A10) sen kautta ei reitity mitään ipv6:tta. ping he.net apilla kyllä toimii siinäkin vaikka 2c0f:fb50:4002:804::200e :een (ipv6.google.com)

E: ZeroTier Professional tier ilmeisesti vaaditaan sen käyttöön, jotta tarvittavia verkkokonffauksia pystyy tekemään. Sen käyttö nyt ei latenssimielessä ole muutenkaan mielekästä, sikäli kun Suomi ei kuulu lokaatioihin

 

[ztec]

Wireguard toimii Samsung S21:ssä (Android 12), mutta S9:ssä (A10) sen kautta ei reitity mitään ipv6:tta. ping he.net apilla kyllä toimii siinäkin vaikka 2c0f:fb50:4002:804::200e :een (ipv6.google.com)

Toimiiko Cloudflaren 1.1.1.1 WARP VPN tunnelilla sulla IPv6? Jänniä eroja kyllä alkaa löytymään, vaikka nää nyt ei sinänsä varmaan tunneliin liity, vaan kuuluisi ehkä taas WireGuard:n IPv6 ongelmat lankaan, jos sellainen olisi. Heh.

 

[pulatunnus]

Sinänsä toki kaikki aina omalla vastuulla, mutta ainakin meidän seulasta oltiin valmiita päästämään tämä läpi

Sanoista luettavissa että työpaikallanne käytetään ?
Selvisikö teille kuka/mikä palvelun takana, millainen organisaatio se on ?

Joskus salaamiselle ihan "hyvät" syyt, ja parempi toki se kuin että valehdellaan ja syyt on pahat, netissä toki vanha ohje, ettei kannata itse vääntää huonolta näyttää hyväksi, vaan epäillä hyvältä näyttävää pahaksi.

 

[Leo_Greta]

Sivusta seuraajan huomatus: @ztec omaa helv... paljon tietoa ja taitoa, mutta hän omasta kuolevaisen näkökulmasta, hän myös odottaa lukijalta lähes samanluokan tietoja ja taitoja.

@ztec Tämä on vain minun henkilökohtainen huomio . Eikä todellakaan mikään loukkaus sinua kohtaan! Olen vain pistänyt merkille, että sinulta löytyy julmetun paljon tietoa & taitoa mitä tulee tietoturvaan & tietosuojaan ja seuraat aktiivisesti hillittömää määrää niihin liittyviä projekteja, sekä kirjoittelet niistä tänne, joka on todella upeaa !

Ongelma on, että ne viestit vaatii välillä tulkkausta, esim mikä on mahdollinen hyöty on esim. tästä projektista jollekin n. 100 koneen minifirmassa, jossa tuskaillaan pääsyä firman sisäsessä verkossa sijaitsevaan SMB-jakoon. Budjetti on tasan NOLLA, mutta firmasta löytyy kaksi fyysistä palvelinta, joista toinen pyörittää Hypervisoria johon mahtuu 1-3 virtuaalikonetta lisää.

Spesifi kysymys, mutta silti oletuksen tasolla .

 

[Inffi]

Sanoista luettavissa että työpaikallanne käytetään ?
Selvisikö teille kuka/mikä palvelun takana, millainen organisaatio se on ?

Joskus salaamiselle ihan "hyvät" syyt, ja parempi toki se kuin että valehdellaan ja syyt on pahat, netissä toki vanha ohje, ettei kannata itse vääntää huonolta näyttää hyväksi, vaan epäillä hyvältä näyttävää pahaksi.

Oma kosketus tähän on se, että olen yhtenä omistajana tuossa Web1 firmassa joka tarjoaa Suomi POP:n Route48:lle. Web1:llä ei ole kyseinen palvelu itsellä käytössä koska natiivi v6 löytyy omasta takaa jo valmiiksi, mutta arvioitiin että tähän osallistuminen voi jollain (hyvin) pienellä tavalla edesauttaa v6:n yleistymistä.

Teknisessä mielessä tässä on aika vähän väärinkäytösten mahdollisuuksia koska palvelun käyttäjät todennäköisesti osaavat itse arvioida mitä ovat tekemässä ja nykypäivänä (lähes) kaiken liikenteen pitäisi jokatapauksessa olla salattua, kulki se sitten suoraa Suomioperaattorin tai Route48:n solmun kautta kohteeseensa.

Web1:n suuntaan en koe, että palvelun taustalla vaikuttavat hahmot (Adam B/Zappiehost + Ryan/Cloudie) olisivat salailleet mitään ja taustakeskusteluiden puolesta itselle ei ainakaan jäänyt mitenkään erikoinen maku suuhun. Peeringdb:n puolelta löytyy myös abuse kontaktia ihan puh-nron. kera (kuten kuuluukin), joten meidän suunnasta ainakin on selvää ketä kuumotella jos jotain ilmenee.

 

[jase]

No niin, 5... *köh* 30 minuuttia myöhemmin deskari jutustelee internettiin oman IP:nsä kautta, jonka sai routterilta DHCP:lla. Android puhelin ei juttele, mutta jätetään se muhimaan.

 

[olkitu]

No niin, 5... *köh* 30 minuuttia myöhemmin deskari jutustelee internettiin oman IP:nsä kautta, jonka sai routterilta DHCP:lla. Android puhelin ei juttele, mutta jätetään se muhimaan.

Android ei taida tukea vieläkään DHCPv6 jos semmoinen lähiverkossa on... Joskohan saisivat sen toimimaan olisi aika kiva.

 

[user9999]

Android ei taida tukea vieläkään DHCPv6 jos semmoinen lähiverkossa on... Joskohan saisivat sen toimimaan olisi aika kiva.

Löytyy pitkä keskustelu aiheesta.

Google Issue Tracker

issuetracker.google.com

 

[jase]

Eipä kannata tuota odotella, joten pienellä googlailulla löyty että SLAAC:illa onnistuu, eli laittaa router advertisements -asetuksista router moden assisted tilaan (pfsense-termein) niin alkaa Androidkin käyttään IPv6:sta.

 

[pulatunnus]

Löytyy pitkä keskustelu aiheesta.

Google Issue Tracker

issuetracker.google.com

Lainaan ketjuun pari kommenttia

Jun 3, 2012 04:17PM

Created issue.

Android does currently not support DHCPv6 as defined by RFC 3315. T
...

Ja n,10 v tuoreemman.

Mar 19, 2022 01:43PM


Still waiting for DHCPv6 on Android 12n hope it will be added on Android 13

No en paljoa enempää lukenut, joten jäi vähän ilmaan miksi ei tueta. Enemmän osu silmään miksi tarvitaan.

 

[mikajh]

Toimiiko Cloudflaren 1.1.1.1 WARP VPN tunnelilla sulla IPv6?

Eipä tuo näytä toimivan, tosin vikana on siis tuo Android-sovellus, joka rikkoo DNS IPv6 AAAA vastaukset ilmeisesti. Kun wifi-verkon laittaa luotetuksi, niin oletettavasti 1.1.1.1 tulee ohitetuksi ja IPv6 testit toimivat hienosti.
NextDNS toimii paremmin. Tuossa 1.1.1.1:ssähän on sekin vika/ominaisuus, että se haluaa olla ainoa aktiivinen vpn ja tappaa muut (there can be only one: )

 

[mikajh]

Sen muuten voisi mainita, että tuo tunnelin testi pingi tulee jostain muusta osoitteesta kuin suoraan gateway:ltä. En tosin jaksanut kaivaa logeista mistä se täsmälleen tuli

Mielestäni riittää, että sallii IPv4 ICMP echo requestin vain (Route48:n) Server Addressista

pfsense-termein

OPNsensessä pitää valita näitä ohjeista soveltaessa GIF-interfacen remote-addressiin prefixin pituudeksi tasan 128 Configure IPv6 Tunnel Broker — OPNsense documentation
Tämän jälkeen ifconfig gif0 (tai mikä numeo tulikaan määritellyksi) näyttää validia routable IPv6-osoitetta, ja ping6 toimii jo siitä
Sitten LANiin pitää valita staattiseksi IPv6-osoitteeksi vaikka joku muu /64 verkko (ei se sama, joka on gif-interfacessa jo käytössä. Muita vaihtoehtoja on 65535 kappaletta) Configure IPv6 Tunnel Broker — OPNsense documentation

 

[mikajh]

Jaahas, yksi tunneli hajosi. Olinkin juuri lisäämässä toista dual-WANiin NPT:llä, sille voi olla tarvetta
E1: Ei ollut onneksi Route48-puolen ongelma, vaan pfSensen ilmeisesti. Jos on vaikka kaksi GIF-interfacea, viimeksi käyttöön otettu toimii (esim. interfacen disable/enable), täytyy tutkia lisää
E2: Nyt toimii dual WAN IPv6 load balancing NPt:llä, tosin em. ongelmasta johtuen niin, että toinen WAN menee Kuusitunneli.fi:in

 

[ztec]

Tuossa 1.1.1.1:ssähän on sekin vika/ominaisuus, että se haluaa olla ainoa aktiivinen vpn ja tappaa muut (there can be only one: )

Niin vika tai ominaisuus, WARP:n etu on siinä, että sehän tuo IPv6:n laitteisiin kun sen heittää päälle. Eli jos joku kysyy helpointa IPv6 tunnelia ja myös todnäk parasta (normaalikäyttäjälle), niin WARP:ia voisi mielestäni pitää sellaisena.

Mielestäni riittää, että sallii IPv4 ICMP echo requestin vain (Route48:n) Server Addressista

Testasitko, kuin tuon on juuri se, mitä tein, ja ei toiminut. Oletin sitten, että se tulee todnäk jostain kuten niiden web-UI:lta tms, joka sitten mahdollisesti etäkonfiguroi tunnelin toiseen sijaintiin tms. En tiedä miten toi backend on toteutettu. Mutta hyvin vois kuvitella, että siellä ois tuollainen pieni glitchi.

Mulla on noihin kaikkiin Kuusitunneli, tunnelbroker (Tukoholma) ja route48 (Suomi) jatkuva 24/7 monitorointi, alertit ja logit. Nopeesti näkyy jos jossain pykii.

Ongelma on, että ne viestit vaatii välillä tulkkausta, esim mikä on mahdollinen hyöty on esim. tästä projektista jollekin n. 100 koneen minifirmassa, jossa tuskaillaan pääsyä firman sisäsessä verkossa sijaitsevaan SMB-jakoon. Budjetti on tasan NOLLA, mutta firmasta löytyy kaksi fyysistä palvelinta, joista toinen pyörittää Hypervisoria johon mahtuu 1-3 virtuaalikonetta lisää.

Suosittelisin että ajatte omaa VPN:ää, esim. WireGuardilla. Toisaalta IPv6 kiinteillä osoittelilla toimii "melkein VPN:nä", jos ja kun on kiinteät IPv6 osoitteet käytössä. Sitten voi listata että salli vain tästä rangesta tulevat yhteydet. Tietysti jos protokolla on salaamaton, niin tuohon liittyy vielä ongelmia. SMB:ssä voi kyllä heittää salauksen päälle. Mutta en missään nimessä kyllä exposettaisi IPv6:n yli SMB:tä globaalisti, vaan ehdottomasti vain muutamaan whitelistattuun osoitteeseen / rangeen.

Itsehän en ole koskaan tietenkään moisia virityksiä tehnyt, köh köh. Mutta toi menee vähän siihen harmaaseen sektoriin, että tietoturva ei oo ihan 100%, kun ei ole oma VPN ratkaisu käytössä. Mutta on 99,9% satunnaisten hyökkääjien / skannaajien osalta, jotka eivät näin ollen löydä niitä päätepisteitä, kun eivät suorita hakujaan luotetusta avaruudesta. Tosin onko tuolla sitten väliä, jos tuon range filtterin lisäksi on esim, RDP / TLS / SSH mikä tahansa muu autentikoitu ja salattu protokolla siinä päällä käytössä? Joskus tuntuu jopa hassulta, että pitäisi olla kaksin tai kolminkertainen salaus päällekäin, mitä sillä sitten oikeasti saavutetaan? Btw. toi SSH:n portti-ohjaus toimisi myös teidän tilanteessa. Mut eiks tää oo kuitenkin vähän off topic tähän asiaan. Eli yksi kone teidän verkkoon jossa on IPsec / WireGuard / SSH, mistä sitten ikinä tykkäätkin, ja sen kautta sitten jatkot sisäverkkoon, luoteteuista verkoista ja käyttäjiltä / työasemista. - Tällaisia on tullut tunkattua lukemattomia, ja näin yleensä organisoin myös itse pilvi-infrat jne. Eli on "bastion host" josta sitten liikenne välitetään eteenpäin.

Tämä setuppi löytyy myös operoimistani Tor-palvelimista, koska ne on ihan järjettömän hyökkäyksen edessä, jos ei ole tuollaisia perussuojaus ja kovetus asetuksia tehty. Nyt kukaan ei edes näe mitä hallinta protokollia / tekniikoita on sallittuna ja mistä.

 

[ztec]

Lisätään vielä tuosta Cloudflare WARP:ista tämä screenshot. Eli sillä saa heittämällä IPv6:n kuntoon myös liittymässä kuin liittymässä.

Tuolla oli myös keskustelua DHCPv6:sta ja RA:sta, käsittääkseni DHCPv6 ei toimi automaattisesti, ilman RA paketteja, ellei sitten ole erikseen konfiguroitu lähiverkon asetuksia jo muuten kuntoon. Normaalisti se on nimenomaisesti RA joka kertoo, että verkko on managed tilassa ja tulisi käyttää DHCP:tä eikä SLAAC:ia. Joskin on olemassa tilanteita jolloin DHCPv6:n voi aktivoida ilman RA:ta, mutta se on normaalien käyttäjien scopen ulkopoulella. Esim. hakemaan DNS tiedot.

 

[tigeli]

Näyttäisi toimivan, tosin kuusitunneliin verrattuna "on-link mtu" piti tiputtaa 1480 -> 1450 että paketit tulivat perille asti.

 

[ztec]

Tunnelbroker fiksusti ei käytä 0 networkkiä reititykseen, kuten route48 käyttää. Mutta kun tuo vähän sieppasi, niin totesin, että pakkoko sen reititys networkin on olla /64:lla? Vaihdoin sen /126 prefiksiksi ja kaikki pelaa edelleen hienosti. Nyt saan sitten loput tuosta subnetistä napattua yhteen laniin jossa on kiva kun saa mahdollisimman paljon turhaa veke :: nollien hukkaus merkinnällä. Joku voi kertoa jos toi on massive fail, mutta ainakaan mitään ongelmia en (viielä) löytänyt edes kohtuullisella testaamisella.

 

[amrs]

Route48 :: IPv6 Tunnel Broker :: 100% Free IPv6 BGP Transit, 100% Free IPv6 Tunnel Broker

Tämä toimii myös NAT:n läpi, eli on aivan kaikkien halukkaiden käytettävissä, sekä tukevat myös Wireguard VPN:ää ja sitä myöten myös liikenteen salausta. Vaikuttaa teknisesti katsottuna ainakin selvästi parhaalta IPv6 tunnelilta mitä Suomessa on saatavissa.

Tulipa tuota nyt kokeiltua, siis sit-tunneli (6in4) Linux-reitittimeen systemd-networkd:llä ja jako sisäverkkoon. Aikani tuhersin mutta reitittimestä ei mennyt IPv6 minnekään, route48:n ohjeet sisältävät vain sen miten tuon putken saa kasaan. Kunnes bongasin jostain maininnan että 6in4 on "manuaalinen" jolloin vihdoin tajusin että pitää vaan manuaalisesti laittaa joku siivu jakoon sisäverkkoon ja että reititys toimii ulospäin niin vaatii myös ipv6:n sisäverkon sillalle. Täytyy sanoa että networkd:n tuki 6rd:lle teki sen putken pystyttämisestä pari dekadia helpompaa mutta olipa edes mistä katsoa mallia kun tuo 6rd setup oli olemassa.

Ihan varma en ole edelleenkään onko tuo nyt järjellisesti konfiguroitu mutta toimii kuitenkin. Oudolta tuntuu että Google ei löytänyt yhtään esimerkkiä tällaisesta putkesta vaikka ei kai se niin eksoottinen ole.

 

[ztec]

Route48:n ohjeet sisältävät vain sen miten tuon putken saa kasaan. Kunnes bongasin jostain maininnan että 6in4 on "manuaalinen" jolloin vihdoin tajusin että pitää vaan manuaalisesti laittaa joku siivu jakoon sisäverkkoon ja että reititys toimii ulospäin niin vaatii myös ipv6:n sisäverkon sillalle.

Meikäläisen Netplan:

tunnels:
    r48:
      mode: sit
      remote: 185.218.193.178
      local: 0.0.0.0
      addresses:
        - "2a06:a003:####::2/48"
      ipv6-privacy: true
      accept-ra: false
      routes:
        - to: "::/0"
          via: "2a06:a003:####::1"
          on-link

Saa koko /48:n reititettyä kerralla, ja tuosta voi sitten jakaa eri VLAN:eihin /64:t tarpeen mukaan. Käytössä tällä hetkellä 5 /64:sta.

 

[samip537]

He on läpsäisseet lapun luukulle.

 

[Algron28]

Enpä ole kauhean yllättynyt, valitettavasti....

 

[ztec]

He on läpsäisseet lapun luukulle.

Harminlista. Suomalaiset ISP:t ei ole vielä saanet hommiaan kuosiin. Ja he.net ei ole sekään kovin hyvä vaihtoehto. Saas nähdä ilmestyykö jostain jotain käyttökelpoista tilalle. Toivottavasti.

Varmaan joutuu välissä ottamaan he.net:n taas käyttöön ja nauttimaan sitten sen tuomista haasteista. Sivut tuntuu olevan täysin jumissa tällä hetkellä.

Linkki: tunnelbroker.net

Tietenkin Route48 tarjosi VPN ominaisuudet ja toimi myös CGNAT:n takaa, mitä tunnelbroker ei tee. Joten siinä mielessä r48 oli kyllä varsin ylivoimainen palvelu. Lisäksi suomen yhteiyspiste toimi nopeasti ja vakaasti, ihan muutamaa pientä katkoa lukuunottamatta koko tämän ajan.

 

[ztec]

Näköjään yhtenä hyvänä vaihtoehtona on myös route64, joka tukee myös WireGuardia:

Home | ROUTE64: free transit & ipv6 tunnelbroker provider

Free transit provider for ipv4 and ipv6 transit to support ipv6 distribution or get a free ipv6 subnet via our tunnelbroker service

route64.org