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