Как предотвратить отказ в соединении с SOCKS на dataproc?

Я пытаюсь настроить подключение SOCKS к искровому кластеру dataproc, следуя руководству Google Jupyter, но я продолжаю получать ошибки «отказ в соединении» после запуска браузера Chrome:

channel 4: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 6: open failed: connect failed: Connection refused
channel 7: open failed: connect failed: Connection refused
channel 8: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 16: open failed: connect failed: Connection refused
channel 16: open failed: administratively prohibited: open failed
channel 17: open failed: administratively prohibited: open failed
channel 18: open failed: administratively prohibited: open failed
channel 16: open failed: connect failed: Connection refused
channel 18: open failed: connect failed: Connection refused
channel 18: open failed: connect failed: Connection refused
channel 18: open failed: connect failed: Connection refused

Это происходит как с --proxy-server="socks5://localhost:1080", так и с --proxy-server="socks5://127.0.0.1:1080"


ssh google-cloud-dataproc socks
person Emre    schedule 15.07.2016    source источник
comment
Без флагов динамической пересылки вы можете, по крайней мере, напрямую подключиться к главному узлу по SSH через gcloud compute ssh <your-master-node>?   -  person Dennis Huo    schedule 15.07.2016
comment
О, конечно, я некоторое время с удовольствием использую Jupyter с переадресацией портов. Единственная причина, по которой меня интересует SOCKS, — это возможность доступа к SparkUI.   -  person Emre    schedule 15.07.2016
comment
Есть ли у вас более подробная информация об ошибках отказа в подключении? Они приходят из браузера? Или вы используете какое-то другое пользовательское приложение для соединения с socks?   -  person Dennis Huo    schedule 15.07.2016

Ответы (1)


arrow_upward
3
arrow_downward

Итак, я не уверен на 100%, откуда берутся «административно запрещенные» сообщения, но по моему опыту это всегда были ложные тревоги, и я вижу эти сообщения open failed: administratively prohibited: open failed, даже когда мой socks-прокси работает правильно, как и ожидалось.

Что касается фактической проблемы, из-за того, как такие вещи, как YARN, связывают свои веб-сервисы, я получил Connection refused при попытке доступа к пользовательскому интерфейсу YARN с помощью http://localhost:8088 вместо http://<master-hostname>:8088. Это соответствует поведению запуска get внутри кластера:

dhuo@dhuo-jupyter-m:~$ wget http://localhost:8124
...
Saving to: ‘index.html.13’

index.html.13                                                          100%[=============================================================================================================================================================================>]  11.41K  --.-KB/s   in 0s     

2016-07-15 23:26:25 (222 MB/s) - ‘index.html.13’ saved [11686/11686]

dhuo@dhuo-jupyter-m:~$ wget http://localhost:8088
--2016-07-15 23:26:28--  http://localhost:8088/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8088... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:8088... failed: Connection refused.
dhuo@dhuo-jupyter-m:~$ wget http://`hostname`:8124
...
Saving to: ‘index.html.14’

index.html.14                                                          100%[=============================================================================================================================================================================>]  11.41K  --.-KB/s   in 0s     

2016-07-15 23:26:34 (260 MB/s) - ‘index.html.14’ saved [11686/11686]

dhuo@dhuo-jupyter-m:~$ wget http://`hostname`:8088
...
Saving to: ‘index.html.15’

index.html.15                                                          100%[=============================================================================================================================================================================>]  10.81K  --.-KB/s   in 0s     

2016-07-15 23:26:37 (248 MB/s) - ‘index.html.15’ saved [11067/11067]

Как видите, это отличается от поведения Jupyter (которое я запускал на порту 8124), где веб-приложение Jupyter работает правильно, разрешая localhost:8124 на мастере. Поскольку разрешение имен с этими связанными инструкциями должно происходить на мастере, поведение браузера при разрешении хостов будет таким же, как при запуске wget на узле, в который вы туннелировали.

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

person Dennis Huo    schedule 15.07.2016
comment
Административно запрещенные сообщения появляются только с 127.0.0.1 - person Emre; 16.07.2016