nslookup получает SERVFAIL, но не в Windows

На моем рабочем VPN есть DNS-сервер 10.92.131.26, который, похоже, настраивается на моем компьютере, когда я подключаюсь к нашему серверу VPN anyconnect. Когда я выполняю nslookup server на своем рабочем месте с Linux, я получаю SERVFAIL для этого:

;; Получен ответ SERVFAIL от 10.92.131.26, пробую следующий сервер
Сервер:     10.50.177.208
Адрес:      10.50.177.208#53

** сервер не может найти сервер: SERVFAIL

Но когда я открываю виртуальную машину Windows на своем рабочем месте и выполняю nslookup, она успешно работает для того же самого DNS-сервера.

Сервер по умолчанию:  a.company.domain
Адрес: 10.92.131.26

Почему так?

TMI: Почему мне это интересно? На работе наша система MFA накладывает дополнительные ограничения, когда я пытаюсь получить доступ к определенным сайтам компании с моего компьютера под управлением Linux, но я не сталкиваюсь с этими ограничениями, когда запускаю Windows, или когда пытаюсь с виртуальной машины Windows из своей системы Linux. (И я не могу удовлетворить эти дополнительные ограничения, так как ИТ, похоже, не планировала, что кто-то на самом деле столкнется с ними легитимно.)

ИТ говорит мне:

Обычно это связано с проблемой маршрутизации VPN к [нашим] серверам… Попробуйте в Google Chrome, если по-прежнему не работает, так как Firefox иногда использует свои собственные DNS для разрешения адресов, и это может вызвать эту ошибку, в то время как Chrome просто будет работать.

…И действительно, их утверждение кажется обоснованным: в виртуальной машине Windows мои попытки через Chrome удачны, а попытки через Firefox — нет. Тем не менее, мои попытки на моем Linux-хосте вообще не работают.

Я wonder, удастся ли мне выполнить запросы из Linux, если я смогу настроить мой компьютер с Linux на использование 10.92.131.26 в качестве своего DNS-сервера.

Выводы

Обновление: по запросу, вот выводы для netstat -rn на каждой машине. Они довольно длинные, поэтому я просто ссылаюсь на pastebin: на Linux, на Windows

Вот tracert 10.92.131.26 из виртуальной машины Windows:

Отслеживание маршрута до 10.92.131.26 с максимальным количеством 30 переходов

  1    29 мс    27 мс    25 мс  192.168.100.1 
  2    35 мс    31 мс    33 мс  173.36.212.117 
  3    35 мс    34 мс    29 мс  50.216.158.108 
  4    41 мс    35 мс    37 мс  10.92.131.26 

Отслеживание завершено.

Поскольку ситуация становится немного более сложной, чем это можно выразить в комментариях, я использую ответ.

Мы видим две машины:

• Машина с Linux, с IP, вероятно, в 192.168.68.0/24 и шлюзом 192.168.68.1
• Виртуальная машина с Windows, с IP в 10.0.2.0/24 и шлюзом 10.0.2.2.

Сеть 10.0.2.0/24 — это то, что видит виртуальная машина. Теперь нам не хватает немного информации. Я предполагаю, исходя из приведенной выше информации, что виртуальная машина Windows имеет мостовой адаптер, и VPN настроен с хоста Linux. Пожалуйста, подтвердите это.

Если хост Linux предоставляет VPN, он должен иметь возможность достигать шлюза VPN. С помощью ifconfig вы должны увидеть IP-адрес на интерфейсе tun. Вы должны иметь возможность достичь шлюза на VPN-туннеле, иначе вы не сможете маршрутизировать ничего через туннель.

Ваша виртуальная машина Windows видит 10.0.2.2 как шлюз на VPN; следовательно, ваш хост Linux также должен видеть это как маршрутизатор. Поэтому странно, что вы получили недоступную сеть, добавляя конкретный маршрут на вашем Linux-компьютере; вы уверены, что VPN был активен, когда вы пытались добавить маршрут?

В качестве дополнительной отладочной информации tracert от клиента Windows к 10.92.131.26 будет полезен.