From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: raulbe@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id bcce5b41 for ; Mon, 10 Jul 2017 14:56:49 +0000 (UTC) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8fa4e956 for ; Mon, 10 Jul 2017 14:56:49 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id p21so76270823qke.3 for ; Mon, 10 Jul 2017 08:14:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170710024322.GA31153@zx2c4.com> References: <20170710024322.GA31153@zx2c4.com> From: raul Date: Mon, 10 Jul 2017 20:44:56 +0530 Message-ID: Subject: Re: Early Feedback on Container Networking, Resilience, Json Config and AcceptedIPs To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="001a1142df1ccbf56f0553f80bf9" Cc: wireguard@lists.zx2c4.com List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a1142df1ccbf56f0553f80bf9 Content-Type: text/plain; charset="UTF-8" Hi Jason, So: things won't be too big of a pain, and at some point, there won't be > any possibility of pains. > Great to hear that! What precisely are you doing that you think might be easier with JSON? I did look at wg-json. I was wondering more about /etc/wireguard/*.conf and the possibility of using json config there. I am trying to parse wgX.conf so that we can quickly add and remove peers and subnets. Currently I am dumping it into a python dict keyed with the pubkeys In this sense, on outgoing, it's sort of like a routing table. on incoming, > it's sort of like an IP access control list. That's a pretty succinct way of putting it. It does sounds simple put that way. You don't have to run WireGuard in a star topology. You can do full mesh > if you want, or whatever other topology. One interface can have multiple > peers, so you can connect things together any which way you like. > As Jonathan mentioned he is running a mesh. And it does open up possibilities in terms of access control that I haven't fully considered. But how do we scale a mesh? For a number of hosts lets say 20+ with 20 container subnets or more to share, one would imagine managing a peer to peer configuration as the network scales up and down can become a chore. A client server with let's say a /16 shared may be more feasible, as then all the client's acceptedIPs can be the single /16 subnet, while the individual client subnets are added to the server for routing as they are added. I will think about this some more. Once again this is really impressive and valuable. Thanks! Raul --001a1142df1ccbf56f0553f80bf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jason,


So: things won't be too big of a pain, and at some point, there won'= ;t be
any possibility of pains.
=C2=A0

<= div>Great to hear that!


What precisely are you doing that you think might be easier with= JSON?


I did look at wg-json. I was wondering more= about /etc/wireguard/*.conf and the possibility of using json config there= . I am trying to parse wgX.conf so that we can quickly add and remove peers= and subnets. Currently I am dumping it into a python dict keyed with the p= ubkeys


In thi= s sense, on outgoing, it's sort of like a routing table. on incoming, i= t's sort of like an IP access control list.
=C2=A0

=C2=A0That's a pretty succinct way of putting it.= It does sounds simple put that way.


You don't have to run WireGuard in a star topology. You can do f= ull mesh
if you want, or whatever other topology. One interface can have multiple peers, so you can connect things together any which way you like.

=C2=A0
As Jonathan mentioned he is running a = mesh. And it does open up possibilities in terms of access control that I h= aven't fully considered. But how do we scale a mesh? For a number of ho= sts lets say 20+ with 20 container subnets or more to share, one would imag= ine managing a peer to peer configuration as the network scales up and down= can become a chore.

A client server with let's say a /16 share= d may be more feasible, as then all the client's acceptedIPs can be the= single /16 subnet, while the individual client subnets are added to the se= rver for routing as they are added. I will think about this some more.
<= br>
Once again this is really impressive and valuable.
<= div>
Thanks!
Raul



--001a1142df1ccbf56f0553f80bf9--