отказ в соединении через прокси-сервер SOCKS через Firefox 47.0 / Kubuntu 16.04

У меня проблемы с подключением к веб-сайтам с использованием Firefox через туннельный прокси SOCKS. SOCKS4 / SOCKS5 не имеет значения.

Я настроил туннель с помощью

ssh -D 1234 id@remotehost.example.com

, а затем направил SOCKS-прокси Firefox на localhost на tcp / 1234.

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

Проблема в том, что FF, похоже, не «хочет» устанавливать соединение. Я набираю URL или нажимаю на ссылку, и я мгновенно получаю «Невозможно подключиться» / «Firefox не может установить соединение с сервером при ...» Когда я говорю «мгновенно», я имею в виду это всплывает ко мне через несколько секунд.

Поэтому я нажал «Попробуй еще раз» или маленькую стрелку перезагрузки. И я делаю это снова, и снова, и снова, так быстро, как только могу. И после нескольких попыток - иногда 3-4, иногда целых 15-20 - я получаю соединение, и все работает! Таким образом, соединение туннель / SOCKS доступно, просто FF отказывается его использовать, пока его не запугивают. Как только я получаю соединение, дальнейшая перезагрузка не приводит к его потере.

У меня есть некоторые надстройки, но а) я выборочно отключил их без посторонней помощи, и б) я (конечно) попробовал безопасный режим. Без изменений.

Есть предложения?

4
задан 14 June 2016 в 16:53

2 ответа

К сожалению, эта проблема неустойчива, и это соединило мои усилия по поиску и устранению неисправностей. Ответ @Terrance дал выше, который я отметил как Ответ, на самом деле не решение проблемы для меня. Это казалось для работы, и на самом деле работал некоторое время. Затем я столкнулся с проблемами снова. Иногда остановка моей ssh сессии и перезапуск ее исправили бы проблему - некоторое время - и иногда перезапуск не будет иметь никакого значения.

предложение упомянуло этот поток в другом месте - т.е. указывать 127.0.0.1, а не "localhost" в браузер настройки, прокси - аналогично, казалось, имели значение, но были в конечном счете неэффективны. Я ранее ответил, что это было критическим различием между работой соединений браузера и не работой, но снова это было преждевременно. Я продолжал испытывать неустойчивые проблемы в способности своего браузера установить связи с веб-сайтами через туннель.

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

Ubuntu-4ubuntu1 OpenSSH_7.2p2, OpenSSL 1.0.2g-fips 1 марта 2016

, я основываю это на a) том, что проблема явно независима от браузера (проверенный в Firefox, Хроме и w3m) и b) том, что использование альтернативы ssh клиент надежно исправило проблему.

я загрузил источник и создал и установил PuTTY (от эта ссылка ).Примечание: удостоверьтесь, что Вы устанавливаете виртуальный пакет gtkgl-dev, таким образом, источник PuTTY может найти заголовочные файлы. Затем я настроил его, как я имею в Windows так много раз в прошлом, и это работало обработка в течение приблизительно двух дней теперь. НУЛЕВЫЕ отказы.

я уверен, что это - фиксация и что существует ошибка в текущем OpenSSH. Я буду работать над созданием отчета тому эффекту.

я выбираю свой собственный ответ как Ответ в целях этого вопроса, хотя ответ @Terrence выше является все еще очень полезным чтением.

0
ответ дан 15 June 2016 в 02:53

Я должен каждый день использовать прокси на работе для соединения с серверами с другой стороны брандмауэра. Я также использую Firefox, Chrome и Ubuntu 16.04.


Править: Я забыл одну часть этого. Я должен был добавить тайм-аут к ssh файлу конфигурации, или мой туннель будет тайм-аут, и я теряю свое соединение. После того как я добавил следующий материал, мое соединение остается открытым:

В ~/.ssh/config добавьте следующую информацию (если файл не существует, создайте его.). Это будет отправлять проверку активности сервера в Ваш туннель каждые 15 секунд.

Host *
ServerAliveInterval 15

Я открываю свое туннельное соединение со следующей командой:

ssh -CfND 1234 username@proxyhost

Затем в Firefox при Настройках подключения в Ручной конфигурации прокси я только заполняю Хост SOCKS: с 127.0.0.1 и Порт: 1234. Затем я удостоверяюсь, что SOCKS v5 выбран. Также обратите внимание, что у меня ничего нет ни в Каком Прокси для: поле.

Я могу подключить к своим хостам тот путь без любых проблем.

enter image description here

Затем для Chrome я выполняю командную строку, таким образом, я не должен устанавливать настройки на Chrome каждый раз, когда я хочу пройти прокси, затем никакой прокси. Для соединения Chrome с прокси, я выполняю следующую строку:

nohup google-chrome-stable --proxy-server="socks5://127.0.0.1:1234" & > /dev/null 2>&1

from ssh manpage

 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11, TCP and UNIX-domain connec‐
         tions).  The compression algorithm is the same used by gzip(1),
         and the “level” can be controlled by the CompressionLevel option
         for protocol version 1.  Compression is desirable on modem lines
         and other slow connections, but will only slow down things on
         fast networks.  The default value can be set on a host-by-host
         basis in the configuration files; see the Compression option.

 -f      Requests ssh to go to background just before command execution.
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         implies -n.  The recommended way to start X11 programs at a
         remote site is with something like ssh -f host xterm.

 -N      Do not execute a remote command.  This is useful for just for‐
         warding ports.

 -D [bind_address:]port
         Specifies a local “dynamic” application-level port forwarding.
         This works by allocating a socket to listen to port on the local
         side, optionally bound to the specified bind_address.  Whenever a
         connection is made to this port, the connection is forwarded over
         the secure channel, and the application protocol is then used to
         determine where to connect to from the remote machine.  Currently
         the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
         as a SOCKS server.  Only root can forward privileged ports.
         Dynamic port forwardings can also be specified in the configura‐
         tion file.

Надеюсь, это поможет!

6
ответ дан 15 June 2016 в 02:53

Другие вопросы по тегам:

Похожие вопросы: