Telekom IPv6 a láthatáron?

 ( Zozz | 2016. október 25., kedd - 20:26 )

http://www.telekom.hu/rolunk/ipv6

Belefutottam ebbe a linkbe. Azt írják, 2016 végétől a lakossági ügyfelek minden technológián (mobilon is) kaphatnak IPv6-ot. Ezen a linken aránylag részletesen leírják a szolgáltatás műszaki részleteit. Én nem értek nagyon az IPv6-hoz, de ez alapján elég korrekt szolgáltatásnak tűnik. Hozzáértők leírhatnák a véleményüket.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A műszaki leírásból igazából csak az utolsó pár pont érdekes:

- A HGW Internet felőli oldalára egy /64-es IP subnetből 1 db. IPv6 címet kap.

Korrekt, bár nem tudom minek, de így szokás. (A link-local címek erre tökéletesen elegek lennének, szokott is velük működni, de mégis adnak mellé publikusat.)

- A HGW 1db /56 prefixet is kap, melyből az első /65 prefix a LAN oldalon kerül felhasználásra

Ez vélhetően elírás, a LAN oldalnak /64-nek kellene lennie. (Ha valóban /65 akkor lényegében használhatatlan.) Viszont a /56 előrelépés, rendes saját router esetén ez azt jelenti hogy több belső subnetet is meg tudsz címezni IPv6-tal. (Az egyetlen lakossági IPv6-ot nyújti DIGI-nél erre nincs lehetőséged.)

- A kiosztott /56 prefixek és az Internet felőli 1 db. IPv6 cím csak addig maradnak változatlanok az adott végponton, amíg a kapcsolat meg nem szakad, ezt követően újracsatlakozáskor új cím kerül kiosztásra

Ez szívás, és nem igazán értem az okát. DIGI-nél is így van, egy csomót kell hekkelni mire az eszközök rájön hogy új címe van. Remélhetőleg az IPv6 terjedésével ezt alapból jobban fogják kezelni az eszközök.

- HGW-ekben alapértelmezetten az IPv6 tűzfal úgy van konfigurálva, hogy internet felől ne lehessen IPv6 kapcsolatot létrehozni ügyfeleink helyi hálózata felé. Ez a funkció a HGW beállításaiban, jellemzően kikapcsolható.

Korrekt, bár ha egybites a kikapcsolás (vagy minden vagy semmi sem érhető el) akkor lényegében nem szabad kikapcsolni. Fehérlistáról nincs szó, de remélhetőleg lesz rá valami ügyes megoldás. (IPv6 címet ugye nem tudsz statikusan fehér-listázni, mert mint fentebb jelezték változnak. Szóval ehhez valamilyen trükkös MAC vagy DNS vagy esetleg "fordított maszkolás" kell.)

Összefoglalva nagyjából rendben van. Számomra egyébként nehezen érhető, hogy a szolgáltatók miért nem szeretnének statikus IPv6-ot nyújtani.

"Számomra egyébként nehezen érhető, hogy a szolgáltatók miért nem szeretnének statikus IPv6-ot nyújtani. "

mint ahogy v4-en se kapsz statikus ip-t.
Gondolom lehet érte jó pénzt kérni, másrészt minek statikus ? Mivel lakossági neten elvileg nem nagyon szolgáltathatnál szerver ilyenek, így nem kell statikus ip sem.

Fedora 24, Thinkpad x220

IPv4-en a belső hálód NAT mögött van, ezért házon belül tudsz statikus (privát) címeket osztani.

IPv6 esetén normális esetben nem használsz NAT-ot, így a prefix változásakor az egész belső hálód átszámozódik, és mondjuk a WAN kapcsolat leszakadásakor lerohad a belső gépeid közötti kommunikáció is, ha nem Unique Local vagy Link Local felett megy. (SLAAC mellett ki tudsz szórni Uniqe Local és Global prefixet a belső gépeknek egyaránt, viszont DHCPv6 esetén a kliensek "by default" csak egyféle címet tudnak kérni maguknak, kivéve ha hegesztesz a kliensen - és, ha a kliens egyáltalán lehetővé teszi.)

Az IPv6 szabvány is változott menet közben, a "nagyon nagy valószínűséggel egyedi" unique local / site local címek koncepcióját elvetették. Maradtak a link local címek, amik viszont ugye nem igazán routeolhatóak. Ez azt jelenti hogy ha dinamikus /56-ot kapsz, akkor két /64-es subneteid között az átjárást egészen konkrétan nem tudod megoldani hacsak nem konfigurálod azt is újra minden címváltáskor.

De a legnagyobb probléma az, hogy mivel az IPv6-nál a router nem fedi el a címváltozást, ezért egy belső eszköz számára egészen addig elérhetetlen az egész internet, amíg rá nem talál az új címére. Hogy ez ne okozzon gondot, az IPv6 címeknek testing-preferred-deprecated-invalid életciklusa kellene legyen, amit persze a szolgáltatók nem tartanak be. Következmény a usability fail: a legtöbb eszközt egy címváltás után rá kell erőszakolni az új címére, pl. a WiFi ki-be kapcsolásával.

IPv4 esetén ugye ilyen gond nincs, mert a NAT ápol és eltakar. Egy címváltás a nyitott kapcsolatok szétesését okozza ugyan, viszont az esetek 99%-ában a szoftverek ezt maguktól a háttérben egy újracsatlakozással lekezelik, és a felhasználó meg sem érzi a döccenést.

> Következmény a usability fail: a legtöbb eszközt egy címváltás után rá kell erőszakolni az új címére, pl. a WiFi
> ki-be kapcsolásával.

Na, de a kliens miért nem hallja meg a router advertisementet az új prefix-szel? (Én teszt jelleggel váltogattam prefix-eket, és a kliensek jellemzően 1-2 másodperc alatt átálltak. Csak szerencsém volt?)

> Egy címváltás a nyitott kapcsolatok szétesését okozza ugyan, viszont az esetek 99%-ában a
> szoftverek ezt maguktól a háttérben egy újracsatlakozással lekezelik, és a felhasználó meg sem
> érzi a döccenést.

Ezt kérlek magyarázd el a stateful tűzfalaknak is, mert ők nem tudnak róla. Oké, ha a kliens teljes újracsatlakozást (SYN...) csinál, akkor újra átmegy a tűzfalon. De a teljes újracsatlakozásról meg az SSH, SIP és társai nem tudnak.

> Na, de a kliens miért nem hallja meg a router advertisementet az új prefix-szel?
> (Én teszt jelleggel váltogattam prefix-eket, és a kliensek jellemzően 1-2 másodperc alatt átálltak. Csak szerencsém volt?)

Tapasztalatom szerint felveszik az újat, de nem dobják el a régit mert nem járt le. Ennek következményeként egyrészt ha valaki megkapja a régi címtartományodat azt te nem éred el (nyilván ennek kicsi az esélye), másrészt az alkalmazások küzdhetnek tovább a régi címmel, ha akarnak.

> Ezt kérlek magyarázd el a stateful tűzfalaknak is, mert ők nem tudnak róla. Oké, ha a kliens teljes újracsatlakozást (SYN...) csinál, akkor újra átmegy a tűzfalon.

Teljes újracsatlakozás úgyis kell, mert a túloldal más címről lát téged, tehát ott mindenképpen szakad, tűzfal nélkül is. (A tcp kapcsolatot ugye 2 cím + 2 port határozza meg.)

> De a teljes újracsatlakozásról meg az SSH, SIP és társai nem tudnak.

Igen, ők az 1%. A 99% meg HTTP, és különböző http jellegű zárt protokolok.

Az is lehet hogy routing gondok álnak a dinamikusság mögött. Nehéz megoldani hogy a terheléselosztáskor utánad menjen a v6 prefixed, ezért inkább kapsz egy olyat ami ott kéznél van? (http://blog.ipspace.net/2010/10/dhcpv6-over-pppoe-total-disaster.html)

Mivel lakossági neten elvileg nem nagyon szolgáltathatnál szerver ilyenek, így nem kell statikus ip sem.

Mert valamiért az terjedt el, hogy bár te internet-kapcsolatot veszel, ez lassan kimerül a http-ben...
Hát az nem internet-kapcsolat!
Egyébként nem értem, hogy miért fájna a szolgáltatónak, hogy én az 5/0.5 ADSL-emmel szervert üzemeltetek. Megy is már jópár éve, soha nem szóltak érte.

Azért fájhat mert erre van a bérelt, vonal. Amúgy üzemeltethetsz persze senki se mondta hogy nem.
Csak vannak hátrányai, ami főleg levelezésnél szokott előjönni.

Fedora 24, Thinkpad x220

Már bocsánat, de mit nevezünk jelen esetben szervernek? Mert nekem pl. az az igényem, hogy:

1.) Haza tudjak SSH-zni
2.) Haza tudjak VPN-ezni
3.) Az otthoni "okos" rendszereket (pl. kazánvezérlés) tudjam távolról basztatni (Web szerver!)

Egy élmény volna, ha ezeket nem dinamikus IP felett, dyndns-sel kellene megoldani. (Persze valójában hazatunnelezek egy fix IP címet, mivel "hobbiból" ISP vagyok és van saját IPv4 prefixem, csakhát akkor meg ugye nincs natív/optimális routing.)

Nyilván a legjobb az volna, ha adnának a 4500 Ft-os otthoni csomaghoz BGP peering lehetőséget :)))

"Egy élmény volna, ha ezeket nem dinamikus IP felett, "

Pont ezt mondtam, az élményért fizetni kell.

Fedora 24, Thinkpad x220

> Viszont a /56 előrelépés, rendes saját router esetén ez azt jelenti hogy több belső subnetet is
> meg tudsz címezni IPv6-tal. (Az egyetlen lakossági IPv6-ot nyújti DIGI-nél erre nincs
> lehetőséged.)

FYI: a UPC-nél is van már DS-Lite alapú "lakossági" IPv6, ahol pedig kizárólag SLAAC /64 van. Annál valóban jobb.

Hozzáteszem, hogy a UPC-féle DS-Lite implementáció külön szívás azért, mert a DS-Lite alapjaiban véve egy natív IPv6 fölött kitunnelezett IPv4-et jelent - és ezáltal a technológia lehetővé tenné publikus IPv4 cím kitunnelezését is, de a UPC kizárólag privát IP-t hajlandó rajta szolgáltatni. Magyarul, választhatsz:
- publikus IPv4 (MTU 1500), IPv6 nélkül,
vagy
- privát IPv4 (MTU 1460), IPv6-tal.

A UPC IPv6 implementációja jelenlegi formájában szerintem nem elfogadható, itt sajnos még mindig az IPv4+SiXXS tunnel a legjobb megoldás. (Külön pikáns ízt kölcsönöz ennek a UPC peering-politikája).

> Külön pikáns ízt kölcsönöz ennek a UPC peering-politikája

Na, meg a Telekomé. Nézd meg a Telekom BGP hirdetését a BIX-en. Annyiféle "érdekes" community van rajta, hogy csak na. A Hurricane Electric BIX POP például csak Prágán át érhető el Telekom hálózatból, Budapestről.

+1
Számomra egyébként nehezen érhető, hogy a szolgáltatók miért nem szeretnének statikus IPv6-ot nyújtani.

Én sem értem, az IPv6-ot eleve úgy alkották meg, hogy ha minden porszem kap külön címet, akkor is van elég.

Egyébként köszi az összefoglalót!

Lehet, pont ez a baj. Minden porszem forgalmát már nem bírnák, a NAT meg visszafogja a dolgokat :) Esetleg megnövekedett adminisztrációs terhek és a szakik tömeges képzése. Az eszközcserét ne is említsük, bár azért már illene mindnek támogatnia, kivéve a legolcsóbb otthoni routerek, amiket kiszórtak nagy kegyesen a szolgáltatók "ingyen".

Köszönöm a választ (a többieknek is)!
A leírás szerint különbség van a DOCSIS és az egyéb technológiájú hálózatok között, pl. DOCSIS esetén nem változik az IP cím:
"A kiosztott /56 prefixek általában változatlanok hosszú ideig egy adott végponton, de bármilyen Telekom oldali hálózati átalakítás vagy HGW csere esetén a delegált /56 prefix megváltozhat"

A másik, hogy én eddig azt hittem (ez az IPv6 marketingszöveg) hogy minden eszköznek egyedi, fix IP címe lesz. Ezek szerint ez nem így van, továbbra is szívni kell DynDNS szerű dolgokkal.

--
Soli Deo Gloria

Egyedi címe lesz, csak nem fix, különben miből élnének meg a szolgáltatók :D . A NAT száműzése így is kipipálva.

Ezek szerint ez nem így van, továbbra is szívni kell DynDNS szerű dolgokkal.

Ha jól értem, akkor nem feltétlenül kell, hiszen nem arról van szó, hogy akár naponta kétszer is megváltozna, hanem arról, hogy X évente, ha változik a hardver, akkor változhat a cím is.
Egyébként a céges fix IPv4 címünk is ~10 év alatt változott egyszer.

Ez szívás, és nem igazán értem az okát. DIGI-nél is így van, egy csomót kell hekkelni mire az eszközök rájön hogy új címe van. Remélhetőleg az IPv6 terjedésével ezt alapból jobban fogják kezelni az eszközök.

A leírás szerint nem változik sűrűn. Nálam pl. évek óta nem változott az IP. Ha ez így lesz a tartománnyal is, akkor nem lesz ez rossz (egyébként már megy itt DOCSIS-en is):

- A kiosztott /56 prefixek általában változatlanok hosszú ideig egy adott végponton, de bármilyen Telekom oldali hálózati átalakítás vagy HGW csere esetén a delegált /56 prefix megváltozhat

--
http://naszta.hu

Kábelmodemen ahol csak simán DOCSIS van. PPPoE-n minden becsatlakozáskor más IPv4-et kapsz, valószínűleg a v6 sem fog maradni.

Rég volt ADSL-em. Mi ott most a periódusidő? Annak idején 24 óra volt. Optika is PPPoE-n megy? Ha igen, az tényleg szívás.

Update: közben elolvastam azt a részt is, ami nem rám vonatkozik. ADSL-en és optikán szívás ez még...
--
http://naszta.hu

Azt nem értem, miért éri meg nekik szórakozni a dinamikus kiosztással??

IPv4 esetén elfogadható indok, hogy kevés a cím, és spórolnak vele, de v6-nál semmi értelme a dinamikus játéknak, megoldható lenne, hogy mindig ugyanaz cím/tartomány kerüljön kiosztásra.

Marhára úgy tűnik, hogy Nat6 lesz az egészből!

Irgalmatlanul idegesítő, hogy a modem napi 6x-8x újracsatlakozik, és minden alkalommal több perc, mire észreveszi magát a v6 hálózat...

Amióta elterjedtek az otthoni routerek, már az ipv4 spórolás sem áll meg, mivel mindenki mindig fel van csatlakozva.

> Kábelmodem vagy bridge módban használt HGW esetén a modemre kapcsolódó ügyfél eszköznek
> kötelezően DHCPv6-ot kell használnia, ott az SLAAC nem támogatott
> ...
> (ADSL/GPON) Modem esetén a modemre kapcsolódó ügyfél eszköznek DHCPv6-ot kell használnia

Modem (bridge) módban használt GPON HGW-m van. Az IPv4 PPPoE fölött érkezik.

1.) A "tesztidőszak" alatt kellett csinálni egy második PPPoE session-t, amin lehetett DHCPv6 PD kérést csinálni. Ezentúl nem kell majd második session, hanem egy dual-stack PPPoE session fölött érkezik majd az IPv4 és az IPv6?

2.) A "tesztidőszak" alatt statikus /56-ot adtak. Ha ez most tényleg dinamikus lesz (és igényelni sem lehet statikusat) akkor szüljenek farfekvéses tarajos sült a DIGI-vel együtt! (Főként, hogy a DIGI a céges, fix IPv4 címet tartalmazó feláras csomaghoz is dinamikus IPv6 prefixet ad!) REGRESSZIÓ!

Nekem a "tesztidőszakos" második PPPoE session továbbra sem megy (a PAP authentikáció sikeres, de nem jön meg a linkre a prefix IPV6CP-vel) illetőleg az első (IPv4-es) PPPoE sessionra sem sikerül IPV6CP-zni. Ezek szerint nálam még nem aktív a szolgáltatás? (Gondolom, nem a nyers ethernet interfészen kell DHCPv6 PD-t küldeni, hanem ez is PPPoE-be lesz enkapszulálva)

-

Nézegettem, hogy kis céges környezetben hogy lehetne legegyszerűbben elérni az IPv6-ot. Lehet egy ideig a belső hálót IPv4-en kellene hagyni és kifele az IPv6 elérést pl web proxy-n keresztül, az átjáróra telepített SMTP proxy-val és más proxy/repeater alkalmazásokkal megoldani. IPv4-es kliensről squid segítségével tudtam böngészni az IPv6-os oldalakat. Levélküldésnél is a DNS név a fontos. SIP esetén is vannak proxy-k meg egyszerűbb szerveralkalmazások.
Biztos jó dolog az IPv6 a világhálón, de kis helyi hálón nem tudom, van-e sok értelme. De tényleg, ha van, akkor írjátok meg nekem, mert még nem jöttem rá. A NAT léte-nem léte nem izgat annyira, a helyi szolgáltatások szempontjából érdekelne.

Sok előnye van azért ezen kívül is, alapjában véve fejlettebb technológia.

Egy érdekes példa a broadcast storm IPv4-en: A gyakorlatban pár ezer gépnél többet egy v4-es lanra nem igazán lehet kötni, mert a hálózat önmagának generált broadcast forgalma (ARP, DHCP) olyan nagy lesz, hogy jelentős processzor erőforrásokat esz meg, az olcsóbb routerek le is döglenek tőle. Kolégiumokban ez úgy szokták workaroundolni hogy mesterségesen feldarabolják a hálót /24-22 darabokra, de persze ennek routingban fizetik meg az árát. IPv6-nál ilyen probléma nincsen: mivel broadcast helyett solicited-node multicast van, ezért egy IPv6-os hálózat nagyságrendekkel jobban skálázódik.

Persze a nem romlott el ne javítsd meg elvet követve nem fogsz belátható időn belül átállni IPv6-ra :-)

Nincs itt nem hogy ezer, még száz gép se és még a LanSweeper 100-as korlátjába se ütköztünk bele. De azért nem baj, ha egyes szolgáltatások kilátnának az IPv6-os Internetre.
Tényleg amúgy az IPv6-os része a világhálónak az már az Internet 2? Valamikor régen bedobták ezt a nevet, de nem tudom, hogy most mit értenek alatta.

Az Internet 2 az egy egészen más dolog, még valamikor a 2000-es évek elején kezdődött, tulajdonképpen az internet interaktívvá válását jelentette, de lehet, hogy többmindent értettek még ez alatt. A Google-ban biztos utána lehet nézni a részleteknek. :)

Az a Web2, amire te gondolsz. Az Internet2 az más:
https://en.wikipedia.org/wiki/Internet2

Tényleg az a Web 2.

A telekom oldalon nincs konkret datum - van, akinel mar el ez a szolgaltatas?

Nálam mai nappal kapcsolták be.

Ez jo hir. Egyszercsak megjelent magatol, vagy HGW reboot kellett kezzel (azt gondolnam, uj firmware/konfig kell)?

Megjelent magától.

Ha kell is, simán megcsinálják távolról Telnet-en keresztül. Hacsak le nem tiltod a HGW-n a Telnet-et :)

--
robyboy

Nálam egy újraindulás után megjelentek IPv6-tal kapcsolatos menüpontok, a router mode átváltott IPv4-ről Dual Stack-re, de nem kap IPv6-os címet, így még nem működik...
Mobilon viszont úgy néz ki megy, miután az APN-t átállítottam IP4/IP6-ra.

--
Soli Deo Gloria

Es valoban, mobilon szepen megy.
Akit erdekel, van telekomos video youtubeon a beallitasrol: https://www.youtube.com/watch?v=A6rjO3l3rhw&feature=youtu.be

Mobilon is tartományt ad a T, vagy ott csak egy darab IPv6 címet?

Ez sehol nincs leirva, de gondolom egy darabot.

Ami azért határeset, mert egyfelől IPv6 cím tényleg nagyon sok van, másfelől meg egy mobil is tudhat hotspot módot és onnan kezdve lenne minek tovább osztani az IPv6 címeket.

Invitelről nincs hír?

Invitelnél még kanyarba sincs...

:( , na mindegy, már csak egy év hűségidő és addigra talán a Telekom kiépíti az optikát itt is, mert behirdették a modernizációt.

Sajnos globális IPv6 címem még mindig nincs, de próbálkoztam a belső hálózaton játszani kicsit: minden eszközömnek van link local IPv6 címe (fe80:: kezdetű) és ezen próbálom őket elérni. Pingetni lehet is, de a router weboldala nem érhető el, ha az IPv6 címmel próbálom: "A webhely nem érhető el ERR_INVALID_ARGUMENT" a hibaüzenet. Ez mitől lehet? Chrome böngésző, a címet szögletes zárójelek közé írtam.

--
Soli Deo Gloria

A Chrome nem támogatja a Link-local címek használatát távoli gépek elérésére. Firefoxból megy.

ahh, köszi :(

--
Soli Deo Gloria

Meg kell cáfoljalak, mert nálam bejött.

http://[fe80::12fe:edff:fec1:a45e]/cgi-bin/luci

Úgyhogy szerintem Zozz csak rossz linken lokális címmel próbálkozott.

Nálam a Chrome (v54 / Linux) szintén ezt mondja:

This site can’t be reached

The webpage at http://[fe80::c24a:ff:febe:8f34]/cgi-bin/luci might be
temporarily down or it may have moved permanently to a new web address.

ERR_INVALID_ARGUMENT

Ugyanez Firefoxból működik.

Kis háttérolvasmány, miért nem praktikus a link local irány: https://en.wikipedia.org/wiki/Link-local_address
Helyette adj (akár a routeredből automatikusan) "192.168.x.x"-jellegű belső Unique local címet az fd00::/8-ból.
Bővebben: https://en.wikipedia.org/wiki/Unique_local_address

Kis háttérolvasmány, miért nem praktikus a link local irány: https://en.wikipedia.org/wiki/Link-local_address

Szerintem a linkelt oldal nem arról szól, hogy miért nem praktikus, hanem arról, hogy mi az.

+1
Nem tudom mi a hátránya a link-local címnek és miért nem támogatja a chrome. Nekem ennek használata természetesnek tűnne belső hálózaton, ha már ilyet kap automatikusan minden host.

--
Soli Deo Gloria

Azért a link-local cím sem tökéletes. Több hálókártya esetén (WiFi+LAN) már kérdés, hogy melyik kártya legyen a feladó? Mindkettő ugyanabban a tartományban van, ugyanazt a tartományt látja - de csak IP címek tekintetében. Innen kezdve egy link-local IP-t csak maga az IPv6 cím nem azonosít egyértelműen, azt is tudni kell, hogy melyik local linken lehet elérni!

Azért ennyire nem rossz a helyzet: valamelyiken! Mivel a link-local címek is általában MAC-ből vannak számolva, nem valószínűbb hogy lesz ütközés mint hogy L2 ütközés lenne. Persze vannak kivételek, de 99%-ban egyértelmű egy cím. Simán jó lenne ha hálókártya infó hiányában azon a linken érnénk el a címet amelyiken először találunk megfelelőt.

A fenti wikipedia cikk szerint a megoldás ki van találva: az interfész azonosítóját a cím mögé kell írni % jellel elválasztva (fe80::3%eth0). Persze hzsolt94 fenti ötlete is működhetne, az esetek 99%-ban ha van is két hálózati interfész, csak az egyik működik, így lehetne tudni merre kell küldeni.
Sajnos úgy látom a Chrome-ban ezt nem akarják támogatni, pedig ahogy az utolsó hozzászóló írja, sokszor szükség lenne rá (persze amíg van IP4 is, addig nem égető...)

--
Soli Deo Gloria

Szerintem kár a gőzért. Ha valakinek nincs "rendes" publikus IPv6 prefixe, tegyen fel egy Unique Local-t, és máris mindennel ugyanúgy lehet tesztelni, ismerkedni, homokozni...

Egyébként akkor is jól jön az Unique local, ha a szolgáltató dinamikus IPv6-ot ad.
Miért? Mert a fránya LAN-os eszközeidnek mindig változik a publikus IPv6 címe. Jó ha van belül valami állandó, könnyebb belső DNS-t csinálnod, stb.

Ezért az eszközök nálam IPv6-on:
- Digi-s publikus IP-t megkapják - minden napra másikat.
- Unique localt - ez van a belső DNS szerverben feloldva.
- Link local meg adott a hálózati háttérszolgáltatáshoz, másra mint fentebb írtam nem praktikus erőltetni.

$ ping6 raspberrypi3
PING raspberrypi3(raspberrypi3.lan (fdee:f362:64f7::839)) 56 data bytes
64 bytes from raspberrypi3.lan (fdee:f362:64f7::839): icmp_seq=1 ttl=64 time=1.44 ms

Unique Local-al próbáld, azt néztem, hogy otthoni hálózat esetén is jobb választás lehet, mint a link local és az OpenWRT támogatja, legalább is a Chaos Calmer.

btw, tegnap belőttem OpenWRT-re, mondom teszek egy próbát, hátha bekapcsolták már itt is.

És igen!

Bár alapvetően egy DIGI* howto-t követtem a beállításhoz, de az mellékes.

https://logout.hu/bejegyzes/slug/digi_ipv6_over_pppoe_openwrt.html

konkrétan ezt itt ^^

https://1drv.ms/f/s!AmKObYSrI5vilwNieqcWeULvrN7m

kicsit kimaszatolva, de műxik (fentebb pár kép). Gyakorlatban az összes eszköz kapott rendes "kintről" látható v6 címet, hogy "hülyén" fogalmazzam meg.

by-default openwrt firewall tilt minden féle cuccost befele.

Ami próbáltam, ipv6 szerver pingek, ipv6 oldalak, chrome-hoz leszedtem egy kis extensiont, ami mutatja hogy az adott oldalon épp mi jön v6-on és mi jön v4-en.

klienseken gyakorlatilag semmit nem kellett állítani. A DHCP-t sem csesztettem, kapok egy local v6 címet ha jól láttam, amit kioszt a wrt dhcpje + megkapja a kliens a t-online által kioszott "külső" v6 címet is.

Kis teszteket végezve. OpenWRT "net felöli lába" válaszol pingre (így van belőve).
Kipróbáltam a saját gépemen egy apache-ot 80-as porttal + a saját v6 külső címével. OpenWRTben itt csak annyit kellett engedélyeznem a tűzfalba, hogy bejövő v6 (azaz wan6) esetén a 80-as portot engedje be bárhova. Teszt jelleg volt.

Külső v6-os szerverről meghívtam a gépem v6 címét 80-as portra és tádám, fogadott egy apache.
Tök független webes ipv6 portscanről direktbe scanneltettem a 80-as portot a kliens v6 IPre, ment.

Csak egy kis összegzés hogy elkezdett működni. :)

ps.: jah, Kecskemét helyileg.
ps2.: btw kissé összekavarodtam, mert ma már tökmás a vége a saját gép v6jának (a net felöli WRT-n maradt). Tény, ennek még utána kell olvasnom rendesen :)

üdv
-krix-

"btw, tegnap belőttem OpenWRT-re, mondom teszek egy próbát, hátha bekapcsolták már itt is.

És igen!"

Ejjjh, de várom már a szülők telefonhívását otthonról... Náluk Sagemcom doboz van, a beépített szolgáltatások felét ki kellett lőni (de még a DHCP is idetartozik ám), mert használhatatlanok voltak, a másik felét nem használom, szóval a mögé rakott rendes router, na meg az NMHH mérőbox, meg a wifis multinyomtató.
"Remélem" tényleg tolt egy új firmwaret a T, gyári beállításokkal, és minden romokban odahaza... :) :/

Szerintem az hogy magán a T* vagy bármi más modemen bekapcsolják az ipv6ot, semmit nem fog eredményezni a "szülők" routerén :)

Mivel ahhoz hogy az ipv6ot használjon, kell egy kicsit heggeszteni azért :)

Bár ha nincs saját router és a ISP* routere oszt mindent, nos, akkor valóban lehet gond :)

Amikor a T bekapcsolta az IPv6-ot nálunk, akkor semmit nem kellett hegeszteni, a router mögötti gépek automatikusan kaptak IPv6 címet és tudtak kifelé IPv6-on kommunikálni. A befelé irányhoz, hogy kintről elérhessék a router mögötti gépet, kellhet esetleg hegeszteni.

hadd kérdezzem meg, hogy kinek milyen Telekom által adott GPon gateway-e van?
nekem HG8245 - anno a 120mbps nethez ilyet adtak, és állítólag viszi a gigás netet is.

Viszont ez csak router módban tud működni, bridge-ben nem...
Illetve láttam valami olyan trükköt,h Firebug-ban átheggeszteni html form-ot,de ehhez nem voltam elég bátor :-)

vagy másnak másik CPE van?

Nekem HG850a van. Sosem próbáltam menedzselni, drop-in-replacementként érkezett az ADSL modem helyett, csak átdugtam az ethernet kábelt, és működött - még a PPPoE account is ugyanaz maradt.

az tiszta. csak az a kérdés, hogy ez a végberendezés neked bridge vagy router?
Azaz a saját eszközöd loginol-e PPPoE-val vagy a fenti?

Persze hogy bridge. Én terminálom a saját eszközömmel a PPPoE-t.

Nekem is ez van. Egyszer végignéztem a beállításait kíváncsiságból. Layer 2-es módban vannak a portjai beállítva, a Layer 3 opcionális.
Ja még annyi, hogy ennek 100 Mbites-ek a portjai.

--
robyboy

Hogy kell rajta belépni? http://192.168.100.1/ -re bejön az admin felülete, de semmilyen általam ismert, Telekom által szokásos user/pass párossal nem enged be. (admin/admin, 3play/3play, root/Bridge, admin/üres, üres/üres, stb...)

Ha leírom, megváltoztatja a szolgáltató? Mondjuk, ha a LAN-on letiltom a Telnet-et, akkor nem ;)

--
robyboy

Hátakkó' küldd privátban :)

Valami Sagemcom. Talán 3686AC!? A Sagemcom az biztos... :P

Az ed3 eszköz. Amúgy eddig hg850a, hg8245(fekete?) és hg8245h-t(fehér) láttam. Egyszer viszont egy genexsis-t.

Nem attol "varom" az osszeomlast, hogy bekapcsoljak esetleg az IPv6-ot. A problemat az jelenthetne, ha ehhez uj firmware kell pl, gyari beallitasokkal.

Én RouterOS-en próbáltam összehozni, elvileg csak a PPPoE interfacen kell indítani egy dhcp6 klienst ugye?
Nekem sajna nem ad IP-t. Üzleti GPON-ról lenne szó.

Valakinek összejött már így?

A linkre kell kapnod IPV6CP-vel egy /64-es prefixet, és ha van belső hálód a túloldalon, annak DHCPv6 IA_PD-vel tudsz kérni további prefixet.

Ha már a PPPoE linkre sem kapsz IPv6-ot, akkor még nincs nálad bekapcsolva. (Nálam sincs még, én is GPON végponton vagyok.)

Köszi, ezek szerint akkor kb. jól akartam és meg nincs aktiválva.

Csak egy keresztkérdés a nagynéphez.

Android telefonoknál tapasztaltam ipv6 beállítás után, hogy ipv6 és ipv4 címet is kap a droid (ami nem baj), viszont ipv6 óta nagyon sűrűn "kis felkijáltójeles ikonná" alakul a WIFI jel. Ami gyakorlatban annyit takar, hogy azt érzékeli, hogy nincs internet kapcsolat.

