URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 80017
[ Назад ]

Исходное сообщение
"Оптимизация vpn канала (ppp-over-ssh)"
Отправлено zmc , 26-Апр-08 19:09

Доброго времени суток!
Собственно САБЖ, имеется vpn соединение двух офисов ppp-over-ssh.
Наблюдаю такую картину.
VPN'КА ПОДНЯТА
...
pty "ssh -1 -C -i ~/.ssh/vpn.key -o CompressionLevel=9 xxx.xxx.xxx.xxx ppp -direct vpn"
поднимается ppp интерфейс, допустим 192.168.0.2 -> 192.168.0.1
wget http://192.168.0.1/big.file
скачка идет секунд 30-35 средняя скорость 200KB/s, размер файла 5MB.
VPN'КА ОПУЩЕНА
ssh -1 -C -L 8008:172.168.0.1:80 -o CompressionLevel=9 root@xxx.xxx.xxx.xxx
http_proxy=127.0.0.1:8008 wget http://172.168.0.1/big.file
172.168.0.1 внутрений адрес в LAN
скачка идет три секунды средняя скорость 1.5MB/s, размер файла тот же.
Несколько раз повторял тесть результаты теже, плюс минус.
Собственно два вопроса.
Первый почему такая большая разница, т.е. я могу понять что есть какие то системные расходы на ppp соеденение поверх ssh но 200KB в сравнении с 1.5MB уж очень много.
Второй можно ли как нибуть оптимизировать соединение догнать хотябы до трети второго примера?
Ряд замечаний:
Параметры ppp минимальные(default) единственное deflate в 9,9 стоит.
Вопрос чисто принципиальный, я понимаю что к примеру openvpn и иже сними может разрулить ситуацию такого рода на ура.
Офисы на растоянии 3000 км у обоих DSL каналы одинаковые(более менее)
Заранее спасибо

Содержание

Оптимизация vpn канала (ppp-over-ssh),zmc, 18:04 , 27-Апр-08
Оптимизация vpn канала (ppp-over-ssh),Heckfy, 22:18 , 27-Апр-08
- Оптимизация vpn канала (ppp-over-ssh),tmp, 05:52 , 28-Апр-08
  - Оптимизация vpn канала (ppp-over-ssh),Heckfy, 12:15 , 28-Апр-08

Сообщения в этом обсуждении

"Оптимизация vpn канала (ppp-over-ssh)"
Отправлено zmc , 27-Апр-08 18:04

ДаАаАаА вот как то так :-(

"Оптимизация vpn канала (ppp-over-ssh)"
Отправлено Heckfy , 27-Апр-08 22:18

>Собственно САБЖ, имеется vpn соединение двух офисов ppp-over-ssh.
А если отказаться от ppp?
Например, выделить набор критичных сервисов и вывесить их на своей стороне, при необходимости, подымая дополнительные ip-адреса "той стороны". А трафик заворачивать файрволом.

"Оптимизация vpn канала (ppp-over-ssh)"
Отправлено tmp , 28-Апр-08 05:52

>
>А если отказаться от ppp?
>Например, выделить набор критичных сервисов и вывесить их на своей стороне, при
>необходимости, подымая дополнительные ip-адреса "той стороны". А трафик заворачивать файрволом.
Блин не понял :-)

"Оптимизация vpn канала (ppp-over-ssh)"
Отправлено Heckfy , 28-Апр-08 12:15

Как вариант:
тут и там - дебиан, "там" сеть 192.168.101.0/24, "тут" - 192.168.100.0/24
"Там" есть 10 серверов с апачем (192.168.101.101-110), 3 с mysql (192.168.101.51-53) и 1 c Windows Terminal Server (192.168.101.151).
"Тут" есть почтовый сервер IMAP и SMTP: 192.168.100.143 и 192.168.100.25
Пробрасываем известным методом порты:
nobody@192.168.100.1:/ $ ssh -L1101:192.168.101.101:80 \
  -L1102:192.168.101.102:80 \
  ...
  -L1110:192.168.101.110:80 \
  -L13306:192.168.101.51:3306 \
  -L23306:192.168.101.52:3306 \
  -L33306:192.168.101.53:3306 \
  -L3389:192.168.101.151:3389 \
  -R1025:192.168.100.25:25 \
  -R1143:192.168.100.143:143 \
  192.168.101.1
Получаем 2 букета на локалхостах машин с адресами 192.168.100.1 и 192.168.101.1
Забирать проброшенное как-то неудобно.
Делаем дополнительные интерфейсы на _192.168.100.1_ (не .101.1):
iface eth0:51 inet static
        address 192.168.101.51
        netmask 255.255.255.0
...
iface eth0:53 inet static
        address 192.168.101.53
        netmask 255.255.255.0
iface eth0:101 inet static
        address 192.168.101.101
        netmask 255.255.255.0
...
iface eth0:110 inet static
        address 192.168.101.110
        netmask 255.255.255.0
iface eth0:151 inet static
        address 192.168.101.151
        netmask 255.255.255.0
Получаем на своей стороне такие же адреса, как на другой стороне. Ни сервер, ни клиент ssh путаться не будут. Если что-то не заработало, на этом этапе глюк можно не искать.
nobody@192.168.100.1:/ $ ssh -L192.168.101.101:80:192.168.101.101:80 \
  -L192.168.101.102:80:192.168.101.102:80 \
  ...
  -L192.168.101.110:80:192.168.101.110:80 \
  -L192.168.101.51:3306:192.168.101.51:3306 \
  -L192.168.101.52:3306:192.168.101.52:3306 \
  -L192.168.101.53:3306:192.168.101.53:3306 \
  -L192.168.101.151:3389:192.168.101.151:3389 \
  192.168.101.1
Разберем синтаксис:
-L192.168.101.151:3389:192.168.101.151:3389
слева "-L192.168.101.151:3389"
справа ":192.168.101.151:3389"
Левую часть понимаем только "тут", правую часть умеет понимать сервер, к которому подсоединяемся. В адресе справа можно писать доменные имена, которые "тут" даже не разыменовать, а "там" можно.
Что бы добавить следующие строки,
  -R192.168.100.25:25:192.168.100.25:25 \
  -R192.168.100.143:143:192.168.100.143:143 \
надо на другой стороне провести аналогичную работу по созданию интерфейсов.
192.168.100.1:~ # iptables -t filter -A INPUT -d 192.168.101.101 -p tcp -m tcp --dport 80 -j ACCEPT
Даем доступ к проброшенному с 192.168.101.101 80-му порту пользователям сети 192.168.100.0/24 и другим, кто может там тусить.
Для примера, сделаем либеральную политику - всем "тут" можно ходить на сайты "там":
-A INPUT -d 192.168.101.0/24 -s 192.168.100.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
Всё. Творческих узбеков.