nmcli не желает задействовать синтаксически верный pac-файл

Что я делаю не так?

Ты думаешь что wget учитывает настройки ненужного network-manager-а.

Я не знаю кто их вообще учитывает. Скорее всего только всякий гномософт. Может быть ещё браузеры, если поставить «учитывать системные настройки прокси».

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

Но я очень хочу этот пресловутый system-wide proxy.pac. Что же, эти все 100500 советов из из интернета врут?...

И в браузере настройки прокси - «системные», но без толку.

Ну а как ты думаешь? proxy.pac это скрипт на js. То есть в wget надо засунуть не только поддержку извлечения этого скрипта из network manager-а, но ещё и js-движок чтоб его выполнять? А ещё wget не поддерживает socks-прокси, который может быть прописан в pac.

Настоящих системных настроек прокси не существует.

Есть настроенные (на уровне роутинга ip-пакетов) интерфейсы в ядре - вот они реально system-wide. Есть общесистемная настройка dns в файле /etc/resolv.conf и /etc/nsswitch.conf (их поддержка зашита в libc, но тут уже бывает софт который ей не пользуется и использует что-то своё). Всё остальное это кастомные нестандартные штуки, и чтоб они работали - требуется явно сделанная поддержка от всего софта, который ты используешь.

И в браузере настройки прокси - «системные», но без толку.

Видимо там другие системные имеются ввиду. Подробнее не знаю, никогда этим не пользовался.

Но...

Нетворк-менеджер это же целый системный NetworkManager сервис, и он должен именно что регулировать любой сетевой чих любого софта...

Сомневаюсь я, что wget и прочие утилитки, которые умеют в сеть, так уж прямо и игнорируют этот системный демон.

Нет такого понятия «регулировать любой чих какого-то софта». Это просто ещё одна программа, которая что-то там делает. Единственный софт, который совершенно для всех неизбежен - это ядро, всё остальное запросто игнорируется, и даже не специальными усилиями по игнорированию, а просто отсутствием поддержки. Тот функционал nm, который связан с настройкой интерфейсов, по факту является просто отправкой различных команд ядру. Для прокси у ядра ничего нет.

Сомневаюсь я, что wget и прочие утилитки, которые умеют в сеть, так уж прямо и игнорируют этот системный демон.

Ну и конкретно про wget, а почему собственно оно должно вообще думать про nm? Nm продвигается redhat-ом и gnome-ом, wget к ним никаким боком не относится, он просто скачивает файлы по сети и работает на любых системах вне зависимости от наличия в них тех или иных демонов. Какой-нить gnome download manager (если такой есть или будет), наверно будет всё это учитывать.

Нетворк-менеджер это же целый системный NetworkManager сервис

NM настраивает сеть и предоставляет желающим полезные сервисы. Он никоим образом не вмешивается в работу приложений.

NM настраивает сеть и предоставляет желающим полезные сервисы. Он никоим образом не вмешивается в работу приложений.

wget, curl, браузер - это я использовал просто чтоб посмотреть, работает фишка или нет.

Так и не надо, чтоб он в работу приложений мешался, надо, чтоб он трафик маршрутизировал. Любой трафик, от любых приложений. Это «настройка сети».

Раскидывание трафика по проксям согласно pac-файлу - это «полезный сервис».

Вот я и недоумеваю, почему софт не выполняет заявленный функционал.

Подозреваю, что ему мешает какой-то недоубитый системный сетевой демон, пытающийся работать параллельно...

Nm продвигается redhat-ом и gnome-ом, wget к ним никаким боком не относится, он просто скачивает файлы по сети

Вооот. Он лезет в сеть. Сетевой движ должен регулироваться Network Manager'ом (он же так и нызывается - «сетевой управлятель»). На этом моменте NM и должен осуществить ожидаемый функционал по pac-файлу. А он не осуществляет(

Он по-твоему должен влезть внутрь wget и пропатчить его на лету, добавив туда поддержку себя самого, pac и socks-прокси?

Он, по-моему, должен принять от wget'а сетевой запрос, обработать его, и выдать wget'у сетевой ответ.

Он системный сетевой демон, он так с любой софтиной должен поступать.

Эту задачу изначально у меня сервис systemd-networkd делал - когда я его останавливаю, мне в интернет не пробиться. Ни wget'ом, ни браузером.

Насколько я понимаю, сервис NetworkManager должен делать то же самое. Сервис запускается, но эффекта нет.

NetworkManager это очень враждебная поделка, которая вообще не работает дальше «подключиться к вайфаю»

С чего wget будет слать в nm какие-то запросы? Он их шлёт тому серверу, который ты ему в аргументах указал (откуда скачивать).

