Vpn тунель и скорость соединения

[Saler]

Исходные данные(без конкретики пока):

 

1. Сервер UBUNTU 12.04. Белый айпи. Развернут vpn - сервер (помимо трафпро и dhcp)

2. Несколько удаленных системников (на операционке Win7 и Ubuntu 12.04)

3. Подключение к частной сети происходит по средствам VPN (pptp) подключения от клиента к серверу через интернет.

 

Трабелз 1

Проблема заключается в том что с разных осей(вин/линь) скорость vpn подключения разная (сужу по исходящему потоку от клиента к серверу и не только по этому)

 

Проблема особенно явна когда через эрдипи открываю учетную запись и пробрасываю программе 1с v8 со сканера штрих код. С винды штрих проходит полностью, а в этой же учетной записи эрдипи через того же провайдера через линя ubuntu 12.04 lts штрих код приходит не весь.

 

Внимание, знатоки, вопрос: кто сталкивался с подобной проблемой и знает как сие вылечить с меня пивасик!

 

Трабелз 2.

Один и тот же комп, одна и та же ося(вин/линь - не важно)Через большинство провайдеров vpn подключение проходит нормально, т.е. конектится, а через одного конкретного не буду называть его имя, хотя его основной корпоративный цвет green, нет соединения

 

Внимание, знатоки, вопрос: кто сталкивался с подобной проблемой и знает как сие вылечить с меня пивасик!

 

З.Ы. Конфиги выложу при дальнейшем обсуждении

[хрюконавт]

pptp использует архаичный транспорт gre, который некоторые провайдеры блочат. мой совет - перейти на OpenVpn. простейшие тестовые конфиги будут чуть позже.

[oldbay]

Трабелз 1

Проблема заключается в том что с разных осей(вин/линь) скорость vpn подключения разная (сужу по исходящему потоку от клиента к серверу и не только по этому)

сие странно - нужны более конкретные замеры скорости прохождения пакетов внутри тоннеля в обоих случаях - из самого простого - скажем погонять тяжелый пинг и посмотреть на скорость ответа

Впечатление отзывчивости на графическом клиенте может зависеть от многих факторов: не забывайте что реакция иксов будет всегда медленнее чем графического winapi

Проблема особенно явна когда через эрдипи открываю учетную запись и пробрасываю программе 1с v8 со сканера штрих код. С винды штрих проходит полностью, а в этой же учетной записи эрдипи через того же провайдера через линя ubuntu 12.04 lts штрих код приходит не весь.

проброс осуществляли при помощи какого клиента: rdesktop? freerdp?....адекватнее второй - особенно для работы с новыми вин серверами >2003, сам проброс tty я делал средствами клиента только в пределах локальной сети - по туннелю однажды эксплуатировал remserial... но немного в других условиях.

Вообще всегда следует помнить что в гетерогенных средах даже протоколы поддерживаемые разными осями - могут сталкиваться с проблемами совместимости.

 

Трабелз 2.

Один и тот же комп, одна и та же ося(вин/линь - не важно)Через большинство провайдеров vpn подключение проходит нормально, т.е. конектится, а через одного конкретного не буду называть его имя, хотя его основной корпоративный цвет green, нет соединения

как уже правильно сказал Свин:

pptp использует архаичный транспорт gre, который некоторые провайдеры блочат. мой совет - перейти на OpenVpn.

тут действительно проблема gre

[хрюконавт]

простейший вариант - конфиг на сервере

 

dev tun

port 49999

ifconfig 10.1.0.1 10.1.0.2

no-replay

float

 

конфиг на клиенте

 

dev tun

port 49999

ifconfig 10.1.0.2 10.1.0.1

no-replay

float

remote SERVER_IP

 

и тестим скорость и стабильность.

если нравится, то потом можно перейти к мультиклиентному серверу с

шифрованием на сертификатах.

 

также рекомендую ознакомиться с моими статьями

 

http://ta.gd/vpn1

http://ta.gd/vpn2

[хрюконавт]

"прохождения пакетов внутри тоннеля" - такие загадочные слова, сразу кажется,

что им там внутри как-то темно, страшно и трудно ползти.

 

на самом деле всё проще простого.

давайте разберёмся.

 

представим, что есть некие две точки с адресами A и B

они подняли некий туннель с адресами внутри C и D

 

если в A говорят "ping B" то просто уходит пакет icmp A->B

если же в A говорят "ping D" то формируется пакет icmp C->D

он вкладывается в UDP пакет с небольшим служебным заголовком и уходит

udp A->B (внутри него icmp C->D).

этот процесс инкапсуляции не требует никаких значительных ресурсов.

 

по моим наблюдениям за OpenVPN процесс обмена C<->D

и время пинга ну никак не отличается от обмена A<->B

 

так что если A<->B хорошо, но между ними же C<->D туго,

то ищите проблему в софте, который организует туннель.

[Saler]

OldBay и Чрюконавт - куда пивасика выслать?

[хрюконавт]

Пиво нам не интересно. Нам интересно, что ты сделал и какой получился результат.

[oldbay]

Пиво нам не интересно. Нам интересно, что ты сделал и какой получился результат.

+100 Свину, от пива толку мало - только голова болит: потому решай свои вопросы, то что нужно спрашивай = и пиши что получилось ... а там глядишь что то и самим пригодится

[Saler]

проброс осуществляли при помощи какого клиента: rdesktop? freerdp?....адекватнее второй - особенно для работы с новыми вин серверами >2003, сам проброс tty я делал средствами клиента только в пределах локальной сети - по туннелю однажды эксплуатировал remserial... но немного в других условиях.

 

А что скажут мавры о remmine?

[хрюконавт]

У меня WinServer2003 и VNC на основе UltraVNC,

 

остальное на Дебиане, а там только SSH нужен.

[oldbay]

А что скажут мавры о remmine?

remmina это только оболочка мультипротокольный клиент - для подключения по rdp он может использовать как xfreerdp так и rdesktop

 

кстати на лоре нашёл обсуждение по похожей на вашу проблеме : низкая скорость работы rdp клиента под linux

 

У меня WinServer2003 и VNC на основе UltraVNC

боюсь что тут может и не "проканать" - человек через rdp еще com порт пробрасывает ... может еще чего то что не указал (принтеры, блочные устройства и пр.)

Но если только экран гонять - по vnc самое то, тоже его на конторе используем в гетерогенной среде(win/lin) как стандарт ... весьма удобно.

 

Есть еще вариант nx - но он подходит только для проброса графической сессии(и некоторых устройств) с *nix сервера в направлении тонкого клиента.

[Saler]

remmina это только оболочка мультипротокольный клиент - для подключения по rdp он может использовать как xfreerdp так и rdesktop

 

кстати на лоре нашёл обсуждение по похожей на вашу проблеме : низкая скорость работы rdp клиента под linux

 

 

боюсь что тут может и не "проканать" - человек через rdp еще com порт пробрасывает ... может еще чего то что не указал (принтеры, блочные устройства и пр.)

Но если только экран гонять - по vnc самое то, тоже его на конторе используем в гетерогенной среде(win/lin) как стандарт ... весьма удобно.

 

Есть еще вариант nx - но он подходит только для проброса графической сессии(и некоторых устройств) с *nix сервера в направлении тонкого клиента.

про ком порт верно подмечено. Пробрасываю компорт для фискального регистратора (вернее принтер чеков енвд), но сие канает только на виндовых осях, как на пингвине сие сделать пока не знаю, вернее надо сначала на локальной машине настроить адекватно драйвер ккм, а потом пробросить ком порт порт по рдп(и все на пингвине)

[oldbay]

про ком порт верно подмечено. Пробрасываю компорт для фискального регистратора (вернее принтер чеков енвд), но сие канает только на виндовых осях, как на пингвине сие сделать пока не знаю, вернее надо сначала на локальной машине настроить адекватно драйвер ккм, а потом пробросить ком порт порт по рдп(и все на пингвине)

Один из драйверов ККМ часто ставлю на линуксовых станциях frs для ПРИМов(от искры) - хоть и под вайном, но работают без проблем. По сути все эти драйверы, это просто программы инициализации и настройки фискальных принтеров - по сути можно поставить под виндой на одной конкретной машине - на ней же настроить все фискалки и уже настроенные принтеры пробрасывать через com-порт на линуксовых станциях.

Есть еще опыт работы с фискалками подключенными к нативному линуксовому POS клиенту ДЭНСИ Касса , с которым можно настроить синхронизацию 1с-ки.

[Saler]

Один из драйверов ККМ часто ставлю на линуксовых станциях frs для ПРИМов(от искры) - хоть и под вайном, но работают без проблем. По сути все эти драйверы, это просто программы инициализации и настройки фискальных принтеров - по сути можно поставить под виндой на одной конкретной машине - на ней же настроить все фискалки и уже настроенные принтеры пробрасывать через com-порт на линуксовых станциях.

Есть еще опыт работы с фискалками подключенными к нативному линуксовому POS клиенту ДЭНСИ Касса , с которым можно настроить синхронизацию 1с-ки.

 

Вы драйвер ККМ от атола под вайном используете?

В винде приходиться "USB-serial" прописывать драйвер, менять при необходимости ком порт и скорость на драйвер, а потом галочку в рдп свойствах на проброс портов, а там в рдп сервера снова проверка и отлдака "дравером ККМ"

как вы в лине пробрасывает фискалку можно подробнее?

[oldbay]

Вы драйвер ККМ от атола под вайном используете?

нет, я использую в основном "драйвер" для ФР ПРИМ от искры

В винде приходиться "USB-serial" прописывать драйвер, менять при необходимости ком порт и скорость на драйвер, а потом галочку в рдп свойствах на проброс портов, а там в рдп сервера снова проверка и отлдака "дравером ККМ"

Тут я вам не скажу - в винду через rdp пробрасывал принтер и флешку + работал на клиенте в режиме remote app. Какие где галочки ставятся и как там обстоят дела с ФР незнаю.

как вы в лине пробрасывает фискалку можно подробнее?

В основном использовал софтину remserial - если с обоих концов linux, то она может работать как в режиме сервера так и клиента - как в этом примере. Если устройство к com порту подключено на linux станции, а проброс нужно осуществить на windows сервер - то можно использовать такой пример, если наоборот - то такой

 

п.с:

 

Опять таки по теории(отталкиваюсь от os linux) - "драйвер" ККМ это не драйвер в привычном нашем понимании: модуль ядра который позволяет демону udev создать файл устройства в каталоге /dev . В качестве такого устройства фискалки используют стандартный com порт /dev/ttyS0,1 и т.д. или при использовании com-usb переходника /dev/ttyUSB0,1 и т.д.

А все эти "драйвера" ККМ ФРС-ы всякие , это просто программа настройки фискального регистратора = которая сама общается с фискалкой через стандартный com порт при помощи монструозного протокола обмена в режиме вопрос-ответ кидаясь в обоих направлениях текстовыми строками. При определённом упорстве и желании можно написать собственную "приблуду" на любом языке программирования для такого "общения" с фискалкой - как прример написано на Python: для атола, для штриха.