Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
On Sun, Sep 19, 2021 at 11:17:47AM +0200, Gijs Hillenius wrote:
> On 19 September wilden Paul en Geert
> >> Doe ook ping testen binnen het VPN.
> >> En dan gewoon het Virtual Private Network gebruiken.
> >
> > Precies, ping eens naar 10.93.15.1 en 2a01:4f8:200:546b:0:9e15:9e15:1 .
>
> Er gaat geen pakket de deur uit!
>
> ping 10.93.15.1
> PING 10.93.15.1 (10.93.15.1) 56(84) bytes of data.
> ^C
> --- 10.93.15.1 ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 1011ms
>
> root@inauditus:~# ping4 10.93.15.1
> PING 10.93.15.1 (10.93.15.1) 56(84) bytes of data.
> ^C
> --- 10.93.15.1 ping statistics ---
> 9 packets transmitted, 0 received, 100% packet loss, time 8178ms
>
> root@inauditus:~# ping6 2a01:4f8:200:546b:0:9e15:9e15:1
> PING 2a01:4f8:200:546b:0:9e15:9e15:1(2a01:4f8:200:546b:0:9e15:9e15:1) 56 data bytes
> ^C
> --- 2a01:4f8:200:546b:0:9e15:9e15:1 ping statistics ---
> 5 packets transmitted, 0 received, 100% packet loss, time 4075ms
>
>
>
> onderstaande is met wg0 up op client en server
>
>
> op de server
>
> route -n
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 10.219.216.14 0.0.0.0 UG 0 0 0 eth0
> 10.93.15.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
> 10.219.216.14 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
>
> route -A inet6
>
> Kernel IPv6 routing table
> Destination Next Hop Flag Met Ref Use If
> localhost/128 [::] U 256 2 0 lo
> 2a01:4f8:200:546b::/64 [::] U 256 1 0 eth0
> 2a01:4f8:200:546b::/64 [::] U 256 1 0 wg0
> fe80::/64 [::] U 256 1 0 eth0
> [::]/0 2a01:4f8:200:546b::3 UGH 1024 3 0 eth0
> localhost/128 [::] Un 0 4 0 lo
> 2a01:4f8:200:546b::/128 [::] Un 0 3 0 eth0
> 2a01:4f8:200:546b::/128 [::] Un 0 3 0 wg0
> hillenius.com/128 [::] Un 0 5 0 eth0
> 2a01:4f8:200:546b:0:9e15:9e15:1/128 [::] Un 0 2 0 wg0
> fe80::/128 [::] Un 0 3 0 eth0
> fe80::5054:ff:fe49:7447/128 [::] Un 0 4 0 eth0
> ff00::/8 [::] U 256 3 0 eth0
> ff00::/8 [::] U 256 1 0 wg0
> [::]/0 [::] !n -1 1 0 lo
>
>
> op de client
>
> route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 192.168.1.1 0.0.0.0 UG 600 0 0 wlp0s20f3
> 10.93.15.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp0s20f3
> 192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp0s20f3
>
>
> route -A inet6
> Kernel IPv6 routing table
> Destination Next Hop Flag Met Ref Use If
> [::]/0 [::] U 1024 9 0 wg0
> localhost/128 [::] U 256 2 0 lo
> 2a01:4f8:200:546b::/64 [::] U 256 4 0 wg0
> 2a02:a03f:6b2d:b400::/64 [::] U 600 1 0 wlp0s20f3
> 2a02:a03f:6b2d:b400::/56 _gateway UG 600 2 0 wlp0s20f3
> fe80::/64 [::] U 600 1 0 wlp0s20f3
> [::]/0 _gateway UG 600 9 0 wlp0s20f3
> localhost/128 [::] Un 0 11 0 lo
> inauditus/128 [::] Un 0 2 0 wg0
> inauditus/128 [::] Un 0 4 0 wlp0s20f3
> inauditus/128 [::] Un 0 3 0 wlp0s20f3
> ff00::/8 [::] U 256 10 0 wlp0s20f3
> ff00::/8 [::] U 256 1 0 wg0
> [::]/0 [::] !n -1 1 0 lo
>
Ik ben het een beetje kwijt.
En ik heb daar aan meegeholpen.
Wil daarom ook meehelpen om het goed te krijgen.
Wat "goed" deze keer betekent, is waarschijnlijk het echte probleem.
Zo heb ik de verwachting dat een VPN als VPN gebruikt wordt.
Toen ik een bericht zag dat VPN-client bij een IPv6 host **buiten** het
VPN moest kunnen, was er van mij het idee in het IPv6-adres-blok van de
server te gaan zitten.
| [1]
|
| Iets om te proberen:
| Onder 2a01:4f8:200:546b/64 bijvoorbeeld 2a01:4f8:200:546b:4653/80
| hangen. Aan wireguard server geef je 2a01:4f8:200:546b:4653::1
| Aan wireguard client geef je 2a01:4f8:200:546b:4653::2 [2]
|
|
| [1] Tja, de verwachtingen van een "VPN"
| [2] In het oorspronkelijke bericht stond o.a.
| Gebruik ik de verkeerde IPv6 reeks?
Momenteel zijn we dus verder van huis dan aan het begin.
Laten we een keuze maken.
Optie 1, jumphost.
We zijn onderweg met een client computer.
En kunnen/mogen niet bij gewenste bestemming.
Door via een tussen-station te gaan, kan/mag
bestemming wel bereikt worden. Gangbare naam
voor zo een tussenstation is jumphost.
Optie 2, VPN.
We zijn onderweg met client computer.
En kunnen/mogen niet bij gewenste bestemming.
Als we in hetzelfde netwerk zijn als bestemming,
dan is er de beperking niet. Met behulp van VPN
zetten we alles in hetzelfde netwerk.
Optie 3, anders
We kunnen vooruit en we komen vanzelf een volgend obstakel tegen.
Bij optie jumphost is geen "wireguard" nodig.
Bij optie VPN kunnen we wireguard gebruiken.
Dan voor 2a01:4f8:200:546b:4653/80 wat anders kiezen.
ULA, Unique Local Address, [3], begint met fc00::/7
De fdab:9205:cf78:f608:: uit het begin van deze thread voldoet daaraan.
Groeten
Geert Stappers
[3] https://en.wikipedia.org/wiki/Unique_local_address
P.S.
Vermijdt `route` commando en gebruik `ip route` en `ip -6 route`.
Want commando `ip` heeft wel de ontwikkelingen van de Linux kernel
gevolgd. ( `route` is in ontwikkeling achtergebleven)
--
Silence is hard to parse
Reply to: