Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2020-09-29 at 15:14 -0400, Simo Sorce wrote:
> On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> > On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson <cra@xxxxxxxxxxxx
> > > > 
> > > wrote:
> > > > I think the VPN plugin and VPN server has some input, no?  All
> > > > the
> > > > VPN
> > > > servers I've used send routes to the VPN client to determine
> > > > which
> > > > traffic the client should send via the VPN.  How does that
> > > > interact
> > > > with "use this connection only for resources on its
> > > > network"?  Does
> > > > the user preference take precendence over the VPN server-
> > > > provided
> > > > routes?  What if the VPN server doesn't send any route other
> > > > than
> > > > 0.0.0.0/0?
> > > 
> > > Good question! So good that I don't know the answer. Yes, the
> > > VPN 
> > > plugin indeed gets to make decision based on configuration pushed
> > > by 
> > > the VPN server. The NetworkManager developers are experts in how
> > > these 
> > > settings interact. I *think* the routes provided by the VPN take 
> > > precedence over the checkbox (but only for routing, not for DNS)?
> > > But 
> > > this would certainly be good to document and explore more fully.
> > 
> > If you check "Use this connection..." then NetworkManager will:
> > 
> > (a) never set the default route through the VPN
> > (b) enable split DNS using the VPN-provided (or manually
> > configured)
> > DNS search domains
> > 
> > If you do not check that box, then the VPN will become the default
> > route and all your non-local traffic will be sent to it.
> > 
> > Unfortunately you cannot rely on VPNs to "do the right thing" and
> > always pass back 0.0.0.0 when it wants all the traffic. Plus the
> > user
> > may not want to pass all traffic to the VPN, regardless of what the
> > VPN
> > wants. If you have a corporate laptop and the company wants all
> > your
> > data to go through the VPN, then that laptop is presumably well-
> > managed 
> > and the IT admin will enforce that "Use this connection..." is
> > unchecked.
> 
> Dan,
> I think that unfortunately we cannot conflate "Use this
> connection..."
> to both decide on packet routing and well as DNS routing.

I'm not disagreeing that in a perfect world we'd actually differentiate
two different things.

But it's been this way for 12+ years with NM and (even though I've been
out of NetworkManager for a long time) I've never seen this much
discussion about the topic. Clearly something has worked for the
majority of users for a long, long time.

But perhaps it's time to evaluate improvements.

> There are definitely VPNs where routing allows only to reach internal
> networks and does not allow passthrough, and at the same time VPN
> expects that all DNS resolution happens through the VPN DNS server as
> they selectively override names so some traffic is routed over VPN
> when
> connected but over the regular internet when not (via DNS views).
> 
> I am not saying this is good or bad, it just is, and if we conflate
> this setting we cannot express that setup, which is common (for
> example
> this is the recommended/required configuration for our RH VPN IIRC).

Sure, those setups are not possible with the binary option we have to
day with NM.

> I am also *not* saying we should have two flags that read the same
> but
> just add "for DNS" in one and "for packets" in the other, as most
> users
> would probably be confused.
> 
> In general I would say that for the common case the default should be
> to send queries to the VPN even if there is packet routing split,
> especially if we are thinking about the "café case" I would
> definitely
> trust more the DNS server via the VPN than the one spoofed by the
> café
> broken wifi.

That is the current default, if you leave "Use this connection..."
unchecked. Of course that also sends your traffic to the VPN, which may
not actually work depending on your VPN config.

> Maybe the way to do this is to provide a different switch that say
> something like "I trust this connection to protect my privacy". Then
> if
> you do not want to trust the DNS provided by the VPN for everything,
> you can toggle that one off (default would be on), and that will
> cause
> split DNS as well based on configured domains.

Well... I trust this connection to protect my privacy in some ways, but
not others. I don't think it's that clear-cut.

I honestly don't expect most users to understand or care about the
difference bewteen split IP routing and split DNS routing. But for
those that do, perhaps there should be additional configuration
possible. That's an RFE for the NM team.

Dan

> WDYT ?
> 
> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux