Подключение по VPN из Беларуси тормозит

[katit]

Народ, чего можно придумать умного чтобы разрулить проблем.
Короче есть комп в Беларуси, подсоединяется к моей сетке по VPN (PPTP)

Когда работает ОК а когда тормоза, таймауты и т.д. Здесь все ОК т.к. другие клиенты тоже сидят на VPN и все отлично.

Я попробовал пинговать сервер внутри сетки, около 190мс. Без ВПН пинговал свой адрес - теже 190мс. Визуально конечно просто дуступ к сайту без ВПН быстрее а все что через ВПН капец тормозит.

Гугл к примеру пингуется ~60мс

Вот трейс до моего сервера. Много времени на "Cogent" серверах. Чего делать с этим? Как убыстрить работу?

http://forums.businesshelp.comcast.com/ ... /td-p/8459" onclick="window.open(this.href);return false;

[uncle_Pasha]

Скорее всего, ваш клиент "под колпаком". Расшифровка пакетов тоже занимает время
Еще можно попробовать уменьшить MTU на outgoing interface on the client's router (например, поставить 1300 вместо 1500 в случае кабель модема).
Но не сняв IP трассу - это как гадание на кофейной гуще.

[mitnlag]

Чините свой ВПН. Про МТУ - отличная идея.

Со скоростью пинга все нормально - соединение на пол-планеты ровно столько и занимает.

[aleh]

mgts belpak - прям как забытая колыбельная из далекого детства

[aleh]

А по теме, то почему PPTP? It is old and vulnerable.

[katit]

Меня безопасность совсем не волнует, нечего там скрывать. Ovpn будет лучше?

[aleh]

Ну я далеко не эксперт, но недавно пытался разобраться.
Про OpenVPN пишут, что "Best performance. Fast, even across great distances and on high latency connections."
Как бы неформальный стандарт для сегодня. Просто глаз зацепился.

[katit]

Я использовал тот т.к. для виндовыых клиентов больше ничего не надо было, оно работало из коробки. С OVPN надо будет заморочиться с установкоы клиента

[helg]

Может, канал перегружен. Но часто бывает, что с одной стороны на интерфейсе стоит большой MTU для пакета. Большой пакет рубится на фрагменты каким транзитным маршрутизатором, и эти фрагменты на приёмнике вместе не собираются. Помнится, на XP сборку фрагментированых пакетов так до конца и не починили.

Проверяется максимальный пропускаемый размер пакета по каналу пингом с ключиком -s SIZE с обеих сторон и находится максимальный пропускаемый SIZE. Если найденный SIZE оказался меньше MTU на интерфейсе с какой-либо стороны, MTU на интерфейсах с обеих сторон уменьшается до пропускаемого размера.

Если с серверной части винда, которая цепляется к другому оборудованию, то от снижения MTU на одном из её интерфейсов может появиться побочных эффектов. Но это уже второй этап разруливания.

[katit]

Может, канал перегружен. Но часто бывает, что с одной стороны на интерфейсе стоит большой MTU для пакета. Большой пакет рубится на фрагменты каким транзитным маршрутизатором, и эти фрагменты на приёмнике вместе не собираются. Помнится, на XP сборку фрагментированых пакетов так до конца и не починили.

Проверяется максимальный пропускаемый размер пакета по каналу пингом с ключиком -s SIZE с обеих сторон и находится максимальный пропускаемый SIZE. Если найденный SIZE оказался меньше MTU на интерфейсе с какой-либо стороны, MTU на интерфейсах с обеих сторон уменьшается до пропускаемого размера.

Если с серверной части винда, которая цепляется к другому оборудованию, то от снижения MTU на одном из её интерфейсов может появиться побочных эффектов. Но это уже второй этап разруливания.

Ок, для меня это уже немного адвансд Но тем не менее. Как я понимаю шаги должны быть такими:
1. Проверим пинг и размер пакета (кстати оно даже иногда при стандартном пинге таймаутит)
2. Серверная сторона - Mikrotik router. PPTP MTU/MRU стоит 1450, keepalive 30. Ovpn стоит 1500, keepalive 60 но пока его не пробовали
3. Когда я смотрю на подключенных клиентов (PPTP) показывает "actual MTU 1400" для всех клиентов (и тех что в Америке)

[helg]

Раз короткие пинги теряются, значит таки канал перегружен или какой-то маршрутизатор по дороге. Тут шаманство с mtu не поможет.

Попробуйте найти глючный маршрутизатор.

Запросто в каком кондёр высох - и он перегружается. Или он старый, и процессора не хватает. Если все хороши, купите канал без потерь - и будет вам счастье. Можно, конечно, на существующем канале с потерями поиграться с tcp retransmit timeout и увеличением размера очереди. Замирания не уйдут, но станут короче. Но это как локтями в толпе орудовать: остальным в толпе от этого хуже, и если все будут толкаться, хуже будет всем.

[Palych]

А VPN реализован на роутере или на компьютере?
Может на роутере ресурсов не хватает (CPU, memory)?
У меня такое и без VPN было, даже с NAT не справлялся, я здесь писал...

[aleh]

Ежели почитать ссылку из первого поста, то там пишут,что нетфликс сидит на Cogent серверах и как только приходит вечер, то начинаются траблы со скоростью через Cogent

[katit]

А VPN реализован на роутере или на компьютере?
Может на роутере ресурсов не хватает (CPU, memory)?
У меня такое и без VPN было, даже с NAT не справлялся, я здесь писал...

Да раутер вроде справляется. Нет никаких проблем ни внутри ни у других клиентов.
Может ресурсов на клиенте не хватает? Такое может быть?
Даже вот по TeamViewer подключаешься к клиенту. Все вроде ОК. А то что по VPN идет прямо тормозит.

Прямо такое чувство что именно VPN трафик тормозят.

[mariad_10]

Ну я далеко не эксперт, но недавно пытался разобраться.
Про OpenVPN пишут, что "Best performance. Fast, even across great distances and on high latency connections."
Как бы неформальный стандарт для сегодня. Просто глаз зацепился.

As far as i know, almost all vpn providers work with the Ovpn protocol, please correct me if i am wrong.