Ezek amúgy Android 5.0.X -ek. kettő Sony teló + egy LG.

Ami érdekes, hogy az én Xiaomi mi4c -m (szintén android, bár ez 5.1) nem csinál ilyet.

A laptopok sem csinálnak ilyet + a fix gépek sem.

Ötlet esetleg? Arra tippelek, hogy valahogy valahol a 3 telefon "eltéved v6 és v4 között" valahogy és úgy érzékeli mintha nem lenne net.

Amint átállok routerileg csak ipv4 -re, akkor megszűnik minden gond.

Előre is kösz :)

Üdv
-krix-

Ez akkor Telekomnál? Milyen router? Routeren DHCP megy IPv6-on is? Android régóta nem hajlandó DHCPv6-ot támogatni, az lehet probléma? Mondjuk nincs is rá szükség, én kikapcsoltam a címkiosztást.

Bár ha a Xiaomi működik, akkor más lehet a baj. Talán az 5.0 szar?

OpenWRT van 15.05.1 verzió van. Mint fentebbi hozzászólásokban látszik, hogy hogyan kapja meg a v6ot.

router dhcpv6 osztotta ki a címeket mindenkinek. normál gépen kaptam egy ideiglenes címet, ami a belső cím + egy rendes telekom által publikált címet is.

+ ezt megkapták a droidok is.

5.0 - 5.1 között csak nincs annyi különbség hogy ilyen gondok előjöjjenek.

Bár passz. Mind1 is, visszaraktam v4re, majd később WIFI fele tiltom az ipv6 dhcpt azt jóvan.

rákérdeztem - az IPv6 csak magánelőfizetők részére érhető el, közületek még nem kérhetik.
Van valakinek ezzel ellenkező infója?

Hogy-hogynem, most latom hogy a tamogatott eszkozok listajarol lekerult a Sagemcom HGW. Ami szomoru, mert az enyemet nemreg erre csereltek le.

Na ez vajon typo vagy ennyi volt? :)

Na valaszolok magamnak, most beszeltem az ugyfelszolgalattal, nem tudni miert nem latom most mar az eszkozok listajan, de tamogatott.

Nalam is Sagemcom van. :(

Csak kivancsisagbol, van itt olyan, akinek ilyen eszkoze van, es mar el rajta a szolgaltatas?

Egy dolgot nem értek: az iPhone-omnak miért van 3 IPv6 címe? 2 rendben lévőnek tűnik: 1 link local és egy globális. De minek a 3-ik (ránézésre az is globális)?
--
http://naszta.hu

tippre: ideiglenes cím. Hogy ne lehessen a készüléket egyértelműen azonosítani.

Fedora 24, Thinkpad x220

Igen, egy ideiglenes, egy állandó. Szinte minden nagyobb platformon így van.

Úgy néz ki a T-Home bekapcsolta nálam is a dual-stack módot. Ha a Cisco EPC3925 kábel modem WIFI-jére csatlakozok tudok is kapcsolódni IPv6 hálózatokhoz.

Viszont van egy TP-Link router-em OpenWrt 15.05.1-el, amit próbáltam beállítani, hogy rajta keresztül is menjen, de nem sikerült. Állítólag csak akkor működne, ha a kábel modem bridge módba lenne állítva. Most router módban van és a T nem engedi átállítani. Az ügyfélszolgálat azt mondja, hogy letiltották, mivel bridge módban nem működne az IPTV.

Sikerült már valakinek ilyet beállítani?

Akkor sem kapcsolják át, ha az usernek nincs iptv előfizetése? vagy akkor igen?

Nem tudom, de sok jóra nem számítanék tőlük.
Felajánlották, hogy 8500 Ft kiszállás + 5000 Ft/óra díjért kiküldenek egy szakit, aki megpróbálja beállítani a routert. Ha nem sikerül neki se, akkor nem kell fizetnem. Ez volt a nagyvonalú ajánlatuk.

Ez egész baráti óradíj már nemazért.

De az átkacsoláshoz nem kell kiszállnia senkinek, azt központból át lehet kacsolni.

Anno nekem egy szerelő elmesélte, hogy ő, a központból mindet lát a kapott modemen, az összes rákötött számítógépet, nyomtatót, iptv-boxot, a wifire csatlakozó, és egyéb eszközt, a mac-címek szintjén.

Pont azért, mert ha az átlagfelhasználó, (a nem tipikusan hup olvasó...) betelefonál, hogy "nem megy a wifi, vagy ez nem látja azt, nem megy a nyomtató, stb." problémákkal, akkor ők ezt, az ügyfélhez való kiszállás nélkül is meg tudják oldani.

Mondjuk ebben semmi meglepö sincs. Most is szól a fejem mellett több rádióadás, csak egy antenna kell ahhoz kb. hogy halljam.
Ahol meg átfolyik az adat, ott figyelhetö, lopható, menthetö, eladható, és a többi.
Akik hisznek a biztonságos hálózatokban, azok naívak.

De ha pl. mondjuk letiltod a Telnet-et, SSH-t a szolgáltató cuccában, akkor... jó pénzért kiszállnak, hogy visszaállítsák ;)

--
robyboy

„De ha pl. mondjuk letiltod a Telnet-et, SSH-t a szolgáltató cuccában, akkor... jó pénzért kiszállnak, hogy visszaállítsák ;)”

Nálam a szolgáltató cuccában semmilyen WAN oldali beállítás nem lehetséges. Tehát nem tudok olyat beállítani, hogy ők távolról ne tudják menedzselni a gateway-t. Van olyan szolgáltató (Magyarországon) aki megengedi a WAN oldal konfigurálását az általa adott, és kötelezően használandó eszközön?

igen, Telekom.
a Telekom által adott ONT-n sokkal több dolog konfigurálható, mint a Digi által biztosított eszközön.
A telekomnak ellenben olyan provision rendszere van ehhez, hogy a kolléga amikor telepít, az ONT-t a mobiljáról programozza provision-ön keresztül, nem LAN ról...
felteszem, ha valamit elba**ol rajta, távolról felküldik újra az alap provision konfigot és kész...

Ez a telnet/ssh letiltás nettó hülyeség!
Ők a központól nem telneten, vagy ssh-n mennek be, hanem erre külön port van nyitva, amit az user nem tud letiltani.
Amikor távolról állítják, akkor nem egy terminálból teszik, hanem egy GUI-s programmal, illetve webes felületen.
Pl: egyszer nézz rá portcsannal, egy iptv boxra, van egy nyitott TCP port (10000, vagy 8000 környékén), ami erre való.
A DOCSYS-os és a GPON-os szabványok támogatják a HGW-re való távoli firmware feltöltést, nem csak a konfig feltöltését.

pont ezt magyarázom én is...

Próbáltad a saját routert bridge módban használni, ha az övéket nem lehet?

Egyrészt nem is tudom hogyan lehet OpenWrt-nek ezt megmondani, másrészt meg olyan dolgokat rontana el, amik eddig működtek, például OpenVPN.

Mi értelme?
Ha nem kell a saját router, akkor sokkal egyszerűbb kikötni a hálózatból, és még villanyt sem fogyaszt.

A Telekom oldalán ezt írják: "A HGW 1db /56 IPv6 prefixet is kap, melyből az első /64 prefix a LAN oldalon kerül felhasználásra. A /56 prefix többi részét az ügyfeleink által telepített plusz routerek használhatják (kérhetik DHCP-vel) prefix delegálás keretében további interfészeik IP címmel ellátására"
Ezek szerint a routerednek DHCP-vel kellene ebből a tartományból címet kérni.
Vagy van egy IP Pass-through opció is az Applications & Gaming menüben, ez nem használható?

--
Soli Deo Gloria

Köszi az infót. Most már értem minek kéne történnie. Látszólag az OpenWrt jól teszi a dolgát, mert a router /64-es címet kapott (2001:4c4c:14dc:8c00::), amíg a router-re kapcsolódó eszközöknek /54-eset osztott ki (2001:4c4c:14dc:8c80::). Viszont nem jön válasz a kábel modem felől, olyan mintha blokkolná a 8c80-as címeket. IPv6 tűzfal ki van kapcsolva a kábelmodemben.

Nálam egy Cisco EPC3925 eszközt szereltek be, ennél nincs IP Pass-through opció. Mióta dual stack módba kapcsolták, annyit vettem észre, hogy megjelent egy Lan IPv6 setup menü. Más állítási lehetőség nincs.

Na puding próbája: Zalaegerszeg, T-Com hálózata, lakossági előfizetés, ADSL.

Device Type: Speedport Entry 2i
Hardware Version: V1.0.1
Software Version: V1.0.0_HU_T2P3

IPv6 Connection Status: Connecting
IPv6 Online Duration: 0 h 0 min 0 s

A DHCPv6 be van pipálva a T által kihelyezett eszközön. Egyelőre NINCS ipv6 rajta, csak a 84.1.x.x -ből IPv4.
... bár a hirdetésükben említett 2016 végéig végülis még van 5 napjuk.

Nálam sincs még rajta IPv6. (GPON)

> ... bár a hirdetésükben említett 2016 végéig végülis még van 5 napjuk.

Én egy reverse DNS delegációra várok náluk másfél hónapja. Szerintem örüljünk, ha 5 éven belül összejön nekik.

Sziasztok,

Előre leszögezem, hogy nem értek az IPv6-hoz, de lenne pár kérdésem.
A Telekom nálunk is bevezette az IPv6 dual stack megoldását. Cisco EPC3925 HGW-nk van, s hiába kapcsolom ki a LAN IPv6 menüben, az Android-os mobil eszközeim ugyanúgy kapnak IPv6-os címet is. Ami elsősorban azért gáz, mert a Telekom IPv6-os DND szervereivel borzasztó lassú a névfeloldás. Hogyan lehet átírni a DNS szervert nem routeolt eszköz esetében, vagy csak szimplán kikapcsolni az IPv6-ot? Routeolni nem tudom, ugyanis céges eszköz.
Egyébként, hogy működik dual stack esetében a priorizálás? Mi dönti el, hogy IPv6-os vagy IPv4-es címzést használ?

> Routeolni nem tudom, ugyanis céges eszköz.

Akartad mondani, rootolni, mert vagy ötször elolvastam, mire leesett, hogy mit kérdezel.

> Egyébként, hogy működik dual stack esetében a priorizálás? Mi dönti el, hogy IPv6-os vagy IPv4-es címzést használ?

Ha van (rendes) IPv6 címed, akkor az a preferált az IPv4 fölött.

upsz :D igen, szóval rootolni

Az IPv6-ot az alkalmazásnak támogatnia kell, rajta múlik hogy hogyan használ IPv6-ot. A megszokott eljárás az, hogy ha egy domain névhez tartozik AAAA rekord, akkor arra IPv6-tal megpróbálunk csatlakozni, és időtúllépés esetén visszaváltunk IPv4-re (ha van).

Biztos hogy az IPv6-os névfeloldással van gondod? Azzal nem szokott probléma lenni. Nem lehet hogy az IPv6-os kapcsolatoddal van probléma, és ezért várnod kell amíg az alkalmazás feladja az IPv6-ot, és IPv4-en próbálkozik helyette?

Próbáld inkább kideríteni hogy mi a baj a v6-tal, ne kikapcsolással kezd. Másold be a http://test-ipv6.hu http://test-ipv6.com tesztek eredményeit, valószínűleg segíteni fog.

Az Androidos eszközök egyébként nem támogatják a DHCPv6-ot*, úgyhogy RA-ból veszik a címet SLAAC-vel. Ezt az Androidos eszközön a WiFi hálózat beállításai között letilthatod ha muszáj.

A fenti tesztoldalak szerint minden rendben, viszont azt vettem észre, hogy a DNS szerverek (2001:4c48:1::1 és 2001:4c48:2::1) pl. laptopról pingenek, meg feloldás is működik , viszont egyik Androidos cuccról sem megy a ping sem. Szóval gondolom az a helyzet, amit írtál, hogy timeout-ol IPv6-on és utána próbálkozik IPv4-gyel. Csak nem tudom mit lehetne tenni, meg hogy hol a hiba.

IPv4-es névszervereket nem oszt a router? DHCPv6 hiányában az androidok csak RFC6106-al tudnak IPv6-os névszerver beállítást átvenni. (RA DNS extensions) Igazából normális DHCPv6 hiányában fixen IPv4-en szokott menni a DNS lekérdezés, még akkor is ha működő IPv6 van a hálózatban.

Olyan eszközről nyisd meg a tesztoldalt, amin a hibát tapasztalod, működnek mobilról is. (Másold be légyszi a kimenetet, ha minden rendbent ír akkor is van benne diagnosztikai infó bőven.)

getprop net.dsn1 2001:4c48:2::1
getprop net.dsn2 2001:4c48:1::1
getprop net.dns3 8.8.8.8

A tesztoldal (Android 6.0.1) :

Tesztelés IPv4 DNS rekorddal
rendben (0.214s) kapcsolat: ipv4
Tesztelés IPv6 DNS rekorddal
rendben (0.232s) kapcsolat: ipv6
Tesztelés Dual Stack DNS rekorddal
rendben (0.230s) kapcsolat: ipv6
Dual Stack DNS és nagy csomag tesztelése
rendben (0.229s) kapcsolat: ipv6
IPv4 teszt DNS nélkül
rendben (0.223s) kapcsolat: ipv4
IPv6 teszt DNS nélkül
rendben (0.229s) kapcsolat: ipv6
Nagy IPv6 csomag tesztelése
rendben (0.248s) kapcsolat: ipv6
Az internetszolgáltató IPv6 DNS tesztje
rendben (0.226s) kapcsolat: ipv6
Find IPv4 Service Provider
rendben (0.156s) kapcsolat: ipv4 ASN 5483
Find IPv6 Service Provider
rendben (0.181s) kapcsolat: ipv6 ASN 5483

Viszont az http://ipv6-test.com/ oldalon a droidok az alábbiakra unreachable-t mondanak:

DNS6 + IP4 Unreachable
DNS6 + IP6 Unreachable

Ubuntu-n Reachable. Ezen az oldalon nincs details szóval egyebet nem mond.

Úgy tűnik hogy a routered beállít IPv6-on elérhető DNS szervereket, de utána ezek mégsem működnek. Így az operációs rendszered minden egyes DNS lekérdezésnél megvárja amíg a v6 sikertelen.

Próbáld a routereden a névszervereket átállítani, és kivenni közülük az IPv6 címmel rendelkezőket.

Sajnos a Telekomos Cisco EPC3925 HGW-n nincs ilyen opció. Futok majd egy kört a szolgáltatónál, de szerintem így jártam, veszett fejsze nyele. Köszi a segítséget.

Utolsó megoldásként az androidos eszközeiden, A WiFi hálózat beállításai között le tudod tilatni a spec beállítások között az IPv6-ot.

Nincs ilyen opció. Több helyen is azt írják, hogy root kell hozzá :(

Nem tűnik szolgáltatói hibának, ha az Ubuntu működik faszán. Ping se megy a szerverekre Androidról? Traceroute mit mond, meddig jut el?

Nekem van olyan érzésem, hogy az android ipv6 kezelésével lesz gond. Sajna nálam is előjöttek anomáliák.

Fedora 25, Thinkpad x220

Úgy tűnik, másnál is van ilyen: http://www.hwsw.hu/hirek/56684/telekom-ipv6-ip-android-wifi.html
Én nem tapasztalok problémát, itt is Cisco HGW van és két Androidos telefon (5.1.1 és 7.1.1 verziók)

"Frissítve: “Adatközponti konfigurációs hiba” okozta a hibát a Telekom hozzánk eljuttatott álláspontja szerint. “Ezt a hibát a mai nap során a Magyar Telekom szakemberei elhárították” - mondja a vállalat, a hálózat a cég szerint az eszközök újraindítása nélkül újra rendeltetésszerűen működik. A cég elismerte, hogy a problémát az IPv6-os DNS-feloldás okozta, azt nem tudni, hogy pontosan mekkora felhasználói bázist érintett."

--
Soli Deo Gloria

Igen, már nálam is működik.

Jelenleg a Cisco EPC3925-ön teljesen ki van kapcsolva az IPv6, viszont a mobil hálózaton már kap az iPhone-om is címet. (Mondjuk azt, hogy miért nem carrier NAT van, azt nem értem, 10.xxx.xxx.xxx a címem.)

Van akinek működik kábelen az IPv6?
--
http://naszta.hu

Nem 100.64./10 lesz az? De még ha 10./8 is, attól még az CGNAT.

Nem. 10./8 a címem. Ami itthon még ok, de a cég is ezt használja...
--
http://naszta.hu

Hello,
A 10/8, az a HGW belső oldalán van, azaz a HGW NAT-ol neked...;
Ennek by the way az az oka, hogy a DOCSIS forgalom elég combos, a CGNAT meg elég drága..., szval nem nagyon éri meg az ED3-at NAT-olgatni;
Van kis gond ezeknek a Modemeknél a ipv6 támogatással, ezért javításig ki van kapcsolva, ha javítódik, akkor lesz megint ipv6.

Nem fogalmaztam tisztán: a mobil neten kapok 10/8-at, ami gáz, ha a cégben is 10/8 van. Ott elvárnám a carrier grade NAT-ot.

A DOCSIS-on sima IPv4 címem van, publikus és csak a router NAT-ol (192.168.0/24). IPv6 kábelen nincs.
--
http://naszta.hu

Szia,

igen, furcsáltam is a 10/8-at a DOCSIS mögött :)
A Mobile-ban van CGN, azaz megkapod a Cellular interface-re a 10/8-at, majd ott az internet és a VRF között ott van a CGN, mert máshogyan nem nagyon működhetne a világ felé...

De miért zavar, ha 10.x.y.z/32-t kapsz a PDP session-ödre?
Valami spéci "split-tunnel" VPN van a cégben, ami ennek ellenére, hogy /32-t kap a mobile-od, beállít valami nagyobb prefixet "helyinek"?

Most akkor képzeld el, hogy a DNS server az 10.1.1.1 a céges hálózaton. A telefon keresi: melyik interface-hez menjen? Mindkettőn lehet ez az IP. Vagy más az átjáró címe a céges és mobil szolgáltató által adott neten. Hova menjen a telefon alapesetben? Stb. Pontosan ezért van a carrier grade NAT, saját lefoglalt IP blokkal (100.64.0.0/10). Egyébként néha a T is ezt ad. Pl. most ilyen címem van: 100.113.109.23.
--
http://naszta.hu

Hello,
Hát az IP routing egész jó megoldást erre a problémára...:)
Van egy PDP interface-ed, ott van egy /32-...lehet az bármilyen cím...10/8 vagy 100/10, mind1..., a lényeg, hogy a routing hogy áll.
Ha pl oda mutat - Celluar felé- egy default route...mondjuk a VPN tunneled irányába meg egy specifikus RFC1918, akkor
ez elvileg nem okozhat gondot...
a routing táblát nézted már, amikor ilyen gondod van ?

Nem akarok találgatni, mert ezer dolog lehet, de indulj a routing tábla irányából a problémának...
A 10/8 még marad egy darabig a CGN előtt...sorry :( mindamellett a 100/10 is használva van, GW függő...hogy milyen pool-ból kapcsz címet...;