Проблема обрыва VPN

  1. sid
    Для серфа использую vpn-подключение с софтом vpn-провайдера. Периодически случаются обрывы и траф летит в сеть нешифрованный. Подскажите, как можно устранить эту проблему? (Кроме SSH)
     
  2. VPN-то какой? от прова? Если сторонний, анонимный, то и софт лучше использовать тот, что предоставляет сервис.
     
  3. sid
    Сейчас vpn от privatetunnel.com, софт также их
     
  4. Ну, тогда советую обратиться в службу поддержки, это их проблемы.
     
  5. Часто встречаю сообщения на подобную тему, но ни как не могу понять суть проблемы.
    Сам более 5 лет настраиваю OpenVPN для корпоративных клиентов, но с такой проблемой как утечка трафика мимо туннеля VPN, ну не сталкивался, хоть убейте и не понимаю теорию данного бага у некоторых пользователей.

    На моей практике всё это выглядит в точности так:
    - происходит коннект к серверу VPN по IP
    - проверка ключей
    - установка соединения
    Далее сервер VPN командой push изменяет на стороне клиента маршрутизацию, основной шлюз и заменяет DNS сервера.

    Смотрим на практике.
    Примерно так выглядит таблица маршрутов до подключения VPN:
    Код:
    c:\>route print
    …
    IPv4 таблица маршрута
    Активные маршруты:
    Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
              0.0.0.0          0.0.0.0      [шлюз_моего_провайдера]      [мой_IP_у_провайдера]     20
    …
    Постоянные маршруты:
      Отсутствует
    Смотрим кто сейчас резолвит DNS:
    Код:
    C:\>nslookup
    Default Server:  [мой_провайдер]
    Address:  [dns_моего_провайдера]
    Теперь подключаем VPV:
    Код:
    Wed Dec 14 01:54:42 2011 OpenVPN 2.2.1 Win32-MSVC++ [SSL]...
    ...
    Wed Dec 14 01:54:58 2011 Initialization Sequence Completed
    Соединение установлено. Проверяем заново маршруты:
    Код:
    c:\>route print
    …
    IPv4 таблица маршрута
    Активные маршруты:
    Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
              0.0.0.0        128.0.0.0         10.8.0.9        10.8.0.10      1
    …
    Основной шлюз:            10.8.0.9
    Как видим, добавился новый маршрут и к нему основной шлюз, на который теперь пойдут все пакеты, явно не указанные другими маршрутами.
    Проверяем сервер имен:
    Код:
    c:\>nslookup
    Default Server:  ns1-cache.securedservers.com
    Address:  174.138.175.115
    Вот и отлично, ибо это уже далеко не наш провайдер.
    На всякий случай проверяем трассировку маршрута до любого сайта, что бы убедиться в том, что трафик идет через VPN:
    Код:
    c:\>tracert google.com
    Трассировка маршрута к google.com [74.125.227.16]
    с максимальным числом прыжков 30:
      1   32 ms   32 ms   32 ms  10.8.0.1 – это внутренний IP сервера VPN
      2   32 ms   32 ms   32 ms  [внешний_шлюз_сервера_VPN]
    …
     13   32 ms   32 ms   32 ms  dfw06s03-in-f16.1e100.net [74.125.227.16]
    Трассировка завершена.
    Замечательно. Трафик от нас теперь идет по шифрованному каналу, сервер DNS используется чужой.

    И тут Остапа понесло… )
    Что-то я увлекся, извиняюсь. Хотя, может быть кому-то это будет познавательно в принципе работы через VPN.

    Теперь по сути топика. Роняем удаленный сервер VPN для эксперимента.
    # service openvpn stop
    Stopping virtual private network daemon: server.

    Отлично. Соединение VPN упало.
    Ни чего теперь не трогаем у себя на компьютере, просто проверяем доступность интернета:
    Код:
    c:\>ping google.com
    При проверке связи не удалось обнаружить узел google.com. Проверьте имя узла и
    повторите попытку.
    c:\>tracert google.com
    Не удается разрешить системное имя узла google.com.
    Всё. Ни чего не работает и не заработает до тех пор, пока не восстановится соединение VPN. По крайней мере, у меня именно так.

    В процессе эксперимента исользовались:
    - сервер OpenVPN 2.0 на Debian 6
    - клиент OpenVPN 2.2.1 Win32 на 2003 Serv.

    P.S. В результате эксперимента ни кто не пострадал, с уроненным сервером работают менеджеры, днем в офисе.
     
    3 пользователям это понравилось.
  6. big-hearted,
    а как работает система VPN, если у каждого статический IP?

    Т.е. выдали модемы, на одном я выбрал режим статик-ip, указал свой ип, и шлюз, а также внутренний лан-адрес модема, и на втором. Так оно должно объединить две сети через телефонную линию. Но почему-то я не могу пинговать из одной сети вторую. Может какие-то роуты дополнительно надо прописывать?
     
  7. Dr. MefistO, если я правильно понял вопрос, то речь идет о связи своих компьютеров через VPN. Если так, то разницы нет, статика или динамика на модемах. Разницы вообще нет каким образом компьютер подключается к интернету. Главное условие на стороне клиента - это возможность получить доступ к внешнему IP сервера VPN по указанному порту. После соединения все компьютеры, подключенные к одному серверу VPN, оказываются в одной локальной приватной сети 10.8.0.1/24. Логично, что между компьютерами в одной локальной сети можно делать что угодно, даже если они находятся в разных странах мира.
    Другое дело в том, что продавцы VPN по понятным причинам закрывают опцию обмена пакетами client-to-client.
     
  8. Что можно проверить? Вообще, это услуга нашего провайдера Белтелеком - это он организовал корпоративную впн-сеть.

    Настройки у клиентов такие (например):
    первая сеть:
    - впн-модем (основные настройки):
    * ип-адрес 192.168.1.9
    * маска 255.255.255.252
    * шлюз 192.168.1.10
    - впн-модем (внутрисетевой адрес):
    * ип 192.168.14.1
    * маска 255.255.255.240

    вторая сеть:
    - впн-модем (основные настройки):
    * ип-адрес 192.168.1.25
    * маска 255.255.255.252
    * шлюз 192.168.1.26
    - впн-модем (внутрисетевой адрес):
    * ип 192.168.12.100
    * маска 255.255.252.0

    При таком раскладе оно должно из сети 1 пинговать сеть 2? Я чет в это не очень въезжаю...
     
  9. Dr. MefistO, надо читать условия провайдера или позвонить в сапорт и задать вопрос о возможности обмена трафиком напрямую между клиентами их VPN.
    Но вообще, было бы глупо, если бы провайдер разрешил это. Представ, сканируешь локальную сеть, а там тысячи доступных чужих компьютеров. Это же настоящий праздник для некоторых ))

    Добавлено через 4 минуты
    Попробую предположить, что провайдер настроил сеть таким образом, только для того, что бы спрятать своих клиентов за NAT.
     
  10. Просто у меня не получилось настроить, но в соседних районах у коллег вышло. Т.е. в сети разрешен трафик только между этими двумя сетями.
     
  11. Если всё же обмен пакетами открыт, то надо смотреть какие диапазоны адресов у удачливых коллег. Однако, в твоем случае IP второго VPN не попадает в диапазон адресов первого VPN:
    Этот диапазон включает адреса 192.168.14.1 - 192.168.14.14.
    Сам же видишь, что 192.168.12.100 в него не попадает.

    Смотри внимательно таблицы маршрутов, считай теорию на калькуляторе, а потом проверяй эту теорию на практике через трассировку. Полную таблицу маршрутов ни кому не показывай, верить нельзя ни кому )
     
  12. :fuck: "DC(++) наше все!")))))
     
  13. Я уж надеялся, что все DC++ вымерли как мамонты после прихода bit-torrent :)
     
  14. :) В bit-torrente потрындеть нельзя; не у всех пока интернеты достойные, чтобы с такой же скоростью тащить извне.

    Плюс к тому, DC++ просто пример, шутки ради. В нормальных сетях игровые сервера, к примеру есть. Как с ними быть? :)
    Как быть с радиовещанием через LAN?
     
  15. sid
    На днях тестил бесплатный вариант VPN от securitykiss.com. Уже была пара обрывов и траф так же шел в инет напрямую в этом случае. Т. к . поключение через их софт, сам ничего настраивать в OpenVpn не могу. Проблему решил с помощью запуска батника после подключения к VPN, который удаляет первоначальный маршрут - железный вариант*mrgreen*
     
    1 человеку нравится это.
  16. ~|~евто|-|, тут я конечно проявил долю эгоизма, каюсь. О больших сетях и их пользователях даже не подумал :-[
    На порядок лучший вариант, нежели доверять свою безопасность каким-то сомнительным программкам.
     
  17. Тут все дело в настройках клиента. Сам только занялся изучением OpenVPNа( раньше сидел плотно на корп решениях). Вот маршруты "иногда" добавляются, а не заменяются. При отвале ВПНа получаем что дефолтный маршрут все также смотрит на провайдерский шлюз. Особо не разобрался в проблеме, но подтверждаю имет место быть.