All of lore.kernel.org
 help / color / mirror / Atom feed
* Sharing peer data
@ 2018-04-14 19:16 Luiz Angelo Daros de Luca
  2018-04-14 23:15 ` Jason A. Donenfeld
  0 siblings, 1 reply; 5+ messages in thread
From: Luiz Angelo Daros de Luca @ 2018-04-14 19:16 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hello,

In a setup node A <> node B, node A <> node C, C might talk to B passing
through A. Would it be possible that A could share B and C info (ip and
pubkey) in other to them to talk to each other directly? It would be
similar to ip redirect. Node A must be trusted by both for that.

Regards,
-- 

Luiz Angelo Daros de Luca
luizluca@gmail.com

[-- Attachment #2: Type: text/html, Size: 572 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sharing peer data
  2018-04-14 19:16 Sharing peer data Luiz Angelo Daros de Luca
@ 2018-04-14 23:15 ` Jason A. Donenfeld
  2018-04-15  3:18   ` Luiz Angelo Daros de Luca
  2018-04-15 10:08   ` ST
  0 siblings, 2 replies; 5+ messages in thread
From: Jason A. Donenfeld @ 2018-04-14 23:15 UTC (permalink / raw)
  To: Luiz Angelo Daros de Luca; +Cc: WireGuard mailing list

Hi Luiz,

You could indeed arrange for something like this, either directly --
if both IPs are accessible or if A is able to punch a hole -- or
relayed, if you can't establish a direct session. This is similar to
what Tinc does. Namely, this falls in the category of, "making a full
mesh from a partial mesh." I say, "you could", because currently this
is something people are generally doing manually with WireGuard.
However, there's a GSoC project for making a minimal mesh networking
utility for WireGuard, which I hope pans out, and maybe even Tinc
integration. So we'll see what happens in this space.

Jason

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sharing peer data
  2018-04-14 23:15 ` Jason A. Donenfeld
@ 2018-04-15  3:18   ` Luiz Angelo Daros de Luca
  2018-04-15 10:08   ` ST
  1 sibling, 0 replies; 5+ messages in thread
From: Luiz Angelo Daros de Luca @ 2018-04-15  3:18 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Thanks Jason,

Yes, something very similar to tinc. I imagine having two or more
static/known peers (redundancy) configured on every node. Once connected,
they discover the others.

It's good to know there is a GSoC for something like it.
-- 

Luiz Angelo Daros de Luca
luizluca@gmail.com

[-- Attachment #2: Type: text/html, Size: 506 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sharing peer data
  2018-04-14 23:15 ` Jason A. Donenfeld
  2018-04-15  3:18   ` Luiz Angelo Daros de Luca
@ 2018-04-15 10:08   ` ST
  2018-04-16  1:47     ` Luiz Angelo Daros de Luca
  1 sibling, 1 reply; 5+ messages in thread
From: ST @ 2018-04-15 10:08 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

On Sun, 2018-04-15 at 01:15 +0200, Jason A. Donenfeld wrote:
> Hi Luiz,
> 
> You could indeed arrange for something like this, either directly --
> if both IPs are accessible 

Which IPs do you mean here? Public IPs or private VPN IPs (i.e. those
defined within WireGuard configuration)? I got an idea how to do that
using SFTP... I'll write about it in a separate email...

Just one question: let's assume B and C got the required information
about each other's IPs/public keys from A. Will they now communicate
directly without relying on A in whatever way?... It is important to
know for the case when A is a server with metered paid traffic... Will
the communication between B and C affect the traffic of A or not?

Thank you!

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Sharing peer data
  2018-04-15 10:08   ` ST
@ 2018-04-16  1:47     ` Luiz Angelo Daros de Luca
  0 siblings, 0 replies; 5+ messages in thread
From: Luiz Angelo Daros de Luca @ 2018-04-16  1:47 UTC (permalink / raw)
  To: ST; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

>
> Just one question: let's assume B and C got the required information
> about each other's IPs/public keys from A. Will they now communicate
> directly without relying on A in whatever way?... It is important to
> know for the case when A is a server with metered paid traffic... Will
> the communication between B and C affect the traffic of A or not?


In my point of view, it is something that all nodes must agree to accept (a
non-default option). Of course, if node A wants to measure traffic, it
ahould not allow it, forcing all traffic from B to C to pass through it.

I imagine something like:

Node A: hey node B, I noticed that you are sending traffic to another
remote node (node C). You can continue to send traffic through me but, in
parallel, could you please try to contact node C directly? It is currently
using ip x.x.x.x and its pubkey is aaaaaa.
-- 

Luiz Angelo Daros de Luca
luizluca@gmail.com

[-- Attachment #2: Type: text/html, Size: 1347 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-04-16  1:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-04-14 19:16 Sharing peer data Luiz Angelo Daros de Luca
2018-04-14 23:15 ` Jason A. Donenfeld
2018-04-15  3:18   ` Luiz Angelo Daros de Luca
2018-04-15 10:08   ` ST
2018-04-16  1:47     ` Luiz Angelo Daros de Luca

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.