LINUX.ORG.RU

Туннель через ПРОЗРАЧНЫЙ http прокси


0

1

Здравствуйте. Дано - сервер и клиент, который можно настраивать как угодно. Клиент находится в сети, наружу которой открыт только 80 и 443 порты и стоит ПРОЗРАЧНЫЙ прокси сервер. Хотелось бы между клиентом и сервером поднять VPN или хотя бы ssh туннель.

Для чего это может быть нужно? Например, чтобы из макдака (а там именно такая конфигурация сети, как я описал) можно было подключиться по ssh к серверу.

Повторяю, наружу закрыто Все, кроме tcp/80 tcp/443 и то через прозрачный прокси. (udp/53 тоже закрыт наружу)

Вопрос такой - возможно ли это теоретически и, если да, то есть ли реализации?


Легко.

Тот же openvpn, например. Главное, чтобы vpn-сервер слушал на 443 порту, а прокся разрешала HTTP-метод CONNECT (а она должна это разрешать, потому что 443/TCP HTTPS только через CONNECT и работает).

Просто в качестве сервера указываешь свой сервак, порт 443, и все должно работать.

P.S. Если хочется секса и тормозов, можешь сделать DNS-туннель. Должен спокойно пройти сквозь рекуррентный резольвер.

anonymous
()
Ответ на: комментарий от anonymous

Просто в качестве сервера указываешь свой сервак, порт 443, и все должно работать.

Пробовал, не работало.

Возможно, прокси видит, что это не https траффик и его режет? Например, видет, что нету http заголовков. Они же, вроде как, не шифруются.

потому что 443/TCP HTTPS только через CONNECT и работает

Не очень понятно, как это может быть, если прокси прозрачный...

l_o_r
() автор топика
Ответ на: комментарий от l_o_r

потому что 443/TCP HTTPS только через CONNECT и работает

Не очень понятно, как это может быть, если прокси прозрачный...


сори, туплю, думал, что CONNECT это метод прокси, а не http

l_o_r
() автор топика
Ответ на: комментарий от l_o_r

>Возможно, прокси видит, что это не https траффик и его режет? Например, видет, что нету http заголовков. Они же, вроде как, не шифруются.

Нет, шифруется все. Если HTTPS на тот же сервер работает (для теста можно временно поднять там апач), то и openvpn должен работать.

В твоем случае вижу три возможных причины, почем оно не работало: 1. CONNECT зарезан вообще/админ прокси идиот (зачем разрешать 443, если HTTPS все равно запрещен?). 2. Как-то по-особому забанены адреса/порты твоего сервера и/или клиента (админ прокси очень хитрый, он все уже просек). 3. Ты криво настроил openvpn.

anonymous
()

А не проще на сервере повесить ssh на 443 или 80 порт? Или, если эти порты уже заняты, то сделать переадресацию файрволом с адресов макдака на 22 порт?

fractaler ★★★★★
()
Ответ на: комментарий от fractaler

> А не проще на сервере повесить ssh на 443 или 80 порт? Или, если эти порты уже заняты, то сделать переадресацию файрволом с адресов макдака на 22 порт?

И как, нормально HTTP-прокси ssh-трафик проксирует?

anonymous
()
Ответ на: комментарий от anonymous

>Просто в качестве сервера указываешь свой сервак, порт 443, и все должно работать.

Боюсь, не все так просто. Обычно openvpn заворачивает свой трафик в CONNECT только при наличии директивы http-proxy. Можно попробовать указывать vpn-сервер одновременно как сервер и как прокси, но это может и не сработать.

nnz ★★★★
()
Ответ на: комментарий от anonymous

Хз, я бы попробовал.
Предлагаю ещё повесить на серваке веб-морду к ssh.

fractaler ★★★★★
()
Ответ на: комментарий от anonymous

>И как, нормально HTTP-прокси ssh-трафик проксирует?
Жалкие людишки! Это будет совершенно нормально, если объяснить ssh-клиенту, что он работает через прокси: http://daniel.haxx.se/docs/sshproxy.html

fractaler ★★★★★
()

А ты уверен, что именно прокси, а не нат?

Так как проксировать https нет никакого проку. Вполне может быть, что tcp/443 выполнен через нат.

ansky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.