Mikrotik hAPac2 Digi (ONE) ipv6 nem megy

IPv6

A tárgyban szereplő konfiggal gyűlt meg a bajom. Amíg Digi volt működött, de most nem kapok ipv6 címet. Az ONT modem módban van, a Mikrotik szépen létrehozza a pppoe kapcsolatot, ipv4 cím (ráadásul publikus, mert kivettek a CGNat mögül) van. Ám valamiért ipv6 címet nem kapok. Illetve kapok, mert ha direktben rádugom a laptopra és betárcsázok, akkor minden rendben van. (Legalábbis Linux alatt, mert  a windows-os gép Error 720 hibával nem működött, de ez most irreleváns.) Szóval biztosan én rontok el valamit a konfigban. Segítsetek kérlek, hogy hol hibáztam!

Megpróbálom a releváns infókat megadni, ha valami még kell természetesen azt is megadom.

 ipv6/route/ print 
Flags: D - DYNAMIC; A - ACTIVE; c, d, v, y - COPY; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
     DST-ADDRESS              GATEWAY                               DISTANCE
DAd+ ::/0                     fe80::e5f3:ee76:d95a:3dfc%pppoe-digi         1
DAd+ ::/0                     fe80::e5f3:ee76:d95a:3dfc%pppoe-digi         1
DAv+ ::/0                     pppoe-digi                                   1
DAc  2a01:36c:1400:2af7::/64  pppoe-digi                                   0
DAc  2a01:36d:1400:2af7::/64  bridge1                                      0
D d  2a01:36d:1400:2af7::/64                                               1
DAc  fe80::%ether1/64         ether1                                       0
DAc  fe80::%bridge1/64        bridge1                                      0
DAc  fe80::%pppoe-digi/64     pppoe-digi                                   0

Szerintem valahol a pool környékén, vagy a prefixeknél lehet a hiba.

[zslaszlo@MikroTik] > ipv6/dhcp-client/print 
Columns: INTERFACE, STATUS, REQUEST, PREFIX
# INTERFACE   STATUS  REQUEST  PREFIX                              
0 pppoe-digi  bound   address  2a01:36d:1400:2af7::/64, 6d22h40m57s
                      prefix                                       
[zslaszlo@MikroTik] > ipv6/dhcp-server/print 
Flags: D - DYNAMIC
Columns: NAME, INTERFACE, ADDRESS-POOL, PREFERENCE, LEASE-TIME
#   NAME        INTERFACE   ADDRESS-POOL   PREFERENCE  LEASE-TIME
0 D pppoe-digi  pppoe-digi  2a01:36c::/32         255  3d        
[zslaszlo@MikroTik] > ipv6/pool/print 
Flags: D - DYNAMIC
Columns: NAME, PREFIX, PREFIX-LENGTH, EXPIRES-AFTER
#   NAME   PREFIX                   PREFIX-LENGTH  EXPIRES-AFTER
0 D pool6  2a01:36d:1400:2af7::/64             64  6d22h40m15s  
[zslaszlo@MikroTik] > ipv6/nd/print 
Flags: X - disabled, I - invalid; * - default 
 0 X* interface=all ra-interval=3m20s-10m ra-delay=3s mtu=unspecified 
      reachable-time=unspecified retransmit-interval=unspecified 
      ra-lifetime=30m ra-preference=medium hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=no 
      managed-address-configuration=no other-configuration=no dns="" pref64="" 

 1    interface=bridge1 ra-interval=3m20s-10m ra-delay=3s mtu=unspecified 
      reachable-time=unspecified retransmit-interval=unspecified 
      ra-lifetime=30m ra-preference=medium hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=yes 
      managed-address-configuration=no other-configuration=no dns="" pref64=""

Minden segítséget köszönök!

Ui. Mikrotik 7.8 (stable) a verziószám

  • 1076 megtekintés

( bennyh | 2025. 02. 25., k – 12:17 )

Amiket ugye meg lehet nézni:

- a router tudja-e pingelni a google v6-os DNS címeit

- a kliensek kapnak e a digi-s prefxből címeket

- kliensekről traceroute a google v6-os DNS szerverei felé mit mond

A másik, hogy a RouterOS-ben ráfeküdtek a v6-ra és érdemes lenne frissíteni, most jött ki a 7.18 is.

Egyébként gondolkodtam én is ax eszköz upgraden, de mivel a háztartásban egyetlen eszköz wifi6 képes, így feleslegesnek találtam a beruházást.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Én viszont nem használom a Wifi részét :D

