Утечка Surfshark VPN в Linux
Через некоторое время я только что вернулся к этому вопросу и, наконец, решил его. Проблема в том, что OpenWRT использует путь к исходному коду ядра, и дополнительная опция должна быть отключена , а именно CONFIG_PROC_STRIPPED. Он находится в
(make) kernel_menuconfig -> File systems -> Pseudo filesystems -> [ ] Strip non-essential /proc functionality to reduce code size
Это выяснилось при просмотре исправленной версии исходного кода ядра, а не официальной. Спасибо за все усилия, которые вы приложили!
В настоящее время у вас есть 5 nameserverзаписей в /etc/resolv.conf, 2 из которых являются дубликатами. Обычно поддерживается максимум 3 записи. Это может не быть причиной вашей утечки, но это может привести к тому, что ваше разрешение DNS будет вести себя неопределенным образом, что затруднит понимание того, что происходит. Или дополнительные записи могут быть просто проигнорированы... но будут ли система использовать первые 3 или последние 3?
У вас также есть 127.0.0.53, указанный как последняя запись, которая указывает, что systemd-resolved.serviceможет присутствовать; пожалуйста, запустите systemctl status systemd-resolved, чтобы узнать, работает ли он, и если да, resolvectl status, чтобы увидеть, какие DNS-серверы он настроен использовать; он может иметь конфигурацию, отличную от /etc/resolv.conf.
Утечки DNS могут не иметь никакого отношения к тому, что Amazon может обнаружить ваш VPN. Как прокомментировал MariusMatutiae, они могут просто обнаружить, что попытка подключения исходит с IP-адреса, который является известной точкой выхода SurfShark, и отказать в подключении именно из-за этого.
Поскольку /etc/resolvconf/interface-orderсуществует в вашей системе, это означает, что resolvconf, вероятно, установлен. Если это так, ls /run/resolvconf/interfaceдолжен отображать один или несколько файлов, содержащих настройки DNS, полученные через DHCP и/или другие методы настройки. Если при активации SurfShark там появляется еще один файл, возможно, VPN-клиент SurfShark обходит NetworkManager, и вам может потребоваться настроить параметры resolvconf, чтобы он использовал параметры SurfShark исключительно при активном VPN.
Если в /run/resolvconf/interface/есть только один файл с именем NetworkManager, то NetworkManager — это вещь с полным контролем конфигурации DNS на уровне ОС -. В этом случае некоторые диагностические шаги будут:
запустите
nmcli c show, чтобы увидеть имена всех сетевых подключений, известных NetworkManager. Есть ли там SurfShark VPN?если SurfShark есть в списке,запомните его имя, а затем активируйте SurfShark VPN и запустите
nmcli c show "place the actual connection name of SurfShark VPN here" | grep -i dns. Если VPN-подключение SurfShark предоставило какую-либо информацию о DNS-сервере для NetworkManager, эта команда должна указать ее.
Если ни один из этих подходов не покажет никаких настроек DNS, связанных с SurfShark, вам следует проверить, изменится ли содержимое /etc/resolv.confи/или вывод resolvectl statusпри включении/отключении SurfShark VPN. Возможно, VPN-клиент манипулирует одним или обоими из них напрямую.
Если нет очевидных изменений настроек DNS, связанных с включением/отключением VPN где бы то ни было, VPN-клиент SurfShark может перенаправлять любой DNS-трафик на уровне ядра на серверы SurfShark. В зависимости от того, как именно это делается, это может быть или не быть видимым локально; в самом сложном случае вам может понадобиться внешний анализатор трафика, чтобы убедиться, что DNS-трафик действительно перенаправляется на SurfShark.
Также обратите внимание, что современные веб-браузеры могут использовать DNS -поверх -HTTPS или DNS -по -TLS. Эти методы будут обходить всю инфраструктуру разрешения имен хостов на уровне ОС -и устанавливать прямые зашифрованные соединения с поставщиком DoH или DoT. Это может быть то, что обнаруживают ваши тесты на утечку DNS.
(systemd-resolvedтакже может использовать DNS -поверх -TLS, если параметр DNSOverTLSвключен в /etc/systemd/resolved.conf.)