[MEGOLDVA] IPv6 beüzemelése Turris MOX-on (openwrt-vel)

Hálózati eszközök

Mivel az AWS 2024. februártól bevezeti a havi sarcot a publikus IPv4 címekre, felmerült az igény, hogy az otthoni hálózatomból is jó lenne, ha elérnék publikus IPv6 címeket, és tudnám menedzselni az immár IPv6-only AWS node-omat.

Itthon router szempontból egy Turris MOX van, amin eddig az IPv6 funkcionalitás ki volt gyomlálva.
Jelenleg Vodafone-os kábeles netem van, ami IPv4-only, így jobb híján maradt megoldásnak a Hurricane Electric-es IPv6 tunnel.
A HE tunnel regisztrációja és létrehozása rendben ment. Az OpenWRT oldali konfigot ez alapján a cikk alapján csináltam.

A tunnel létre is jött, és a tunnel által leküldött prefix-ek le is terítődnek a kívánt belső hálózatokba az openwrt-s DHCPv6 szerveren keresztül, viszont a routing nem működik jól, és így ki sem tudok látni az Internetre IPv6-on.
A routerről tesztelve legfeljebb a tunnel másik vége az, amit pingelni tudok.

Segítséget szeretnék kérni, hogy mit kellene beállítanom még, hogy rendesen működjön az IPv6 elérés.

A routeren:

root@router:~# ip -6 a s
...
68: 6in4-wan6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 state UNKNOWN qlen 1000
    inet6 2001:470:XXXX:YYY::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::c0a8:a/64 scope link 
       valid_lft forever preferred_lft forever
70: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP qlen 10000
    inet6 2001:470:ZZZZ::1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::da58:d8ff:fe01:cdc9/64 scope link 
       valid_lft forever preferred_lft forever
...
root@router:~# ip -6 ro sh
default from 2001:470:XXXX:YYY::/64 dev 6in4-wan6 proto static metric 1024 pref medium
default from 2001:470:ZZZZ::/48 dev 6in4-wan6 proto static metric 1024 pref medium
2001:470:XXXX:YYY::/64 dev 6in4-wan6 proto kernel metric 256 pref medium
2001:470:ZZZZ::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2001:470:ZZZZ::/48 dev lo proto static metric 2147483647 pref medium
...
root@router:~#

Egy LAN-os végponton:

root@host:~# ip -6 ro sh
::1 dev lo proto kernel metric 256 pref medium
2001:470:ZZZZ::fe5 dev enxcABCD proto kernel metric 102 pref medium
fe80::/64 dev enxcABCD proto kernel metric 1024 pref medium
root@host:~# ip -6 a s
...
26: enxcABCD: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP qlen 1000
    inet6 2001:470:ZZZZ::fe5/128 scope global dynamic noprefixroute 
       valid_lft 22526sec preferred_lft 22526sec
    inet6 fe80::1803:dc8b:c2d1:bfd1/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@host:~#

A fentiek alapján az lehet a probléma, hogy a default route nem kerül leterítésre a kliensek felé. A helyes default route beállítás elvileg a router br-lan interfészén felvett 2001:470:ZZZZ::1 cím lenne.
Ha pedig a routeren próbálok internetes IPv6 címeket pingelni, akkor jó eséllyel az lehet a gond, hogy nem a router, a tunnel által leterített /48-as tartománybeli címével keletkezik a forgalom és mivel a helyes default route csak a /48-beli forrásból származó forgalomra vonatkozik, így nem talál be a tunnelbe.

Az egyedüli bajom csak az, hogy az openwrt webes felületén nem találtam semmi arra vonatkozó lehetőséget, hogy beállítsam a DHCPv6 által leterítendő IPv6-os default route-ot. Esetleg van erre valamilyen lehetőség?

Előre is köszönöm!
János

( sibike | 2024. 01. 15., h – 08:30 )

A default route-ot nem a DHCPv6 protokoll szoláltatja, hanem a router advertisment üzenetek. Valszeg annál lesz a hiba. Milyen verziójú openwrt fut a routeren?

A lanos végponton tudsz egy ilyen tcpdumpot futtatni?

sudo tcpdump -vvvv -ttt -i any icmp6 and 'ip6[40] = 134'

Ez meg fogja mondani, hogy mit hirdet a router a kliens felé.

Illetve most olvasom, hogy a routerről sem működik az IPv6. Lehet először azt kellene megfixálni.

