From: "Ivan Labáth" <firstname.lastname@example.org> To: lejeczek <email@example.com> Cc: WireGuard mailing list <firstname.lastname@example.org> Subject: Re: wgX iface as slave to a bridge - Linux Date: Tue, 27 Apr 2021 19:49:00 +0000 Message-ID: <YIhqrEPpmsAfVQuM@matrix-dream.net> (raw) In-Reply-To: <email@example.com> Normally, you would use routing (L3) instead of bridging (L2). Conceptually, the connectivity should work about the same, as long as you configure your routes and enable forwarding. Routes need to be configured on the host, not container-only, but if assign a subnet to a bridge, devices can use addresses from it without intervention on the host. If you want roaming addresses, you could do live route updates on your wireguard links and host routing table for a native L3 solution. For a pre-existing automated solution, you can use a some kind of routing service, usually with multiple additional layers of encapsulation, as others have mentioned. Regards, ivan On Sun, Apr 25, 2021 at 02:13:24PM +0100, lejeczek wrote: > On 25/04/2021 13:21, Chriztoffer Hansen wrote: > > What is your use case behind the question? > > > Containers. Simple (but also can be complex too as scales > easily) case where containers would be glued together and be > able to communicate across nodes/hosts via wireguard > tunnel/link. > I'm looking at it from a 'regular' admin standpoint. > Then it'd be just one wiregurard host-to-host link which all > container could utilize, as oppose to separate wireguard > for/in each container. > > many thanks, L.
next prev parent reply other threads:[~2021-04-27 19:52 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 2021-04-24 10:11 ` lejeczek 2021-04-25 5:33 ` Mike O'Connor 2021-04-25 12:21 ` Chriztoffer Hansen 2021-04-25 13:13 ` lejeczek 2021-04-27 19:49 ` Ivan Labáth [this message] 2021-04-25 14:07 ` Roman Mamedov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YIhqrEPpmsAfVQuM@matrix-dream.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Development discussion of WireGuard This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.vuxu.org/wireguard/0 wireguard/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 wireguard wireguard/ https://inbox.vuxu.org/wireguard \ firstname.lastname@example.org public-inbox-index wireguard Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.wireguard AGPL code for this site: git clone https://public-inbox.org/public-inbox.git