[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: krijg Wireguard niet naar verwachting aan de gang met IPv6



On Sun, Sep 19, 2021 at 01:22:20PM +0200, Paul van der Vlis wrote:
> Op 19-09-2021 om 11:17 schreef Gijs Hillenius:
> > 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!
> 
> Je bedoeld: je ontvangt geen pakket terug. Dat is wat anders!
> 
> Het kan bijvoorbeeld zijn dat er een firewall op de server staat die het
> inkomende of uitgaande verkeer tegen houdt.

Ja, dat kan.
 
> Wat ik zou doen is de firewall op de server op loggen zetten, zodat je kunt
> zien wat er wordt tegen gehouden.

We weten echter niet of "firewall" het obstakel is.

 
> Ook op de client kan de firewall je verkeer tegenhouden.

Ik ken eigenlijk geen firewall die eigen uitgaand verkeer
niet toestaat om terug te keren.


> Als volgende stap zou je die kunnen laten loggen.
> 
> > 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
> 
> Dit lijkt me goed.

De host-route, herkenbaar aan de H, vind ik wat vreemd.


 
> > 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

Dus twee maal netwerk 2a01:4f8:200:546b::/64   


> > 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

Opnieuw dubbel, deze keer "slash honderdachtentwintig",  /128,    vreemd ...


> > hillenius.com/128              [::]                       Un   0   5     0 eth0
> > 2a01:4f8:200:546b:0:9e15:9e15:1/128 [::]                       Un   0   2     0 wg0

Twee keer  /128   die ik wel begrijp.


> > 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
> 
> Ik concentreer me even op IPv4.
> 
> > 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
> 
> Dit lijkt me ook goed.
> 
> Ik kijk wat vreemd aan tegen de rechte haken die je gebruikt rond het IP van
> Endpoint.

Zie https://lists.debian.org/debian-user-dutch/2021/09/msg00020.html

> Ik gebruik zelf een naam zonder rechte haken.
> 
> 
> #server
> ------
> [Interface]
> Address = 10.10.10.1/24
> ListenPort = 443



> PrivateKey = blabla
> 
> [Peer]
> PublicKey = blabla
> AllowedIPs = 10.10.10.2/32
> ------
> 
> #client
> -----
> [Interface]
> Address = 10.10.10.2/24
> # dit staat bij mij uit, maar bij andere gebruikers aan:
> # DNS = 192.168.16.2, domein.local
> PrivateKey = blabla
> 
> [Peer]
> PublicKey = blabla
> AllowedIPs = 10.10.10.0/24, 192.168.16.0/24, 192.168.208.0/24
> Endpoint = vpn.domein.nl:443
> PersistentKeepalive = 25
> -----
> 
> Ook verkeer naar b.v. 192.168.16.33 gaat zo door de VPN.
> In werkelijkheid zijn er veel meer [Peer] definities op de server.
> 
> Groeten,
> Paul
 

Groeten
Geert Stappers
-- 
Silence is hard to parse


Reply to: