туннель через https

[12:31] se@o /usr/ports >make search name='ssltunnel'
Port: ssltunnel-client-1.16
Path: /usr/ports/net/ssltunnel-client
Info: PPP over SSL virtual private networking (client part)
Maint: at@rominet.net
B-deps: libiconv-1.13.1
R-deps: libiconv-1.13.1
WWW: http://www.hsc.fr/ressources/outils/ssltunnel/

Port: ssltunnel-server-1.16
Path: /usr/ports/net/ssltunnel-server
Info: PPP over SSL virtual private networking (server part)
Maint: at@rominet.net
B-deps:
R-deps:
WWW: http://www.hsc.fr/ressources/outils/ssltunnel/

поднимаешь openvpn 443 порту на компе А, на компе C конектишься к компу А через proxy на B

Поддерживаю OpenVPN.
На работе такая же история, но заблочено меньше.

http://www.exiledmind.net/vpn-tunnel

http://www.google.ru/search?hl=ru&source=hp&q=openvpn+http+proxy&...

> на компе C конектишься к компу А через proxy на B

Вот интересует, как это приблизительно происходит?

openvpn --client --remote host [port] --http-proxy server port

ну и прочие опции по вкусу.

>Вот интересует, как это приблизительно происходит?

Отрывок из конфига openvpn:

proto tcp
# Прокся без авторизации
http-proxy 10.128.1.100 8080
# Прокся с авторизацией
#http-proxy 10.0.0.48 8080 /etc/openvpn/pa basic
http-proxy-retry # retry on connection failures

ммм... до прокси еще не дошел, теситровал просто как работает через tcp. Клиент и сервер net-misc/openvpn-2.1_rc19 В режиме udp все работает прекрасно, в режиме tcp если только одни пинги идут то все путем, если еще что-то помимо этих пингов начинает ходить - то сервер где-то запутывается в ответах и соединение как бы вешается. причем и клиент и сервер считают что все в порядке. при tcp соединение пингаю впн сервер - все ок. в соседнем окошке включаю nmap -sP private_network_over_vpn - пинги перестают проходить и соединение как бы вешается. Ктонить сталкивался? Может версию не bleeding-edge поставить?

У меня 2.0.9 сервер + клиенты 2.0.9, 2.1rc11 и еще какие-то :)
Все работает через TCP безо всяких проблем, с кучей параллельных потоков, с передачей больших файлов и т.п.

Варианты по вашей проблеме:
1. Косяки с PMTU discovery (по симптомам немного похоже).
2. Какие-нибудь веселые настройки sysctl для tcp (например, window_scaling).
3. А что стоит между сервером и клиентом? Там никаких зверских шейперов с RED случаем нет?

Судя по логам первым "затыкается" сервер. Любые RED не должны влиять на прохождение tcp-потока таким образом, что это могло бы привести к такой работе опенвпн. Тсп соединение держиться. Возможно, косяки в реализации tcp режима на сервере.

Что такое PMTU discovery я не знаю, погуглю вечерком

> У меня 2.0.9 сервер + клиенты 2.0.9, 2.1rc11 и еще какие-то :) Все работает через TCP безо всяких проблем, с кучей параллельных потоков, с передачей больших файлов и т.п.

Ну прям засада какаято. даунгрейдил сервер и клиент до 2.0.9 - та же фигня. по юдп - все отлично бегает, по тсп - затыкается при начале большой закачки или при множестве параллельных потоков. Не могу вдуплить в чем дело. Можете привести все установленные переменные (кроме адресов и сертификатов) которые есть в конфигах ваших серверов и клиентов? Буду премного благодарен.

Как бороться с path MTU discovery так и не понял

В пределах квартиры (т.е. не проходя маршрутизаторов) поднял опенвпн сервер и клиентился к нему с бука: с tcp все работает отлично. не понимаю.

Сервер:

dev tun
proto tcp

server 172.21.0.0 255.255.0.0

client-to-client

keepalive 10 120
comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-stat

Клиенты (конфиги делались по одному образцу):

http-proxy 10.128.0.100 8080
http-proxy-retry

remote сервер порт

resolv-retry infinite
nobind

user nobody
group nobody

persist-key
persist-tun

comp-lzo

Все остальное относится к сертификатам и маршрутам.

Как бороться с path MTU discovery так и не понял

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Но вряд ли это оно. Скорее всего либо маршрутизатор кривой, либо провайдер.