| 1 |
On Tue, Jun 19, 2018 at 1:02 PM, Grant Taylor |
| 2 |
<gtaylor@×××××××××××××××××××××.net> wrote: |
| 3 |
> On 06/19/2018 05:57 AM, Mick wrote: |
| 4 |
>> |
| 5 |
>> Actually, I don't know if there is a way to set up multiple nameservers |
| 6 |
>> for corresponding name resolution in/out of the tunnel, without using a |
| 7 |
>> domain- specific override as you would with dnsmasq and without leaking DNS |
| 8 |
>> queries to the ISP if you are meant to be querying the tunnel's nameservers. |
| 9 |
> |
| 10 |
> |
| 11 |
> My go to solution would be a local DNS server that decides where different |
| 12 |
> queries go. |
| 13 |
|
| 14 |
That's what NM does. It uses dnsmasq. (Maybe not by default but that's |
| 15 |
how I've got it running.) |
| 16 |
|
| 17 |
>> Yes, those VPN implementations that set up separate routing policy tables |
| 18 |
>> help to keep main and 'VPN' rules separate, which is neat and easy to |
| 19 |
>> maintain. only contains the route from the local VPN subnet to the remote |
| 20 |
>> LAN subnet. |
| 21 |
> |
| 22 |
> |
| 23 |
> Yep. |
| 24 |
> |
| 25 |
>> Quite. The user (or his VPN client via some NM plugin) is meant to add in |
| 26 |
>> this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use |
| 27 |
>> only for resources on this connection" in order to set up a split tunnel. |
| 28 |
>> Then tun0 will only be used to tunnel connections to these subnets. All |
| 29 |
>> other connections to the Internet or local LAN will go outside the tunnel, |
| 30 |
>> using the default local gateway. |
| 31 |
> |
| 32 |
> |
| 33 |
> *nod* |
| 34 |
> |
| 35 |
>> Given Hilco's results I'm surmising an empty table in the NM translates as |
| 36 |
>> 0.0.0.0/0 and all connections end up being routed via the VPN stack, but I |
| 37 |
>> could be wrong because I don't know what he may have entered in this table. |
| 38 |
> |
| 39 |
> Agreed. |
| 40 |
|
| 41 |
Originally, I had nothing in there. Adding the one route (see my email |
| 42 |
on June 7th) makes it working ... mostly. |
| 43 |
|
| 44 |
>> Yes, but leaving the routes table empty ... it seems to tunnel everything |
| 45 |
>> through it ... I don't know without trying it out myself or getting more |
| 46 |
>> info on the settings. |
| 47 |
> |
| 48 |
> |
| 49 |
> Ya. This is unexpected behavior to me. I also don't have a convenient way |
| 50 |
> to reproduce it. |
| 51 |
> |
| 52 |
>> I expect you can set up a subnet here and from this the NM will configure |
| 53 |
>> the route accordingly to make it go through the VPN stack. |
| 54 |
> |
| 55 |
> |
| 56 |
> That is the expected behavior. |
| 57 |
> |
| 58 |
> IMHO the lack of additional routes mean that nothing other than the VPN link |
| 59 |
> itself should be routed through the VPN. |
| 60 |
> |
| 61 |
>> Is this something I can manipulate via resolv.conf on the local PC |
| 62 |
>> (without a local resolver) to make sure DNS searches meant for the VPN stack |
| 63 |
>> are tunneled to the remote nameservers not leaked outside it? |
| 64 |
> |
| 65 |
> |
| 66 |
> I don't know of a good way to do this without a local DNS server. |
| 67 |
> |
| 68 |
>> PS. Thanks for your write up on network namespaces. I'll look into this |
| 69 |
>> in more depth when I get a minute, because I would like to contain/isolate |
| 70 |
>> desktop applications I inherently mistrust - e.g. Skype. |
| 71 |
> |
| 72 |
> |
| 73 |
> You're welcome. I'm glad to hear people benefiting from it. Feel free to |
| 74 |
> reach out if you have any questions. |
| 75 |
|
| 76 |
Thanks for discussing this. At minimum it's quite interesting. :-) |
Archives