Linux proxy connection failed

Содержание

Connection Refused while apt-get update ubuntu 18.04 over proxy
Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid
8 комментариев on «Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid»
Ubuntu Server not using proxy settings
3 Answers 3

Connection Refused while apt-get update ubuntu 18.04 over proxy

m@m-Lenovo-ideapad-500-15ISK:~$ ping archive.ubuntu.com PING archive.ubuntu.com (91.189.88.161) 56(84) bytes of data. 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=1 ttl=45 time=127 ms 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=2 ttl=45 time=127 ms 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=3 ttl=45 time=127 ms 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=4 ttl=45 time=127 ms 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=5 ttl=45 time=127 ms ^C --- archive.ubuntu.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 127.232/127.426/127.761/0.296 ms

m@m-Lenovo-ideapad-500-15ISK:~$ env | grep proxy HTTP_PROXY=http://proxy.iiit.ac.in:8080/ FTP_PROXY=http://proxy.iiit.ac.in:8080/ https_proxy=http://proxy.iiit.ac.in:8080/ http_proxy=http://proxy.iiit.ac.in:8080/ ALL_PROXY=socks://proxy.iiit.ac.in:8080/ no_proxy=localhost,127.0.0.0/8. 1 HTTPS_PROXY=http://proxy.iiit.ac.in:8080/ all_proxy=socks://proxy.iiit.ac.in:8080/ ftp_proxy=http://proxy.iiit.ac.in:8080/

Note that apt-get update is working fine without proxy on my mobile hotspot but not via the proxy on my lan / wifi. How do I fix this ? edit Trying to install sublime gives the following error :

m@m-Lenovo-ideapad-500-15ISK:~$ sudo apt-get install sublime-text Reading package lists. Done Building dependency tree Reading state information. Done The following NEW packages will be installed: sublime-text 0 upgraded, 1 newly installed, 0 to remove and 90 not upgraded. Need to get 8,494 kB of archives. After this operation, 25.1 MB of additional disk space will be used. Err:1 https://download.sublimetext.com apt/stable/ sublime-text 3176 Could not connect to download.sublimetext.com:443 (104.236.0.104). - connect (111: Connection refused) E: Failed to fetch https://download.sublimetext.com/files/sublime-text_build-3176_amd64.deb Could not connect to download.sublimetext.com:443 (104.236.0.104). - connect (111: Connection refused) E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

ping 104.236.0.104 PING 104.236.0.104 (104.236.0.104) 56(84) bytes of data. 64 bytes from 104.236.0.104: icmp_seq=1 ttl=48 time=206 ms 64 bytes from 104.236.0.104: icmp_seq=2 ttl=48 time=207 ms 64 bytes from 104.236.0.104: icmp_seq=3 ttl=48 time=206 ms 64 bytes from 104.236.0.104: icmp_seq=4 ttl=48 time=206 ms 64 bytes from 104.236.0.104: icmp_seq=5 ttl=48 time=207 ms ^C --- 104.236.0.104 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 206.334/206.879/207.767/0.593 ms

Источник

Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid

Всё чаще стали проявляться проблемы у пользователей при открытии HTTPS сайтов в Chrome (версия 29.0.1547.66 m) с использованием прокси сервера Squid (Basic и NTLM аутентификация), при чём даже на одинаковых аппаратных конфигурациях у одних пользователей всё исправно работало, у других нет. В браузерах — Opera, Firefox всё работало без проблем.

Симптомы следующие: при переходе на любой HTTPS сайт, например, на https://dropbox.com https://twitter.com страница не загружалась (но если и загружалась, то с 10-ой попытки обновления, и не полностью). Также при открытии появлялись ошибки ERR_TIMED_OUT и ERR_TUNNEL_CONNECTION_FAILED.

UPD: Проблема также (если не в основном) кроется в том, что проверка сертификатов в CRL или с помощью OCSP различными браузерами выполняется по-разному — кто то использует указанные настройки Proxy или внутренний механизм проверки (Firefox, например), а кто то (Chrome) использует встроенный в Windows механизм проверки, который зачастую идёт «напрямик» (возможно, необходимо «корректно» указать настройки системного прокси) через шлюз по-умолчанию, на котором нет выхода в Интернет. Для решения данной проблемы я запустил на шлюзе прозрачный прокси на порт 80 и разрешаю обработку URL по правилам:

/etc/squid/acls/without_any_restrictions_dstdom_regex.acl
.
(^|\.)certum.pl$
(^|\.)digicert.com$
(^|\.)verisign.com$
(^|\.)globalsign.com$
(^|\.)ocsp.comodoca.com$
(^|\.)ocsp.comodoca4.com$
(^|\.)ocsp.usertrust.com$
(^|\.)thawte.com$
(^|\.)letsencrypt.org$
(^|\.)ocsp-responder.com$
(^|\.)ocsp.godaddy.com$
(^|\.)ocsp.sca1b.amazontrust.com$
.
acl without_any_res_dstdom_regex dstdom_regex -i «/etc/squid/acls/without_any_restrictions_dstdom_regex.acl»
http_access allow all without_any_res_dstdom_regex
acl cert_file_ext urlpath_regex -i \.crl$ \.crt$
http_access allow all cert_file_ext

Испробовали всё, что можно: указание в Chrome прокси сервера вручную, указание конкретного типа аутентификации (так как по логам Squid было видно, что Chrome не всегда пытается аутентифицироваться, во всяком случае реже, чем при открытии просто HTTP сайтов), далее убрали все ограничения Squid и аутентификацию в том числе, но это не помогло решить проблему. Также было замечено, что Internet Explorer имеет аналогичные проблемы при доступе на HTTPS сайты.

В итоге решено было посмотреть «диалог» между клиентом и прокси сервером, используя анализатор сетевого протокола Wireshark (http://wireshark.org). Wireshark запускался на стороне клиента. Проходящие пакеты были записаны и отфильтрованы по адресу прокси ip.addr==192.92.92.100. И тут обнаружилось следующее — пакеты, отправляемые клиентом, имели некорректную (нулевую) контрольную сумму (скриншот приведён ниже). После чего было решено в настройках сетевого адаптера отключить всё, что касается «разгрузок протоколов», энергосбережения, контроля трафика и прочих функций, которые берёт на себя сетевая карта вместо ОС. Пакеты стали отправляться с правильной контрольной суммой заголовка и Chrome стал открывать HTTPS узлы мгновенно, без нареканий, с использованием аутентификации на прокси сервере Squid. На остальных проблемных компьютерах данные манипуляции также помогли решить проблему (сетевая карта была такая же). Возможно также помогает обновление драйвера сетевой карты, но данный метод не испробован.

Сетевая карта: Realtek PCIe GBE Family Controller
Драйвер: Realtek 21/03/2011, version 7.43.321.2011

Пакеты с некорректной контрольной суммой заголовка:

Окно с настройками сетевой карты:

8 комментариев on «Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid»

У меня была похожая проблема! Есть шлюз под линуксом (сквид3), с клиентской машины не могу зайти по https (причем 50 на 50, на некоторые сайты зайти можно, на некоторые выдает ERR_TUNNEL_CONNECTION_FAILED )
Думал, что дело в сквиде (очищал кэш, менял конфигурацию, отключал блэклист и пр.), не помогло. А потом увидел в настройках сетевой карты клиентской машины прописаны два каких-то левых ДНС (62.109.12.227 и 162.211.228.130). Прописал днс своего сервака и вуаля, все заработало. Потом прошелся троянремувером и удалил «потенциально нежелательную прогу» и все ОК.

Спасибо за сообщение!
У нас были проблемы на различных машинах без вредоносного ПО с правильным DNS и другими настройками, в том числе и NTLM протокола, по-этому ситуацию удалось разрешить только после применения снифера.

Читайте также: Cue to wav linux

Не могу зайти в Google Crome. Прочитала статью, в итоге решила посмотреть «диалог» между клиентом и прокси сервером, используя анализатор сетевого протокола Wireshark (http://wireshark.org). Выдал ошибку » Uh-oh, something went wrong! Error Code: 403″, что это значит?

Подскажите,
Uh-oh, something went wrong! Error Code: 403 отсутствует сетевой адрес . Посмотрела и верно, отсутствует сетевой адрес, в строке, Значение, если её активировать сплошные нули, а сразу выдаёт Значение: Отсутствует. Как задать сетевой адрес? Может я не установила правильно Браузер?

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

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

Сетевой адаптер Интел, подобные действия не привели к нужному результату. Подозреваю что проблема не на стороне клиента, и если уж в сетевой карте дело то на стороне сквида. Так как если не использовать маршрутизацию через сквид то интернет работает нормально со всеми сайтами, как только пишу в свойствах браузера проксю — не работают некоторые сайты (я проверял на youtube.com). Теперь осталось понять как все эти управления Rx/Tx отключить в линуксе на стороне сквида.
PS: небольшая ремарка — сквид у меня крутится на виртуалке Hyper-V.

Источник

Ubuntu Server not using proxy settings

i am using the ubuntu server package (terminal only) and i am struggling to get the proxy server working. there is no username/password for the proxy. When i am trying to do sudo apt-get update i get multiple errors like:

Failed to fetch blablabla. Cannot initiate the connection to proxy:8080 (proxy). - connect (101: network is unreachable)

http_proxy="http://proxy:8080/"; https_proxy="https://proxy:8080/"; ftp_proxy="ftp://proxy:8080/";

when i do $http_proxy it returns http_proxy=»http://proxy:8080/»; i have set the /etc/gai.conf to prefer IPv4 by putting precedence ::ffff:0:0/96 100 I’m using wireless but i have ethernet available. It does not recognise the ethernet though. The setup asked for the proxy and it accepted it (not sure if it used it or not). edit: route -n gives:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface

I assume «proxy» is a placeholder for the proxy’s IP address? Could you show the output (add it to your question) of running route -n ? Also, if you could tell us the proxy’s IP address, that’d be good, but not necessary if you have any reason for wanting to keep it secret.

Yes «proxy» is a placeholder. We are a school and use the councils proxy, not secret as such but it’s not my place to put it up on the internet.

Ok, your routing table is wrong as it doesn’t show anything 🙁 this means your network interface is misconfigured and not actually up, which explains the «network unreachable» report. Do you have any internal web servers you can check without setting the proxy? this will let you solve one problem at a time, because right now, the problem is that you’re not really connected to any networks. For completeness, here’s an example of how your routing table should look like, once a wlan0 interface is up and has a default route: paste.ubuntu.com/10160311

3 Answers 3

I think you may need to set the proxy specifically for apt, see this ubuntu documentation link which the source for the following:

Setting up apt-get to use a http-proxy

These are three methods of using apt-get with a http-proxy.

Temporary proxy session

This is a temporary method that you can manually use each time you want to use apt-get through a http-proxy. This method is useful if you only want to temporarily use a http-proxy.

Enter this line in the terminal prior to using apt-get (substitute your details for your proxy address and proxy port):>

export http_proxy=http://yourproxyaddress:proxyport

If you normally use sudo to run apt-get you will need to login as root first for this to work unless you also add some explicit environment settings to /etc/sudoers, e.g.

Defaults env_keep = «http_proxy https_proxy ftp_proxy»

APT configuration file method

This method uses the apt.conf file which is found in your /etc/apt/ directory. This method is useful if you only want apt-get (and not other applications) to use a http-proxy permanently.

On some installations there will be no apt-conf file set up. This procedure will either edit an existing apt-conf file or create a new apt-conf file.

Add this line to your /etc/apt/apt.conf file (substitute your details for your proxy address and proxy port).

Acquire::http::Proxy «http://yourproxyaddress:proxyport»;

Save the apt.conf file.

BASH rc method

This method adds a two lines to your .bashrc file in your $HOME directory. This method is useful if you would like apt-get and other applications for instance wget, to use a http-proxy.

Add these lines to the bottom of your ~/.bashrc file (substitute your details for your proxy address and proxy port)

http_proxy=http://yourproxyaddress:proxyport export http_proxy

Save the file. Close your terminal window and then open another terminal window or source the ~/.bashrc file:

source ~/.bashrc Test your proxy with sudo apt-get update and whatever networking tool you desire. You can use firestarter or conky to see active connections.

If you make a mistake and go back to edit the file again, you can close the terminal and reopen it or you can source ~/.bashrc as shown above.

source ~/.bashrc

Then log out and back in and try

Источник