Проблема — заблокирован доступ к отдельным подсетям и, возможно, DNS. Блокировка github.com наглядно показала наличие проблемы. Есть несколько решений разной степени сложности и надёжности. OpenVPN, squid, sshuttle.
Проблема доступа через каналы с низкой надёжностью соединения (телефон в деревне) пока остаётся открытой. Возможно, sshuttle через Mosh вместо ssh поможет — пока не пробовал, но вопрос такой уже возникал и судя по ответу должно работать.
OpenVPN
Вариант очевидный. Плюсы и минусы тоже очевидны — его надо настраивать.
Удалённый proxy сервер
Предполагается, что у нас есть удалённый сервер, на котором стоит что-то вроде squid. Мы обращаемся к нему, пробросив удалённый порт на локальный порт нашей клиентской машины. #!/bin/sh /bin/sh ~/kill-proxy.sh while : do ssh -C -N -D 3128 tokar@git.pilat66.ru sleep 1 done
То есть в настройках firefox надо указать использование локального прокси сервера 127.0.0.1:3128, или HTTP_PROXY=http://127.0.0.1:3128 или HTTP_PROXY=127.0.0.1:3128 для программ, поддерживающих HTTP_PROXY переменную окружения. Это работает и для windows, и для linux.
Плюсы — можно давать доступ к прокси (и к заблокированным сетям) для отдельных программ. Не нужен рутовый доступ ни на клиенте, ни на сервере — вообще очень ценное свойство.
Минусы — оно же, надо давать доступ именно для программ, которые работают через прокси. Ну и icmp пробросить нельзя, и что-то кроме HTTP тоже. И нужен проки сервер.
Кстати, совсем не обязательно пробрасывать порт http proxy сервера, можно и socks.
shuttle
https://github.com/apenwarr/sshuttle
sshuttle -v —dns -r user@external_host 0.0.0.0/0
user — не обязательно root!. external_host — любой хост с ssh доступом, который видит нужные подсети, и на котором стоит питон.
You don’t need to install sshuttle on the remote server; the remote server just needs to have python available. sshuttle will automatically upload and run its source code to the remote python interpreter.
Получаем проброс tcp сессий на удалённый external_host.
Плюсы. DNS и доступ к сайтам работает. Настраивать почти ничего не нужно. Можно объявить подсети, которые надо пробросить, или подсети, которые не надо пробросить.
Минусы. В отличии от классических VPN, не проброшен icmp, то есть пинг удалённой подсети идёт через обычный канал, не через ssh туннель. То есть для github это подходит, а вот для всяких хитрых программ может и не получится. Например, в случае https будет сообщение о недоверенном узле.
Неясно как будет вести себя соединение при падении ssh канала. Возможно, sshuttle через Mosh будет близким к идеальному решением на плохих линиях, вот только Mosh ещё надо установить.
Tor
В общем случае вообще не решение — кто гарантирует, что оконечные узлы, через которые идёт трафик к выбранному серверу, тоже не заблокированы. А ведь выбираются они случайным образом.
Leave a Reply
You must be logged in to post a comment.