routeros ipv6 vodafone

IPv6

Sziasztok!

A vodafone itt járt pénteken, és beszereltek hozzám egy új eszközt. A régi ipv4 cím helyett IPv6-ot kaptam, és mellé CGNAT-ot. Alapvető problémám ezzel az új eszközzel, hogy 10-ből egyszer (de időnként 10-ből 10-szer) "no route to host" ICMP csomagok jönnek vissza, amikor a gépem TCP kapcsolatot akar kialakítani. Namost próbáltam náluk elérni, hogy visszaadják a "rendes" publikus IPv4 címemet, de sajnos az elmúlt 5-6 napban még nem sikerült feldolgozniuk "a készülék aktiválását". Nem tudom hogy ez pontosan mit jelent, de minden nap hívom őket, és minden nap azt a választ kapom, hogy "még nem dolgoztuk föl a készülék aktiválását". Most már nagyon elegem van ebből az egészből, de a sajánálkozáson kívül nem tudok túl sok dolgot tenni... Megvan a véleményem a Vodafone-ról, de ezen szerintem senki nem tud segíteni, szóval ezt hagyjuk.

A lényeg, hogy amíg nem kapom vissza a publikus IPv4 címemet, addig szeretnék beállítani IPv6 -ot. A router-be be tudok jelentkezni, és ott azt írja, hogy /57 -et kaptam. Viszont sehogy nem sikerül hozzá beállítani a DHCP klienst.

Így van beállítva:

 

/ipv6 dhcp-client
add add-default-route=yes interface=ether5-wan pool-name=voda-pool6 pool-prefix-length=57 request=prefix use-peer-dns=no
 

és ezt látom:

[gandalf@router.lacinet] /ipv6/dhcp-client> print 
Columns: INTERFACE, STATUS, REQUEST
# INTERFACE   STATUS        REQUEST
0 ether5-wan  searching...  prefix 
 

Próbáltam pool-prefix-length megadása nélkül is, de úgy is ugyan ez az eredmény. Ugyan ezen az interface-en az IPv4 DHCP kliens szépen kap címet. RouterOS verzió 7.6

Még soha nem csináltam ilyet, tehát valamit biztosan elrontottam.

Mit csinálok rosszul?

  • 2403 megtekintés

( sibike | 2022. 11. 02., sze – 18:04 )

Milyen router-t kaptál? Vodánál DS-Lite szokott lenni, ott te már csak egy /64-et kapsz, és nincs is prefix delegation.

Bizony...

A DS-Lite technikailag ugye annyit tesz, hogy a hálózaton IPv6 van csak natívan, az IPv4-et egy IPv6-ba enkapszulált tunnelben kapod. (Vigyázz, ha konfigurálod - nem lesz rajta meg az 1500-as MTU!) Technikailag lehetne ehhez publikus IPv4 cím is, meg akármekkora IPv6 prefix is, az már a UPC/Vodafone saját döntése volt, hogy valamiért nem ad az IPv4 tunnelre opcionálisan sem publikus IPv4 címet. Az pedig teljesen érthetetlen, hogy az IPv6-hoz miért nem ad legalább még egy /64-et, de inkább egy /56-ot... :(

( mauzi v | 2022. 11. 02., sze – 18:15 )

Szerkesztve: 2022. 11. 02., sze – 18:16

"no route to host" ICMP csomagok jönnek vissza, amikor a gépem TCP kapcsolatot akar kialakítani.

Tökéletesen biztos vagy Te abban, hogy valóban "no route to host" ICMP jön vissza, nem pedig path MTU discovery bajod van, mert megszűrted az ICMP-t? A DS-Lite tunnelben adja az IPv4-et, ahhoz pedig kisebb MTU jár. A probléma nem szűnik meg akkor, ha beállítasz mss clampingot?

( nagylzs v | 2022. 11. 02., sze – 18:18 )

Mekkora MSS Clamping-et állítsak be? Van rá tipped?

Egyébként meg tényleg kapják be! :-)

( nagylzs v | 2022. 11. 02., sze – 18:21 )

Most megnéztem a tűzfal szabályaimat, és úgy látom hogy az ICMP -re valóban nem volt forward chain-ben semmi, csak az input-ban.

Ettől függetlenül, mennyi az annyi?

Lehet hogy majd csinálok egy kis packet sniffing-et, és megnézem hogy honnan származik ez a "no route to host" üzenet.

Na de koncentráljunk az eredeti kérdésre: miért nem kapok IPv6 cím prefixet DHCP klienssel? (És igen DS-LITE van, és külön AFTR címem van, szóval ez nem igazán kapcsolódik az eredeti kérdéshez)

Nem követem a UPC/Vodafone aktuális munkásságát, de korábban egyetlen /64-et adtak, amit praktikusan nem tudsz továbbosztani további subnetekre. Ha saját routered van, akkor az a /64 felcsücsül a WAN oldaladra, a LAN oldaladra pedig nem jut global scope-os prefix. Ez van...

Ha véletlenül lenne azóta ebben változás, szóljatok, mert engem is érdekel.

BTW, ha esetleg van itt a fórumon valami Vodafone-os emberke, tökre kiváncsi lennék rá, miafacér' nem adnak legalább két /64-et.

Köszi, akkor megfejeltem még 40-nel

add action=change-mss chain=forward ipsec-policy=in,none new-mss=1360 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1360
add action=change-mss chain=forward ipsec-policy=out,none new-mss=1360 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1360
 

és most tesztelem. :-)

Nos, ez nem nyert.

https://imgur.com/a/4FPWTt0

Chrome szerint "ADDRESS UNREACHABLE", és ezt random módon csinálja. De ha TCP kapcsolatot nézek, akkor "no route to host"-ok jönnek vissza. Bekapcsolt TCP clamp mellett, MTU=1360, mindenfelé engedélyezett ICMP forward stb.

Ja és ezt a hozzászólást is már vagy 10-szer próbáltam meg beküldeni. Ki kell másolnom vágólapra, mert néha 11-edikre megy be.

Tipp: a routered hirdeti magát router advertisementtel befelé default routernek, a webböngésződ feloldja az AAAA rekordot és IPv6-on próbál csatlakozni, de global prefix hiányában nem tud eljutni a célig. Megoldás: ne hirdess befelé default route-ot, amíg nincs IPv6 prefixed. (UPC-nél nem is lesz a belső hálódra, lásd feljebb.)

Erősen fusi workaround, ha mindenáron IPv6-on akarsz menni a külvilágba úgy, hogy a LAN szegmensedhez nincs global IPv6 prefixed: használj unique local prefixet a belső hálóra, és mellé IPv6 prefix translationt (IPv6 NAT) (RouterOS 7 kell hozzá)

A kliens gépemen csak link local IPv6 címem van.

 

╰─$ netstat --protocol=inet6 -nr
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::/0                           ::                         !n   -1  1     0 lo
::1/128                        ::                         U    256 1     0 lo
fe80::/64                      ::                         U    256 1     0 vethb913a40
fe80::/64                      ::                         U    256 1     0 docker_gwbridge
fe80::/64                      ::                         U    1024 1     0 wlp1s0
::/0                           ::                         !n   -1  1     0 lo
::1/128                        ::                         Un   0   8     0 lo
fe80::42:3aff:fee0:4599/128    ::                         Un   0   3     0 docker_gwbridge
fe80::54fa:8dff:feea:6445/128  ::                         Un   0   2     0 vethb913a40
fe80::e0f9:c078:a05:1ec8/128   ::                         Un   0   3     0 wlp1s0
ff00::/8                       ::                         U    256 10     0 wlp1s0
ff00::/8                       ::                         U    256 9     0 vethb913a40
ff00::/8                       ::                         U    256 9     0 docker_gwbridge
::/0                           ::                         !n   -1  1     0 lo
 

/tool sniffer
set filter-ip-address=192.168.14.106/32 filter-ip-protocol=udp filter-port=dns
start

 

kliensen:

$ ip a | grep inet | grep 192
    inet 192.168.14.106/24 brd 192.168.14.255 scope global dynamic noprefixroute wlp1s0
$ telnet hup.hu 80                                                                                                                                                    1 ↵
Trying 92.119.122.43...
Trying 2a01:6ee0:1:201::bad:c0de...
telnet: Unable to connect to remote host: Network is unreachable

router-en:

[gandalf@router.lacinet] /tool/sniffer> packet/
[gandalf@router.lacinet] /tool/sniffer/packet> print 

[gandalf@router.lacinet] /tool/sniffer/packet>

Ezt mégis mire véljem?

Még érdekesebb, hogy a traceroute egyszer sem jelez semmiféle hibát, miközben ugyanúgy nem lehet kapcsolódni:

╭─gandalf@laci-vivobook-linux.lacinet oktaport-dev ~  
╰─$ traceroute hup.hu
traceroute to hup.hu (92.119.122.43), 30 hops max, 60 byte packets
 1  192.168.14.254 (192.168.14.254)  4.599 ms  4.530 ms  4.497 ms
 2  192.168.0.1 (192.168.0.1)  4.461 ms  4.668 ms  4.638 ms
 3  * * *
 4  * * *
 5  catv-89-133-4-5.catv.fixed.vodafone.hu (89.133.4.5)  26.639 ms  24.942 ms  27.090 ms
 6  bix.CR0.VH.BUD.rackforest.net (193.188.137.46)  28.027 ms  16.171 ms  23.416 ms
 7  hup.rackforest.hu (92.119.122.43)  21.585 ms *  23.260 ms
╭─gandalf@laci-vivobook-linux.lacinet oktaport-dev ~  
╰─$ telnet hup.hu 80
Trying 92.119.122.43...
Trying 2a01:6ee0:1:201::bad:c0de...
telnet: Unable to connect to remote host: Network is unreachable
╭─gandalf@laci-vivobook-linux.lacinet oktaport-dev ~  
╰─$

Akárhányszor próbáltam, a traceroute mindig jól ment, a TCP kapcsolódás meg minimum 50%-ban hibát dob.

Namost, ha TCP SYN alapú traceroute-t próbálok, akkor meg

─$ sudo traceroute -T hup.hu 80
traceroute to hup.hu (92.119.122.43), 30 hops max, 60 byte packets
 1  192.168.14.254 (192.168.14.254)  4.948 ms  4.877 ms  4.848 ms
 2  192.168.0.1 (192.168.0.1)  5.354 ms  5.328 ms  5.299 ms
 3  192.0.0.1 (192.0.0.1)  16.593 ms !X  26.429 ms !X  25.663 ms !X

És ez "icmp-host-prohibited"-nek felel meg.

Kezdek arra gyanakodni, hogy valami aktív csomagszűrés folyik itt. Lehetséges lenne, hogy az itthon futó syncthing-em nem tetszik neki, amihez egyszerre vagy 20 peer csatlakozik?

Kikapcsoltam a syncthing-emet és megszűnt a probléma.

Nem az MTU-val volt a baj, és nem is azzal, hogy IPv6 router-ként hirdetet magát a router-em.

Úgy tűnik, hogy gyanúsnak találták az internet forgalmamat, és büntibe kerültem.

Akkor most már csak az a kérdés, hogy emiatt hol tudok reklamálni. (Sehol?)

Illetve hogy ezek után hová fogom tenni a syncthing -emet, amin 6TB-nyi backup adat van. (Tudom, béreljek rá szervert, de nincs "kedvem" 6TB-nyi tárhelyet bérelni...)

