Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
On Sat, Sep 25, 2021 at 09:04:26AM +0200, Gijs Hillenius wrote:
> Goedenmorgen!
>
> Tijd voor een update. Er zit een (klein) beetje schot in, maar ik ben er
> nog niet.
>
> /me veegt lei schoon, huidige configuratie onderaan.
>
>
> A) IPv4 lijkt het te doen.
>
> Met ping4 kom ik voorbij de server. En, ik kan (als voorbeeld) met ssh
> -4 een-vriend@shell.xs4all.nl bereiken, en dan toont het me dat ik kom
> vanaf 144.76.204.189, zoals de bedoeling is.
>
> Mijn conclusie: masquerading werkt,
> en de firewalld doet zijn werk. Voor IPv4.
Ja, er zal sprake zijn van masquerading.
Waar het gebeurd heeft het verhaal nog niet vertelt.
Is het misschien iets wat "ADSL modem router" doet?
> b) IPv6 gaat gedeeltelijk goed.
>
> Zowel client en server kan ik nu heen en weer met ping6 bereiken. Maar
> ik kom niet vanaf de client voorbij de server, niet met ping6, maar ook
> niet met ssh. Bijvoorbeeld
>
> ssh -6 weer-die-vriend@shell.xs4all.nl
> (knip)
> debug1: Connecting to shell.xs4all.nl [2001:888:0:1::9] port 22.
>
> en dan stilte, tot ik ^C doe.
Er zal ook masquerading nodig zijn. Dan wel iets anders zodat "local
addresses" ( fc80:: ) niet meer lokale adressen zijn.
> De configuratie van de client - let op, er staan twee mogelijke IPv[4,6]
> reeksen, ze doen het beiden (niet tegelijk, uiteraard).
>
> ,----
> | [Interface]
> | Address= 10.93.15.2/24, fc80::b85f:d925:971e:110f/64
> | # een alternatief, werkt ook: Address = 10.66.66.2/24,fd42:42:42::2/64
> | PrivateKey = <privatekey>
> |
> | [Peer]
> | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0=
> | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820
> | AllowedIPs = 0.0.0.0/0, ::/0
> | PersistentKeepalive = 25
> `----
>
> en die van de server:
>
> ,----
> | Interface]
> | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64
> | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64
> | PrivateKey = <privatekey>
> | ListenPort = 51820
> |
> | [Peer]
> | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U=
> | # alternatief: AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128
> | AllowedIPs = 10.93.15.2/32, fc80::b85f:d925:971e:110f/128
> `----
>
> In de spaarzame vrije tijd heb ik van alles nagelopen.
>
... IPv4 ...
>
> Dan spelde ik https://wiki.debian.org/NetworkConfiguration: mist mijn
> static configured ethernet device (die van de oops) soms "accept_ra 2"
> (ik begrijp het helaas nog niet helemaal)
>
> sysctl net.ipv6.conf.all.accept_ra=2 getest
>
> Maar het maakt voor WireGuard niets uit.
>
> Ik zie ook /niets/ relevants in de logs (mezelf kennende zal het er toch
> wel staan).
>
> Hier een paar van de huidige IPv6 instellingen op de server:
>
> sysctl -a | grep -E 'ipv6.*\.(forwarding|accept_ra) ='
> net.ipv6.conf.all.accept_ra = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv6.conf.default.accept_ra = 1
> net.ipv6.conf.default.forwarding = 1
> net.ipv6.conf.eth0.accept_ra = 0
> net.ipv6.conf.eth0.forwarding = 1
> net.ipv6.conf.lo.accept_ra = 1
> net.ipv6.conf.lo.forwarding = 1
> net.ipv6.conf.wg0.accept_ra = 1
> net.ipv6.conf.wg0.forwarding = 1
Met de diverse 'forwarding = 1' ben ik het mee eens.
Wat ik hier van de "accept router advertizing" moet vinden,
weet ik nog niet.
> Waarom doe ik al die moeite om Wireguard ook via IPv6 te doen? Tja: ik
> wil het gewoon in orde hebben, het is net als het strijken van je
> overhemden. In België wordt IPv6 gewoon goed ondersteund, het werkt goed
> op mijn LAN, het doet het uitstekend in Debian. WireGuard kan het, dus
> waarom zou ik het niet doen?
Met alle respect: "Your logic is flawed"
Weet dat ik het ook een uitdagend probleem vind.
Mijn insteek is wel "Waar gaat het kapot?" (vermoeden: Geen NAT)
Gijs zijn insteek is meer "Hoe krijg ik het werkend?"
Als we roepen "Het gaat niet" komt de mensheid nooit vooruit.
> op de server:
>
> ip -6 route
> ,----
> | ::1 dev lo proto kernel metric 256 pref medium
> | 2a01:4f8:200:546b::/64 dev eth0 proto kernel metric 256 pref medium
> | fd42:42:42::/64 dev wg0 proto kernel metric 256 pref medium
Dat komt niet overeen met
| Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64
Eventueel wel met
| # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64
> | fe80::/64 dev eth0 proto kernel metric 256 pref medium
> | default via 2a01:4f8:200:546b::3 dev eth0 metric 1024 onlink pref medium
> `----
>
> Mij valt op dat ssh -6 hierboven wel weet welk IP address ie moet
> hebben.
>
> /etc/resolf.conf op de server (wg0 is up)
> nameserver 2606:4700:4700::1111
> nameserver 1.1.1.1
>
> op de client (wg0 is eveneens up)
> search home
> nameserver 192.168.1.1
>
> dank voor de aandacht!
Output van `ip -6 route` op client ontbrak.
> Vraag: Hoe tover ik op de wireguard server informatie tevoorschijn die
> toont waarom het IPv6 verkeer stopt bij de server. Iemand suggesties?
Het echte probleem^Wuitdaging is connectie tussen wireguard client en
IPv6 host voorbij wireguard server. Of dat IPv6 verkeer stopt bij de
wireguard server is nog niet gebleken, het kan ook zijn de
netwerkpakketen verder op verloren gaan.
> Tips zijn (zeer) welkom!
Op WGserver: sudo tcpdump -ni any port 2309
Op WGclient: telnet host_achter_server 2309
Voorbeeld output van tcpdump
$ sudo tcpdump -ni any port 2309
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:55:52.417979 IP 192.168.124.192.55166 > 192.168.65.25.2309: Flags [S], seq 4217907771, win 64860, options [mss 1380,sackOK,TS val 1993389822 ecr 0,nop,wscale 7], length 0
22:55:52.418023 IP 192.168.124.192.55166 > 192.168.65.25.2309: Flags [S], seq 4217907771, win 64860, options [mss 1380,sackOK,TS val 1993389822 ecr 0,nop,wscale 7], length 0
22:55:52.418031 IP 192.168.124.192.55166 > 192.168.65.25.2309: Flags [S], seq 4217907771, win 64860, options [mss 1380,sackOK,TS val 1993389822 ecr 0,nop,wscale 7], length 0
22:55:52.418036 IP 192.168.124.192.55166 > 192.168.65.25.2309: Flags [S], seq 4217907771, win 64860, options [mss 1380,sackOK,TS val 1993389822 ecr 0,nop,wscale 7], length 0
22:55:52.418421 IP 192.168.65.25.2309 > 192.168.124.192.55166: Flags [R.], seq 0, ack 4217907772, win 0, length 0
22:55:52.418421 IP 192.168.65.25.2309 > 192.168.124.192.55166: Flags [R.], seq 0, ack 1, win 0, length 0
22:55:52.418421 IP 192.168.65.25.2309 > 192.168.124.192.55166: Flags [R.], seq 0, ack 1, win 0, length 0
Dus pakketten worden op meerdere interfaces gezien en komen ook terug.
(vier heen en drie terug had ik niet verwacht)
Vervolgens
Op WGserver: sudo tcpdump -ni wg0 port 2309
Op WGclient: telnet host_achter_server 2309
En ook
Op WGserver: sudo tcpdump -ni eth0 port 2309
Op WGclient: telnet host_achter_server 2309
Controleer Wat er aan pakketen voorbij komt. Let op de "masquerading"
Dan die meetingen nog een keer met "telnet -6 host_achter_server 2309"
Alleen de tcpdump output van IPv6 verkeer is relevant
voor "krijg Wireguard niet naar verwachting aan de gang met IPv6"
Groeten
Geert Stappers
--
Silence is hard to parse
Groeten
Geert Stappers
--
Silence is hard to parse
Reply to: