Не удается разрешить пользовательские домены, когда VPN работает

Я только что обновился до 12.04 с 11.10, и теперь я не могу разрешить пользовательские домены через VPN (например, * .dev.local ). Он работал великолепно до обновления.

И мой /etc/resolv.conf, и route -n выглядят точно так же, как и до обновления.

Я использую OpenVPN, и он подключается без проблем.

вывод из пинга

$ ping example.dev.local
ping: unknown host example.dev.local

resolv.conf

nameserver 172.16.1.4
nameserver 172.16.1.5
nameserver 10.4.180.250
search office.local corp.local

маршрут -n

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.4.180.250    0.0.0.0         UG    0      0        0 eth0
10.4.180.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.61.80.0      172.28.0.254    255.255.255.128 UG    0      0        0 tap0
10.61.80.128    172.28.0.249    255.255.255.128 UG    0      0        0 tap0
10.200.2.126    172.28.0.249    255.255.255.255 UGH   0      0        0 tap0
81.92.65.52     172.28.0.249    255.255.255.255 UGH   0      0        0 tap0
81.92.71.128    172.28.0.249    255.255.255.192 UG    0      0        0 tap0
81.92.72.128    172.28.0.254    255.255.255.224 UG    0      0        0 tap0
81.92.72.160    172.28.0.249    255.255.255.224 UG    0      0        0 tap0
172.16.0.0      172.28.0.1      255.255.248.0   UG    0      0        0 tap0
172.28.0.0      0.0.0.0         255.255.254.0   U     0      0        0 tap0

Фрагмент из /etc/dhcp3/dhclient.conf (22-25 является оригинальным до обновления, ранее по некоторым причинам, о которых я забыл, пришлось удалить серверы доменных имен)

 22 #request subnet-mask, broadcast-address, time-offset, routers,
 23 #       domain-name, domain-name-servers, domain-search, host-name,
 24 #       netbios-name-servers, netbios-scope, interface-mtu,
 25 #       rfc3442-classless-static-routes, ntp-servers;
 26 
 27 prepend domain-name-servers 192.168.1.1;
 28 request subnet-mask, broadcast-address, time-offset, routers,
 29         domain-name, domain-search, host-name,
 30         netbios-name-servers, netbios-scope, interface-mtu,
 31         rfc3442-classless-static-routes, ntp-servers;

Любая помощь будет принята с благодарностью.

Изменить: я могу добраться до хостов по IP, это просто разрешение, которое не работает.

Может быть, посмотрите /etc/nsswitch.conf. У меня была проблема с Ubuntu, не признающим имена с моего локального DNS-сервера, независимо от /etc/resolve.confнастроек. Slackware работал нормально, поэтому я изменил мой, чтобы быть немного ближе к версии Slackware:

hosts:          files dns mdns4_minimal mdns4 [NOTFOUND=return]

Я думаю, что мне пришлось перенести материал dns и mdns4 ... возможно, там была звездочка ( *), которая помешала дальнейшему поиску.

Проблема в том, что VPN использует в localкачестве домена верхнего уровня, который также используется avahi для mdns.

Документация авахи

http://avahi.org/wiki/AvahiAndUnicastDotLocal

говорит

If you come across a network where .local is a unicast
DNS domain, please contact the local administrator
and ask him to move his DNS zone to a different domain.
If this is not possible, we recommend not to use Avahi
in such a network at all.

Весьма вероятно, что когда вы используете VPN, ваш сервер имен и / или поисковые домены отличаются. Если вы используете nslookup для настраиваемого DNS-имени, к которому вы пытаетесь обратиться, вам нужно увидеть сервер имен, к которому вы обращаетесь. Если адрес отличается, вы пытаетесь разрешить имя на сервере, где его нет в списке.

например...

munich:~ jeremy$ nslookup bangkok
Server:     192.168.1.2
Address:    192.168.1.2#53

Name:   bangkok.home.com
Address: 192.168.1.5

Бангкок - это собственное DNS-имя для ящика в моей домашней сети. Если бы я подключался к VPN своих компаний, я бы сначала нажал на их сервер имен, чтобы я мог вращать их пользовательские имена, такие как svn и wiki. У нас работает несколько имен, каждый со своим доменом, таким как foo.work.com, bar.work.com и work.com. Если в качестве моего первого домена указан bar.work.com, и я пытаюсь связаться с svn.foo.work.com только с помощью svn, поиск не сможет разрешиться по ip-адресу, поскольку он будет искать svn.bar.work.com. ,