сервис systemd-networkd делал - когда я его останавливаю, мне в интернет не пробиться. Ни wget'ом, ни браузером.

Когда ты его останавливал, он перед остановкой слал ядру команду выключить интерфейс значит.

Ещё раз: никакие «сервисы» не занимаются и не могут заниматься поддержкой сети, сеть поддерживается ядром и ядро в этом плане полностью самодостаточно. Всё, что они делают - это отправляют в ядро команды, а сам демон ты можешь сделать kill -9 в любое время (чтоб он не успел испортить настройки перед выходом, ну и как-то предотвратить его повторный запуск systemd) и никуда сеть не пропадёт. Именно поэтому все эти «сетевые демоны» нормальные люди так не любят - это лишняя нашлёпка, не выполняющая практически никаких полезных функций.

Что действительно нужно, так это провести настройку - да, но для этого постоянно запущеный демон не нужен.

надо, чтоб он трафик маршрутизировал

Трафик маршрутизирует ядро.

Это «настройка сети».

Настройка сети — это поднятие интерфейсов, назначение адресов, добавление маршрутов, настройка DNS и т.д. NM это всё делает, следит за сетевыми событиями, предоставляет информационные сервисы.

Раскидывание трафика по проксям согласно pac-файлу - это «полезный сервис».

NM вообще ничего не раскидывает.

Вот я и недоумеваю, почему софт не выполняет заявленный функционал.

Покажи место в документации, где такая функциональность заявлена.

Подозреваю, что ему мешает какой-то недоубитый системный сетевой демон, пытающийся работать параллельно…

Уф.

Он, по-моему, должен принять от wget’а сетевой запрос, обработать его, и выдать wget’у сетевой ответ.

Он системный сетевой демон, он так с любой софтиной должен поступать.

🤦

Эту задачу изначально у меня сервис systemd-networkd делал - когда я его останавливаю, мне в интернет не пробиться.

Потому что он при остановке выполняет деконфигурацию интерфейсов.

Насколько я понимаю, сервис NetworkManager должен делать то же самое.

Он действительно делает примерно то же самое, что и sd-networkd :)

Жесть у вас тут перепись луддитов.

ТС, NM - это единорог🦄, он никуда не вмешивается, он просто конфигуряет штуки. Смотри маршруты, почему трафик не идёт через твою фигню.

Смотри маршруты, почему трафик не идёт через твою фигню

Какие, в жопу, маршруты? Прокси ­это L7, а маршруты — L3. Сборище ыкспертов по сетям, блин.

Убил и пересоздал NM-соединение:

вот я смотрю:

headcrab@piyavking:~ $ nmcli connection up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
headcrab@piyavking:~ $ ping ya.ru
PING ya.ru (5.255.255.242) 56(84) bytes of data.
64 bytes from ya.ru (5.255.255.242): icmp_seq=1 ttl=249 time=6.02 ms
64 bytes from ya.ru (5.255.255.242): icmp_seq=2 ttl=249 time=6.08 ms
64 bytes from ya.ru (5.255.255.242): icmp_seq=3 ttl=249 time=8.79 ms
64 bytes from ya.ru (5.255.255.242): icmp_seq=4 ttl=249 time=6.35 ms
64 bytes from ya.ru (5.255.255.242): icmp_seq=5 ttl=249 time=6.63 ms
^C
--- ya.ru ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 6.024/6.773/8.787/1.029 ms
headcrab@piyavking:~ $ nmcli connection down eth0
Connection 'eth0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
headcrab@piyavking:~ $ ping ya.ru
ping: ya.ru: Temporary failure in name resolution
headcrab@piyavking:~ $ 

Я включаю NM-соединение - есть трафик, выключаю - нет трафика. Значит NM работает штатно, и соединение eth0 в нём тоже работает, но proxy.pac-script, который я туда вбил, и который мне показывает nmcli connection show - не применяется(.

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

Он, по-моему, должен принять от wget’а сетевой запрос, обработать его, и выдать wget’у сетевой ответ. Он системный сетевой демон, он так с любой софтиной должен поступать.

Прокси работает не так.

Может тебе надо privoxy?

Ещё взять tun2socks и завернуть в отдельный неймспейс. В теории должно работать.

Покажи место в документации, где такая функциональность заявлена

В диалоге настройки сетевого подключения «nmcli c edit eth0» есть абсолютно ясные мне и интернету параметры set proxy.pac-script и set proxy.pac-url.

Если это не заявленный функционал осуществления маршрутизации интернет-трафика согласно заранее составленного джава-скрипта - пресловутого pac-файла - , то объясни мне, что это.

Не знаю. Возможно. Но описанный лайфхак, насколько я понимаю, работает у всего интернета. И никакого privoxy не требует....

Прокси работает не так

Я не про работу прокси писал, а про работу системного демона, который в процессе своей деятельности использует прокси.

Это разные вещи.

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

абсолютно ясные мне

После твоих перлов про сетевые демоны, это несерьёзно.

объясни мне, что это

Экспорт настроек для поддерживающих приложений.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-proxy.c

За ссылку спасибо, почитаю.

Я несерьёзно просто кальку с английского сделаю:

это буквально «указать пак-скрипт» и «указать адрес пак-скрипта».

Ты серьёзно пытаешься мне сказать, что эти параметры не имеют к пак-скрипту никакого отношения?

В этом посте перлы мечу не только я, это точно. И, кстати, для экономии времени: то, что я невежа и болван, я и без тебя прекрасно знаю. Я просто хочу присоединиться к толпе невеж и болванов, у которых этот лайфхак почему-то заработал без осложнений - урл дёрнул первый попавшийся подходящий из поиска, например...

урл дёрнул первый попавшийся подходящи

И где там написано, что после этого весь трафик начинает ходить через прокси?

И что же там написано, по-твоему? Я прошерстил гугль по вопросу: все ссылки твердят: установи эти два параметра в nmcli и блаженствуй

Неужели же я должен обмазаться всякими гном-сеттингами, чтобы это работало?...

Неужели же я должен обмазаться всякими гном-сеттингами, чтобы это работало?…

А тебе и гномсеттингс весь трафик в прокси не завернет.

весь трафик в прокси завернуть как раз вроде и не проблема, но я хочу завернуть его в автопрокси, а это другое.

вроде и не проблема

Что, и wget твой через прокси в таком случае пойдет? Кулстори.

Хотя если оно переменную http_proxy выставляет, то wget может как раз и будет работать. Но речь не об этом вообще.

«Системный демон» тоже работает не так.

Ну если эту проксю запихать в какие-нибудь /etc/network -netplan и, как подсказывает Легион, http_proxy не забыть в систему вбить, то да, почему бы этой сказке и не стать былью? Но речь и правда о другом.

Хорошо, объясни тогда невеже и болвану, что поправить в инструкции из интернета, которую я нагуглил. Другие невежи и болваны по ссылкам вроде выше мелькавшей, обещают вслед за этим system-wide autoproxy. Я выполняю инструкцию - у меня system-wide autoproxy не настаёт. Нетворк-менеджер фурычит, соединение у него работает, но proxy параметры этого соединения игнорируются.

Ну вот скажи, какой ещё смысл может быть в параметре соединения, буквально названным «путь к автопрокси-скрипту» или просто у вбитого в параметр «автопрокси-скрипт» этого скрипта в явном виде? Он синтаксис проверит! Он неправильный не съест!

Объясни мне тогда смысл наличия параметров автопрокси-скрипта в конфиге NM-соединения. На что они, по-твоему, влияют? Как система их использует?

Как система их использует?

Никак.

Я выполняю инструкцию - у меня system-wide autoproxy не настаёт

И не настанет. Прокси - целиком и полностью забота программы, никто за нее это не делает и не должен делать. Если программа не умеет читать настройки прокси из nm - то никто ее не заставит. Смирись с этим.

Другие невежи и болваны по ссылкам вроде выше мелькавшей, обещают вслед за этим system-wide autoproxy

Ты их неправильно понял и сделал неверные выводы.

Возможный путь решения (privoxy + обвязка) я посоветовал выше, возможно есть ещё способы.

А как ещё их понимать? Я б послушал, серьёзно. Привокси, буду разбираться, спасибо.

возможно есть ещё способы

Есть ещё WPAD. Но это отдельный адок. Вроде задача практически с трёх слов - system-wide pac-file. Автопрокси, влияющий на всё. И такой гимор!

Прокси - целиком и полностью забота программы

Здрасьте, приплыли. «proxychains4 программа» - и программа прекрасно шуршит через прокси, какая бы программа ни была. Даже Айседора Дункан не раз тут помянутый wget.

Только tcp и не всегда работает.

УМВР

Чтобы автонастройка прокси работала в определённой программе, программа должна поддерживать:

1. PAC-файлы, т.е. иметь в себе встроенный интерпретатор JS
2. NetworkManager — получать данные о PAC-файле из его настроек

В Linux нет какого-то универсального слоя работы с сетью, как wininet, поэтому PAC-файлы работают только в браузерах, по-сути.

Это грустно(

https://git.kernel.org/pub/scm/network/connman/pacrunner.git

Освобождает от требования JS-движка.