Wireguard peer to peer

[FeronIT]

Situatie is alvolgt. Thuis heb ik een Linux-bak(je) als Wireguard server, zodat ik vanuit overal thuis kan inloggen. Dit werkt allemaal prima, vanaf laptop en telefoon is mijn thuisnetwerk bereikbaar, Pihole voor voor de telefoon werkt.
Wat ik niet werkend krijg is een verbinding tussen 2 peers, bijvoorbeeld laptop en telefoon. Op de een of andere manier zien de peers elkaar gewoonweg niet.
Client-config (voor 1 van de 2, andere is vergelijkbaar, maar dan heeft deze .0.6 bij addres en .0.4 bij [peer]:

code:

[Interface]
PrivateKey = hahah=
Address = 10.9.0.4/32

[Peer]
PublicKey = xaisTstnRvArcNxMMXyePyeMQpe7h3KMkwtnCPD+wEE=
AllowedIPs = 192.168.178.31/32, 40.68.37.158/32, 192.168.178.248/32, 10.9.0.0/24
Endpoint = dns.naar.mijn.huis:443

[Peer]
PublicKey = IWIbkjAOung/NerglrI1sg0YZcu6Iuo+Oz4iUnf/92k=
AllowedIPs = 10.9.0.6/32

Server config:

code:

[Interface]
ListenPort = 443
PrivateKey = haha=

[Peer]
PublicKey = gSO7uEa1wmTV/wLH28RoFoQqfPM6GihCsDaNStdeWho=
AllowedIPs = 10.9.0.2/32

[Peer]
PublicKey = WqCoZFqIUyCTprwJvFUFT602vzoeU4UMOqIJmZaw3mc=
AllowedIPs = 10.9.0.3/32
Endpoint = x.x.137.36:10969

[Peer]
PublicKey = p7lQHqL2NGfqFQO82tgV5gVhbEtOWz2yHmg0m8lD13c=
AllowedIPs = 10.9.0.4/32
Endpoint = x.x.145.146:49322

[Peer]
PublicKey = 68vc9SwL/CXOyYjSBt34UdguvV2RuEMe0Q0lt5HtcEk=
AllowedIPs = 10.9.0.5/32

[Peer]
PublicKey = IWIbkjAOung/NerglrI1sg0YZcu6Iuo+Oz4iUnf/92k=
AllowedIPs = 10.9.0.6/32
Endpoint = 192.168.178.1:63573

De endpointsip adressen worden zelf ingevuld/aangepast door wireguard. Als de clients een vast IP adres zouden hebben, zou ik dat in kunnen vullen bij de [peer] sectie van de andere clients maar omdat ik altijd onderweg ben werkt dit niet.
Heeft iemand enig idee hoe dit aangepast zou kunnen worden (zodat er een verbinding gemaakt kan worden van 10.9.0.4 --> 10.9.0.6 bv)

[BAJansen]

Zoals je het nu probeert in te stellen proberen laptop en telefoon een directe wireguard verbinding tussen elkaar op te zetten. Dit werkt echter niet omdat je geen endpoint kunt invullen. Het beste kun je gewoon de beide apparaten een wireguard verbinding met de server op laten zetten welke het verkeer vervolgens naar de andere client routeert.

[Thralas]

FeronIT schreef op maandag 11 mei 2020 @ 14:11:
Wat ik niet werkend krijg is een verbinding tussen 2 peers, bijvoorbeeld laptop en telefoon. Op de een of andere manier zien de peers elkaar gewoonweg niet.

Tik eens op de client:

ip route get 10.9.0.6

..dan zie je waarom het niet werkt.

Je netmask in de Interface section klopt niet

[FeronIT]

Beide alvast bedankt voor de hulp. @BAJansen, ik heb de extra [peer] weggehaald en toen werkte het deels. Ik zat gisteren bij mijn vriendin thuis en toen kon ik wel verbinden vanaf mijn telefoon <-->laptop. MAAR vanaf mijn machine thuis kon ik niet verbinden naar de laptop. De laptop kan wel verbinden met het 192.168.x.x adres van de server, maar niet met het 10.9..x.x adres...
Het lijkt erop dat ik vanaf mijn thuisnetwerk de clients in 10.9.x.x niet bereikbaar zijn. De vpn server 10.9.0.1 is wel gewoon bereikbaar...
Clients zijn trouwens allemaal Windows machines

[BAJansen]

Ik denk dat het 'm inderdaad zit in wat @Thralas zegt. In de [Interface] sectie moet je de netmask instellen op de netmask van het gehele subnet dat je voor wireguard gebruikt. Afgaande op de andere configuratieregels moet dit /24 zijn. /32 klopt wel wanneer je het bij AllowedIPs gebruikt in de configuratie op de server.

[FeronIT]

Dat biedt helaas geen oplossing. Ik zit nu niet thuis en kan van laptop --> telefoon. "route print" op de laptop geeft (relevantie stuk):
[code]
10.9.0.0 255.255.255.0 On-link 10.9.0.4 5
10.9.0.4 255.255.255.255 On-link 10.9.0.4 261
10.9.0.255 255.255.255.255 On-link 10.9.0.4 261
[code]

En de server geeft bij "route print"

code:

         10.9.0.0    255.255.255.0         On-link          10.9.0.6      5
         10.9.0.4  255.255.255.255         On-link          10.9.0.6      5
         10.9.0.6  255.255.255.255         On-link          10.9.0.6    261
       10.9.0.255  255.255.255.255         On-link          10.9.0.6    261

Wat me allebei correct lijkt.
tracert 10.9.0.3 (telefoon) geeft op de laptop:

code:

Tracing route to 10.9.0.3 over a maximum of 30 hops
  1    20 ms    21 ms    20 ms  10.9.0.1
  2    96 ms    80 ms    73 ms  10.9.0.3

Trace complete.

En vanaf de server:

code:

Tracing route to 10.9.0.3 over a maximum of 30 hops

  1    15 ms    14 ms    14 ms  10.9.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *
enz

Het lijkt wel of de wireguard server deze requesten niet doorstuurt als ze vanaf het interne nerwerk komen.


-- Toevoeging
Ter test heb ik op de server in het lokale netwerk van de VPN server (10.9.0.6) de VPN verbinding afgesloten. Toen was de 10.9.0.1 ook niet meer te bereiken (logisch). Na het toevoegen van de route 10.9.0.0 /255.255.255.0 --> lokaal ip van vpn server, kon ik 10.9.0.1 weer bereiken, maar 10.9.0.4 en .3 nog steeds niet

[ Voor 9% gewijzigd door FeronIT op 12-05-2020 12:08 . Reden: Zonder VPN maar route toegevoegd ]

[Thralas]

Ik kan er zo geen chocola van maken. Je hebt het over een Linux Wireguard 'server', maar vervolgens laat je een 'route print' van een 'server' zien die blijkbaar Windows draait. Zijn dat twee verschillende machines?

Bovendien gebruik je afwisselend een IP of een naam als 'laptop' om naar machines te verwijzen. Wees daar eens consequent in en/of geen een overzicht van <naam>:<ip>.

Om toch nog een pointer te geven: uit je traceroute blijkt dat 10.9.0.1 de weg naar 10.9.0.3 blijkbaar gewoon kent (situatie 1) maar dat in situatie 2 niet werkt: logische stap zou dan zijn om even wat packets te capturen om 10.9.0.1, dan zie je zo waar het misgaat. Desnoods ook even pingen vanaf de telefoon.

Als ik mag gokken: als 10.9.0.1 geen onderscheid maakt, dan zal het het wel 10.9.0.3 zijn die alleen een werkende route naar 'laptop' (??) heeft maar niet naar 'server' (??) - klopt de AllowedIPs daar wel?

Wat ik ook niet snap: 'server' heeft wel degelijk een rare routetabel - waar komen die /32 routes vandaan? Wat heb je dáár met AllowedIPs gedaan? Laat de Wireguard config eens zien van alle devices die je betrekt bij je ping tests..

[FeronIT]

Voor mij was het duidelijk maar daar schiet niemand iets me op. Hier een vereenvoudigd overzicht:

In het kort C en D kunnen met elkaar verbinden en kunnen ook naar A via het 10.9 IP adres. Via de VPN is machine B bereikbaar via 192.168.178.31. Als ik een VPN opzet van B --> A met IP dan B niet naar C of D en andersom ook niet via 10.9.
Machine B C en D hebben een config zoals dit:

code:

[Interface]
PrivateKey = hahah=
Address = 10.9.0.4/32

[Peer]
PublicKey = xaisTstnRvArcNxMMXyePyeMQpe7h3KMkwtnCPD+wEE=
AllowedIPs = 192.168.178.31/32, 40.68.37.158/32, 192.168.178.248/32, 10.9.0.0/24
Endpoint = dns.naar.mijn.huis:443

waarbij elke machine natuurlijk zijn eigen Key en IP adres heeft
En de server heeft als config:

code:

[Interface]
ListenPort = 443
PrivateKey = haha=

[Peer]
PublicKey = gSO7uEa1wmTV/wLH28RoFoQqfPM6GihCsDaNStdeWho=
AllowedIPs = 10.9.0.2/32

[Peer]
PublicKey = WqCoZFqIUyCTprwJvFUFT602vzoeU4UMOqIJmZaw3mc=
AllowedIPs = 10.9.0.3/32
Endpoint = x.x.137.36:10969

[Peer]
PublicKey = p7lQHqL2NGfqFQO82tgV5gVhbEtOWz2yHmg0m8lD13c=
AllowedIPs = 10.9.0.4/32
Endpoint = x.x.145.146:49322

[Peer]
PublicKey = 68vc9SwL/CXOyYjSBt34UdguvV2RuEMe0Q0lt5HtcEk=
AllowedIPs = 10.9.0.5/32

[Peer]
PublicKey = IWIbkjAOung/NerglrI1sg0YZcu6Iuo+Oz4iUnf/92k=
AllowedIPs = 10.9.0.6/32
Endpoint = 192.168.178.1:63573

Het valt me nu op, ben weer thuis, dat de laptop en de telefoon niet kunnen verbinden zoals een (of beide) met het interne netwerk verbonden is. Laat ik beide via de hotspot lopen dan werkt het wel.

[Thralas]

FeronIT schreef op woensdag 13 mei 2020 @ 09:11:
Voor mij was het duidelijk maar daar schiet niemand iets me op. Hier een vereenvoudigd overzicht:

Kijk, dat verduidelijkt enorm:

Als ik een VPN opzet van B --> A met IP dan B niet naar C of D en andersom ook niet via 10.9.

Waarom zou je tussen B en A Wireguard nodig hebben? Ze zitten in hetzelfde netwerk; B zou C en D moeten kunnen adresseren met z'n 192.168.178.x-adres?

Het valt me nu op, ben weer thuis, dat de laptop en de telefoon niet kunnen verbinden zoals een (of beide) met het interne netwerk verbonden is. Laat ik beide via de hotspot lopen dan werkt het wel.

Dat is totaal niet logisch, want je (non-tunnel) connectivity staat los van wat er binnen de tunnel gebeurt.

Ik denk dat je het beste even aan de slag kunt met de opmerkingen uit m'n voorlaatste post. Als alles via 10.9.0.1 loopt is dáár je centrale locatie om wat captures te maken.

[FeronIT]

De Wireguard tussen B en A had ik "uit wanhoop" opgezet. Nadat ik alle probeersels van de server ( en de laptop (D) heb verwijderd, Wireguard op D opnieuw ingericht heb en op de B

code:

    route add 10.9.0.0 mask 255.255.255.0 192.168.178.227

heb uitgevoerd werkt alles.
Dank jullie voor de hulp