# tcpdump -vvvv -ttt -i enxc84bf6de65b5 icmp6 and 'ip6[40] = 134'
tcpdump: listening on enxc84bf6de65b5, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 00:00:00.000000 IP6 (flowlabel 0xa2b88, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::da58:d7ff:fe00:ccba > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 96
        hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): da:58:d7:00:cc:ba
            0x0000:  da58 d700 ccba
          mtu option (5), length 8 (1):  9000
            0x0000:  0000 0000 2328
          prefix info option (3), length 32 (4): 2001:470:XXXX::/64, Flags [onlink, auto], valid time infinity, pref. time infinity
            0x0000:  40c0 ffff ffff ffff ffff 0000 0000 2001
            0x0010:  0470 XXXX 0000 0000 0000 0000 0000
          rdnss option (25), length 24 (3):  lifetime 1800s, addr: _gateway
            0x0000:  0000 0000 0708 2001 0470 XXXX 0000 0000
            0x0010:  0000 0000 0001
          advertisement interval option (7), length 8 (1):  600000ms
            0x0000:  0000 0009 27c0

Egyelőre ezt kapom.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

( _ventura_ v | 2024. 01. 15., h – 09:18 )

Ezt annó shell scriptel oldottam meg, akkor se ment másképp. Annyi volt az automatizmus, hogy a hotplugd kezelte az eseményt, azaz ha letrejött a tunnel akkor felvettem rá az IP-t meg a route-ot.

Fedora 38, Thinkpad x280

( makos | 2024. 01. 15., h – 09:24 )

A tuzfalon at kell engedned a 6in4 (proto 41) csomagokat a HE tunnel vegpontja felol.

( arpi_esp v | 2024. 01. 15., h – 10:25 )

nekem a HE tunnel nem nagyon mukodott, sokfele persze ment a ping, de a sebesseg is tre volt (1-2 mbit) es nem minden halozat volt elerheto belole. szerintem sok helyen tiltjak is a potencialis veszelyek miatt.

