Настройка прокси для WSL (Ubuntu)

  • Tutorial

В данной статье будут рассмотрены настройки для корректной работы в WSL из-под прокси для:


  • apt-get
  • curl
  • wget
  • git
  • npm

Apt-get


Примечание здесь и далее используются следующие данные для прокси:


  • host: http://proxy.example.com
  • port: 7777
  • login: user@example.com
  • password: somePassword

Для корректной работы apt-get необходимо в файл /etc/apt/apt.conf.d/proxy.conf добавить строку Acquire::http::Proxy "http://user@example.com:somePassword@proxy.example.com:7777";
Для этого можно выполнить команду


sudo cat <<EOF >>/etc/apt/apt.conf.d/proxy.conf
Acquire::http::Proxy "http://user@example.com:somePassword@proxy.example.com:7777";
EOF

Проверим правильность сделанных настроек:


cat /etc/apt/apt.conf.d/proxy.conf

Результат должен содержать:


Acquire::http::Proxy "http://user@example.com:somePassword@proxy.example.com:7777";

Затем необходимо выйти из WSL и после повторного входа проверить правильность работы, например, выполнив:


sudo apt-get update -y

Curl


Если логин и/или пароль не содержат @, то можно ограничится добавлением переменной среды http_proxy со значением http://user:somePassword@proxy.example.com:7777.


Если прокси не требует авторизации, то http://proxy.example.com:7777.


Сделать это можно командой:


cat <<EOF >> ~/.profile
export http_proxy=http://user:somePassword@proxy.example.com:7777
EOF

Чтобы не перезагружать WSL можно выполнить команду:


source ~/.profile

Но в нашем случае придется создать файл ~/.curlrc со следующим содержимым:


proxy-user=user@example.com:somePassword
proxy=http://proxy.example.com:7777

Сделать это можно, выполнив команду:


cat <<EOF >> ~/.curlrc
proxy-user=user@example.com:somePassword
proxy=http://proxy.example.com:7777
EOF

Wget


Если логин и/или пароль не содержат @ или прокси не требует авторизации, то можно воспользоваться соответствующими шагами для curl, если они не были сделаны раньше.
В нашем случае, создадим файл ~/.wgetrc следующего содержания:


proxy-user=user@example.com
proxy-password=somePassword
http_proxy=http://proxy.example.com:7777
use_proxy=on

Сделать это можно командой:


cat <<EOF >> ~/.wgetrc
proxy-user=user@example.com
proxy-password=somePassword
http_proxy=http://proxy.example.com:7777
use_proxy=on
EOF

Осталось еще несколько команд для git и npm.


Git


git config --global http.proxy "http://user@example.com:somePasswrod@proxy.example.com:7777"

Npma


npm set proxy http://user@example.com:somePassword@proxy.example.com:7777/
npm set https-proxy http://user@example.com:somePassword@proxy.example.com:7777/

UPD 1: исправлены опечатки и неточности по комментариям DaemonGloom и achekalin.

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 12

    +2

    Это же фактичеки, настройки для использования для любой программы под linux. При чем тут wsl ?

      –1

      Согласен. Наверное, написанное в статье подойдет и для Ubuntu. Но в моем случае, не было возможности проверить это. Поэтому указал, что для wsl.

      0
      sudo cat <<<EOF >>/etc/apt/apt.conf.d/proxy.conf
      Acquire::http::Proxy "http://user@example.com:somePassword@http://proxy.example.com:7777";`
      EOF

      А вы уверены, что apt обрадуется такому количеству http в параметре? И для apt (и системы в целом) рекомендуют указывать ещё и https proxy, а не только http. Как для apt, так и для системы. В теории, в .profile можно взять имя пользователя в кавычки — это решит проблему с символом @. Ну и для добавления одной строки извращение с cat проще заменить на простейший echo.

      И да. Зачем эта статья на хабре и чем не устроили прошлые?
        0

        Спасибо за замечание. Это была опечатка. Исправлю. Написано ради кейса с @ в логине. В моем случае написанные ранее статьи не помогали, так как в результате следования им я получал отказ в авторизации.

        +2

        Вы несколько раз написали «Если логин не содержит @», но вариант «если пароль не содержит символ @» как-то пропустили. А чедь грабли будут одинаковыми, @ поломает схему url-а и в том, и в другом случае.


        И, да, wsl из заголовка и текста надо убирать, ничего wsl-особенного вы не написали. Я, уж и правда, ожидал увидеть указание прокси в каком ключе реестра, или еще что-то неожиданное и сакральное.

          0

          Согласен. @ в пароле тоже "ломает" схему. Поправлю текст.
          Что касается названия, то я сам искал настройку proxy в Ubuntu для WSL. И, видимо, поэтому название получилось несколько "зашоренным".

          +3

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


          У себя в команде мы почти сразу пришли к сетапу, когда на win-хосте работает cntlm, а внутри wsl определены переменные окружения HTTP_PROXY и HTTPS_PROXY, смотрящие на cntlm. Те инструменты, которые в 2020 игнорируют эти переменные, настраиваются смотреть на cntlm вручную, но их довольно мало.

            0

            Согласен. Предлагаемый в статье подход подразумевает ручную замену значений в достаточно большом количестве мест. Предлагаемый вами подход представляется перспективным. Но не смог найти примеров и/или реализовать самостоятельно определение и использование нужных переменных окружения для настройки wget и curl в случае наличия спецсимволов в логине или пароле.

              +1

              А зачем Вам спецсимволы в пароле? По сути, речь идёт о том, чтобы на win-хосте поднять локальный прокси, на котором авторизация не требуется вовсе, и ходить из wsl на него. И уже на локальном прокси проходить аутентификацию на внешнем.


              В случае доменной инфраструктуры внешний прокси скорее всего поддерживает NTLM, и здесь отлично подходит cntlm, который в своем конфиге пароля от доменной учётной записи вовсе не содержит.


              Если уж совсем невмоготу, то спецсимволы в пароле можно заменять на hex-значения (url encode), то есть вместо @ будет %40 и так далее.

                0

                не всегда вы можете влиять на пароль. представим что вам такой выдали и тогда вся статья сводится к теме "как использовать спецсимвол @ при работе с proxy в linux"

                  +1

                  Моя мысль была не про то, чтобы влиять на пароль. А про то, чтобы вынести использование пароля из wsl на уровень win-хоста, где это зачастую проще.

            0

            Было бы прикольно ещё разобрать подробности работы с корпоративным прокси где есть mitm и собственный сертификат

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

            Самое читаемое