Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: JBB 24. 07. 2024, 11:44:56
-
Ahoj,
už hodnou dobu se snažím rozchodit IPv6 DHCPv6 NA a PD. Mám Debian 12, zkusil jsem jak dhclient, tak wide-dhcpv6-client. Požádám o NA a PD, zpět dostanu jen PD 2a01:*:*:4140/60. Ten wide-dhcpv6-client krásně rozdělí na všechna (V)LAN rozhraní, toto funguje jak má. Ale WAN nedostane adresu, jedině až po delší době (asi SLAAC) a z jiného prefixu 2a01:*:*:0:*/64. Společně s ISP nejsme schopni docílit přidělení NA, což prý u ostatních klientů, co mají mikrotik, funguje. Navíc pokaždé dostanu jiný prefix, neb se nedaří zafixovat dle DUID.
Debug výpis:
dhcp6c -D -f wan
Jul/24/2024 10:08:20: get_duid: extracted an existing DUID from /var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:2e:32:69:bf:74:da:38:ff:f1:42
Jul/24/2024 10:08:20: cfdebug_print: <3>[interface] (9)
Jul/24/2024 10:08:20: cfdebug_print: <5>[wan] (3)
Jul/24/2024 10:08:20: cfdebug_print: <3>begin of closure [{] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# request a non-temporary address] (33)
Jul/24/2024 10:08:20: cfdebug_print: <3>[send] (4)
Jul/24/2024 10:08:20: cfdebug_print: <3>[ia-na] (5)
Jul/24/2024 10:08:20: cfdebug_print: <3>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# request prefix delegation address] (35)
Jul/24/2024 10:08:20: cfdebug_print: <3>[send] (4)
Jul/24/2024 10:08:20: cfdebug_print: <3>[ia-pd] (5)
Jul/24/2024 10:08:20: cfdebug_print: <3>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# send rapid commit, don't wait for RA] (38)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#send rapid-commit;] (19)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# we'd like information about DNS, too] (38)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#request domain-name-servers;] (29)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#request domain-name;] (21)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# script provided by my distribution, it adds nameservers to resolv.conf] (72)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#script "/etc/wide-dhcpv6/dhcp6c-script";] (41)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of closure [}] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>[id-assoc] (8)
Jul/24/2024 10:08:20: cfdebug_print: <15>[pd] (2)
Jul/24/2024 10:08:20: cfdebug_print: <15>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <15>begin of closure [{] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>[prefix-interface] (16)
Jul/24/2024 10:08:20: cfdebug_print: <5>[lan] (3)
Jul/24/2024 10:08:20: cfdebug_print: <3>begin of closure [{] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# subnet. Combined with ia-pd to configure the subnet for this interface.] (73)
Jul/24/2024 10:08:20: cfdebug_print: <3>[sla-id] (6)
Jul/24/2024 10:08:20: cfdebug_print: <3>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#IP address "postfix". if not set it will use EUI-64 address of the interface. Combined with SLA-ID'd prefix to create full IP address of interface. In my case, ifid 1 means that eth1 will get a IPv6 ending with ::1] (215)
Jul/24/2024 10:08:20: cfdebug_print: <3>[ifid] (4)
Jul/24/2024 10:08:20: cfdebug_print: <3>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# prefix bits assigned. Take the prefix size you're assigned (something like /48 or /56) and subtract it from 64. In my case I was being assigned a /56, so 64-56=8] (163)
Jul/24/2024 10:08:20: cfdebug_print: <3>[sla-len] (7)
Jul/24/2024 10:08:20: cfdebug_print: <3>[4] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of closure [}] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>[prefix-interface] (16)
Jul/24/2024 10:08:20: cfdebug_print: <5>[lan.33] (6)
Jul/24/2024 10:08:20: cfdebug_print: <3>begin of closure [{] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>[sla-id] (6)
Jul/24/2024 10:08:20: cfdebug_print: <3>[3] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [#ifid 1;] (8)
Jul/24/2024 10:08:20: cfdebug_print: <3>[sla-len] (7)
Jul/24/2024 10:08:20: cfdebug_print: <3>[4] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of closure [}] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of closure [}] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>[id-assoc] (8)
Jul/24/2024 10:08:20: cfdebug_print: <15>[na] (2)
Jul/24/2024 10:08:20: cfdebug_print: <15>[1] (1)
Jul/24/2024 10:08:20: cfdebug_print: <15>begin of closure [{] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>comment [# id-assoc for lan] (18)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of closure [}] (1)
Jul/24/2024 10:08:20: cfdebug_print: <3>end of sentence [;] (1)
Jul/24/2024 10:08:20: configure_pool: called
Jul/24/2024 10:08:20: clear_poolconf: called
Jul/24/2024 10:08:20: dhcp6_reset_timer: reset a timer on wan, state=INIT, timeo=0, retrans=446
Jul/24/2024 10:08:21: client6_send: a new XID (c29bdb) is generated
Jul/24/2024 10:08:21: copy_option: set client ID (len 14)
Jul/24/2024 10:08:21: copyout_option: set identity association
Jul/24/2024 10:08:21: copy_option: set elapsed time (len 2)
Jul/24/2024 10:08:21: copyout_option: set IA_PD
Jul/24/2024 10:08:21: client6_send: send solicit to ff02::1:2%wan
Jul/24/2024 10:08:21: dhcp6_reset_timer: reset a timer on wan, state=SOLICIT, timeo=0, retrans=1004
Jul/24/2024 10:08:21: client6_recv: receive advertise from fe80::764d:28ff:fe27:dfe6%wan on wan
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option client ID, len 14
Jul/24/2024 10:08:21: DUID: 00:01:00:01:2e:32:69:bf:74:da:38:ff:f1:42
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option server ID, len 10
Jul/24/2024 10:08:21: DUID: 00:03:00:01:74:4d:28:27:df:e7
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option preference, len 1
Jul/24/2024 10:08:21: preference: 255
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option IA_PD, len 41
Jul/24/2024 10:08:21: IA_PD: ID=1, T1=43200, T2=69120
Jul/24/2024 10:08:21: copyin_option: get DHCP option IA_PD prefix, len 25
Jul/24/2024 10:08:21: copyin_option: IA_PD prefix: 2a01:*:*:4140::/60 pltime=77760 vltime=86400
Jul/24/2024 10:08:21: client6_recvadvert: server ID: 00:03:00:01:74:4d:28:27:df:e7, pref=255
Jul/24/2024 10:08:21: client6_send: a new XID (4f7ebc) is generated
Jul/24/2024 10:08:21: copy_option: set client ID (len 14)
Jul/24/2024 10:08:21: copy_option: set server ID (len 10)
Jul/24/2024 10:08:21: copy_option: set elapsed time (len 2)
Jul/24/2024 10:08:21: copyout_option: set IA_PD prefix
Jul/24/2024 10:08:21: copyout_option: set IA_PD
Jul/24/2024 10:08:21: client6_send: send request to ff02::1:2%wan
Jul/24/2024 10:08:21: dhcp6_reset_timer: reset a timer on wan, state=REQUEST, timeo=0, retrans=972
Jul/24/2024 10:08:21: client6_recv: receive advertise from fe80::764d:28ff:fe27:dfe6%wan on wan
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option client ID, len 14
Jul/24/2024 10:08:21: DUID: 00:01:00:01:2e:32:69:bf:74:da:38:ff:f1:42
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option server ID, len 10
Jul/24/2024 10:08:21: DUID: 00:03:00:01:74:4d:28:27:df:e7
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option preference, len 1
Jul/24/2024 10:08:21: preference: 255
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option IA_PD, len 41
Jul/24/2024 10:08:21: IA_PD: ID=1, T1=43200, T2=69120
Jul/24/2024 10:08:21: copyin_option: get DHCP option IA_PD prefix, len 25
Jul/24/2024 10:08:21: copyin_option: IA_PD prefix: 2a01:*:*:4140::/60 pltime=77760 vltime=86400
Jul/24/2024 10:08:21: client6_recvadvert: XID mismatch
Jul/24/2024 10:08:21: client6_recv: receive reply from fe80::764d:28ff:fe27:dfe6%wan on wan
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option client ID, len 14
Jul/24/2024 10:08:21: DUID: 00:01:00:01:2e:32:69:bf:74:da:38:ff:f1:42
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option server ID, len 10
Jul/24/2024 10:08:21: DUID: 00:03:00:01:74:4d:28:27:df:e7
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option IA_PD, len 41
Jul/24/2024 10:08:21: IA_PD: ID=1, T1=43200, T2=69120
Jul/24/2024 10:08:21: copyin_option: get DHCP option IA_PD prefix, len 25
Jul/24/2024 10:08:21: copyin_option: IA_PD prefix: 2a01:*:*:4140::/60 pltime=77760 vltime=86400
Jul/24/2024 10:08:21: get_ia: make an IA: PD-1
Jul/24/2024 10:08:21: update_prefix: create a prefix 2a01:*:*:4140::/60 pltime=77760, vltime=86400
Jul/24/2024 10:08:21: ifaddrconf: add an address 2a01:*:*:4141::1/64 on lan
Jul/24/2024 10:08:21: ifaddrconf: add an address 2a01:*:*:4143:ea9c:25ff:fe12:8a65/64 on lan.33
Jul/24/2024 10:08:21: dhcp6_remove_event: removing an event on wan, state=REQUEST
Jul/24/2024 10:08:21: dhcp6_remove_event: removing server (ID: 00:03:00:01:74:4d:28:27:df:e7)
Jul/24/2024 10:08:21: client6_recvreply: got an expected reply, sleeping.
Jul/24/2024 10:08:21: client6_recv: receive reply from fe80::764d:28ff:fe27:dfe6%wan on wan
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option client ID, len 14
Jul/24/2024 10:08:21: DUID: 00:01:00:01:2e:32:69:bf:74:da:38:ff:f1:42
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option server ID, len 10
Jul/24/2024 10:08:21: DUID: 00:03:00:01:74:4d:28:27:df:e7
Jul/24/2024 10:08:21: dhcp6_get_options: get DHCP option IA_PD, len 41
Jul/24/2024 10:08:21: IA_PD: ID=1, T1=43200, T2=69120
Jul/24/2024 10:08:21: copyin_option: get DHCP option IA_PD prefix, len 25
Jul/24/2024 10:08:21: copyin_option: IA_PD prefix: 2a01:*:*:4140::/60 pltime=77760 vltime=86400
Jul/24/2024 10:08:21: client6_recvreply: XID mismatch
Předem díky za každou radu.
-
Moc z toho nevidim, ale obecne IPv6 ne uplne snese DROP vsechno provozu na INPUTu. Takze bych se podival na firewall. To ze projde nejake to DHCP muze byt tim, ze mu pomuze RELATED,ESTABLISHED pravidlo.
Smerem k providerovi bych nastavil na interface accept_ra=2 a zkusil pouzivat SLAAC, trochu cekam, mikrotiku to funguje, protoze provider pouziva pro konektivitu SLAAC a DHCP jen pro PD, v tom logu nejak IA_NA nevidim.
-
Moc z toho nevidim, ale obecne IPv6 ne uplne snese DROP vsechno provozu na INPUTu. Takze bych se podival na firewall.
A co jiného, když ne drop? Reject?
To ze projde nejake to DHCP muze byt tim, ze mu pomuze RELATED,ESTABLISHED pravidlo.
Ne, nepomůže, odchází to na ff02::1:2 a vrací se to z LLA.
Musí tam být:
udp dport dhcpv6-client ip6 daddr fe80::/64 limit rate 13/second accept
Smerem k providerovi bych nastavil na interface accept_ra=2 a zkusil pouzivat SLAAC, trochu cekam, mikrotiku to funguje, protoze provider pouziva pro konektivitu SLAAC a DHCP jen pro PD, v tom logu nejak IA_NA nevidim.
To jsem taky zkoušel a ano, i bez accept_ra=2 dostanu za hodnou chvíli adresu, ale z jiného prefixu. 2a01:*:*:0:* místo 2a01:*:*:4040:*. A podle providera má být i adresa DHCP a od těch mikrotiků vidí lease, ode mě ne.
V logu i v odchyceném provozu vidím moji žádost NA a PD, jako odpověď přijdou 2 pakety jen s PD.
-
...
A co jiného, když ne drop? Reject?
...
Predevsim musis mit funkcni ICMP, pokud ho zahazujes, tak ti IPv6 nikdy fungovat nebude.
-
Predevsim musis mit funkcni ICMP, pokud ho zahazujes, tak ti IPv6 nikdy fungovat nebude.
Mám.
ip6 nexthdr icmpv6 limit rate 13/second accept
-
Pro ladeni bych dal normalne do INPUTu ACCEPT a do FORWARDu DROP aby se mi nekdo neprosel po vnitrni siti. Ten router samotny bud otevreny provoz chvili snese a nebo muzete shodit sluzby co na nem bezi. Firewall muzete utahnout hned jak bude fungovat konektivita.
Pokud dostavate IP z jineho prefixu, je otazka jak je to mozne. Klidne muze mit soused blbe propojenou sit a komunikujete s nim misto v providerem. Byt pokud jsou tohle realna cisla, videl bych sit s nulami spise jako nejakou infrastrukturni. Ale to by mel rict provider, jaka je to adresa a jestli je za nej OK, ze ji klienti dostavaji. Protoze takto vypadajici adresu si ten router urcite nevymyslel, tu musel od nekoho dostat. A kdyz neni ve vystupu dhcp, tak jinak nez pres SLAAC pritect nemohla. (Pomijim moznost, ze distribuce ma na pozadi bezici dhcp klient a vy jste pustil z ruky druhy).
Zajimavy by byl vystup z
tcpdump -vvvv -n -ttt -i wan icmp6 and 'ip6[40] = 134'
jestli je tam managed-config-flag, protoze pokud by tam nebyl, tak dhcp klient potencialne adresu zadat nebude, ale nekoukal jsem do zdrojaku jak presne je tohle vymyslene. Soucasne uvidite prefixy, ktere tam nekdo posila.
Pripadne kouknout na
tcpdump -i wan -n -vvvv -ttt '(udp port 546 or 547) or icmp6'
jestli realne neprichazi odpoved a nebo jestli prichazi ale vas klient ji nevidi.
-
K tcpdumpu bych pridal jeste "-e", at vidite MAC adresy.
ISP musi tak jako tak posilat router advertisementy, aby klientuv router vedel, kam nasmerovat default gateway. A pokud od nekoho chodi router advertisementy, pomoci MAC adresy by melo jit porovnat, jestli je stejna jako MAC default gateway pro IPv4 (pak to nejspis posila ISP) nebo jina (spatne nakonfigurovany klient?)
pripadne se da pouzit jeste rdisc6 -1 nazev_wan_interface (postnete nam sem vystup)
Mikrotik ma mimochodem divnou funkcionalitu, kdy default gateway dokaze nastavit na link-local adresu, ze ktere prisla DHCPv6 odpoved.
Dalsi namet: skutecne klientum s mikrotikem funguje IA_NA? Nebo klienti s mikrotikem jen nastavi gateway (viz vyse) a traffic tece?
Technicky muzete mit WAN bez IPv6 adresy. Vadi necemu absence IPv6 adresy na WAN? Doroutuje se k vam traffic z Internetu na oddelegovany prefix?
-
Pro ladeni bych dal normalne do INPUTu ACCEPT a do FORWARDu DROP aby se mi nekdo neprosel po vnitrni siti.
Dal jsem iifname "wan" counter accept.
Pokud dostavate IP z jineho prefixu, je otazka jak je to mozne.
Prý se nedaří zafixovat dle DUID. Takže PD req k nim chodí. A můj DUID je typ 1, tj "plus time", jejich je 3 bez času. Změnit se mě to nepodařilo (wide-dhcp-client).
(Pomijim moznost, ze distribuce ma na pozadi bezici dhcp klient a vy jste pustil z ruky druhy).
6-kový běží opravdu jen jeden.
tcpdump -vvvv -n -ttt -i wan icmp6 and 'ip6[40] = 134'
00:00:00.000000 74:*:*:*:df:e6 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::764d:*:*:dfe6 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
hop limit 0, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
source link-address option (1), length 8 (1): 74:*:*:*:df:e6
0x0000: 744d 2827 dfe6
prefix info option (3), length 32 (4): 2a01:5e0:6c::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x0000: 40c0 0027 8d00 0009 3a80 0000 0000 2a01
0x0010: 05e0 006c 0000 0000 0000 0000 0000
00:00:00.000912 74:*:*:*:df:e6 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::764d:*:*:dfe6 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
hop limit 0, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
source link-address option (1), length 8 (1): 74:*:*:*:df:e6
0x0000: 744d 2827 dfe6
prefix info option (3), length 32 (4): 2a01:5e0:6c::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x0000: 40c0 0027 8d00 0009 3a80 0000 0000 2a01
0x0010: 05e0 006c 0000 0000 0000 0000 0000
00:02:28.647933 ac:*:*:*:ea:20 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::ae8b:*:*:ea20 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
hop limit 64, Flags [other stateful], pref low, router lifetime 0s, reachable time 0ms, retrans timer 0ms
source link-address option (1), length 8 (1): ac:*:*:*:ea:20
0x0000: ac8b a9e0 ea20
Ten druhý by mohla být záložní linka do města.
tcpdump -i wan -n -vvvv -ttt '(udp port 546 or 547) or icmp6'
Filter dumpu jem omezil jen na DHCPv6, protože ICMPv6 je tam toho hodně ze vnitřku do světa.
00:00:00.000000 74:*:*:*:f1:42 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 122: (flowlabel 0x8479d, hlim 1, next-header UDP (17) payload length: 68) fe80::76da:*:*:f142.546 > ff02::1:2.547: [bad udp cksum 0x9df8 -> 0x2be9!] dhcp6 solicit (xid=dbf85a (client-ID hwaddr/time type 1 time 775055807 74*f142) (IA_NA IAID:1 T1:0 T2:0) (elapsed-time 0) (IA_PD IAID:1 T1:0 T2:0))
00:00:00.007517 74:*:*:*:df:e6 > 74:*:*:*:f1:42, ethertype IPv6 (0x86dd), length 148: (hlim 64, next-header UDP (17) payload length: 94) fe80::764d:*:*:dfe6.547 > fe80::76da:*:*:f142.546: [udp sum ok] dhcp6 advertise (xid=dbf85a (client-ID hwaddr/time type 1 time 775055807 74*f142) (server-ID hwaddr type 1 74*dfe7) (preference 255) (IA_PD IAID:1 T1:43200 T2:69120 (IA_PD-prefix 2a01:*:*:4190::/60 pltime:77760 vltime:86400)))
00:00:00.000265 74:*:*:*:df:e6 > 74:*:*:*:f1:42, ethertype IPv6 (0x86dd), length 148: (hlim 64, next-header UDP (17) payload length: 94) fe80::764d:*:*:dfe6.547 > fe80::76da:*:*:f142.546: [udp sum ok] dhcp6 advertise (xid=dbf85a (client-ID hwaddr/time type 1 time 775055807 74*f142) (server-ID hwaddr type 1 74*dfe7) (preference 255) (IA_PD IAID:1 T1:43200 T2:69120 (IA_PD-prefix 2a01:*:*:4190::/60 pltime:77760 vltime:86400)))
00:00:00.000606 74:*:*:*:f1:42 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 149: (flowlabel 0x8479d, hlim 1, next-header UDP (17) payload length: 95) fe80::76da:*:*:f142.546 > ff02::1:2.547: [bad udp cksum 0x9e13 -> 0x9cf7!] dhcp6 request (xid=f46d9c (client-ID hwaddr/time type 1 time 775055807 74*f142) (server-ID hwaddr type 1 74*dfe7) (elapsed-time 0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2a01:*:*:4190::/60 pltime:77760 vltime:86400)))
00:00:00.004148 74:*:*:*:df:e6 > 74:*:*:*:f1:42, ethertype IPv6 (0x86dd), length 143: (hlim 64, next-header UDP (17) payload length: 89) fe80::764d:*:*:dfe6.547 > fe80::76da:*:*:f142.546: [udp sum ok] dhcp6 reply (xid=f46d9c (client-ID hwaddr/time type 1 time 775055807 74*f142) (server-ID hwaddr type 1 74*dfe7) (IA_PD IAID:1 T1:43200 T2:69120 (IA_PD-prefix 2a01:*:*:4190::/60 pltime:77760 vltime:86400)))
00:00:00.000360 74:*:*:*:df:e6 > 74:*:*:*:f1:42, ethertype IPv6 (0x86dd), length 143: (hlim 64, next-header UDP (17) payload length: 89) fe80::764d:*:*:dfe6.547 > fe80::76da:*:*:f142.546: [udp sum ok] dhcp6 reply (xid=f46d9c (client-ID hwaddr/time type 1 time 775055807 74*f142) (server-ID hwaddr type 1 74*dfe7) (IA_PD IAID:1 T1:43200 T2:69120 (IA_PD-prefix 2a01:*:*:4190::/60 pltime:77760 vltime:86400)))
pripadne se da pouzit jeste rdisc6 -1 nazev_wan_interface (postnete nam sem vystup)
Soliciting ff02::2 (ff02::2) on wan...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : Yes
Mobile home agent : No
Router preference : low
Neighbor discovery proxy : No
Router lifetime : 0 (0x00000000) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Source link-layer address: AC:*:*:*:EA:20
from fe80::ae8b:*:*:ea20
Dalsi namet: skutecne klientum s mikrotikem funguje IA_NA? Nebo klienti s mikrotikem jen nastavi gateway (viz vyse) a traffic tece?
Jo, to já k nim nevidím, ale prý u ostatních v něčem vidí DHCP6 leased addr, u mě ne.
Technicky muzete mit WAN bez IPv6 adresy. Vadi necemu absence IPv6 adresy na WAN? Doroutuje se k vam traffic z Internetu na oddelegovany prefix?
Úplně bez asi ne, je tam vždy LLA. Asi spíš vadí, abych se dostal domů na VPN server. A ano, doroutuje, alespoň dle ping6. Mám to teď komplet static.
-
Asi to nechápu, ale to je přece naprosto v pořádku, že adresa na WAN rozhraní je z jiného prefixu než je prefix distribuovaný pomocí DHCP-PD. Naopak kdyby byla ze stejného bylo by to zvláštní.
Pokud adresu na WAN rozhraní nevyžaduje ISP - což jak se zdá nevyžaduje - tak ji prostě nemusíte řešit a k routeru se připojovat pomocí adresy na LAN rozhraní z delegovaného prefixu.
-
Asi to nechápu, ale to je přece naprosto v pořádku, že adresa na WAN rozhraní je z jiného prefixu než je prefix distribuovaný pomocí DHCP-PD. Naopak kdyby byla ze stejného bylo by to zvláštní.
Jako úplně jiného, nespadající do mého rozsahu?
2a01:*:*:0:*/60 místo 2a01:*:*:4040:*/60
Pokud adresu na WAN rozhraní nevyžaduje ISP - což jak se zdá nevyžaduje - tak ji prostě nemusíte řešit a k routeru se připojovat pomocí adresy na LAN rozhraní z delegovaného prefixu.
Jo, taky řešení. Nevím, jestli ISP ví co vyžadovat, ale "připadá mu to divné, poněvadž ostatní ji dostanou." A taky aby na tom DHCP lease neměl závislé další featury, kdy u IPv4 pokud se nějaký týden neozvu, spadne mi rychlost na minimum.
-
To není jiný prefix, to je prefix nadřazený.
Mám prefix 56 a na WAN interface adresu ve tvaru: <prefix48>:0::<prefix12>
Prefix 48 patří ISP, z toho mi kousek ukrojil, přidal dalšich 12 bitů, ktere jsou ve WAN adrese jako ID uživatele.
Na WAN adresu mi dojde celý delegovaný prefix 56 a router to přepošle na některý LAN interface - rozhoduje dalších 8 bitů z prefixu.
Na DHCP lease je vázané nějaké routovací nebo firewall pravidlo, když na WAN nastavím stejnou adresu ručně, tak to nejede, stejně tak když lease expiruje a není obnoven.
-
Podle tech dat z tcpdumpu a rdisc6 ISP neoznamuje "managed" ("stateful address") flag, stejne tak v DHCP odpovedich neprirazuje adresy, takze jini zakaznici na tomto segmentu site nemohou zadnou adresu dostat. Prijde mi zvlastni, ze ISP nevi, co ma nakonfigurovane...
Jinak jak pise Ondrej, adresy na WAN jsou typicky z jineho prefixu nez z toho, ktery prijde v PD odpovedi od ISP, a je to tak normalni a spravne. Na router se pripojite pomoci adresy z LAN rozhrani (firewallova pravidla na inputu se aplikuji na vsechny adresy na routeru, tj. pokud je v input chainu povolen pristup z WAN rozhrani na tcp/22, bude fungovat SSH z Internetu na LAN i WAN adresy).
Jeste me prekvapuje, ze v reakci na router solicitation pomoci rdisc6 nedorazi zadny WAN prefix, zatimco v tcpdumpu zcela jasne chodi 2a01:5e0:6c::/64 s priznakem "auto" (=pouzij SLAAC).
-
Jeste jednou koukam na ten tcpdump a v siti jsou dve zarizeni (podle tech zamaskovanych MAC adres), ktera posilaji router advertisementy. Ani jedno ale neoznamuje, ze by se v siti pouzivalo DHCPv6 pro pridelovani adres (IA_NA).
-
...Naopak kdyby byla ze stejného bylo by to zvláštní....
Nikoli, je to pomerne bezna vec, typicky se pouziva prvni /64. Duvod je prosty - zaevidujes k pripojce /56 a nemusis resit dalsi IPcko. Samo pak nemuzes odroutovat tu /56 celou.
Nekdy to maji udelano tak, ze dostanes trebas ..:100::/56 a router dostane ...:0:100::1/64 => ma IPcko z jineho rozsahu ale to obsahuje steje cislo. (takto nejak to maji tusim petriny.net)
Router na IPv6 nemusi mit verejny adresy vubec, vystaci s linkovyma.
-
Router na IPv6 nemusi mit verejny adresy vubec, vystaci s linkovyma.
Router asi vystačí.
Ale pokud ten router dělá ještě něco jiného, tak se ta veřejná adresa může hodit. Zvlášť pokud by ten router měl zahajovat nějaké spojení (stačí ping) ven.
-
Ale pokud ten router dělá ještě něco jiného, tak se ta veřejná adresa může hodit. Zvlášť pokud by ten router měl zahajovat nějaké spojení (stačí ping) ven.
A takových věcí bude dost, třeba upgrade...
-
Router nemusí mít globální adresy na WAN, pro odchozí provoz použije adresu, kterou si nakonfiguruje z delegovaného prefixu.
Mimochodem, pokud nějaký ISP přiděluje /64 pro WAN z delegovaného (většího) bloku, např. /56, tak je to velmi kreativní. Pokud by přiděloval první /64, tak tím asi může dost routerů rozbít (pokud by domácí router pro LAN chtěl použít stejný - první - /64 prefix jako je na WAN, jak se to asi bude chovat?).
Existuje sice RFC 6603 (https://www.rfc-editor.org/rfc/rfc6603), které něco podobného umožňuje, ale nevím o tom, že by ho běžně používaná CPE podporovala.
-
Router nemusí mít globální adresy na WAN, pro odchozí provoz použije adresu, kterou si nakonfiguruje z delegovaného prefixu.
Já už se v tom ztrácím. Takže ji ale nakonec má. Globální. Si nakonfiguruje jakože samo linux jádro?
Mimochodem, pokud nějaký ISP přiděluje /64 pro WAN z delegovaného (většího) bloku, např. /56, tak je to velmi kreativní. Pokud by přiděloval první /64, tak tím asi může dost routerů rozbít (pokud by domácí router pro LAN chtěl použít stejný - první - /64 prefix jako je na WAN, jak se to asi bude chovat?).
Takže vlastně ISP to má správně, když dává jen PD a s tím si můžu dělat co chci, např. 1. na LAN, 3. na WAN?
-
Takže ji ale nakonec má. Globální. Si nakonfiguruje jakože samo linux jádro?
Namá a přesto to jede. Otestováno ping6. Použije asi první globální, co se mu namane. V mém případě tu z LAN. *:4041::1
-
Já už se v tom ztrácím. ...
To je zjevny ...
Hele, libovolny zarizeni muze mit libovolny pocet rozhrani a na nich libovolny pocet adres. Z pohledu toho zarizeny vsechny ty adresy pari jemu, takze je jedno, na kterym iface tu adresu mas.
Typicky zarizeni pouzije pro odchozi provoz tu adresu, ktera je na iface pres ktery odchozi provoz odchazi. Kdyz je tam tech adres vic ... tak bud reknes aplikaci kterou ma pouzivat nebo se pouzije ta nejmensi (nebo muzes mit milion jinych pravidel).
IPv6 ma fungovat tak, ze ti ISP pres PD prideli prefix (nejmin /56) a tvuj router si z toho vyzobe rozsahy pro jednotlive site, idealne opet sam. V ramci toho muze a nemusi (v zavislosti na konfiguraci) na iface smerujici do tech siti pridelit adresu. Ano, pro 4kare zcela nepochopitelny. Takze typicky spis prideli.
A kdyz tam tu adresu (na ten LAN) mas, tak to staci, staci ti i jen jedna, a muzes s tim i zvenku komunikovat, protoze kdyz prijde provoz na to IPcko, tak ten router vi, ze to je jeho adresa. Stejne tak vi, ze kdyz chces pingat ven, mimo tu linku, tak pouzije v src prave tu jednu ipv6 kterou ve tvym pripade nejspis ma.
To co je ve tvym pripade ponekud zvlastni (alespon z toho jak to popisujes) je to, ze provider tvrdi, ze dhcp prideluje adresu jen tobe ne, a pak ji dostanes z RAcka s nejakym zpozdenim.
Mimochodem, krome (neomezovani) ICMP, protoze se pouziva namisto ARP (napr) jeste potrebujes aby ti fungoval multicast, protoze ten se pouziva taky. Takze co takhle firewall uplne vypnout a uvidis jak to bude chodit?
Zatim 100% "divnych" veci na IPv6 bylo vzdy konfiguraci firewallu na tema "v ipv4 to prece nanic nepotrebuju".
-
Tak po dlouhé době nějaký malilinkatý porkrok:
2 měsíce to jelo na komplet static konfiguraci. Včera ráno to přestalo fungovat, dopídil jsem se, že data odcházejí ale nevracejí se: ICMP6, time exceeded in-transit. Oba jsme nevěděli co s tím a tak jsem znovu spustil dhcp, konkrétně wide-dhcp. A ejhle, dostal jsem PD i RA a data začala chodit obousměrně. Bez změny FW na mé straně, ISP mezitím měnil switch...
Jenže jsem potřeboval přerozdělit sítě, takže restart dhcp a dostal jsem jiný prefix. No po dlohém bádání jsme dospěli k poznání, že mikrotik na straně ISP očekává DUID typ 3 (pouze MAC) a wide-dhcp posílá pouze typ 1 (čas + MAC). Vite někdo co s tím? Prolezl jsem i zdrojáky a tam je v komentu "podpora pouze typ 1". No tak jsem mu podstrčil DUID s tím "správným" starým časem, ale mikrotik tvrdošíjně přiděluje jiný prefix.
A jako další drobná "chybka" je, že dostanu RA až za nějakou chvílku (200-500s má nastaveno ISP), což chápu tak, že kvůli static konfiguraci se nijak nedozví, že jsem se připojil a bylo by záhodno poslat RA hned.