Ha a conntrack tábla volt kicsi, akkor ez még gyászosabb képet fest a vodafone-ról. :-(

1. Nem megy az IPv6 PD
2. Nincs rendes dual stack, pedig már 2015-ben (7 éve!) arról fórumoztunk, hogy már el vannak vele késve. 
3. Helyette van egy olyan DS-Lite, aminél 30 aktív TCP kapcsolattal már nem megy a IPv4 CGNAT
 

Már évek óta menekülnél tőlük, de sajnos ahol én lakom, ott nincs választási lehetőség.

A Telekomnak van optikai net a szomszéd utcában (kb. 200 méterre), több éve. De ide nem húzzák át, ki tudja miért.

Hát azzal indítottam ezt a topic-ot, hogy ezt a szart NEM LEHET visszarakni legacy IPv4-re. Azért nem, mert nincs ilyen menüpont rajta. Telefonon lehetne kérni a Vodától elvileg, de telefonon már vagy 5 napja azt a választ kapom, hogy "még nem dolgozták fel az eszköz aktiválását".

( nagylzs v | 2022. 11. 02., sze – 19:54 )

Oké szóval az ipv4 kapcsolódási problémák okára fény derült. Az eredeti topic indító kérdés továbbra is áll. Ha a Vodafone router status lapja szerint /57 prefxet delegált, akkor ezt miért nem tudom IPv6 dhcp-vel lekérni routeros 7-ben?

Én vagyok a hülye, vagy a Vodafone router hazudik?

Értem, tehát gyárilag rossz. :-D Ráadásul 100% hogy a hardware tudná ,csak nem implementálták. Azért, mert nekik az ügyfél annyira fontos. Ezt ahhoz lehet hasonlítani, mint amikor felhívom az ügyfélszolgálatot, és 40 perc várakoztatás után is azt hallgatom, hogy "hívása fontos számunkra". Ja meg azt, hogy "ügyfélszolgálatunk ÁTMENETI túlterheltsége miatt a várakozási idő több perc is lehet". Ami szintén egy ordas nagy hazugság, mivel a tapasztalat azt mutatja, hogy náluk minden nap minden időszakban átmeneti túlterhelés van, ami pont az "átmeneti" ellentéte.

Ha számukra tényleg fontosak lennének az ügyfelek, akkor vennének föl több ügyfélszolgálatost. De azt nem lehet, mert az csökkentené a profitot. Meg normális firmware-t íratnának a saját eszközükre. De azt szintén nem lehet, mert csökkentené a profitot. Akkor ezek után mégis ki hiszi azt el, hogy ügyfélközpontúak?

Persze nem vagyok benne biztos, hogy más szolgáltatónál jobb a helyzet, mert sajnos még választási lehetőségem sincs...

Na jól kihisztiztem magamat.

Mar tobb forumban is kiveseztuk a temat. Mas szolgatatoknal (Telekom, Digi) van rendes IPv6, csak Vodae ilyen bena.

Ha valojaban nincs szukseged IPv6-ra, akkor vard meg mig processzaljak a keszulek aktivalasat, es telefonos ugyfelszolgalatost kerd meg hogy kapcsolja at IPv4 only-ra publikus IP-vel.

https://imgur.com/a/BlHuFrq

Amit belinkeltél képet, annak alapján a következő van:
1db ipv6 címre  routolnak 1db /57 ipv6 subnetet

Te a /57 ipv6 subnetet tudod használni, ahol a GW cím pedig az 1db ipv6 cím (Vodafone router külső lába).

Ebben a felállásban, miként akarod használni a Mikrotik eszközt?

( nagylzs v | 2022. 11. 04., p – 21:21 )

Szerkesztve: 2022. 11. 04., p – 21:24

Na egy hét utáns sikerült elérni, hogy saját publikus ipv4 címet adjanak. Ezután jött a meglepi:

 

* nincs dmz

* port forward csak upd vagy tcp lehet, semmi ESP ipsec meg hasonló

Ez nem szolgáltatás, ez egy sz@¢¥√¥π£÷r.

Nincs rajta ilyen funkció. Átnéztem az összes menüpontot. Az admin felülete az előző fehér connectbox -hoz képes nagyon gagyi, alig lehet rajta valamit állítani. A modell száma TG3442DE. Sötét álló doboz, az alján van egy fémhenger (dísz).

Amúgy bazi nagy méretű, az előző modem helyére nem fért be, és olyan helyre keleltt tennem, ahol nem szép...

Ahhoz képest hogy milyen nagy, nagyon keveset tud. 

Azt se teljesen tartom korrekt dolognak, hogy 500Mbps -ről 1Gbps-re upgrade-elek, és kihoznak egy olyan eszközt, ami nem ismeri az AX módot, és AC módban (saját méréseim tanulsága szerint) 200-300Mbps-t tud (ugyan abban az időszakban mértem, amikor vezetéken 630 Mbps-t.)

Természetesen a szerződésben meghatározott sebességeket se hozza ("rendes körülmények között 700Mbps", de az elmúlt egy hétben nekem még sosem sikerült "rendes" körülményeket teremteni...)

Én is sokat küzdöttem velük, az xl netes csomaggal, amikor még RB4011 -em volt.

Mind Bridge módban, mint router módban billegett a wan oldal, firmwaret kellett volna frissítenie a vodafone-nak, de erre nem voltak hajlandóak, mert ezen az "elosztó-állomáson" amin én is vagyok, csak ~ 10 ember kérte ezt a meglévő 100+-ból, így gazdaságilag nem lett volna hatékony szerintük. Most egy Asus AX3000V2 van a modem után, azzal be tudtam állítani, hogy wan oldalról folyamatos legyen a dhcp lease, így atomstabilan működik és a sebesség is 970/45 Mbps.

Amíg nem vittem vissza az ügyfélszolgálatra a régi eszközt, addig nekem sem voltak hajlandóak lezárni az ügymenetet.

Asus configban van olyan opcio, ahol wan oldalról be lehet állítani, hogy a dhcp lekérdezési frekcencia normál, agresszív, vagy folyamatos legyen. A folyamatos kivételével mindegyik módban random lecsatlakozott a wan oldali interface, és valamikor percekig nem csatlakozott vissza, csak ha kézileg reconnectre kattintottam.

( mr shadow v | 2022. 12. 30., p – 16:14 )

Szerkesztve: 2022. 12. 30., p – 16:14

Egy kérdés a topiknyitóhoz illetve mindenki máshoz aki meg tudná válaszolni: az Arris Touchstone TG3442DE esetén (mivel ez puma 7 chipsetes), fennáll még az ismert hiba túl sok tcp kapcsolat(és még egyéb más) közben? Nekem Compal CH7465LG alatt pl a tunnelbroker.net 10 megabitnél nem tud többet, és gyanítom hogy ez összefügg az intel puma 6 hibájával ami a 7esben is jelen lehet.. 

--
>'The time has come,' the Walrus said<