Debian: Pedido de servidores DNS ao usar VPN

3

Meu notebook recebe seus servidores DNS via DHCP.

Quando inicio uma sessão VPN (pptp, gerenciei meu networkmanager), os servidores DNS recebidos dessa sessão VPN são consultados primeiro.

Gostaria de usar os servidores DNS da VPN somente se meu DNS principal retornar NXDOMAIN.

Como faço isso?

/etc/resolv.conf

# Generated by NetworkManager
domain homesweethome
search homesweethome
nameserver 192.168.1.1

traceroute 8.8.8.8 quando conectado a VPN

 1  sheldon.homesweethome (192.168.1.1)  0.714 ms  0.880 ms  1.001 ms
 2  * * *
 3  172.30.12.49 (172.30.12.49)  13.693 ms  14.181 ms  14.316 ms
 4  84.116.191.49 (84.116.191.49)  15.067 ms  15.199 ms  15.336 ms
 5  * * *
 6  216.239.56.106 (216.239.56.106)  22.409 ms  14.401 ms  14.447 ms
 7  216.239.57.192 (216.239.57.192)  14.414 ms 216.239.57.188 (216.239.57.188)  22.950 ms 216.239.57.127 (216.239.57.127)  22.846 ms
 8  66.249.95.23 (66.249.95.23)  22.992 ms 66.249.95.39 (66.249.95.39)  23.832 ms 209.85.253.216 (209.85.253.216)  23.556 ms
 9  74.125.37.150 (74.125.37.150)  28.828 ms  28.571 ms  24.278 ms
10  209.85.246.160 (209.85.246.160)  21.975 ms 216.239.42.98 (216.239.42.98)  21.467 ms 216.239.51.207 (216.239.51.207)  23.297 ms
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  22.556 ms  23.421 ms  23.266 ms

traceroute 8.8.8.8 quando não está conectado

 1  sheldon.homesweethome (192.168.1.1)  0.651 ms  3.098 ms  4.927 ms
 2  * * *
 3  172.30.12.49 (172.30.12.49)  16.504 ms  16.791 ms  17.125 ms
 4  84.116.191.49 (84.116.191.49)  17.186 ms  23.111 ms  23.277 ms
 5  * * *
 6  216.239.56.22 (216.239.56.22)  25.766 ms 216.239.56.178 (216.239.56.178)  17.433 ms 216.239.56.22 (216.239.56.22)  18.432 ms
 7  216.239.57.182 (216.239.57.182)  17.526 ms  14.840 ms 216.239.57.190 (216.239.57.190)  15.748 ms
 8  209.85.253.216 (209.85.253.216)  17.661 ms 66.249.95.39 (66.249.95.39)  17.786 ms  18.213 ms
 9  74.125.37.154 (74.125.37.154)  29.039 ms 74.125.37.103 (74.125.37.103)  28.667 ms 74.125.37.97 (74.125.37.97)  25.168 ms
10  209.85.250.165 (209.85.250.165)  25.532 ms  24.350 ms 216.239.51.149 (216.239.51.149)  25.776 ms
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  22.513 ms  22.979 ms  22.484 ms

/etc/ppp/resolv.conf

nameserver 10.11.10.101
nameserver 10.11.10.102
    
por Jan 10.02.2016 / 12:58

1 resposta

2

O acesso de recursos internos ao ter uma conexão VPN ativa só deve funcionar se você tiver o Split Tunneling ativo.

Dividir o tunelamento

Split tunneling is a computer networking concept which allows a mobile user to access dissimilar security domains like a public network (e.g., the Internet) and a local LAN or WAN at the same time, using the same or different network connections.

Com o tunelamento dividido, é uma questão do servidor de pedidos DNS ter o DNS da VPN no topo e os servidores DNS normais no final. Pelo funcionamento interno normal do DNS, os principais que não atenderem ao pedido passarão para os inferiores.

Parece que você já dividiu o encapsulamento ativo por nossa depuração, então, como uma solução rápida, é uma questão de adicionar seu DNS a /etc/ppp/resolv.conf .

Quanto a ter uma abordagem mais genérica, esta página fala sobre o uso do dnsmasq.

Roteamento de DNS após conexão PPTP

A solution would be to run a local DNS server that can forward queries to other DNS servers based on subdomain/domain.

Ubuntu's network-manager already runs a local DNS server (dnsmasq-base) however the required options are not available so disable it then install and configure the full dnsmasq package as follows:

1) Comment out dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf
2) Restart network-manager: sudo service network-manager restart
3) Install dnsmasq package: sudo apt-get install dnsmasq
4) Edit /etc/dnsmasq.conf and add: address=/.mywork/VPN_DNS_IP address=/#/INTERNET_DNS_IP
5) Restart dnsmaq: sudo service dnsmasq restart

Também deixarei aqui um link sobre segurança com protocolos VPN.

PPTP VS L2TP / IPSEC VS OPENVPN

The Microsoft implementation of PPTP has serious security vulnerabilities. MSCHAP-v2 is vulnerable to dictionary attack and the RC4 algorithm is subject to a bit-flipping attack. Microsoft strongly recommends upgrading to IPSec where confidentiality is a concern.

    
por 10.02.2016 / 13:21

Tags