A sebesség olyan, amilyen, nekem böngészésre megfelelt. Azonban ezzel automatikusan 'külföldi' lettem, olyan szolgáltatások, amelyek csak magyarországi IP címeket szolgáltak ki, helyből meghaltak, amíg le nem lőttem az IPv6-ot (sajnos az alkalmazásban nem lehet választani, hogy v4-en menjen, ha van v6, többnyire az az elsődleges. Emiatt aztán le is szálltam a HE-ről. Amit meg a Voda ad v6-ot, az használhatatlan (nincs rendes prefix delegation, eddig már kétszer kellett visszakérnem a v4-et. Sajnos szolgáltatás-megújításkor átteszik v6-ra).

( lcsaszar v | 2024. 01. 15., h – 16:01 )

A klienseken a helyes default route ::/0 a link-local gateway fe80::aaaa:bbbb:cccc:dddd felé kell mutasson. A routeren pedig nálam: default dev 6in4-wan6 a route.

( Zs | 2024. 01. 15., h – 16:32 )

Lépésenként az aknamezőn. Amig "A routerről tesztelve legfeljebb a tunnel másik vége az, amit pingelni tudok.", addig a kliensek se fognak tovább látni (vagy addig se). Elsőként a routeren kéne rendbe tenni az IPv6-ot, legyen onnan elérhető minden, a kliensekkel utána foglalkozzunk.
A tünet alapján egyébként a routeren annyi route van, hogy a tunel ezen végén keresztül a másik vége elérhető - az meg hiányzik, hogy a másik végén elérhető minden más...
Nálam Digi van, az PPoE-n ad IPv6-ot is. Ott a tunelt maga a pppd konfigolja be, de kizárólag link-local címekkel. Ezen a ponton hiába is lenne default gw. a ppp0 túloldala, amíg a helyi oldal nem kap valós IPv6 címet, addig szintén karcsú a kinézegetés az IPv6 világ felé. IPv6-ot viszont már a standard IPv6 router advertisement alapján kap - kicsit később.
Ha ez gurul, akkor jöhet a folytatás: a router hogy ad IPv6 címet, illetve IPv6 router címet a kliensek felé? A kliensek megkapják-e? ...

( lcsaszar v | 2024. 01. 15., h – 16:39 )

Szerkesztve: 2024. 01. 17., sze – 20:24

Ha ez segít, én leírhatom az én OpenWRT-m 6-in-4 konfigurációját, ami nálam kiválóan működik. Szintén Tunnelbroker. A szolgáltatótól csak IPv4 WAN címet kapok.

Irtam erről egy blogot.

Nagyjából átrágtam magam a konfigodon, jópár dolgot átemeltem tőled, és néhányat pedig csak simán megváltoztattam a routeremen.
A route-ok már sokkal jobban néznek ki és a tűzfal szabályai is jobban rendbe vannak téve, de valamiért a forgalom nem megy ott ki ahol kellene neki.
Más magyarázatot nem nagyon találok, mint hogy a tűzfal lehet elkefélve valamilyen szempontból.
A pingjeim az index.hu AAAA-i felé rouing szerint eltalálnának jó felé, de tcpdump-olva az "any" interfészen, a forgalmam nem jelenik meg sehol.

Majd holnap technikaibb leírást is adok majd erről.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

Nos, csak most jutott időm, hogy ezzel foglalkozzak kicsit.
A helyzet a következő:

  • A route-ok és a prefixek amennyire meg tudom ítélni jól terjednek
  • A belső LAN-ra kötött hosztról és a routerről tudom pingelni a tunnel HE felőli IPv6-os végpontját, azonban azon túl semmit.
    A LAN-os hosztról pingelve a router LAN oldali lábának címével kapok választ, mely szerint "Destination unreachable: No route". Ha a routerről próbálom, csak 100%-os packet losst látok. A routing szerint jó irányban látszik a hoszt.
    A routerről pingelve az indexet IPv6-on, azt látom a "tcpdump -peni any host 2a02:730:4000::c0 or host 2a02:730:4000::f0" kimenetében, hogy a filter nem kap el semmit sem, egyik interfészen sem, ergo a tűzfal valószínűleg eldobja a forgalmat és ki sem megy sehová. (Ha a tunnel HE felőli végpontját pingelem IPv6 felett, akkor az a megfelelő filterrel látszik a tcpdump kimenetén, tehát nem az a gond, hogy nem látja a tunnelben menő forgalmat.)
     

A LAN-os gépemről:

root@host:~# ip -6 ro sh
::1 dev lo proto kernel metric 256 pref medium
2001:470:ZZZZ:1::fe5 dev enxcABCD proto kernel metric 102 pref medium
2001:470:ZZZZ:1::/64 dev enxcABCD proto ra metric 102 pref medium
fe80::/64 dev enxcABCD proto kernel metric 1024 pref medium
default via fe80::da58:d8ff:fe01:cdc9 dev enxcABCD proto ra metric 102 pref medium

root@host:~# ping 2001:470:XXXX:YYY::1
PING 2001:470:XXXX:YYY::1(2001:470:XXXX:YYY::1) 56 data bytes
64 bytes from 2001:470:XXXX:YYY::1: icmp_seq=1 ttl=63 time=17.8 ms
64 bytes from 2001:470:XXXX:YYY::1: icmp_seq=2 ttl=63 time=17.5 ms
64 bytes from 2001:470:XXXX:YYY::1: icmp_seq=3 ttl=63 time=15.5 ms
^C
--- 2001:470:XXXX:YYY::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 15.482/16.946/17.814/1.041 ms
root@host:~# ping 2001:470:XXXX:YYY::2
PING 2001:470:XXXX:YYY::2(2001:470:XXXX:YYY::2) 56 data bytes
64 bytes from 2001:470:XXXX:YYY::2: icmp_seq=1 ttl=64 time=0.539 ms
64 bytes from 2001:470:XXXX:YYY::2: icmp_seq=2 ttl=64 time=0.498 ms
^C
--- 2001:470:XXXX:YYY::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1031ms
rtt min/avg/max/mdev = 0.498/0.518/0.539/0.020 ms
root@host:~# ping -6 index.hu
PING index.hu(manis-1.cdn.magex.hu (2a02:730:4000::c0)) 56 data bytes
From 2001:470:ZZZZ:1::1 (2001:470:ZZZZ:1::1) icmp_seq=1 Destination unreachable: No route
From 2001:470:ZZZZ:1::1 (2001:470:ZZZZ:1::1) icmp_seq=2 Destination unreachable: No route
From 2001:470:ZZZZ:1::1 (2001:470:ZZZZ:1::1) icmp_seq=3 Destination unreachable: No route
From 2001:470:ZZZZ:1::1 (2001:470:ZZZZ:1::1) icmp_seq=4 Destination unreachable: No route
From 2001:470:ZZZZ:1::1 (2001:470:ZZZZ:1::1) icmp_seq=5 Destination unreachable: No route
^C
--- index.hu ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4006ms

A routerről:

root@router:~# ip -6 ro sh
default from 2001:470:XXXX:YYY::/64 dev 6in4-wan6 proto static metric 1024 pref medium
default from 2001:470:ZZZZ::/48 dev 6in4-wan6 proto static metric 1024 pref medium
2001:470:XXXX:YYY::/64 dev 6in4-wan6 proto kernel metric 256 pref medium
2001:470:ZZZZ::/64 dev br-wlan proto static metric 1024 pref medium
2001:470:ZZZZ:1::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2001:470:ZZZZ::/48 dev lo proto static metric 2147483647 pref medium
unreachable fdec:2f47:8966::/48 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev br-wlan proto kernel metric 256 pref medium
fe80::/64 dev wlan1-1 proto kernel metric 256 pref medium
fe80::/64 dev 6in4-wan6 proto kernel metric 256 pref medium
fe80::/64 dev tun_turris proto kernel metric 256 pref medium
default dev 6in4-wan6 proto static metric 1024 pref medium

root@router:~# ping -6 index.hu
PING index.hu(manis-4.cdn.magex.hu (2a02:730:4000::f0)) 56 data bytes
^C
--- index.hu ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6269ms

root@router:~# ip ro get 2a02:730:4000::f0
2a02:730:4000::f0 from :: dev 6in4-wan6 proto static src 2001:470:XXXX:YYY::2 metric 1024 pref medium

root@router:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option drop_invalid '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        list network 'wlan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'
        list network 'wwan'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option proto 'icmp'
        option limit '100/sec'
        option family 'ipv6'
        option target 'ACCEPT'
        list icmp_type 'bad-header'
        list icmp_type 'destination-unreachable'
        list icmp_type 'echo-reply'
        list icmp_type 'echo-request'
        list icmp_type 'neighbour-advertisement'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'packet-too-big'
        list icmp_type 'router-advertisement'
        list icmp_type 'router-solicitation'
        list icmp_type 'time-exceeded'
        list icmp_type 'unknown-header-type'
        option src 'wan'

config rule
        option name 'Allow-ICMPv6-Forward'
        option dest '*'
        option proto 'icmp'
        option limit '100/sec'
        option family 'ipv6'
        option target 'ACCEPT'
        list icmp_type 'bad-header'
        list icmp_type 'destination-unreachable'
        list icmp_type 'echo-reply'
        list icmp_type 'echo-request'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'unknown-header-type'
        option src 'wan'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config zone 'turris_vpn_client'
        option name 'tr_vpn_cl'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'

config forwarding 'turris_vpn_client_forward'
        option src 'lan'
        option dest 'tr_vpn_cl'

config zone 'vpn_turris'
        option enabled '1'
        option name 'vpn_turris'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option masq '1'
        list network 'vpn_turris'
        option forward 'ACCEPT'

config rule 'vpn_turris_rule'
        option name 'vpn_turris_rule'
        option target 'ACCEPT'
        option proto 'udp'
        option src 'wan'
        option dest_port '1194'
        option family 'ipv4'

config forwarding 'vpn_turris_forward_lan_in'
        option enabled '1'
        option src 'vpn_turris'
        option dest 'lan'

config forwarding 'vpn_turris_forward_lan_out'
        option enabled '1'
        option src 'lan'
        option dest 'vpn_turris'

config forwarding 'vpn_turris_forward_wan_out'
        option enabled '1'
        option src 'vpn_turris'
        option dest 'wan'

config include 'bcp38'
        option type 'script'
        option path '/usr/lib/bcp38/run.sh'
        option family 'IPv4'
        option reload '1'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'
        option family 'any'
        option reload '1'

config rule
        option src 'wan'
        option name 'allow-proto-41-from-HE'
        list src_ip '216.66.87.14'
        option family 'ipv4'
        option target 'ACCEPT'
        option device 'eth0'
        option direction 'in'
        list proto '41'

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

A LAN (br-lan) interfésznek négyféle címe van:

  • IPv4, ez 192.168.0.1 vagy hasonló RFC1918 cím
  • IPv6 global, 2001:470:xxxx:1::1/64
  • IPv6 ULA, fd31:yyyy:zzzz:1::1/64
  • IPv6 link-local, fe80::valami

Ezeket nézd meg, hogy a kliensekből pingelhetők-e.

Továbbá IPv4-en pingelni kell tudni a HE távoli végpontot, ami 216.66.87.14, és IPv6-on a tunnel távoli végpontot, ami 2001:470:cccc:dddd::1

Minden kliens kell kapjon egy IPv6 global címet prefix delegation által, ami 2001:470:xxxx:1::valami/128 (ahol xxxx ugyanaz, mint a br-lan interfészen az IPv6 global címben levő xxxx.

A WAN6 (6in4-wan6) interfésznek háromféle IPv6 címe van, ebből a link-local fe80:: nem érdekes, a többi:

  • IPv6 global, ez a tunnel helyi végpontja, 2001:470:cccc:dddd::2/64
  • IPv6-PD, ez a prefix delegation, ebből kapnak a kliensek globális címeket, 2001:470:xxxx::/48 ahol xxxx ugyanaz, mint a br-lan interfészen

Ezeket ellenőrizd, hogy megvannak-e, pingelhetőek-e, stb.

Köszi a tippeket!

Nos, a router br-lan interfészén nálam a következő címek vannak:

  • rendes IPv4-es cím, amit eddig is használtam
  • IPv6 global, 2001:470:xxxx:1::1/64
  • IPv6 link-local, fe80::valami

Másmilyen cím nincs rajta, ezek mindegyike pingelhető a kliensemről.
A kliensről pingelhető a távoli HE végpont IPv4-en, és IPv6-on pedig a HE tunnel távoli végének a címe.
A kliensek DHCPv6-on megkapják a delegált címtartomány egy /64-es subnetjéből (2001:470:xxxx:1::0/64) a címüket.

A routeren a tunnel interfésznek pedig az alábbi címei vannak:

  • IPv6 global, 2001:470:cccc:dddd::2/64
  • link-local fe80::

Más bejegyzés nem látszik az "ip a s" kimenetében, ettől függetlenül a prefix delegáció szerintem működik rendesen, mert a tunnel beállításainál beírtam, ahogy kell, és a helyi LAN és WLAN-on rendesen osztva vannak a megfelelő /64-es subnetekből a címek.

Tehát ebből megkockáztatom, hogy a beállítások túlnyomó többsége rendben van.
Valamilyen tűzfal beállításra tudok már csak gondolni.
Arra esetleg van valamilyen tippje valakinek, hogy azt hogyan lehet megnézni valamilyen számlálóval, hogy melyik iptables rule mennyiszer match-csel, illetve ezen számlálókat hogyan lehet nullázni?
Gondolom ez lenne a legcélszerűbb lépés, hogy lássam melyik szabály droppolhatja a kifelé tartó forgalmamat.
Erre abból jutottam, hogy ha tcpdumpolok az "any" interfészen, akkor azt látom, hogy bármely forgalom, amely már a tunnel távoli végpontján túlra menne, beérkezik a routerre, de kifelé már sehová sem megy. Sem a tunnelbe, sem bármelyik másik interfészre, annak ellenére, hogy az "ip ro get" parancs a tunnelt dobja ki rá, tehát a kinti cím a megfelelő irányban látszik.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

Ha nslookup-pal megkeresed valaminek az IPv6 címét, és azt próbálod trace-elni vagy pingelni, akkor sem megy? Lehet esetleg névfeloldás probléma.

Én pl. az Adguard DNS szervereinek a címeit állítottam be:

https://adguard-dns.io/en/public-dns.html

Előkotortam otthon egy félretett, beüzemelésre váró szűz openwrt-s routert, beállítottam neki ugyanazt a tunnelt, és láss csodát az ipv6 csont nélkül megy.
Most akkor a következő teendő az lesz, hogy összefésüljem a tűzfalbeállításokat a két eszköz között, remélve, hogy találok valami eltérést, ami megmagyarázza az eltérő viselkedést.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

( wowbagger v | 2024. 02. 16., p – 07:38 )

A saga legújabb felvonása itt olvasható: https://forum.turris.cz/t/ipv6-routing-problems-from-lan-with-tunnelbro…
Annyi változott, hogy a Turris MOX routeren/routerről már működni tűnik az IPv6, de valamiért a LAN-ra kötött gépemről nem.
Mindez annak ellenére, hogy a cím és a default route leterül a gépemre, amiről tesztelek.

Valamiért a router LAN oldali lába mondja azt, hogy nincs megfelelő útvonal kifelé, annak ellenére, hogy az IPv6-os default route rendesen be van állítva a routeren.
A vicc az, hogy kintről be tudok pingelni IPv6-on a belső hálómba, de ha bentről szeretnék kifelé, akkor nem megy.
Ennek semmi értelme.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos