Я пытаюсь понять, как работает маршрутизация DNS с/без vpn. У меня есть следующий интерфейс.
Wireless LAN adapter Wi-Fi:
DNS Servers . . . . . . . . . . . : 192.168.40.1
nslookup в этом случае работает:
nslookup google.com 192.168.40.1
Address: 192.168.40.1
Non-authoritative answer:
Name: google.com
Если у меня запущен VPN, я получаю другой интерфейс, и DNS-запросы по умолчанию направляются на него.
Unknown adapter Mullvad:
DNS Servers . . . . . . . . . . . : 10.8.0.1
Однако если я теперь попытаюсь сделать запрос DNS на другом интерфейсе, он не пройдет.
nslookup google.com 192.168.40.1
DNS request timed out.
но я могу без проблем отправлять запросы на свои локальные серверы.
curl 192.168.40.22:8080
OK
Как это работает? IP-трафик проходит, но DNS блокируется? Я понимаю, что VPN обычно настраивают правила таблицы маршрутизации, чтобы направлять трафик на свой шлюз. Но это для IP правильно? DNS не должен быть затронут этим. Какой базовый механизм стоит за этим? Есть ли способ принудительно отправлять DNS-запросы на другой интерфейс?
Это работает на Windows, но я предполагаю, что это будет работать и на Linux.
решение1
Упрощенный ответ:
В зависимости от настроек VPN-клиент пропускает весь трафик через виртуальный интерфейс,то есть, Он блокирует трафик в локальной сети. Поскольку локального трафика нет, клиент может использовать разные серверы имен, когда туннель активен.
решение2
Я скучаю поipconfigВ любом случае, в обоих сценариях получается, что без VPN вы получаете IP и серверы имен по умолчанию от локального DCHPd, поэтому ваш компьютер может запрашивать разрешение DSN на локальном сервере имен.
После подключения к VPN создается впечатление, что вы получили другой IP-адрес от VPN-сервера и установили маршрут по умолчанию на VPN-интерфейс. Это означает, что весь трафик проходит через VPN, который, вероятно, не может достичь вашего локального сервера имен.
Чтобы решить эту проблему, вы можете использовать глобальный DNS-сервер (например, 8.8.8.8 или 1.1.1.1), к которому можно получить доступ из обеих сетей.