1 |
On 8/13/20 4:03 PM, Grant Edwards wrote: |
2 |
> I'm not sure what "go out of your way" means in this context. I assume |
3 |
> I'd create a network namespace for Plex, and then use either macvlan |
4 |
> or ipvlan to share one of the physical interaces between the root |
5 |
> namespace and the Plex namespace. |
6 |
|
7 |
I've found that MACVLAN / MACVTAP, and I assume IPVLAN / IPVTAP, have a |
8 |
bit of a flaw. Specifically, I've not been able to put an IP address on |
9 |
the parent interface, e.g. eth1, and get communications between the host |
10 |
and the {MAC,IP}V{LAN,TAP} clients. To get such host to |
11 |
{MAC,IP}V{LAN,TAP} communications, I've had to add an additional |
12 |
{MAC,IP}V{LAN,TAP} and put the host's IP on that. |
13 |
|
14 |
Conversely, I've been able to use traditional bridging or OVS to |
15 |
accomplish this. |
16 |
|
17 |
> I'd like the 'lo' interfaces to be shared as well, but I'm not sure |
18 |
> that's possible. |
19 |
|
20 |
I think that's contrary to how network namespaces work. |
21 |
|
22 |
I've got a colleague at work who has written a proxy program that will |
23 |
listen on a port in one network namespace and connect to the same (or |
24 |
optionally different) port in another network namespace. It sort of |
25 |
behaves much like OpenSSH's local port forwarding going from one network |
26 |
namespace to another network namespace with the service running. |
27 |
Somewhat akin to SSH agent forwarding. |
28 |
|
29 |
|
30 |
|
31 |
-- |
32 |
Grant. . . . |
33 |
unix || die |