Azt rábíztam openWRT alapú cuccokra. Nekem az az 1.8 GHz-re boost-olni tudó 4 magos ARM SoC-a kellett RouterOS-sel, olcsón (használtam vettem olcsóbb volt, mint az új ára, ami meg olcsóbb, mint az AX3 ugyanezzel a SoC-cal) 

- [zslaszlo@MikroTik] > ping ipv6.google.com
invalid value for argument address:
    invalid value of mac-address, mac address required
    invalid value for argument ipv6-address
    failure: dns name exists, but no appropriate record

- nem kapnak a digis prefixből címeket, hanem a saját poolból (192.168.x.x-nek megfelelő ip tartomány)

- zslaszlo@zsigmond-latitude5420:~$ ping -6 google.com
ping: connect: Network is unreachable
 

Érdekes, mert tegnap megújítottam kézzel az ipv6 címeket és működött is. Kaptam a digis prefixből ip-t. Egészen a következő újraindításig. Tehát valahol a prefix és a dhcp környékén kell lenni a gebasznak szerintem. 

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( pt56 | 2025. 02. 25., k – 16:34 )

Nem teljesen analóg és lehet, hogy nem segít, de én a Digi-s ipv6-tal is szívtam Mikrotik-en.

A ppp interfészre kaptam ip-t, a /64-es prefix is megjelent, a router-ről el is értem a v6-os hálózatot, de a mögötte lévő eszközökön nem (ip-t kaptam, de forgalmazni nem tudtam). Az volt a megoldás, hogy a bridge1-re (ahol a többi eszköz van) kellett a v6-os tartományból húzni egy ip-t, és minden rendben lett, azóta is így működik.

A v6-os dhcp kliens beállításainál egy "script" fut le, amikor v6-os ip-t/prefix-et kérek:

:if ($leaseBound = "1") do={
    /ipv6 address add address=::1/64 from-pool=digi interface=bridge1 advertise=yes
}

( zslaszlo v | 2025. 02. 25., k – 20:04 )

Úgy tűnik megoldódik a gond. Bekapcsoltam az EUI64 címeket a bridge1 interface-n, ahogy fentebb javasolta pt56 kolléga. (Jó nem ezt javasolta, de jó irányba terelgetett). Most ez a helyzet:

ping -6 google.com
PING google.com (2a00:1450:400d:802::200e) 56 data bytes
64 bytes from bud02s41-in-x0e.1e100.net (2a00:1450:400d:802::200e): icmp_seq=1 ttl=58 time=6.88 ms
64 bytes from bud02s41-in-x0e.1e100.net (2a00:1450:400d:802::200e): icmp_seq=2 ttl=58 time=26.9 ms
64 bytes from bud02s41-in-x0e.1e100.net (2a00:1450:400d:802::200e): icmp_seq=3 ttl=58 time=220 ms
64 bytes from bud02s41-in-x0e.1e100.net (2a00:1450:400d:802::200e): icmp_seq=4 ttl=58 time=12.6 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 6.884/66.493/219.536/88.660 ms

Tehát a kliensek kapnak ip címet és tudnak pingelni is.

Illetve a routeren:

[zslaszlo@MikroTik] > ipv6/route/print 
Flags: D - DYNAMIC; A - ACTIVE; c, d, v, y - COPY; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
     DST-ADDRESS             GATEWAY                               DISTANCE
DAd+ ::/0                    fe80::34be:e778:5645:9c19%pppoe-digi         1
DAd+ ::/0                    fe80::34be:e778:5645:9c19%pppoe-digi         1
DAv+ ::/0                    pppoe-digi                                   1
DAc  2a01:36c:1400:30b::/64  pppoe-digi                                   0
DAc  2a01:36d:1400:30b::/64  bridge1                                      0
D d  2a01:36d:1400:30b::/64                                               1
DAc  fe80::%ether1/64        ether1                                       0
DAc  fe80::%bridge1/64       bridge1                                      0
DAc  fe80::%pppoe-digi/64    pppoe-digi                                   0

Két további kérdésem lenne:

1. Mi a konkrét parancs mikrotik router parancssorban az ipv6 címek pingelésére?

2. Hogyan is működik pontosan ez az EUI64 mód? Itt olvastam róla, elég jól leírják de nem javasolják a használatát. 

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Remek. Köszönöm szépen! A router tudja pingelni az ipv6 címeket. Tehát a v6dhcp Neighbor Discovery lesz a gond. 

[zslaszlo@MikroTik] > ping 2001:4860:4860::8888
  SEQ HOST                                     SIZE TTL TIME       STATUS        
    0 2001:4860:4860::8888                       56  59 6ms84us    echo reply    
    1 2001:4860:4860::8888                       56  59 6ms34us    echo reply    
    2 2001:4860:4860::8888                       56  59 6ms82us    echo reply    
    3 2001:4860:4860::8888                       56  59 18ms394us  echo reply    
    4 2001:4860:4860::8888                       56  59 5ms819us   echo reply    
    5 2001:4860:4860::8888                       56  59 5ms957us   echo reply    
    6 2001:4860:4860::8888                       56  59 6ms113us   echo reply    
    sent=7 received=7 packet-loss=0% min-rtt=5ms819us avg-rtt=7ms783us 
   max-rtt=18ms394us

Miközben a linux hoston:

zslaszlo@zsigmond-latitude5420:~$ ping -6 google.com
ping: connect: Network is unreachable

Most már közelebb vagyok a hiba forrásához.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Sajnos mégsem jó. A következő újraindítás után továbbra sincs publikus ipv6 kiosztás. Gondolom ugyanaz volt, mint néhány napja, ha manuálisan megújítom megy, de a következő indulásnál már nem tud címet kiosztani. Keresem tovább a lehetőségeket. Bármilyen ötletet szívesen fogadok.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Alapbol tul hosszu az RA a Mikrotiken, le kell kicsit roviditeni, nekem a lenti bevalt (szinten Digi):

interface=bridge ra-interval=3m20s-10m ra-delay=3s mtu=unspecified
      reachable-time=unspecified retransmit-interval=unspecified
      ra-lifetime=30m ra-preference=medium hop-limit=64
      advertise-mac-address=yes advertise-dns=yes
      managed-address-configuration=no other-configuration=no

Maszkolás:

/ipv6 firewall nat

add action=masquerade chain=srcnat comment="Masquerade not LAN subnets" connection-state="" out-interface-list=MASQ src-address-list=Local-range to-address=::/64

Ahol a MASQ listában ott a PPPoE, a Local range meg a helyi címtartomány (eredetileg ULA-t használtam volna, de jobb egy (2001:)db8-as tartomány, csak ki kell szedni a bad_ipv6 tiltólistáról)

Ha csak prefix-et akarod maszkolni:

/ipv6 firewall nat

add action=netmap chain=srcnat comment=IPV6SNAT connection-state="" out-interface-list=WAN src-address-list=\
    LAN-pri to-address=[szolgáltatótol kapott /64-es prefix]::/64

add action=netmap chain=dstnat comment=IPV6DNAT connection-state="" dst-address=[szolgáltatótol kapott /64-es prefix]::/64 \
    dst-address-list="" dst-address-type=!local in-interface-list=WAN to-address=[LAN tartomány, ULA vagy DB8]::/64

A szolgáltatói prefix frissítése a szabályokban DHCPv6 kliensen futtatott scripttel (poolname legyen, amit használsz a szolgáltatói tartomány tárolásához):

:local poolname "Digi-pool";
:delay 1s;
:if ( [/ipv6 pool print count-only where name=$poolname] =1 ) do= { 
  :local ispprefix [/ipv6 pool get value-name=prefix $poolname];
  /ipv6 firewall nat set to-address=$ispprefix [find comment="IPV6SNAT"];
  /ipv6 firewall nat set dst-address=$ispprefix [find comment="IPV6DNAT"];
  /ipv6 firewall connection remove [find];
} 

Én úgy csinálom, hogy a LAN felől prefix translation van, minden más alhálóról az internet felé meg maszkolás.

Elsőre szerintem próbálj egy db8-as tartományt a LAN-on és hozzá maszkolást és úgy teszteld. Ha minden működik és össze tudtad integrálni a meglevő szabályaiddal, utána jöhet a prefix translation (netmap)

Annak amúgy szolgáltatótól függetlenül menni kellene, azzal szokott gond lenni, ha változik a tartomány és nem frissül időben, de a többiek is ajánlottak rá tuningolt meg az újabb RouterOS-ekben is volt fejlesztés pl az elavult címtartomány "visszahívására".

elavult címtartomány "visszahívására".

Mi számít elavultnak ?

SLAAC nál is van "lease time"  mint a DHCP nél, és ha az lejár akkor az IP nek le kell konfigurálódnia.

Persze értem én, hogy a szolgáltató balszfasz és az 1 hetes lease time-al kiadott tartományt 5 perc múlvva másik váltja fel, de ezt miért kell megerőszakolni ?

Most hirtelen nem tudom, de mintha rémlene, hogy routeros ben is felül lehet ezeket az értékeket bírálni, szóval mondhatod, hogy neked 5 perc múlvva lejár és újítsa meg ...

Fedora 41, Thinkpad x280